In Apache CloudStack, Host Affinity and Host Anti-Affinity refer to the ability to deterministically ensure that a set of Instances run on the same or diverse hypervisor hosts in order to meet specific workload needs.
How Affinity Groups Worked Previously
Before Apache CloudStack 4.18 there were two types of Affinity Groups: Host Affinity and Host Anti-affinity.
• Host Affinity
Host Affinity Groups allow users to specify that a set of Instances should always run on the same hypervisor host. This ensures minimum latency and maximum bandwidth between Instances as there’s no need for the network traffic to leave the hypervisor. However, if there isn’t enough capacity in a given hypervisor host to run all Instances in the group the Instance deployment will fail.
• Host Anti-Affinity
On the other hand, Host Anti-Affinity Groups allow for users to specify that a set of Instances should always run on different hypervisor hosts, this ensures that the application is spread horizontally through multiple hypervisor hosts, increasing application availability in the case of failure of a hypervisor host. However, in case there isn’t available capacity in enough diverse hypervisor hosts to run all Instances in the group, the Instance deployment will fail.
Introducing CloudStack Adaptive Affinity Groups
Adaptive Affinity Groups is a new feature in Apache CloudStack 4.18 which brings extra flexibility to Instance deployment. The functionality is very similar to the pre-existing one, the only difference being that the Instance deployment requirements (affinity or anti-affinity) will be performed in a best-efforts manner, and the Instance deployment will still succeed even if there isn’t enough hypervisor host capacity available to meet such requirements.
The pre-4.18 Affinity Group types continue to exist in later versions of ACS, but have been renamed to host affinity / anti-affinity (strict).
• Non-strict Host Affinity Group
In this case, the instances will be deployed together on the same host only if possible. If there isn’t enough capacity on the host to fulfil the Affinity Group’s requirements, CloudStack will still deploy the new Instance to another available hypervisor host.
• Non-strict Host Anti-Affinity Group
In this case, the instances will be deployed on diverse hosts only if possible. If there isn’t enough capacity on the cluster to fulfil the Affinity Group’s requirements, CloudStack will still deploy the new Instance to the same hypervisor host of a previously deployed one.
Determining a target Host for Instances with Strict and Non-Strict Affinity Groups
Before Apache CloudStack 4.18, users were only able to associate Instances with Strict Affinity Groups. If the requirements were not met when CloudStack defined the target Host for the Instance allocation, the Instance’s deployment (or start-up process) would fail, as shown in the following diagram:
Strict Affinity Groups still exist in order to meet user application requirements, but if these requirements can be met in a more flexible manner, then the use of Non-Strict Affinity Groups is recommended. In this case, CloudStack will check the availability or resources in order to meet what the Affinity Group rule says and, if not possible, it will then allocate the Instance to another host as if it did not belong to any Affinity Group. In this case, the allocation algorithm “vm.allocation.algorithm” defined in the global settings will be used.
The destination host for Instances with Non-Strict Affinity Groups is determined by host priorities. Hosts have a default priority of 0 and if there is an Instance in the same Non-Strict Anti-Affinity Group on the Host, this priority is then decreased by 1. All available Hosts are reordered with their priorities when deploying or starting an Instance.
Here are some examples of how Host priorities are calculated:
Example 1: The instance has a Non-Strict Host Anti-Affinity Group.
If Host-1 has 2 Instances in a group and Host-2 has 3. Host-1’s priority is equal to -2 and Host-2’s priority is equal to -3. If there are only 2 hosts, the Instance will be deployed to Host-1 as it has higher priority (-2 > -3).
Example 2: The Instance has a Non-Strict Host Affinity Group.
If Host-1 has 2 Instances in the group and Host-2 has 3, in this case, Host-1’s priority is equal to 2 and Host-2’s priority is equal to 3. If there are only 2 hosts, the Instance will be deployed to Host-2 (3 >2).
Example 3: The Instance has a Non-Strict Host Affinity Group and also a Non-Strict Host Anti-Affinity Group.
If Host-1 has 2 Instances in the Non-Strict Host Affinity Group, and 3 in the Non-Strict Host Anti-Affinity Group, then Host-1’s priority is calculated by:
0 (default) + 2 (Instances in Non-Strict Host Affinity Group) – 3 (Instances in the Non-Strict Host Anti-Affinity Group) = -1
Conclusion
With the increased Instance deployment flexibility brought by Adaptive Affinity Groups in Apache CloudStack 4.18, users can further refine the distribution of instances to better meet their application’s workload requirements.
Wei Zhou works as a Software Architect at ShapeBlue. He has many years experience on cloud computing and a passion for various cutting-edge knowledge. Wei works on software design and implementation, as well as resolving issues for customers and community users. Wei has been a committer of the Apache CloudStack project since 2013 and a PMC member since 2017.
