Simple iSCSI Best Practices (Top 3)

Setting the stage and expectations of iSCSI.
A lot of conversations on this topic seem to arise when talking about data center architecture.  Most of my brethren in the enterprise, never dip their toes into these waters, because of legacy architecture standards, fabric technology investments, and team skills.  A lot of people would go as far to say that Fibre Channel is actually easier to use. 

Nonetheless, in the commercial sector where 80% of the business market exists, iSCSI many times is the way to go.  Especially when throughput does not dictate more than real world iSCSI capabilities… and when your data center communication backbone is TCP/IP… and the team skills are primarily TCP/IP.  Then iSCSI is arguably easier to use.

Real World statistics… iSCSI’s best use is when throughput is below (<60MBps). While higher performance is possible with iSCSI, the increased cost (iSCSI HBAs) and complexity (dependence on load balancing) offsets the normal iSCSI “simplicity/cost” benefits, at least with today’s Gigabit Ethernet. Generally speaking, many servers are usually below this 60MBps limit and are good candidates for iSCSI connectivity.  The best way to find out are by collecting statistics through IOSTAT, Perfmon, or other built in tools that measure the OS and the applications.  Email me to find out the mathmatic formulas to crunch the numbers.

The net of this if course is, make sure your architect or consultant is recommending iSCSI when it is appropriate for you.  Not just because it is the only protocol his or her storage can leverage.  That’s like me going to ask a Ford dealer if he has any Chevy autos on the lot for sale.  What do you think he will say?

With that being said… here are the nuts and bolts behind iSCSI best practices.  Top 3 best practices.

#1 Use a Private Network for an iSCSI SAN (see diagram)

#2 Network Considerations (Security)
• Private networks are typically more secure
– Allow segregation of both everyday and iSCSI traffic
– Port-level VLANs can act as a form of zoning

• Initiator to Target authentication
– Challenge Handshake Authentication Protocol (CHAP)
– Initiator CHAP
• Target sends challenge to initiator
• Initiator responds with a calculated value to the target
• Target checks the calculated value, and if it matches, login continues
– Mutual CHAP
• Target challenges & authenticates with initiator
• Initiator challenges & authenticates with target

How does security work?

Now that the connection between the server and storage system has been established, CHAP can be enabled to enhance security. CHAP is a protocol that is used to authenticate the peer of a connection and is based upon the peer sharing a password or secret. The iSCSI protocol requires vendors, like EMC to include the CHAP protocol in the package. The decision to implement CHAP in any environment is up to the system administrators. EMC supports both one-way and mutual CHAP.  Each target can have its own unique CHAP secret for one-way CHAP and the initiator itself has a single secret for mutual CHAP with all targets.

To configure CHAP, use Navisphere Manager to configure the storage system ports and use the vendor tools for either the iSCSI HBA or NIC installed on each initiator host. For a NIC on a WIndows server, use the Microsoft iSCSI Initiator software (most Linux & Unix OSes have this built in as well) and for an HBA, use the HBA management software (typically installed when installing the drivers -both for WIndows or Linux/Unix servers). Note: When using the HBA and software, CHAP often must be configured for the HBA first and then configured on the storage system second (there may be exceptions).

When the Initiator attempts to access the array, it negotiates with the target that CHAP is to be implemented and what hashing engine will be used on each side.  The target then builds a CHAP challenge packet with three essential values, a sequential ID number that is used in all of this series of packets and a random value generated by the target and the authentication name of the challenger target.  The target, then sends the challenge packet to the initiator.  The initiator then takes the sequential ID and the random value from the challenge packet and feeds that into the hashing engine.  The initiator also takes the authentication name from the challenge packet and looks up the secret it has for that authentication name and feeds the secret into the hashing engine.  The initiator using the hashing engine generates a hash value, which it sends bank to the target in a challenge response packet. The target then takes the sequential ID and the random value from the challenge packet it sent and feeds that into its hashing engine.  The target also takes the authentication name from the challenge packet and looks up the secret it has for that authentication name and also feeds that secret into its hashing engine.  The target using its hashing engine generates a hash value, which it then compares to the hash value it received from the initiator in the challenge response packet.  If the two hash value are the same a CHAP success packet is sent to the initiator and the link is established.  After this the target can randomly challenge the initiator during the communication.  If the hash values are not equal in our implementation the link is dropped.

#3 Performance Considerations
• Best Practices for an iSCSI environment
– Attached hosts should always use supported 1 Gb/s devices
• 1 Gb/s iSCSI HBAs are best due to the TCP/IP offloading
• 1 Gb/s NIC provide lowest cost –and are fine, however consume more host cycles
– Always use a dedicated 1 Gb/s private network for data traffic

What other best practices have you found to be of value?

Comments

[Steve (click here, to go back to the main page)]

If you like this article, then please check out this podcast from a joint effort description on best practices posted by engineers from EMC, NTAP, HP, Dell, and VMware

http://bit.ly/az3M9

And also do not forget to read my re-posted article from these same people here;

http://bit.ly/fRgpt