HP StorageWorks 8/80 HP StorageWorks Fabric OS 6.1.x administrator guide (5697 - Page 170

Admin Domains, zones, and zone databases Each Admin Domain has its own zone database, with both defined and effective zone configurations and all related zone objects (zones, zone aliases, and zone members). Within an Admin Domain, you can configure zoning only with the devices that are present in that Admin Domain. With a hierarchical zoning model, the name space for each Admin Domain and the root zones are separate; configurations are supported with the same zone object name appearing in the root zone database and different ADs (for example, the same zoneset name in AD1 and AD2). Zoning operations ignore any resources not in the Admin Domain, even if they are specified in the zone. The behavior functions similarly to specifying offline devices in a zone. All zones from each Admin Domain zone configuration are enforced. The enforcement policy encompasses zones in the effective zone configuration of the root zone database and the effective zone configurations of each AD. NOTE: AD zone databases do not have an enforced size limit. The zone database size is calculated by the upper limit of the AD membership definition and the sum of all the zone databases for each AD. Admin Domains support defzone mode of noaccess alone. Before configuring any Admin Domain, you must set the defzone to noaccess mode. Admin Domains without effective zone configurations are presented with no access. See "Activating default zones" on page 407 for more information. If the administrative domain feature is not active (AD1-AD254 are not configured and no explicit members are added to AD0), AD0 supports both defzone allaccess and noaccess modes. Admin Domains introduce two types of zone database nomenclature and behavior: • Root zone database-If you do not use Admin Domains, you will have only one zone database. This legacy zone database is known as the root zone database. If you create Admin Domains, you will have the root zone database, which is owned by AD0, and other zone databases, one for each user-defined Admin Domain. • During the zone update process, only the root zone database is sent to AD-unaware switches. • AD-level zone information is merged with the root zone configuration and enforced. • Zone databases-The Admin Domains each have separate zone databases and zone transaction buffers. You can concurrently edit the separate zone databases. The AD zone database also has the following characteristics: • Each Admin Domain (AD1 through AD254) has its own zone definitions. These zone definitions include defined and effective zone configurations and all related zone objects including zones, zone aliases, and zone members. For example, you can define a zone name of test_z1 in more than one Admin Domain. • Each zone database has its own namespace. • There is no zone database linked to the physical fabric (AD255) and no support for zone database updates. In the physical fabric context (AD255), you can only view the complete hierarchical zone database, which is made up of the zone databases in AD0 through A254. • With AD support, zoning updates are supported selectively at each AD level. For example, a zone change in AD1 results in an update request only for the AD1 zone database. Admin Domains and LSAN zones LSANs under each Admin Domain are collated into a single name space and sent out to FCR phantom domains using the following format: _AD For example, a zone with name lsan_for_linux_farm in AD5 is internally converted to lsan_for_linux_farm_AD005. LSAN zone names in AD0 are never converted for backward compatibility reasons. 170 Managing administrative domains