HealthITGuy's Blog

The evolving world of healthcare IT!

UCS Manager: Key Components part 1

There are several foundational concepts of the UCS Manager that need to be understood before being able to grasp the new way of deploying and managing blades.  Here is part 1 of an explanation of the concepts as I currently understand them.


By default there is the “root” organization.  Organizations are global to UCS, meaning if you create an organization for example called “finance” it will exist in all areas of the system.  You may want to use sub-organizations as a means to organize objects, control access or manage access within the system.  For example, your finance group may have 6 blades they manage and have control over.  You can allow the finance users to see and manage only items in the finance organization.

You can think of Organizations as being similar to Organizational Units (OU) in active directory.


Servers Policy Listing.

Servers tab Policy Listing.

Policies exist under the 3 areas of Server, LAN and SAN.  A policy is a defined parameter that is assigned to service profiles.  For example, the Server policy called Boot Policy is where you define various means to boot a blade; via LAN, boot from SAN, local disk, etc.

Cisco defines the policies as well as the options within each policy.  Policies are dynamic, if you change a setting within a policy it will take effect wherever that policy is defined (it may require a reboot of the blade depending on the policy).  Over time I can see Cisco adding additional functionality by adding new policies.  Things like Bios Boot policy to allow you to have groups of blades boot to different bios levels, etc.



SAN Pools.

A pool is a defined set of values to be used by service profiles.  Currently you can define pools for the following items:

Server Tab:  Server pool (physical blades) and UUID suffix

LAN Tab:  MAC address pool

SAN Tab:  WWNN and WWPN pools

This is where you get to define what MAC address, WWNN and WWPN values you want to use, which can be powerful.  This is because you can pre-define your WWPN and zone your fabric ahead of time, so your server people are not waiting on your storage people to zone new servers.

For example, we created 2 WWPN pools for our ESX servers; 24 WWPNs for fabric A and 24 for fabric B.  Then we exported the list of generated WWPN and put them into my spreadsheet that generates all of the CLI commands for creating zones on my Cisco MDS switches.  Within 20 minutes we had pre-zoned my next 24 ESX hosts on the SAN fabric.  As we add ESX hosts via UCS each will get a WWPN from the pool and already be zoned to my storage array.  Note, the storage person will still get to control what storage resources the new host sees.

In addition, you can have more than 1 range defined for any of the pools.  Meaning you can define a range of MAC addresses that you only want to use for ESX hosts and another range that will always be for Windows 2008 servers.  It really comes down to how you want to manage your environment.  Does it add value to be able to identify that a specific MAC address is a UCS blade running W2K8?  We decided it did not, but it could be useful for others.  This same thought process was used when defining each of the pools.  Obviously we felt the WWPN pools had value by creating ranges for specific purposes (i.e., A and B fabric).

That is a start, more to come later.

November 13, 2009 - Posted by | UCS Manager | , ,

No comments yet.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

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

Google photo

You are commenting using your Google 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 )

Connecting to %s

%d bloggers like this: