The Distributed Resource Scheduler (DRS) will automatically balance the virtual machines (VMs) in the vSphere cluster based on resource usage. Most of the time, DRS does its job perfectly. But because DRS is not aware of applications running on the VM and its dependencies, we need to help DRS optimize the placement of VMs on ESXi hosts in some cases. Affinity and anti-affinity rules can help define the limitations and constraints when it comes to moving VMs.
Creating a VM affinity rule ^
You can create a VM affinity rule to place a specific group of VMs on a single ESXi host. When you are running a multi-tier application, for instance a web server, an application server, and a backend database server, those three tiers communicate intensely. If the tiers are on different ESXi hosts, this will result in heavy network traffic between the hosts.
To improve performance, we can create an affinity rule to ensure the multi-tier application always resides on the same ESXi host. If you manually move a VM, DRS considers the affinity rule and migrates the other two VMs to the same host, or it moves the manually moved VM back to the original host. When providing recommendations, vSphere DRS considers performance optimization.
DRS migrates the VM according to affinity rules if it is in automated mode. When DRS is in partially automated or manual mode, it only offers recommendations to migrate a VM to comply with the affinity rules.
Log in to vCenter Server using the vSphere Web Client. Select the vSphere cluster where you want to create VM affinity rules and then click Configure -> VM/Host Rules -> Add.
Specify the name for the anti-affinity rule, select Keep Virtual Machines Together from the Type drop-down, and click Add.
Select the VMs from the list, click OK to add VMs to the affinity rules, and click OK to create the affinity rule.
Ensure the Enable Rule checkbox is selected. Click on OK.
This will create the affinity rule. You will be able to see the created rules under the VM/Host Rules section of the vSphere cluster.
After creating the affinity rule, I noticed DRS migrated all three VMs that were part of the affinity rule into a single ESXi host to comply with the affinity rule.
I tried to migrate one of the multi-tiered application VMs (App-1 in the screenshot above) to a different ESXi host manually. DRS automatically started the migration of two other VMs (DB-1 and Web-1) to the same host to comply with the affinity rules. Even in a second attempt, DRS migrated back the manually vMotioned VM to the same host.
I changed the DRS mode to partially automated to understand the DRS recommendations for affinity rules. The partially automated DRS mode will display the migration recommendation and perform the initial placement when powering on the VM. After changing DRS to partially automated, I migrated the database VM (DB-1) to a different ESXi host.
Let's see what DRS recommends in partially automated mode. To see the DRS recommendations, select the ESXi cluster -> Monitor -> vSphere DRS -> Run DRS Now, which will manually run DRS immediately. Otherwise, DRS will run as per its time interval.
DRS displays the recommendation to migrate the VM DB-1 back to the ESXi host where other two VMs are running. You can click on Apply Recommendation to apply the DRS recommendation.
Creating DRS anti-affinity rules ^
Anti-affinity rules are just the opposite of affinity rules. You can create an anti-affinity rule to place a specific group of VMs across multiple hosts by separating each VM in the group to run on a different ESXi host. This will improve redundancy.
You can create anti-affinity rules to separate VMs. The simple use case for anti-affinity is when you run a cluster with applications such as Microsoft SQL or Exchange to ensure high availability (HA). If the application cluster nodes are running on same ESXi host, you will lose the entire application cluster when the host fails.
HA will restart all the application node VMs on a different ESXi host. This means downtime to the application even though you are running a cluster. To avoid this failure, we can create anti-affinity rules to separate VMs in the clustered group from each other. This will place each node of the application cluster VMs on different ESXi hosts in the vSphere cluster. As a result, this provides additional availability along with the application level cluster.
Creating anti-affinity rules works the same way as with affinity rules. The only difference is to select the type as Separate Virtual Machines instead of Keep Virtual Machines Together.
Specify the name for the anti-affinity rule, select Separate Virtual Machines from the Type drop-down, and then click add. Select the VMs to add to the anti-affinity rule and click OK.
After creation of the anti-affinity rule, DRS migrates the VMs to separate ESXi hosts to comply with the rule.
Figure 10. VM placement on the ESXi host after anti-affinity rule creation
Note that if your configuration violates DRS rules—say you have three nodes in your cluster but only two ESXi hosts—an error message will appear under DRS Faults.
Maintenance mode and anti-affinity rules ^
We have created anti-affinity rules to separate VMs from each other. We now need to understand what will happen when we place the ESXi host in maintenance mode. I created an anti-affinity rule to separate two VMs (Node-1 and Node -2) from each other in a two-node ESXi cluster.
When I try to place the ESXi host (esxic-lab-1) into maintenance mode, vSphere displays a warning message:
The following hosts are in a DRS cluster: … One or more virtual machines might need to be migrated to another host in the cluster, or powered off, before the requested operation can proceed.
The ESXi host is not entering maintenance mode even though it is in fully automated DRS mode. It displays another error message:
Unable to automatically migrate the virtual machine Node-1 from the ESXi host esxic-lab-1.
When this happens, you don't get any warning or dialog pop-up. You need to go to the Tasks & Events of the ESXi host manually to understand the reason the host did not enter into maintenance mode.
In this case, we have to disable the anti-affinity rule temporarily or manually migrate the VM to a different ESXi host, thus allowing the host (esxic-lab-1) to enter maintenance mode. As a permanent solution, we can add an additional host to the cluster.
DRS rules in conflict ^
We can create multiple VM affinity and anti-affinity rules. If two rules are in conflict, you can't enable them. For example, I created an anti-affinity rule to separate the VMs "Loginsight-1" and "Loginsight-2," and I am trying to create an affinity rule to keep the same VMs together. This produces an error message:
The DRS rule is in conflict with the existing DRS rules in the cluster. It will be disabled. The rule can be enabled manually when the conflicts are resolved.
When two rules conflict, the older one takes precedence, and DRS will disable the newer rule. DRS will satisfy the enabled rules and will ignore the disabled rules. It gives higher precedence to preventing violations of anti-affinity rules than violations of affinity rules.