Using server affinity for HA

Server affinity refers to the practice of ensuring compute instances are either: allocated to the same or allocated to explicitly different hypervisors (physical servers). The process of having your instances allocated on the same hypervisor is known as server “affinity” and the process of separating your instances across hypervisors is known as server “anti-affinity”

Server affinity is useful when you want to ensure that the data transfer amongst compute instances is as fast as possible. On the other hand it may increase CPU contention or reduce the availability of your application (a single server going down affects all compute instances in the group.)

Server anti-affinity is useful when you want to increase the availability of an application within a region and create redundancy for your compute instances. Compute instances in an anti-affinity group are placed on different physical servers, ensuring that the failure of a server will not affect all your compute instances simultaneously.

Soft-affinity is respectively similar to normal affinity. There is a key different however in that this policy only attempts to run all servers on the same hypervisor host. If this is not possible, this policy ensures that your remaining servers start on as few other hypervisor hosts as possible.

Soft anti-affinity follows almost the same behavior as the regular anti-affinity policy, only this policy ensures that your servers start on as many differing hypervisor hosts as possible, even if some servers must end up sharing the same hypervisor.

Warning

When deciding which server affinity type to use, please keep in mind that the policy behavior you choose will effect your servers behavior should a hypervisor experience a failure.

  • In the case of the affinity policy, if the hypervisor your instances are running on goes down then all instances that are part of that group may be unavailable for a period of time.

  • If you are using an anti-affinity policy and there is a hypervisor crash, an affected instance may not be migrated until another hypervisor becomes available that can support that same policy.

Using the dashboard

There are two parts to the management of server groups. The first part is the creation of a server group, that has the policy that you want. The next is adding instances to your server group.

Starting with the creation of your server group, we first need to navigate to the server groups section of the dashboard:

../_images/Server-group-mainpage.png

From here we select + Create Server Group and the following screen will appear:

../_images/server-group-create.png

After we input a name and select the policy that we want our group to have (in our case we will use Anti-affinity, since this is the most common policy) we click submit and wait for our server group to build.

../_images/server-groups-filled-in.png

Once our group is created we should be able to see it from this page:

../_images/server-group-created.png

Now that we have our created Anti-affinity group, we can start adding instances to it. It is important to note that only new instances can be added to a server group. You cannot add instance that have already been created because the server group cannot retroactively enforce its policies on them. You can declare the server group you want your instance to be a part of when creating it, from the following screen:

../_images/create-instance-server-group.png

Using programmatic methods

Note

Before using any of the following methods, you will have to source your environment variables using an openRC file.

To create a server group:

openstack server group create --policy $policy $groupname

Where:

  • $groupname is a name you choose (eg: app-servers)

  • $policy is anti-affinity

To list server groups:

openstack server group list

To delete a server group:

openstack server group delete $groupid

Deleting a server group does not delete the compute instances that belong to the group.


Once you have created a server group, any new instances that you create can be added to it. You can do this by passing a hint to our cloud scheduler when creating your instance, to indicate it belongs to a server group. This is done using the --hint group=$GROUP_ID parameter, as indicated below.

openstack server create --flavor $CC_FLAVOR_ID --image $CC_IMAGE_ID
--key-name $KEY_NAME --security-group default --security-group $SEC_GROUP
--nic net-id=$CC_PRIVATE_NETWORK_ID --hint group=$GROUP_ID first-instance

Note

If you receive a No valid host was found error, it means that the cloud scheduler could not find a suitable server to honour the policy of the server group. For example, we may not have enough capacity on the same hypervisor to place another instance in affinity, or enough hypervisors with sufficient capacity to place instances in anti-affinity.

Via the APIs

Please refer to the server groups API calls at https://docs.openstack.org/api-ref/compute/#server-groups-os-server-groups.