During the next few years, storage area networks will take an evolutionary leap forward—from the small, segregated storage pools we have today to routable storage networks that can consolidate storage on a companywide level.
However, it hasnt been a smooth process, nor will it be in the future. In many ways, the painful evolution eWEEK Labs is seeing in SANs resembles the excruciating development of IP networks several years ago.
Although storage networking vendors can learn some lessons from the experiences of IP networking vendors, SAN technologies are very different from IP networking technologies. In addition, there are a few unique problems in the legacy Fibre Channel SAN products that must be addressed.
To understand the problems related to SAN routing, one needs to look at how SAN technologies from the recent past were implemented and why limitations in those older products are making for a painful evolution to routing.
SAN networking heavyweights Cisco Systems Inc. and Brocade Communications Systems Inc. are trying to move technology forward without forcing customers into painful forklift upgrades.
Before getting into the nuts and bolts of SAN routing, however, we need to look at some of the reasons it has become a necessity.
Even in well-run companies with generous technology budgets, a topology diagram for storage resources will show pools of storage scattered throughout the company with few, if any, links among the islands.
Early SAN purchases were made to suit the needs of a department or a new application. Therefore, most companies have several smaller SANs (for example, the PeopleSoft SAN, the Exchange SAN and the accounting SAN) functioning independently, instead of a single companywide SAN with centralized management and resource sharing.
In addition to being a management nightmare, this configuration scheme makes it impossible to move storage resources among SANs. For example, if a PeopleSoft SAN needs more storage, an IT manager would be forced to purchase a new storage system, even if idle storage were sitting in another SAN island.
A logical solution to this scenario would seem to be simply adding an ISL (Inter-Switch Link) to connect SAN islands. However, merging SAN islands is harmful to the overall performance of the SAN.
It can also be dangerous—in Fibre Channel SANs, the addresses used by server host bus adapters and storage units are assigned by the Fibre Channel switch when the HBAs and adapters first log on to the switch. Each Fibre Channel switch has a domain identity (there are 239 possible values) that it uses to help create unique addresses for the devices attached to it. If two switches are connected and both have the same domain identity, a disruptive fabric reconfiguration process is started to reapply addresses to all the devices logged in to the fabric to ensure the new merged fabric doesnt have duplicate addresses.
This process essentially brings down everything attached to the fabric, creating application failures and unplanned downtime.
The chattiness of the Fibre Channel protocol is another, more practical reason to avoid doing large-scale fabric merges. Linking large numbers of Fibre Channel islands would make the merged fabric susceptible to broadcast storms.
Unlike IP networks, where packet loss and latency are expected, SANs have little tolerance for these things and can become inefficient or break down when bandwidth becomes constrained.
Next page: Solutions for SAN routing.
Page Two
The purpose of san routers is not only to route traffic from one SAN island to another but also to keep SAN islands from flooding each other with communication traffic.
In Brocades SilkWorm Multiprotocol Router solution, routers are inserted between SAN islands and act as virtual switches. (Brocade calls these phantom switches.) Each router can talk with the switches in each SAN island and can get their configuration information. The router uses this information to populate its routing tables. When a device on one SAN island gets permission to talk to a device on another SAN island, the router uses NAT (Network Address Translation) to translate the data as it crosses to the other SAN island.
Brocades SAN routing solution can tolerate duplicate domain identities, eliminating the danger of disruptive fabric reconfiguration events.
Cisco entered the SAN market relatively late, giving it the second-mover advantage. Using technology and ideas from IP networking, Cisco created its VSAN (Virtual SAN) routing technology, called Inter-VSAN, to segregate traffic and make large SANs more efficient.
Unlike other switches on the market, Ciscos Fibre Channel SAN switches have ASICs (application-specific integrated circuits) that sit in the data path and analyze and modify frames at wire speeds. Using these ASICs, the Cisco switches are able to perform tagging at wire speeds on the storage traffic to route frames to the correct SAN islands.
Ciscos VSAN technology adds information to the Fibre Channel frame header to identify the VSANs to which a particular frame belongs. The tagging (where information is added to the Fibre Channel header) done by the Cisco switches is analogous to the tagging process we see in IP VLANs (virtual LANs) today.
The Cisco switches built-in intelligence enables them to detect non-Cisco Fibre Channel switches. When a packet has to be sent to a non-Cisco switch, the ASICs automatically remove the tagged information.
Ciscos VSAN technology was recently chosen by Technical Committee T11 of the International Committee for Information Technology Standards to be the ANSI-approved industry standard for implementing Virtual Fabrics.
However, even with the new standard, we dont expect to see many non-Cisco switches using this technology in the near future. Beyond the challenge of having to develop the technology to implement Virtual Fabrics, the other switch vendors need to contend with the fact that they already have large customer bases that would be less than thrilled with the idea of disruptive mass upgrades.
While VSANs in their current implementation are very good at segregating traffic and improving the efficiency and manageability of large SANs, they cannot handle duplicate domain identities.
In February, Cisco will release a new version of its Inter-VSAN routing technology that will eliminate the need for unique domain identities for each switch.
According to Cisco officials, the Inter-VSAN routing system will let IT managers choose between NAT and non-NAT routing on their SANs.
As SANs continue to grow in size and complexity, SAN routers will become an absolute necessity for all enterprise-class IT environments.
Senior Analyst Henry Baltazar can be reached at henry_baltazar@ziffdavis.com.