HealthITGuy's Blog

The evolving world of healthcare IT!

Sharing UCS with others . . .

I have contact with several other like organizations in healthcare whom have similar growth and change occurring.  As part of an idea sharing that we do I hosted several of my peers a few weeks back to give them an overview of Cisco UCS, why we choose it, how we implemented and how we manage the environment.  From these sessions there were a few things that came up with most of the other organizations.  I thought I would share some of them.

Code Updates:  The question and concern was mentioned what happens when you have to apply new bios or code to the components of UCS, do you have to take down 8-16 servers?

The comparison of UCS to a SAN comes in handy for this question.  Currently there are 2 components on a blade that can get updates, the code on the fabric extender (the IO module inside the chassis) and the Fabric Interconnects (6120 switches running UCS Manager).

For the blade itself you can update the firmware on the IO mezzanine card which requires a reboot of that server at your selected time.  In addition, the BMC Controller has firmware that can be updated and the last update did not require a reboot.

For the fabric extender and the Fabric Interconnects the redundancy built into the system means you do not have a downtime.  Like with a SAN array upgrade you perform your upgrades on the A side, then reboot while everything is functioning on the B side.  Then perform the upgrade and reboot on the B side while everything is functioning on the A side.  I would still perform this type of activity during second shift but the system would not require a downtime.

What if a chassis fails?

When you look at the chassis, there is not any component that I could see failing that would take out 8 servers.  The fans, power supplies, blades and fabric extenders are all redundant.  Outside of those items the chassis is just a box.  I am sure there are more details to it that someone familiar with the chassis details, but I do not see it as a likely concern.

Concern that UCS is a Generation 1 Product:

My thoughts are yes it is a gen 1 system, however, not fully.

Yes, the Cisco blade server is “new”, however it is using all of the same industry standard components that other server vendor are using; same memory, CPU, etc.  For the IO cards the Cisco server is using mezzanine cards which have chips and drivers provided by Emulex and QLogic.

From the infrastructure standpoint the Fabric Interconnect is built on the Cisco Nexus 5000 platform which has been in production for at least 18 months.  The Nexus platform has been using converged networking for all of this time.

The major generation 1 component is the added functionality of the UCS Manager on the Fabric Interconnect.

So yes, it is gen 1 but it is taking what has existed and bringing it to the next level.


During one of my meetings we were talking and a peer asked his co-worker, “it is cool, but would we want to take a risk on a gen 1 product?”.  I had to jump in and answer his question as “Yes”, it was to compelling to me not to move forward with UCS.  At this point, Cisco UCS has streamlined our processes and the way we handle x86 servers that I cannot see going back.


December 31, 2009 - Posted by | Cisco UCS | ,

1 Comment »

  1. Very informative!

    Comment by Hutto | January 7, 2010 | Reply

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: