Fibre Channel.

SAN Interoperability

The rate of adoption of any new technology is governed by a number of factors. The new technology has to have demonstrable value over any predecessor; it must fulfill needs that otherwise cannot be met; it must not create more problems than it solves; and, since the advent of open systems mentality in the market, it must be available from multiple vendors. A multi-vendor market implies cooperative competition or collaboration on common standards while competing to implement those standards in viable products. As the contradictory forces of cooperation and competition grind against each other in the market, interoperability issues periodically erupt. Having initially agreed on common standards, vendors will inevitably have conflicting interpretations of how they are to be engineered with the consequent collision between proprietary and open implementations.

While Fibre Channel SANs are gradually replacing legacy SCSI connections between servers and storage, interoperability issues increasingly govern the rate of adoption. Early-adopter customers may be willing to endure a certain amount of pain to implement a new solution, but the majority of customers do not have the resources or patience to undergo interoperability testing onsite. To complicate matters, interoperability in storage networks has several components in addition to multi-vendor operation. Compatibility between different topologies, e.g. arbitrated loop and fabrics; between different operating systems and SAN storage resources; and between different higher level applications within a SAN environment are all technical issues that must be resolved before customers can deploy storage networks on a large scale.

Since most customers have rejected monolithic, single-vendor solutions, vendors of SAN hardware and software have a common interest in promoting compatibility between their products. Organizationally, collaborative bodies like the Storage Networking Industry Association (SNIA) and participation in ANSI standards committees express this. At the same time, underlying competitive pressures sometimes lends a political tone to the proceedings of these bodies. A vendor with a strong market position will naturally attempt to steer the rest of the industry towards its specific implementation, either as an approved standard or, failing that, as a de facto standard. Resolving interoperability issues is usually not, therefore, a completely objective, altruistic process that culminates in the best technical solution to a problem.

Plug And Play?

The precedent for how SAN products should work together has been established by customer expectations of interoperability in local and wide area networking. These expectations have not been helped by the market hype over "plug and play," a fabrication of naive marketers who do not understand complex technologies. Even the best engineering cannot accommodate the variety of configurations that are spontaneously generated by users of routers, switches, telecommunications, upper level applications, and operating systems. So while clearly defined standards such as PCI or frame relay have been around for some time, it is not unusual for a customer to spend hours or days attempting to get an initial installation of an option card or router to actually work in their specific environment. This is despite the "plug and play" label that accompanies some products and the marketing descriptions that highlight ease of installation. Regardless of this practical experience, however, there is a pervasive urban myth that inte roperability in local and wide area networking has in fact been resolved and that customers can freely deploy gateways, routers, switches, and interface cards with minimal exposure. In practice, installations that go smoothly are most often pre-staged off-site by the equipment provider, where the bugs are worked out far from view of the customer.

Certified Solutions

Pre-staging a network configuration is, whether or not an official label is applied, a form of certification. The supplying vendors, usually under direction of a large OEM or solutions provider, test a specific configuration, fix any problems via firmware or software patches, and agree to support it. This process is a very specific form of interoperability. Different vendors' products are proven to work efficiently together, but only with the narrow confines of a custom configuration. What happens when a third party device is later added to the configuration? Even if the new device adheres to common standards, there is no assurance of interoperability. On the contrary, the original configuration may have been certified to work only by fudging standards to accommodate weak engineering by one of the original vendors. That would make the new, compliant device potentially incompatible.

The push for interoperability based on accepted standards has encouraged vendors to proactively certify their solutions with a variety of partners. Storage vendors, for example, are cooperating with manufacturers of host bus adapters to insure compatibility between device drivers and adherence to common Fibre Channel protocols. Tape vendors are working with both server and interconnect (hub and switch) vendors to validate connectivity and operation. Storage software vendors are cooperating with hardware vendors to provide workable configurations that meet customer requirements. The standards-compliant aspect of this partnering activity now plays a dominant role, since no individual vendor wants to be isolated in a proprietary implementation. As the various noncompeting hardware and software vendors partner to create viable solutions, the general level of standards compliance and interoperability throughout the industry is raised.

Arbitrated loop, for example, is now as stable as other forms of data transport, thanks largely to cooperative efforts between storage, host bus adapter, router, and hub vendors over the last two years and the introduction of smart features within loop hubs. This does not mean that all loop products will work flawlessly out of the box, just as not all SCSI adapters or Ethernet products will always perform as advertised. The step from a risk-laden, unmanaged, and emergent technology to a more stable, manageable, and customer-ready technology has been taken. However, and as long as the customer is not so naive as to believe in plug and play, they can generally assume that managed loop products can be deployed with the usual allowance for the unexpected.

