Storage area networks (SANs) are deployed at most larger organizations, and provide centralized administration for storage devices and management functions. When multiple clients are accessing storage resources through a SAN, you need a way to limit which targets and logical units each initiator can see. Typically LUN masking is used on the storage array to limit which initiators can see which logical units, and zoning is used on the SAN switches to limit which initiators can see which targets. In the next five blog posts, I plan to provide a step-by-step guide to zoning Brocade switches.
Brocade zoning comes in two main flavors. There is hard zoning (port-based zoning), which allows you to create a zone with a collection of switch ports. The second zoning method is soft zoning (WWN-based zoning), which allows you to create a zone with one or more WWNs. There are tons of documents that describe why you would want to use each form of zoning. I typically use the following two rules to determine which zoning method I will use:
1. Will I ever need to move the host to a different switch or port? If so, I will implement soft zoning.
2. Are there any policies that require me to lock an initiator to a specific port? If so, I will use hard zoning.
I prefer soft zoning, since it provides tons of flexibility when dealing with switch upgrades, faulty SFPs, and defective hardware. But each location has different policies, so it’s best to to take that into account each time you design or implement your zone layout.
To implement zoning on a Brocade switch, the following tasks need to be performed:
Brocade provides awesome zoning documentation, which you can access though the help and zonehelp commands:
aliAdd Add a member to a zone alias aliCopy Copy a zone alias aliCreate Create a zone alias aliDelete Delete a zone alias aliRemove Remove a member from a zone alias aliRename Rename a zone alias aliShow Print zone alias information cfgAdd Add a member to a configuration cfgCopy Copy a zone configuration cfgCreate Create a zone configuration cfgDelete Delete a zone configuration cfgRemove Remove a member from a configuration cfgRename Rename a zone configuration cfgShow Print zone configuration information zoneAdd Add a member to a zone zoneCopy Copy a zone zoneCreate Create a zone zoneDelete Delete a zone zoneRemove Remove a member from a zone zoneRename Rename a zone zoneShow Print zone information cfgClear Clear all zone configurations cfgDisable Disable a zone configuration cfgEnable Enable a zone configuration cfgSave Save zone configurations in flash cfgSize Print size details of zone database cfgActvShow Print effective zone configuration cfgTransAbort Abort zone configuration transaction
Reading through (i.e., running help <command>) the help sections prior to implementing your zone layout will save you a lot of hassle, especially when you start to ask yourself questions like “Does cfgremove or cfgdelete remove an entry from a configuration?”. Well, that is all for today. Tomorrow I will discuss aliases, and how to use the ali* commands to create and manage them.