Skip to content

Affinity/Anti-Affinity

Multiple instances of the same service or application should be deployed in different availability zones to avoid service disruption in case of an infrastructure outage. When this isn't possible or isn't enough to guarantee your application availability you can use an anti-affinity schedule policy. An affinity policy is also available and a soft version as well. Soft versions won't restrict VMs scheduling to a signle host and will act as a best effort mechanism.

We recommend using soft-affinity and soft-anti-affinity types to avoid VM scheduling failures
openstack server group create  --os-compute-api-version 2.15 --policy soft-anti-affinity my-soft-anti-affinity-group
openstack server group create  --os-compute-api-version 2.15 --policy soft-affinity my-soft-affinity-group

Create a server group

First you need to create a "server group". The server group will contain all the instances to which you want to apply an anti-affinity/affinity policy.

$ openstack server group create --policy <policy> <name>

with:

  • policy : Add a policy. we recommended the soft versions among soft-affinity soft-anti-affinity affinity and anti-affinity. Defaults to affinity.

  • name : New server group name

Example:

taylor@laptop:~$ openstack server group create  --os-compute-api-version 2.15 --policy soft-anti-affinity my-policy
+----------+--------------------------------------+
| Field    | Value                                |
+----------+--------------------------------------+
| id       | 202cd313-30c0-4db3-8eab-62cb131fe6ec |
| members  |                                      |
| name     | my-policy                            |
| policies | soft-anti-affinity                   |
+----------+--------------------------------------+

  • You can see your server groups with:
    $ openstack server group list [--long]
    

Example:

taylor@laptop:~$ openstack server group list
+--------------------------------------+------------------------+--------------------+
| ID                                   | Name                   | Policies           |
+--------------------------------------+------------------------+--------------------+
| 79bff002-2228-433c-974c-f5097cc3fa64 | taylor-564-group-nodes | anti-affinity      |
| 7be47cd5-685d-47c6-9a47-c7a00d66e6cf | taylor-67-group-nodes  | anti-affinity      |
| aebb58c0-caf2-43d2-b874-1c0281575425 | taylor-316-group-nodes | anti-affinity      |
| 6f1303d6-e21f-4d8c-a16b-275de0913821 | taylor-883-group-nodes | anti-affinity      |
| 202cd313-30c0-4db3-8eab-62cb131fe6ec | my-policy              | soft-anti-affinity |
| 1f50d63c-8460-418d-b532-2e4a3fb43d4d | same-hypervisor        | affinity           |
+--------------------------------------+------------------------+--------------------+

  • Display server group detail

    $ openstack server group show <uuid>
    

  • Delete server group

    $ openstack server group delete <uuid>
    

Affinity1

  • Name your server group and choice a policy

Affinity2

Info

If you want all the instances to be hosted on different compute nodes, create a server group with an anti-affinity policy. Otherwise use an affinity policy.

Create an instance and apply a schedule policy

To add an instance to a server group, use the following extra option when creating a new instance.

--hint group=<server_group_uuid>

Example:

$ openstack server create --image <image_uuid> --flavor <flavor_name> --hint group=<server_group_uuid> <new_instance_name>

Affinity3

Warning

You can only add an instance to a server group at instance creation time. Not afterwards! When using an affinity policy you are limited to the resources available in the compute node where the first instance was scheduled.