HealthITGuy's Blog

The evolving world of healthcare IT!

UCS Upgrade: Step One the Servers: Part 3

We are making progress with the server component of the upgrade process.

Our spare blade with an Emulex mezz. card running 1.1(1l) code for the interface and BMC was ready for a real workload.  We put one of our production ESX hosts into maintenance mode and powered off the blade.  Then we unassociated it and associated it to the physical blade running the 1.1(1l) code with the same type of Emulex card.  The server booted with no issues, we confirmed all was normal and after about 30 minutes we had it back in the live cluster.

We repeated this process on 2 additional ESX hosts and now are running with 3 of the 10 ESX servers in the UCS cluster with the new firmware with no issues.  The plan is to do several more tomorrow, maybe the rest of them.  Very positive results.

Two ways to update endnode firmware (meaning the blade):

As I was reading through the “how to upgrade UCS…” release notes I recalled some early discussions when I was looking at purchasing UCS.  There are 2 ways to update the firmware on the Interface and BMC, etc.  We have been using the method of the UCSM tool to go to the physical blade and update it at this level.  The other way is via the Service Profile Host Firmware Package policy.

This makes it pretty interesting once you think about it.  Instead of thinking of firmware by hardware you think of it as the workload (Service Profile).  Lets say my W2K3 server interface can only run on 1.0(2b) firmware and I need to make sure that regardless of the physical blade it is running on that the correct firmware is there.  By using a Service Profile firmware policy you can make that happen.  So when you move the W2K3 workload from chassis 1 blade 3 to chassis 3 blade 7 the Service Profile (via the Cisco Utility OS) drops in the approved firmware version.  Pretty cool to think about.

Note there is at least one drawback to the Service Profile approach.  This firmware policy is auto updating, so if you make a change in firmware version it will automatically apply the change and restart the server. This means you have to be careful in how you use this as a means to perform the updates. (when doing firmware updates via UCSM you DO have the ability to control when you reboot the workload).

March 30, 2010 Posted by | Cisco UCS, UCS Manager | , , | Leave a comment

UCS Code Versions: How to choose . . .

Turns out Cisco released a new version of code, 1.2(1b) on 3-26-10 for supporting the new M2 blades as well as some bug fixes, etc.  We had an internal discussion today on whether or not we should stay the course with 1.1(1l) or jump up to 1.2(1b) code.  In the end we decided to stay with 1.1(1l) for 2 reasons.

1.  The 1.1 code has been revised/updated 12 times (I think that is what the L means) so my gut tells me it is stable.  The 1.2 code has probably been updated 2 times (that is why the B?).  I could be off base on this, maybe someone can comment if this is not the correct way of interpreting the numbering.

2.  Support for the M2 blade.  I expect to have some M2 blades in the environment by June/July timeframe.  By then I suspect I will want to be upgrading the code to something newer anyway, so I probably will not be saving a step.

Being the UCS product itself is new and the industry continues to move forward with new CPU, etc. I would suspect it is reasonable to plan on upgrading the firmware/code of a UCS system 2 to 4 times per year.  This would depend on your organization’s growth, but here I suspect things will continue as they have been, heavy on the growth side.  It keeps it fun.

March 30, 2010 Posted by | Cisco UCS | , | 1 Comment