iSCSI storage networking: What you need to know

As simple as iSCSI is to get running, configuring it to perform optimally requires a solid knowledge of how it actually works

Over the past two weeks, I've written about some of the commonly overlooked aspects of building a bulletproof IP storage network and how to best use that network with NFS. This week, I'll show you the ins and outs of configuring iSCSI for performance and redundancy, as well as how it compares with NFS.

The first thing to understand is that although NFS and iSCSI are both IP storage protocols supported by many server operating systems and hypervisors, that's about as far as the similarity between the two extends. NFS is a high-performance file-sharing protocol in the same vein as SMB/CIFS, while iSCSI is a block-level storage protocol more akin to Fibre Channel in that it encapsulates raw SCSI commands. This distinction is important because it has significant bearing on how you get redundancy and performance scalability.

iSCSI vs. NFS on the network: How they differ

When comparing the networking requirements of NFS and iSCSI, the largest practical difference is that the iSCSI protocol has built-in redundancy and link aggregation capabilities, called multipath input/output (MPIO). NFS lacks MPIO. You can use MPIO to offer both link redundancy and additional throughput -- entirely without the use of the problematic NIC/link teaming that's required to do the same for NFS.

In a typical NFS configuration, servers are each configured with a single-storage IP address bound to a NIC team spread across two stacked switches. On the storage side, the same configuration is duplicated, except that the storage is generally configured with a second IP address alias to allow better load balancing over the team members because the NIC teaming algorithms use source and destination IP address to load-balance traffic. In this scenario, the failure of an individual link or entire switch stack member is handled by the NIC teaming software -- the NFS client and server software isn't involved.

By contrast, iSCSI configurations use separate, unteamed NICs each with its own IP address on both the server and storage side. When properly configured, the iSCSI initiator software on the server and target software on the storage array build multiple storage connections across those links, so each of the two interfaces on the server has a connection to both of the interfaces on the storage array. If an individual link or one of the redundant storage switches failed, the iSCSI initiator software would recognize that two of its four storage paths had become unavailable and would funnel all traffic over the other two paths.

The exact means by which iSCSI initiators (servers) and targets (storage arrays) work together depends somewhat on what server-side software is used and what array it is connected to. That's why the Microsoft iSCSI initiator works slightly differently than the software iSCSI initiator built into EMC VMware's vSphere. Likewise, the iSCSI target software in an EMC VNXe SAN differs slightly from that in a Dell EqualLogic SAN in how it load-balances connections and offers targets and LUNs.

In all cases, it's vitally important to read your storage vendor's documentation and check out support forums for tips because different OS/array combinations can have significantly different best practices. If you really want to get the most out of your array and network, it's very rarely ever as simple as punching in some IP addresses and calling it a day.

iSCSI setup in practice: An example

Let's say you've been charged with connecting a VMware vSphere host to a Dell EqualLogic PS4100 over the physical network that I outlined in an earlier post. This entry-level array is fairly simple in that it has only two storage interfaces on each of its two controllers.

Attaching to the switch is simply an issue of plugging the first interface from the first controller and second interface from the second controller into your first network switch, then plugging the remaining two ports into the second switch. Because this array's controllers are used in an active/passive configuration, staggering the NICs across the switches ensures that the failure of a switch won't isolate all the interfaces on the active controller at the same time, which could prompt a controller failover.

EqualLogic arrays are configured with a group IP address (the portal address), as well as individual IP addresses assigned to each active physical interface. At the end of the day, you end up with three IP addresses on the storage array, but the group address is the only one you'll type in anywhere. The other two are used behind the scenes.

1 2 Page 1
Page 1 of 2