Cisco UCS Pools In Depth

I was playing around with the pools built into Cisco's UCS today and I found some information that I wanted to share.   Let's start at the beginning.   A physical UCS blade is attached to a service profile.  The service profile is the identity of the blade and contains all the attributes of the blade.  My best analogy here is Frankenstein.  The service profile is the magic that makes the physical blade come alive (It's Alive!!).  Until a service profile is associated (think big bolts of lightning zapping the blade), the blade won't power on because it doesn't have an "identity" assigned to it.

You have three options to make this happen.  You can 1. Take the hardware defaults, 2. Manually override the hardware default, or 3. Pull your attributes from a pool.  Pools are in some ways like DHCP.  You could specify an ip address for a server or you could pull one from the DHCP pool. 

What is a UCS Pool?  A UCS pool is a predetermined range for an attribute for a UCS blade.  Examples of this could be the server UUID, MAC address, WWNN, and WWPN's for FC.

When are entries from a pool requested?  Entries from a pool are assigned to a blade at Service Profile creation and live with that piece of hardware for the life of the Service Profile.

How large should I make my pools?  Since service profiles pull entries from pools, you need a pool size to match the size of your service profile environment, NOT the hardware environment.  If you are running stateless UCS, you could have one server with 10 profiles (and 10 entries from the pool for the blade) and pop back and forth between any of them at any time.

When is an entry released? A pool entry is released when a service profile is deleted.  Even if a service profile is unassociated from a server, the entry will remain for future use.

Can you determine the order that entries are pulled? Good Luck with that!  You can but it is pretty complex and seems to pull in HEX (every 16).

What else do I need to know?  The only issue I found is what happens when a service profile is deleted and another is created?  There is chance (although not 100% in my experience) that you may pull an entry that was just deleted.  This could cause issues if end to end clean up wasn't performed on your infrastructure.  Think of a LUN on the SAN that is masked to a WWPN.  If this isn't cleaned up when the service profile is deleted there is a chance you might get yourself into trouble because you could access a LUN that you didn't intend too.  This could be any attribute (WWPN, WWNN, MAC, UUID, etc).

Let me be clear on the last point, this isn't a UCS problem.  It is a procedure issue that exists in any organization.  It is simply amplified with UCS because it is now easier because the attribute is moved from hardware to a pool.  In the case of FC, the problem was at the HBA level and now it is in the pool.

As with everything, with great power comes great responsibility!