Shared storage and zoning before compute recovery

About this article: AI-assisted writing, reviewed against the cited sources. This is source research, not a lab validation of the procedures. Check the stated versions and your own recovery requirements before making changes.

Bring the storage path up before the workloads that need it, and do not treat a powered-on server as proof that the path is right. Shared storage is one resource under many servers. Zoning decides which ports on the fabric may talk. The array's own masking decides which volumes those ports may use. Both have to match the servers you are about to start. Correct visibility is not permission for concurrent writes: also verify volume ownership, fencing, and the supported filesystem or cluster arrangement. A saved copy of the zone database is not automatically the copy the fabric is enforcing.

This is a planning article. It does not tell you the commands to push a zone set, to map a volume, or to repair a server. Those actions can isolate a link or expose the wrong disks, and they were not run for this article.

Why it matters

NIST SP 800-34 Rev. 1 describes a storage area network as shared multi-server storage. In its 2010 discussion of multi-server environments, NIST recommends that storage not be dedicated to each server but centralised, and it names SAN and NAS as the usual way to do that. That historical architectural recommendation is not a universal requirement for modern distributed or local-storage systems. Centralising data can simplify coordinated backup, but consistency still requires an appropriate backup design. The same design makes the storage path a shared dependency. If the path is wrong, every server that was supposed to come back on those volumes is wrong together.

NIST's recovery time objective is the maximum time a resource can stay unavailable before the impact on other resources and on the business process becomes unacceptable. The storage network does not have a private clock. The earliest dependent business deadline constrains the path’s recovery target, with time reserved for the remaining application recovery and validation work.

Two failure modes look alike from the server console and are not alike at all.

• The server is up and sees no disks. People start repairing the operating system. The zone membership or the array mask never included this port.
• The server is up and sees disks it should not see. IBM's introduction to storage networks uses this as a reason zoning exists: not every storage device can protect its own resources from any host that goes looking, so the fabric has to refuse the conversation. A recovered test host dropped into a production zone is how a recovery creates a second outage.

How it works

What the fabric is deciding

IBM's Redbook, ninth edition, December 2017, puts it directly. Zoning is finer segmentation of a switched fabric. It can put a barrier between environments. Only members of the same zone can communicate inside that zone, and attempts from outside are rejected. A device can sit in more than one zone. Zoning is a security control, not only a way to keep teams tidy, and it is also how you keep a test or maintenance environment off the production paths without building a second fabric.

IBM distinguishes two implementations, and they fail differently in a recovery.

Port zoning (what IBM calls hardware zoning) names physical switch ports. The member is the hole in the switch, not the device. IBM's stated disadvantage is that the device has to stay on that port. Move the cable, including to a spare port you plugged in during the incident, and the zone no longer describes the device you think it does. The advantage IBM notes is that you can leave spare ports inside the zone so a failed optic does not force a zoning change. That only helps if the spare was in the zone before the failure.

WWN zoning (what IBM calls software zoning in this book) names the device. Members can be a node World Wide Name or a port World Wide Name. IBM says that if you use WWNs, a device moved to another physical port stays in the same zone, because the name did not change. The zone follows the name. IBM then adds a warning that matters more than the comfort of that sentence: unplugging a disk system and plugging it into another switch port does not mean the host can still use the disks. Whether it can depends on the operating system and the multipath software. This article does not provide those host steps. The planning point is that a port move is not finished when the zone still contains the old name.

IBM also says you can define several zone sets and only one set is active. You can activate another set without powering the switch off. Activation is the moment the fabric's idea of "who may talk" changes. Editing a definition that is not the active set does not change traffic.

Software zoning, in IBM's description, is enforced by what the name server tells a port, not by refusing every frame. A misaddressed frame can still be delivered. IBM also warns that a host can present a World Wide Name other than the one its adapter was given. Many vendors offer hardware-enforced WWN zoning so the switch, not the server, restricts access. "We use WWN zoning" on a diagram does not say which of those two styles you have.

What Cisco MDS 8.x adds, and where it disagrees

The Cisco MDS 9000 fabric guide, Release 8.x, is a specific product, not a restatement of the IBM introduction. Zoning, Cisco says, sets up access control between storage devices or user groups, and it is enforced by examining the source and destination identity. The chapter's own feature list is the one to plan against.

