Idle gear: It's too darn hot

Sysadmin Blog IT projects can arise from the most interesting of circumstances. One project begets another project and another and down the rabbit hole you go. The subject of this article is power management; a project brought to the forefront by of all things our upcoming replacement of desktops with low-power Wyse thin clients. If that seems bizarre to you, allow me the chance to explain.

The project at hand is the replacement of virtually all desktops in service with Wyse thin clients, which will force the last of our users onto VDI, and for all intents and purposes prevent them from running anything locally on the system that sits on their desk. From a desktop power management standpoint this is grand, because these little Wyse boxes absolutely sip power. No moving parts, and the LCD screens they drive put off more heat (and pull more wattage) than they do.

How then does this lead to a power management article? Well, all those cycles that used to be consumed on the desktop went somewhere: right into my datacenter (DC). From a performance standpoint, I’m ready for this.

I’ve been running VDI for a while, and a little bit of extra loading is really only running the servers closer to maximum utilization, rather than running us out of capacity. The issue at hand is one of heat. Running the servers closer to the redline has increased the thermals in the datacenter just enough to cause various things that go 'ping’ to email me several times a day complaining that they are a little too warm.

I’ve gotten away with it for the past six months largely because the Canadian prairies tend towards long, cold winters, and our outside air system kept the DC as cold as I could possibly want it. Well, I’ve had the (fingers crossed) last snowfall of spring here, and very soon it’s going to be 35 Celsius outside. At those temperatures, the pair of A/C units in place simply aren’t going to cut it.

I am additionally paranoid about one of them failing, and the other not even beginning to be able to cope. A third A/C unit is on its way, but it could be a couple of months before it’s fully installed and ready to rock.

Even better, our few non thin client desktops are all together in one area; an area that has seen quite a lot of equipment rearrangement over the past several months, and which will itself be facing thermal issues this summer. Looking at the weather forecast I have a week to figure out everything there is to figure out about power management, after which the organic fertilizer will encounter the rotary air recirculation mechanism. Not being the sort to ever do research twice if I can avoid it, the power management tricks I learn to keep my servers powered down can be applied to the remaining full-fat desktops in place, and even their thin client brethren.

The project at hand is essentially to create a system by which I can perform lights out management (LOM) on every system on my network, while powering anything and everything down when it is not needed. Having already virtualized everything that can be virtualized, the low hanging fruit that is left is all the gear I leave on hot standby.

These systems really should be on cold standby, but I leave them up because I periodically need to patch them, change their configs, etc. To run these in cold standby I need to be able to bring them out of a sleep state, and preferably to be able to access their console remotely in case there is some sort of error on boot. In addition there is spare networking gear that is similarly just sitting around waiting for the primary to fail.

There are also some systems that do their job, and then don’t need to be heard from again for a while. They could be powering down during this “dead time,” thus not pumping however many hundreds of watts of heat into the air that they consume just sitting there, and allowing the A/C units to get the air mass just that much colder.

When I think about it, we have some big multifunction printers scattered about the office that pull quite a bit of juice. Some of the newer ones can be programmed to go to sleep and wake up on print or at a specific time, but the MFCs and the smaller printers just don’t have that feature. This is where I start getting into the world of wake-on-LAN. It’s amazing what WOL can do.

As the name suggests, WOL lets you wake up from a sleep state a properly configured network attached device by sending it a specially crafted “magic packet.” WOL has been superseded recently by Desktop and mobile Architecture for System Hardware (DASH), but devices incorporating this standard are still pretty rare.