Storage Reality Check - Open Systems Standardization

Datamation content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.

The evolution of open systems SAN technology is constantly shaped by diverse market contradictions. Customers, for example, often make product selections based on unique and proprietary features while at the same time demanding that their vendors comply with open standards. Likewise, vendors may collaborate to develop and promote open specifications such as the Storage Management Initiative (SMI), but at the same time pursue vendor-specific technologies designed to ensure vendor lock-in.

Customer willingness to overlook standards violations, it turns out, is often proportional to the investment a customer has made with a particular vendor.And, given the chance, vendors will almost always seek a competitive advantage by bending standards rules.

As a technology, open systems storage has yet to match the standards compliance and interoperability expectations of open systems networking, and in fact may never match it. In the IP and Ethernet world, standards compliance and interoperability are simply assumed. No one would think of introducing a new Ethernet switch or network interface card (NIC) that did not fully comply with all the relevant IEEE, IETF, or ANSI standards. And no one (with, perhaps, the exception of a Cisco) would presume to impose a proprietary protocol on the market and expect everyone else to simply follow along.

In the storage networking market, however, such impositions are commonplace, to the point that a proprietary method may quickly move from being a vendor-imposed de facto standard to being the draft version of an actual standard. Brocade’s Fabric Shortest Path First (FSPF) routing protocol, for example, was reverse-engineered by Ancor and presented back to the technical community as a standards proposal some years ago.

Even today, we continue to have both vendor-specific and “open systems” functionality living side by side. When building SAN fabrics, proprietary expansion (E_Port) modes tend to have richer zoning functionality, compared to the open systems mode. Customers are not so committed to open systems that they will sacrifice vendor value-added features, and yet often complain when they run into switch interoperability issues because of them.

Page 2: Wanting It Both Ways

Wanting It Both Ways

Customers want it both ways, which is their fundamental right as consumers and controllers of purse strings. The answer from the open systems industry would seem to be: raise the bar on standards functionality, so that rich features can be provided across the board while maintaining openness and interoperability.

Fibre Channel, which is fairly well entrenched in mainstream enterprise networks, will probably witness continued antagonism between proprietary and open systems currents, especially as the technology moves to more network intelligence and faster speeds. The jury is still out on IP-based storage technology, though, whose adoption is just beginning to gain momentum. The standards development for iSCSI has been accompanied at every step with practical interoperability and standards compliance testing. At the same time, Microsoft is promoting its own compatibility matrix for iSCSI devices, which is fine for the Windows world but does little for Linux or Unix users.

Unlike iSCSI, neither FCIP nor iFCP were accompanied by practical standards compliance or interoperability testing. Despite the fact that multiple vendors are concretely implementing FCIP in product, there has been no attempt to promote or ensure multi-vendor compatibility. Why? Because, unlike iSCSI products, customers are not expecting or demanding interoperability for SAN extension, and vendors will be the last ones to put that idea in customers’ heads. The assumption on both sides is that the customers will buy a pair of SAN extension gateways from a single vendor — McDATA-to-McDATA, Cisco-to-Cisco, Brocade-to-Brocade, CNT-to-CNT, and so on.

So although those vendors sometimes accuse iFCP of being single-vendor, all FCIP solutions are in fact inherently single vendor. iSCSI, FCIP, and iFCP are all open systems standards, but today that openness is at the protocol definition level, and does not necessarily trickle down to practical interoperability for real products and real customers.

Storage Virtualization in the Same Boat

The jury is also out on storage virtualization, which may in the end not readily lend itself to open systems standardization. We have seen a common vocabulary develop for virtualization methods and processes — e.g., in-band, symmetrical, out-of-band, asymmetrical, pooling, snap-shots, etc. — but each vendor may implement these methods very differently.

Like other complex applications, storage virtualization sits on top of an open systems infrastructure but is unlikely to accommodate interoperability between virtualization programs (e.g., DataCore, VERITAS, and FalconStor in a single complex environment). Will this bother customers? Probably not, except for the unfortunate IT manager who inherits an eclectic array of heterogeneous storage and virtualization solutions as a by-product of a company merger or acquisition.

Page 3: Open Only to Themselves

Open Only to Themselves

One of the main reasons it has been difficult to achieve meaningful openness in the SAN market is simply due to the complexity of the technology. Ethernet and IP networks assume intelligence on the part of end systems (nodes), with the network itself largely restricted to data transport. SANs assume intelligence in the network (the fabric) and little intelligence on the end systems (particularly storage targets).Designing a new fabric switch or host bus adapter that is both standards-compliant and interoperable is therefore far more challenging than in the data communications world.

In addition, although storage targets may have lower IQs than the fabric they’re attached to, they are a much higher expense and as a result tend to be a much higher priority for customers. For a switch or adapter to achieve success in the SAN market, for example, it must have stamps of approval from the storage systems providers. This has the practical benefit of openness, in that different products are qualified and supported to work together. But this is not open systems by IP and Ethernet expectations.

For their part, storage systems vendors only have to be open to themselves. Although some customers would love to connect their Symmetrix and Sharks directly together for, say, data replication, there has been significant vendor resistance. With its CLARiiON-based SAN Copy data copy application, EMC has made a significant step towards accommodating heterogeneous storage without the use of virtualization appliances. These sorts of solutions are predicated on previously established standards for initiator and target behavior, and as long as customers have the flexibility of using a diversity of products to accomplish common tasks, the solutions have the look and feel, if not the reality, of openness.

Tom Clark

Director, SAN Technology, McDATA Corporation

Author: Designing Storage Area Networks Second Edition (2003) (available at Amazon.com), IP SANs (2002) (also available at Amazon.com).

»

See All Articles by Columnist Tom Clark