3 Requirements #

All machines (cluster nodes and arbitrators) that will be part of the cluster need at least the following modules and extensions:

When installing the machines, select HA GEO Node as system role. This leads to the installation of a minimal system where the packages from the pattern Geo Clustering for High Availability (ha_geo) are installed by default.

The virtual IPs to be used for each cluster site must be accessible across the Geo cluster.

The sites must be reachable on one UDP and TCP port per booth instance. That means any firewalls or IPsec tunnels in between must be configured accordingly.

Other setup decisions may require opening more ports (for example, for DRBD or database replication).

All cluster nodes on all sites should synchronize to an NTP server outside the cluster. For more information, see the Administration Guide for SUSE Linux Enterprise Server 15 SP6.

If nodes are not synchronized, log files and cluster reports are very hard to analyze.

Use an uneven number of sites in your Geo cluster. If the network connection breaks down, this makes sure that there still is a majority of sites (to avoid a split-brain scenario). If you have an even number of cluster sites, use an arbitrator for handling automatic failover of tickets. If you do not use an arbitrator, you need to handle ticket failover manually.

The cluster on each site has a meaningful name, for example: amsterdam and berlin.

The cluster names for each site are defined in the respective /etc/corosync/corosync.conf files:

totem {
    [...]
    cluster_name: amsterdam
    }

Change the name with following crmsh command:

# crm cluster rename NEW_NAME

Stop and start the cluster services for the changes to take effect:

# crm cluster restart

Mixed architectures within one cluster are not supported. However, for Geo clusters, each member of the Geo cluster can have a different architecture—be it a cluster site or an arbitrator. For example, you can run a Geo cluster with three members (two cluster sites and an arbitrator), where one cluster site runs on IBM Z, the other cluster site runs on x86, and the arbitrator runs on POWER.