Using Nova Server Groups for Reliable Multi‑Instance Deployment in OpenStack

Problem: a single point of failure can kill your service

When you run three or more instances of a stateful service, a hardware outage on the compute node that hosts all of them can bring the whole service down. Traditional HA tricks such as manual load balancing or separate VMs add complexity, and they don’t guarantee that the instances stay on different physical machines.

Thesis: use Nova server groups with anti‑affinity

OpenStack Nova server groups let you declare a placement intent for a set of instances. The anti‑affinity policy tells the scheduler to place each member on a different compute host. Because the decision is made at launch time, the guarantee is enforced before the instance boots, so a later failure cannot affect the group.

How server groups work

Creating a group is a Compute API call. The command below creates an anti‑affinity group; replace my-group with your chosen name.

1. openstack server group create --policy anti-affinity my-group

The group now exists but contains no instances. When you launch a new server, you must add a hint that points to the group. The hint is supplied via the --hint flag.

1. openstack server create --flavor m1.small --image cirros --network public --hint group=my-group my-instance

Replace my-instance with the desired name. The scheduler consults the ServerGroupAntiAffinityFilter; if no host can satisfy the policy, the request fails with a NoValidHost error rather than silently placing multiple instances on the same host. This fail‑closed behavior protects you from accidental co‑location.

During a reschedule, evacuation, or live migration the filter re‑evaluates the constraint, but the initial placement is immutable after the instance boots. Adding an existing running instance to a group is not supported, so the decision must be made at creation time.

Worked example: three replicas on separate hosts

Assume you need three Galera database nodes. Follow these steps on a controller node where you have admin privileges.

1. Create the anti‑affinity group:
   openstack server group create --policy anti-affinity db-replicas
2. Boot the first replica (the group is optional here, but using a hint guarantees placement):
   openstack server create --flavor m1.medium --image ubuntu-cloud --network internal --hint group=db-replicas node1
3. Boot the second replica:
   openstack server create --flavor m1.medium --image ubuntu-cloud --network internal --hint group=db-replicas node2
4. Boot the third replica:
   openstack server create --flavor m1.medium --image ubuntu-cloud --network internal --hint group=db-replicas node3

After the three instances are active, verify that they are on different hosts. The openstack server group show db-replicas command displays the group ID. Then run:

1. openstack server list --columns Name,ID,Status,OS-EXT-SRV-ATTR:host

You should see node1, node2, and node3 as the host values, confirming anti‑affinity was respected. If any two instances share a host, the policy was not applied (perhaps because the cloud has fewer eligible hosts than replicas).

To double‑check at the hypervisor level, you can also run:
openstack hypervisor show <host-id> for each host and verify that only one of the instances appears on each host.

Trade‑off and limitation

Strict anti‑affinity requires at least as many eligible compute hosts as there are members. In a small cloud with only two hosts, trying to place three instances will cause the boot to fail with NoValidHost. Newer Nova releases introduce a “soft” anti‑affinity policy that prefers separation but allows multiple members on the same host when capacity is tight. Check your cloud’s Nova version before recommending the soft variant; the policy name changes (e.g., anti-affinity vs. soft-anti-affinity) and may not be available in older releases.

Another limitation is that server group membership is effectively immutable at launch. Adding a running instance to an existing group is not supported, so the design decision must be made when the instance is created. If you anticipate dynamic scaling, plan the group size up‑front or use separate groups for different scaling phases.

Actionable closing: verify and use

To safely adopt anti‑affinity:

• Confirm the supported policies on your cloud: openstack server group create --help or inspect the API microversion.
• Ensure you have enough compute hosts that meet the flavor and network requirements for the number of instances you plan to place.
• Create the group, launch instances with the --hint flag, and run the openstack server list check as shown above.
• If a boot fails with NoValidHost, either add more hosts or switch to the soft‑anti‑affinity policy (if available).
• Monitor the openstack server group show output and the OS-EXT-SRV-ATTR:host attribute after each launch to catch any unexpected co‑location.

By following these steps you can achieve true high‑availability placement without external orchestration, making Nova server groups a practical engineering choice for reliable multi‑instance deployments in OpenStack.