An assessment revealed that in a company’s current physical environment, the total RAM usage of the Windows servers during times of peak demand was 128 GB, which was 67% of the total RAM capacity of 192 GB. This led to a decision to allow 150% RAM over commitment for the Windows VMs. After analyzing the existing servers and planning for growth for three years, the predicted total configured RAM for all VMs was 450 GB. But, to allow 150% over commitment, only 67% of the estimated, or 300 GB, was procured for direct use by VMs. More RAM was actually purchased to allow overhead and spare capacity for ESXi downtimes, but only 300 GB was planned for direct VM usage.
Initially, the administrator was concerned about over commitment, so to build some trust, resource pools were implemented. The first phase of VM deployment involved just ten Windows servers. He chose to create a resource pool named Pool-01 with RAM Reservation set to 67% of the total configured RAM for the VMs. This was done with the intent to guarantee that the pool will be able to access real memory that its VMs are expected to need. He set the RAM Limit to equal the Reservation plus extra RAM to allow for the overhead of each VM. Since the total configured RAM of the first ten VMs was 15 GB, the Reservation was set to 10 GB (67% of 15 GB), and the Limit was set to 11 GB, allowing 100 MB overhead per VM.
Although access to available CPU and RAM resources were limited on the VMs, the administrator saw that the performance was still very satisfactory under actual workload.
The administrator chose to continue using this “building block” approach going forward. For each new wave of servers that he deployed, he chose to create a resource pool, whose RAM Reservation and Limit was calculated and set using the same formula. Later, he expanded the concept to allow for other over commitment targets. For example, when he analyzed a particular set of physical Web Servers, he saw that they currently only utilized 50% of the configured RAM during times of peak usage. He chose to configure a pool for these VMs whose limit was set to 50% of the total configured RAM plus room for overhead.
Although this approach is not commonly used in the field, it was effective for this administrator. It allowed him to proactively determine if the VMs would behave well in the future, even if RAM contention occurred. Basically, he configured limits to force contention to the planned maximum level and verified that the applications still performed well. Whenever a set of VMs did not perform well in their pool, he would increase the Limit and would accordingly adjust his capacity plans. Such adjustments could have led to deploying fewer VMs to the cluster than originally planned or purchasing more hardware.
Resource pools can be very useful tools, but care must be given to planning and configuring the pools. In many cases, it may be best not to create any resource pools. But in the examples provided in these posts, resource pools were very helpful in meeting a specific need.
Reproduced from Global Knowledge White Paper: Recommended Use of Resource Pools in VMware vSphere DRS Clusters
Related Courses
VMware vSphere: Install, Configure, Manage [V5.1]
VMware vSphere: Fast Track [V5.1]
VMware vSphere: Optimize and Scale [V5.1]