Building the uber-SAN

Many companies -- either by design or because of a merger -- end up managing multiple SANs. But merging two SANs can be a disruptive, risky process. Even when everything is compatible, SAN configuration inconsistencies may trigger a chain reaction that brings both networks to a halt.

The good news is that major switch vendors have recently developed solutions that -- although based on different architectures -- hold a similar promise of easily sharing devices across SANs while maintaining separate networks.

Brocade's SilkWorm Mutliprotocol Router does just that; it's a superswitch capable of selectively connecting devices from multiple SAN islands with minimal or no service disruption.

I am pleased with the SilkWorm Multiprotocol Router's ease-of-use and its seamless reach across foreign FC (Fibre Channel) and iSCSI networks. It adds another management layer and more cost to your storage network, but the benefits are well worth the investment -- if your fabric is labeled Brocade.

Bridging the SAN

The SilkWorm router's 2U box hosts eight optical working ports that customers can easily extend to 16 with a software license update. Each port supports FC or GbE connections, and the router can be configured to work with multiple scenarios, such as consolidating local and remote FC fabrics and integrating iSCSI devices into an FC SAN.

That flexibility is software driven: Customers can choose from a range of optional services, including Basic Routing to consolidate multiple SANs, FCIP (FC over IP) Tunneling to connect remote networks, and iSCSI Gateway to connect local IP storage.

Brocade prepared a test bed with two local storage networks, SAN-1 and SAN-2, both built around a director-class switch. A third network, SAN-3, mimicked the configuration of a smaller fabric for a remote branch.

My test configuration involved three SilkWorm routers attached to a GbE switch and to three SANs. I didn't use FC switches from other vendors because the SilkWorm router doesn't support non-Brocade devices; the company is considering extending routing capabilities to foreign switches in future versions.

I used a combination of iSCSI, FCIP, and IFLs (interfabric links) for the connections. IFLs are essentially FC connections, similar in concept to ISLs (interswitch links); typically you use two or more IFLs for each SAN for robustness and performance.

This configuration may sound complicated, but it exemplifies the SilkWorm router's capabilities: connecting any host to any storage device in an adjacent SAN, regardless of protocols and switch configurations.

Fencing the SAN

The first step was to create a connection between a host on SAN-1 and a storage array on SAN-2. Inter-SAN connections live in virtual networks that Brocade calls LSANs (Logical SANs).

Creating an LSAN is easy. Working on each SAN, you create special zones containing devices or hosts suitable for cross-SAN connections. LSAN zones are similar to regular zones in concept and are created using the same tools. The SilkWorm routers will acknowledge for routing only devices contained in the LSAN zone, limiting other devices to their original SAN boundaries.

To avoid conflicting SAN addresses, the router uses FC-NAT that, like its IP equivalent, masks addressing conflicts between adjacent networks.