This page is mainly based on Brocade zoning standards.
SAN zoning is used to logically group hosts and storage devices together in a physical SAN, so that authorised devices can only communicate with each other if they are in the same SAN zone. A typical SAN setup will have several zones and a device in a SAN can belong to more than one zone. It might seem intuitively wrong to design a SAN to allow inter-device communication and then restrict that communication, but zoning servers two purposes
When a change is made to a SAN fabric, or an event occurs like a switch going offline, the Fabric Name Server sends out Registered State Change Notification (RSCN) signals so that all the nodes in the fabric know about the change. As nodes are usually zoned together in small groups, zoning means that an RSCN will only be sent to devices in the correct zone, so the SAN is not flooded by fabric-wide RSCN traffic. However while zoning will help prevent RSCN floods, to be honest they are much less of a problem these days anyway with modern HBAs.
While this is not about LUN masking, you need to complement SAN zoning with LUN Masking.
A LUN is a single drive, a drive partition or a set of RAID devices that is presented to a host as a single disk. However a Fibre Channel port can service more than one LUN. You use zoning to restrict access to a port but an authorised server will see all LUNs presented to that port. If you need to restrict access to a subset of LUNs on a port then you need to use LUN masking.
Zoning used to be described as 'hard' or 'soft', but these terms mean nothing with modern switches as all zoning is implemented in hardware. Application Specific Integrated Circuits (ASICs) do the hardware enforcement by filtering out all unauthorised traffic, so only that which is intended for a specific zone can pass through. Now there are only two zoning methods, pWWN or D,P.
You should consider a few factors when choosing between pWWN and D,P zoning -
If you use D,P zoning and a device moves to a different port, then the zoning configuration must be changed. However a zone change is not required when you swap an HBA.
If you use pWWN and you swap out an HBA card then the WWNs will change so you will need to change the zoning, but you do not need to change the zoning if you move a node to a different port.
The switch domain ID does not have to be unique between two fabrics, so the D,P zoning method is not globally unique, unlike pWWN which is unique. However you can make use of this duplication feature for D,P zoning if you have a dual fabric SAN, as you can make the zoning identical on both sides of the fabric, which makes maintenance easier.
The type of zoning you will use is restricted to some extent by what you are configuring. If you are installing FICON channels then you need D,P zones.
Most sites use some kind of server virtualisation these days and this requires pWWN zoning. It actually adds a whole new level of complexity to your SAN and the virtual hosts are zoned on physical hypervisors, which makes it that much harder to track down problems.
Fibre Channel Routing (FCR) lets nodes in two different fabrics communicate without requiring the fabrics to merge. This needs pWWN as all the zones names must be unique and D,P cannot guarantee this between fabrics.
N_PORT ID Virtualisation (NPIV) allows several fiber channel port IDs to share single physical n-port, so saving on hardware. This means that there is more than one device on a port so they need pWWN to identify them. Think about it, if you have several servers sharing one port, then how could you zone them independently with D,P zoning?
So the conclusion seems to be that pWWN zoning is the future way to go.
pWWN is more secure than D,P as it is harder to spoof access by adding a device to a port. OK, to do this, you need an unused port in the correct zone, but it could be done. For this reason, unused ports should be disabled and E-port functionality disabled for N-ports . You can add a duplicate device into a zone as duplicate logins are allowed. Device Connection Control (DCC) Policies or port ACLs can be used to prevent this as they map a PWWN to a specific port.
One top of this, you have two methods of zoning enforcement, Frame based enforcement and Session based enforcement. If you define zones where all the members are pWWN or all the members are D,P then the enforcement will be Frame based, whereas if the zoning is mixed or overlapping the enforcement will be Session based
A 'configuration' is a set of SAN zones.
The 'Defined Configuration' is the complete set of all the zone objects that have been defined in the Zone Configuration database. This database will be replicated over all the switches in the fabric when the cfgsave command is issued. You can use the cfgshow command to display its contents. The config database is used to store alias relationships and it has a limited size, so it's best to keep alias lengths reasonably small to prevent the database running out of space. You can use the cfgsize command to see you big your database is.
The 'Effective Configuration' is the configuration that is currently active, and includes any changes made to the configuration that have not been 'hardened' or saved.
The 'Saved Configuration' is the configuration that was stored in flash memory last time the cfgsave command was run. This configuration will be loaded on power up, or when the cfgenable command is run, and any unsaved changes in the effective configuration will be lost
This section describes the commands used to zone a Brocade switch using the CLI. First you will want to find out the WWPNs for the devices that you are going to zone. You may have to log into the devices to check this, or you could try the switchshow command (or the nsshow command for devices that connect using NPIV) to identify the HBA address of both the targets and initiators.
Next, run the cfgshow command which will display the configuration and how the zoning is currently configured. This will display two sections, Defined Configuration and Effective Configuration. The Defined Configuration is the section in which zones and aliases are listed. Any previously created zoning configurations that are available are also displayed. The Effective Configuration is the current running configuration or configuration in production.
Now run the alicreate command to create aliases for the HBA addresses that you identified earlier. As discussed above, keep the aliases reasonably short but meaningful. The syntax of the command is:
Next, run the zonecreate command to create a new zone. The command syntax is:
You can enter several aliases, separated by semicolons.
Once you have created the zone, either add it to an active configuration with the cfgadd command, or if there is no active configuration, create a new one with the cfgcreate command
Now you have to save the configuration by running cfgsave. This will return a 'yes/no' prompt, so hit 'y' to save the configuration.
However this does not make the new zone live. You need to issue a cfgenable command to do that.
BEWARE OF SLEEPING CHANGES!! If someone else has been changing the config, and has not enabled their changes, you will bring them in. this can (and has!) cause problems. Good change control procedures are essential if more than person can update your SAN zoning.
The screenshot below shows a very simple example of adding a single zone, consisting of one server HBA connecting to a storage controller.
When you design a SAN you need to take 4 things into consideration
In all probability, you will not be designing a SAN from scratch, but working out how to upgrade or extend an existing SAN. You can do this yourself, but I'd recommend that you involve your switch vendor, as they know the parameters and limitations of their equipment. If you are going to use switches from more than one vendor then vendor support can be an issue.
Before making any changes to a SAN fabric, or if you need to design a new SAN architecture, I suggest you start by drawing pictures. Many switch management applications will do this for you. Another method that works well is to use an Excel spreadsheet with a worksheet for each switch.
Start with an overview diagram that shows the ISL links between all the switches and includes details of all the E-ports. Then draw a series of diagrams for each switch, that details every port on the switch, what type it is, and what it is connected to. An Excel spreadsheet with colour coding can be very effective. You should show all the unused ports, and indicate if they are reserved or free. Next you need to detail each zone, but if you have a large fabric that uses SIZ, then that will need too many diagrams. A simple table is more than adequate. Remember that while you can include E-Ports in a D,P zone , they will not be locked down as any user can use any E-Port. Also E-Ports do not have a WWN, so they cannot be specified in pWWN zoning schemes.
Next, you need to decide on the basic type of zoning for each zone, pWWN or D,P, based on any special requirements.
Use Aliases, especially for pWWN zoning, and work out a good alias naming scheme to make the configuration easy to understand, and so easier to maintain. You need to keep the right balance on your alias name length. Make them long enough the be meaningful and to cope for future expansion, but not so long that the fill up the configuration database.
Don't forget your physical SAN security strategy, which should include physical access to the switches, password access and access to the IP addresses.
How should you decide how to group objects into zones? Methods can be based on application, host, storage array or machine hall, but these all have disadvantages with RSCN flooding, scalability and the possibility of affecting a large part of your enterprise if things go wrong. The suggested good practice is to define a zone for every HBA. If an HBA can serve both tape and disk devices, then give that HBA two zones, one for disk and one for tape. This is known as Single Initiator Zoning (SIZ). The reason it is preferred is because it limits problems to a single HBA, and separates disk and tape as tape systems are worst affected by RSCN storms.
You should also define a default zone that has a -noaccess setting. While you are enabling a new configuration, the zoning drops to a default setting for a very short time. The normal default setting is that all nodes can access all other nodes.