SANs are Ready to Take the Next Step

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.

Hewlett-Packard is integrating Brocades SAN switching capabilities into its BladeSystem architecture. Click here to read more.

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.