Minimizing the unexpected is the task of the solutions provider and cooperating vendors. OEMs such as Compaq, IBM, and NCR, for example, sell configurations that include servers, host bus adapters, transceivers, hubs, switches, storage arrays, and software. Since the ultimate end user may at some point attach a third party product to these SANs, the OEM must insure that the components they supply are both interoperable with each other and standards compliant.

Interoperability Testing

Since a Fibre Channel vendor cannot simply shove its way uninvited into an OEM's lab to test interoperability and few vendors can afford to amass all the servers, host bus adapters, hubs, switches, storage, and software necessary to validate interoperability with all other SAN products, the Fibre Channel industry as a whole requires a forum where all vendors can test their own equipment against their peers. This forum has been provided by the University of New Hampshire InterOperability Lab's Fibre Channel Consortium and by Interphase Corporation's sponsorship of periodic PlugFests at its facilities in Dallas, Texas.

Compared to other technologies such as FDDI and ATM, Fibre Channel has had a significant advantage in terms of venues for putting standards compliance and interoperability to the test. Conducted with test suites developed by UNH and staged in Interphase lab facilities, the PlugFests allow vendors to assemble under the safeguards of a mutual nondisclosure agreement to work out interoperability issues.

PlugFests are largely responsible for the stabilization of arbitrated loop, which in the end has accelerated adoption of SANs by the market. PlugFest planning is now part of the Fibre Channel Industry Association's (FCIA) working group on interoperability and has extended testing to include storage applications and fabric environments. Chaired by Ed von Adelung of Interphase, the PlugFest activity affirms the Fibre Channel community's recognition that the fate of all vendors is tied to proven interoperability of SAN products.

In addition to University of New Hampshire and the Interphase PlugFests, independent facilities such as Medusa Labs conduct interoperability and performance tests under contract to Fibre Channel vendors and large corporate accounts that are implementing SANs.

Interoperability Today

The large population of arbitrated loop devices in the market has been a proving ground for basic loop operation, compatibility between host bus adapters and storage arrays, and interoperability with loop hubs in stand-alone and cascaded configurations (Fig). The applications supported by these fairly simple SANs include storage consolidation, tape backup, and two-node server clusters. These configurations have existed, for the most part, as departmental storage networks and have generated interoperability issues as new devices have been added to grow the SAN for more complex applications. Private arbitrated loop, however, has matured as a stable transport, and few vendors now commit the elementary engineering errors that were more common several years ago.

Fabric switches have had a more insular existence. The largest installed base of fabric switches (which is still very small compared to the market opportunity) resides in proprietary configurations that have not been exposed to third party products or applications. As fabrics are introduced into more open systems, they face the gauntlet of interoperability issues though which loop products have already run. Fabric switches must validate more complex protocols from a variety of host bus adapters and storage controllers, and verify that upper layer applications function appropriately.

Switch-to-switch interoperability is a major issue, since customers need the flexibility to deploy different switch products for specific applications. A director-level backbone switch, for example, should support departmental switches from multiple vendors, and departmental switches, in turn, should support loop hubs for fan-out to servers and arrays based on shared segments. E_Port, or expansion port, implementations must be consistent among switch vendors, as well as the exchange of Simple Name Server information and routing tables. Driven by customer requirements, switch vendors are cooperating on basic switch interoperability through the Open Systems Fabric Initiative (OSFI). This project is based on a phased approach to interoperability that will eventually allow customers to deploy switches from different vendors in a vanety of cascaded and meshed configurations.

Zoning, or the ability to create separate SAN segments on one or more switches, presents another interoperability challenge. Although different vendors initially introduced this feature as a proprietary value add to their products, customers have found it so useful they are requesting zoning capability in multi-vendor environments. This, in turn, will drive zoning into the standardization process so that common implementations can be developed.

In addition to switch-specific functions, attachment of arbitrated loop devices (e.g., JBODs) and loop hubs to fabrics adds complexity to interoperability testing. Previously, vendors of loop-only devices did not have to accommodate the more sophisticated services that fabrics require. HBA vendors, for example, supplied device drivers that, through repeated interoperability testing, adequately supported loop protocols, handled loop initializations with other vendors' equipment, and communicated at the SCSI level with target devices. Attachment of a shared loop segment to a fabric switch requires these loop-specific features, but also additional functions such as fabric login, registration with a Simple Name Server (SNS), and SNS queries.

Application-level interoperability testing has also been formulated by the FCIA to insure that upper layer applications function properly on various SAN infrastructures. Applications may include tape backup, server-free tape backup, storage management, and server clustering software. As with hardware interoperability efforts, application testing is a means to facilitate SAN adoption by reducing the end user's exposure to problems. Tom Clark is the director of technical marketing at Vixel Corp. (Bothell, WA) and the author of Designing Storage Area Networks (Addison, Wesley Longman).

www.vixel.com