Large Cisco UCS Central Environment

Advantages of UCS Central for a Large Environment

Large deployments of UCS need Cisco UCS Central. Cisco has over 300 registered UCS domains, with 6,000-plus servers. Internal analysis by Cisco IT shows that they save about 1-person/yr in operations equipment workload by leveraging Cisco UCS Central. Cisco manages every UCS domain with Cisco UCS Central.

Cisco tested the latest release of Cisco UCS Central to support up to 10,000 servers in a single instance. This type of scaling drove the complete redesign of the HTML-5 user interface (UI). The HTML-5 UI is much more suited to managing UCS domains and servers when scaling. The older Flash-based UI suffered from performance issues when used in large environments.

With larger deployments, leveraging an efficient domain group hierarchy is critical. A large environment can contain UCS domains dispersed all around a country, or around the world. A domain group might encompass different time zones, DNS servers, user authentications, domain controllers, and remote FTP servers. An efficient domain group hierarchy permits a more granular approach to firmware upgrades and management.

Trying to separately manage the backup-job schedules for dozens of UCS domains is tedious and prone to error. This task is simplified with Cisco UCS Central. You can define custom schedules for backup (fullstate.bin), configuration export (allconfig.xml), and specific remote-copy FTP servers to ensure proper safeguarding of those backups.

When using LDAP integration for UCS domains with internal LDAP servers, replicating those granular settings is also tedious and prone to error. Cisco UCS Central makes this task much easier. It sets LDAP configurations as part of the domain group hierarchical policy. You can define the policy as broadly, or as granularly, as required.

Note

Cisco UCS Central treats the LDAP Policy as a single policy. You cannot break apart different components of the policy, such as defining the group mappings at one level in the hierarchy, and LDAP providers at a lower level.


You can place policies as high up in the domain group hierarchy as applicable for the UCS domain groups registered in your geographic domain group. You can also place infrastructure and catalog firmware more granularly, lower in the subdomain group structure.

Ultimately, what works best for you and your organization will be the best practice. You can always opt for the simple approach and change or expand your subdomain group structure. It is easier to change a domain group structure than to change an organization structure. Changes to organization structure tend to be changes that result in disruption of the environment.

Figure 1. Large UCS Central Environment: Configuration Example


1

Global policies could reside here. Cisco UCS Central can push them down to subdomains.

2

Policies such as infrastructure and catalog firmware, backup and export, user management, DNS management, time zone, and SEL could reside here.

Greenfield Environments in a Large Environment

For large, planned Greenfield deployments, we recommend initially adopting Cisco UCS Central, and designing your global policy and object infrastructure correctly from the beginning. Creating everything globally within Cisco UCS Central saves time and money, and makes scaling much easier. It also saves time when managing daily operations.

Cisco UCS Central closes the gap that has existed between Cisco UCS Central and Cisco UCS Manager in the initial setup of a UCS domain. Cisco UCS Central now includes the ability to define equipment policies, unified port configurations, port roles, and port-channel configurations.

In addition to planning domain group hierarchy, consider the organizational hierarchy before deploying the final architecture. This includes planning for global ID pools, policies, VLANs, VSANs, templates, and service profiles. The ability to intelligently create organizational boundaries benefits multitenancy and potentially decreases the number of global service profile templates needed for the environment.

Other advanced features, such as VLAN and VSAN aliasing, and ID-range access control policies, also support decreasing the number of global service profile templates to manage. You can manage as much, or as little as you wish, but simplifying management always reduces operating costs.

Brownfield Environments in a Large Environment

A large architecture of Cisco UCS Manager and Cisco UCS Central might contain hundreds or thousands of service profiles. Therefore, moving to UCS Central requires careful planning and calculation. Pay attention if moving the object repository to Cisco UCS Central and converting local service profiles to global service profiles. Build the global infrastructure to mirror the local infrastructure in all of your UCS domains.

Remember that converting a local service profile to a global service profile is disruptive. However, the convenience of managing everything globally from a single interface, and gaining workload mobility among multiple UCS domains, outweighs the negatives.

Some large Brownfield clients have opted to move the object repository, and convert the local service profiles slowly, over time. This takes advantage of future maintenance windows to sequentially migrate to Cisco UCS Central. Upgrading host firmware, controller firmware, BIOS, network adapters, CIMC, and storage controllers are all disruptive actions. The hosts require maintenance windows to gracefully shut down and register the service profile to the blade server performing the upgrades. During this time, you can replace the existing local service profile with a new global service profiles.

Other Brownfield clients have adopted a model of operating Brownfield and Greenfield environments in parallel. This means that existing UCS infrastructure remains as Brownfield. It is locally managed within the respective Cisco UCS Manager domains, while anything new in the environment is deployed as global objects from Cisco UCS Central.

As your network evolves, and local infrastructure reaches end-of-life, convert more of the environment to global. Even if you keep local service profiles, use global service profiles by switching from local to global within the service profile or template. This decreases the number of policies and provides management from one place within Cisco UCS Central. See Brownfield – Accessing Global IDs and Policies with Local Service Profiles

Automation with Powertools and scripts with the XML-API can greatly facilitate the conversion process. See Migrating Brownfield Local Service Profiles to Global Service Profiles