I have just returned from the Intel sponsored Eco-Technology Great Debates where I was slotted into the topic of Thin vs. Thick Client Energy Efficiency. I had the opportunity to weigh in on the side of "Thick" clients as the most energy efficient. The bad news is that our team lost; the good news is that we didn't lose by much (29 to 24)! The best news is that all of the teams had some very strong arguments (and even several very entertaining exchanges).

Being a simple data center guy, I learned a lot, especially as it relates to thin client architecture and energy impacts. No contest, thin clients consume less energy at the device level than do thick clients (PCs and Laptops). But is that really the energy efficient answer?

For thin clients, compute and storage are necessarily displaced to the data center. Data centers with thier concentrated IT equipment are typically inefficient to power and cool relative to laptops and PCs which are distributed by nature and cooled by ambient air. Generally data centers require 1 watt of power for cooling and electrical distribution (house load) for 1 watt of IT load (newer data centers are more efficient but still incur additional power costs simply to power and cool). Therefore, every kW of power that is shifted from distributed thick client use to a data center causes more or less 2 kW of impact in the data center! Wow!

With the majority of the world's data centers facing power or cooling capacity constraints and some with no additional grid power available at all, total energy costs extend beyond the simple house load + IT load equation. Expansion and upgrade of facilities increases energy consumption, as well. There are too many areas to detail here but needless to say the total power consumption for extracting and manufacturing data center components, transporting them to a site and construction of new facilities is non-trivial and likely larger per unit of compute than for the typical laptop. This collateral consumption is not comprehended in any calculations of alternative client model power efficiencies of which I am aware..

I also have no specific data on the power efficiency of PCs or laptops to provide rigorous comparison to data center power utilization efficiency. The above arguments, however, do appear to be logical. More work needs to be done to collect the data and analyze these concepts in detail.....

If you want to see the instant replay of all of the debates (including the client debate, liquid vs. air cooling and ac power vs dc power in the data center), click on the web link above and look for the embedded webcast URL at the bottom of the resulting page. There are also a couple of links to other articles on the subject that are well worth reading.

TTFN!

Do Not Wait for an Alarm or Failure Give your Data Center a "Health Check" using a simple hand held Infra Red (IR) Gun. This tool can provide early warning for electrical breaker overload, CRAC unit calibration issues, server air supply stratification, source of CRAC short-cycling. See the image below and use the number references for legend. The cost of the tool is between $100 and $500 the higher priced guns are recommended for the multiple features

1. Check temperature range of breakers
Check panel cover for ambient temperature, then breaker temperature range. Look for outliers hot and cold. Hot could be loose wire or overloaded circuit.
2. Check under floor for poor air flow
Floor tile temperature is a quick check for restricted air flow or range beyond CRAC.
3. Check actual temperature of delivered air (Supply air)
Concrete in front of CRAC should be around 55 degrees Fahrenheit.
4. Server in-take temperature on rack frame low
Rack frame at first server position compared to temperature at top of rack shows air temperature stratification or rack heating from conductive heat loads. Temperature range of 6 degrees is good. If more than 10 degrees, look for hot air mixing from above or behind servers. Max intake air temp greater than 90 degrees is a great risk to the server platform.
5. Server in-take (supply) temperature on rack frame high
Plus 6 to 10 degrees is the range from good to poor. (See note in 4 previous)
6. In-coming air (return air) temperature off sheet metal frame
Temperature in center of CRAC filter bank is a good indication of actual ambient mixed air returned to CRAC. Compare this temp with CRAC thermal readout for indication of short cycling or bad CRAC temp sensor.

See previous Blogs at
Data Center Toolbox for Power and Cooling

See Published articals at
http://searchdatacenter.techtarget.com/originalContent/0,289142,sid80_gci1275008,00.html
http://www.cio.com.au/index.php/id;537667845;fp;4;fpid;51245
http://www.computerworld.com/action/article.do?command=viewArticleBasic&articleId=9028098&pageNumber=1

Please comment on and rate this Blog.

New topics coming soon:
"Generic Data Center Racking, Cost and Space Benifits"
"Data Center Layer One and Structured Cabling Designs, Without Costly Patch Panel Installations"
"Server Power Cord Management"
"Humidity Management to "Humidify or Not Humidify"

Disclaimer

The opinions, suggestions, management practices, room capacities, equipment placement, infrastructure capacity, power and cooling ratios are strictly the opinion and observations of the author and presenter.
The statements, conclusions, opinions, and practices shown or discussed do not in any way represent the endorsement or approval for use by Intel Corporation.
Use of any design practices or equipment discussed or identified in this presentation is at the risk of the user and should be reviewed by your own engineering staff or consultants prior to use.

Recently, a colleague and I spoke to a group of IT administrators in Washington, DC. We left our car in a self-park parking lot in which the attendants had everyone leave their keys in their car, in lieu of keeping them on a valet "key board". They seemed to be depending on reasonably honest customers (we were in a secure area past a government checkpoint) and their own memories to ensure no cars were "lost". We returned to find that the parking lot attendants had completely rearranged the vehicles. Since it was a rental car, it was hard to describe the car and therefore hard to find. (By this point you're probably thinking that I've posted to the wrong board or that Intel pays me by the word, but bear with me)

It took a rather lengthy iterative search, but we eventually found the car. As we walked, my colleague and I joked about this as "parking lot virtualization". Our vehicle was moved from one slot to another to better fulfill the changing needs of the parking environment over time. This struck a chord with us, having just been discussing some of the challenges with virtualization.

In the data center, most virtualization suites allow an administrator to manually move a workload from one host to another. This is a very powerful concept - instead of having to negotiate for a 3:00am Sunday morning maintenance window to do preventative hardware maintenance, we can move all of the workloads to another physical machine, perform maintenance during normal working hours, and eventually move the workload back to its original location. We can also migrate workloads from a less powerful machine to a newer machine for performance or in order to retire hardware.

Combining this capability with the ability to host multiple workloads on a single piece of hardware, the data center can quickly become very complex. Without a robust database to map workload to physical machine (and vice-versa) or an automated update mechanism to adjust these mappings after a move, we can easily lose track of our services. These mappings are needed in order to answer questions like "host/rack/row/room x went down - what services need to be restarted?"

My colleague noted that ITIL has mature, well-defined mechanisms to deal with many of these types of events. Change orders, maintenance escalations, and configuration databases were all designed with these business processes in mind, albeit at a much slower (and more manual) pace. It would defeat much of the benefit of virtualization if one had to get a signed piece of paper, email approval, or file a trouble ticket in order to offload a workload in response to a failed CPU fan. Instead, we should use policy to anticipate and enact these types of responses. The discipline and rigor of change management is critical within the virtualized data center, but it must be directly encapsulated by our tools in order to be effective. In essence, the CMDB needs to be dynamically updated in order to maintain fidelity to the Data Center's logical state at any given instant.

For those of you who have deployed virtual machines in large-scale production, what techniques have been most successful for managing the chaos of moving services and images? Are you using a glue layer for your legacy CMDB and other management tools, or are you finding it easier to throw them out and depend on the tools provided by your virtualization stack?