Data Center Strategies

When All You Have is Hammer…

Everything looks like a nail, a truism that ASHRAE (The American Society of Heating, Refrigerating and Air-Conditioning Engineers) has just demonstrated in its advice to data center operators on how to achieve greater cooling efficiency in the data center (see ASHRAE Standard 90.1). In ASHRAE’s opinion, the way to achieve data center cooling efficiency is through the use of various economizer techniques (air-side, water-side …) to reduce the amount of energy used by the cooling plant. Unfortunately, this is a rather narrow view of the problem, focused on the stuff that ASHRAE members do best, i.e. air-conditioning and chilled water plants. The ASHRAE standard has now drawn a universal thumbs down from some of the largest data center operators (Google, Microsoft, Amazon, Digital Realty Trust, DuPont Fabros Technology and Nokia) who issued a joint statement urging ASHRAE to re-think it’s position.

The truth is that economizer are just one approach to achieving more efficient energy usage and the best approach will vary based on a host of factors. For example, one company might favor widespread adoption of server virtualization as a way to reduce energy consumption, while another might be able to scavenge energy from the waste heat produced by the data center and use it heat buildings. Both approaches lead to more efficient use of energy without requiring the use of economizers. The problem with ASHRAE’s approach is that there is a danger it will get built into building construction codes and potentially restrict innovation in the data center. James Hamilton’s blog entry on the subject (see here) does an excellent job of describing the problems of such a restrictive definition.

Posted by: Nik Simpson

Intel Takes the Wraps off Its Spring Collection

This morning Intel announced the first of its 2010 line of server processors, the Xeon 5600 family. The Xeon 5600 processors are a development of last year’s Xeon 5500, with several key differences:

• Manufactured on a 32nm process versus last years 45nm process
• Up to six cores and 12 MB of cache on each processor (50% greater than the Xeon 5500 family)
• Extended instruction set with new instructions to support AES-based cryptographic algorithms in hardware
• Reduced power consumption due to the ability to power down more unused areas of the processor

So far, the only performance numbers available are from the Intel press release and website, so we’ll have to see what the vendors announce. However, just the numbers released by Intel are pretty impressive, particularly on the VMmark benchmark where they cite a Cisco UCS B250M2 blade that reached 35.83 @ 26 tiles. To put that in perspective, compare the Xeon 5600 with it’s immediate predecessors the 5500 and 5400 families (results separated by 15 months):

CPU	VMmark	Power Envelope
Xeon X5470 3.33 GHz (4 cores/CPU)	9.15 @ 7 tiles	120 Watts
Xeon X5570 2.93 GHz (4 cores/CPU)	25.06 @ 17 tiles	95 Watts
Xeon X5680 3.33 GHz (6 cores/CPU)	35.83 @ 26 tiles	130 Watts

So in little more than a year, the performance of 2-socket Intel servers have increased by almost 4x! But it’s about more than just performance, many are now focusing on performance/watt and the improvements there are equally compelling. The following table compares estimated power costs for a sixteen server virtualization cluster built in 2008 versus a four server cluster using the latest Xeon X5680, assuming that the average power consumption is 400 Watts/server.

	Annual kW-hours	Power @ $0.1/kW-hour
16 servers @ 400 W	56,064	$5,604
4 servers @ 400 W	14,016	$1,401

Add on savings for cooling and the new servers would save in the order of $25,000 over three years just on the power bill. Add in reduced spending on hypervisor licensing etc, and the business case for replacing even relatively modern servers is pretty good. The case for replacing older servers is even more compelling. Assume each of the new servers can host virtual machine workloads equivalent to fifteen aging physical servers, so four servers can replace 60 physical servers:

	Annual kw-hours	Power @ $0.1/kW-hour
60 servers @ 400 W	210,240	$21,024
4 servers @ 400 W	14,016	$1,401

Add on savings for cooling and the new servers would save ~$120K over 3-years, more than enough to pay for themselves.

Posted by: Nik Simpson

Which Reminds Me…

I was just reading an article about IT’s desire to better understand costs (see here). The article reminded me that back in July, I posted (here) an invitation to a survey that Burton Group was conducting as part of my ongoing research on data center cost models. At the time I promised to share some of the results on the blog. Before I go into the details of the survey I’d like to link to some additional information that may be helpful.

