Zoning and masking terms are often confused by those who just started working with SAN. But it takes 5 minutes googling to understand that the main difference is that zoning is configured on a SAN switch on a port basis (or WWN) and masking is a storage feature with LUN granularity. All modern hardware supports zoning and masking. Given that, the much more interesting question here is what’s the point of zoning if there is masking with finer granularity.
Both security features do the same thing, restrict access to particular storage targets. And it seems that there is no point in configuring both of them. But that’s not true. One, not that convincing argument, is that in case one of the features is accidentally misconfigured, you still maintain security. But the much bigger issue in no-zoning configuration are RSCNs. RSCNs are Registered State Change Notification messages which are issued by SAN Name Server service when fabric changes it’s configuration (new device has been added to the fabric, a zone has changed, a switch name or IP address has changed, etc). RSCNs can be disruptive to fabric operation. And if you don’t have zones RSCNs are flooded to everyone each time something changes in a fabric, even if it has nothing to do with majority of devices. So zoning is a SAN best practice and its configuration is highly recommended.
In fact, Brocade recommends to adopt a so called Single Initiator Zoning (SIZ) practice, when one host pWWN (initiator) is zoned to one or more storage pWWNs. It reduces RSCN issue to a minimum.
As a best reference read Brocade’s: Secure SAN Zoning – Best Practices.
Tags: fabric, initiator, Logical Unit Number, LUN, masking, port, pWWN, Registered State Change Notification, RSCN, SAN, security, Single Initiator Zoning, SIZ, storage area network, switch, target, World Wide Name, WWN, zone, zoning
Niktips's Blog 
March 29, 2013 at 3:42 am |
I believe that another reason to use both zoning and masking is when connecting non-clustered devices/servers, which need access to same LUN/Storage Device/Target; this is because Zoning can only be done on a target-initiator basis.
March 29, 2013 at 4:27 am |
Rafael, thank you for your comment. I have two questions. 1. Can you describe a use case scenario, when two non-clustered devices need an access to the same LUN. 2. It’s not quite clear why would anybody use Zoning without Masking. Usually it’s an opposite case, Masking is configured on LUN-by-LUN basis and nobody cares about Zoning.
April 3, 2013 at 5:37 pm
One possible scenario for more than one server to access the same LUN is in VMware ESXi. These do not even have to be clustered – VMs can be moved manually. All ESX servers must see all available LUNs where VMs are located so you can move VMs around.
My question is rather on the question of RSCN. Based on the possible scenarios given above, why would a group of servers that are not zoned but rather LUN masked, be affected by an RSCN but another group of servers in a zone, not be affected by an RSCN? I need further understanding of why an RSCN would not affect zoned participants vs those that are not. Where is the RSCN initiating from?
April 3, 2013 at 9:15 pm
You are right. Clustered file systems are one of the examples which I didn’t think of.
RSCN comes from a SAN NS service. For instance, if a new member is added to a zone, all members of the zone receive a message. LUN masking is configured on a storage and has no effect on propagation of FC commands through a SAN.