VMware vSphere Distributed Resource Schedule (DRS) is the resource scheduling and load balancing solution for vSphere. DRS works on a cluster of ESXi hosts and provides resource management capabilities like load-balancing and virtual machine (VM) placement. DRS also enforces user-defined resource allocation policies at the cluster level, while working with system-level constraints.
Although DRS is widely deployed and generally understood, questions about “how” DRS does what it does are not uncommon. Not knowing exactly how DRS works often leads to confusion and improper expectations about DRS behavior and its performance.
Let’s take a closer look at how DRS achieves its goal of ensuring VMs are happy, with effective placement and
efficient load balancing.
Effective VM Placement:
When a VM is being powered up in a DRS cluster, DRS runs its algorithm to determine the right ESXi host for it to be powered up on. This decision, also known as VM placement (or initial placement) is made based on the expected change in resource distribution (after ensuring that there are no constraint violations if the VM was placed on the host).
Efficient Load Balancing
When the host resources in a cluster are more or less evenly utilized, then the cluster is well balanced. DRS uses a cluster-level balance metric to make load-balancing decisions. This balance metric is calculated from the standard deviation of resource utilization data from hosts in the cluster. DRS runs its algorithm once every 5 minutes (by default) to study imbalance in the cluster. In each round, if it needs to balance the load, DRS uses vMotion to migrate running VMs from one ESXi host to another.
Calculating VM Resource Demand
In calculating the resource utilization, DRS looks for the demand for every running VM in the cluster. VM demand is the amount of resources that the VM currently needs to run. For CPU, demand is calculated based on the amount of CPU the VM is currently consuming. For memory, demand is calculated based on the following formula.
VM memory demand = Function(Active memory used, Swapped, Shared) + 25% (idle consumed memory)
In other words, by default, DRS balances memory workloads based mostly on a VM’s active memory usage, while considering a small amount of its idle consumed memory as a cushion for any increase in workload. This behavior enables you to efficiently run memory workloads in your DRS clusters, even with over-commitment.
Detecting VM Demand Changes
During each round, along with resource usage data, DRS also collects resource availability data from each and every VM and host in the cluster. Data like VM CPU average and VM CPU max over the last collection interval depict the resource usage trend for a given VM, while availability data like VM CPU Ready Time2 and VM Memory Swapped3 indicate resource shortage, if any, for the VM (availability data indicate if a VM is running short of resources). DRS then correlates the resource usage data with the availability data and runs its loadbalancing algorithm before taking necessary vMotion actions in order to keep the cluster balanced and toensure that VMs are always getting the resources they need to run.
Cost Benefit Analysis
vMotion of live VMs comes with a performance cost, which depends on the size of the VM being migrated. If the VM is large, it will use a lot of the current host’s and target host’s CPU and memory for vMotion. The benefit,however, is in terms of performance for VMs on the source host, the migrated VM on the destination host, and improved load balance across the cluster.
Factors That Affect DRS Behavior:
While DRS constantly works to ensure that VMs are getting the resources they need, it also provides several useful customizations that work very well for a variety of cluster needs. By understanding these customizations, you can get the best performance out of DRS and have it meet your expectations. In this section, we discuss some of the customizations and factors that affect DRS and how to use them for best performance.
During initial placement and load balancing, DRS generates placement and vMotion recommendations,respectively. DRS can apply these recommendations automatically, or you can apply them manually.
DRS has three levels of automation:
• Fully Automated – DRS applies both initial placement and load balancing recommendations automatically.
• Partially Automated – DRS applies recommendations only for initial placement.
• Manual – You must apply both initial placement and load balancing recommendations.
The DRS aggression level controls the amount of imbalance that will be tolerated in the cluster. DRS has fiveaggression levels ranging between 1 (most conservative) and 5 (most aggressive). The more aggressive the level, the less DRS tolerates imbalance in the cluster. The more conservative, the more DRS tolerates imbalance.As a result, you might see DRS initiate more migrations and generate a more even load distribution when you increase the aggression level. By default, DRS aggression level is set to 3. However, if you do need DRS to be more active in load balancing at the
cost of increased live migrations, you can increase the DRS aggression level. When DRS aggression is set to level 1, DRS will not load balance the VMs. DRS will only apply move recommendations that must be taken either to satisfy hard constraints, such as affinity or anti-affinity rules, or to evacuate VMs from a host entering maintenance or standby mode.
This is for DRS automation :
Reservation, Limit, and Shares:
DRS provides many tools for you to customize your VMs and workloads according to specific use cases. Reservation, limit, and shares
You might need to guarantee compute resources to some critical VMs in your clusters. This is often the case when running applications that cannot tolerate any type of resource shortage, or when running an application that is always expected to be up and serving requests from other parts of the infrastructure.
With the help of reservations, you can guarantee a specified amount of CPU or memory to your critical VMs.
Reservations can be made for an individual VM, or at the resource pool level. In a resource pool with several
VMs, a reservation guarantees resources collectively for all the VMs in the pool.
In some cases, you might want to limit the resource usage of some VMs in their cluster, in order to prevent them from consuming resources from other VMs in the cluster. This can be useful, for example, when you want to ensure that when the load spikes in a non-critical VM, it does not end up consuming all the resources and thereby starving other critical VMs in the cluster.
Shares provide you a way to prioritize resources for VMs when there is competition in the cluster. They can be set at a VM or a resource pool level.
A very good documentation on the workflow of DRS are :