Zum Inhalt springen
documentation.suse.com / Kurzanleitung zu Geo-Clustering
SUSE Linux Enterprise High Availability 15 SP6

Kurzanleitung zu Geo-Clustering

Veröffentlicht: 12. Dezember 2024

Geo-Clustering schützt Workloads in global verteilten Rechenzentren. Dieses Dokument führt Sie durch die grundlegende Einrichtung eines GeoClusters. Dabei werden Geo-Bootstrap-Skripte eingesetzt, die in der crm-Shell bereitgestellt werden.

Copyright © 2006–2024 SUSE LLC und Mitwirkende. Alle Rechte vorbehalten.

Es wird die Genehmigung erteilt, dieses Dokument unter den Bedingungen der GNU Free Documentation License, Version 1.2 oder (optional) Version 1.3 zu vervielfältigen, zu verbreiten und/oder zu verändern; die unveränderlichen Abschnitte hierbei sind der Urheberrechtshinweis und die Lizenzbedingungen. Eine Kopie dieser Lizenz (Version 1.2) finden Sie in Abschnitt GNU Free Documentation License.

Die SUSE Marken finden Sie im https://www.suse.com/company/legal/. Die Rechte für alle Marken von Drittanbietern liegen bei den jeweiligen Eigentümern. Markensymbole (®, ™ usw.) kennzeichnen Marken von SUSE und seinen verbundenen Unternehmen. Sternchen (*) kennzeichnen Marken von Drittanbietern.

Alle Informationen in diesem Buch wurden mit größter Sorgfalt zusammengestellt. Auch hierdurch kann jedoch keine hundertprozentige Richtigkeit gewährleistet werden. Weder SUSE LLC, ihre Tochtergesellschaften, die Autoren noch die Übersetzer können für mögliche Fehler und deren Folgen haftbar gemacht werden.

1 Konzeptübersicht

GeoCluster, die auf SUSE® Linux Enterprise High Availability 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.

Cluster mit zwei Sites – 2 x 2 Knoten + Vermittler (optional)
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 GeoCluster finden Sie im Book “Administration Guide”.

2 Einsatzszenario

Die Verfahren in diesem Dokument führen zu einem einfachen GeoCluster mit zwei Cluster-Sites und einem Vermittler:

  • Die Cluster-Sites erhalten die Namen amsterdam und berlin.

  • Jede Site besteht aus zwei Knoten. Die Knoten alice und bob gehören zum Cluster amsterdam. Die Knoten charlie und doro gehören zum Cluster berlin.

  • Die Site amsterdam erhält folgende virtuelle IP-Adresse: 192.168.201.100.

  • Die Site berlin erhält folgende virtuelle IP-Adresse: 192.168.202.100.

  • Der Vermittler besitzt folgende IP-Adresse: 192.168.203.100.

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

Anforderungen
Zwei vorhandene Cluster

Sie haben mindestens zwei bestehende Cluster, die Sie zu einem GeoCluster zusammenfassen möchten (wenn Sie zuerst zwei Cluster einrichten müssen, befolgen Sie die Anweisungen in der Article “Kurzanleitung zur Installation und Einrichtung”).

Aussagekräftige Cluster-Namen

Jeder Cluster hat einen aussagekräftigen Namen, der seinen Standort widerspiegelt, z. B. amsterdam und berlin. Clusternamen werden in /etc/corosync/corosync.conf definiert.

Vermittler

Sie haben einen dritten Rechner installiert, der nicht Teil eines vorhandenen Clusters ist und als Vermittler verwendet werden kann.

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

3 Anforderungen

Alle Rechner (Cluster-Knoten und Vermittler) benötigen mindestens die folgenden Module und Erweiterungen:

  • Basesystem Module 15 SP6

  • Server Applications Module 15 SP6

  • SUSE Linux Enterprise High Availability 15 SP6

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.

Netzwerkanforderungen
  • Auf die virtuellen IPs, die für die einzelnen Cluster-Sites verwendet werden, muss ein Zugriff über den GeoCluster möglich sein.

  • Die Sites müssen pro booth-Instanz über einen UDP- und einen TCP-Port erreichbar sein. Folglich müssen Firewalls oder IPSec-Tunnel zwischen ihnen entsprechend konfiguriert sein.

  • Weitere Entscheidungen bezüglich der Einrichtung machen es möglicherweise erforderlich, weitere Ports zu öffnen (z. B. für DRBD oder Datenbankreplikation).

