13.2 Interoperability

One of the main objectives of standardization is to promote interoperability between the products of different vendors. Standards compliance and interoperability, however, are two distinct states. No standard is so rigorously defined that it excludes variations in interpretation by engineers. Two similar products may therefore be designed to the same standard and yet fail basic compatibility testing. This was evident in the early standards development of Fibre Channel technology, which in turn encouraged the development of vendor plugfests and standards conformance test suites by the University of New Hampshire (UNH). This work has been extended by the Fibre Channel Industry Association (FCIA) into its SANmark program for pass/fail compliance testing for various levels of Fibre Channel protocols. Similarly, compliance with early drafts of the iSCSI protocol proposal has been periodically validated by UNH-sponsored plugfests, and the SNIA has invested substantial funds in developing a standards compliance test harness that can be adapted to multiple management protocols.

In addition, the SNIA Interoperability Committee hosts multimillion-dollar interoperability demonstrations at the SNIA Technology Center and Storage Networking World conferences, which provide showcase examples for customers and gives vendors the opportunity to test their products with a more diverse range of hardware and software components. Aligning standards development with compliance testing accelerates product time to market and, hopefully, removes most of the burden of discovering interoperability issues from the backs of customers.

Interoperability in SANs is still problematic, however, for a number of reasons. With hundreds of vendors in the same market space, it is simply not possible to test every permutation of product interaction. An interoperability matrix must include not only lists of vendor products but also specific versions of microcode or software that have been tested, along with combinations of multiple products in the same configuration. Even large vendors with sophisticated interoperability labs have difficulty staying current with new releases of products and microcode from their peers, and the qualification process for a specific product may be in a long queue behind other newly released or untested products.

In addition, because SAN components include everything from transceivers to upper-layer storage software applications, interoperability issues may derive from higher levels not covered by existing standards or interoperability test processes. An unexpected mismatch between the upper-layer application, the operating system, middleware, device drivers, or virtualization engines may result in failure, even though the rest of the SAN system is thoroughly interoperable. This highlights the value of testing total solutions before customer installation to ensure success (and avoid embarrassment).

Another source of SAN interoperability issues is the formation of vendor affinity groups, or alliances that promote interoperability between specific vendors but lock out others. A subtle, agreed-upon change in the use of a bit in a protocol stream may or may not violate the relevant standard but may result in interoperability problems for everyone except the participants. Sometimes these collective changes are meant only to enhance functionality between a given set of products and thus add value to the solution. In other instances, they amount to a conspiracy to produce a working solution that is at best difficult for others to attach to. The excluded vendors are thus forced to reverse-engineer the modification and are always a step behind.

The more sinister roots of interoperability problems are found in the lower depths of vendor competition and are expressed in the desire to trade industry compliance for market share. A dominant vendor may, for example, refuse to participate in interoperability activity with competitors and simply declare itself to be the de facto standard. This strategy may even work for a while, until customer complaints and bad press eventually begin to impact sales. Although there are no laws in the storage industry to punish the evil doers, customer commitment to open systems interoperability exacts its own justice in the end.

As long as new storage products and technologies continue to surface in the market, it will always be a challenge to deal with interoperability issues proactively. The catch phrase "plug and play" is not really applicable to SANs, at least not for some time to come. Even vendor-tested solutions generate the occasional surprise that only seems to occur on the customer site. Customers, however, should always keep the vendors' margin-swollen feet to the flame to ensure that the vendor community, and not the customer base, bears responsibility for identifying and resolving interoperability problems.



Designing Storage Area Networks(c) A Practical Reference for Implementing Fibre Channel and IP SANs
Designing Storage Area Networks: A Practical Reference for Implementing Fibre Channel and IP SANs (2nd Edition)
ISBN: 0321136500
EAN: 2147483647
Year: 2003
Pages: 171
Authors: Tom Clark

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net