Pools

Identifier Management

Global identifier management addresses one of the biggest challenges for multidomain management in Cisco UCS: guaranteed unique addressing for system identifiers (MACs, WWxNs, UUIDs). Previously, Cisco UCS Manager best practices suggested embedding a domain ID within the high-order bytes of the ID pool ranges. This is not practical for Cisco UCS Central managed global IDs.

With Cisco UCS Central, you can define all of the ID pools and access them globally across all Cisco UCS domains. This guarantees unique and non-overlapping IDs for service profile assignments across all Cisco UCS domains.

Cisco UCS Central immediately notifies you if you are creating a block of IDs that conflict with another pool or block in the system, at both the local and global levels.

Global ID pools belong to the organization structure. Global pools do not depend on domain groups, as do the Cisco UCS Central operational policies. Instead, the range of global ID pools extends across all Cisco UCS domains in the scope of the organization structure within Cisco UCS Central, regardless of any domain-group partitioning.

When deploying Cisco UCS Central, a best practice is to adopt global IDs along with a global service profile for deployment of new Cisco UCS domains.

Pool Sizing

To minimize the number of managed objects, create a smaller number of pools with a larger number of blocks.

To distinguish A-side versus B-side traffic, create corresponding A-side or B-side pool names. Use an “A” or “B” embedded in the high-order byte of the MAC/WWPN address range. Extending this model toward Cisco UCS Central involves creating multiple blocks under such a pool structure. The most efficient sizing for each block is 256 addresses (0xFF).


Note

Cisco UCS Central imposes a maximum block size of 1,000 addresses (0x3E8) for all pools (UUID, MAC, WWxN).

Duplicate Pool IDs

Cisco UCS Central provides visibility into possible duplicate ID usage.

All pool types (UUID, MAC, WWxN) offer the ability to display duplicate IDs that may exist across Cisco UCS domains. View them in the ID usage summary. Duplicate ID severity is flagged as either "major," for IDs that appear in multiple service profiles, or as "warning," for IDs that appear in multiple local pools.

The only method for viewing local ID pool consumption is to select an individual ID, and view the corresponding local pool and local service profile details.

Transitioning to Global ID Pools

You can reconfigure local service profiles that currently reference local ID pools to instead use global ID pools. Changing any ID for an associated service profile typically causes a service interruption. However, Cisco UCS Central is designed to ease this migration to global ID pools, and not cause a service interruption.

When changing references from a local IS pool to a global ID pool, select the global pool in the vNIC/vHBA reference pull-down in the LAN tab of UCS Manager. First, use Reset MAC/WWxN/UUID to change the pool reference from local to global, then perform the reset. Drill down through ID Usage to see the definitive way of verifying ID association to a local or global ID pool.

Local service profiles that use global IDs are guaranteed ID uniqueness if the global service profiles that reference the global IDs are exclusive. However, local service profiles that reference global ID pools cannot take advantage of global service profile mobility. They always reside in and are confined to the specific local Cisco UCS domain.

Creating New Global ID Pools

Existing Cisco UCS customers, with multiple domains, may have addressed multiple domain ID challenges by embedding a domain ID within the high-order bytes of ID pool ranges. But some administrators might wish to segregate global IDs in a way that is distinct from the previous local ID consumption method.

Generally, domain IDs are no longer relevant when creating global ID pools for new deployments. The exception to this is if you were using a domain-specific ID qualification policy (or a block within a pool).

The best practice of creating distinct A-side or B-side global pools is useful for troubleshooting.

Challenges When Migrating to Global UUID Pools

Transitioning to global UUID pools from local UUID pools creates some challenges.

Challenge Area

Description

Prefixes

Define UUID prefixes at the domain level. You can use UUID suffixes to create blocks within pools. Adopting global UUIDs that are supersets of all local UUID pools requires creating at least one global UUID pool per Cisco UCS domain.

Therefore, the number of global UUID pools must be equal to the number of domains, yielding no consolidation in the number of pools.

Organizations (Orgs)

Global pools are based on organizations, but UUID prefixes are based on domains (internal IDs from the fabric interconnects). There is no mapping between organizations and domains.

Adoption

Existing service profiles cannot adopt the use of global UUIDs in the absence of a reconfiguration cycle and a server reboot.

Cisco recommends letting existing local service profiles remain as local service profiles until they reach the end of their life cycle. Create new local service profiles as global service profiles.

Recommendations for Migrating to Global ID Pools

