# Server Groups

Source: https://docs.quake.ai/docs/compute/concepts/server-groups
Markdown: https://docs.quake.ai/docs/compute/concepts/server-groups.md

---

# Server groups

Server groups apply placement policies (**affinity** or **anti-affinity**) that control whether your instances land on the same physical host or are spread across different hosts. The Compute service ([OpenStack Nova](https://docs.openstack.org/nova/latest/)) scheduler honors these policies when you create a server group and assign instances to it at launch time.

## What placement policies do

<Figure size="md" caption="Affinity packs instances onto one host; anti-affinity spreads them across hosts for fault isolation">

```d2
direction: down

affinity: Affinity policy {
  host_a: Host A {
    i1: instance 1
    i2: instance 2
    i3: instance 3
  }
}

anti: Anti-affinity policy {
  host_x: Host X {
    a: instance 1
  }
  host_y: Host Y {
    b: instance 2
  }
  host_z: Host Z {
    c: instance 3
  }
}

affinity -> anti: alternative policy {style.stroke-dash: 4}
```

</Figure>

An **affinity** policy tells the scheduler to place instances in the group on the same compute host. This minimizes network latency between them and can improve cache effectiveness for tightly coupled workloads.

An **anti-affinity** policy does the opposite: instances are distributed across different physical hosts so that a single host failure does not take down the entire group. This is the foundation of most high-availability designs.

**Soft** variants of both policies allow the scheduler to make a best-effort attempt. If the preferred placement is impossible because hosts are full or constraints conflict, the scheduler falls back to the best available option instead of failing the request.

## When to use server groups

Use anti-affinity for distributed databases, replicated caches, or any tier where you need fault isolation. If one host goes down, the surviving instances on other hosts keep the service running.

Use affinity when latency between instances matters more than fault tolerance, for example a compute job that exchanges large amounts of data between workers on a shared-memory bus.

## Lifecycle

Create a server group and specify a single policy. When you launch instances, include the server group in the request so the scheduler respects the policy during placement.

Once created, the policy is **immutable**. You cannot change a server group's policy after the fact. To apply a different policy, create a new group and launch new instances into it. You can list, inspect, and delete server groups through the Console, CLI, or API.

## Further reading

**On this platform:**

- [High availability](/docs/compute/concepts/high-availability): anti-affinity groups as the foundation of HA designs
- [Instances](/docs/compute/concepts/instances): how server groups influence instance placement
- [Server groups console](/reference/compute/console/server-groups): Console reference for group management
- [Server groups CLI reference](/reference/compute/server-groups-cli): `openstack server group` commands

**External resources:**

- [OpenStack Nova server groups documentation](https://docs.openstack.org/nova/latest/user/server-groups.html): upstream reference for placement policies and scheduler behavior