In multi-tenant environments, it is sometimes necessary to configure certain virtual machines so that they never reside on the same host server. For example, if your organization were hosting virtual machines for both Coke and Pepsi, you would not want the two companies’ virtual machines to reside on a common host server.
It is relatively easy to keep virtual machines separate from one another when you initially create the virtual machines. However, virtual machines are anything but static and the chances of a virtual machine remaining on the same Hyper-V host for an indefinite period of time are slim.
If you have virtual machines that need to be kept separate, you can reduce the chances of those virtual machines ever ending up on a common host by using anti-affinity rules. Anti-affinity rules prevent virtual machines that must remain separate from failing over to a common host.
Unfortunately, anti-affinity rules are not exactly easy to work with. These rules can only be established through PowerShell, and the process is not very intuitive.
The key to understanding how the process works is to understand that for every clustered virtual machine, there is a corresponding cluster group.
Each cluster group uses the same name as the virtual machine for which it was created. Anti-affinity rules are applied to cluster groups, not to
Figure 4.19
Cluster groups are made up of a number of properties.
As you look at the properties in the screen capture above, you will notice that the third property from the bottom of the list is named AntiAffinityClassNames.
Creating an anti-affinity rule involves assigning a value to this property.
Normally you could modify this type of value by using a command like this:
Get-ClusterGroup <virtual machine name> | Set-ClusterGroup – AntiAffinityClassNames <value>
However, there is just one problem with the command shown above—there is no Set-ClusterGroup cmdlet. The fact that such a command does not exist is a safety precaution—if a Set-ClusterGroup cmdlet did exist, you could potentially destroy a virtual machine if you used the cmdlet incorrectly.
Since you can’t use Get-ClusterGroup and Set-ClusterGroup, you have to use a completely different approach to modifying the AntiAffinityClassNames property.
Unfortunately, Windows PowerShell does not contain the code for managing the AntiAffinityClassNames property. However, you can download a PowerShell module that makes it possible to directly manipulate this property. In case you are not familiar with the concept of a PowerShell module, it is basically a collection of PowerShell cmdlets that can be bolted on to the core cmdlet set.
You can download the PowerShell Module for Configuring AntiAffinityClassNames in Failover Clustering at:
. This module is designed for use with Windows Server 2008 R2, but it works with Windows Server 2012 as well.
The download consists of a ZIP file. You will need to download the ZIP file and extract its contents to the server’s hard disk. The path that you use is up to you, but you will have to enter the full path into PowerShell, so it is beneficial to use a relatively simple path. For demonstration purposes this example places the extracted files into a folder named C:\Modules.
Once you have extracted the zip file’s contents, you’ll need to import
the module into PowerShell. Note that importing a module is not a permanent operation. The module only remains imported for as long as PowerShell is open. If you need to use the module again at a later time, you will have to import it again.
Before you can import the module, you will have to configure your server’s execution policy to allow PowerShell scripts to be run. The easiest way to do this is to enter the following command:
Set-ExecutionPolicy Unrestricted
This command allows PowerShell to run any PowerShell script, regardless of where it came from (Figure 4.20). Obviously, there are some security implications associated with allowing unrestricted access to scripts, as explained in the text shown below (Figure 4.20). If you are concerned about security, you can set the execution policy back to Restricted when you finish working with the AntiAffinityClassNames by using the Set-ExecutionPolicy Restricted cmdlet.
Figure 4.20
You must configure the execution policy to allow PowerShell scripts to be run.
With that said, you can use the following command to import the module (assuming that the module resides in C:\modules):
Import-Module C:\Modules\AntiAffinityClassNames
When you execute the command listed above, you will see several prompts asking if you want to allow the script to run (Figure 4.21). You must run each of these scripts in order to successfully import the module.
Figure 4.21
Figure 4.22
The AntiAffinityClassNames module adds three new cmdlets to PowerShell.
Now that all of the necessary components are in place, you can begin working with anti-affinity rules. The basic idea behind these rules is that certain servers should never reside on the same hosts. You can specify these servers by
adding a value to the AntiAffinityClassNames parameter. Servers with the same AntiAffinityClassNames parameter will not normally fail over to a common host.
A more concrete example of how this works is a situation in which
an organization has multiple virtualized domain controllers. You would never want to be in a situation in which all of your domain controllers failed over to the same host. That being the case, you could add the phrase “Domain Controller” to each domain controller’s AntiAffinityClassNames parameter to indicate that each server that uses this tag is a domain controller and that each domain controller should reside on a separate host. To be perfectly clear, the “Domain Controllers” value is just an example—you can call your anti-affinity values anything that you want.
Setting up anti-affinity rules in this manner does not guarantee that the virtual machines will never be hosted on the same server. If the cluster is ever put into a situation where there aren’t enough remaining cluster nodes to facilitate the requirements of the anti-affinity rules, Windows will place the virtual machines wherever it can. The assumption is that it is more important to keep the virtual machines running than it is to keep them separated.
Now you can configure anti-affinity rules by using the Set-AntiAffinityClassNames cmdlet. This cmdlet requires you to specify the name of the cluster, the cluster group to which the rule should apply (the cluster group name is the same as the virtual machine name), and the value that you want to assign. Suppose, for example, that your cluster is named HyperVCluster and that you want to assign an AntiAffinityClassNames value of “Domain Controller” to a virtual machine named VM3. To do so, use the following command:
Set-AntiAffinityClassNames –Cluster HyperVCluster –ClusterGroup VM3 – Value “Domain Controller”
It is worth noting that the Set-AntiAffinityClassNames cmdlet sometimes has trouble recognizing a cluster name. You may receive an error telling you to check the spelling of the cluster name. If that happens, enter the Get-AntiAffinityClassNames cmdlet (Figure 4.23). By doing so, you might find that the cluster name is listed as localhost rather than by its designated name.
Figure 4.23
The cluster name is sometimes listed as localhost.
When you successfully assign a value to the AntiAffinityClassNames property, PowerShell does not acknowledge the success of the operation. The easiest way to confirm that the operation was successful is to enter the
Get-AntiAffinityClassNames cmdlet (Figure 4.24).
Figure 4.24
Use the Get-AntiAffinityClassNames cmdlet to verify the success of the operation.