1. If you are Burton Group customer, you can download “Counting the Cost of the Elephant in the Data Center”  which contains a more detailed look at cost modeling and also includes a sample spreadsheet that can be used a starting point for looking at infrastructure costs (i.e. what does it cost each year to run a server).
2. There is a recording of my 1/2 day workshop on data center economics from Catalyst 2009 which is available to anybody with a browser. In the interests of full disclosure, this is $199 to purchase.

And while I’ve got your attention, if anybody is interested in talking to me about data center cost models and how they are used in your business, please get in touch via email to nsimpson@burtongroup.com.

Anyway, on the results of the survey…

The 80+ respondents to the study were well distributed across industry segments and company size:

• Participants in all major IT sectors including; education, government, pharmaceuticals, aerospace, energy and consulting.

• Companies ranging in size from less than $50 million to greater than $10 billion in annual revenues.

Out of all the companies surveyed, less than 25% had a comprehensive model for their data center costs. A similar number had no cost model of any kind. The rest of the companies surveyed had some form of cost model that was limited in scope and application.

Of the companies that did not maintain a cost model or only maintained a limited model, the key problems were either lack of motivation (i.e. costs are not a major part of the decision making process) or difficulty in collecting the necessary information because of it’s spread across multiple fiefdoms within the organization (i.e. facilities, purchasing, human resources, etc.)

As to the contents of the data center cost model, at least 25% of those using a cost model did not include any information about power, cooling, or facilities costs. This represents a serious shortcoming as these costs are a significant part of the overall IT costs.

Another point that emerged is that the old idea that a data center should be expected to last twenty years is no longer valid. Of the survey respondents, more than 85% had built or upgraded a data center since the year 2000, with 45% having done the work in the last year to 18 months. Yet 65% of the respondents expect to outgrow their current facility within five years. The major factors dictating data center life were limits on floor space and power distribution, with cooling coming in a distant third.

The biggest gap in terms of data required for a data center cost model was in the area of power. Only about 25% of respondents could track power consumption down to the individual piece of IT equipment, rest had varying levels of insight into their power usage. Interestingly this 25% figure was mirrored almost perfectly by the number of respondents who had calculated PUE for their data center.

Another weakness common to the majority of respondents was the availability of detailed purchase price information for equipment in the data center. Roughly 20% of respondents had the purchase price information in the corresponding Configuration and Management Database (CMDB) entry for the equipment. Another 23% had a spreadsheet that has to be maintained by somebody in the IT organization. But over 50% of respondents would have to track down the information from other sources in the company such as a purchasing department.

Overall, the survey indicated that many IT organizations are not in a position to fully understand the costs of running their data center. The lack of a complete understanding of data center costs creates a potentially dangerous hole in the IT decision making process, especially because IT decisions are increasingly cost driven.

Posted by: Nik Simpson

ASHRAE says “turn it up”

I’ve just finished writing a report on data center cooling (which should be published later in the quarter), and one of the recommendations was that data center operators should set the temperature to at least 77^F (25^C), per the recommendations of the American Society of Heating, Refrigerating and Air-Conditioning Engineers (ASHRAE), as a way to reduce energy consumption in the data center. So I was interested to note that ASHRAE has just changed that recommendation to 80.6^F (27^C) measured at the inlet of the equipment in the rack (coverage here, here, and here).

But before you go and adjust the thermostat in your data center, there are a number of potential impacts that need to be understood:

• Fans in equipment in the racks will have to work harder to keep the equipment temperature in range, so they will be noisier. More importantly, more active fans in equipment will move some of the power load from the HVAC equipment to the data center power distribution network. That’s fine if you have ample headroom in power delivery to the racks, but if you are operating at the edge with respect to power delivery then you might start tripping power breakers.
  
• The hot-aisle will get hotter. If you assume that the temperature difference between the hot- and cold-aisle is 55^F (13^C), then hot-aisle is going to be a toasty 135^F (57^C), not what you would a call a pleasant working environment if you have to work at the back of an equipment rack.
  