To maintain the same ID for local service profiles, while migrating to global ID pools, construct the global ID pools so that they are supersets of the corresponding local ID pools. This means that the global ID pool contains all identifier blocks that are currently within the local ID pools.

The best practice is to adopt an A/B naming orientation for MAC and WWPN pools for the fabric, such as G-MAC-A or G-WWPN-B. Once you have created the global ID pools, you can change the service profile, VNIC, VHBA, or template to reference the global ID pools. Cisco UCS Central automatically assigns the same identifier that was previously used in the local ID pool, if not already assigned, thus eliminating the need for a service interruption.

When the ID space is already partitioned and not overlapping, adopt as follows:

  1. Create a new global ID pool in Cisco UCS Central with a unique name. Use Global- or G- for the pool-name prefix. For MAC and WWPN pools, add an -A or -B suffix to the pool name, if desired.


    Note

    For MAC pools, the Network Administrator always sees A and B MACs intermeshed on the network upstream. This is because Cisco UCS Central clusters the upstream connectivity from the FIs to the aggregation layer-2, TOR (top of rack), EOR (end of row) switch.

  2. For each local ID block in the local pool, recreate a corresponding ID block in the global pool.

  3. Change any existing templates (service profiles, VNICs, and VHBAs) to refer to the corresponding global ID pool name.

  4. Change the Pool reference from local to global. Perform a Reset MAC/WWxN/UUID Address on the specific instantiated managed object to effect the global ownership change.

  5. Verify that the corresponding local ID block has no assignments.

  6. Verify, through ID usage, that the address now references a global pool.

  7. Delete the corresponding local ID block for each local ID block in the local pool.

For VNICs, or VHBAs, created from initial templates, once the IDs reference the global ID pools, then all subsequently created managed objects reference the new global ID pools.

For VNICs, or VHBAs, that are bound to updating templates, once the IDs reference the global ID pools, then all existing managed objects bound to the template reference the new global ID pools. If the existing managed object’s ID is present and unassigned in the global pool, then this transition does not cause a reconfiguration, reboot, or service impact.

For VNICs, or VHBAs, that are not bound to a template, if the service profile pool name is modified to point to a global pool, and the existing ID is already used in the global pool, then the service profile receives a new ID, causing a reconfiguration, reboot, and service impact. If the ID is not already used, then the ID is retained and points to the global pool, without incurring a reconfiguration or service impact.

You can also manage IP addresses for ext-mgmt and iSCSI initiators through global pools.

ID Range Qualifications

In Cisco UCS Central, you can use ID range qualification policies to assign ID blocks within a global pool, to a specific domain or domain group, for any local and global service profiles that reference the global pool. In this way, one or more Cisco UCS domains, from a particular domain group, are assured of using a discrete range of identifiers.

In Cisco UCS Central, global service profiles can reference global pools that utilize ID range qualification policy definitions on one or more ID blocks. Cisco UCS Central created the concept of lazy-binding for ID allocation. Cisco UCS Central waits until you have selected a Cisco UCS server for association. Then it allocates an ID from a pool that contains at least one qualified block.

Global ID Usage by Global Service Profiles

The following describes what happens during the global service profile creation, association, and disassociation process.

Global Service Profiles Without a Binding Server

If the global service profile does not use IDs from any qualified pool, then Cisco UCS Central obtains the ID values from the appropriate ID pool.

If the global service profile does use IDs from a qualified pool, the global service profile moves into a config-failure state which triggers the warning message: Using ID pool which contains block with Qualifier (Lazy-Binding)

ID Usage During the Association Process

During the global service-profile association process, the target server and the domain access the global service profile.

Cisco UCS Central performs normal ID resolution to consume the IDs from the appropriate ID block for the domain, or domain group, within the global pool.

ID Usage During the Migration or Disassociation Process

During the global service-profile migration, or disassociation, process, the ID consumption performs as follows:

  • Non-Qualified ID pool—Cisco UCS Central does not release IDs, that are already in use, from the global service profile.

  • Qualified ID pool—During the global service profile migration process, Cisco UCS Central attempts to reacquire the IDs used in the global pools. This assumes that those IDs are still qualified for the newly targeted domain or domain group. If the newly targeted server is in the same domain, Cisco UCS Central reacquires the same IDs. If the newly targeted server resides in a different domain or domain group, Cisco UCS Central re-evaluates the domain qualification policy. If the previously acquired ID does not meet the qualification policy, the ID is released and a new ID is assigned.