HP StorageWorks Fabric OS 5.X Administrator Guide (AA-RVHWB-TE, September 2005)

Fabric OS 5.x administrator guide 179
Zone objects
A zone object is any device in a zone, such as the:
• Physical port number or area ID on the switch
• Node WWN (N-WWN)
• Port WWN (P-WWN)
Zone objects identified by port number or area number are specified as a pair of decimal numbers in the
form d, area (d is the domain ID of the switch and area is the area number on that switch).
For example, on Core Switch 2/64 or SAN Director 2/128, 4,46 specifies port 14 in slot number 3
(domain ID 4, area 46). On fixed-port models, 3,13 specifies port 13 in switch domain ID 3.
When the physical port number specifies a zone object, all devices connected to that port are in the zone.
If the physical port is an arbitrated loop, all devices on the loop are part of the zone.
Table 34 Approaches to fabric-based zoning
Form Description
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
presumes 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.
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, providing greater susceptibility to
administrative errors, such as RSCNs going 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. It 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.
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 unrestricted access to the
fabric. This form of zoning should be used only in a small and tightly controlled
environment, such as when host-based zoning or LUN masking is deployed.