Skip to content

Server Groups

Server groups in OpenStack allow you to control the placement of instances (virtual machines) to meet specific requirements, such as high availability, redundancy, and performance optimization. OpenStack offers several policies to manage server groups: Affinity, Anti-Affinity, Soft Affinity, and Soft Anti-Affinity. Each policy has unique characteristics and use cases.

Policies in Server Groups

Affinity

The policy ensures that instances within a server group are placed on the same host. This can be useful for scenarios where low latency and high bandwidth between instances are critical, such as in-memory caching clusters or tightly coupled compute tasks.

Anti-Affinity

The policy ensures that instances within a server group are placed on different hosts under different hypervisors (one hypervisor per host). This policy is ideal for high availability and fault tolerance, as it reduces the risk of all instances going down simultaneously due to a single host failure.

Soft Affinity

It Is a more flexible version of the Affinity policy. It tries to place instances on the same host but does not enforce it strictly. If the scheduler cannot meet this requirement due to resource constraints or other factors, it allows instances to be placed on different hosts.

Soft Anti-Affinity

It is a relaxed version of the Anti-Affinity policy. It prefers to place instances on different hosts but does not strictly enforce it. If resources are insufficient, instances can be placed on the same host.

Create and Manage Anti-Affinity Groups

To illustrate the use of Anti-Affinity groups, let's consider setting up a Galera cluster. Galera is a synchronous multi-master database cluster for MySQL. Ensuring that each Galera node runs on a different host increases the cluster's resilience.

Run a Galera cluster Using Anti-Affinity Policy

  1. Create a Server Group:

    • Navigate to Projects > Compute > Server Groups and click Create Server Group.
    • Enter a name for the server group (in this example: GaleraCluster) and select the Anti-Affinity policy.
    • Click Create Server Group.

  2. Launch Instances in the Anti-Affinity Group:

    • Navigate to Projects > Compute > Server Groups and click Launch Instance.
    • Complete the instance required fields (name, flavor, image, etc.).
    • Select previously created network where you want to place your instances.
    • Under Server Group, select GaleraCluster.
    • In the Configuration tab paste the following Cloud-Init script in the Customization Script text box:
    #cloud-config
package_update: true
package_upgrade: true
packages:
- mariadb-server
- galera
- rsync
- socat

runcmd:
- sed -i '/^\[mysqld\]/a wsrep_on=ON' /etc/my.cnf
- sed -i '/^\[mysqld\]/a wsrep_provider=/usr/lib64/galera/libgalera_smm.so' /etc/my.cnf
- sed -i '/^\[mysqld\]/a wsrep_cluster_address="gcomm://<ip_node_1>,<ip_node_2>,<ip_node_3>"' /etc/my.cnf
- sed -i '/^\[mysqld\]/a wsrep_cluster_name="galera_cluster"' /etc/my.cnf
- sed -i '/^\[mysqld\]/a wsrep_node_address="<ip_node>"' /etc/my.cnf
- sed -i '/^\[mysqld\]/a wsrep_node_name=$(hostname)' /etc/my.cnf
- sed -i '/^\[mysqld\]/a wsrep_sst_method=rsync' /etc/my.cnf
- sed -i '/^\[mysqld\]/a binlog_format=row' /etc/my.cnf
- sed -i '/^\[mysqld\]/a default_storage_engine=InnoDB' /etc/my.cnf
- systemctl start mariadb
- mysql -u root -e "CREATE USER 'sstuser'@'localhost' IDENTIFIED BY 'your_password';"
- mysql -u root -e "GRANT RELOAD, LOCK TABLES, PROCESS, REPLICATION CLIENT ON *.* TO 'sstuser'@'localhost';"
- mysql -u root -e "FLUSH PRIVILEGES;"

    Important

    Replace <ip_node_1>, <ip_node_2>, and <ip_node_3> with the actual IP addresses of your instances. Replace <NODE_IP> with the IP address of the current node. Adjust the MySQL user and password as necessary.

    • Repeat the process to launch two more instances in the same server group.

Create a Server Group: 

openstack server group create --policy anti-affinity GaleraCluster
Launch Instances in the Anti-Affinity Group: 
openstack server create --flavor <flavor> --image <image_id> --key-name <key_name> --network <network_id> --user-data <cloud_init_file> --hint group=<server_group_id> galera-node-1
openstack server create --flavor <flavor> --image <image_id> --key-name <key_name> --network <network_id> --user-data <cloud_init_file> --hint group=<server_group_id> galera-node-2
openstack server create --flavor <flavor> --image <image_id> --key-name <key_name> --network <network_id> --user-data <cloud_init_file> --hint group=<server_group_id> galera-node-3

Replace placeholders:

  • <flavor>: The chosen flavor for the instances.
  • <image_id>: The ID of the image you are using.
  • <key_name>: Your SSH key pair name.
  • <network_id>: The network ID.
  • <cloud_init_file>: Path to your Cloud-Init script file.
  • <server_group_id>: The ID of the GaleraCluster server group created earlier.

You can find the Server Group ID using: 

openstack server group list

Effects of Anti-Affinity Policy

By applying the Anti-Affinity policy, each Galera node (VM instance) is placed on a different host. This setup ensures that if one host fails, the remaining Galera nodes continue to operate, maintaining the availability and integrity of the Galera cluster.

Understanding and utilizing server group policies in OpenStack is crucial for achieving specific goals such as high availability, fault tolerance, and performance optimization. Using both the Horizon Dashboard and OpenStack CLI, you can easily create and manage these server groups to meet your deployment needs.