What’s new with Distributed Resource Scheduling (DRS) in vSphere 7

kaleidico-3V8xo5Gbusk-unsplash

In this blog series, we will discuss elements of the release of vSphere 7, which was released earlier this year in May. In part one, we will review enhancements and changes made to Distributed Resource Scheduling (DRS). In future blogs, we will look at other new features and enhancements.

VMware DRS is a feature used for balancing resources of virtual machines across ESXi hosts in a cluster. The purpose of DRS is to balance CPU and memory across clusters. It can be set to automatically move VMs based off of its algorithms, or be set to manual and give recommendations for manually moving VMs. Due to the variable nature of database workloads, it is generally not desirable to allow vSphere DRS to relocate production databases at will. Instead, human intervention is preferred for planning and monitoring VMs, as well as determining the location of business-critical database workloads. Therefore, we do not recommend enabling fully automated DRS. Rather set it to partially automated, which allows VMware to recommend a location for the guest, but does not attempt to move it automatically.

vSphere 7 DRS logic has changed most significantly in regard to the balancing approach. Prior versions of DRS balanced at the vSphere cluster level. It would review ESXi hosts for high memory and CPU usage and attempt to balance the cluster more equally. With vSphere 7, DRS evaluates virtual machine performance instead of the cluster, and also has more granular checks, looking at metrics like CPU Ready Time and memory ballooning. Now, if DRS can provide better performance to a VM on another ESXi host, it will move it or make a recommendation for it to be moved. DRS now uses a score to determine the performance efficiency of the virtual machine. I believe the reason VMware uses the word “efficiency” over performance is because DRS is not looking at all performance metrics; for example, I/O throughput is not a metric for which DRS gathers data.

DRS Comparison

Affinity Must Rule

A quick word on DRS Affinity Rules. For licensing reasons, it may be desirable to set a “Must” rule. It is recommended to set host affinity “Must” rules for VMs that need to stay on certain hosts for licensing purposes. Depending on the version of vSphere, VMware HA does not respect affinity rules when restarting a VM due to hardware failure. However, this behavior was addressed beginning in vSphere 6.5. With newer versions allowing host affinity rules to be set that define where VMs can or cannot (anti-affinity) run.

The VMware doc for VM-Host Affinity Rules, describes adding a host affinity must rule.

To create an affinity rule in vCenter, see the below steps:

  1. Right click the Cluster > Edit Settings
  2. Enable DRS, if it is not already enabled
  3. Click Rules > Add
  4. Click the DRS Groups Manager tab
  5. Click Add under ‘Host DRS Groups’ to create a new Host DRS Group containing the hosts in the cluster that you want to tie the VMs to
  6. Click Add under ‘Virtual Machine DRS Groups’ to create a Virtual Machine DRS Group for all of the virtual machines that you want to tie to hosts listed in the Host group created above
  7. Click the Rule tab, give the new rule a name and from the ‘Type’ drop-down menu, click Virtual Machines to Hosts
  8. Under ‘Cluster VM Group’ select the newly created VM group
  9. Select Must run on hosts in group
  10. Under Cluster Host Group select the newly created Cluster Host Group and click OK

Summary

vSphere 7 offers a variety of new features and enhancements, including a greatly improved UI for DRS. In this blog, we focused on those enhancements as well as enhanced functionality related to DRS. In future blogs in this series, we will examine other vSphere 7 features and enhancements, so check back soon.

Table of Contents

Related Posts