If you are running Exchange 2010 in a virtualized environment, chances are that you are doing so in a cluster with multiple host servers; whether they are running VMware ESX, Microsoft Hyper-V or any other’s vendor hypervisor. In this article, we will take a look at how to achieve this for Exchange servers. (Note that this approach is actually valid for any other type of VM)
To minimize the risk that the failure of a single host affects multiple Exchange servers (and thus possibly causing more damage), you’d logically want the Exchange servers to run each on a separate host server – also after a failure. By doing so, you increase the resiliency of your Exchange environment because a single host failure will not be able to take out your entire Exchange environment. The same logic applies to any other application running on multiple servers (e.g. Domain Controllers).
Let’s take the example of a 3-node cluster with 2 Exchange servers:
- On the first Hyper-V Host Server, we are running our first Exchange Server along with another VM
- The second Hyper-V server is running our second Exchange server and some other VMs
- The third Hyper-V host is only running some other VMs
In case our first server would fail, the EX01 VM would – by default – be allocated to one of the other available nodes which is running the lowest amount of VMs. In this case, that would be Hyper-V HOST3 (only running 2 VMs vs. 3 on HOST2). Because EX01 is moved to HOST3, both Exchange servers are still running on a separate host; so there’s no real issue here.
However, consider the following situation:
The third host is now running more VM’s than the second host. In case of a failure of the first Hyper-V server, the EX01 VM would normally be moved to the second Hyper-V host which is already running an Exchange server…
Although this does not necessarily need to be a problem, since it’s very unlikely that you will lose two hosts at once or with little time between failures, it is possible that you somehow also lose your second server and as a result fail both your Exchange servers and therefore your entire messaging environment. A scenario which you – obviously – would want to avoid.
“AntiAffinityClassNames” is a cluster group property which allows you to configure where Hyper-V will attempt to move a VM to (e.g. after a failure). You need to configure each VM (cluster group) with a similar value for the property. When a failure occurs and Hyper-V needs to move the VM from the failed host to another host, it will take the value of this property into consideration and avoid moving a VM to a host which already runs another VM with the same value for that property. Only if there’s no other alternative Hyper-V server available, both VMs will be placed on the same host.
Let’s take the example of above, but this time the AntiAffinityClassNames property has been set to “EXCH” on both Exchange servers:
If the first Hyper-V host would fail, normally the EX01 Virtual Machine would be moved to the second host because that hosts runs less VMs than the third one. However; because of the property we’ve just set, Hyper-V would notice that there is already a similar VM running on the second host and it will move the EX01 VM to the third host anyway:
The second VM that was running on HOST1 would be moved to HOST2 since we haven’t made any change to it’s configuration.
Unfortunately, there is no GUI where you can simply enter a value for that property. The property can only be set using the cluster.exe command line tool:
cluster group “<name>” /prop AntiAffinityClassNames=”<value>”
If we take the example above, we would need to enter the following:
cluster group “EX01” /prop AntiAffinityClassNames=”EXCH”
cluster group “EX02” /prop AntiAffinityClassNames=”EXCH”
To view if or what value has been set for a specific cluster group (VM), type the following:
cluster group “<name>” /prop (e.g. cluster group “EX01” /prop)
For more information on the AntiAffinityClassNames property, take a look here.
Michael Van Horenbeeck