Until recently, iSCSI was deployed mostly by small and midsized firms migrating from direct-attached to networked storage; large organizations remained loyal to more mature and proven Fibre Channel (FC) SANs. But the technology's low cost and simplicity has an increasing number of Fortune 1000 firms complementing their FC infrastructure with iSCSI SANs for data protection and Tier-2 storage.
Marrying iSCSI to FC isn't without its challenges. Bringing iSCSI into existing FC SANs not only raises integration issues, it leads to a somewhat more complex storage infrastructure that requires IP and FC knowledge, as well as the ability to manage and troubleshoot a multiprotocol storage environment. Storage architects attempting to go down this path must be familiar with iSCSI design options as they affect performance, security and availability.
Performance
Some of the novelties of iSCSI are related to the nature of the IP protocol. While the FC protocol is optimized for networks dedicated to connecting servers to arrays, IP-based iSCSI SANs may have to compete with nonstorage IP traffic. To minimize the impact of disruptive IP traffic, data center managers are isolating iSCSI traffic from nonstorage traffic via dedicated iSCSI networks that have no physical connection to the rest of the network, or leveraging Ethernet isolation techniques like access control lists and Virtual LANs (VLANs).
Although physical and virtual segregation greatly enhance security and performance, storage managers may need to resort to advanced Ethernet techniques like Ethernet jumbo frames and enabling flow control on the network switch and adapters to alleviate congestion and optimize throughput. In cases where the bandwidth of a single gigabit link doesn't suffice, multiple links may have to be combined into a single aggregated link by taking advantage of Ethernet trunking or link aggregation; this can sidestep the need to deploy an expensive 10Gb Ethernet infrastructure to overcome bandwidth limitations.
On the host-side, TCP offload engines (TOEs) and iSCSI HBAs can save valuable CPU cycles, especially on slower or performance-critical application servers. Although TCP and iSCSI overhead of 1Gb/sec connections is less than 10% on state-of-the art server hardware and 85% of today's iSCSI deployments just use software iSCSI initiators, according to David Dale, chairman of the SNIA IP storage forum, TOEs and iSCSI HBAs will play a much larger role once 10Gb iSCSI becomes more prevalent. Besides the I/O performance boost, iSCSI HBAs come with added services like the ability to boot from a SAN and encryption.
In mixed-protocol environments, storage managers need to be aware of Ethernet oddities like erroneous speed/mode autonegotiations between Ethernet switches and network interface cards (NICs) because they can have a detrimental impact on iSCSI network performance. To eliminate the possibility of autonegotiation problems, some users hardcode all switch and server Ethernet ports.
Security
The different approaches taken by iSCSI and FC to secure storage access are probably the biggest hurdles multiprotocol storage architects have to deal with. While FC leverages FC switches for zoning, arrays for LUN presentation and host identification through worldwide names, iSCSI secures storage access through a combination of the aforementioned physical and virtual isolation of the iSCSI network, as well as access restriction by IP addresses, initiator-target names and internal/external CHAP authentication.
Although it may seem confusing to have multiple iSCSI authentication options, there's a simple rule of thumb: For isolated IP-based iSCSI networks, initiator-target name authentication will typically suffice. In situations where the iSCSI network is physically connected to the LAN, the stronger CHAP authentication should be deployed, eliminating the external threat of spoofed IP addresses accessing iSCSI LUNs. In environments with a large number of iSCSI devices, central authentication via a Radius server eliminates the need to manage user credentials in iSCSI targets.
One of the big benefits of iSCSI over FC is the native support for IPsec encryption within the IP protocol, and it should be used whenever IP traffic may fall into the wrong hands. But the overhead of IPsec encryption on a busy server can be significant. In environments with IPsec turned on, servers and bandwidth-hungry desktops should be equipped with iSCSI HBAs or NICs with hardware encryption available from companies like Cavium Networks Inc. At the network level, encryption appliances from companies such as Decru Inc. (now a NetApp company) and NeoScale Systems Inc., which sit in the data path, encrypt the FC and iSCSI data before it reaches the network-attached storage arrays.
Storage management interfaces are highly vulnerable to security lapses, but are often neglected during storage design. Using default passwords, a single password for all storage devices or passwords that are never changed puts an otherwise well-designed SAN at risk. Securing management interfaces by making them accessible only from certain systems and VLANs with strong password policies, and using a centralized Radius authentication server in environments with a large number of IP devices, reduces the risk of unauthorized management changes.
Availability
Availability is the most important requirement for any SAN, including iSCSI SANS, and it needs to be architected at the server, network and array level. At the network level, redundancy is achieved by deploying switches in pairs and leveraging Ethernet failover techniques like spanning tree and dynamic routing. At the server level, high availability is achieved by dual-connecting servers to Ethernet switches; with Microsoft Corp.'s 2.0 release of its iSCSI Initiator in 2005, multipath IO (MPIO) has enabled iSCSI hosts to redundantly connect to the iSCSI network.
Redundancy options in iSCSI targets vary by vendor and product type. ISCSI gateway appliances, intelligent storage switches and server-based iSCSI targets are typically available in cluster configurations in which two devices run in active-active or active-passive mode. Some midrange storage arrays with iSCSI support, such as EMC Corp.'s Clariion CX3-20 and CX3-40, provide redundancy via dual-controller architectures. High-end arrays like the EMC Symmetrix DMX family are chassis based and redundancy is obtained by simply adding multiple iSCSI blades.
ISCSI integration options
ISCSI can be integrated into an existing FC SAN at various levels and to varying degrees, depending on the existing storage environment and integration goal. On one hand, there are storage architects like Baylor College's Layton whose main goal is to access all existing FC storage via iSCSI. At the other end of the spectrum are storage managers like Dharni who have completely migrated to iSCSI, eliminating their FC SANs. Another option is to run FC and iSCSI SANs side by side, the approach taken by Spokane Public Schools' Mount and Dan Schneidemantle, data systems manager at Logs Financial Services Inc., Northbrook, IL.
In the latter case, the key design consideration is the extent of the iSCSI FC SAN integration. In many mixed-protocol environments, storage architects deploy an additional iSCSI SAN that runs in parallel to the existing FC infrastructure, each managed separately, to avoid complex integration issues. "Most of our customers run the iSCSI SAN separate from their FC SAN," says Eric Schott, director of product management at EqualLogic Inc. "Mapping iSCSI LUNs and FC LUNs, which employ a very different security model, isn't a trivial task," says Schott, "and to many storage architects the integration benefits aren't worth the added complexity."
Unified management of iSCSI and FC SANs is doable with multiprotocol storage arrays from a single vendor. EMC, HDS, Hewlett- Packard (HP) Co. and Net-App all offer multiprotocol arrays that manage iSCSI, Fibre Channel and, in some cases NAS, under a single umbrella. Unified storage management can also be accomplished with iSCSI virtualization products from companies such as FalconStor Software Inc., NetApp and Sanrad Inc.