Sonstige Anforderungen und Empfehlungen
  • Alle Cluster-Knoten auf allen Sites sollten mit einem NTP-Server außerhalb des Clusters synchronisiert werden. Weitere Informationen finden Sie im Administration Guide for SUSE Linux Enterprise Server 15 SP6.

    Wenn Knoten nicht synchronisiert sind, ist es sehr schwierig, Protokolldateien und Cluster-Berichte zu analysieren.

  • Verwenden Sie in Ihrem GeoCluster eine ungerade Anzahl an Sites. Dadurch wird beim Ausfall der Netzwerkverbindung sichergestellt, dass weiterhin eine Mehrheit von Sites gebildet werden kann (um ein Systemspaltungsszenario zu vermeiden). Falls Sie über eine gerade Anzahl an Cluster-Sites verfügen, verwenden Sie zur Bearbeitung des automatischen Failovers von Tickets einen Vermittler. Verwenden Sie keinen Vermittler, müssen Sie das Ticket-Failover manuell bearbeiten.

  • Der Cluster der einzelnen Sites besitzt einen aussagekräftigen Namen, z. B. amsterdam und berlin.

    Die Cluster-Namen für die einzelnen Sites sind jeweils in der Datei /etc/corosync/corosync.conf definiert:

    totem {
        [...]
        cluster_name: amsterdam
        }

    Ändern Sie den Namen mit folgendem crmsh-Befehl:

    # crm cluster rename NEW_NAME

    Stoppen und starten Sie die Clusterdienste neu, damit die Änderungen wirksam werden:

    # crm cluster restart
  • Gemischte Architekturen innerhalb eines Clusters werden nicht unterstützt. Bei Geo-Clustern kann jedoch jedes Mitglied des Geo-Clusters eine andere Architektur besitzen – unabhängig davon, ob es sich um eine Cluster-Site oder einen Vermittler handelt. Sie können beispielsweise einen Geo-Cluster mit drei Mitgliedern (zwei Cluster-Sites und ein Vermittler) betreiben, wobei eine Cluster-Site auf IBM Z läuft, die andere Cluster-Site auf x86 und der Vermittler auf POWER.

4 Überblick über die Geo-Bootstrap-Skripte

  • Mit crm cluster geo_init machen Sie einen Cluster zur ersten Site eines GeoClusters. Das Skript übernimmt einige Parameter, wie die Namen der Cluster, den Vermittler und eines oder mehrere Tickets und erstellt daraus /etc/booth/booth.conf. Es kopiert die booth-Konfiguration auf alle Knoten auf der aktuellen Cluster-Site. Außerdem konfiguriert es die Cluster-Ressourcen, die auf der aktuellen Cluster-Site für booth erforderlich sind.

    Weitere Informationen finden Sie unter Abschnitt 6, „Einrichten der ersten Site eines GeoClusters“.

  • Mit crm cluster geo_join fügen Sie den aktuellen Cluster zu einem vorhandenen GeoCluster hinzu. Das Skript kopiert die booth-Konfiguration von einer vorhandenen Cluster-Site und schreibt diese auf allen Knoten auf der aktuellen Cluster-Site in /etc/booth/booth.conf. Außerdem konfiguriert es die Cluster-Ressourcen, die auf der aktuellen Cluster-Site für booth erforderlich sind.

    Weitere Informationen finden Sie unter Abschnitt 7, „Hinzufügen einer weiteren Site zu einem GeoCluster“.

  • Mit crm cluster geo_init_arbitrator machen Sie den aktuellen Rechner zum Vermittler für den GeoCluster. Das Skript kopiert die booth-Konfiguration von einer vorhandenen Cluster-Site und schreibt diese in /etc/booth/booth.conf.

    Weitere Informationen finden Sie im Abschnitt 8, „Hinzufügen des Vermittlers“.

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 Book “Administration Guide”.

5 Installieren der Hochverfügbarkeits- und Geo-Clustering-Pakete

