Organization

Hierarchy

Cisco UCS Manager is hierarchical in nature, as reflected through its structure.

For Cisco UCS Central, the hierarchical structure takes on a global scope.

The structure of the domain group in Cisco UCS Central is also hierarchical. One important distinction is that "domain group" is purely a Cisco UCS Central construct. It is used for the mapping and application of operational policies, VLANS, VSANS, and some special policies such as ID Access Control Policies, to the registered Cisco UCS domains. Local Cisco UCS domains have no visibility of domain groups, but they are impacted by operational policies.

The best practice for organizations and domain groups is to create the hierarchy to best reflect the logical (organization) and physical (domain group) segmentation of the enterprise.

  • Ensure that any operational policies created in the /root domain group are truly intended to have global applicability for all domains.

  • Ensure that any service profile policies placed in the /root organization are meant to be exposed to the entire Cisco UCS domain.

Mixed-Workload Environments

For Brownfield environments, consider adopting Cisco UCS Central and global consistency for new workloads that are deployed in existing Cisco UCS domains. Such an environment is called a mixed-workload environment, because it may contain both globally and locally managed objects. Two models exist for mixed-workload environments, where an existing domain may contain managed objects owned by both Cisco UCS Central and Cisco UCS Manager:

  • Segregated organizations

  • Integrated organizations

Segregated Organizations

In this model, an organizational hierarchy (starting below /root) contains managed objects owned and managed exclusively by either Cisco UCS Central or Cisco UCS Manager.

Using this approach, the best practice would be to create the organization with a distinctly global name where the organization is only populated with globally managed objects. At the same level within the hierarchy, a corresponding organization would only contain locally owned managed objects.

Workload in the local organization would only reference local pools, policies, and templates. Workload in the global organization would only reference global pools, policies, and templatess.

Furthermore, using the G- prefix in the organization name would imply global scope for all objects. This reduces the need for a G- prefix for each managed object within the organization.

Cisco UCS Central creates this global organization structure and subsequently deploys down during the first association of a global service profile. Best practices dictate that you differentiate the name within this global organization structure. However, we still recommend using the G- prefix names for subordinate pools, policies, VLANs, VSANs, templates, and global service profiles.