Brocade 1:1 Fiber Channel Zoning Commands via PowerShell

One of my customers asked me to help out with the zoning configuration on their Brocade fiber switches.  I'm neither a SAN nor a network engineer, but I've created a few fiber zones in my time.  The best practice that I've always heard is to create 1:1 zones.  That means that each zone has 1 initiator (an ESXi host's VMHBA) and 1 target (the storage processor on the SAN).  This is a very simple process, but it's also really arduous and really boring, especially as environments scale up with redundant VMHBAs and multiple SANs with redundant storage processors.

So, I spent a little bit of time reading about how to use the Brocade CLI, then moved forward.  I'm not quite confident enough in my scripting to actually enable any changes on the Brocade switches (after all, if you mess something up, storage could simply go away), so what I did was create a PowerCLI script that generates a bunch of Brocade CLI commands.  These commands (after you've read them over to ensure that they look good) can then be copied and pasted into an SSH session to the Brocade switch.  After the commands have been executed, you can log into the switch and add them to your current Config, then enable that Config (or clone it or whatever your standard process is).  Importantly, these commands will do the boring work of registering all of the aliases and creating all of the zones.

To use this script, simply launch it in a connected PowerCLI session.  You'll want to enter the aliases for your SAN Targets into the $targets variable, either by editing the script or by passing it the -targets parameter.  Most of my customers link vmhba0 to one fiber switch and vmhba1 to another, so this script is built to generate output for a single vmhba at a time (as determined by the $initiator parameter).

The script generates 3 types of CLI commands.  The first section runs nsshow commands, looking for the WWNs of the vmhbas discovered.  Each of these commands should return a line of data; that way you know that you're working on the switch that those adapters are actually plugged into.  If any of those don't return data, that might mean that the ESXi host is disconnected or, more likely, that the host is just plugged into the other switch.  If that's the case, you should either recable the hosts or just accept the way that it's done and specify the other adapter ;)

The second section (the aliCreate commands) create Aliases in the form of <ESXi short name>_<VMHBA#>.  Once you're sure that the HBAs are plugged into this switch, you can run these commands to register human friendly aliases so that we don't need to work directly with WWNs.

The third section (the zoneCreate commands) creates the actual zones.  One zone will be configured for each initiator for each target.  The zone names will be pretty straight forward: <initiator alias>_<target>.  By creating these zones by script, we can remove a lot of arduous work from the administrator while reducing the likelihood of a typo or other error sneaking into the environment.

The final command simply saves the configuration (cfgSave).  It does not add these zones to any existing configuration or enable anything; you'll have to do that by hand.  That's your chance to look over everything and ensure that it's all correct, as zoning errors can be really painful.


Popular posts from this blog

Deleting Orphaned (AKA Zombie) VMDK Files

Clone a Standard vSwitch from one ESXi Host to Another

vCenter Server Appliance Crash due to Full /Storage/SEAT Partition