This article can also be found in the Premium Editorial Download "Storage magazine: Storage products of the year 2003."
Download it now to read this article plus other related content.
|Making the IP to FC connection|
|Administrators responsible for|
| configuring Fibre Channel (FC) storage area networks (SANs) have become familiar with the concepts of zoning and LUN masking to ensure that SAN storage is only presented to the appropriate hosts. Zoning involves segregating sets of ports or world-wide names (WWNs) to isolate access. (For an in-depth discussion of zoning, see W. Curtis Preston's series of three articles, beginning with "Protect Your SAN From Attack" in the August 2003 issue of Storage). LUN masking involves building the appropriate mapping tables of host WWNs with corresponding storage WWNs.
How do you do this for an iSCSI host? "iSCSI host to FC storage" shows an iSCSI host connected to an FC storage array through a gateway switch that supports both FC and iSCSI protocols. The gateway provides a virtual iSCSI target for each physical FC SAN target device. To successfully provide the host with access to the storage requires implementing iSCSI and FC access control mechanisms.
On the iSCSI side, there are no WWNs or zones. Instead, several other constructs are utilized, including some that are standard within TCP/IP networks and others that are unique to iSCSI. For addressing, iSCSI uses TCP/IP addresses and ports. Each initiator has an IP address. In addition, for discovery purposes, each initiator also has an iSCSI name, which is a dot-separated structure that is roughly analogous to a URL. iSCSI zoning is accomplished by two mechanisms: virtual LANs and discovery domains, which are similar to FC WWN zones.
To enable an iSCSI host to access an FC target, a mapping between an initiator TCP/IP address/port and a WWN must occur within the switch. While these mappings can be dynamic or static, in most cases static mapping is used to present a persistent view of a device to a host. On the FC side of the gateway, traditional zoning and LUN masking can be configured using the mapped address. On the IP side, VLANs and discovery domains are created. Discovery from the host perspective is transparent, but ensuring that appropriate mappings and access controls are in place requires careful management.
Security and access control in an IP SAN potentially represent a greater concern than in traditional FC SAN environments. This is largely because LANs tend to be more open and widely accessible than SANs. The good news is that iSCSI was designed to take advantage of existing network security capabilities. Standard protocols such as CHAP for authentication and IPsec for encryption can be employed to make a SAN secure. This functionality can actually be implemented transparently to iSCSI. It's anticipated that in many environments, iSCSI hosts will require access to storage in existing FC SANs. This will require a combination of IP and FC access control (see "Making the IP to FC connection").
Among the fundamental lessons learned from the design of FC SANs is the importance of redundancy. In a direct-attached storage (DAS) environment, loss of connectivity only impacts a single server; in a storage network, the impact can be widespread. Therefore, avoiding single points of failure and understanding the impact from a storage perspective of the loss of key components are critical design considerations.
Another lesson learned from FC SAN deployment is to carefully adhere to vendor support matrices.
iSCSI SANs are new, and interoperability issues are certain to arise. Components that logically should work together may not, or may only partially work. Any design should be validated to ensure that all hardware and software components are certified to interoperate.
The case for IP SANs
Unfortunately, traditional FC SANs have one substantial downside. The cost to acquire SAN technology, including HBAs and switches, the cost to implement this technology and not insignificantly, the cost to manage this infrastructure are limiting factors to widespread deployment. When smaller organizations carefully evaluate the TCO for a storage network proposal, they can't justify the expenditure. Even within larger organizations, cost has often been the limiting factor in the extensive deployment of storage networks.
IP SANs, which are based on iSCSI technology, promise to address all three of these cost issues, making widespread storage networking a reality. iSCSI SANs can be implemented using standard Gigabit Ethernet (GigE) cards and IP switches. In most environments, this technology is already in place and well understood. Even if this equipment must be purchased, the costs--compared to FC--are substantially lower (see "Sample cost comparison").
Because most organizations already have network management capability, implementation and management costs are also considerably lower.
Furthermore, IP SANs promise additional benefits beyond the capabilities of FC. They can span far greater distances and can provide prioritized service capabilities through functions such as IP VLAN tagging and TCP/IP QoS. They also provide the potential for greater security through the use of standard network security capabilities such as IPsec.
So, do IP SANs give you more functionality at a lower cost? While that sounds attractive, don't put your FC gear up on eBay just yet. FC is a more mature technology and--at least in the short term--will have a performance advantage over iSCSI. Rather than work as a replacement, IP SANs offer the opportunity to extend the storage network beyond its current boundaries.
|Sample cost comparison:|
connecting 100 hosts via an IP SAN and an FC SAN
This was first published in December 2003