This is a a two part blog post on Cisco UCS Server Pools. This first post will focus on what Server Pools are and use cases and the next post will focus on configuration.
Cisco UCS Server pools are one of the more mysterious features of UCS. I say mysterious because in my opinion the usage and configuration of them is not very intuitive. Let’s start with Cisco’s definition of a Server Pool, this definition was copied from the Cisco UCS Manager GUI Configuration Guide, Release 1.2(1) found here – http://www.cisco.com/en/US/products/ps10281/products_installation_and_configuration_guides_list.html
“A server pool contains a set of servers. These servers typically share the same characteristics. Those characteristics can be their location in the chassis, or an attribute such as server type, amount of memory,local storage, type of CPU, or local drive configuration.”
You are probably thinking that doesn’t sound very mysterious and you are right it doesn’t until you start digging into the use cases and configuration of Server Pools.
Here are some characteristics of a Server Pool:
- Can be manually populated or auto-populated
- Manual is where you select the blades that you want to be part of a given pool.
- Auto-populated works by creating Server Pool Qualifications and Server Pool Policies where you define the specific hardware characteristics and based on that the blades are placed into one pool or another.
- A blade can be in multiple pools at the same time – For example lest say you have a multi-tenancy UCS environment and multiple Server Pools have the same blades in them. The blades are not actually tied to a specific organization in UCS and so when a user deploys a new service profile and uses a Server Pool for the assignment they will grab the next available server in their pool. This blade could have also been in any other Server Pool in any other UCS organization that met the qualification. It works on a first come first serve model. Once a blade is associated with a Service Profile is not available to any
- A service profile template or service profile can be associated with a Server Pool for rapid blade deployments
- A blade can be located in any chassis that is management by the UCS Cluster
Server Pool Use Cases
Server Farm Model – In this model you have an environment made up of varying applications that have varying hardware requirements.
For example:
- Web server farm that needs at least 8 GB RAM and 1 quad core CPU.
- Database server farm that needs at least 32 GB RAM and 2 quad core CPUs.
- An ESX server farm that needs at least 48 GB RAM, 2 quad core CPUs and a Cisco UCS VIC M81KR adapter.
Rapid Deployments – This would be a new UCS implementation where you are wanting to deploy new blades as fast and efficiently as possible without have to select specific blades to associate Service Profiles with.
thanks for ur articles
Pingback: Some UCS Links - blog.scottlowe.org - The weblog of an IT pro specializing in virtualization, storage, and servers
great article, very clear, now I understand what server pools are used for, thanks
very descriptive, good job dude
Any idea if a pool can be shared across “organizations?”
Hi, I just dropped by to read this blog. It is really full of great content and I
had a good time browsing it, thank you very much
for the good stuff!
Hi jere , i have doubt about creating server pools , let say my environment four blade using for Hyper-v running as cluster , if any blade get failed , VMs automatic will move to another blade so here what will get benefit to creating server pools . kindly elaborate more about advantage and disadvantage of server pools.
Thanks