SupportConsoleDevelopersStart a trialContact

6.11. Affinity Groups

6.11.1. Affinity Groups

You can create Affinity Groups to help determine where selected virtual machines run in relation to each other and to specified hosts. This capability helps manage workload scenarios such as licensing requirements, high-availability workloads, and disaster recovery.

The VM Affinity Rule

When you create an Affinity Group, you select the virtual machines that belong to the group. To define where these virtual machines can run in relation to each other, you enable a VM Affinity Rule: A Positive affinity rule tries to run the virtual machines together on a single host; a Negative affinity rule tries to run the virtual machines on separate hosts. If the rule cannot be fulfilled, the outcome depends on whether the weight or filter module is enabled.

The Host Affinity Rule

Optionally, you can add hosts to the Affinity Group. To define where virtual machines in the group can run in relation to hosts in the group, you enable a Host Affinity Rule: A Positive affinity rule tries to run the virtual machines on hosts in the affinity group; a Negative affinity rule tries to run the virtual machines on hosts that are not in the affinity group. If the rule cannot be fulfilled, the outcome depends on whether the weight or filter module is enabled.

The Default Weight Module

By default, both rules apply the weight module in the cluster’s scheduling policy. With the weight module, the scheduler attempts to fulfill a rule, but allows the virtual machines in the affinity group to run anyway if the rule cannot be fulfilled.

For example, with a positive VM Affinity Rule and the weight module enabled, the scheduler tries to run all of the affinity group’s virtual machines on a single host. However, if a single host does not have sufficient resources for this, the scheduler runs the virtual machines on multiple hosts.

For this module to work, the weight module section of the scheduling policies must contain the VmAffinityGroups and VmToHostsAffinityGroups keywords.

The Enforcing Option and Filter Module

Both rules have an Enforcing option which applies the filter module in the cluster’s scheduling policy. The filter module overrides the weight module. With the filter module enabled, the scheduler requires that a rule be fulfilled. If a rule cannot be fulfilled, the filter module prevents the virtual machines in the affinity group from running.

For example, with a Positive Host Affinity Rule and Enforcing enabled (the filter module enabled), the scheduler requires the virtual machines in the affinity group to run on hosts that are part of the affinity group. However, if those hosts are down, the scheduler does not run the virtual machines at all.

For this module to work, the filter module section of the scheduling policies must contain the VmAffinityGroups and VmToHostsAffinityGroups keywords.

Examples

To see how these rules and options can be used with one another, see Affinity group examples.

Warning
  • For affinity labels to work, the filter module section of the scheduling policies must contain Label.
  • If an affinity group and affinity label conflict with each other, the affected virtual machines do not run. To help prevent, troubleshoot, and resolve conflicts, see Affinity group troubleshooting.
Important

Each rule is affected by the weight and filter modules in the cluster’s scheduling policy.

  • For the VM Affinity Rule rule to work, the scheduling policy must have the VmAffinityGroups keyword in its Weight module and Filter module sections.
  • For the Host Affinity Rule to work, the scheduling policy must have the VmToHostsAffinityGroups keyword in its Weight module and Filter module sections.

For more information, see Scheduling Policies in the Administration Guide.

Note
  • Affinity groups apply to virtual machines in a cluster. Moving a virtual machine from one cluster to another removes it from the affinity groups in the original cluster.
  • Virtual machines do not have to restart for the affinity group rules to take effect.

6.11.2. Creating an Affinity Group

You can create new affinity groups in the Administration Portal.

Creating Affinity Groups

  1. Click Compute Virtual Machines and select a virtual machine.
  2. Click the virtual machine’s name to go to the details view.
  3. Click the Affinity Groups tab.
  4. Click New.
  5. Enter a Name and Description for the affinity group.
  6. From the VM Affinity Rule drop-down, select Positive to apply positive affinity or Negative to apply negative affinity. Select Disable to disable the affinity rule.
  7. Select the Enforcing check box to apply hard enforcement, or ensure this check box is cleared to apply soft enforcement.
  8. Use the drop-down list to select the virtual machines to be added to the affinity group. Use the + and - buttons to add or remove additional virtual machines.
  9. Click OK.

6.11.3. Editing an Affinity Group

Editing Affinity Groups

  1. Click Compute Virtual Machines and select a virtual machine.
  2. Click the virtual machine’s name to go to the details view.
  3. Click the Affinity Groups tab.
  4. Click Edit.
  5. Change the VM Affinity Rule drop-down and Enforcing check box to the preferred values and use the + and - buttons to add or remove virtual machines to or from the affinity group.
  6. Click OK.

6.11.4. Removing an Affinity Group

