Role in IT decision-making process:Align Business & IT GoalsCreate IT StrategyDetermine IT NeedsManage Vendor RelationshipsEvaluate/Specify Brands or VendorsOther RoleAuthorize PurchasesNot Involved

Work Phone:

Company:

Company Size:

Industry:

Street Address

City:

Zip/postal code

State/Province:

Country:

Occasionally, we send subscribers special offers from select partners. Would you like to receive these special partner offers via e-mail?YesNo

Your registration with Eweek will include the following free email newsletter(s):News & Views

By submitting your wireless number, you agree that eWEEK, its related properties, and vendor partners providing content you view may contact you using contact center technology. Your consent is not required to view content or use site features.

By clicking on the "Register" button below, I agree that I have carefully read the Terms of Service and the Privacy Policy and I agree to be legally bound by all such terms.

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.

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.

Advertiser Disclosure:
Some of the products that appear on this site are from companies from which QuinStreet receives compensation. This compensation may impact how and where products appear on this site including, for example, the order in which they appear. QuinStreet does not include all companies or all types of products available in the marketplace.