• The recommendation is for inlet temperatures of IT equipment, and these will vary depending on where the equipment is located in the rack. So wandering around the cold-aisle with a thermometer isn’t good enough, you need to place several temperature sensors into the racks to get an understanding of the temperature gradient from bottom to the top of the rack.
  
• Increasing data center temperatures will allow for a more humid environment which may lead to water condensing in the computer room air conditioners, reducing their efficiency.

Perhaps the most important concern for IT  will be the perception that hotter equipment fails more frequently than cooler equipment. On the surface, this is correct, if you let equipment overheat, then it’s more likely to fail. But the ASHRAE recommendation isn’t intended to make the equipment run hotter. The increase in cold-aisle temperature will be counteracted by the fans in the equipment so there should be no net increase in the internal temperature.

But the question you have to ask at the end of the day is how much difference will this make to overall data center energy consumption? The answer to that question depends on what you’re current operating temperatures is. For example if you are at the old ASHRAE recommendation of ~77^F (25^C) then the answer is “not much”. But if you are operating at temperatures substantially below the new recommendation (which is surprisingly common) then you really need to take a hard look at how you operate your data center, because modern IT equipment is much more tolerant of high temperatures than we give it credit for. Consider the following table which lists the operating temperature range for a sample of common IT equipment:

Device	Temperature range
Dell PowerEdge r805	50F-95F (10C-35C)
Cisco Nexus 5000	32F-104F (0C-40C)
Sun SPARC Enterprise M9000	41F-89.6F (5C-32C)
NetApp FAS 6000	50F-104F (10C-40C)

Add the fact that mean time between failure (MTBF) numbers are calculated at the high end of the range (i.e. 95^F or 35^C for the PowerEdge r805) and it’s clear that 80^F isn't extreme as far as the equipment is concerned

Posted by: Nik Simpson

Putting Your Data Center on a Diet

So Christmas is over and we are all looking somewhat ruefully at our waist lines and hoping to get back in shape before the summer rolls around. Data center operators have another problem, how to cut some of the fat out of their data centers and get their energy budget in shape for the new year. Just this week I was asked the question “How can I trim a million KW-hours energy consumption this year?” That sounds like a daunting, but worthy exercise, a million KW-hours sounds like a huge number, but at 8-cents a kilowatt-hour trimming 1 million kilowatt-hours would save $80,000 dollars in the first year (of course, price/KW-hour varies considerably by location, so your mileage may vary.)

The first point to note is that while the number seems huge, that simply reflects the size of the customer’s data center, the real question is “what changes will have the most impact on energy consumption?” So here’s some tips on how you can reduce energy consumption in the data center:

