|
| 1 | +============= |
| 2 | +Server Groups |
| 3 | +============= |
| 4 | + |
| 5 | +Server groups provide a mechanism for indicating the locality of servers |
| 6 | +relative to other servers. They allow you to indicate whether servers should |
| 7 | +run on the same host (affinity) or different hosts (anti-affinity). Affinity is |
| 8 | +advantageous if you wish to minimise network latency, while anti-affinity can |
| 9 | +improve fault-tolerance and load distribution. |
| 10 | + |
| 11 | +.. note:: |
| 12 | + |
| 13 | + Server groups are useful for separating or grouping workloads but should |
| 14 | + not generally be relied on to provide HA. Instead, consider using |
| 15 | + availability zones. Unlike server groups, availability zones can only be |
| 16 | + configured by admins but they are often used to model failure domains, |
| 17 | + particularly in larger deployments. For more information, refer to |
| 18 | + :doc:`/user/availability-zones`. |
| 19 | + |
| 20 | +Server groups can be configured with a policy and rules. There are currently |
| 21 | +four policies supported: |
| 22 | + |
| 23 | +``affinity`` |
| 24 | + Restricts instances belonging to the server group to the same host. |
| 25 | + |
| 26 | +``anti-affinity`` |
| 27 | + Restricts instances belonging to the server group to separate hosts. |
| 28 | + |
| 29 | +``soft-affinity`` |
| 30 | + Attempts to restrict instances belonging to the server group to the same |
| 31 | + host. Where it is not possible to schedule all instances on one host, |
| 32 | + they will be scheduled together on as few hosts as possible. |
| 33 | + |
| 34 | + .. note:: |
| 35 | + |
| 36 | + Requires API microversion 2.15 or later. |
| 37 | + |
| 38 | +``soft-anti-affinity`` |
| 39 | + Attempts to restrict instances belonging to the server group to separate |
| 40 | + hosts. Where it is not possible to schedule all instances to separate hosts, |
| 41 | + they will be scheduled on as many separate hosts as possible. |
| 42 | + |
| 43 | + .. note:: |
| 44 | + |
| 45 | + Requires API microversion 2.15 or later. |
| 46 | + |
| 47 | +There is currently one rule supported: |
| 48 | + |
| 49 | +``max_server_per_host`` |
| 50 | + Indicates the max number of instances that can be scheduled to any given |
| 51 | + host when using the ``anti-affinity`` policy. This rule is not compatible |
| 52 | + with other policies. |
| 53 | + |
| 54 | + .. note:: |
| 55 | + |
| 56 | + Requires API microversion 2.64 or later. |
| 57 | + |
| 58 | + |
| 59 | +Usage |
| 60 | +----- |
| 61 | + |
| 62 | +Server groups can be configured and used by end-users. For example: |
| 63 | + |
| 64 | +.. code-block:: console |
| 65 | +
|
| 66 | + $ openstack --os-compute-api-version 2.64 server group create \ |
| 67 | + --policy POLICY --rule RULE NAME |
| 68 | +
|
| 69 | +Once a server group has been created, you can use it when creating a server. |
| 70 | +This is achieved using the ``--hint`` option. For example: |
| 71 | + |
| 72 | +.. code-block:: console |
| 73 | +
|
| 74 | + $ openstack server create \ |
| 75 | + --hint group=SERVER_GROUP_UUID ... NAME |
| 76 | +
|
| 77 | +Once created, a server group cannot be modified. In addition, a server cannot |
| 78 | +move between server groups. In both cases, this is because doing so would |
| 79 | +require potentially moving the server to satisfy the server group policy. |
0 commit comments