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.

Best Practices for Using Static IDs when Converting Local Service Profiles to Global Service Profiles

Setting static IDs within Cisco UCS Central is the best practice when migrating a local service profile to a global service profile. Because storage is likely provisioned on the local service profile, it’s critical that the IDs remain exactly the same for the corresponding global service profiles.

It’s also a best practice that all IDs resolve to global pools. When you set a static ID, it, by definition, does not resolve to a pool. Therefore, you must ensure sure that a global pool exists, containing the exact IDs you intend on setting statically for the global service profile. After changing and assigning a static ID, you can then click the reset icon to resolve the newly changed static ID to its corresponding global ID pool, containing the same ID.

To resolve an ID means that Cisco UCS Central verifies that the static ID used resides in the ID pool. If Cisco UCS Central does not find the static ID listed in the pool, it substitutes the static ID with an ID from the pool.


Important
Before assigning static IDs, make sure that you create global ID pools containing all of the IDs that you plan to use for static IDs.

Note

You can only set static IDs in a global service profile in the following conditions:

  • A global service profile that is not bound to an updating global service profile template.

  • A global service profile that is created from an initial global service profile template.

  • A global service profile that is not referencing LAN or SAN connectivity policies

Follow the instructions in the Cisco UCS Central Server Management Guide, Release 2.0 to assign static IDs.

Proper Order for Using Static IDs when Converting Local Service Profiles to Global Service Profiles

Following is the proper order for static ID tasks, when using static IDs to convert from local service profiles to global service profiles:

  1. Create pools with blocks that contain the same IDs that are in the local service profiles.

  2. Create global service profile templates.

  3. Use the same pool names and IDs, as the local service profile. Specify the global pool names with a prefix (G-). Make sure that the IDs match the exact pattern defined in the local UCS domain and local service profiles.

  4. Create global service profiles.

  5. Unbind the global service profiles from the global service profile templates.

  6. Select static IDs, check for utilization and configure the static IDs.

  7. Bind the global service profiles back to the global service profile templates.

  8. Reset the IDs so Cisco UCS Central can verify that the IDs resolve to a pool.

Using Static IDs

Cisco UCS Central centralizes ID sourcing with pools. Centralizing IDs makes it simple to move objects between Cisco UCS domains.

Previously, you could only set static IDs by using a script. Now, you can still use a script if you choose to, but the UI provides an easier method. You can now manually create and enter, or copy and paste, static IDs into the UI static ID fields. You can set static IDs for the following addresses:

  • MAC

  • IP, both IPv4 and IPv6

  • IQN

  • WWPN

  • WWNN

  • UUID

  • iSCSI Initiator IP

Assigning Static IDs for UUIDs

The best practice for UUIDs is to:

  1. Unbind the global service profiles from the global service profile template.

  2. Enter the static IDs, check for utilization and configure them.

  3. Save the changes.

    Note

    In the global service profile Identifiers tab, Cisco UCS Central displays the newly assigned static UUID, but there is no Resolved Global ID Pool listed.

  4. Bind the global service profile back to a global service profile template that references a global pool.

  5. Reset the IDs so Cisco UCS Central can resolve the IDs to a pool.

Assigning Static IDs Using In-Band or Out-of-Band Management or iSCSI Initiator IP Addresses

If you want to use a static ID, then you cannot bind the service profile to a template. If your service profile is bound to a template, then it obtains an ID from the pool. If there is no pool assigned, it removes the IDs. The only exception is with out-of-band IDs, if you do not assign a pool for a template, then after assigning a static ID and binding to the template, the ID remains as static.

To assign a pool:

  • Create a pool that contains only one ID, the one that you want to use for the static ID. Then, when Cisco UCS Central obtains the ID from the pool, it uses the designated ID.

  • Create as many pools as needed for out-of-band or in-band IDs or initiator IP addresses.

Assigning Static IDs for vNICs and vHBAs

When assigning static IDs for vNICS and vHBAs, the best practice is to:

  1. Unbind the global service profile from the global service profile template.

  2. Select the correct PCIe interface, (in the Interfaces tab).

  3. Use the Check Utilization feature to verify that the newly assigned static WWPN is available in the system, and not used by another global service profile.

  4. Verify that the newly assigned WWPN registers on the vHBA in the Connectivity tab.

    Note
    At this stage, the Resolved ID Pool has no value because the ID is statically assigned, but does not yet resolve to a global pool.

  5. Click the Reset icon to resolve the statically assigned ID to a pool.


    Note

    This action can take up to 10 seconds. When referenced properly, the global ID pool displays in the Resolved ID Pool column.

  6. Repeat this best practice for all PCIe (vNIC/vHBA) interfaces.

Using Static IDs Without Binding the Global Service Profile to a Template

You can choose not to bind the global service profile to a global service profile template. The best practice is to:

  1. Select the static IDs, check for utilization and configure them.

  2. Edit the global service profiles and assign the appropriate ID to a global pool through the Identifiers tab.

  3. Save the changes, click the Reset icon and confirm that Cisco UCS Central resolves the static ID to a global pool containing that static ID.

Now the static ID references a global pool.


Note

Allow the configuring process to properly complete. It can take a minute or two.

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,024 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.