Today in my vSphere class a question came up about zoning a fibre channel SAN. Best practices from most storage vendors and security specialists recommends WWN single initiator/single target zoning. What the heck does that mean? First, it means a lot of zones–they multiply like bunnies!
An initiator is your HBA in a server. It always reaches out to your array and asks for data. It may have one or two ports, or more. The target is the storage processor (host port) on your disk array. It is the target of SCSI requests and executes commands it receives. In a typical SAN your server will have at least two HBA ports, and your storage array will have four or more. Most mid-range arrays will have four ports, like the HP EVA. High-end arrays like EMC Symmetrix, HDS USP and 3PAR T series support many more host facing ports.
Let’s picture zoning this way. You server HBA has ports H1 and H2. Your storage array has ports S1, S2, S3 and S4. S1 and S2 are on one controller, and S3 and S4 are on the second controller. Ports H1, S1 and S3 are in one physical fabric and ports H2, S2 and S4 are in a second independent fabric.
For this situation we would have four zones:
H1 and S1
H1 and S3
H2 and S2
H2 and S4
Each zone has a single initiator and single target WWN. If your storage array has eight ports, then you’d end up with eight zones if all LUNs were presented through all eight ports. Why is this better than one big zone? First, there’s a Fibre Channel command called a RSCN. Registered State Change Notifications are a disruptive event which are sent to a fabric when changes happen.
Changes can be a new HBA logging in to the fabric, a device removed from the fabric, or other scenarios. RSCNs are disruptive and can interrupt in-flight I/Os. RSCNs should always be minimized and isolated. Period. In recent years switch vendors, like Brocade, have been very good at minimizing the number of devices which receive RSCNs. In the early days of Fibre Channel there was a potential to see a lot of RSCNs in a dynamic fabric, sometimes called RSCN storms.
If you have a single zone for all your storage devices, all hosts are impacted by RSCNs which can lead to fabric instability, poor performance, or other mysterious problems. Single initiator/single target zoning confines the RSCNs to only the devices that need to know about the state change.
Second, on the security front, you don’t want devices communicating with anything on the fabric that they aren’t supposed to. Does server A need to send traffic to server B? Absolutely not. Server A and B only talk to the storage array. What if server A was compromised, you don’t really want any communications path to other devices in the fabric. It could launch a DOS attack, or other nastiness. Think of zones as individual DMZs, or VLANs, where you tightly control what can talk to what.
If you have a SAN attached tape library, that requires even more zoning. If we continue my example of server A, if it needs to communicate with a tape library that has two FC ports, that will require two more zones.
Don’t get zoning confused with LUN masking/presentation. Once a server is zoned to storage array ports, you can present any number of LUNs without altering the zoning. Adding a new LUN? No problem. No zoning changes are needed since the server can already communicate to the storage array.
Yes you will need to update your LUN masking to allow hosts to access the new LUN, but that’s completely independent of any zoning. The primary exception to this that I can think of, is if your storage array has a boatload of host facing ports and you only present specific LUNs to specific storage ports. If you server isn’t zoned to all ports, then you may need to add zones if you want to present a LUN through ‘new’ ports the server can’t yet see.
Personally in most situations I’d zone all server HBA ports to all disk array ports in their respective fabrics, using the single initiator/single target model. Exceptions would be very large SANs where your storage administrator reserves specific ports on the storage array for certain kinds of hosts. Maybe some storage ports only support ESX hosts, and other are for physical Unix hosts. In this case, zone a server for all storage ports that are appropriate, say all ESX ports if it will be an ESX host. I would limit zoning a server to no more than eight storage array ports, with four being much more common. Do you really need more than eight paths to your disk array? Highly doubtful.
Our 3PAR T400 array has eight host facing ports, so each of our servers has eight zones just for the disk array LUNs. Add additional zones for our Fibre Channel physical tape libraries and our FalconStor VTL. Zones can multiply like rabbits if you have a lot of devices. Having a good naming standard for zones is key, plus a complete set of documentation.
Switches have a maximum number of zones they support, so consult your switch vendor. Generally these numbers are in the thousands, so all but the largest environments won’t run out of zoning storage space in the switches. Brocade Fabric OS 6.0 supports 11,866 single initiator/single target zones using WWNs.
Brocade has a good whitepaper on Secure SAN Zoning best practices, you can see here. Brocade calls this model of zoning “Single initiator Zoning (SIZ)”.
very good explanation abt single initiator/single target zoning. thansk