Boot times for UCS Blades

As part of our firmware upgrade process we will be rebooting the blades for the firmware to take effect.  So as part of my prep process I have done some time measures today to get a feel for how long it may take to accomplish our tasks.

I measured times for VMware, W2K3 and the Cisco Utility OS boot times.

Results:

ESX 4.0 host:

Shutdown Process:
VMware function:  Put into Maint Mode (9 up srv & 8 powered off srv):  3 min. 18 sec.
VMware function:  Power down ESX host via vCenter:  45 sec.

Boot Process:
UCS function:  Click Boot Server until ping and console appear:  4 min. 10 sec.
VMware function:  Time for ESX to fully become available in vCenter:  3 min. 13 sec. additional

Windows 2003 Server:

Boot Process:
UCS function:  Click Boot Server until Windows 2003 splash Screen:  2 min. 16 sec.
W2K3 function:  Time between splash screen and login prompt:  54 sec.

Shutdown Process:
W2K3 function:  38 sec.

Cisco Utility OS, i.e., Service Profile Association:

For any server to run on UCS you first have to associate a Service Profile to a physical blade.  This is the process in which the hardware abstraction is done by running the Cisco Utility OS on the physical blade.  This process does take some time. 

UCS function:  Associate/Disassociate Service Profile to blade:  5 min. 6 sec.

Note the time to Associate/Disassociate Service Profile to a Blade is something that is only ran when first associating these 2 items or when a change in the Service Profile is done.  This does NOT run on every boot.

UCS Upgrade: Step One the Servers: Part 2

Driving into work today I realized I left out some key items regarding upgrading code in UCS Manager (UCSM).  

One of the things that really makes UCS different is the central UCSM running on chips in the Fabric Interconnects (6120).  Having one location to control and manage the full system really simplifies all management tasks, including firmware updates.  Ok, that sounds great from a design and marketing perspective but here is the everyday “does it make your job easier” side.  

1.  All firmware updates are done in one location:  Equipment — Firmware Management.  This provides a tree structure displaying all components, running version, startup version and backup version.  You can filter this view any way you like to only see the components you are interested in.  So to see which blades are running x firmware is a quick process.  

Display of Firmware Management Tab

 NOTE:  You will see in the screen shot Server 2, 3 and 4 are each in a different state regarding firmware.  Server 2 is live running a W2K3 workload with 1.0(2d) version and 1.0(1e) as the backup.  Server 3 is in the state of having 1.1(1l) as Startup Version with the Activate Status as pending-next-boot.  Then Server 4 is running 1.1(1l) code with 1.0(2d) version as backup.  Server 4 is ready for an ESX Service Profile to be moved to it for testing next week. 

2.  Ability to perform firmware updates/changes to one or many components.  Since UCSM gives you a full view of the system you can either select an individual component (blade 2 in chassis 3) or select many (all blades in chassis 1) to perform a firmware task.  This worked well for us.  After doing the pre-stage (called Update Firmware) and activation of new firmware on 2 individual blades we were comfortable with performing a group pre-stage and activation to the remaining 5 spare blades.  This is a parallel process, so it is about the same amount of time to update 1 blade or 10 blades.  Also, the UCSM interface is very good at automatically updating where things are in the process via the Server FSM tab or on the General tab — Status Details.  

3  Ability to Pre-Stage (Update Firmware) without applying the new firmware.  This goes hand in hand with the point above.  You can get your new code on all of the components without impacting the servers.  I like this ability because it allows you to really control each step of the process and visually see your current state.  

4.  Ability to move new firmware to “Startup Version” allowing you to control when the new code takes effect.  This step is done under the Activate Firmware task.  You have the option to either have the activation process only place the new firmware as the Startup Version or it can automatically also reboot the device/component so the new firmware goes into use.  This step is nice because you as the admin get to decide how you want to “activate” the change.  You can choose a one by one, slow, methodical approach or a quick rollout process based on your organization’s needs.  

I hope this information helps with understanding some fundamental differences you have with firmware updates in Cisco UCS.