Reference Guide

Refer to Best practices for zoning on page 302 for additional information that should be kept in mind when working with zones.
To list the commands associated with zoning, use the zoneHelp command. For detailed information on the zoning commands used in
the procedures, refer to the Fabric OS Command Reference .
Approaches to zoning
Table 62 lists the various approaches you can take when implementing zoning in a fabric.
TABLE 62 Approaches to fabric-based zoning
Zoning approach Description
Recommended approach
Single HBA Zoning by single HBA most closely re-creates the original SCSI bus. Each
zone created has only one HBA (initiator) in the zone; each of the target
devices is added to the zone. Typically, a zone is created for the HBA and
the disk storage ports are added. If the HBA also accesses tape devices, a
second zone is created with the HBA and associated tape devices in it. In
the case of clustered systems, it could be appropriate to have an HBA
from each of the cluster members included in the zone; this is equivalent
to having a shared SCSI bus between the cluster members and assumes
that the clustering software can manage access to the shared devices.
In a large fabric, zoning by single HBA requires the creation of possibly
hundreds of zones; however, each zone contains only a few members.
Zone changes affect the smallest possible number of devices, minimizing
the impact of an incorrect zone change. This zoning philosophy is the
preferred method.
Alternative approaches
Application Zoning by application typically requires zoning multiple, perhaps
incompatible, operating systems into the same zones. This method of
zoning creates the possibility that a minor server in the application suite
could disrupt a major server (such as a Web server disrupting a data
warehouse server). Zoning by application can also result in a zone with a
large number of members, meaning that more notifications, such as
registered state change notifications (RSCNs), or errors, go out to a larger
group than necessary.
Operating system Zoning by operating system has issues similar to zoning by application. In
a large site, this type of zone can become very large and complex. When
zone changes are made, they typically involve applications rather than a
particular server type. If members of different operating system clusters
can see storage assigned to another cluster, they might attempt to own
the other cluster’s storage and compromise the stability of the clusters.
Port allocation Avoid zoning by port allocation unless the administration team has very
rigidly enforced processes for port and device allocation in the fabric.
Zoning by port allocation does, however, provide some positive features.
For instance, when a storage port, server HBA, or tape drive is replaced,
the change of WWN for the new device is of no consequence. As long as
the new device is connected to the original port, it continues to have the
same access rights. The ports on the edge switches can be pre-
associated to storage ports, and control of the fan-in ratio (the ratio of the
input port to output port) can be established. With this pre-assigning
technique, the administrative team cannot overload any one storage port
by associating too many servers with it.
Not recommended
No fabric zoning Using no fabric zoning is the least desirable zoning option because it
allows devices to have unrestricted access on the fabric. Additionally, any
device attached to the fabric, intentionally or maliciously, likewise has
Administering Advanced Zoning
Brocade Fabric OS Administration Guide, 8.0.1
53-1004111-02 299