In vSphere, the Distributed Resource Scheduler is a great service to use to automate vSphere’s ability to balance workloads in ways that make sense from a resource perspective. However, sometimes, workload management requires additional thought beyond just “are there enough resources to support it” scenarios.
Affinity rules – VM/VM
At times, you need to ensure that multiple virtual machines are always running on the same host. As such, if one of the virtual machines is vMotioned to a different host, the associated virtual machines must be moved as well. The scenario is common between, for example, application and database servers where keeping communications between the VMs on the same host is preferable to having that communication traverse a network link.
These kinds of needs are addressed through the creation of affinity rules.
Affinity rules – Host/VM
In other cases, it’s not important to maintain VM to VM communication, but you need to make sure that certain workloads always run on the same host. Many companies, for example, want to know on which host vCenter is running or they may have an application running inside a virtual machine, but that application is tied via licensing rules to the current vSphere host. Administrators can create virtual machine to host affinity rules to make sure that these virtual machines are never migrated to other hosts. Of course, the downside here is that the failure of the host will result in the workload going down as well.
Anti-affinity rules – VM/VM
Finally, there are times during which certain virtual machines should not run on the same host. For example, most organizations want to make sure that at least one domain controller remains available at all times, so those organizations will create VM to VM anti-affinity rules which state that these virtual machines are to run on different hosts, even if performance would be better by combining them.