HP StorageWorks 16-EL HP StorageWorks Zoning V3.1.x/4.1.x User Guide (AA-RS26C - Page 58

Fabric-Based Zoning Philosophies, No Fabric Zoning, Zoning by Application, Zoning by Operating System

Get HP StorageWorks 16-EL - SAN Switch PDF manuals and user guides View all HP StorageWorks 16-EL manuals
Add to My Manuals
Save this manual to your list of manuals

Page 58 highlights

Zoning Concepts and Guidelines Fabric-Based Zoning Philosophies This is perhaps the most controversial aspect of zoning. There are a number of philosophies for the implementation of fabric zoning. All will work in most cases. However, there are pros and cons to each form. The primary forms are no fabric zoning, single HBA, grouping by operating system, grouping by application, and port allocation. No Fabric Zoning This is the least desirable zoning option because of the unrestricted access that devices have on the fabric. All devices have full knowledge of the fabric membership and potentially have access to all the devices. Additionally, any device attached to the fabric, intentionally or maliciously, will likewise have unrestricted access to the fabric. This form of zoning should only be utilized in a small and tightly controlled environment, such as when host-based zoning or LUN masking is deployed. Zoning by Application In most environments, the concern for availability is by application, not by server, such as in clusters. This method will most likely require zoning multiple operating systems into the same zones. Some operating systems have issues co-existing in the same zone with other operating systems. This method of zoning creates the possibility that a minor server in the application suite potentially has the ability to disrupt a major server, such as a web server being able to disrupt a data warehouse server. Zoning by this method may also result in a zone with a large number of members that would provide a greater opportunity for administrative errors to occur, such as RSCNs going out to a larger group than might be necessary. Zoning by Operating System The issues here are much the same as zoning by application. In a large site, this zone may become very large and complex. When zone changes are made they typically don't involve a particular server type, but are more concerned with applications. Situations have been encountered with operating system clusters. For example, if members of different clusters can see storage assigned to another cluster, they may attempt to own the other cluster's storage and compromise the stability of the clusters. 58 Zoning Version 3.1.x/4.1.x User Guide

  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28
  • 29
  • 30
  • 31
  • 32
  • 33
  • 34
  • 35
  • 36
  • 37
  • 38
  • 39
  • 40
  • 41
  • 42
  • 43
  • 44
  • 45
  • 46
  • 47
  • 48
  • 49
  • 50
  • 51
  • 52
  • 53
  • 54
  • 55
  • 56
  • 57
  • 58
  • 59
  • 60
  • 61
  • 62
  • 63
  • 64
  • 65
  • 66
  • 67
  • 68
  • 69
  • 70
  • 71
  • 72
  • 73
  • 74
  • 75
  • 76
  • 77
  • 78
  • 79
  • 80
  • 81
  • 82
  • 83
  • 84
  • 85
  • 86
  • 87
  • 88
  • 89
  • 90
  • 91
  • 92
  • 93
  • 94
  • 95
  • 96
  • 97
  • 98
  • 99
  • 100
  • 101
  • 102
  • 103
  • 104
Zoning Concepts and Guidelines
58
Zoning Version 3.1.x/4.1.x User Guide
Fabric-Based Zoning Philosophies
This is perhaps the most controversial aspect of zoning. There are a number of
philosophies for the implementation of fabric zoning. All will work in most cases.
However, there are pros and cons to each form. The primary forms are no fabric
zoning, single HBA, grouping by operating system, grouping by application, and
port allocation.
No Fabric Zoning
This is the least desirable zoning option because of the unrestricted access that
devices have on the fabric. All devices have full knowledge of the fabric
membership and potentially have access to all the devices. Additionally, any
device attached to the fabric, intentionally or maliciously, will likewise have
unrestricted access to the fabric. This form of zoning should only be utilized in a
small and tightly controlled environment, such as when host-based zoning or LUN
masking is deployed.
Zoning by Application
In most environments, the concern for availability is by application, not by server,
such as in clusters. This method will most likely require zoning multiple operating
systems into the same zones. Some operating systems have issues co-existing in
the same zone with other operating systems. This method of zoning creates the
possibility that a minor server in the application suite potentially has the ability to
disrupt a major server, such as a web server being able to disrupt a data warehouse
server. Zoning by this method may also result in a zone with a large number of
members that would provide a greater opportunity for administrative errors to
occur, such as RSCNs going out to a larger group than might be necessary.
Zoning by Operating System
The issues here are much the same as zoning by application. In a large site, this
zone may become very large and complex. When zone changes are made they
typically don't involve a particular server type, but are more concerned with
applications. Situations have been encountered with operating system clusters. For
example, if members of different clusters can see storage assigned to another
cluster, they may attempt to own the other cluster's storage and compromise the
stability of the clusters.