1. Reduce the amount of equipment in use: The quickest way to significant savings is to cut back the amount of equipment in use through technologies such as server virtualization. Let's assume that 1/3rd of the servers in a data center are suitable candidates for virtualization and that on average a 5:1 consolidation ratio is possible (and that’s a conservative estimate for the consolidation ratio.) A datacenter with a thousand servers would be able to virtualize 333 of them, replacing those 333 physical servers with just 67, a net reduction of  266 physical servers. Now lets assume that these original servers were 1U pizza-box servers each consuming 300 watts of power, and that the new servers are bigger (to accommodate the extra memory, processors etc) and consume 600 watts of power, the net power saving is almost 60 kilowatts. Such an approach would also reduce power consumption for cooling by a similar margin (assuming 1:1: ratio between power consumed by equipment and power consumed by cooling.) This step alone would save a million KW-hours, throw in some improved storage management practices and deduplication for data and the energy savings quickly pile up.
2. Get rid of old equipment: Some data centers continue to use equipment until it finally dies, that can mean servers that are 5 or even 10 years old (I've seen even worse cases). These servers are energy and space hogs and deliver very little work for the power consumed compared to a more modern system, especially if the more modern system is combined with server virtualization. 
3. Improve power distribution: This can take the form of a number of improvements and upgrades. For example old UPS equipment is substantially less efficient (i.e. wastes more energy) than modern UPS systems, replacing the old UPS could yield a 5-10% reduction in energy consumption. Also minimize the number of voltage conversions between the power as delivered by the utility and the power consumed by the equipment, i.e. bring high-voltage power as close to the racks as possible.  Data centers in the US still using 120V AC to power equipment in the racks, need to take a long hard look at switching to 240V AC, the equipment doesn’t care and it will save energy and simplify the wiring.
4. Cooling improvements: Air-side economizers can deliver big savings, especially in more temperate climates. Assume roughly half the energy consumed by the data center is used for cooling, and that the airside economizer can function for half the year, then potential savings in energy consumption are pretty obvious. Also improve hot-aisle/cold aisle separation or implement fully ducted hot-air removal from racks can increase cooling efficiency inside the data center.

The big lesson here is that the quickest payback for reducing energy consumption is to reduce the amount of equipment in the data center and opportunity presented by maturing server virtualization technology is too good to pass up! The downside is that to save money in the long term, you’ll have to spend some money in the short term.

Posted by: Nik Simpson

Not Your Father's Data Center

When you decide to build a data center that holds 500,000+ servers and consume 120 MW of power it makes sense to think really hard about what that data center should look like. Do you take a conventional design and simply scale it up, i.e. a big empty box of a building filled with rows of racks that seem “to stretch out to the crack of doom”? Or do you start from first principles and question almost every piece of conventional wisdom about data center design including power distribution, cooling, and availability?

Interestingly, Microsoft chose the latter approach, and in the process, they have created their Generation 4 Modular Data Centers (I’ll call them G4M for short) which look nothing like a conventional data center. The details of their G4M Data Centers were publicized this week in a very interesting blog posting from Mike Manos at Microsoft. The key aspect of G4M data center is that it is completely containerized, not just the servers but everything, power, cooling etc all come in pre-built standard container configurations. The containers are deployed in the open air (think “trailer park” data center) and new modules can be added rapidly to meet demand. Different configurations of containers can be used to deal with different availability requirements ranging from very low (relying on air cooling and no redundant power) all the way to full “tier IV” availability with redundant everything. Just to give you an idea of how different this data center looks, here’s one of the graphics from the blog entry…

So in parting, if you are at all interested in the future of data center design, go read the blog!

 

--

Posted by: Nik Simpson

Distributed Power Management: Improved Efficiency or Playing with Fire?

I've been traveling quite a bit lately, so it's been hard to keep up with the blogs that I normally frequent. Today I played catch-up with Mike Dipetrillo's blog, which contained an interesting post on VMware's Distributed Power Management (DPM), an "experimental" feature in VMware's VI 3.5 software. This is an interesting concept, and one that competitors such as Virtual Iron offer as well. While such features make for a nice story and blog post, I have to question how relevant they are to the typical enterprise. Don't get me wrong. Power management is critical and the virtualization platform vendors will have to play a role in adding power management to the hypervisor; however, I'm not convinced that fully shutting down physical hosts is the solution. Sure the mobility offered by virtualization mitigates the risk associated with component failure that may result from frequent power cycles - if one physical host doesn't come up, the VMs can run on the remaining nodes in the cluster. But is the approach offered by DPM a pill most enterprises are ready to swallow?

This year alone, I have asked hundreds of IT folks about power management and I can count on one hand those that would allow software to dynamically shut down and power up their production systems. Why? Practically every one of them has cold booted a server and had it not come back up. So the idea of scheduling such an activity to occur daily scares the (insert your favorite adjective here) out of them. Driven by these concerns, Burton Group approached every major server independent hardware vendor (IHV) this year and asked them if they had conducted any testing on the impact of distributed power management (shutting down servers nightly) and mean time between failure (MTBF). Across the board, the answer was "No."

Some IHVs aren't too interested in even testing such a scenario because they don't think it will ever fly in most enterprises. Instead, they feel that adding more power management features (e.g. powering down unneeded CPUs, memory, or PCI devices) to their server platforms is the right path to take. Of course, this means that the hypervisor vendors will need to update their software to take advantage of such features. Also, the IHVs will still need to conduct MTBF testing to ensure that any new power management features do not significantly degrade MTBF. As embedded hypervisors (e.g. ESXi, XenServer OEM) continue to evolve, we'll hit a time where physical drives are no longer needed in servers. Instead, the hypervisor will simply load from flash. Getting the hard disk out of the server will improve power efficiency, but we also need better power management between the hypervisor and server too.

Microsoft has already announced that advanced power management will be included in the Hyper-V update coming in Windows Server 2008 R2. VMware, Citrix, and Virtual Iron (among others) will need to follow a similar path. Until we have advanced power management in the server and hypervisor, and have MTBF tests that allow enterprises to adopt such features with confidence, let's hold off on propping up science projects features like DPM. Using such features in development, test, or training environments may make sense if you feel the good (improved energy efficiency) outweighs the bad (reduced server or component life). In production environments, stay away from features such as DPM until your preferred IHV will stand behind a particular power management solution, and has the test data to back it up.

Posted by: Chris Wolf

Catalyst Day 2 Virtualization Highlights

The second day of virtualization coverage at Catalyst focused on virtualization as an enabler to workload mobility and orchestration, as well as standards-based management for the virtual data center.

For me, the highlight of the day was the DMTF unveiling the public release of the Open Virtualization Format (OVF) standard as a work in progress. In addition to the OVF announcement, DMTF president Winston Bumpus also announced the launch of the Virtualization Management subcommittee. Winston also announced that live demos of vendor OVF integration would be shown at Catalyst for the first time publicly. In terms of the best integration that you can use right now, Novell and VMware are at the top of the list. Novell is currently leveraging OVF in their ZENworks Orchestrator management suite, and VMware has supported using OVF to import VM appliances into Virtual Center since the end of last year. OVF is an XML-based virtualization metadata format and is fully extensible. All vendors that are contributing to OVF have very large long term plans for the spec. Look for OVF to start its transition from a standardized metadata format for importing VM appliances to the industry standard format for VM runtime metadata. There's no technical reason why this cannot happen, so to me runtime metadata seems like OVF's next step in its logical evolution. So it's foreseeable that proprietary VM metadata file formats such as .vmc (Microsoft) and .vmx (VMware) could be replaced with a .ovf file. The fact that OVF is extensible means that vendors can leverage OVF to define custom components of their virtualization stack. So even as virtualization architectures evolve, OVF has been designed to evolve with them.

Neither Citrix nor Microsoft had an OVF implementation at the show that is usable today. Instead, Citrix had developed a tool solely for the purpose of providing a demo, and expects its OVF implementation to be shipping early next year. While I would have liked to have seen more from Microsoft and Citrix, final work on the OVF standard is just wrapping up. So once the standard is ratified I expect all vendors to step up efforts to further support OVF. While there wasn't a shipping OVF solution for Citrix XenServer or Microsoft Hyper-V at the show, Citrix previewed an internal tool that facilitates Hyper-V to XenServer migrations, and vice-versa. With the tool, I could create a VM on Citrix XenServer, migrate it to Hyper-V and boot it up (the reverse process works too). All that's required is that you preload the paravirtualized device drivers for each hypervisor in the VM's guest OS once it's created. When the VM boots, Windows plug-and-play would load the appropriate drivers for the underlying hypervisor and the VM would be good-to-go. To Microsoft and Citrix's credit, they were the only vendors that were showing how to use OVF to facilitate hypervisor interoperability at the live demo. Still, with the spec nearly complete, it's time to see real implementations and not just a demo specifically prepared for Catalyst. Microsoft missed an opportunity to support OVF in System Center Virtual Machine Manager 2008 (it's still beta, but it's too far down the development path to add new features).

VMware CTO Steve Herrod offered an insightful glimpse of OVF's evolution and its future role in virtualization management. Key points highlighted in Herrod's session included:   

• OVF's initial implementation is as a distribution format for virtual machines
   
• Packaging and deploying VMs via OVF includes several advantages:      
        
  • Validation         
              
    • Verify licensing, security, integrity
                
    • Resource requirements and placement
                
    • Application Properties (IP addresses and passwords)
         
  • Conversion         
              
    • Convert virtual disks to run-time format
             
  • Installation         
              
    • Provide runtime environment for application (customization and localization)
                
    • Provide installation feedback to user
 
• Several VMs that are part of an OVF package can be instantiated as a single service object in the virtual infrastructure inventory
   
• OVF helps the industry deliver vendor-independent VMs that are easier to deliver and deploy

I presented a session on VM Mobility and Orchestration, with much of the focus on today's barriers to mobility. Those include:

• Live migration remains unavailable on several platforms (e.g., Hyper-V, Solaris Containers)
   
• Outside of VMware's DRS, dynamic VM load balancing technology is still maturing. Microsoft System Center Virtual Machine Manager Performance Resource Optimization (PRO) and Platform Computing's VM Orchestrator (VMO) are examples of further innovation in this space. Orchestration products from vendors such as Computer Associates and Novell are also providing innovative methods for automating VM relocation in response to changes in workload demands.
   
• Dynamic VM load balancing is going to transition from a reactive technology to a proactive technology, with vendors such as CiRBA providing intelligence to top level orchestrators to migrate VMs in anticipation of expected workload peaks based on historical workload performance patterns
   
• There's no technical reason why vendors cannot agree on a standardized virtual hard disk format. Such a format, in my opinion, would ease third party vendor integration and deployment of virtual appliances. Also, this standard format could include embedded checksums and tokening information that cause the disk to be authorized before it is mounted. This would provide a safeguard against theft of a virtual disk file.
   
• Differences in hardware-assisted virtualization remain a mobility barrier, forcing organizations to standardize physical clusters on AMD or Intel hardware.
   
• Several management issues, such as SLA assurance and compliance are difficult to effectively audit in virtualized environments.
   
• Improvements need to be made in physical server power management before running servers in a suspend state or at a reduced power mode will be an option. Ideally, organizations would like to run servers at a reduced power state as workload needs dictate in order to save on power and cooling costs.

That's it for Catalyst North America 2008's virtualization highlights. I hope to see some of you at Catalyst Europe in the October.

Posted by: Chris Wolf

Is There Any Hope for Benchmarks? (part 1)

As long as I've been in this industry, vendors have been using (and misusing) benchmarks as marketing tool (shaped like a big club for beating competitors over the head with). These benchmarks typically fall into three categories:

1. Barely useful - these are the application benchmarks such as those created by the Transaction Processing Performance Council (TPPC) which make a genuine effort to model a real workload and to police the whole benchmark process so that vendors can't play games with pricing or take short cuts on configurations to inflate their numbers or reduce their overall price. There main problem here is that if there is no benchmark that comes close to modeling your workload, then throwing darts at a board is likely to be as effective as reviewing benchmark data when trying to select the best solution for your needs. Workstation buyers are better serviced here with real application benchmarks such as SPECapcSM for Solid Edge V19™.
2. Largely academic interest - these are benchmarks of a single aspect of a system, such as the Systems Performance Evaluation Council's (SPEC) benchmark - SPEC CPU 2006. For the most part these benchmarks are very hard to interpret when trying to decide which system gives the best bang for the buck on your specific application, unless you know a lot about the type of compute load your application generates and where its performance bottlenecks lie.
3. Benchmarketing - these are the internal benchmarks done by the vendors where the primary purpose is macho displays of "chest thumping" at the expense of another vendor. You know what I'm talking about here, benchmark reports done by the vendor or by an "independent body" hired by the vendor (no problem with impartiality there) often using a workload cooked up by the vendor specifically to make their system look good against their competition.

I get particularly annoyed when there is a useful industry standard benchmark that is largely ignored. For example, you can't throw a rock these days without hitting some vendor telling you how energy efficient their blade systems are, yet there is not a single blade system with published results for the SPECpower benchmark. Granted the benchmark has not been out that long, but even so, IBM, DELL, and HP have taken the time to publish results for some of their rack mount servers, but their blade platforms are all missing in action. So instead of having comparable, independently verified numbers for power consumption all we get is self-serving proclamations from the vendors about how their secret power saving sauce is more effective than the other guys stuff; conclusions based on their entirely independent internal benchmark of course.

The major benchmarking authorities; TPPC and SPEC deserve some credit for producing benchmarks that have been widely published over the years, for example SPEC's sfs97 file server benchmark has become the de-facto performance benchmark for network attached storage, unfortunately it only covers NFS performance. Meanwhile, TPPC (and the Storage Performance Council) deserve credit for insisting on pricing information as part of the benchmark (a feature sadly lacking in SPEC's benchmarks) which allows customers to make judgements about price/performance.

