Skip to main content
IMHCloud Logo
Back to support home

Creating Server Groups for High Availability in OpenStack

High Availability

What are Server Groups?

Server groups in OpenStack provide control over where instances are placed across your cloud infrastructure. When you create a server group with specific policies, OpenStack's scheduler respects those rules during instance launches, ensuring your workloads are distributed according to your availability or performance requirements.

A server group defines a logical collection of instances and applies placement policies that tell the scheduler where instances should or should not be placed relative to each other. This gives you precise control over physical host distribution without needing to know the underlying hardware topology.

Server groups are project-specific, meaning they cannot be shared across projects. Each project must create and manage its own server groups.

Understanding Placement Policies

OpenStack server groups support two primary policy types that control instance placement behavior.

Anti-Affinity Policy

The anti-affinity policy ensures instances in the same server group are placed on different physical hosts. This is the most common policy for high availability scenarios.

When you apply anti-affinity, OpenStack guarantees that if one physical host fails, only one instance from your server group goes down. The remaining instances continue running on separate hosts, maintaining service availability.

Use cases for anti-affinity:

  • Web server clusters where you need redundancy
  • Database replicas that should survive single-host failures
  • Load-balanced application tiers
  • Any service requiring fault isolation

Affinity Policy

The affinity policy does the opposite. It places instances from the same server group on the same physical host when possible. This can reduce network latency between tightly coupled instances.

Use cases for affinity:

  • Instances that communicate heavily with each other
  • Performance-sensitive workloads where network overhead matters
  • Testing environments where resource consolidation is preferred

Important: Affinity trades availability for performance. If the physical host fails, all instances in the affinity group go down together.

How to Create Server Groups in Horizon Dashboard

You can create and manage server groups directly in the Horizon dashboard, making it accessible for users who prefer a graphical interface.

Creating a Server Group

  1. Log into the Horizon dashboard for your InMotion Cloud environment
  2. Navigate to Project > Compute > Server Groups
  3. Click Create Server Group in the upper right corner
  4. In the Create Server Group dialog:
  • Name: Enter a descriptive name (e.g., web-servers-ha)
  • Policy: Select your desired policy from the dropdown:
    • Anti-Affinity: Instances placed on different physical hosts
    • Affinity: Instances placed on the same physical host when possible
  1. Click Create Server Group

The server group appears in the Server Groups list and is immediately available for use when launching new instances.

Launching Instances into a Server Group

After creating your server group, you assign instances to it during the launch process:

  1. Navigate to Project > Compute > Instances
  2. Click Launch Instance in the upper right corner
  3. In the Launch Instance wizard, proceed through the required tabs:
  • Details: Set instance name and count
  • Source: Select your image or volume
  • Flavor: Choose instance size
  • Networks: Select your network
  1. Navigate to the Server Groups tab
  2. In the Available table, locate your server group
  3. Click the plus (+) button next to the server group to move it to the Allocated table
  4. Complete any remaining configuration tabs
  5. Click Launch Instance

OpenStack schedules the instance according to the server group's policy, automatically handling placement constraints.

Viewing Server Group Details

To view information about an existing server group:

  1. Navigate to Project > Compute > Server Groups
  2. Click on the server group name to view its details
  3. The details page displays:
  • Server group name and ID
  • Policy type
  • List of member instances
  • Metadata

This view helps you verify which instances belong to each server group and confirm the policy is correctly configured.

How to Create Server Groups Using OpenStack CLI

For users who prefer command-line tools or need to automate server group creation, the OpenStack CLI provides full access to server group functionality.

Creating a Server Group with CLI

First, create the server group with your chosen policy:

1openstack server group create \
2  --policy anti-affinity \
3  web-servers-ha

This creates a server group named web-servers-ha with anti-affinity policy. OpenStack returns the server group UUID, which you'll use when launching instances.

To verify the server group was created:

1openstack server group list

You can view detailed information about the server group:

1openstack server group show web-servers-ha

The output displays the group's policy, member instances, and metadata.

Launching Instances into a Server Group

When creating instances, reference the server group using the --hint parameter:

1openstack server create \
2  --flavor m1.medium \
3  --image ubuntu-22.04 \
4  --network private-net \
5  --hint group=<server-group-uuid> \
6  web-server-1

Replace <server-group-uuid> with the UUID from the server group creation step. Launch additional instances the same way:

1openstack server create \
2  --flavor m1.medium \
3  --image ubuntu-22.04 \
4  --network private-net \
5  --hint group=<server-group-uuid> \
6  web-server-2

OpenStack's scheduler automatically distributes these instances across different physical hosts based on the anti-affinity policy.

Verifying Instance Placement

After launching instances, verify they are properly distributed. Check which host each instance is running on:

1openstack server show web-server-1 -c "OS-EXT-SRV-ATTR:host"
2openstack server show web-server-2 -c "OS-EXT-SRV-ATTR:host"

For anti-affinity groups, the host values should be different. For affinity groups, they should match (when possible).

You can also view all members of a server group:

1openstack server group show web-servers-ha -c members

This lists the UUIDs of all instances currently in the group.