Die Pakete zum Konfigurieren und Verwalten eines GeoClusters sind in den High Availability- und Geo Clustering for High Availability-Installationsschemata enthalten. Diese Schemata sind erst nach der Installation von SUSE Linux Enterprise High Availability verfügbar.

Sie können sich beim SUSE Customer Center registrieren und SUSE Linux Enterprise High Availability 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.

Vorgehen 1: Installieren der Schemata für Hochverfügbarkeit und Geo-Clustering
  1. Installieren Sie die Schemata für Hochverfügbarkeit und Geo-Clustering über die Kommandozeile:

    # zypper install -t pattern ha_sles ha_geo
  2. Installieren Sie die Schemata für Hochverfügbarkeit und Geo-Clustering auf allen Rechnern, die Teil Ihres Clusters sein sollen.

    Anmerkung
    Anmerkung: Installation der Softwarepakete auf allen Knoten

    Für eine automatisierte Installation von SUSE Linux Enterprise Server 15 SP6 und SUSE Linux Enterprise High Availability 15 SP6 müssen Sie zum Klonen von bestehenden Knoten AutoYaST verwenden. Weitere Informationen finden Sie im Book “Administration Guide”, Chapter 3 “Installing SUSE Linux Enterprise High Availability”, Section 3.2 “Mass installation and deployment with AutoYaST”.

6 Einrichten der ersten Site eines GeoClusters

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

Vorgehen 2: Einrichten der ersten Site (amsterdam) mit crm cluster geo_init
  1. Definieren Sie pro Cluster-Site eine virtuelle IP, über die auf die Site zugegriffen werden kann. Hierzu verwenden wir in diesem Beispiel 192.168.201.100 und 192.168.202.100. Es ist jetzt noch nicht erforderlich, die virtuellen IPs als Cluster-Ressourcen zu konfigurieren. Das erledigen die Bootstrap-Skripte.

  2. Definieren Sie einen Namen für mindestens ein Ticket, mit dem die Berechtigung erteilt wird, bestimmte Ressourcen auf einer Cluster-Site auszuführen. Verwenden Sie einen aussagekräftigen Namen, der auf die Ressourcen hinweist, die von dem Ticket abhängen (z. B. ticket-nfs). Die Bootstrap-Skripte benötigen nur den Ticketnamen. Die weiteren Einzelheiten (Ticketabhängigkeiten der Ressourcen) können Sie später, wie in Abschnitt 10, „Nächste Schritte“ beschrieben, definieren.

  3. Melden Sie sich bei einem Knoten eines vorhandenen Clusters an (z. B. beim Knoten alice des Clusters amsterdam).

  4. Führen Sie crm cluster geo_init. Verwenden Sie beispielsweise die folgenden Optionen:

    # crm cluster geo_init \
      --clusters "amsterdam=192.168.201.100 berlin=192.168.202.100" \1
      --tickets ticket-nfs \2
      --arbitrator 192.168.203.1003

    1

    Die Namen der Cluster-Sites (die in /etc/corosync/corosync.conf definiert sind) und die virtuellen IP-Adressen, die Sie für die einzelnen Cluster-Sites verwenden möchten. In diesem Fall haben wir zwei Cluster-Sites (amsterdam und berlin), die je eine virtuelle IP-Adresse besitzen.

    2

    Den Namen eines oder mehrerer Tickets.

    3

    Den Hostnamen oder die IP-Adresse eines Rechners außerhalb des Clusters.

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:

Beispiel 1: Mit crm cluster geo_init erstellte booth-Konfiguration
# 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"
Beispiel 2: Mit crm cluster geo_init erstellte Cluster-Ressourcen
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

1

Eine virtuelle IP-Adresse für jede Cluster-Site. Diese wird von den booth-Daemons benötigt, die für jede Cluster-Site eine persistente IP-Adresse voraussetzen.

2

Eine primitive Ressource für den booth-Daemon. Er kommuniziert mit den booth-Daemons auf den anderen Cluster-Sites. Der Daemon kann auf einem beliebigen Knoten der Site gestartet werden. Damit die Ressource möglichst auf demselben Knoten verbleibt, wird „resource-stickiness“ auf INFINITY gesetzt.

