Recent Cisco UCS EnhancementsPosted: June 17, 2015 Filed under: Cisco UCS | Tags: 2.2, 2.2(4), 2.2(5), cisco ucs, fabric interconnect traffic evacuation, per fabric interconnect chassis reacknowledgement, release notes, server packs, ucs, ucs server pack, ucs server packs Leave a comment
Reading the release notes is always a good idea – but boring. But I perked up today when I was perusing the latest release notes for 2.2(5) for an upcoming implementation. Here are a few items I think are mentionable. Note that all these features were released in 2.2(4).
Clearly I didn’t deploy any UCS’s around the time that 2.2(4) was released because I totally missed this feature. In the distant IT past (pre 2.1 days), both the Infrastructure and Server firmware had to be at the same level to stay in support. Then came 2.1 which introduced backward compatibility with older Server firmware. Now you’re not necessarily forced to upgrade your blade firmware at the same time as your Infrastructure firmware. Nice. Now with 2.2(4) and Server Packs, blade firmware is backward compatible with Infrastructure firmware. Even better. Of course, this comes with caveats. That being that this feature starts at 2.2(4). So at this point, only 2.2(4) and 2.2(5) support such a configuration. But this is cool. Below is the latest mixed firmware version table from the release notes.
Fabric Interconnect Traffic Evacuation
I like the UCS platform now that I’m pretty familiar with it. But it can be a beast at times. One thing that is still not as simple as it may be touted is a firmware upgrade. The process is pretty simple and well documented, but I’ve upgraded so many environments now that it seems I’ve run into many of the software bugs associated with the new or current firmware used during an upgrade. So this new feature sounds like a useful addition.
This feature allows you to evacuate all traffic from the secondary Fabric Interconnect during an upgrade to ensure OS or hypervisor networking fails over appropriately before rebooting the Fabric Interconnect.
Per Fabric Interconnect Chassis Reacknowledgement
Have you ever had to tell a client that something will need to take downtime to fix? It’s never a fun conversation to add to an already stressful environment. Chassis reacknowledgements are usually needed when troubleshooting and in the past, it meant the entire chassis would be offline during the process. No more. Since 2.2(4), you can reacknowledge a chassis one Fabric Interconnect at a time so connectivity to your blades remain across the other Fabric Interconnect.
During firmware upgrades, an automatic, internal, full state backup is created.
For a full list of recent software features of 2.2, check out the Release Notes.