SUSE Linux Enterprise High Availability Extension 15 SP4

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.

Autoren: Tanja Roth und Thomas Schraitle

Versionsgeschichte: SUSE Linux Enterprise High Availability Extension – Dokumentation

1 Konzeptübersicht #

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 (eine dritte Cluster-Site bzw. ein 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 GeoCluster finden Sie im Administration Guide.

2 Einsatzszenario #

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

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 vorhandene Cluster, die Sie in einem GeoCluster kombinieren möchten. (Falls Sie zuerst zwei Cluster einrichten müssen, folgen Sie der Anleitung in der Kurzanleitung zu Installation und Einrichtung).
Aussagekräftige Cluster-Namen: Für jeden Cluster wird in /etc/corosync/corosync.conf ein aussagekräftiger Cluster-Name definiert, der den Standort angibt.
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 (Clusterknoten und Vermittler), die Teil des Clusters sind, müssen mindestens über folgende Module und Erweiterungen verfügen:

Basesystem Module 15 SP4
Server Applications Module 15 SP4
SUSE Linux Enterprise High Availability Extension 15 SP4

Wählen Sie bei der Installation der Rechner HA GEO-Knoten als system role. Dadurch wird ein Minimalsystem installiert, bei dem die Pakete aus dem Schema Geo-Clustering für Hochverfügbarkeit (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. Sie finden weitere Informationen hierzu im Administrationshandbuch für SUSE Linux Enterprise Server 15 SP4.
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 im Fall eines Ausfalls der Netzwerkverbindung sichergestellt, dass weiterhin eine Mehrheit von Sites gebildet werden kann (um das Szenario der Systemspaltung 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:
```
root # crm cluster rename NEW_NAME
```
Stoppen und starten Sie den Service pacemaker neu, damit die Änderungen wirksam werden:
```
root # 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 einem bestehenden Geo-Cluster 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 zu einem 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 unter 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 unter Administration Guide.

5 Installation #

SUSE Linux Enterprise High Availability Extension bietet Unterstützung für Hochverfügbarkeits-Cluster über unbegrenzte Entfernungen.

Um einen GeoCluster einzurichten, benötigen Sie die in den folgenden Installationsschemata enthaltenen Pakete:

Hochverfügbarkeit (mit dem Namen sles_ha in der Befehlszeile)
Geo-Clustering für Hochverfügbarkeit (mit dem Namen ha_geo in der Befehlszeile)

Beide Schemata sind nur verfügbar, wenn Sie Ihr System beim SUSE Customer Center (oder bei einem lokalen Registrierungsserver) registriert und die jeweiligen Module oder Installationsmedien als Erweiterung hinzugefügt haben. Informationen zur Installation von Erweiterungen finden Sie im Bereitstellungshandbuch für SUSE Linux Enterprise 15 SP4.

Verwenden Sie Zypper zum Installieren der Pakete beider Schemata über die Kommandozeile:

root # zypper install -t pattern ha_sles ha_geo

Wichtig: Installation der Softwarepakete bei allen Parteien

Die für hohe Verfügbarkeit und GeoCluster benötigten Softwarepakete werden nicht automatisch auf die Cluster-Knoten kopiert.

Installieren Sie SUSE Linux Enterprise Server 15 SP4 sowie die ha_sles- und ha_geo-Schemata auf allen Rechnern, die Teil Ihres Geo-Clusters sind.
Statt die Pakete manuell auf allen Rechnern zu installieren, die Teil Ihres Clusters sein werden, können Sie mit AutoYaST vorhandene Knoten klonen. Weitere Informationen finden Sie im 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 1: Einrichten der ersten Site (amsterdam) mit crm cluster geo_init #

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.
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.
Melden Sie sich bei einem Knoten eines vorhandenen Clusters an (z. B. beim Knoten alice des Clusters amsterdam).

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

root # crm cluster geo_init \
  --clusters1 "amsterdam=192.168.201.100 berlin=192.168.202.100" \
  --tickets2 ticket-nfs \
  --arbitrator3 192.168.203.100

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 1 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 2 beschrieben). Das Skript benötigt SSH-Zugriff auf eine bereits konfigurierte Cluster-Site und fügt dann den aktuellen Cluster zum GeoCluster hinzu.

Vorgehen 2: Hinzufügen der zweiten Site (berlin) mit ccrm cluster geo_join #

Melden Sie sich bei einem Knoten der Cluster-Site an, die Sie hinzufügen möchten (z. B. beim Knoten charlie des Clusters berlin).

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

root # crm cluster geo_join \
  --cluster-node1 192.168.201.100\
  --clusters2 "amsterdam=192.168.201.100 berlin=192.168.202.100"

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 bereits vorhandenen Cluster-Site verwenden. Alternativ können Sie die IP-Adresse oder den Hostnamen eines bereits für Ihren GeoCluster konfigurierten Vermittlers verwenden.

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 den Vermittler mit crm cluster geo_init_arbitrator ein.

Vorgehen 3: Einrichten des Vermittlers mit crm cluster geo_init_arbitrator #

Melden Sie sich bei dem Rechner an, den Sie als Vermittler verwenden möchten.

Führen Sie den folgenden Befehl aus. Beispiel:

root # crm cluster geo_init_arbitrator --cluster-node1 192.168.201.100

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 Hawk4 überwacht werden sollen, muss SUSE Linux Enterprise High Availability Extension 15 SP4 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 4: Verwendung des Hawk2-Dashboards #

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.
Melden Sie sich an der Hawk2-Weboberfläche an.
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.
Abbildung 2: Hawk2-Dashboard mit einer Cluster-Site – (amsterdam) #
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.
  Abbildung 3: Hawk2-Dashboard mit beiden Cluster-Sites #
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 GeoCluster jedoch in einen funktionierenden GeoCluster zu überführen, der in einer Produktionsumgebung eingesetzt werden kann, sind weitere Schritte erforderlich. Siehe Erforderliche Schritte für den Abschluss des GeoCluster-Setups.

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

11 Weitere Informationen #

Mehr Dokumentation zu diesem Produkt ist unter https://documentation.suse.com/sle-ha/ verfügbar. Weitere Konfigurations- und Verwaltungsaufgaben finden Sie im umfassenden Geo Clustering-Handbuch
Informationen zur Datenreproduktion in Geo-Clusters über DRBD finden Sie im folgenden Dokument Bewährte Vorgehensweisen in SUSE.

12 Rechtliche Hinweise #

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 im Abschnitt „GNU Free Documentation License“.

Die SUSE-Marken finden Sie unter http://www.suse.com/company/legal/. Alle anderen Marken von Drittanbietern sind Besitz ihrer jeweiligen Eigentümer. Markensymbole (®, ™ usw.) kennzeichnen Marken von SUSE und ihren Tochtergesellschaften. Sternchen (*) kennzeichnen Marken von Drittanbietern.

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