This article can also be found in the Premium Editorial Download "Storage magazine: Exploring new options for disk-based backup."
Download it now to read this article plus other related content.
|Best suited for...|
In contrast to FCIP, iFCP translates 24-bit FC addresses to the Internet addresses of the IP protocol. The data in the FC packet is roughly equivalent to the data in the IP packet but, to use the envelope analogy again, the FC-addressed envelope is given an IP-addressed label before it's given to the IP postman to deliver. There's no overhead, but the labeler has to have enough intelligence to write the new label quickly. When the envelope is opened, the data is revealed, rather than another envelope as with FCIP.
Because of the translation service between FC and IP, an iFCP fabric on one side of an iFCP port sees all of the fabrics on the other side of the IP link as separate and autonomous fabrics, each with an IP address. Using our earlier example, this means the Atlanta SAN would need only a single IP access point to send out all of its IP packets that are routed to Boston, Chicago or wherever. Adding a new data center doesn't require new tunnel provisioning for all associated pre-existing data center switches, although the switch would have to be made aware of the new IP/FC association.
The translation provides an easy segmentation point, and a fabric on one side of an iFCP connection remains autonomous from the fabric at the other side with all of its own fabric-related services. Each fabric is still subject to the FC protocol limitation of 239 switches, but this limitation is confined to each connected SAN rather than to the overall logical SAN that includes all of the connected SANs. A single but very large data center SAN, or even a campus SAN, can be segmented in the same way that SAN islands across a WAN would be segmented. Within a large FC SAN, the FC e-port connections between switches could be replaced with iFCP connections. In this way, a department might have a SAN with only an occasional need to connect to a larger local backup SAN. The iFCP connections become a means of reducing the effect of a fabric reconfiguration to functionally isolated switches.
The resiliency of iFCP is identical to that of the Internet because iFCP requires only ping-able access with a low drop rate from one iFCP access point to another to function properly. In practice, storage administrators are very unlikely to drop their iFCP packet out onto the public Ethernet or to simply trust the speeds available on their company's private intranet connections. Both will require careful networking provisioning and detailed knowledge of network traffic pattern ebbs and flows. But iFCP provisioning is easier than FCIP provisioning because the latter adds the complexity of tunnel management to the management of private intranet connections.
iFCP is more resilient than FCIP because autonomous fabrics can better accommodate opportunistic connections between remote FC SAN islands. The impact of a connection loss to a fabric can be tolerated by the infrastructure until such time as a data flow is needed.
The innovative potential for iFCP far exceeds FCIP because iFCP has the means of representing all end nodes of the FC SAN with separate and unique IP addresses. The network address translation from FC WANs to IP addresses lets IP vendors apply mature IP solutions such as time-of-day allocations down to the storage port on a particular disk frame or an FC tape drive in a library. This potential will always be far beyond the reach of the FCIP switch's vendor development teams, who will need to write the solution into FC-based tools before the user can reap any benefit.
Some users may anticipate the demise of FC as iSCSI gains popularity; indeed, high-priced FC might be dealt a fatal blow when enterprise-class iSCSI disk frames arrive. Many managers will have to decide whether to pay high FC SAN prices now or wait for wider adoption of the iSCSI solutions.
iSCSI networking will always remain separate from FCIP networking, and an FC hardware vendor will need to provide the bridge. The iFCP protocol design creates the bridge that can allow FC-based disk frames to communicate with iSCSI server host bus adapters because it already incorporates a Network Address Translation between FC and IP.
Users tend to dismiss the implications of protocol choices as details for vendors to work out. But vendors are working out the details of their own solutions, creating features to meet the current business needs their marketing departments have identified. The FCIP protocol will prolong the current reliance on FC networking. The iFCP protocol will shift this reliance to TCP/IP networking solutions, the solutions in place for iSCSI implementations. Ultimately, iFCP and iSCSI SANs may appear indistinguishable to administrators.
This was first published in June 2005