3

Eine Cluster-Ressourcengruppe für beide Primitive. Mit dieser Konfiguration ist jeder booth-Daemon an der jeweiligen IP-Adresse verfügbar, und zwar unabhängig von dem Knoten, auf dem der Daemon ausgeführt wird.

4

Die Cluster-Ressourcengruppe wird standardmäßig nicht gestartet. Nachdem Sie die Konfiguration Ihrer Cluster-Ressourcen überprüft (und die für Ihr Setup erforderlichen Ressourcen hinzugefügt) haben, müssen Sie die Ressourcengruppe starten. Ausführliche Informationen finden Sie unter Erforderliche Schritte für den Abschluss des GeoCluster-Setups.

7 Hinzufügen einer weiteren Site zu einem GeoCluster

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.

Vorgehen 3: Hinzufügen der zweiten Site (berlin) mit crm cluster geo_join
  1. Melden Sie sich bei einem Knoten der Cluster-Site an, die Sie hinzufügen möchten (z. B. beim Knoten charlie des Clusters berlin).

  2. Führen Sie das Kommando crm cluster geo_join aus. Beispiel:

    # crm cluster geo_join \
      --cluster-node 192.168.201.100\1
      --clusters "amsterdam=192.168.201.100 berlin=192.168.202.100"2

    1

    Legt fest, von wo die booth-Konfiguration kopiert werden soll. Verwenden Sie die IP-Adresse oder den Hostnamen eines Knotens in einer bereits konfigurierten GeoCluster-Site. Sie können auch (wie in diesem Beispiel) die virtuelle IP-Adresse einer vorhandenen Cluster-Site verwenden. Alternativ können Sie die IP-Adresse oder den Hostnamen eines bereits für Ihren GeoCluster konfigurierten Vermittlers verwenden.

    2

    Die Namen der Cluster-Sites (die in /etc/corosync/corosync.conf definiert sind) und die virtuellen IP-Adressen, die Sie für die einzelnen Cluster-Sites verwenden möchten. In diesem Fall haben wir zwei Cluster-Sites (amsterdam und berlin), die je eine virtuelle IP-Adresse besitzen.

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

8 Hinzufügen des Vermittlers

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.

Vorgehen 4: Einrichten des Vermittlers mit crm cluster geo_init_arbitrator
  1. Melden Sie sich bei dem Rechner an, den Sie als Vermittler verwenden möchten.

  2. Führen Sie den folgenden Befehl aus. Beispiel:

    # crm cluster geo_init_arbitrator --cluster-node 192.168.201.1001

    1

    Legt fest, von wo die booth-Konfiguration kopiert werden soll. Verwenden Sie die IP-Adresse oder den Hostnamen eines Knotens in einer bereits konfigurierten GeoCluster-Site. Sie können alternativ (wie in diesem Beispiel) die virtuelle IP-Adresse einer bereits vorhandenen Cluster-Site verwenden.

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.

9 Überwachen der Cluster-Sites

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.

Voraussetzungen
  • Auf allen Clustern, die über das Dashboard von Hawk2 überwacht werden sollen, muss SUSE Linux Enterprise High Availability Extension15 SP6 ausgeführt werden.

  • Wenn Sie das eigensignierte Zertifikat für Hawk2 noch nicht auf jedem Cluster-Knoten durch ein eigenes Zertifikat (oder ein von einer offiziellen Zertifizierungsstelle signiertes Zertifikat) ersetzt haben, gehen Sie wie folgt vor: Melden Sie sich auf jedem Knoten in jedem Cluster mindestens einmal bei Hawk2 an. Überprüfen Sie das Zertifikat (oder fügen Sie im Browser eine Ausnahme hinzu, um die Warnung zu umgehen). Andernfalls kann Hawk2 keine Verbindung mit dem Cluster herstellen.

