DRS/SDRS Affinity & Anti-Affinity Rules

By | 23/01/2018

Although there are 1000 of articles written on this topic, purpose of writing this article is to cover few objectives of VCAP6-Deploy exam. When I published my VCAP6 study guide, few topics I left purposefully as I had planned to write them later when I get some time.

So in this post we will be discussing about DRS & SDRS affinity/anti-affinity rules. 

Affinity Rules – VM to VM

Affinity rules are used by DRS to keep 2 virtual machines always running together. Affinity rules are generally used to keep virtual machines toether which have dependency on each other.

For e.g: You may want to keep an application and a database servers together on same host so that communication between the 2 servers don’t have to traverse a network link. If the VM’s of a multi-tiered application are running on different hosts, then they may generate a lot of network traffic between 2 hosts and can affect performance of VM’s/Hosts.

To improve performance, we can create an affinity rule to ensure the VM’s always resides on the same Esxi host. If a VM is manually migrated by admin, DRS automatically migrates the other VM to the same host, or it moves the manually moved VM back to the original host. 

How to create Affinity Rules

To create affinity rules between 2 or more VM’s, login to vSphere Web Client and navigate to Cluster > Manage > VM/Host Rules and click on Add button.

drs-1.PNG

Provide a name for the rule and make sure rule is enabled. Select type as “Keep VM’s together” and clcik on Add button to add list of VM’s to this rule. 

drs-2

Select the VM’s which you always want to keep together. In my example I have chosen to keep my PSC and VC appliance together. Hit OK to save the selection. 

drs-3

Newly created rule will be now visible in list. 

drs-4

If the DRS is running in fully automated mode and the 2 VM’s for which you just created an affinity rule, are running on different host, then DRS will bring them together. 

You can watch the events for migration from Monitor > vSphere DRS > History 

drs-5

Anti-Afinity Rule – VM to VM

VM-VM Anti-Affinity rule is used to ensure 2 VM’s that offers same kind of services, shpuld always run on different host so that in event of an Esxi host failure, there should not be a total failure of sevrice. Lets understand this by an example.

Suppose you have your Domain Controller (DC)  and Additional Domain controller (ADC) are running as a VM, then you might want to run these 2 VM’s always on different host.

Now suppose both DC and ADC are running on same host and that host encounters an issue (hardware problem or PSOD etc), then both DC and ADC will be down at the same time resulting in total failure of the sevrice until HA restart both of them on some other host. If these 2 VM’s would have been running on different host then in case of host failure, there would have been least impact on sevrice avaialbility.

How to create VM-VM Anti-Affinity Rule

Login to vSphere Web Client and navigate to Cluster > Manage > VM/Host Rules and click on Add button. 

Provide a name for the rule and make sure enabled button is checked. Select type as “Separate Virtual machines” and click on Add button to add the list of VM’s to this rule

drs-6.PNG

Affinity Rules – VM to Host

VM to Host affinity rules are used to restrict a list of VM’s to run or do not run on a subset of Esxi host. By configuring this rule you are telling DRS to migrate a given number of VM’s to only a subset of hosts and not on all hosts (basically you are making life of DRS a bit tough). Now why would anyone want to do so? Lets understand the use case for this from below example.

Suppose you have 100’s of VM’s running on 20 Esxi hosts in your environment. Out of those 20 Esxi hosts, some are from the lastest generation and some are from a bit older generation. The latest generation servers are offering some new CPU features that aren’t available in the older servers, and you have few VM’s (out of thsoe 100 VM’s) that can take advantage of the new cpu offerings by the newer hosts, then you might want those few VM’s to run always only on the newer hosts and not anywhere else. 

How to configure VM-Host Affinity Rule

Before creating this rule, we have to first define Host Groups (which contains the list of hosts where you want your particular VM’s to berunning) and VM Groups (List of all those VM’s which will be running only on selected Esxi host)