• A zone has members. Members in a zone can access each other. Devices with no shared zone cannot communicate through an explicit zone; overlapping memberships and the default-zone policy must also be considered.
• A device can belong to more than one zone. Cisco's example is a host that can see two storage systems because it is in both of their zones, while another storage system is limited to one host.
• A zone set contains zones. Only one zone set can be active at a time in the sense Cisco states for the fabric. Zones themselves are contained in a VSAN, and each VSAN has its own full database and its own active database. A zone set that is correct in the wrong VSAN does nothing for the servers in the VSAN you are recovering.
• When you activate a zone set, that active copy is what the switches enforce. Cisco says the active zone set cannot be modified in place. You can edit the full zone database while a set of the same name is active, and the edit is enforced only when you activate again. Activating a different zone set deactivates the one that was active. You do not get both.
• On activation, the active zone set is stored so it survives a switch reset. Changes to the full database have to be saved explicitly. After a reboot you can therefore have an active set that is not the same as the last full database somebody edited.
• Hard zoning cannot be disabled on this platform. Name-server queries are soft-zoned. Those are Cisco's words for this product, and they are stricter than IBM's general warning about soft zoning. Do not export either sentence onto a different vendor's switch without that vendor's guide.
• If no zone set is active, every device is in the default zone. Cisco says that on a switch initialised for the first time, members of that default zone are not permitted to talk to each other, and that the current default policy is deny. The policy can be changed to permit, and it is configured per switch. It is not distributed with the zone set. A mismatch, permit on one switch and deny on the other, fails the zone merge and isolates the link between them.

That last point is the recovery trap. Two fabrics, or a recovered switch and the surviving fabric, do not "sort zoning out" by being cabled together. Cisco's merge description says the switches compare protocol versions and zone policies first. If the policies differ, the inter-switch link is isolated. If the merge control is set to restrict, the active zone set and the full zone set have to be identical or the link is isolated. Isolation feels like a failed recovery of the path. It is the fabric refusing a dangerous merge. Clearing it by forcing a merge, without knowing which database will win, is how a recovery site's zone set replaces the production one.

Cisco also says that when you activate a zone set, every participating switch in the relevant VSAN receives the active set. Full zone sets are distributed only if that feature is enabled on the source switch. A new switch added to the fabric acquires zone sets. "Add the recovery switch to the production fabric so it can see the disks" is a merge, not a cable.

Membership on Cisco can be a port World Wide Name, a fabric port, a Fibre Channel ID, an interface, a domain and port, or an address. The port World Wide Name is the identity of the N_Port. Our reasoning, not a Cisco sentence: a replacement adapter commonly presents a new port World Wide Name, so a zone naming only the old identity will not admit it. Virtual or administratively assigned WWPNs may be preserved; verify the identity that actually logs in. A Fibre Channel ID is assigned when the port logs in and can change. A recovery record that only stores the address the host used last Tuesday will not match the port that logs in on Wednesday.

Cisco's sizing guidance is easy to break in an incident. For a zone of N members the switch allows N times (N minus 1) pairs. A single initiator with a single target is the efficient pattern, and many initiators with many targets is not recommended. A temporary zone of every recovered host with every array port is the pattern the guide tells you not to build.

Masking is not zoning

IBM treats logical-unit masking as a separate control, in the storage device rather than in the switch. The array presents virtual disks as logical unit numbers. More than one host can be able to see the same unit, which IBM flags as both a practical problem and a security problem. Masking is the array checking an access list and accepting or rejecting the host. The operator defines which hosts may use which units.

Read that beside zoning and the gap is obvious. A correct zone lets the host speak to the array port. It does not choose the volume. A correct mask on an array the host is not zoned to will never be reached. A recovered server can fail either test and the symptom on the console is still "no disk" or, worse, "extra disk". The recovery gate is both, in that order: the fabric allows this initiator to reach this target, and the array allows this initiator to use these volumes and not the others.

NIST's point about centralised storage is why the mask is an estate decision. One array holds volumes for many servers. Restoring "the" mask from an old backup can remove a volume from a server that is still running, or present a volume to a server that was never meant to mount it. Our recommendation: the mask you activate is the one that matches the initiators you intend to log in now, checked against a record of which volumes belong to which service, not merely the newest file in the backup catalogue.

