Cisco UCS Server Pools: Configuration

In my previous post I discussed Cisco UCS Server Pools and use cases. In this post I will be walking through the configuration of Server Pools, Server Pool Policies and Server Pool Policy Qualifications.

As stated in my previous post one of the use cases for Server Pools is in the server farm model where you have varying amounts of RAM and CPUs in your blades and and you want a way to efficiently deploy a farm of web server, ESX hosts and database servers without having to specifically choose a server blade.

In this configuration example I will walk through the configuration on an auto-populated Server Pool using Server Pool Policies and Server Pool Policy Qualifications.

The first step is to create a Server Pool. To do this go to the Servers tab, Pools.

image 

 

Right-click on Server Pools to create a new pool

image

On the add server page temporarily add a blade and then remove it. If you don’t do this the Finish button stays grayed out. This is one of the UCSM nuances.

image

The next step is to create a Server Pool Policy Qualification

image

I am going to create a web server qualification that uses a Memory Qualification for 8 GB RAM

image

Now to tie it all together with a Server Pool Policy

image

To use this new auto-populating Server Pool associate a Service Profile Template to is so that when you deploy new Service Profiles from the template you don’t have to select a blade, it will be automatically selected if there is one available in the associated pool.

image

 

One important note is that if your blades have already been discovered you will need to re-acknowledge them before they will be added to a server pool.

Another important note is that if you re-acknowledge a blade it will reboot it without asking so you probably only want to re-acknowledge blades that are not associated with a Service Profile.

3 thoughts on “Cisco UCS Server Pools: Configuration

  1. Good summary, Jeremy. It’s worth noting that you wouldn’t bother trying to get in-use blades (those already associated with service profiles) into these auto-populating pools anyway. They’re not available for use, so their pool membership doesn’t matter.

    If and when the blade becomes available again (because the service profile has been disassociated), the associated UCS Utility OS (UUOS) boot will cause the blade to be added to the matching pools.

    I’m still not sure why blades are added only during discovery or post-acknowledgment. The UCS Manager database already contains everything needed to make the determinations of pool membership. A Cisco product from a while back, VFrame Data Center (a product I developed training for), had many similar concepts including the auto-populating server pools. It was capable of adding servers to pools automatically without a rediscovery. I know a lot of the TopSpin/VFrame folks are now involved in UCS – maybe they can explain the logic here.

  2. Thanks Dave, my thinking here was for new deployments where UCS has already discovered all of the blades but you have not associated them with service profiles.

  3. Pingback: Some UCS Links - blog.scottlowe.org - The weblog of an IT pro specializing in virtualization, storage, and servers

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com 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 )

Google+ photo

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

Connecting to %s