Last week I wrote a bit about vSphere’s Data Recovery feature. There are a lot of good things to talk about in vSphere so this week I thought I’d cover Dynamic Power Management, or DPM. Many users of VI3 are probably familiar with DPM. It was available, but not fully supported since it was marked Experimental. Since it was Experimental it wasn’t commonly implemented, though it was the topic of much conversation.
Dynamic Power Management allows vCenter to put ESX servers in a standby state when they aren’t needed as a way to reduce power consumption. If you have used Dynamic Resource Scheduling, DRS, in VMware you are familiar with many of the concepts that DPM uses. With DRS when load is unbalanced vCenter will vMotion virtual machines around in the cluster as needed to balance the load across the servers. To save power the DPM functionality monitors load on the cluster as well and when possible removes all virtual machines from an ESX server and then puts that server in standby. Instead of going through the work of creating a demonstration I’ll link to a great video already done showing DPM in a shifting workload environment.
Putting DPM to Use
The configuration of DPM closely resembles that of DRS. As with DRS you set an automation level. The values are:
- Off – Disable DPM and do not provide recommendations
- Manual – Provide recommendations but do not carry out actions automatically
- Automatic – Automatically execute on recommendations, if the VMs can be moved automatically
Look familiar? I thought so. By default all hosts in the cluster inherit the cluster’s DPM automation level but this can be overridden on each host. Again, similar to DRS, there is also a slider threshold to set the priorities of the recommendations from priority-one (required action) to priority-five (slight improvement). By adjusting the slider you can change the sensitivity so that only priority-one recommendations are executed all the way to priority-five.
Hardware Requirements
DPM will put an ESX host in a standby state when its compute resources are not currently needed. To bring the host out of that state it must use one of the three supported wake-up technologies. These are:
- Intelligent Platform Management Interface (IPMI)
- Hewlett-Packard Integrated Lights-Out (iLO)
- Wake-on-LAN (WoL)
If a host supports multiple protocols, they are used in the following order: IPMI, iLO, WoL.
How Much Can I Save?
How much you save really depends on your environment and the hardware you are using. From an earlier post, do you know what your data center costs to operate? To give you some idea let’s take a look at a server that uses 1KW/h of power. That’s a lot, but I like round numbers. If you can put that server in standby for 8 hours per day that can save you $584/year, including cooling costs. Scale that by the number of servers that run needlessly over nights and weekends and you can really see the benefit of this feature.
Hey Wait, is This a Good Idea?
So, do you want an automated system powering down your servers? That’s a topic of some debate. For some opinions:
On the technology side you have to put some faith in to those magic WoL packets to start your servers up again. What happens when that doesn’t work on Monday morning? That’s where good testing comes in. On the policy side will most organizations let an automated system make these sort of changes or does each server cycle require invoking the change control process?
I think that in time this will be common place. It’s going to be driven by need as many data centers and server rooms are forced to find ways to conserve power and reduce operational costs. Like most technologies it will come with time, testing, and comfort.
