Kurzanleitung zu Geo-Clustering #

GeoCluster, die auf SUSE Linux Enterprise High Availability Extension basieren, können als „Overlay“-Cluster betrachtet werden, wobei jede Cluster-Site einem Cluster-Knoten in einem traditionellen Cluster entspricht. Der Overlay-Cluster wird durch den Cluster-Ticket-Manager booth (im Folgenden booth) verwaltet. Alle in einen GeoCluster involvierten Parteien führen den Service boothd aus. Dieser stellt eine Verbindung mit den booth-Daemons her, die auf den anderen Sites ausgeführt werden, und tauscht Konnektivitätsinformationen mit ihnen aus. Damit Cluster-Ressourcen über Sites hinweg hochverfügbar werden, verwendet booth als Tickets bezeichnete Cluster-Objekte. Mit einem Ticket wird das Recht zum Ausführen bestimmter Ressourcen auf einer bestimmten Cluster-Site gewährt. Booth garantiert, dass jedes Ticket jeweils nur einer Site erteilt wird.

Wenn die Kommunikation zwischen zwei booth-Instanzen ausfällt, kann dies an einem Ausfall des Netzwerks zwischen den Cluster-Sites oder an einem Ausfall einer Cluster-Site liegen. In diesem Fall wird eine zusätzliche Instanz benötigt, d. h. eine dritte Cluster-Site bzw. ein arbitrator (Vermittler), um einen Konsens über Entscheidungen (wie Failover von Ressourcen zwischen den Sites) zu erzielen. Vermittler sind einzelne Rechner (außerhalb der Cluster), auf denen eine booth-Instanz in einem speziellen Modus ausgeführt wird. Jeder GeoCluster kann einen oder mehrere Vermittler besitzen.

Abbildung 1: Cluster mit zwei Sites – 2 x 2 Knoten + Vermittler (optional) #

 

Sie können auch ein GeoCluster mit zwei Sites ohne Vermittler ausführen. In diesem Fall muss ein GeoCluster-Administrator die entsprechenden Tickets manuell verwalten. Soll ein Ticket für mehr als einen Standort gleichzeitig gewährt werden, wird in booth eine Warnmeldung angezeigt.

Weitere Details zum Konzept, zu den Komponenten und zur Ticketverwaltung für Geo-Cluster finden Sie im Administration Guide.

Im Folgenden richten wir einen einfachen GeoCluster mit zwei Cluster-Sites und einem Vermittler ein:

Bevor Sie fortfahren, müssen Sie sicherstellen, dass folgende Voraussetzungen erfüllt sind:

Detaillierte Informationen zu den einzelnen Anforderungen finden Sie auch in Abschnitt 3, „Anforderungen“.

Alle Rechner (Clusterknoten und Vermittler), die Teil des Clusters sind, müssen mindestens über folgende Module und Erweiterungen verfügen:

Wenn Sie die Rechner installieren, wählen Sie HA GEO Node als system role aus. Dies führt zu einer Minimalinstallation, wobei die Pakete aus dem Schema Geo Clustering for High Availability (ha_geo) standardmäßig installiert werden.

Alle Bootstrap-Skripte protokollieren die zugehörigen Daten in der Datei /var/log/crmsh/crmsh.log. In der Protokolldatei finden Sie alle Details des Bootstrap-Prozesses. Alle während des Bootstrap-Prozesses festgelegten Optionen können später geändert werden (durch Änderung der booth-Einstellungen, der Ressourcen usw). Weitere Informationen finden Sie im Administration Guide.

Die Pakete für die Konfiguration und Verwaltung eines Geo-Clusters sind in den Installationsschemata High Availability und Geo Clustering for High Availability enthalten. Diese Schemata sind nur verfügbar, wenn die SUSE Linux Enterprise High Availability Extension installiert ist.

Sie können sich im SUSE Customer Center registrieren und die High Availability Extension während oder nach der Installation von SUSE Linux Enterprise Server installieren. Sie finden weitere Informationen hierzu im Deployment Guide für SUSE Linux Enterprise Server.

