Geo Clustering Quick Start #

Geo clusters based on SUSE® Linux Enterprise High Availability can be considered “overlay” clusters where each cluster site corresponds to a cluster node in a traditional cluster. The overlay cluster is managed by the booth cluster ticket manager (in the following called booth). Each of the parties involved in a Geo cluster runs a service, the boothd. It connects to the booth daemons running on the other sites and exchanges connectivity details. For making cluster resources highly available across sites, booth relies on cluster objects called tickets. A ticket grants the right to run certain resources on a specific cluster site. Booth guarantees that every ticket is granted to no more than one site at a time.

If the communication between two booth instances breaks down, it might be because of a network breakdown between the cluster sites or because of an outage of one cluster site. In this case, you need an additional instance (a third cluster site or an arbitrator) to reach consensus about decisions (such as failover of resources across sites). Arbitrators are single machines (outside of the clusters) that run a booth instance in a special mode. Each Geo cluster can have one or multiple arbitrators.

Figure 1: Two-site cluster—2x2 nodes + arbitrator (optional) #

  

It is also possible to run a two-site Geo cluster without an arbitrator. In this case, a Geo cluster administrator needs to manually manage the tickets. If a ticket should be granted to more than one site at the same time, booth displays a warning.

For more details on the concept, components and ticket management used for Geo clusters, see the Administration Guide.

In the following, we will set up a basic Geo cluster with two cluster sites and one arbitrator:

Before you proceed, make sure the following requirements are fulfilled:

For detailed requirements on each item, see also Section 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.

All bootstrap scripts log to /var/log/crmsh/crmsh.log. Check the log file for any details of the bootstrap process. Any options set during the bootstrap process can be modified later (by modifying booth settings, modifying resources etc.). For details, see the Administration Guide.

The packages for configuring and managing a Geo cluster are included in the High Availability and Geo Clustering for High Availability installation patterns. These patterns are only available after the SUSE Linux Enterprise High Availability is installed.

You can register to the SUSE Customer Center and install SUSE Linux Enterprise High Availability while installing SUSE Linux Enterprise Server, or after installation. For more information, see Deployment Guide for SUSE Linux Enterprise Server.

Use the crm cluster geo_init command to turn an existing cluster into the first site of a Geo cluster.

The bootstrap script creates the booth configuration file and synchronizes it across the cluster sites. It also creates the basic cluster resources needed for booth. Step 4 of Procedure 2 would result in the following booth configuration and cluster resources:

# The booth configuration file is "/etc/booth/booth.conf". You need to
# prepare the same booth configuration file on each arbitrator and
# each node in the cluster sites where the booth daemon can be launched.

# "transport" means which transport layer booth daemon will use.
# Currently only "UDP" is supported.
transport="UDP"
port="9929"

arbitrator="192.168.203.100"
site="192.168.201.100"
site="192.168.202.100"
authfile="/etc/booth/authkey"
ticket="ticket-nfs"
expire="600"

primitive1 booth-ip IPaddr2 \
  params rule #cluster-name eq amsterdam ip=192.168.201.100 \
  params rule #cluster-name eq berlin ip=192.168.202.100 \
primitive2 booth-site ocf:pacemaker:booth-site \
  meta resource-stickiness=INFINITY \
  params config=booth \
  op monitor interval=10s
group3 g-booth booth-ip booth-site \
meta target-role=Stopped4

After you have initialized the first site of your Geo cluster, add the second cluster with crm cluster geo_join, as described in Procedure 3. The script needs SSH access to an already configured cluster site and will add the current cluster to the Geo cluster.

The crm cluster geo_join command copies the booth configuration from 1, see Example 1. In addition, it creates the cluster resources needed for booth (see Example 2).

After you have set up all sites of your Geo cluster with crm cluster geo_init and crm cluster geo_join, set up the arbitrator with crm cluster geo_init_arbitrator.

The crm cluster geo_init_arbitrator script copies the booth configuration from 1, see Example 1. It also enables and starts the booth service on the arbitrator. Thus, the arbitrator is ready to communicate with the booth instances on the cluster sites when the booth services are running there too.

To view both cluster sites with the resources and the ticket that you have created during the bootstrapping process, use Hawk2. The Hawk2 Web interface allows you to monitor and manage multiple (unrelated) clusters and Geo clusters.

The Geo clustering bootstrap scripts provide a quick way to set up a basic Geo cluster that can be used for testing purposes. However, to move the resulting Geo cluster into a functioning Geo cluster that can be used in production environments, more steps are required.

The bootstrap scripts create the same booth resources on both cluster sites, and the same booth configuration files on all sites, including the arbitrator. If you extend the Geo cluster setup (to move to a production environment), you will probably fine-tune the booth configuration and change the configuration of the booth-related cluster resources. Afterward, you need to synchronize the changes to the other sites of your Geo cluster to take effect.

Note: Synchronizing changes across cluster sites

• To synchronize changes in the booth configuration to all cluster sites (including the arbitrator), use Csync2. Find more information at Chapter 5, Synchronizing configuration files across all sites and arbitrators.

• The CIB (Cluster Information Database) is not automatically synchronized across cluster sites of a Geo cluster. That means any changes in resource configuration that are required on all cluster sites need to be transferred to the other sites manually. Do so by tagging the respective resources, exporting them from the current CIB, and importing them to the CIB on the other cluster sites. For details, see Section 6.4, “Transferring the resource configuration to other cluster sites”.