A word of personal preference/advice:
I recommend mapping out the hardware and software configuration before you begin implementing. By this I mean, establish a logical map of your physical layout and work from this throughout the build. Map physical NIC ports and note the networking details associated with them. This will be a good reference point when actually building the environment.
Step-wise, the tasks to be completed when building an environment from scratch are as follows:
- Build server OS and assign IP addresses accordingly to NICs
(I recommend naming the NICs for their particular purpose prior to assigning IPs.
A potential naming scheme could follow the template
[node_card_port_purpose, eg. N1_intel1_P0_iSCSI1] )
You will be using at least 2 subnets depending on the purpose of the server.
E.g. 192.168.1.x for regular server management traffic and 10.10.10.x for iSCSI
- Settings to be configured on switch for iSCSI traffic
Flow control : enabled
Storm control : disabled
Jumbo frames : enabled
- Configure V-lans for iSCSI network
- Connect to Equallogic management com port interface through putty and configure:
* grpadmin password
* EQ member name
* eth0 IP address (on 10.10.10.x network)
* eth0 subnet
* eth0 gateway (use fake gateway as there is likley * no gateway on network used for iSCSI)
* group name
* group IP address
- Connect to web GIU for EQ via group IP address and configure remaining interfaces for management
eth1-iscsi (this will be on the 10.x network)
eth2-mgmt (this will be on the 192.168.x network and will be the IP you use for the web interface from now on)
- Update SAN firmware (this is obtained from the Equallogic support site)
- Configure a storage pool then configure the member with RAID version desired
- Decide on weather or not to use authentication (in our tests we did not)
- Create any volumes required for the environment
- Download,install and run Host Integration Toolkit on each host (the HIT is provided from the Equallogic support site)
- Run HIT configuration for MPIO, in our testing the least queue depth option resulted in predictable utilization drops when stress testing)
- Connect to LUN’s via Microsoft iSCSI initiator and add to favorites
When performing Microsoft JetStress testing on a CSV volume, we experienced predictable repetitive drops in iSCSI utilization on both NICs. This occurred when using the MPIO configuration for Least Queue Depth. When these were configured for Load Balancing, the utilization remained constant during the stress testing.