Host Affinity

In vSphere 4.1 VMware introduced a new feature call Host Affinity. Host Affinity allows for the creation of a “sub-cluster” within a VMware Cluster. This features lets a vSphere Administrator create a relationship between virtual machines and the ESX hosts on which they reside. The vSphere Administrator can configure rules that either allow virtual machines to run inside an ESX Host grouping or force these virtual machines to run outside this ESX Host grouping. If virtual machines are not specifically identified to run inside, or outside an ESX host grouping, they can drift in and out of an ESX host grouping.

Why should one consider Host Affinity? One use case is for ISV (Independent Software Vendor) licensing requirements. If an ISV requires that an organization license every ESX host the virtual machine can possibly run on inside the cluster, an organization can use Host Affinity configured with the “must run on hosts in this group” rule to limit which ESX hosts the virtual machine can reside. Organizations should check with their ISVs to ensure licensing compliance.

Another reason for using Host Affinity is for increased availability. Host Affinity, in combination with VMware HA allows for a higher level of availability. For example, a vSphere Administrator can configure an ESX Host DRS group in which they select ESX hosts that reside in different physical racks. The vSphere Administrator can then configure virtual machine anti-affinity rules to ensure the VMs do not run on the same ESX hosts. The net-net of this design is two virtual machines that will not reside on the same physical ESX hosts and hosts are in different physical racks. The virtual machines are protected against a hardware failure at the server level (meaning a physical server outage will not take down both virtual machines) and they are also protected against physical failure within the rack. Extending this example to a blade environment, use Host Affinity to create an ESX Host DRS group that has ESX hosts in different enclosures.

In the example below, we will create two (2) virtual machine DRS groups, one for the SQL virtual machines and one for the Exchange Mailbox Server virtual machines. We will create one ESX Host DRS group consisting of two (2) ESX hosts. We will then configure VM to Host Affinity rules to keep the SQL virtual machines inside the ESX Host DRS Grouping and the Exchange Mailbox virtual machines outside this ESX Host DRS grouping. The reason for this is to ensure we are meeting our SQL Licensing requirements and to keep the Exchange Mailbox server outside this ESX Host DRS grouping. All other virtual machines will be able to run on any of the ESX hosts in the cluster. Note, the lab I am working with has four (4) ESX Hosts, so the example below is for illustrative purposes and not necessary what one would do in a production environment.

In the diagram below, please note the the following:

  • CLUSTER02 has four (4) ESX Hosts
  • SQL2K8_01 is running on ESX06
  • SQL2K8_02 is running on ESX05
  • EX_2010_mbx01 is running on ESX07
  • EX_2010_mbx02 is running on ESX08

Screen_1

Next, create the virtual machine and ESX host DRS groups.

  • Right click the Cluster, and select Edit Settings… to bring up the properties dialog box.

Screen_2

  • Click on DRS Group Manager, the click on the Add… button inside the Virtual Machine DRS Group section to bring up the Virtual Machine DRS Group dialog box

Screen_3

  • Once the Virtual Machine DRS Group dialog box appears, give the DRS group a name (SQL VM DRS Group), then locate the virtual machines (in this case the SQL2K8 virtual machines) and move them from the “Virtual machines not in this DRS group” on the left to “Virtual machines in this DRS group” on the right using the >> button, and click OK to save the DRS Group configuration.

Screen_4

  • Repeate the same steps to create the Exchange MBX VM DRS Group.
  • Next, create the ESX Host DRS group – click the Add… button under Host DRS Groups to bring up the Host DRS Groups dialog box.

Screen_5

  • Once the ESX Host DRS Group dialog box appears, give the DRS group a name (SQL ESX Host DRS Group), then  located the ESX Hosts that will be part of this group (in this case ESX07 and ESX08) and move these ESX Hosts from the “Hosts not in this DRS group” on the left to “Hosts in this DRS group” on the right using the >> button. Click OK to save the DRS Group.

Screen_6

  • On the Cluster Settings dialog box, click Rules and then click Add.. to open the Rule dialog box
  • In the Rule dialog box, under Name, give the rule a name (SQL VM-Host Affinity)
  • Under Type, select Virtual Machines to Hosts
  • Under Cluster Vm Group: Select the appropriate group (created earlier, SQL VM DRS Group)
  • Next, select the affinity type and level, Must run on hosts in group
  • Under Cluster Host Group, select the ESX DRS group, SQL ESX Host DRS Group
  • Click OK to save the configuration and close the Rule dialog box

