cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Announcements

UCS Central and My Existing Environment - How do I get there?

3587
Views
16
Helpful
5
Comments
Cisco Employee

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:

  1. Centralized information dashboard
  2. Centralized configuration tool for Domain-wide settings
  3. Centralized configuration tool for defining Global server settings
  4. 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.

  1. 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.
  2. 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 ;-) ).
  3. 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.
  4. 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.
  5. 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...

Brad TerEick

btereick@cisco.com

@BradTerEick

5 Comments
Beginner

Brad,

Great post,  I have few challenge  and questions regarding migration  to  UCS central.

1.   Cureently, I have  non overlapping local pools( MAC, UUID, WWPN, etc)  to each domain.  I have below two options,

A.     I am thinking about creating one big global pool with big range of MAC, WWPN( from all domain) and assign it to service profile templates-- this will make MAC, WWPN assignment mixes between domains.-- It may be little difficult to identify which MAC and WWPn is  belongs to which domain.

B. Create seperate global pools(WWPN,MAC) based on each domain,create seperate global/local service profile based on domain and use  global pools specific to each domain.

Q1: Is it possible to use single global service profile template  but based on domain - it used different pool information?

Q2: Is it possible to create global pools with aggregation of all existing local pools-- when change service profile to use global pools-- is it possible to keep same local ID( MAC/WWPN) even after migrating to new global pool?

Q3: Please advise me, which of above option is better, It appears that, Option A is better but what is risk/disadvantage of using option A?

2. I am plannig to install UCS Central in cluster mode with primary node is main site  and secondary node is in DR site,what is requirement for latency requirement between both node?  Is it possible to keep cluster node in two seperate subnet?

3.  What will happen if, UCS Central VM  is installed  within same domain managed by UCS Central?  I understand, even if UCS central is down, UCS manager will still function expect new global service profile will not get IPS etc.

4. What is steps to restore UCS Central? if UCS Central VM is within same domain managed by UCS central , how does it impact restoration process of UCS Central?

5. How do I keep MULTIPLE  copies of UCS central and UCS manager backup?  Is it possible to export or upload it to external FTP server on daily basis?

Thnaks 

Hetal Soni

Cisco Employee

I’d like to thank my colleague, Jeff Silberman for assisting me with this response.

Q1: Is it possible to use single global service profile template  but based on domain - it used different pool information? 


Golden rule… Global Service Profiles and Global Service Profile Templates can only use global pools.  It is possible, to segment ID usage based on a Domain Group, but only when a given ID is consumed by a Local SP. 

Q2: Is it possible to create global pools with aggregation of all existing local pools-- when change service profile to use global pools-- is it possible to keep same local ID( MAC/WWPN) even after migrating to new global pool?


Yes --- BUT --- you MUST be on 2.1.3 and after the assignment to the Global Pool, you will still need to do a “Reset MAC” to have the Global Pool assignment take effect.

Q3: Please advise me, which of above option is better, It appears that, Option A is better but what is risk/disadvantage of using option A?

Keep in mind: there’s no way to make a Local SP become a Global SP.  Based on this, you might just want to keep everything Locally Managed with Local ID’s --- and have a completely new address scheme for Global IDs (see best practice guide). 

Q2. I am plannig to install UCS Central in cluster mode with primary node is main site  and secondary node is in DR site,what is requirement for latency requirement between both node?  Is it possible to keep cluster node in two seperate subnet?

No.  UCS Central uses a shared storage target for it’s HA cluster; therefore we only support HA at the same site --- not DR.   Assumption is that Central is running in one Hypervisor cluster.

Q3. What will happen if, UCS Central VM  is installed  within same domain managed by UCS Central?  I understand, even if UCS central is down, UCS manager will still function expect new global service profile will not get IPS etc.

This is not advisable.  Yes; UCS Manager can function without UCS Central (even if it was previously managed by UCS Central), but picture a situation where UCS Central is enforcing a policy that affects the server that is running UCS Central. When if that policy requires a reboot.  This is definitely not advisable.  All bets are off. 

Q4. What is steps to restore UCS Central? if UCS Central VM is within same domain managed by UCS central , how does it impact restoration process of UCS Central?

See #3.

Q5. How do I keep MULTIPLE  copies of UCS central and UCS manager backup?  Is it possible to export or upload it to external FTP server on daily basis?

Ahh!  A good question… UCS Central provides great capabilities for scheduling and maintaining backups, but backups to an external server are not possible.  Backup to an external server is a great request.   Our team of talented TME’s will script and post this shortly.

Enthusiast

Brad,

Great article! So far the switch to Central has been fairly simple. The only big hurdle I've run into is switching the UCS domains over to Global VLANs.

Do you have any strategies to replace local VLANs with the global versions?

For example: I have a local service profile with a vnic using VLAN 100 and I want to create a global service profile for a new host and apply it to an additional blade on the same UCS domain. The GSP's vnic will be configured for VLAN 100 as well but association with the blade will fail due to the VLAN overlapping.

I have found the only way around this is to pull VLAN 100 out of the local vnic template and then delete local VLAN 100.

I then try to associate the GSP to the blade again and this time it will create a global VLAN 100 on the local UCS domain.

At that point I can then add the global VLAN 100 back to the local vnic template so the local SP can communicate again.

The issue I'm running into is that this requires an interruption in data flow since the VLAN has to be deleted and the global version copied down. This becomes a bigger hurdle when all ESX hosts share the same admin/mgmt VLAN. All ESX hosts will have to take a full interruption in mgmt traffic while the VLAN is deleted.

Hopefully I'm over thinking this and there is a simpler way to go about this.

Thanks

Ben

Enthusiast

I know the thread is a bit old but I just went through what you're asking.

Short answer: You need to pick a new name.  UCS from what I can tell does not use any underlying GUIDs but rather does a straight comparison of VLAN name and VLAN ID which results in a ton of overlaps if you try and keep the exact same names.  Helpfully Cisco suggests pre-pending all global policies, VLANs, etc with a "G-" but the reality is that in any brownfield environment, this is an absolute necessity.

In your example, create a global VLAN "g-vlan 100" and then when you change your template over to use the global vlan you will then see it pop into the local UCSM vlan list.  Also, just as a potential pitfall, if you are using VLAN Groups (as we are to split network and iSCSI traffic) you must manually add the new "g-vlan 100" into your VLAN group.  This has to be done with all new global VLANs the first time it is added.

However I would suggest building everything you need into UCS Central as a global policy, vlan, template, etc. and then swapping local policies over to global.  Maintaining both sets of policies is a drag.

I will say that with each release of UCS Central I like it more and more.  It's come a long way from the first release and it does make my life quite a bit easier as we have 5 domains and will be adding a 6th shortly.

Enthusiast

Thanks for the follow up! Yeah I was told by someone else at Cisco to use the "g-" to differentiate the names. I use that as the naming standard for anything in Central now.

I agree that Central has become a much more powerful tool than when it started out.

I have 13 domains globally with 4 more coming in the next couple of months. The UCS Central PowerTool has helped tremendously in scripting the creation of LAN Connectivity Policies and SP Templates. (Which we create a lot of due to the needs of segregation between the different server roles and their associated templates.)

CreatePlease to create content
Content for Community-Ad
August's Community Spotlight Awards
This widget could not be displayed.