To create Host and VM groups, login to vSphere Web Client and navigate to Cluster > Manage > VM/Host Groups and click on Add button. 

drs-8

Provide a name for the rule and select type as Host Group and click on Add button.

drs-9

Select the hosts that will be part of the Host Group and hit OK.

drs-10

Again clcik on Add button from main page and this time select type as “VM-Group” and provide a name for the rule. Click on Add button to add the VM’s.

drs-11

From the list,select the VM’s that will be part of the VM Group and hit OK.

drs-12

Now we have both Host Group and VM Group defined.

drs-13

Now select VM/Host Rules tab and clcik on Add button to add a new rule.

  • Provide a name for the rule and select type as “VM to Hosts“. 
  • Under VM Group tab, select the VM group which we created in last step.
  • Under Host Group select the group which we created earlier. 

Now the setting “Should run on hosts in group” dictates that the VM’s defined in VM Group will be running on hosts defined in Host Group only. 

drs-14.PNG

VM-Host Anti-Affinity Rule

This rule is just opposite of VM-Host affinity rule and this rule dictates that a list of VM’s defined in VM Group will never run on Esxi host defined in Host Group.

To create this rule follow the same steps which we followed to create VM-host affinity rule, just select “Should Not run on hosts in group

drs-15.PNG

Storage DRS Affinity/Anti-Affinity Rules

Just like DRS oprates at VM compute level, SDRS operates at VM’s vmdk level. By using SDRS affinity/anti-affinity rules, you can decide to whether or not to keep 2 or more VMDK’s of a VM together.

By default when you create a VM and selects the default option, all VMDK’s attached to a VM resides on same datastore. Below screenshot is an example from my lab. Both VMDK’s of my VM are stored on datastore iscsi-1

sdrs-0.PNG

Now if you want to keep the VMDK’s on separate datastore, you have to configure override policy to alter the default rule of keeping VMDK’s together. Now a question can pop up in your mind what is the use case for keeping the VMDK’s on different datastore. 

Well if your application is IO intensive and is spwannned across 2 or more disks, then keeping them together can result in producing high IO on a given datastore (causing other VM’s to suffer performance issues). I am not taking into account SIOC here. 

To create a rule for VM override, navigate to storage view in webclient and select Datastore Cluster > Manage > Settings > VM Overrides and click on Add button.

sdrs-1

Click on green + button to add a VM for which which you want to define override rule. 

Set “Keep VMDK’s together” to NO and hit OK.

sdrs-2

Select Rules tab and click on Add button to define new rule.

sdrs-3

Provide a name for the rule.

Select type as “VMDK anti-affinity” and clcik on borowse button to select the VM for which you are creating this rule. 

Select the disk’s of the VM that will be part of this rule and hit OK. 

sdrs-4

A new rule has been created now.

sdrs-5

If you have configured SDRS in fully automated mode, you can view the events for SDRS migrating the VMDK’s of a VM on 2 different datastore. This can be viewd from Datastore Cluster > Monitor > History tab.

sdrs-6

And thats it for this post. I have only covered the basic concepts of Affinity/Anti-Affinity rules. If you want to deep dive on this, then I recommend reading Clustering Deep-Dive book by Duncan and Frank 

I hope you find this post informational. Feel free to share this on social media if it is worth sharing. Be sociable 🙂

Category: VMware

About Alex Hunt

Hi All I am Manish Jha. I am currently working in OVH US as Operations Support Engineer (vCloud Air Operations). I have around 7 Years of IT experience and have exposure on VMware vSphere, vCloud Director,vSphere Replication, vRealize Automation, NSX and RHEL. If you find any post informational to you please press like and share it across social media and leave your comments if you want to discuss further on any post. Disclaimer: All the information on this website is published in good faith and for general information purpose only. I don’t make any warranties about the completeness, reliability and accuracy of this information. Any action you take upon the information you find on this blog is strictly at your own risk. The Views and opinions published on this blog are my own and not the opinions of my employer or any of the vendors of the product discussed.