Your Cisco UCS Central adoption approach depends primarily on whether you are using a Brownfield environment or a Greenfield environment.

• Use global operational policies, global fault and inventory reporting, and global statistics universally, regardless of workload profile and existing Cisco UCS deployments.

• Understand that new deployments that are 100% globally managed generally do not risk any namespace collision, or conflicts. Therefore, they do not require such attention (“G-“ prefix for managed objects).

• Try to restrict new workloads to new domains that are exclusively globally managed.

• Try not to mix global pools, policies, templates, local service profiles in domains that are also locally managed. This helps avoid name collisions and conflicts in local service profile creation and deployment. If a domain does mix local and global objects, use a segregated organization structure to reduce the potential for naming collisions and conflicts.

• Do not import default objects.

• Use named polices that communicate what the policy does, rather than a default named policy. Someone can accidentally change or hide the value-property behind the name. For example, you might make the mistake of changing a default scrub policy, one that is normally set to no for disk scrub or BIOS setting scrub, to yes. This would have catastrophic effects on local service profiles disassociated from blades containing local disk-installed operating systems.

• Use the Cisco UCS Platform Emulator to model and test an adoption procedure.

The https:/​/​communities.cisco.com/​ucs community site hosts valuable content related to Cisco UCS Central and adoption. It includes Brad TerEick’s helpful blog Cisco UCS Central and My Existing Environment - How do I get there?

As you centralize policy and control in Cisco UCS Central, certain challenges may surface that highlight issues best managed with local resources and control points. These are called Local Affinity issues when referencing local domains. The common affinity points are:

• External IP pool (global-ext-mgmt)

• Boot policies

• VLANS and VSANS

Use ID range qualification policies to ensure that Cisco UCS uses the correct blocks of management IPs when a global service profile is migrated from one Cisco UCS domain to another.

You can assign blocks of IPs for a domain or domain group with the ID range qualification policy. As you migrate the local service profile, a new management IP accompanies the association to the respective Cisco UCS domain.

Some organizations are always looking for ways to reduce the number of global service profile templates they create and maintain in their Cisco UCS Central architecture.

One method is to leverage the hierarchy policy resolution capabilities of Cisco UCS and Cisco UCS Central. Some organizations put their ID pools at a high level, because they cannot justify the need to segregate IDs based on the downstream organizations. Similarly, they also place the most common configuration policies high in the organizational structure.

They then rely on policy resolution for Cisco UCS and Cisco UCS Central. This allows for a policy with the same name to exist at different organizational levels, but to have different values embedded within those policies. Therefore, when they create or import a global service profile within that organization, the global service profile accesses that particular named policy with the proper values for that particular organization.

In general, define unique LAN connectivity policies and storage connectivity policies at a lower, more granular level. As long as they have the same names in the different organizations, the global service profile uses the correct policy with the correct values.

Prior to attempting an upgrade of Cisco UCS Central:

1. Upgrade all registered Cisco UCS domains to a minimum of Cisco UCS Manager release 2.1(2a). Use the most recent maintenance and patch release in the Cisco UCS Manager release 2.1 tree if using Cisco UCS Manager release 2.1.

2. Use Snapshot Manager and take a snapshot of the VM to preserve the state of the original VM.

3. Take both a full-state backup and a config-all backup of Cisco UCS Central. Ensure that the backup state is enabled for both, and make sure that these backups are available offline.

   Note	During the backup, the local Cisco UCS domains lose visibility to Cisco UCS Central, but the state changes back to registered once the upgrade completes.

4. Complete all infrastructure firmware updates prior to upgrading to Cisco UCS Central release 1.5. The schedule information for infrastructure firmware update jobs does not transfer to the new release. In release 1.5, you create infrastructure firmware update jobs for maintenance groups, not for domain groups.

Note	Do Not perform an unregister/reregister cycle for your Cisco UCS domain as part of the Cisco UCS Central upgrade.

Can you compare imports from two domains to see if they are different? If you have two domains that you think are configured the same, can you import both and find out?

No, Cisco UCS Central does not have a native Diff function today. It may be considered for a future release. You can create tech-support logs from Cisco UCS Central, extract the log files, and import them into an XML editor or repository that performs a Diff function, to compare two configurations.

Can we export Cisco UCS Central reports in CSV or PDF format?

Yes.

How large can the embedded database be? The documentation shows up to five domains with the embedded database, but is vague on how large the database is.

For five domains, it's about 240-GB. There is no limit. Cisco UCS Central can support up to 10,000 servers.

Does Cisco UCS Central support alternate Disaster Recovery architectures such as VMware Site Recovery Manager (SRM)?

No. Use hypervisor HA tools, like VMware HA, snapshots of VMs, clones, daily backups, and targets. Backup is a Disaster Recovery functionality. Set up a remote copy. Store the remote copies on a different server, like an FTP server. If the Cisco UCS Central fails, you can deploy a new Cisco UCS Central with your backup. Also do not use clustering, use a single VM.

Do I have to still use a global service profile and server association as a delivery mechanism to deliver a VLAN or VSAN down to the Cisco UCS domain?

No. Use local service profiles for something that has to be local. If you want to push a target, use a global VLAN service profile. Global VLANS and VSANS stay on the domains, even if you remove the global service profile. Now we have an API that you can use in the CLI to push global VLANS or VSANS down from Cisco UCS Central to a domain. Use an SSH application to access Cisco UCS Central to perform these tasks.