Enterprise Storage: What's in Store for SAN
An evolving protocol from IBM and Cisco Systems for moving Small Computer Systems Interface (SCSI) commands and data across Gigabit Ethernet – known alternatively as SCSI-over-IP or IP SCSI – was the talk of the trade show floor at the Spring Networld+Interop (N+I). Meanwhile, Adaptec Corporation used the conference to demonstrate a competing technology for networking storage over Gigabit Ethernet that consisted of a SCSI Encapsulation Protocol (SEC) and a lightweight, storage-oriented replacement for TCP: the Storage Transport Protocol (STP).
The response from attendees to this unexpected turn of events was decidedly mixed. Many traditional Ethernet router tenders and switch mavens, who as a general rule prefer to keep their networks separate from their systems, asked the question: "What does storage have to do with networks?"
Some consoled themselves with speculation that it was simply a matter of economics: N+I planners must have run out of network vendors to rent booth space, or perhaps they came up short in their efforts to find knowledgeable speakers to cover "real" networking topics, like Voice-Over-IP.
By contrast, many non-network professionals attending the show, including numerous system administrators and IT operations minions, were delighted by the turn of events. They cheerfully embraced the change in the show’s traditional focus on such rarified matters as non-blocking switch architectures, cut-through routing, IP security protocols and other technologies directly related to, well, networks.
Bottom line: Storage, while decidedly unhip to the network gurus, had arrived as the next big thing in networking.
The concept of a storage area network (SAN) first appeared in the technology trade press in 1996. The SAN vision had numerous proponents. Sun Microsystems’ Project Store X, Compaq’s Enterprise Network Storage Architecture (ENSA), and EMC Corporation’s Enterprise Storage Network (ESN) architecture each described alternative, and somewhat self-serving, approaches to realizing a SAN.
Early storage area networks (SANs), consisting of servers and storage devices interconnected by Fibre Channel loops and switched fabrics, were slow to take hold in the market. Interoperability issues, a general unfamiliarity with Fibre Channel itself, high deployment expense, and several other factors proved to be hurdles that kept the SAN "in the can" – that is, inside a storage array cabinet – for the first couple of years. By 1999, many (but not all) problems with Fibre Channel SANs had been surmounted and it seemed to be on its way to becoming a business-class storage architecture.
However, just as Fibre Channel SAN vendors began to see light at the end of the tunnel, up popped Cisco Systems, who, together with IBM, began talking about SANs based on IP and Gigabit Ethernet. While a standards proposal – a Request for Comment (RFC) in the parlance of the Internet Engineering Task Force (IETF) – has only recently been submitted by the two companies, the handwriting is on the wall. SCSI-Over-IP, or "iSCSI" as it has come to be known, is already being incorporated into the SAN products of several storage network vendors and has been embraced in concept by numerous others.
Call A Plumber
The debate over storage network transports, while essentially a low-level SAN "plumbing" issue, represents significant revenues to SAN product vendors. Not surprisingly, FC product vendors frequently defend Fibre Channel (FC) as the only suitable and mature technology for storage networking. To make their case, FC advocates point to several "facts," including:
• FC is the only SAN transport designed with the high bandwidth and low latency requirements of storage in mind. It is streamlined for storage and devoid of all of those annoying "IP stack" functions that detract from that protocol suite’s appropriateness to storage applications.
• FC removes the distance restrictions and scalability constraints of SCSI and enables greater flexibility in storage network design.
• FC switching provides a means to grow SAN fabrics (a fabric is essentially a set of point to point connections), to group SAN segments into "zones" (zoning is regarded as a precursor to enabling security and usability), and to shape the traffic traversing the SAN.
While all of the above may be true, iSCSI advocates claim that the evolving IP-based SAN offers several offsetting advantages over FC. These include:
• TCP/IP is ubiquitous and well known. FC is still a mysterious technology lacking a broad base of knowledgeable support personnel.
• TCP/IP offers well-established interoperability between the products of competing vendors. Growing a SAN from a workgroup-scale implementation to an enterprise-scale implementation is impeded by the lack of interoperability among vendors of SAN switches. Brocade Communications Systems, an FC SAN switch vendor, uses zoning and routing algorithms that differ significantly from those of, say, Vixel Corporation, despite the fact that both switches comply with the letter of the Fibre Channel standards.
• TCP/IP-based SANs offer one more thing that FC-based SANs do not: in-band management. Currently, FC SANs must rely on a second – or out-of-band – network (typically TCP/IP based) interconnecting all SAN devices in order to collect device status information and to provide other storage management functions. In-band management functions were omitted from the original FC specification in order to reserve the Gigabit-per-second throughput of the transport exclusively for storage commands and data transfers. With an iSCSI SAN, you get both management and I/O operations in the same pipe.
Experts, like Simon Fok, President and CEO of NetConvergence (Santa Clara, Calif.) view the issues raised by the FC vendors as specious, at best. Fok observes that the criticisms of TCP/IP raised by the Fibre Channel Industry Association are out of date and don’t fly in the real world. NetConvergence, which has already created a workable IP-based SAN solution that can bridge FC SANs with Gigabit Ethernet and TCP/IP (as well as several other network protocols), is one of a handful of smaller firms that have approached SANs from an IP perspective in advance of the iSCSI spec. With their storage-optimized versions of TCP (or Reliable UDP), NetConvergence and others have obviated the issues of latency and CPU resource consumption that, according to the FC crowd, invalidated the use of TCP/IP as a SAN interconnect. Implementing TCP/IP stack processing on silicon, a common feature in many next generation Network Interface Cards and Host Bus Adapters, promises to put performance issues to bed once and for all.
Evolving the SAN
So, despite five years of hyperbole and zeal on the part of vendor marketeers, SANs have yet to arrive. SAN-like products offered by numerous vendors may be better classified as rudimentary storage networks. Most are well suited to workgroups or departmental settings, mainly in environments where homogeneous servers or storage subsystems are used. There, they may provide certain valuable supports for data storage requirements, but they are not, by definition, SANs.
The real SAN features inherent scalability, ubiquitous and heterogeneous connectivity, manageability, security and application awareness that distinguishes this architecture from other types of storage networks. For now, vendors have yet to work out the fundamental issues of transport – the plumbing of the SAN house.
The good news is that IETF’s IPS working group is approaching IP-SAN plumbing issues intelligently and tactically. Each aspect of the RFC is being hammered out in discussions and debates between proponents and a "loyal opposition." Only occasionally has a "spoiler" comment, from someone who is hostile to the intent and direction of the iSCSI initiative, been fielded in the forum. These few comments have been quickly and decisively handled for the most part.
In general, I am optimistic that the work of IBM’s Julian Satran, and his cohorts at IBM Haifa and within the industry at large, will result in a transport infrastructure capable of supporting a SAN. However, more than a transport solution will be needed to realize the promise of the SAN.
After resolving the transport layer issue, considerable work will be required to enable IP-based storage networks so they can access IP security, management and quality of service protocols that will make the IP-SAN infrastructure robust. Following (or concurrently with) this effort, the components of a SAN operating system will need to be defined and implemented by third party vendors to give the SAN the intelligence and application awareness that is required of a so-called "storage utility."
The above adds up to considerable time and effort. Time is exactly what many companies – particularly those experiencing 100 percent per annum storage growth – do not have. In the next column, we will look at some interim measures for coping with the storage explosion that do not require an investment in primordial storage networks that may need to be upgraded via forklift tomorrow.
About the Author: Jon William Toigo is an independent consultant and author and author of The Holy Grail of Data Storage Management. He can be reached via e-mail at jtoigo@intnet.net.