Verwenden Sie das Kommando crm cluster geo_init, um einen vorhandenen Cluster zur ersten Site eines GeoClusters zu machen.

Das Bootstrap-Skript erstellt die booth-Konfigurationsdatei und synchronisiert diese zwischen den Cluster-Sites. Es erstellt außerdem die für booth erforderlichen grundlegenden Cluster-Ressourcen. Schritt 4 aus Prozedur 2 erzeugt folgende booth-Konfiguration und Cluster-Ressourcen:

# 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

Nachdem Sie die erste Site Ihres GeoClusters initialisiert haben, fügen Sie mit crm cluster geo_join einen zweiten Cluster hinzu (in Prozedur 3 beschrieben). Das Skript benötigt SSH-Zugriff auf eine bereits konfigurierte Cluster-Site und fügt dann den aktuellen Cluster zum GeoCluster hinzu.

Das Kommando crm cluster geo_join kopiert die booth-Konfiguration von 1 (siehe Beispiel 1). Außerdem erstellt es die für booth benötigten Cluster-Ressourcen (siehe Beispiel 2).

Nachdem Sie alle Sites Ihres GeoClusters mit crm cluster geo_init und crm cluster geo_join eingerichtet haben, richten Sie mit crm cluster geo_init_arbitrator den Vermittler ein.

Das Skript crm cluster geo_init_arbitrator kopiert die booth-Konfiguration von 1, siehe Beispiel 1. Außerdem aktiviert und startet es den booth-Service auf dem Vermittler. Der Vermittler ist damit bereit, mit den booth-Instanzen auf den Cluster-Sites zu kommunizieren, wenn auch dort der booth-Service ausgeführt wird.

Verwenden Sie Hawk2, um beide Cluster-Sites mit den Ressourcen und dem Ticket anzuzeigen, die Sie während des Bootstrap-Prozesses erstellt haben. Über die Hawk2-Weboberfläche können Sie mehrere (nicht zugeordnete) Cluster und GeoCluster überwachen und verwalten.

Die Bootstrap-Skripte für das Geo-Clustering ermöglichen das schnelle Einrichten eines grundlegenden GeoClusters, der zu Testzwecken verwendet werden kann. Um einen solchen Geo-Cluster jedoch in einen funktionierenden Geo-Cluster zu überführen, der in einer Produktionsumgebung eingesetzt werden kann, sind weitere Schritte erforderlich.

Die Bootstrap-Skripte erstellen auf beiden Cluster-Sites dieselben booth-Ressourcen und auf allen Sites, auch auf dem Vermittler, dieselben booth-Konfigurationsdateien. Wenn Sie das GeoCluster-Setup erweitern (um in eine Produktionsumgebung zu wechseln), werden Sie die booth-Konfiguration wahrscheinlich genauer abstimmen und die Konfiguration der zu booth gehörenden Cluster-Ressourcen ändern. Anschließend müssen Sie die Änderungen mit den anderen Sites Ihres GeoClusters synchronisieren, damit sie wirksam werden.

Anmerkung: Synchronisieren von Änderungen zwischen Cluster-Sites

• Verwenden Sie Csync2, um Änderungen der booth-Konfiguration zwischen allen Cluster-Sites (einschließlich dem Vermittler) zu synchronisieren. Weitere Informationen finden Sie im Chapter 5, Synchronizing configuration files across all sites and arbitrators.

• Die CIB (Cluster Information Database) wird nicht automatisch zwischen den Cluster-Sites eines GeoClusters synchronisiert. Daher müssen alle Änderungen der Ressourcenkonfiguration, die auf allen Cluster-Sites benötigt werden, manuell auf die anderen Sites übertragen werden. Markieren Sie hierzu die entsprechenden Ressourcen, exportieren Sie sie aus der aktuellen CIB und importieren Sie sie in die CIBs auf den anderen Cluster-Sites. Weitere Informationen finden Sie unter Section 6.4, “Transferring the resource configuration to other cluster sites”.