As I’m sure most of you already know, Cisco has released an anticipated update to the firmware for UCS. Of the dozens of enhancements that were added or modified, perhaps one of the most interesting is Cisco’s integration of their rack-based “C-Series” line into the UCS Platform. This provides users with a single interface to manage both their rack and their blade server platforms. Instead of re-creating the wheel, I encourage you take a few minutes to read up on all the goodness from M. Sean McGee’s site at http://www.mseanmcgee.com/2010/12/cisco%e2%80%99s-stocking-stuffer-for-ucs-customers-firmware-release-1-41/
hp warranty check
groupon las vegas
gold price history
dallas mavericks schedule
art of war quotes
Kudos on integrating rack servers into UCSM; great improvement.
The power capping of this firmware set release (the 15th of 2010?) interest me most.
I can’t tell from public docs how UCS implements capping. I believe at the server level it’s via BIOS or OS-based processor frequency control. That’s fine for capping average energy consumption — “capping the power bill” — but it’s generally not fast or reliable enough to protect short-term spikes that trip circuits. Hopefully a UCS expert can answer.
I like the idea of power “priority”, but I’d like to hear more use case examples. If you’re running VMWare on Server A, with a Service Profile with a high power priority, then any VM moved by vSphere between Server A and Server B will have its power priority changed, right? You could wind up throttling a high-priority VM.
A better scheme would be assigning power priority to the application level. The tool that assigns power should have awareness of both hypervisor and hardware, so it can predict the power that would be consumed by a workload when placed in any arbitrary HW/SW config. It would also Interface with DCIM tools, so it knew what circuits could actually support.
Pingback: Kevin Houston
Nice update.
sean mentions that you can now manage up to 20 chassis/160 servers in a single UCS manager instance. thought cisco had always talked about being able to manage 320 servers/40 chassis in UCS manager when they launched the product. seems strange they are now talking about this upgrade getting them to 160 servers
mike
Hi Dan
Implemented in the management processor on the Blade, the CIMC, and can cap a blade in about 500ms.
There are a couple of other timings associated with the power capping in UCS. One is the time a blade must be at it’s cap before causing a power re-balance within the chassis, where idle blades can have their caps lowered and active blades can have their caps raised, that currently is 20 seconds. I know the White Paper on Cisco.com is unclear on this and I’m trying to get it fixed at the moment, not sure when it will get published.
Priorities really provide a building block. UCS provides the hooks via the XML interface to discover which blades have a higher priority, current state, as well as the various environmental factors that might be of interest to a power management app that could then intelligently place application or VM loads based on wider datacenter factors.
Disclosure: I work for Cisco.
Tony Harvey
Pingback: Kevin Houston