Sometimes, virtual machines that should not reside on the same virtualization host. This comes into play with virtualized Exchange server roles, VMs that are part of a failover cluster, virtualized Active Directory domain controllers or sometimes a VMs in a web farm. In a private cloud environment, this is likely to come up occasionally, it helps to know how it works and how to configure this behavior.
In VMware, you would configure this in their management UI. Hyper-V works differently, as you don’t configure this setting in VMM 2012. Highly available VMs in Hyper-V are based in failover clustering, this is where anti-affinity would be configured, using the AntiAffinityClassNames property.
How anti-affinity works in Hyper-V and Failover Clustering
A cluster resource will group’s AntiAffinityClassNames property consists of a user-defined string. If the AntiAffinityClassNames properties of two or more groups contain at least one identical string, the groups are said to be anti-affined. By default, all groups are affined (because their AntiAffinityClassNames property is NULL).
When a group is moved during failover, anti-affinity affects the algorithm used to determine the destination node as follows:
1. Using the preferred owner list of the group being moved, the Cluster service finds the next preferred node.
2. If the node is not hosting any group anti-affined with the group being moved, it is selected as the destination node.
3. If the next preferred available node is currently hosting a group anti-affined with the group being moved, the Cluster service moves to the next preferred available node in the preferred owner list.
4. If the only available nodes are hosting anti-affined groups, the Cluster service ignores anti-affinity and selects the next preferred available node as the destination node.
Use this property to identify groups that should not be hosted on the same node. Come up with a unique string value (MS docs suggest a GUID, but I like descriptive string) and add it to the AntiAffinityClassNames property of each group that should be anti-affined.
What will it NOT do?
As mentioned in point 4 above, sometimes you don’t have enough hosts to avoid placing too VM’s on the same host. With this reality in mind, anti-affinity does not guarantee that groups will never be hosted by the same node. If you have an application that cannot support more than one instance per node under any circumstances, you need to create a resource DLL to enforce that limitation.
How to configure anti-affinity
To configure anti-affinity between VM’s, you basically assign each of the VM you’d like to keep separated, the same AntiAffinityClassNames value using the cluster command-line administration tool. This could be two virtual machines are more than two. The name of the resource group basically maps to the name of the VM as appears in the Failover Cluster Management tool. Syntax is shown here:
cluster group “<Name of Resource Group>” /prop AntiAffinityClassNames=”SQLClusterNode”
After you configure these values, failover clustering will do its best to honor the settings based on the points listed above. You can also configure different preferred owners for each anti-affined VM guest in the Failover Cluster Management interface as well if you wish to ensure these hosts remain separate. With him
What about VMM and Dynamic Optimization?
In VMM 2012, where dynamic optimization re-evaluates and optimizes distribution of the VM load every 10 minutes, there is no built-in process to make sure two cluster groups (virtual servers in this case) that are anti-affined are running on different hosts.
One suggestion is to write a PowerShell script that queries the cluster service for all anti-affinity groups periodical, and then checks VMM to ensure the VMs in the anti-affinity groups are not the same physical host. You’d want to run the script every few minutes ensure that redistribution of resources didn’t cause the virtual servers in a resource pool to end up on the same host. (dynamic optimization evaluates load distribution every ten minutes by default)
Another option would be to exclude guests from dynamic optimization that have anti-affinity settings defined.
Here are a few additional private cloud-related posts featuring System Center 2012 and related technologies that may be of interest