UCS Central Design Considerations

What is UCS Central?  UCS Central in essence is a manager of managers.  Without UCS Central, you have to manage each and every one of your domains or Fabric Interconnect pairs as their own isolated configuration using UCS Manager.

This setup is manageable if you only have a couple domains, but as you scale out it can be difficult to keep track of all your pools, your compute, your service profiles.  Enter UCS Central, you can now manage all of the above from a web gui and one pane of glass allowing for mobility and design of an entire datacenter of compute or even multiple datacenters.  Below are some of the items to consider when designing your UCS Central implementation.


Domain Groups

Domain Groups- Domain Groups are a logical container for FI pairs. There are really only 2 policies that apply to Domain Groups.  That is the Common VLANs and Qualifier policies.

Domain Groups

  1. The qualifier policies are strictly rules on whether a domain fits in the logical grouping.  This includes Registration Policies, ID Range Qualification Policies, and Domain Group Policies. These can help with management addresses if planning for multiple sites.
  2. The Common VLANs is what VLANs are allowed across that Domain Group as shown in the example below:


So, in our instance we based our domain groups on whether that pair of FI’s will share a common grouping of VLANs and we will only be using Domain Groups based on which Datacenter they reside at.

Global vs Local Policies

Once a Domain is added into UCS Central you can specify what policies are managed by the FI’s or by UCS Central.  Ideally, you will want to set everything that you can to globally.  If you login to your UCS Manager of your FI pairs and go to Admin->Communication Management->UCS Central you will see the options that you want to have managed locally or by Central.  One area that we did not want to use is the User Management, but this is because UCS Central requires Schema changes whereas Manager does not require Schema changes for management.  We also discovered that doing backups of the UCS managers locally provides more granularity and options for the current release.



This particular topic may not seem particularly important, but if you dig deeper you will begin to realize this may be your most important design consideration.  The reason for this is if you have different types of use cases for your UCS environment.  Let’s use for example you have bare-metal windows, Vmware ESXi, and XenServer that must be deployed.

In this case, pools and policies may be different for each of these implementations.  In theory, you can do each of these at the root of each policy or pool, but then ALL of your Service Profile templates will have access to ALL of your vNIC templates, Boot Policies, etc.  As long as you name everything under root this might be ok, but what if you have an admin accidently select wrong policy by mistake?

Enter Sub-Organization, you can create a Sub-Org for each of these implementations so that you can create vNIC templates, SP templates, and so on with access only to the policies and pools that they need.   There are certain pools you may want to keep at root level and some to put into the sub organization and we will discuss that later on.



There are a few pool types that need to be created in order to get started on most Service Profile Templates.  This would normally include:

  1. WWPN/WWN Pools
  2. Management IP pools
  3. MAC Address pool
  4. UUID pools
  5. Server Pools (optional)

For each of these you need to consider how large your implementation may get.  We decided that for  all of these that we would create the pools at a global level (per DC) and create all the policies/SP’s at the sub-org level.  We are going to have a UCS Central Per Datacenter due to the sizes of our datacenter and for the management ip addresses.  Here is how we created it:

  1. WWPN/WWN Pool – Created a single 1000 (max value) WWPN/WWN pools
  2. Management IP – 1 global pool with a /23 subnet which will provide us with 30 chassis worth of half height blades + 6 FI mgmt address needs.
  3. MAC Pool – Created a 2 – 1000 (max value) MAC pools.  1 for each fabric
  4. UUID Pool – Single 1000 Address pool
  5.  Server Pools – if you have certain blades for multiple technologies for instance XEN and Vmware or Hyper-V and Vmware.  We created 2 pools one with all the top servers and one with all the bottom servers for hardware redundancy between the 2 hypervisors that we run.




Service Profile Templates

Service profiles in UCS Central are where it differentiates itself from just running a large number of UCS Manager instances.  Instead of creating your SP’s for each UCS Manager you can now create Global SP templates that can be moved between Domains managed with UCS Central. With UCS Central, you now not only have mobility between blades, but mobility between your Domain FI pairs.  What you need to consider here is whether you want to create sub-organizations to differentiate between your different service profile types which was covered earlier in this article under the Sub Organization section.  If you decide to use sub-organizations for your different service profile types you will need to create each of your components underneath each Sub.  This includes vNIC templates, vHBA templates, Boot Policies, Bios Policies and the Service Profile template. Although you are creating these under the Sub-Org, they can still reference the Global Pools like MAC between any of your Sub-Orgs while keeping the other templates that may be different segregated.

Example: vNIC template under Sub-Org Referencing Global Pool vNIC_example

One item to note is that you have to grant permissions to each VLAN that your sub-organization needs access to before you can add authorized VLANs to your VNIC Templates.

Example: Common Vlan Permissions per Org


Hope this helps anyone planning a UCS Central implementation.


One Response to UCS Central Design Considerations

  1. Bytes says:

    Dude, where are the pictures?

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: