Mike Manos responded to my post about power capping being
ready for prime time with a very well thought out and argued post that really
looks at this from a datacenter manager's perspective, rather than just my
technology focused perspective.
I'm going to try and summarize some of the key issues that
he brings up and try to respond as best I can.
This one spans a number points that Mike brings up, but I think the key thing here is that you
must have a critical mass of devices in the datacenter that support power
capping otherwise there is no compelling value.
I don't believe it is necessary, however, to have 100% of devices in the
datacenter that support power capping. There
are two reasons why:
In most Enterprise datacenters the vast majority
of the power for the IT load is going to the servers. I've seen numbers around 66% servers, 22%
storage and 12% networking. This is a
limited sample so if you have other numbers let me know I would be interested.
Most of the power variation comes from the
server load. A server at full load can use 2x - 3x the power of a server at
idle. Network switch load variation is
minimal based on some quick Web research (see Extreme Networks power consumption test or Miercom power consumption testing). Storage power consumption variation also seems to
fairly light at no more than 30% more than idle. See Power Provisioning for a
Warehouse-sized Computer by Google
So if our Datacenter manager, Howard, can power cap the
servers then he's got control of the largest and most variable chunk of IT
power. Would he like to have control of
everything, absolutely yes, but being able to control the servers is more than
half of the problem.
Been there done that,
got the T-Shirt
The other thing that we get told by the many Howards that
are out there is that they're stuck.
They've been round and round the loop Mike describes and they've hit the
wall. They don't dare decrease the
budgeted power per server any more as they have to allow for the fact the
servers could spike up in load, and if that blows a breaker taking down a rack
then all hell is going to break lose.
With a server power cap in place Howard can safely drop the budgeted
power per server and fit more into his existing datacenter. Will this cost him, sure, both time to
install and configure and money for the licenses to enable the feature. But I
guarantee you that when you compare this to cost of new datacenter facilities
or leasing space in another DC this will be trivial.
I agree most datacenters are in fact heterogeneous at the
server level either; they will have a mix of server generations and
manufacturers. This again comes down to
critical mass, so what we did was enable this feature on the two of the best
selling servers of the previous generation, DL360 G5 and DL380 G5 and pretty
much all of the BladeSystem blades to help create that critical mass of servers
that are already out there, then add on with the new G6 servers. We would of course love for everyone with
other manufacturer's product to upgrade immediately to HP G6 ProLiant Servers
and Blades, but it's probably not going to happen. This will delay the point at which power
capping can be enabled and for those customers that use other vendors systems
they may not be able to enable power capping until those vendors support it.
Power Cap Management
There's a bunch of issues around power cap management that definitely
do need to get sorted out. The HP
products do come from an IT perspective and they are not the same tools that facilities
managers typically use. Clearly there
needs to be some kind convergence between these two toolsets even if it's just
the ability to transfer data between them.
Wouldn't it be great if something like the Systems Insight Manager/Insight
Power Manager combination that collects power and server data could feed into something
like say Aperture (http://www.aperture.com/)
then you'd have the same information in both sets of tools.
The other question that we have had from customers is who
owns and therefore can change the power cap on the server, the
facility/datacenter team or IT Server Admin team. This is more of a political question than
anything else, and I don't have a simple answer, but if you are really using
power caps to their full potential changing the power cap on a server is
something that both teams will need to be involved in.
I would like to know what are the other barriers you see to
implementing power capping - let me know in the comments and be assured that
your feedback is going into the development teams.
Just to make Mike happy I thought I'd let you know that we
do have SNMP access to the enclosure power consumption.
If you collect all six SNMP MIB power supply current output
power values and add them together, you will have calculated the Enclosure
In the CPQRACK.MIB file, which you can get from here http://h20000.www2.hp.com/bizsupport/TechSupport/SoftwareDescription.jsp?swItem=MTX-a7f532d82b3847188d6a7fc60b&lang=en&cc=us&mode=3&
There are some values
cpqRackPowerSupplyCurPwrOutput which is MIB item:
enterprises.184.108.40.206.220.127.116.11.1 through enterprises.18.104.22.168.22.214.171.124.6
gives you the Input Power of each Power Supply, I know the MIB name says output
but it's actually input - sum these together then you have the Enclosure Input Power.
Power supplies placed in standby for Dynamic Power Savings
will be reporting 0 watts.
And for enclosure ambient temp - read:
We've been on the Adaptive Infrastructure journey at HP for several years now. This week we are announcing an important milestone: BladeSystem Matrix. We've been really thinking a lot about how customers use IT and ways we can optimize IT infrastructure to make it work better for them. We recognize that infrastructure exists for applications, which exist for the business. So we've taken a business and application perspective on how an infrastructure ought to operate.
Deploying an application typically requires an IT architect or team of architects to carefully design the entire infrastructure - servers, storage, network, virtual machines - and then hand off the design to a team of people to deploy, which typically takes several weeks. This length of time is mostly an artifact of the way IT infrastructure is designed. So we decided to change this with BladeSystem Matrix. Now an architectural design is saved out as a template - servers, storage, virtual machines, network, server software image. Then when it is time to provision an application, it's as easy as saying "make it so" - and in a matter of minutes, the Matrix's converged virtualized infrastructure is automatically configured and the application is ready to run. In other words, the way it ought to be.
BladeSystem Matrix is the culmination of several years work at HP - creating an Adaptive Infrastructure that is simpler to buy, deploy and keep running optimally. Applications are easier to provision, maintain, and migrate. We've spent years proving out this architecture, not just in our labs but in real-world environments, with BladeSystem, Virtual Connect, and Insight Software - so we could learn how IT really operates - and more importantly - how it ought to operate.
Some people tell me Matrix's virtualization sounds sort of like a mainframe. Others say that the portal interface reminds them of cloud IT. I guess in a way they are all correct. But unlike those environments, Matrix will run off-the-shelf x86 applications. So I guess I've decided that Matrix is it's own thing.
Every time a competitor introduces a new product, we can't help but notice they suddenly get very interested in what HP is blogging during the weeks prior to their announcement. Then when the competitor announces, the story is very self-congratulatory "we've figured out what the problem is with existing server and blade architectures". The implication being that blades volume adoption is somehow being constrained by the very thing they have and everyone else is really stupid.
HP BladeSystem growth has hardly been constrained; with quarterly growth rates of 60% or 80% and over a million BladeSystem servers sold. So I have to wonder if maybe we already have figured out what many customers want - save time, power, and money in an integrated infrastructure that is easy to use, simple to implement changes, and can run nearly any workload.
Someone asked me today "will your strategy change?" I guess given the success we've had, we'll keep focusing on the big problems of customers - time, cost, change and energy. It sounds boring, it doesn't get a lot of buzz and twitter traffic, but it's why customers are moving to blade architectures.
Our platform was built and proven in a step-by-step approach: BladeSystem c-Class, Thermal Logic, Virtual Connect, Insight Dynamics, etc. Rather than proclaim at each step that we've solved all the industry's problems or have sparked a social movement in computing; we'll continue to focus on doing our job to provide solutions that simply work for customers and tackle their biggest business and data center issues.
Dynamic Power Capping
x86 server market
Nine months ago, I started to build a house. This week was all about tying up loose ends. We're only days away from moving in. One such loose end was the mystery of the missing faucet. It was a cool bronze faucet I picked up on eBay for a song. Forgotten in my trunk, I never gave it to the plumber.
As the plumber came today to install it, he handed me a change order for $175 - something about the valve and trim weren't compatible!?! The faucet was in and the plumber was out in five minutes flat. He also warned me not to cry to him if it breaks. Sigh.
I'm really glad my plumber didn't build my house.
The house budget would have come in just shy of a one billion dollars. I promise you, on a per hour basis, my plumber walked away with 10x more profit than my builder.
Faucets would have been the focal point of every room. I even suspect the pipes would be outside of the walls.
All pipes and faucets would be made of 24k gold. The rest of the house, crape paper.
If you want to build a house, hire a custom builder. They can see your vision. They grasp the big picture and they know how to bring the pieces together. Most importantly, they know how to execute it. Custom builders also know your budget and they don't get paid if they bust it.
That brings me to this article today from Lippis group. The title is "Are Cisco, HP and IBM on Data Center Collision Course?" It's clear to me that Cisco is taking a plumbers' view to the next generation datacenter. Or a "packet plumber" view if you will.
This article does a great job of posing some interesting questions of Cisco while clearly drawing the lines between different approaches already being executed in the market, i.e. Adaptive Infrastructure. James Staten at Forrester echoed some of these sentiments in a recent post as well.
Here are some of the quotes and questions that popped out to me:
"Cisco’s Data Center 3.0 initiative is its vision to orchestrate virtual IT." - What data center is virtual only? Convergence is needed in the data center - not divergence. Virtual and physcial can not be addressed separately with different tools, processes, etc. There needs to be a master plan for physical and virtual to minimize the proliferation of different tools, control conflicts and poorly managed processes.
"Its products include the Nexus family of data center switches including the Nexus 7000, a high-density 10Gbs Ethernet core switch; Nexus 5000 . . . " followed by "Cisco Nexus family provides customers with a granular path to add capacity and capabilities to the data center network while allowing customers to have the ability to leverage their existing and continued investment in Catalyst." The granular path is a little unclear here for Catalyst and IOS folks. Exactly how does Cisco's vision include the millions of Catalyst and IOS products out there?
"But here’s the rub: business models." Quite a rub indeed. HP has a proven history of driving out cost across the data center. Possibly the only player in that can do it on all four axis in the data center - compute, storage, networking, and facilities. Will Cisco drive down network costs the way HP has driven down compute and facilities costs? We think it takes a lot more effort than addressing FCoE to get there.
The final assertion I saw was that Cisco thinks that "HP and IBM will be painted as legacy data center players." I guess I'm okay with that as our legacy.
HP knows data centers. Cisco knows networks. Which one do you want to build your house?