Skip to content

VM placement

Availability zones

When an application has been made cloud-aware and it can tolerate single VM failure, availability can be further improved by placing VMs in different parts of the data centres.

An availability zone is a way in which the user can specify a particular “location” in which a host should boot. The most common usage for availability zones is to group together servers in terms of availability but other features could be external network connectivity or redundant power. When a nova boot command is issued, an availability zone can be provided to specify which zone to start the VM in.

The existing availability zones for VMs can be found running:

$ openstack availability zone list --compute
+---------------+-------------+
| Zone Name     | Zone Status |
+---------------+-------------+
| cern-geneva-c | available   |
| cern-geneva-b | available   |
| cern-geneva-a | available   |
+---------------+-------------+

Each of these zones have different local network switch and power inputs. Thus a failure in an individual hardware component of the cern-geneva-a (such as a server, a network swich, a power distribution unit in a rack, ...) should not affect VMs running in cern-geneva-b.

To create a VM in a particular availability zone, this should be specified at VM creation time:

$ openstack server create --availability-zone cern-geneva-a ...

An additional availability zone called none is used where dedicated servers and special configurations are used.

Server groups

Warning

Support for Server groups is only available in the Prevessin Data Centre as a method to distribute workloads in a setup with a single availability zone.

Server groups provide a mechanism for indicating the locality of VMs relative to others. They allow you to indicate whether VMs should run on the same area (affinity) or different areas (anti-affinity).

Server groups can be configured with a policy and rules: There are currently four policies supported:

  • affinity: Restricts instances belonging to the server group to the same area
  • anti-affinity: Restricts instances belonging to the server group to separate areas
  • soft-affinity: Attempts to restrict instances belonging to the server group to the same area. Where it is not possible to schedule all instances on one area, they will be scheduled together on as few areas as possible.
  • soft-anti-affinity: Attempts to restrict instances belonging to the server group to separate areas. Where it is not possible to schedule all instances to separate areas, they will be scheduled on as many separate areas as possible.

On each of those policies, there is two rules supported:

  • max_server_per_scope: Indicates the max number of VMs that can be scheduled to any given area when using anti-affinity policy
  • scope: Indicates the area in which the policies will maintain (affinity) or distribute (anti-affinity) VMs around. The area can be a host, zone (rack) or location (room).
# Create a group to be placed with a maximum of a single node per rack
openstack server group create --policy anti-affinity --rule scope=zone different_racks_x2
+------------+--------------------------------------+
| Field      | Value                                |
+------------+--------------------------------------+
| id         | c8a6800f-67c5-42c2-80a9-09097b7cd3da |
| members    |                                      |
| name       | different_racks                      |
| policy     | anti-affinity                        |
| project_id | 1ba03dae-e7f9-4b1f-afb3-ba9429d45c67 |
| rules      | scope='zone'                         |
| user_id    | jcastro                              |
+------------+--------------------------------------+

# Create a group to be placed with a maximum of 2 nodes per rack
openstack server group create --policy anti-affinity --rule scope=zone --rule max_server_per_host=2 different_racks_x2
+------------+---------------------------------------+
| Field      | Value                                 |
+------------+---------------------------------------+
| id         | 5996e2fd-f36d-40d3-b11c-21993055760a  |
| members    |                                       |
| name       | different_racks_x2                    |
| policy     | anti-affinity                         |
| project_id | 1ba03dae-e7f9-4b1f-afb3-ba9429d45c67  |
| rules      | max_server_per_host='2', scope='zone' |
| user_id    | jcastro                               |
+------------+---------------------------------------+

Once the server group is created, you can use it when creating a VM. This is achieved using the --hint option for example:

# Create two machines and place them on different racks
openstack server create --image 'ALMA9 - x86_64' --flavor m2.small --hint group=c8a6800f-67c5-42c2-80a9-09097b7cd3da --keyname cloud jcastrack01
openstack server create --image 'ALMA9 - x86_64' --flavor m2.small --hint group=c8a6800f-67c5-42c2-80a9-09097b7cd3da --keyname cloud jcastrack02

Please note than once created, a server group cannot be modified. In addition, a server cannot move between server groups. To help in the service operations, if a user needs to consolidate or distribute their VMs, we recommend the use of soft- policies