Anti-Affinity Groups

Anti-Affinity Groups let you specify which instances should run on separate hosts. In an HA cluster, for example, you could keep your instances on separate hypervisors to ensure more reliable fault tolerance. Two instances in the same anti-affinity group will spawn on different hypervisors. After creation, your instance will stay on its hypervisor for its entire life. It is best practice to define your groups in advance for a proper distribution strategy.

An example of how Anti-Affinity Groups may prove helpful would be associating your instances with different groups based on their role. You could define one Anti-Affinity Group for the database servers and another Anti-Affinity Group for the front servers. In this way, any issue on one hypervisor will not affect your entire infrastructure.

If you need more than eight instances per Anti-Affinity Group, you could split the group in two to grant the best spread. Anti-Affinity Groups let you specify which instances should run on separate hosts. In an HA cluster, for example, you could keep your instances on separate hypervisors to ensure more reliable fault tolerance.

From COMPUTE in the Portal, select the ANTI-AFFINITY section. You can then create, delete, or view the details of your groups, and in the detail of a group, you can see the instances attributed to that group.

Associating Anti-Affinity Groups

When you create an instance, you will see a list of your Anti-Affinity Groups. You can choose to associate your instance with any number of groups. Please note that you will have this option only during the instance creation. Although there is no limit to the number of groups you may have, an Anti-Affinity Group cannot contain more than 8 instances. If a group is full, it will not be presented in the available options.

How to Use Anti-Affinity Groups

Two instances on the same group will be spawned on different hypervisors.

After creation, your instance will stay on its hypervisor for its entire life. To define a proper distribution strategy, it is best practice to define your groups in advance.

An example of how Anti-Affinity Groups may prove useful would be to associate your instances to different groups based on their role. You could define one Anti-Affinity Group for the database servers and another Anti-Affinity Group for the front servers. In this way, any issue on one hypervisor will not affect your entire infrastructure.

If you find yourself needing more than 8 instances per Anti-Affinity Group, a possible strategy would be to split a group in two to grant the best spread possible.