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) #

  

For more details on the concept, components and ticket management used for Geo clusters, see the Chapter 2, Conceptual Overview.

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 bootstrap scripts log to /var/log/ha-cluster-bootstrap.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 Geo Clustering Guide.

Support for using High Availability clusters across unlimited distances is available as a separate extension, called Geo Clustering for SUSE Linux Enterprise High Availability.

For setting up a Geo cluster you need the packages included in the following installation patterns:

Both patterns are only available if you have registered your system at SUSE Customer Center (or a local registration server) and have added the respective product channels or installation media as an extension. For information on how to install extensions, see the Deployment Guide for SUSE Linux Enterprise 12 SP5.

Important: Installing Software Packages on all Parties

The software packages needed for High Availability and Geo clusters are not automatically copied to the cluster nodes.

• Install SUSE Linux Enterprise Server 12 SP5 and the High Availability and Geo Clustering for High Availability patterns on all machines that will be part of your Geo cluster.

• Instead of manually installing the packages on all machines that will be part of your cluster, use AutoYaST to clone existing nodes. Find more information at Section 3.2, “Mass Installation and Deployment with AutoYaST”.

  However, the Geo clustering extension must be installed manually on all machines that will be part of the Geo cluster. AutoYaST support for Geo Clustering for SUSE Linux Enterprise High Availability is not yet available.

Use the ha-cluster-geo-init script 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 ha-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 ha-cluster-geo-join script 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 ha-cluster-geo-init and ha-cluster-geo-join, set up the arbitrator with ha-cluster-geo-init-arbitrator.

The ha-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 as soon as 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—see Required Steps to Complete the Geo Cluster Setup.

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 also 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”.