A sequence that respects both documents

Our recommendation, checked against the impact analysis rather than used instead of it:

1. Decide which fabric is in force. If both sites are up, do not merge them to "see what happens". Cisco's merge rules isolate the link when policies conflict, and they combine zone information when the merge is allowed. Write down which database is allowed to win before anyone connects an inter-switch link.
2. Confirm the switches that will enforce the path are passing traffic to each other, and that a previous merge failure has not left the link isolated. An isolated link is a stop, not a cue to start servers.
3. Read the active zone set, per VSAN if the fabric uses them. Compare it with the set you intend. The full database can contain edits that are not in force. Cisco is explicit that those edits do nothing until activation, and that activation of a different set drops the previous active set.
4. Match members to the ports that will actually log in. Port-based zones must still describe the ports in use. WWN zones must name the adapters and array ports you will use, including any replacement. A changed WWPN requires a planned membership update; verify rather than assume the identity changed.
5. Confirm array masking for those same initiators, including the volumes that must not appear. IBM's separation of this control from zoning is the reason it is its own line on the plan.
6. Only then start the compute that needs the volumes, in the business order from the impact analysis. A server whose only job is to prove the path can be a test initiator in a zone that contains nothing except the volumes you are willing to risk. IBM's reason for zoning includes keeping test off production. Use that, rather than borrowing a production zone for the test.

Before you change anything, record the active set name, the default-zone policy on each switch, and the initiator names in the array mask. That record is the way back. Replacing a zone set belongs before application recovery, not after a disk is already mounted.

What to choose and why

These are our recommendations.

Risks and limits

• IBM and Cisco do not describe the same product. IBM's 2017 introduction says attempts from outside a zone are rejected, and it also says soft zoning does not stop a misaddressed frame. Cisco MDS 8.x says hard zoning cannot be disabled, and it also says a default-zone policy of permit is configurable. Use the guide for the switches you run. Do not average the two documents into one rule.
• The Cisco chapter was read from an Internet Archive capture because the vendor site returned 403 again during independent review on 13 November 2026. The page banner says updated 29 September 2017, and the same chapter's feature table mentions later 8.x releases. It is not a statement about NX-OS releases after 8.x, and it is not a statement about other Cisco SAN platforms.
• Activation is disruptive to membership even when Cisco says unaffected ports keep their traffic. Activating a different zone set deactivates the current one. Pairs that exist only in the old set lose the zoning that allowed them.
• A wide temporary zone is how an incident gets worse. Cisco warns against many-to-many zones. IBM warns that a host can see storage the device cannot protect by itself.
• Masking, replication and array failover are not in the Cisco zoning chapter. This article uses IBM only for the existence and purpose of logical-unit masking. It does not describe any array's mask syntax, snapshot, or remote-copy procedure.
• No host procedure is included. IBM's note that a port move can require an operating-system device refresh is recorded as a limit. The steps are not here, on purpose.
• Nothing was tested. No zone set was activated, no link was merged, and no volume was presented. The sequence is a decision record for a plan, not a runbook cleared on a fabric.

Research and verification

Drafted with AI assistance on 11 November 2026 and independently source-reviewed on 13 November 2026. No article commands or recovery operations were executed. This is educational source research, not a lab-validated production procedure.

Sources

Independently reopened 13 November 2026.

• NIST Special Publication 800-34 Revision 1, Contingency Planning Guide for Federal Information Systems, May 2010: PDF. SAN and NAS as shared multi-server storage; RTO as impact on other resources.
• IBM Redbooks, Jon Tate and others, Introduction to Storage Area Networks, SG24-5470-08, ninth edition, December 2017: PDF. Zoning as segmentation, port zoning versus WWN zoning, one active zone set, soft-zoning limits, logical-unit masking.
• Cisco, Cisco MDS 9000 Series Fabric Configuration Guide, Release 8.x, chapter "Configuring and Managing Zones": official chapter URL cisco.com, which returned 403 on 11 and 13 November 2026. Text was read from the Internet Archive capture of 31 March 2025: archive.org. Active versus full zone sets, default zone, and merge behaviour.

This article was originally published on 13 November 2026.