Policy Enforcement and Scheduling Failures

When you use server groups, OpenStack strictly enforces the policies during scheduling. If the scheduler cannot satisfy the policy constraints, the instance launch fails.

Common Scenarios That Cause Launch Failures

Insufficient hosts for anti-affinity: If you try to launch more instances than available physical hosts, the scheduler cannot satisfy anti-affinity requirements. For example, if you have three physical hosts and try to launch a fourth instance with anti-affinity, the launch fails.

Affinity group on oversubscribed host: When using affinity policy, if the target host lacks resources to accommodate another instance, the launch fails even though other hosts have capacity.

Handling Launch Failures

When a launch fails due to server group constraints, OpenStack returns an error indicating the policy could not be satisfied. You have several options:

  • Add more physical hosts to support additional anti-affinity instances
  • Use a different server group with separate policy constraints
  • Launch without server group hints for instances that don't require specific placement
  • Adjust your architecture to work within available host constraints

Best Practices for Server Groups

Plan for Host Capacity

Before implementing anti-affinity groups, understand your physical host count. You cannot launch more instances in an anti-affinity group than you have available hosts. Account for maintenance windows and capacity planning when designing your architecture.

Group Related Workloads

Create server groups that align with your application tiers or service boundaries. For example:

  • One server group for web tier instances with anti-affinity
  • Another server group for application tier instances with anti-affinity
  • A separate server group for tightly coupled processing nodes with affinity

This provides clear separation and makes it easier to reason about placement rules.

Document Your Server Groups

Maintain documentation of which server groups exist, their policies, and which applications use them. Server groups are infrastructure-level constructs that affect multiple instances over time. Clear documentation prevents confusion during deployments and troubleshooting.

Combine with Other HA Techniques

Server groups control placement, but they're just one component of a comprehensive high availability strategy. Combine server groups with:

  • Load balancers for traffic distribution
  • Health checks and automatic failover
  • Backup and disaster recovery procedures
  • Monitoring and alerting systems

Use Meaningful Names

Name your server groups descriptively to indicate their purpose and policy. Examples:

  • production-api-anti-affinity
  • staging-workers-anti-affinity
  • data-processing-affinity

Clear names make it easier for team members to understand the infrastructure at a glance.

Modifying and Deleting Server Groups

Server groups cannot be modified after creation. If you need to change the policy, you must create a new server group and migrate instances.

To delete a server group, first remove all member instances. Then:

1openstack server group delete web-servers-ha

Deleting a server group does not affect the instances that were members. They continue running on their current hosts. The deletion only removes the logical grouping and placement constraints for future operations.

When NOT to Use Server Groups

Server groups add complexity to your infrastructure. Don't use them when:

Single-instance services: If you only run one instance of a service, server groups provide no benefit. The placement constraints only matter when you have multiple instances.

Testing and development: Development environments often don't require the same availability guarantees as production. Skip server groups to simplify deployments unless you're specifically testing HA behavior.

Instances with no availability requirements: Some workloads can tolerate downtime or are inherently disposable. Batch processing jobs or temporary compute tasks may not need controlled placement.

Limited physical infrastructure: If you operate a small OpenStack deployment with only one or two physical hosts, anti-affinity groups become impractical or impossible to use effectively.

Troubleshooting Server Group Issues

Instance Not Joining Server Group

If an instance launches but doesn't appear in the server group members list, verify you used the correct UUID in the --hint parameter. A typo or wrong UUID causes the scheduler to ignore the server group constraint.

Unexpected Placement

If instances in an anti-affinity group end up on the same host, check:

  • The scheduler is running and configured correctly
  • No scheduler configuration overrides exist that disable policy enforcement
  • The server group policy is set to anti-affinity (not affinity)

Performance Impact

Server groups can slightly increase scheduling time as the scheduler evaluates placement constraints. In large deployments with complex server group configurations, this may become noticeable. Monitor scheduler performance and adjust your architecture if scheduling delays affect operations.

Using Server Groups with Orchestration

When using Heat or Terraform to manage OpenStack infrastructure, you can define server groups in your templates and reference them during instance creation. This ensures consistent server group usage across deployments.

Example Heat template snippet:

1resources:
2  web_server_group:
3    type: OS::Nova::ServerGroup
4    properties:
5      name: web-servers-ha
6      policies:
7        - anti-affinity
8

9  web_server_1:
10    type: OS::Nova::Server
11    properties:
12      name: web-server-1
13      flavor: m1.medium
14      image: ubuntu-22.04
15      networks:
16        - network: private-net
17      scheduler_hints:
18        group: { get_resource: web_server_group }

This approach embeds server group logic directly in your infrastructure as code, making deployments repeatable and reducing manual configuration errors.

Summary

Server groups give you precise control over instance placement in OpenStack without requiring knowledge of underlying hardware topology. Anti-affinity policies spread instances across physical hosts for high availability, while affinity policies co-locate instances for performance. Understanding these tools allows you to build resilient architectures that survive hardware failures and meet your availability requirements.

When implementing server groups, plan for physical host capacity, document your groups clearly, and combine placement policies with other HA techniques for comprehensive availability strategies.