Removing Affinity Groups

  1. Click Compute Virtual Machines and select a virtual machine.
  2. Click the virtual machine’s name to go to the details view.
  3. Click the Affinity Groups tab.
  4. Click Remove.
  5. Click OK.

The affinity policy that applied to the virtual machines that were members of that affinity group no longer applies.

6.11.5. Affinity Groups Examples

The following examples illustrate how to apply affinity rules for various scenarios, using the different features of the affinity group capability described in this chapter.

Example 6.1. High Availability

Dalia is the DevOps engineer for a startup. For high availability, a particular system’s two virtual machines should run on separate hosts anywhere in the cluster.

Dalia creates an affinity group named "high availability" and does the following:

  • Adds the two virtual machines, VM01 and VM02, to the affinity group.
  • Sets VM Affinity to Negative so the virtual machines try to run on separate hosts.
  • Leaves Enforcing cleared (disabled) so that both virtual machines can continue running in case only one host is available during an outage.
  • Leaves the Hosts list empty so the virtual machines run on any host in the cluster.

Example 6.2. Performance

Sohni is a software developer who uses two virtual machines to build and test his software many times each day. There is heavy network traffic between these two virtual machines. Running the machines on the same host reduces both network traffic and the effects of network latency on the build and test process. Using high-specification hosts (faster CPUs, SSDs, and more memory) further accelerates this process.

Sohni creates an affinity group called "build and test" and does the following:

  • Adds VM01 and VM02, the build and test virtual machines, to the affinity group.
  • Adds the high-specification hosts, host03, host04, and host05, to the affinity group.
  • Sets VM affinity to Positive so the virtual machines try to run on the same host, reducing network traffic and latency effects.
  • Sets Host affinity to Positive so the virtual machines try to run on the high specification hosts, accelerating the process.
  • Leaves Enforcing cleared (disabled) for both rules so the virtual machines can run if the high-specification hosts are not available.

Example 6.3. Licensing

Bandile, a software asset manager, helps his organization comply with the restrictive licensing requirements of a 3D imaging software vendor. These terms require the virtual machines for its licensing server, VM-LS, and imaging workstations, VM-WS#, to run on the same host. Additionally, the physical CPU-based licensing model requires that the workstations run on either of two GPU-equipped hosts, host-gpu-primary or host-gpu-backup.

To meet these requirements, Bandile creates an affinity group called "3D seismic imaging" and does the following:

  • Adds the previously mentioned virtual machines and hosts to the affinity group.
  • Sets VM affinity to Positive and selects Enforcing so the licensing server and workstations must run together on one of the hosts, not on multiple hosts.
  • Sets Host affinity to Positive and selects Enforcing so the virtual machines must run on either of the GPU-equipped the hosts, not other hosts in the cluster.

6.11.6. Affinity Groups Troubleshooting

To help prevent problems with affinity groups

  • Plan and document the scenarios and outcomes you expect when using affinity groups.
  • Verify and test the outcomes under a range of conditions.
  • Follow change management best practices.
  • Only use the Enforcing option if it is required.

If you observe problems with virtual machines not running

For possible conflicts between affinity labels and affinity groups

  • If an affinity label and affinity group conflict with each other, the intersecting set of virtual machines do not run.

  • To determine whether a conflict is possible:

    • Inspect the filter module section of the cluster’s scheduling policies. These must contain both a Label keyword and a VmAffinityGroups OR VmToHostsAffinityGroups keyword. Otherwise, a conflict is not possible. (The presence of VmAffinityGroups and VmToHostsAffinityGroups in the weight module section does not matter because Label in a filter module section would override them.)
    • Inspect the affinity groups. They must contain a rule that has Enforcing enabled. Otherwise, a conflict is not possible.

  • If a conflict is possible, identify the set of virtual machines that might be involved:

    • Inspect the affinity labels and groups. Make a list of virtual machines that are members of both an affinity label and an affinity group with an Enforcing option enabled.
    • For each host and virtual machine in this intersecting set, analyze the conditions under which a potential conflict occurs.
  • Determine whether the actual non-running virtual machines match the ones in the analysis.
  • Restructure the affinity groups and affinity labels to help avoid unintended conflicts.
  • Verify that any changes produce the expected results under a range of conditions.
  • If you have overlapping affinity groups and affinity labels, it can be easier to view them in one place as affinity groups. Consider converting an affinity label into an equivalent affinity group, which has a Host affinity rule with Positive selected and Enforcing enabled.
Red Hat logoGithubRedditYoutubeTwitter

Learn

Try, buy, & sell

Communities

About Red Hat Documentation

We help Red Hat users innovate and achieve their goals with our products and services with content they can trust.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. For more details, see the Red Hat Blog.

About Red Hat

We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.

© 2024 Red Hat, Inc.