One of the UCS Central questions I frequently get asked is, “How can I take advantage of UCS Central if I am already running multiple UCS instances that use local policies, local ID pools, and local Service Profiles? I want to take advantage of UCS Central features, but I am just not ready to hand the keys over to a central manager requiring the use of Global policies, ID pools, and Service Profiles.”
This is a great question and a question worthy of some education around UCS Central capabilities. I like to call this type of environment a “brownfield” environment. In other words, this type of environment is already running multiple UCS instances; each environment is simply being managed one UCS Manager instance at a time.
Let’s start with a high level description of the functional capabilities of UCS Central. UCS Central is a tool that delivers these Global UCS management capabilities:
- Centralized information dashboard
- Centralized configuration tool for Domain-wide settings
- Centralized configuration tool for defining Global server settings
- Centralized management tool for Service Profile administration & mobility
A UCS domain can be registered with UCS Central and there will be no perceivable impact to the registered domain. Specifically, the act of simply registering a domain does not grant UCS Central the right to start manipulating the UCS environment being registered. The act of registration does enable the information dashboard capabilities. When a UCS system (or Domain) is registered with UCS Central, it immediately enables domain wide inventory, fault / event collection, ID Pool management, KVM / UCSM cross-launch, as well as statistics gathering. All of this information is retrievable for all domains registered with UCS Central and all of this information is accessible through the UCS Central interface. So, item #1 above can be accomplished by just registering a domain with UCS Central. That’s it.
Registering a domain with UCS Central also lays the groundwork for some very powerful capabilities. After a domain is registered, UCS Central can begin to take advantage of the configuration capabilities mentioned in items #2 and #3 above. Let’s focus on the domain-wide settings capabilities (#2 above). A UCS Domain admin can choose to “allow” UCS Central to make configuration changes for each type of domain-wide administrative setting. In other words, a domain admin can grant permission for UCS Central to control specific settings by opting-in to these settings (“policies”) through the “Policy Resolution Control” interface in UCSM. This is performed by choosing “Global” (opt-in) or “Local” (opt-out, default) for the specific setting in the Policy Resolution Control interface. The domain admin simply chooses what settings UCS Central is allowed to control, by selecting Global. I like to say, “opting-in to a setting is like handing the keys to UCS Central for this specific setting”.
Now that a given domain is registered with UCS Central, the administrator of this domain also has just enabled a virtual pipeline to a central repository of server setting resources (#3 above). UCS Central can be utilized as a tool to define Global Policies and Global ID Pools. These Global settings are stored within UCS Central, but they are accessible by each of the UCSMs registered with UCS Central. The beauty here is that UCS Central allows an administrator to define a common policy or a common ID pool that can be used by all domains. I like to think of this as a “single source of the truth”. UCS Central becomes THE one place to get the IDs and it is THE one place to get the policies (as opposed to each individual UCSM). No duplicate IDs; Why? Because they are defined and stored in one common place. No redundant policies; Why? Because they are defined and stored in one common place. If the UCS Central admin needs to change a policy, they just change it in UCS Central. The change will be reflected everywhere that policy is used. It is important to note: Even though UCS Central can act as the central repository for these global settings, a UCSM can still utilize local IDs and local policies. With UCS Central, the desire is likely to move away from the practice of using local settings, but the capability does exist.
A repository for Global server settings also lays the groundwork for Service Profile mobility (#4 above). Now that UCS Central has enabled a common resource (ID pools and policies) repository, it is conceivable that a Service Profile could become truly mobile across domains. Why? Because each domain has access to these common resources. The IDs can stay the same and policies can draw upon the single source of the truth in any domain registered with UCS Central. To accomplish this, UCS Central allows an admin to define another global resource called a Global Service Profile. Like a Global setting, a Global Service Profile is defined by UCS Central and it lives within UCS Central; But, a Global Service Profile can be “associated” with any physical server living in any domain managed by UCS Central. So, Global Service Profiles are 100% mobile across any UCS Central managed domain. Note: Global Service Profiles can also be created via Global Service Profile Templates and they can also use Global Server Pools (much like UCSM-based local Service Profile Templates and local Server Pools).
So, getting back to the question at hand: How do I take advantage of UCS Central in a “brownfield” environment?
This is not straightforward. There is no “Easy Button” and there is no migration “wizard”. This can take some time, but almost every customer I have worked with believes the effort is worth the benefit. That said, here is a recommended approach that I have chosen to help get many customers started.
- Start simple; register all your UCS Domains with UCS Central. This will not impact your running UCS environments and it will gather a tremendous amount of centralized data.
- Slowly begin “opting-in” to domain-wide admin settings. Pick one or two specific settings at a time across a handful of domains and slowly start handing the keys to UCS Central. You may even want to consider using the UCSM Platform Emulator to build out a copy of your production UCS environments in a QA lab for UCS Central training (perhaps this is a good idea for a future blog ;-) ).
- Create Global ID Pools and define all of your UCS policies as Global Policies in UCS Central. Now these Pools and polices are available immediately for use across all registered UCSMs.
- Define Global Service Profile Templates and start using them at a pre-determined go-forward point. Adopt a philosophy that says all net-new Service Profiles will be Global Service Profiles.
- Start the retrofit of the of the old local Service Profiles:
- When down-time or maintenance is required, retrofit the local Service Profile (that is under maintenance) to a Global Service Profile. Continue this practice for a pre-determined period (weeks, months, year, ?).
- Finish the remaining environment with scheduled effort. Perhaps engage contractor resources depending on scope.
- Reduce or eliminate local ID Pools and local Policies
If you have chosen a different strategy, I would welcome you sharing that with the community. Or, if you have found this strategy helpful, please share.
Thanks for your time...