Imagine a computer room air conditioning system that switches between cooling types based on environmental conditions, using ambient air when wet-bulb temperature is below a predefined threshold, substantially reducing the amount of electricity used to cool the datacentre facility – well, I imagined exactly that a few months ago and our datacentre greening strategy is well on the way to implementation (well, after we iron out a few little bugs and I stop electrocuting myself!).
There are probably a few of you asking yourselves why on earth I’d build something custom when there are many off-the-shelf environmental monitoring and free cooling packages commercially available. The answer to this is twofold: cost and flexibility. Our datacentre is unique in its construction and is specifically designed for medium density content delivery and telecommunications infrastructure for SONET’s ISP business. Whilst most off the shelf systems are customizable enough to allow for equipment of this type, I wanted more granular control over triggers for cooling state changes.
The system is based on a few discreet components:
1. Power control for the evaporation coolers
2. Infrared logic control for the refrigerated air conditioners
3. Temperature and humidity sensors for environmental monitoring (both inside and outside)
4. Embedded Linux controller system to perform the business logic for the application, as well as providing environmental monitoring feedback to the network operations centre.
I’ll give a little insight into how the whole shebang is supposed to work.
AC Power Control
Being a relative newcomer to AC power control (I am not an electrical engineer and my experience with power systems so far has been predominantly DC for rural power systems), power control for the evaporative cooler remains a challenge. There are a few complexities with AC power control – especially with reactive loads – which I am still grasping – thankfully I’ve got an electrical engineer friend who has been helping me sort through the technicalities of our implementation.
I settled for a Braemar evaportative cooler and was especially diligent to ensure that the unit was single phase, as timing TRIAC states between multiple phases is a complex art, requiring high accuracy oscillator circuits to ensure synchronization with the grid. I am settling on using thyristors because of their relative ease of implementation for single phase circuits and their lack of requirement for a snubber circuit for reactive loads (I think – I’m sure an engineer reader can provide a more in-depth description of what exactly goes on here).
I am controlling gating using at ATMEL micro-controller and DAC interfaced by RS232 to a Linux controller box which is responsible for controlling cooling states and passing environmental information back to the NOC. This also gives us the flexibility to pass information in whatever format we like (we are not reliant on SNMP). Whilst this isn’t in production at the moment, when it does we will most likely use SOAP to talk directly to our status display panels in the NOC and in my home office – information will also be saved into a MySQL database for trends analysis, which will allow us to make more informed choices in regards to continuous improvement strategies.
One of the other benefits of this setup is the ability to change gating frequency – this means we can change the air volume based on load and cooling requirements in the facility.
Controlling The Aircons
We’re using commercial splits to cool our facility. Before you get on your high horse, explaining the importance of using properly sized CRACs for load, consider the both the unusually large amounts of control we have over the compressors as well as the amount of time invested in analyzing and sizing the exact requirements to provide adequite cooling to the facility.
Ironically, despite the closed architecture of most split systems, these are actually the easiest of all the components to control. Each setting on the remote control is a separate infrared command, making the control logic for these devices exceptionally easy. Because of the use of our own independent environmental monitoring, we have no need (or desire) to read state information from the air conditioners.
We are using IR windows to pass infrared commands to the splits to change their states based on requirements.
Environmental Monitoring
Did you know they make temperature/humidity sensors with RS232 output? We didn’t until we started using them, and they are fantastic. Reading state information is as easy as logging state updates from the tty into a database and reading them out as required. This also gives us the ability to read trend reports on temperature settings and make changes to our setup as required.
I’ll be monitoring temperature and humidity both inside and outside the datacentre facility, which (with some maths-fu) allows us to determine the potential wet-bulb temperature of the evaporative coolers and activate the appropriate cooling type based on the environmental conditions.
We’re somewhat unlucky in Brisbane, as the humid climate does not allow for evaporative cooling the predominance of the year. Fortunately, our ambient temperatures are some of the most predicable in Australia which allows us to take some liberties with our evaporative strategy.
There are many times where ambient temperature is low enough to cool the facility, but humidity is far too high to allow full evaporative cooling of the facility. By passing commands to the refrigerated A/Cs, we can get them to perform dehumidification without any refrigeration (in conjunction with the evap coolers) for a fraction of the power usage of just running refrigerated A/C (something currently unachieveable with any datacentre environmental control system I have come across). Our use of hot aisle containment allows us to get away with this.
Controlling it All
Debian is God’s gift to rapid deployment. That’s all that needs to be said here. Its flexibility regarding reading from/writing to tty’s is what has allowed us to develop a control system of this complexity so rapidly.
Extensive use of PHP/shell scripting helps too, as well as MySQL. While it may seem counter-intuitive to use a scripting language for this, rapid time-to-market is more important than processor cycles in this regard, and it is no doubt cheaper just to throw more processing power at the problem than it is to optimize. If I was to sell this as a product I’d probably take a more serious approach to this but at the moment it’s purely an R&D experiment.
Future Improvements
Where to go from here – well, a good start will be implementing CT metering for power, so we can get feedback on exactly how much power it takes to cool the facility. This will allow us to make decisions within the business logic regarding how we value efficiency vs. hot/cold aisle temperature and give us some REAL metrics to give when making decisions to cut carbon emissions.
This will also allow us to make proactive changes to cooling during power outages: the evaporative cooler uses so little power that it is feasable to run it off the UPSes. During outages, this means we can sacrifice cold aisle temperature for increased generator/UPS runtime, proactively avoiding power outages within the facility.
There are also obvious improvements, like introducing redundancy for monitoring systems and separating the business logic from the software itself (at the moment a lot of this is contained in hotchpotch PHP scripts, cron jobs and other nasties – this is TRULY in beta). We’ll also need to develop some reports (probably in Crystal Reports) to allow us to get near real-time feedback on our greening strategies and give us highly granular control over our cooling and power usage.