To be fair to vendors, apart from their use in marketing (which has a questionable return on investment) putting any sort of monetary figure on the value of performing benchmarks is very hard to do. It's rare that customers demand industry standard benchmark results as part of a request for proposal, so not doing them doesn't impact business much if at all. Given that fact, it's hard to make a case for vendors to spend time and money on benchmarks, especially the bigger more complex benchmarks which take real expertise and a boatload of hardware to run. To get an idea of the cost of running a major benchmark, take a look at the top x86 TPC/C results from vendors like HP. Their most recent result used $465K worth of hardware and software! Worse still each new generation of servers requires more hardware to get the best numbers (i.e. more disks, faster disks, more memory, more network infrastructure etc) so vendors don't publish very frequently which makes it hard to compare results.

This situation leads to several questions:

1. Is there is any way to make benchmarks more relevant to IT organizations trying to make an intelligent hardware purchasing decision?
2. Assuming the answer to (1) is "yes" then is there any way for IT organizations to pressure vendors into producing useful benchmark results?
3. Is there a better way to create benchmarks that reflect real world customer configurations and requirements?
4. Are the existing independent benchmark bodies such as SPEC doing a good job or do they need to change or be replaced entirely?

I have some ideas on how to answer these questions, but they'll have to wait for my next blog entry. Meanwhile I'd be interested to hear the thoughts and experiences with respect to benchmarks of anybody reading this blog.