Vorgehen 5: Verwendung des Hawk2-Dashboards
  1. Starten Sie einen Webbrowser und geben Sie die virtuelle IP-Adresse Ihrer ersten Cluster-Site, amsterdam, ein:

    https://192.168.201.100:7630/

    Alternativ können Sie die IP-Adresse oder den Hostnamen von alice oder bob verwenden. Wenn Sie beide Knoten mit den Bootstrap-Skripten eingerichtet haben, sollte in beiden Knoten der Service hawk ausgeführt werden.

  2. Melden Sie sich an der Hawk2-Weboberfläche an.

  3. Wählen Sie auf der linken Navigationsleiste Dashboard aus.

    Hawk2 zeigt eine Übersicht der Ressourcen und Knoten auf der aktuellen Cluster-Site an. Außerdem zeigt Hawk2 alle Tickets an, die für den GeoCluster konfiguriert wurden. Informationen zu den in dieser Ansicht verwendeten Symbolen erhalten Sie, indem Sie auf Legende klicken.

    Hawk2-Dashboard mit einer Cluster-Site – (amsterdam)
    Abbildung 2: Hawk2-Dashboard mit einer Cluster-Site – (amsterdam)
  4. Klicken Sie auf Cluster hinzufügen, um ein Dashboard für die zweite Cluster-Site hinzuzufügen.

    1. Geben Sie den Clusternamen ein, der den Cluster im Dashboard identifiziert. In diesem Fall ist dies berlin.

    2. Geben Sie den vollständigen Hostnamen einer der Cluster-Knoten ein (in diesem Fall charlie oder doro).

    3. Klicken Sie auf Hinzufügen. Hawk2 zeigt für die neu hinzugefügte Cluster-Site eine zweite Registerkarte mit einer Übersicht der vorhandenen Knoten und Ressourcen an.

      Hawk2-Dashboard mit beiden Cluster-Sites
      Abbildung 3: Hawk2-Dashboard mit beiden Cluster-Sites
  5. Um weitere Details anzuzeigen oder um eine Cluster-Site zu verwalten, wechseln Sie zur Registerkarte der Site und klicken Sie auf das Kettensymbol.

    Hawk2 öffnet für die Site die Statusanzeige in einem neuen Browserfenster oder Tab. Dort können Sie diesen Teil des GeoClusters verwalten.

10 Nächste Schritte

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.

Erforderliche Schritte für den Abschluss des GeoCluster-Setups
Starten der booth-Services auf Cluster-Sites

Nach dem Bootstrap-Prozess kann der booth-Service des Vermittlers noch nicht mit den booth-Services auf den Cluster-Sites kommunizieren, da diese standardmäßig nicht gestartet werden.

Der booth-Service für jede Cluster-Site wird von der booth-Ressourcengruppe g-booth verwaltet (siehe Beispiel 2, „Mit crm cluster geo_init erstellte Cluster-Ressourcen“). Um eine Instanz des booth-Service pro Site zu starten, starten Sie die entsprechende booth-Ressourcengruppe auf den einzelnen Cluster-Sites. Damit sind alle booth-Instanzen in der Lage, miteinander zu kommunizieren.

Konfigurieren von Ticketabhängigkeiten und Einschränkungen

Um Ressourcen von dem von Ihnen während des Bootstrap-Prozesses für den GeoCluster erstellten Ticket abhängig zu machen, müssen Sie Einschränkungen konfigurieren. Legen Sie für jede Einschränkung mit loss-policy eine Verlustrichtlinie fest, mit der Sie definieren, was mit den betroffenen Ressourcen passieren soll, wenn das Ticket von einer Cluster-Site zurückgezogen wird.

Weitere Informationen finden Sie unter Book “Geo Clustering Guide”, Chapter 6 “Configuring cluster resources and constraints”.

Einer Site ein erstes Ticket gewähren

Bevor ein bestimmtes Ticket im GeoCluster von booth verwaltet werden kann, müssen Sie es einer Site einmal manuell gewähren. Um ein Ticket zu gewähren, können Sie entweder das Kommandozeilenwerkzeug „booth client“ oder Hawk2 verwenden.

Details finden Sie in Book “Geo Clustering Guide”, Chapter 8 “Managing Geo clusters”.

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
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 Book “Geo Clustering Guide”, 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 Book “Geo Clustering Guide”, Chapter 6 “Configuring cluster resources and constraints”, Section 6.4 “Transferring the resource configuration to other cluster sites”.

11 Weitere Informationen