Policies

UCSM is a policy-driven device manager. Policies control behaviors and configurations. They control how a server or other components of the UCS will act or be affected in specific circumstances. The UCSM has a large number of different policies.These policies describe and control all aspects of the UCS such as network, storage, server configurations, and system behavior. Rules are defined in form of policies inside the UCSM, and enforced in the end-point (devices). This removes state from devices and improves mobility and scalability. Policies are centrally defined and enforced at the end-point; they can be used to perform policy enforcement on any device within the same UCS. Policies are managed objects and, like any other MO, can be exported and imported to other UCSMs.

Policies can be Configuration (configure specific MO), Operational (Operational policies determine how the system behaves under specific circumstances), Global (defined for whole UCS), Local (only for organization).

Pools

Pools are containers for resources and ID definitions. There are mainly two different types of pools: ID pools and blade pools. A pool contains only one type of resource. For instance, a blade pool can only contain blades and a WWPN Pool can only contain WWPNs. Pools make a system easier to manage and maintain, since they minimize the need for administrators to manage the use of resources. Multiple pools with different names can contain the same type of resources, but also the very same resources. For example, a blade can be a member of multiple pools. Once a blade is consumed and assigned by the system, the blade is no longer assignable. Pools are providers to Service Profiles and Service Profile Templates.

Identity Pools

Identity pools are used for server identity management and assignments. This allows the UCSM to assign automatically identities to a server and their interfaces in the UCS. This minimizes the administrative tasks needed for network, storage and server administrators. More importantly, this is one of the key components for stateless computing since the servers are stateless and any server can be assigned to any ID and workload at any time. There are four types of identity pools: MAC, WWPN, WWNN, and UUID.

Server Pools

A server pool contains a set of available, stateless servers. This pool type allows two different ways to populate the members of the pool: manual and automatic.

Manual Population of Pools

Manual population is a very simple, but not a very efficient, way to assign pool membership for a server. The operator manually maintains and manages the server membership.

Automatic Population of Pools

A pool can be automatically populated via policies. There are two different policies that decide which pool a server should be a member of:
“Server Pool Policy Qualifications” and “Server Pool Policy”. The “Server Pool Qualifications” policy describes the hardware qualification criteria for servers, like number of processors, amount of RAM, type of adapters, etc. A server that fulfills all of the defined criteria in the policy is considered a qualified server. The “Server Pool Policy” describes which “Server Pool” the server becomes a member of, if it has qualified for a certain “Server Pool Qualification”. The same server can meet multiple qualifications. Multiple “Pool Policies” can point to the same pools.

Service Profiles

A service profile is a self-contained logical representation (object) of a desired physical server, including connectivity, configuration, and identity. The service profile defines server hardware (configuration, firmware, identity, and boot information), fabric connectivity, policies, external management, and high-availability information.

Every server is stateless and must be associated with a service profile to gain its identities and personality. A service profile is associated with a stateless server via manual association, or automatically via a blade pool. An associated server (with a service profile) is similar to a traditional bare metal server in the way that it is ready to be used for production and to run business services or software. Once the service profile is de-associated from the server, the server is reinitialized (erased from any state) and returned to the pools (depending on current pool policies). Servers and service profiles have a one-to-one relationship. Each server can be associated with only one service profile.

Each service profile can be associated with only one server. A service profile can be modified, cloned, or used to instantiate a template. The UCSM uses pools, policies, and service profiles to abstract states and configuration information for all the components that define a server. This is one of the key areas that make the UCS a stateless computing system. It allows separation of an operational state and services from the server hardware and physical connectivity. For example, a service profile can be associated to any available server in a UCS, which automatically includes full migration of identities, firmware, and connectivity to LAN and SAN.

Service Profile Templates

A service profile template is very similar to a service profile except it cannot be associated with a physical server. Templates are used for instantiation of multiple service profiles. This is useful for administrators who need to create a large number of service profiles. A server administrator can create a template for a certain purpose, like a database template, or an application template. This enables other administrators to instantiate new service profiles with limited expertise of requirements for a certain application or software. There are two types of templates: “initial-template” and “updating emplate”. The difference is that a service profile created from an “initial-template” does not inherit any new configuration changes made to the template after the service profile has been instantiated. A service profile that has been created from an “updating-template” maintains relationship. The profile keeps inheriting any configuration changes made to the template.

Organizations

Separation of administrators and their administrative tasks can be done by the use of Organizations, Locales, and RBAC. This can be accomplished by dividing the large physical infrastructure of the system into logical entities known as organizations. As a result, administrators can achieve a logical isolation between organizations without providing a dedicated physical infrastructure for each organization. The structure of the organizations depends upon the business needs of the company. For example, organizations may represent a division within a company, such as marketing, finance, engineering, human resources, or other organizations that represent different customers, etc.

The “base” organization is root and all other organizations are hierarchical. All policies and other resources that reside in a root organization are system-wide and available to all organizations in the system. However, any policies and resources created in other organizations are only available to organizations in the same hierarchy. For instance, consider a system with organizations named “Finance” and “HR” that are not in the same hierarchy. “Finance” cannot use any policies from the “HR” organization, and “HR” cannot use any policies from the “Finance” organization. Unique resources can be assigned to each tenant, or organization. These resources can include different policies, pools, quality of service definitions, etc. Administrators can also be assigned strict privileges by an organization.

Hierarchical Pool and Policy resolution

The UCSM resolves a pool or policy name to a service profile parsing the organization tree bottom-up. Consider the organizational structure in Figure. If a user creates a service profile in Org-D and associates a boot policy called policy-1 with it, since UCSM resolves policy names by traversing the tree upwards, the policy association for the service profile will be the policy-1 policy in the root organization. However, if there was a boot policy named policy-1 in Org-D, then UCSM will use that one and not the one in the root organization. Note that, in the absence of any user-defined boot policies, then the default boot policy associated with the organization will be used. Another nuance in the resolution of a pool to a service profile is that UCSM will search the tree for an available resource. For example, suppose a server pool named pool-esx is associated with a service profile in the org-E. When that service profile is deployed, UCSM will search for an available blade from a blade pool called pool-esx from the org-E organization in the scope of parents and grandparents. If there is no available blade in the org-E pool, but one available in the org-C pool, then UCSM will use the blade from the org-C blade pool. Just as with policies, in the absence of a user-defined server pool, the default server pool associated with the organization will be used.

RBAC

Role-Based Access Control (RBAC) is a method of restricting or authorizing system access for users based on “roles” and “locales”. A role can contain one or more system privileges where each privilege defines an administrative right to a certain object or type of object (components) in the system. By assigning a user a role, the user inherits the capabilities of the privileges defined in that role.

Locales

A locale in UCSM is designed to reflect the location of a user in an organization. A user is assigned all the privileges of his/her roles to all objects in the locale for the entire organizational sub-tree where the locale is associated. A locale describes where the privileges from the role can be exercised. By assigning an administrator a certain user role and a locale, administrators can exercise their privileges in the organizations and sub-organizations defined in the locale.