yblaz - Fotolia
It isn't difficult to create affinity and anti-affinity rules for VMs and host systems, but it's important to consider...
some of the potential pitfalls and problems you might encounter along the way. One common example is VM-VM affinity rule conflicts. It's certainly possible to create multiple VM-VM affinity rules, but it is also possible for these rules to conflict.
For example, a conflict occurs when one rule keeps two VMs together on the same system, while another rule inadvertently keeps those same two VMs apart on the same system. Conflicting rules cannot run together. Older rules typically take precedence over newer rules, and anti-affinity rules typically take precedence over affinity rules. Administrators can edit or disable conflicting rules.
VM-host rule conflicts can also occur. VM-host rules are all applied equally. Suppose the same VM is included in two different VM-host affinity rules specifying two different host groups; the VM can only run on hosts included in the two different host groups. As with VM-VM rules, the older VM-host rules usually take precedence over newer rules. VMware platforms, like Distributed Resource Scheduler (DRS), vSphere High Availability (HA) and vSphere Distributed Power Management (DPM) will never violate a must or must not rule -- though they can violate should or should not rules.
The effects of rule conflicts
Rule conflicts and other unintended violations can cause functional or performance problems -- DRS, HA and DPM might not operate as intended. For example, DRS won't migrate VMs to enable a host maintenance mode if the migration violates a must or must not rule. Similarly, DRS won't spin up VMs, DRS won't migrate VMs for load balancing, vSphere HA won't fail over VMs and vSphere DPM won't migrate VMs to put hosts into standby mode if these operations result in a must or must not rule violation.
The easiest way to prevent functional problems due to rule violations is to use should or should not (preferential) rules rather than must or must not (required) rules. You should review rules, compare them against other rules and then test in a nonproduction environment before you deploy them in production. In addition, allocate enough hosts to the DRS group to ensure that rule snafus don't cause computing shortfalls. An administrator can employ alarms to report rule violations. For example, add an alarm to a VM using the VM is violating VM-host affinity rule as an event trigger.
Affinity rules can't read minds
It's important to point out that VM-host and VM-VM rules do not understand why those rules are implemented in the first place. That's beyond the scope of affinity and anti-affinity rules. For example, if you implement VM-host affinity rules to ensure that specific VMs only run on hosts with properly licensed software, the rules do not monitor whether those hosts are actually licensed properly or not. It's up to the business to correlate the rules to the reasons that provoked those rules. This might require a higher level of policymaking or periodic review to ensure that rules are still necessary and appropriate.
VM placement and migration are incredibly flexible -- these attributes contribute to why virtualization is so rewarding for the enterprise. But flexible VM placement doesn't mean random VM placement. New and failover instances should never be placed entirely by chance. A virtualization administrator can take advantage of VMware's DRS and HA affinity and anti-affinity rules to govern the way that VMs are placed with respect to hosts and other VMs. Still, there are limitations and issues that administrators must consider when working with affinity.
Prevent load-balancing hiccups by being prepared
Keep things running smoothly with smart HA and DRS rules
Save money by consolidating servers with DPM
Dig Deeper on DRS and DPM
Related Q&A from Stephen J. Bigelow
Containers have rapidly come into focus as a popular option for deploying applications, but they have limitations and are fundamentally different ... Continue Reading
ALM and SDLC both cover much of the same ground, such as development, testing and deployment. Where these lifecycle concepts differ is the scope of ... Continue Reading
Eliciting performance requirements from business end users necessitates a clearly defined scope and the right set of questions. Expert Mary Gorman ... Continue Reading