Posted by: Nik Simpson

For those about to rock, we salute you!

There has been much to do of late about direct current (DC) data centers. I find this debate very interesting because it is almost reaching the fervor of the discussions that occurred between Thomas Edison and George Westinghouse in the late 1800s. Additionally, if nothing else, this proves that history does indeed come full circle, or at least comes in repeatable waves. Instead of deciding whether or not to place an Edison power station on every street corner or to have one large alternating current (AC) distribution system, today's AC vs. DC colloquies center on whether to leave the AC to DC power conversion in the hands of a server's power supply unit (PSU) or move that function to the rack or even a dedicated transformer room.

The discussions seem to focus on the following points. I have not organized them into pros and cons because what is a pro for one decision may be a con for another. These talking points are simply what people bring up when they find themselves in the midst of a AC vs. DC debate:

• Removing the PSU from servers and doing a single conversion at the rack or in a dedicated transformer room would reduce the server room's heat output and in turn reducing the amount of cooling needed.
• Reducing the AC to DC conversion points reduces the heat loss in conversion, increasing the overall power efficiency of a data center.
• The TelCo industry has been using DC for years.
• The TelCo industry is looking at moving away from DC power.
• High efficiency AC is almost as efficient as DC.
• It may be hard to find electricians qualified for or who want to work with the amount of DC voltage necessary for a data center server room.
• The cost of retrofitting an existing data center, or the costs associated with building a new DC data center may negate the short-term, and perhaps long-term, efficiency benefits of a DC data center.

These are just some of the topics that engineers and operations managers are considering with regards to AC vs. DC. I have not made my mind up yet on the subject, and I am not necessarily sure there is a black and white answer. Very often the best solution for one problem is not the perfect solution for another. That is why despite the success of Tesla's alternating current, one can still find evidence of Edison's direct approach in the current day. Below is a list of articles that go into further detail on the subject:

War of Currents
http://en.wikipedia.org/wiki/War_of_Currents

Power-saving technologies in the data center http://searchdatacenter.techtarget.com/originalContent/0,289142,sid80_gci1144396,00.html

Engineers: DC Power Saves Data Center Dough
http://www.eweek.com/article2/0,1895,2000867,00.asp

DC power worries data center planner
http://searchdatacenter.techtarget.com/originalContent/0,289142,sid80_gci1235078,00.html

Can DC Power Cut Data Center Costs?
http://www.eweek.com/article2/0,1895,1943258,00.asp

What's cool about DC-powered data centers
http://www.computerworld.com/blogs/node/178

Before I go, we would love to hear your thoughts on the subject. Please feel free to post comments or e-mail me directly. The Burton Group looks forward to hearing from you!

posted by: Andrew Kutz