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 Communications Systems Inc.’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.
LSANs and FC-NAT make it possible to keep separate administration for each SAN and to create LSAN zones without disrupting previous configurations. Customers can connect only selected devices and hosts across fabrics, which is often the most desirable and less challenging option when it comes to SAN integration.
To create my first LSAN zone, I launched Brocade’s Fabric Manager Share Device wizard. When all SANs have the same administrator, using Fabric Manager saves a few steps, because it will automatically create LSAN zones in each network.
The wizard opened a screen with a list of devices to include in the newly named logical network. I selected my server from SAN-1 and the storage array to connect from SAN-2. After a few seconds Fabric Manager confirmed the new LSAN-1.
If this sounds extremely easy to do, it’s because it is. Preparing the environment takes significant work and caution, because incorrectly setting a router port can cause trouble to your SANs. Once the routers are properly installed, however, bringing together devices from different SANs is child’s play.
I launched an Iometer script on the new volume to create some traffic and then opened the performance statistics on the first router. The traffic was, as expected, almost equally balanced between its two IFL ports.
To simulate a fault, I unplugged one of the IFL ports; within seconds, the remaining port began working double duty and absorbing all traffic from my host. The Iometer run on my host was unaffected and kept running when I added a second LUN (logical unit number) to the same LSAN, a process akin to sharing a new device.
Connecting a device on SAN-3 to my host via a simulated FCIP connection was equally easy and involved similar steps, although the router ports leading to the Ethernet switch on that path had to be configured accordingly.
SilkWorm Wrap-up
I have mostly positive remarks for the SilkWorm Multiprotocol Router because it facilitates consolidating existing SANs regardless of the transport protocol. The price you pay is the addition of another hardware layer on top of your existing SANs and a somewhat complex update of your network that includes carefully configuring each router port.
If your business will benefit from consolidating multiple SAN segments or mingling IP and FC devices, consider the SilkWorm Multiprotocol Router. As an added bonus, it makes SAN administration less stressful. For many Brocade customers, that’s an offer they shouldn’t refuse.
Mario Apicella is a senior analyst at the InfoWorld Test Center.
