Recently we discussed the VMware High Availability Admission Control - a very important vSphere feature. As I mentioned in the previous post, Admission Control uses some ways to calculate available CPU, memory in the cluster. One of thing that can affect the calculation is Resource Pool. In this post you will find answers to the following questions:
- What is Resource Pool?
- When using Resource Pool?
- Some good and bad practices of using Resource Pools.
Resource Pool - overview and basic concepts
As VMware says:
A resource pool is a logical abstraction for flexible management of resources. Resource pools can be grouped into hierarchies and used to hierarchically partition available CPU and memory resources.
Resource Pool is just a special folder/container.
Resource Pools - hierarchy.
As shown in above figure, a resource pool can contain child resource pools, virtual machines, or both. You can create a hierarchy of shared resources. The resource pools at a higher level are called parent resource pools. Resource pools and virtual machines that are at the same level are called siblings. The cluster (Tokyo-cluster) itself represents the root resource pool. If you do not create child resource pools, only the root resource pools exist.
So... Resource Pool is similar to a folder (possibility to specify permissions) but not the same, why? For each resource pool, you can specify reservation, limit, shares, and whether the reservation should be expandable. The resource pool resources are then available to child resource pools and virtual machines.
To configure Resource Pools you need to enable VMware Distributed Resource Scheduler (DRS) on a cluster. DRS is available in vSphere Enterprise and Enterprise Plus editions.
You can meet provider-consumer terminology explaining Resource Pools, e.g. here. Normally, the host/cluster is the Provider and the VMs are the Consumers. So what is Resource Pool? For example, as shown in the figure above, Resource Pool 2 is the consumer and the provider as well 🙂
Resource Pool - Shares, Limits and Reservations
Resource Pool provides better control of cluster resource by using Shares, Limits, and Reservations on CPU and RAM usage. Let's explain these parameters:
- Shares
- Limits
- Reservations
Shares
Shares specify the relative priority or importance of a virtual machine (or resource pool). For example, if a virtual machine has triple as many shares of a resource as another virtual machine, it is entitled to consume triple as much of that resource when these two virtual machines are competing for resources. Shares are typically specified as High, Normal, or Low and these values specify share values with a 4:2:1 ratio, respectively. You can also specify Custom as well.
Shares only come into play when there is resource contention (Memory or CPU).
Limits
Limits specify the maximum resource usage. A server can allocate more than the reservation to a virtual machine, but never allocates more than the limit, even if there are unused resources on the system. Assigning a limit is useful if you start with a small number of virtual machines and want to manage user expectations. However, you could waste idle resources if you specify a limit.
Reservations
Reservations establish a minimum guarantee of resource usage. For example, if you have fours VMs belonging to Resource Pool with RAM reservation set to 4 GB, the resource pool guarantees the concurrent RAM usage of all VMs in the pool to a minimum of 4 GB jointly. It means that if VM1 is using only 0.5GB, VM2 and VM3 is using 2GB (1 GB each), VM4 can use 1.5GB.
Shares, Reservations, and Limits can also be set on a per-VM basis.
VM level - Shares, Limit and Reservation
Resource Pools - the purpose of use
Resource Pools should be used whenever you would limit or guarantee resources to VMs. Revelling? 🙂 Of course, not 🙂 There can be another reason to use Resource Pools:
- Prioritizing VMs.
- Selling resource inside or outside an organization.
- Performance Isolation - for example when you have Test/Dev, Prod and also some really crucial VMs (like Business Critical Application (BCA), you can use Resource Pool to isolate/guarantee performance.
Resource Pools - best practices and warnings
- Administering/organizing VMs - it is not seldom when resource pools are configured just for administration and organization of VMs. Instead of doing it, the VMware Admins should configure VM folders.
VM folders better to organize VMs.
- When you use Resource Pools please design/consider the configuration of Resource
Pools carefully. If you want to prioritize Resource Pools (and also VMs inside them)Â by using Shares please remember that amount of VMs is a very important consideration. For example, you have two resource pools with 100 and 10 VMs in each. Shares of resource pool 1 are 8000 (80%of cluster resource), resource pool 2 - 2000 (20% of lustre resource). In this case, when CPU contention occurs, each VM in Resource Pool 1 could get 0.8% of a CPU resource but VM in Resource Pool 2%! I have seen this problem in some environments - Test/Dev VMs got more resources than Production VMs!
Prioritize Resource Pools
- Ensure that each VM is placed in a resource pool and not out of all resource pools (look at point 4). VMs outside pools with shares configured could get more resources than VMs inside resource pool.
Resource Pool for VMs
- Avoid Shares, Reservations, and Limits on a per-VM basis. Of course in some cases, it could be a very good solution but difficult to be controlled by VM Admin.
Conclusion
Resource Pools are very useful tools but require planning and configuring carefully. I hope that Resource Pools are now more understandable 🙂