SAN zoning gains importance once your SAN includes more than a couple dozen devices. During the early days of SAN,...
there was debate about whether zoning was needed as a Fibre Channel SAN standard. Even now, zoning standards and implementation are still evolving. So, let's take a closer look.
What is SAN zoning?
A SAN makes every storage device available to all LAN or WAN servers. It also enables your enterprise to share storage devices, yet lets each device exist in isolation in its own subnetwork, communicating directly with other devices via high-speed storage media.
The premise of SAN zoning is to prevent servers from mounting all the LUNs it sees in a fabric. With zoning, you control which devices a user can access. Devices are isolated into logical groups, although a single device often appears in multiple groups. Zoning promotes efficient management, fabric stability and security. Smaller SAN environments may function with a no zoning architecture that enables all devices to interact, but organizations are discouraged from this setup. If all devices are grouped in one large zone, each one is disrupted whenever there is a change, such as devices being added or removed from the fabric.
When this happens, the SAN issues a registered state change notification. An RSCN is sent when a new device logs in or an existing device leaves the fabric. The resulting stoppage could result in loss of data in flight, destabilizing the fabric and robbing its performance and security inherencies.
Zoning could be set up according to server, storage and switch. Various mechanisms control which devices an application may see on a server and whether the application is permitted to talk with other devices. At the lowest level, a host bus adapter's (HBA) firmware or driver has a masking capability to control whether a server may interact with other devices. In addition, the OS can be configured to control which devices it tries to mount as a storage volume. Finally, extra-layered software for volume management, clustering and file system sharing helps control device access by applications.
For storage zoning, if you ignore JBOD and the earlier RAID subsystems on most disk arrays, there is a form of selective presentation. The array is configured with a list showing which servers can access which LUNs and on which ports. Access requests from unlisted devices are ignored or rejected. In terms of switch zoning, most, if not all, Fibre Channel (FC) switches support some form of zoning to control which devices on which ports can access other devices or ports.
One other category that controls access is the virtualization. Zone sets extend SAN segmentation further and mark a logical step above zoning. Multiple zones make up a zone set. Each zone is assigned to a number of member devices, such as switches, arrays or storage servers. Zone sets help enforce security across fabric-connected devices. Only members of the same zone are granted permission to interact.
Each SAN zone can be a member of multiple zone sets. Zone sets provide the flexibility to perform backup, maintenance and testing of devices in the SAN without encumbering other devices. A SAN may have many zone sets, but only one is active at a time.
Which type of SAN zoning should I use?
The best advice is to use a blended approach. Control which devices and LUNs are mounted on the server using the OS or other software capability to avoid a mount-all approach. Use selective presentation on the storage array and zoning in the fabric. Why do I say this? Using a network analogy, you do not want a PC to hack into the files on your corporate systems.
You prevent this from occurring with access control lists on the files in the file systems. On the shares, you have firewalls, security gateways and packet filtering. Each of these elements does a complementary and slightly different job in protecting your data.
How exactly does zoning work?
When a node connects to a fabric, the first thing it does is a fabric logon. This is how the device obtains its 24-bit address, which is used for routing in the fabric. The device already has its World Wide Name -- or perhaps several -- as each switch port has a unique WWN, usually programmed in hardware.
There is also a node WWN that identifies the node or device and should show up the same on each port. The next step occurs when a device logs on to register with the SAN's name server. The SAN builds a database of every device on the fabric by mapping node and port WWNs to the 24-bit address, as well as to each device's capabilities. This includes whether the device is an FC port (FCP) device that talks SCSI commands over FC.
Finally, a server will ask the name server to send back a list of any FCP devices recognized on the fabric. This is where zoning kicks in. The name server only returns a list of FCP devices that appear in the same or common zone -- in other words, only the devices I am authorized to see.
The server has a list of the 24-bit addresses of all the devices it is authorized to see. It will then typically log on to each one to determine the type of FCP/SCSI device it is. This is similar to normal SCSI where the SCSI controller/server does a scan of the bus and queries the properties of each device it can see on the bus.
There are a number of terms to identify zoning approaches and demonstrate advanced functionality. In my definitions, hard zoning is not the same as port zoning, and soft zoning is not the same as WWN zoning.
When configuring a zone, many SANs allow you to list the members in a zone using the port ID or 24-bit address. To be precise, the syntax is usually X/Y, with X representing the domain ID of a switch and Y denoting the switch's port number. This is similar to seeing how a cable from server 1 is plugged into port 3 of switch 5. Should you change the SAN cabling and topology, you would have to reconfigure all the zones.
The other zone configuration approach is to list the members in a zone using their port WWN or node WWN. The advantage here is that, if you change the domain ID of a switch, the topology of the SAN or where a device is plugged in, then the zone is still good. You may have to replace an HBA and then change the zones, as the WWN is usually burnt into an HBA. But this is a fairly simple change.
What is hard zoning and soft zoning?
Hard zoning is enforced in SAN hardware, blocking access by devices outside the zone. Soft zoning occurs when software invokes the filtering capabilities inherent in FC switching, thus preventing ports from being accessible by users outside the zone.
For example, I may not know your telephone number, but if I guess correctly or misdial, your phone will ring. The security of soft zoning is simple: You are only told things that are vital for you to know.
By comparison, hard zoning is like having a full call bar on your phone. Even if I correctly guess your phone number, your phone will not ring. There is no way for me to get through. Instead of relying on all participants to be good citizens, hard zoning provides real, solid security.
So, why is there confusion about hard zoning and soft zoning? Some switches are not equipped to handle hard zoning. Other switches can do a hard zone, but with lots of restrictions and not with the granularity of individual ports. Still other switches provide hard zoning only if all the zones use the portID syntax, hence the misperception that portID zoning is synonymous with hard zoning. Yet, some switches are now designed to provision hard zoning using either the portID or WWN syntax.
What is the difference between SAN zoning and VSANs?
Here is my view on how a virtual SAN (VSAN) differs from a zone. Note that the VSAN acronym for virtual SAN differs from VMware's vSAN, which is software-defined storage for hyper-converged infrastructure.
As many of you know, the general recommendation -- hot-code activation or not -- is to always run two separate fabrics, connecting each device to both fabrics. There are a number of reasons for this. One is that services like the name server are running as a single distributed service within a fabric. Therefore, there is a small possibility that a badly behaved device could disrupt the name service to the extent that all devices on the fabric, not just those in the same zone, are impacted.
The idea behind a VSAN is to afford a higher-level construct with a totally separate name server database rather than one common to all zones. It may even run as a totally separate service within the switch, so the possibility of cross-contamination is lower and problems are more highly localized.
Of course, a device connected to two separate VSANs may misbehave by bringing down both. A standards-based management system might use the FC unzoned name server query to identify all fabric-connected devices, but how does this command map to VSANs that are not on an FC standard?
Storage zoning and zoning schemas
Now that we understand zoning in a SAN fabric, let's identify common zoning schemas.
Common host. Small and midsize environments tend to use a common host scheme. This method allocates one zone per OS, server manufacturer, HBA brand or a similar approach. This offers a fairly simple approach for environments using the same branded IT gear. It creates a zone consisting of all the common servers, plus the storage devices they need to access.
Single target multiple initiator. Traditionally, many storage subsystems had a rule that any port on an array could only be accessed by multiple servers using the same OS. Customers who started with the common host approach, but then wanted better granularity in their zoning, saw the benefit of having each zone consist of one port on one storage array, along with all the devices that were allowed to access that port.
This form of zoning also makes it visibly easy for a SAN administrator to monitor if the array's OS support guidelines are followed.
Single initiator multiple target. Increasingly common in heterogeneous SANs, this approach comes from a simple premise: SCSI initiators (servers) do not need to talk to other SCSI initiators.
Single initiator multiple target zoning enables one server or HBA in any zone. Also put into the zone are all the storage devices with which the host is authorized to communicate with. This method avoids one server interfering with their servers.
Single initiator single target. This is the ultimate in security, as zones are kept to their absolute usable minimum size to provide maximum security from our zoning. This has been used successfully in a few cases but is not so common. Without good software, it is hard work to set up and manage.
Developments in NVMe flash are expected to have an impact on SAN management, especially newly published standards for FC over NVMe as a way to reduce performance latencies.
As with all things, the approach you use will depend as much on your technology as how you operate. One thing is for sure: You should choose an approach and use it fully and robustly. SAN zoning is not the answer to all your problems, but it is a vital part of storage provisioning. Start off on the right foot, even if you think it is overkill in a small SAN. Once you get going in the right direction, it will be easier to continue with a robust and reliable approach.