This article can also be found in the Premium Editorial Download "Storage magazine: Low-cost storage pieces fall into place."
Download it now to read this article plus other related content.
iFCP: improved error isolation
iFCP is a peer-to-peer gateway IP protocol that provides connection services to FC devices over an IP transport using TCP for the same reasons as I mentioned earlier. SAN islands or individual devices are bridged into the IP network using an iFCP gateway device (see "How iFCP works," on this page). Once bridged, FC devices are assigned an IP address by the gateway for communication across the TCP transport. Thus, after the address is assigned, the FC device will have an ARP-like entry in the iFCP device that refers to both its native FC address and its foreign IP address.
iFCP vendors are able to replace FC switches because their iFCP devices intercept communication coming from locally attached FC devices and either pass the frames to a locally attached FC destination or well-known services, or establish a TCP/IP connection to a remote iFCP gateway and then ship the communicated frame across the IP transport.
Central to the initial discovery and subsequent communication between devices in an IP SAN is the Internet storage name server (iSNS). Similar in functionality to the name server in FC networks, iFCP or iSCSI devices must register their characteristics with an iSNS server residing either in an IP storage device or possibly a centralized iSNS server. Then the device is added to a discovery domain (zone), and is only accessed by the devices in that domain. As with FC SANs, state change
iFCP has two strengths that aren't evident in FCIP:
- FC protocol errors are contained to gateway region being managed by the iFCP gateway
- TCP connections and flow control are managed at the device level
However, with proper zoning, state change notifications (SCNs) will be confined to their respective zone members. As for flow control, because FC devices are assigned IP addresses in iFCP, congestion is managed separately between the communicating pairs. With FCIP, congestion is only managed between the FCIP devices extending the fabric, and not the individual devices. However, this is only likely to be a problem if the bandwidth specifications for both the FC and IP sides of the FCIP device don't match.
iSCSI: Management challenges
Of the long-distance SAN link solutions, iSCSI products have been the slowest to come to market. Perhaps this is because the protocol itself is a complete reworking of how servers access their storage. Both FCIP and iFCP borrow from the FC specification for communicating between end nodes. iSCSI, on the other hand, implements its own protocol stack for the transmission of block data.
As a result, iSCSI vendors had the opportunity and decided to include all the requisite intelligence in the iSCSI interface and thus enable the use of generic IP platforms to transport data over the SAN. This is contrary to FC SANs, where much of the intelligence is in the switching infrastructure. Here, I see a potential for increased administrative burden unless tools are developed to interrogate iSCSI interfaces across the SAN for possible problem resolution. Each device on an iSCSI SAN is outfitted with an iSCSI interface connecting it to the SAN. Unless the SAN administrator has access to the logs of the device drivers on each node from a central point, you will need access to each node point to resolve problems.
Addressing in iSCSI is based on a hierarchy of network identities. At the highest level, there is a network entity identified by an IP address and port number. Underneath the network entity is the iSCSI node name, which is individually managed and can be as long as 255 bytes in length. In this case, the network entity may be the controller on a storage array, and the iSCSI node names the individual disks that sit behind the controller.
As mentioned earlier, iSCSI devices will register with the iSNS server and initiators will discover their targets within the domain. Communication paths are created between the initiator and target through a login process similar to FC. Operating parameters are exchanged and agreed on before a login is accepted.
One challenge with iSCSI is that the SCSI is intolerant of errors on the transport. Put that together with the susceptibility to loss in IP networks and you have a problem. With this in mind, implementing an iSCSI long-distance SAN link requires the highest quality of IP connectivity between sites.
Another challenge is the CPU overhead on iSCSI nodes while processing packets. To address this issue, manufacturers of iSCSI interface cards have added TCP offload engines to handle much of the interrupt processing associated with sending packets on the IP network. Still, you should test the raw performance of a potential vendor's iSCSI interface card before moving off an existing technology or selecting a new one.
This was first published in October 2003