IP Puts SANs In Your Comfort Zone

No matter what size of IT shop your organization maintains, chances are - no, check that - without a doubt, it relies heavily on IP (Internet Protocol) for carrying much of its LAN/WAN (wide area network) data traffic. To borrow a term commonly used to describe the widespread use of the protocol, IP is ubiquitous. (For those about to reach for the Webster's, that means it's everywhere.) In large shops and small, practically anyone with a reasonable claim to having IT skills knows how to design, build, and maintain Ethernet networks that use IP as the primary transport mechanism.

Those shops and their IT staffers, particularly at smaller organizations, should now consider how a comfort level with IP can help them address a more challenging task - providing users with shared access to networked storage. It can even help them build dedicated storage networks or subnetworks. Heretofore, the only viable option for building and/or connecting to a SAN (storage area network) has been Fibre Channel. But, as Tom Major, VP of marketing for IP storage vendor LeftHand Networks Inc. (Boulder, CO), asserts, that option has been too expensive and too complex for many companies, especially those in the SME (small to medium enterprise) space. "The upfront costs and the unique networking expertise required for running Fibre Channel SANs can still be imposing barriers," Major says. "IP-based storage is meant to address those issues."

But, to make use of IP as a replacement for or supplement to Fibre Channel for storage networking, organizations must understand the differences among the various IP-based storage protocols - namely iSCSI (Internet SCSI [small computer system interface]), FCIP (Fibre Channel over IP), and iFCP (Internet Fibre Channel Protocol). The differences in what they do and how they're used illustrate various applications for IP storage.

iSCSI Carries The Local SAN Load
While NAS (network attached storage) devices have offered a less costly alternative to Fibre Channel SANs for creating shared, networked storage, they have traditionally been limited to handling file-level data. With few exceptions, and those coming only recently, NAS devices haven't been designed for block-level storage and retrieval. Of course, SANs have. So, for access to SAN-based storage pools in a LAN environment, iSCSI is emerging as the enabler of choice.

The term iSCSI refers to a process in which traditional SCSI commands, which are not natively formatted in IP, are wrapped in IP packets and transported across Ethernet networks. With the ratification of the iSCSI standard earlier this year and with Microsoft, IBM, and other vendors subsequently announcing plans to release iSCSI drivers, adoption rates should begin to take off. The only factor still slowing adoption is the relatively limited number of vendors offering native iSCSI target devices (e.g. tape libraries and storage arrays equipped with iSCSI interfaces). But, vendors are moving quickly, and that hurdle should soon decrease in significance.

According to Bill Erdman, director of marketing for networking vendor Cisco Systems, Inc.'s (San Jose, CA) Storage Technology Group, the installation of an iSCSI driver in a server gives data from that server immediate connection to the existing IP infrastructure. "The Ethernet interface pushes the storage I/O [input/output] streams inside the server," he explains. "That allows the storage traffic to get on an IP network starting right at the server." And, given the stated ubiquity of IP/Ethernet networks, the basic infrastructure is already there to move storage traffic not only across an IP network but also onto an IP storage network. Says Overland Storage (San Diego) CTO John Matze, "To build out an iSCSI SAN, you basically go out and buy some Gigabit Ethernet switches, create a subnet or VLAN [virtual LAN], and use IP to turn the environment into a SAN. The average IT person can easily put one together."

While it might seem more efficient and convenient to build a pure iSCSI SAN environment (i.e. one in which no Fibre Channel components are in place), the reality is that, at least for now, most iSCSI adopters will be mixing it with Fibre Channel. That's because early iSCSI SAN builders will likely have begun their SAN investments with Fibre Channel-enabled products. Erdman describes a representative scenario. "Let's say you have an existing Fibre Channel network with shared storage arrays, and you want to give your Exchange servers access to those arrays. One approach would be to put new Fibre Channel interfaces into the servers," he says. "Another is to translate IP-encapsulated SCSI packets once they reach the Fibre Channel frame and then push them to the storage units. Using IP keeps you from having to build out the Fibre Channel network all the way to small departments where Exchange servers may reside."

IP Takes SAN On The Road
At this point, iSCSI isn't yet being heavily promoted as a transport mechanism for moving data between geographically distant data centers. Currently, that job is being handled by two additional IP-based storage protocols, FCIP and iFCP. FCIP is often referred to as Fibre Channel "tunneling," meaning that it encapsulates Fibre Channel traffic for transmission over IP to a secondary, remote Fibre Channel SAN. "Most people are using FCIP to transfer data remotely between two Fibre Channel-based locations," Matze explains. "FCIP basically converts Fibre Channel to an IP-based protocol and sends it across the wire. At the other end, they put it back together as Fibre Channel traffic. It works fine, though it doesn't seem to be as fast as some people would like." Similarly using IP networks to carry SAN traffic, iFCP is not limited to Fibre Channel-to-Fibre Channel connections, and can therefore send Fibre Channel traffic to IP-based SANs and to SANs of mixed Fibre Channel and IP design.

According to Tom Clark, director of technical marketing for IP SAN vendor Nishan Systems (San Jose, CA), IP's ability to break down barriers to distance is its strongest selling point for SAN use. "The ability to bring IP and storage into an integrated environment has brought on new applications that weren't feasible in Fibre Channel-only SAN environments," he says. "It's difficult to take Fibre Channel beyond metropolitan distances. If you want to go beyond 50 miles, you have to leverage IP-based wide area networking. That allows you to do data replication, tape vaulting, or content pushing across distances you previously couldn't have conceived of spanning."

Spend Less For More SAN
If the capabilities of IP SANs, such as those outlined above by Clark and the other industry insiders, aren't compelling enough to lure more adopters, Major insists that price will be. A hard look at the numbers, he says, makes the appeal of IP storage impossible to ignore. "In a Fibre Channel SAN, you're going to need Fibre Channel HBAs [host bus adapters], which cost anywhere from $1,000 to $3,000 per server. In an IP SAN, you can use a standard NIC [network interface card] or an advanced network interface card, which costs roughly $300," he says. "In a Fibre Channel SAN, you'll also need Fibre Channel switches at roughly $1,000 per port," he says. "In an IP SAN, a standard Ethernet switch doesn't have to cost you more than $50 or $150 per port. You can build a SAN on your standard Ethernet infrastructure, use your existing IT staff to manage it, and still get advanced storage services, such as replication, failover, high availability, snapshots, centralized management, and so on."