Kurzanleitung zu Geo-Clustering #

Geo-Cluster, 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 Geo-Cluster 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 Geo-Cluster kann einen oder mehrere Vermittler besitzen.

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

 

Sie können auch einen Geo-Cluster mit zwei Sites ohne Vermittler ausführen. In diesem Fall muss ein Geo-Cluster-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.

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

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 (Cluster-Knoten und Vermittler) benötigen mindestens die folgenden Module und Erweiterungen:

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 zum Konfigurieren und Verwalten eines Geo-Clusters 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. Weitere Informationen finden Sie im Installationshandbuch für SUSE Linux Enterprise Server.

Verwenden Sie das Kommando crm cluster geo_init, um einen vorhandenen Cluster zur ersten Site eines Geo-Clusters 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 würde folgende booth-Konfiguration und Cluster-Ressourcen erzeugen:

# 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 Geo-Clusters 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 Geo-Cluster 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 Geo-Clusters 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 Geo-Cluster überwachen und verwalten.

Die Bootstrap-Skripte für das Geo-Clustering ermöglichen das schnelle Einrichten eines grundlegenden Geo-Clusters, 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 Geo-Cluster-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 Geo-Clusters 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 Kapitel 5, Synchronizing configuration files across all sites and arbitrators.

• Die CIB (Cluster Information Database) wird nicht automatisch zwischen den Cluster-Sites eines Geo-Clusters 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 im Abschnitt 6.4, „Transferring the resource configuration to other cluster sites“.