Identity and Resource Pools for Hardware Abstraction

The Cisco UCS abstraction of the hardware and how it affects the server’s identity is illustrated in Figure 17-16.

Figure 17-16 Cisco UCSM Hardware Abstraction

Each physical server has an identity that uniquely identifies it for the purposes of network and storage communication, and the operating system. This identity is used for security purposes and for licensing. As such, it is tightly connected to the behavior of the applications running on the server. The result is that the applications are stuck to the identity of the server. If something happens with the server, such as a hardware failure or an upgrade, this identity changes. This can affect the applications in different ways, from needing a slight reconfiguration to needing to be reinstalled with a new configuration. This is usually disruptive and affects the provided services. These identity values are the UUID of the server, the MAC addresses used for the network communication, the WWPN and WWNN addresses for the Fibre Channel communication, and the BIOS and firmware settings.

With the Cisco UCS, this challenge is solved through hardware abstraction, which is achieved by removing the identity and configuration of the server from the physical hardware. All of the identity information and the needed configuration for the server is contained in a logical object created in the Cisco UCS Manager, called a service profile. When the service profile is associated with a physical server, the identity and configuration are applied to it. If the service profile is disassociated, the identity stays with the service profile, and it will be used on the physical server to which the service profile is associated. This mobility of the server identity and configuration, achieved through the decoupling from the physical hardware via the use of service profiles, allows the physical server to be used only as the provider of the needed hardware resources. As long as a physical server has the needed hardware resources, as required by the service profile, it can be used. It does not matter which one is the physical server—the first, second, or the fifth one in the blade chassis—or whether it’s going to be on the same chassis or on another chassis from the same Cisco UCS domain.

The identity values can be manually configured for each service profile. To avoid overlapping values, you can use identity resource pools, which can be created in the Cisco UCSM, and from them the service profiles can consume identity values.

Each computer, whether it’s a server, desktop computer, or laptop, has a unique identifier that is burned into the BIOS. This is called a universally unique identifier (UUID). UUIDs are 128-bit identifiers with the following characteristics:

They are standardized serial numbers that identify a particular server.
The servers have hardware UUIDs stored in the system BIOS.
UUIDs are used for licensing purposes.
The UUIDs can be manually or automatically assigned in the Cisco UCSM.

When the UUID is assigned manually, the whole 128-bit value needs to be entered. For automating the assignment, you can use a UUID pool. When a UUID pool is created (see Figure 17-17), the Cisco UCSM follows some rules:

Figure 17-17 Cisco UCSM UUID Pool

The Cisco UCSM divides the 128-bit UUID into two pieces: a 64-bit prefix and a 64-bit suffix pool.
To create a UUID, you take the prefix and a value from the suffix pool. This results in a unique ID.
Cisco recommends using the same 24-bit organizationally unique identifier (OUI) across all the identity pools.

For the network communication, you use physical network addresses called Media Access Control (MAC) addresses. The MAC address uniquely identifies a network interface and has a 48-bit value. In the Cisco UCS, the MAC address is assigned to the vNIC, which is visible to the operating system (OS). Just like with the UUIDs, the MAC address value can be configured manually in the service profile, or you can use a MAC pool from which to derive the value (see Figure 17-18). Cisco recommends using a Cisco OUI of 00:25:B5 as the first 24 bits of the MAC address.

Figure 17-18 Cisco UCSM MAC Pool

The World Wide Node Name (WWNN) and the World Wide Port Name (WWPN) addresses are the physical addresses used in the Fibre Channel protocol communication. Both have the same structure and a size of 64 bits, but it is important to remember that they identify different things in the communication. The WWNN uniquely identifies the device. Usually, it is the HBA of the server, but in the Cisco UCS, as the HBAs are created in the silicon of the mezzanine adapter, and are virtualized, the WWNN will represent the server. The WWPN identifies an FC port in the storage communication. In the Cisco UCS, a WWPN will uniquely identify a vHBA from the mezzanine adapter. Again, just like with the previously described types of identities, the WWNN and WWPNs can be set manually in the service profile, or you can use WWNN pools and WWPN pools (see Figure 17-19). In both approaches, special attention has to be paid to the values used. The WWNN must be a different value from the WWPN—especially when the WWNN and WWPN ranges of values are configured in the pools. If they overlap, the Cisco UCSM will fail to associate the service profile with the server, as it will assign first the WWNN value. When it tries to assign the WWPNs, if there is an overlap with the WWNNs, it will stop the procedure with a failure message.

Figure 17-19 Cisco UCSM WWNN Pool

Besides the identity resource pools, which can also be referred to as logical resource pools since they are created by the Cisco UCS administrator and the values are generated, there is one other type of pool in the Cisco UCSM: the server pool. The server pool is also referred to as a physical pool because it is used to group and classify the existing physical servers in a Cisco UCS domain, based on their hardware characteristics, such as model and type of the CPU, number of cores, minimum and maximum memory, mezzanine adapters, and so on. Server pools allow you to utilize in full the mobility of the service profiles. When a server pool is specified in a service profile, the physical server will be taken from it. In case of a failure, the service profile can get another physical server from the same pool, and it will provide the required hardware, as based on this it was included in the server pool.

A physical server can belong to a server pool only when it is not associated with a service profile. It can also belong to multiple server pools, as long as it matches the requirements for the hardware (see Figure 17-20). The moment that a service profile is associated with a physical server, then it becomes unavailable in the pool, or pools, to which it belongs.

Figure 17-20 Cisco UCSM Server Pools

There are two options for how a server can be added to a server pool:

Manual: The administrator manually adds the server to one or multiple server pools.
Automated: This is done using a server pool policy, which has an empty server pool and a qualification policy. The qualification policy is a set of hardware requirements. When a physical server is discovered by the UCSM, its hardware is checked against the qualification policy. If it matches the requirements, it will be added to the empty server pool.