Screen_7

  • Click Add…, this time we are going to add the Exchange Mailbox server anti-affinity rules.
  • On the Rule dialog box, under Name, give the rule a name (Exchange_MBX VM-Host Anti-Affinity)
  • Under Type, select Virtual Machines to Hosts
  • Under Cluster Vm Group, select the previously configured Exchange MBX VM DRS Group
  • Next, select Must Not run on hosts in group
  • Under Cluster Host Group, select SQL ESX Host DRS Group
  • Click OK to save the settings.

Screen_8

We have configured virtual machine to ESX Host Affinity rules to keep our SQL virtual machines contained within our pre-defined sub-cluster and we have configured our Exchange mailbox servers so they will not run inside this sub-cluster. Next, we will create a virtual machine to virtual machine rule. This rule will be used to keep the Exchange mailbox servers on different hosts.

  • On the Cluster settings page, click Add… to bring up the Rule dialog box once again
  • Under Name, give the rule a name (Exchange_MBX_VMs Anti-Affinity
  • Under Type, select Separate Virtual Machines
  • Click Add… to bring up the Virtual Machine dialog box and select the appropriate virtual machines, in this case EX_2010_mbx01 and EX_2010_mbx02 and click OK to close the virtual machines dialog box

Screen_9

  • Click OK to close the Cluster settings dialog box. Once this is done, vCenter will apply the changes and begin to migrate virtual machines (because DRS is set to Fully automated) in adherence to the configuration changes.

Screen_10

After a minute, we see that vCenter Server has migrated virtual machines in accordance with our virtual machine to host affinity rules as well as our virtual machine to virtual machine anti-affinity rule.

  • SQL2K8_01 migrated from ESX06 to ESX07 (adhering to VM-ESX affinity rule)
  • SQL2K8_02 migrated from ESX05 to ESX08 (adhering to the VM-ESX affinity rule)
  • EX_2010_mbx01 migrated from ESX07 to ESX05 (adhering to VM-ESX Host anti-affinity rule)
  • EX_2010_mbx02 migrated from ESX08 to ESX06 (adhering to VM-ESX Host anti-affinity rule)
  • EX_2010_mbx01/EX_2010_mbx02 are not on the same host (adhering to VM-VM anti-affinity rule)

Screen_11

To prove strict adherence, we will attempt to migrate the SQL2K8_01 VM from ESX07 to ESX 05. Remember we configured the SQL 2K8 servers to run on ESX07 and ESX08, not ESX05 or ESX06.

screen_12

We can see from the error message above we are not able to move the virtual machine to an ESX Host that is not part of the ESX Host DRS Group.

For more information on Host Affinity, consult the VMware vSphere 4.1 Resource Management Guide

Post to Twitter Post to Delicious Post to Digg Post to StumbleUpon

  • http://twitter.com/szastak Jeff Szastak

    Anon,
    For the SQL Servers, if ESX07 and ESX08 both failed at the same time, the SQL Servers would be unavailable since VMware respects the MUST RUN ON THESE HOSTS affinity rule. If there are virtual machines on these hosts not part of the SQL VM-Host affinity group, they would move over to ESX05 or ESX06. To get the SQL Server VMs back up (following strict adherence to your ISV licensing), you will need to create a new ESX Host DRS Group and put the SQL Servers into this group. They will then power on and respect the rules of this new group. To get them up as fast as possible, uncheck the box next to the DRS Rule to disable the rule and the SQL VMs will start on any available host in the cluster. (Right click CLUSTER02 > Edit Settings > VMware DRS > Rules and uncheck the box next to SQL VM-Host Affinity). You can see the check box I am referring to in a screenshot above (3 up from the bottom of the article).
    For the Exchange MBX Servers, if ESX05 and ESX06 fail at the same time, the Exchange MBX servers would be unavailable since we configured the MUST NOT RUN ON THESE HOSTS affinity rule and VMware will respect this affinity rule. Virtual machines not part of this anti-affinity group would move over to ESX07 and ESX08, and to get the Exchange MBX servers back up and running we would either create a new ESX Host DRS Rule or uncheck the box next to the ESX_MBX VM-Host Anti-Affinity rule we created). For the Exchange Mailbox Server we could have configured them with the “Should Not run on hosts in this group” and the Exchange MBX Server will not run on ESX 07 or ESX08 unless ESX05 and ESX06 are unavailable. Meaning if ESX05 and ESX06 are both unavailable the EX_MBX server will move over to ESX07 and ESX08.