Data Center Temperature

There are presently many articles and posts around encouraging increasing data center temperatures.  ASHRAE has widened the temperature and humidity recommendations for data centers, and many blogs are recommending and discussing drastically increased temperatures.   Lately the discussions have been around the work environment of over 110F in data centers.  Note, that these high temperatures are in new or re-designed data centers with hot/cold isle separation (hot isle containment or cold isle containment).

Existing data centers should definitively investigate possible temperature increases as well as humidity range broadening.  However any such temperature change should be made slowly and with considerable monitoring.  In traditional data centers it is easy to get upside down with temperature changes.

Keep in mind that the recommendations are for  equipment inlet temperatures.  The temperatures over 90F that are being talked about are rack outlet temperatures.  Invest in at least some moderate temperature monitoring for the rack inlets before making any changes.  Get at least some trending data before changing temperatures and change them gradually.  You want to make sure that you are not getting a lot of hot air recirculation through the equipment, particularly top of rack and end of isle trouble spots.  If your data center doesn't already have them, invest in some rack blanking panels to prevent recirculation within the rack.

Some other points to watch for are that in some traditional data centers with CRA/C units against the walls you might find a slight problem with the location of the temperature sensor for the CRA/C units.  Many of these units are designed for open returns usually an open top for down draft units.   Some of these units have their temperature sensor right on top right in the return air stream.  So these units are measuring and using for control, air that is not the rack inlet supply temperature.

So the CRA/C unit is being controlled by the hot isle temperature instead of the cold isle temperature, but you only care about the hot isle temperature.  Therefore to get the cold isle temperature up to 75-77F the CRA/C set point might have to be set up to 80F or 85F.  The best results will be from relocating the temperature sensor to the cold isle or using multiple remote sensors in the cold isles.

You may not see much savings though depending on the type of cooling involved.  If you are using chilled water you might want to experiment with increasing the water temperature once you have the data center temperature stabilized.  You will want to keep monitoring the data center rack inlet temperatures as you increase the chilled water temperatures.  The highest savings will come from economizers, either chilled water or air systems.  As the data center temperature is increased the effectiveness of economizers increases.

Ultimately you should have a real time power monitoring system in the data center in addition to the temperature monitoring system, before making any changes.  This will help insure that there is some savings as there will be a temperature that proves to be most efficient for your data center and equipment, above which efficiency will start to decrease.

Use total data center (including cooling) energy use to find the best temperature for  your data center.  Do not use PUE for this.  PUE can be deceptive when changing data center temperature.  The problem comes from the fans in the IT equipment.  They are usually variable speed, temperature controlled, such that the fan speed starts to ramp up as the inlet temperature goes above 78F.    Most computers have 5 to 10 fans leaving about 300 fans per rack.  What happens is you decrease the infrastructure side of PUE (cooling) at the same time you increase the IT side (IT equipment fans) which shifts much of the cooling costs to the IT equipment which is much less efficient.  This will result in lowered PUE but increased overall energy utilization.  Using the overall energy utilization will avoid this situation.

You might also investigate moving the CRA/C units to be aligned with the hot isles if they are not already so aligned.  Another option is to install ducted returns from the hot isles which may be more efficient and/or cheaper to implement.  It may be possible to use the data center drop ceiling for a ducted return plenum.  These changes will allow you to increase temperature further and maintain more accurate inlet temperatures.

Software efficiency IS part of data center efficiency

 A few companies are spending effort to optimize hardware and processes towards the reduction of energy in the data center.  Some companies have facilities based projects and others IT based, with a few doing both.  The graphic below from a white paper at Emerson depicts the current thinking in that the further to the left you can save a watt, the more actual savings you receive (assuming right scaling). Thus the further to the right of the graph you save a watt, the less additional savings you receive through this cascade.

Graphic from white paper at http://emerson.com/  

What is missing from this graph, and not often spoken of in data center efficiency conversations, is software efficiency.  I am not talking about virtualization which is allowing you to make better use of hardware and is thus part of the "server component" in the cascade chart above.  I am talking about actual algorithm optimization. 
There are still code shops out there that attempt to optimize their code but as most of us know, most code is rarely optimized these days.  Code optimization has long since fallen under the Moore's Law knife of accounting; "It's cheaper to buy faster hardware than to pay for developer time".  Often time to market pushes aside code optimization (and some times even debugging).

If converting an application from say perl to C++, or simply turning on some compiler options, allows a bit of code to finish in 30 minutes instead of 60 and/or to use less RAM then you likely have a significant measurable power difference that can then trickle down the cascade effect.  I am not by any means saying that all perl or java code should be converted to C or C++ (or any other language).  Just that if you have a piece of code that takes a significant amount of time to run OR is run a significant number of times, spending some effort to optimize it can result in significant savings.

Here is another example.  Say there is a large web application written in some fictional interpreted language (say Perava ;).  The bulk of this code is infrequently hit and performs perfectly well.  But there is one function that is hit repeatedly for every web page.  This function takes 4 seconds to complete and to meet performance requirements for the number of web customers etc. the company deploys 10 redundant servers.  Each server uses 300 watts for a combined 3Kw for servers or following the above cascade up, about 8.5Kw in the data center.
If the optimization of the one segment of code or translation to some fictional compiled language managed to cut the run time in half (overly simplistic I know), so that only 10 servers were needed, and thus just 1.5Kw for servers or just 4.25Kw in the data center.

I have seen this same thing in high performance grid computing as well.  By just turning on optimization flags when compiling programs that are run 100k times a day for minutes at a time, managed to eliminate the need to expand the compute cluster.

We are starting to see some real push towards compiler optimizations particularly around auto-parallelization, which with modern chips is proving hugely successful.  Because of this cascade multiplier effect we can see some real gains on software optimization efforts.

There is another area for optimization which is between the software and hardware layer.  We are used to getting the right hardware to meet the software specs, but what I am thinking about is building the software towards hardware specs.  For example instead of building a single threaded process that would require a very fast processor, build a multy threaded process that can take advantage of a lower watt multi core processor (yes this is already the case for commercial software but in house software can do the same).

Probably a much better and direct example is an in house application that currently, to meet performance requirements keeps all the data in RAM for a particular job.  This might be able to be rewritten to use a combination of much less RAM, multi processing, and SSD (Solid State Disks) to reach even better performance than the original.   I am not talking about just putting SSD drives in a server or using SSDs for SWAP and running the application, but rather the application is altered to use the much faster access times of the SSD.  Bioinformatics, geo-imaging, weather simulations, and many other large data set research programs currently use large RAM systems, MPI clusters, or other methods to handle the large data sets.

Here is a great article on how facebook is drastically increasing performance by cross compiling PHP to C++.