Wednesday, October 13, 2010

Am I Cheating on PUE or DCiE?

In a parallel blog, we've been discussing the death of the modern data center. It's not as dire or alarmist as it sounds - merely the realization that data centers are evolving as both real estate-based solutions outside the enterprise and the use of cloud computing for social media, entertainment and now more traditional corporate computing functions. In many ways, we're returning to the days where the MEP infrastructure is specifically engineered to the computing systems they support. For you old fogies out there (like me, even at 47), chilled water's making a comeback as well. We're not just dumping capacity into a white space anymore.

Recently, I was reviewing an article in ENR stating that a data center achieved a PUE of 1.08. I will say that I found the figure a bit hard to believe. Where we found fault with the statement was that it was:

  • Not backed by environmental data.
  • Did not appear to be normalized over an annualized basis, since the facility has been open less than one year.
  • Not offered out of context to the entire data center population.
  • Does not mention that it uses a significant amount of server fan power to achieve this figure.

It doesn't mean the figure was misstated, just taken out of context.

When viewing some of the home run PUE's of the past couple of years, sites located in areas known for beneficial cooling (like the use of very cold outside air, just off the North or Baltic Sea) were leveled to sites in the US with some explanation. We're not contending the 1.08 was hokey, just that when compared to a site in Phoenix, Dallas or Northern Virginia, clear disclosure is necessary. It also doesn't state if there was a reduction of the kW's consumed - just that the ratio is lower. What you should care about in PUE is the reduction in overall power consumption or an increase in MIPS/W or whatever power-to-IT metric you happen to fancy.

I will also say that the current PUE and DCiE standard is pretty generic. The new ANSI/BICSI Data Center Standard 002 speaks specifically to annualized data, where all four seasons must be considered. The PUE and DCiE figures don't recognize server fan power in the equation. Nor do we expect that to change in the near future.

Here are some areas that we're finding suppress PUE values:
  • Environmental data for the PUE calculation is not taken on either the winter or summer design days. Per the new ANSI/BICSI Data Center Standard 002, PUE must be examined with design day enviromentals.
  • Many users are now using server fans as part of the ventilation chain in a more formalized way. While this has been the case with forced ventilation cabinets for years, users like Facebook, Google and Yahoo will actually design the server fan into the supply and return air chain. What happens is the server fan power is counted with the IT load and not the supporting load. Fair game, but you'll see a PUE as much as 25 - 30 basis points lower than a system that uses more traditional air handling system where the server fans are not engineered into ventilation chain.

Make sure that PUE and DCiE consider the server fan contribution where used when comparing them to facilities that don't employ or consider the server fan power as part of the formal HVAC system.

How Did the Data Center Come Down With a Fatal Disease?

Many of us in the industry have discussed why data centers of the past are changing. I contend that it's not an unanticipated shift, but merely a return to either a generic or highly bespoke solution for a mainfame computing environment. And if you ever worked in a Cray shop, you know how specific the solutions were for that superb platform.

For a minute, let's take a quick review of where we've been. In the 1980's (and yes, I'm that old, been in the MC business that long and I recall chilled water and 415 Hz), data center infrastructure suited a homogeneous platform, in this case the ubiquitous mainframe. With the rise of the microserver, and its 60Hz power and air cooling, the infrastructure of the data center evolved. Remember, there was no hosting or managed service business back in those days (except for TymeNet, run by Tom O'Rourke, the father of one of my best friends from Santa Clara). So, in the 1980's early 1990's, you had a single path data center that served a specific platform.

With the rise of the server farm, we began to see an increase in real-time computing operations. With that came the rise of fault-tolerant MEP systems that had to address a more heterogeneous series of platforms in the compute, storage, server and network activities of the enterprise. Simultaneously, power densities were increasing rapidly. This has been the habit of the industry from the mid 1990's to the mid 2000's. While there was certainly facility solutions specific to a user's computing needs, most solutions simply delivered a specific Tier or Class solution at a given power density (rendered in W/sf).

During the mid 2000's, higher density systems, starting with blade-based systems forced a reversal of evenly spreading capacity throughout the data center to serving the higher density systems with specific power, cooling and racking solutions. Much of what we've seen during this time has been systems-based work outside of the cloud. Most, if not all of our facility solutions, have been addressing the exceptions to the "evenly spread" capacity versus any form of true reengineering of the ENTIRE process. Containerized computing and infrastructure solutions are a step toward solving this challenge.

Here it is. What is causing the death of the modern data center is the split realities of users seeking a real estate based solution to their data center needs and the emergence of cloud computing or specific hardware solutions massively deployed across the enterprise. One of these realities transfers the physical asset to outside the enterprise. The other reality, if properly executed, has and will yield signficant efficiencies in power consumption and computing throughput when examining W/MIP of your computing systems.