Einführung in SUSE Linux Enterprise High Availability

SUSE Linux Enterprise High Availability ist mit den folgenden Produkten verfügbar:

SUSE Linux Enterprise High Availability eliminiert Single Points of Failure und verbessert so die Verfügbarkeit und Verwaltbarkeit wichtiger Ressourcen. Dadurch gewährleisten Sie Geschäftskontinuität, schützen die Datenintegrität und reduzieren ungeplante Ausfallzeiten bei kritischen Workloads.

Die folgende Abbildung zeigt einen Cluster mit drei Knoten. Auf jedem der Knoten ist ein Webserver installiert, der zwei Websites hostet. Alle Daten, Grafiken und Inhalte für diese Websites sind auf einem freigegebenen Festplatten-Subsystem gespeichert, das mit allen Knoten verbunden ist.

Abbildung 1: Cluster mit zwei Knoten #

 

Im normalen Clusterbetrieb befindet sich jeder Knoten in ständiger Kommunikation mit den anderen Knoten im Cluster und überprüft zur Fehlererkennung in regelmäßigen Abständen die Ressourcen.

Die folgende Abbildung zeigt, wie der Cluster Ressourcen verschiebt, wenn Webserver 1 aufgrund von Hardware- oder Softwareproblemen ausfällt.

Abbildung 2: Cluster mit drei Knoten nach Ausfall eines Knotens #

 

Website A wird auf Webserver 2 und Website B auf Webserver 3 verschoben. Die Websites sind weiterhin verfügbar und werden gleichmäßig auf die verbleibenden Clusterknoten verteilt.

Als Webserver 1 ausfiel, hat die High Availability-Software die folgenden Aufgaben ausgeführt:

In diesem Beispiel erfolgte der Failover schnell und die Benutzer konnten innerhalb von Sekunden wieder auf die Websites zugreifen – und zwar in der Regel, ohne sich erneut anmelden zu müssen.

Wenn Webserver 1 in den normalen Betriebszustand zurückkehrt, können Website A und Website B automatisch wieder auf Webserver 1 verschoben werden „(Failback“). Dadurch entsteht eine gewisse Ausfallzeit. Alternativ können Sie die Ressourcen so konfigurieren, dass nur zu einem bestimmten Zeitpunkt ein Failback erfolgt, der eine minimale Unterbrechung des Diensts verursacht.

Ein Hochverfügbarkeits-Cluster ist eine Gruppe von Servern, die zusammenarbeiten, um die Verfügbarkeit von Anwendungen oder Diensten sicherzustellen. Server, die als Mitglieder des Clusters konfiguriert sind, werden als Knoten bezeichnet. Fällt ein Knoten aus, können die auf ihm ausgeführten Ressourcen auf einen anderen Knoten im Cluster verschoben werden. SUSE Linux Enterprise High Availability unterstützt Cluster mit bis zu 32 Knoten. Cluster fallen jedoch in der Regel in eine von zwei Kategorien: Cluster mit zwei Knoten oder Cluster mit einer ungeraden Anzahl von Knoten (in der Regel drei oder fünf).

Die interne Clusterkommunikation wird von Corosync übernommen. Die Corosync Cluster Engine ist ein Gruppenkommunikationssystem, das Messaging-, Mitgliedschafts- und Quorum-Informationen zum Cluster bereitstellt. In SUSE Linux Enterprise High Availability 16 verwendet Corosync „kronosnet“ (knet) als Standard-Transportprotokoll.

Es wird dringend empfohlen, mindestens zwei Kommunikationskanäle für den Cluster zu konfigurieren. Die bevorzugte Methode ist die Verwendung von Netzwerkgeräte-Bonding. Wenn Sie kein Netzwerk-Bonding verwenden können, können Sie in Corosync einen redundanten Kommunikationskanal einrichten (auch bekannt als zweiter „Ring“).

In einem High Availability-Cluster werden die Anwendungen und Dienste, die hochverfügbar sein müssen, als Ressourcen bezeichnet. Bei Clusterressourcen kann es sich um Websites, E-Mail-Server, Datenbanken, Dateisysteme, virtuelle Rechner und andere serverbasierte Anwendungen oder Dienste handeln, die Sie den Benutzern stets zur Verfügung stellen möchten. Sie können Ressourcen bei Bedarf starten, anhalten, überwachen und verschieben. Sie können auch angeben, ob bestimmte Ressourcen zusammen auf demselben Knoten ausgeführt werden sollen oder ob sie nacheinander gestartet und angehalten werden sollen. Wenn ein Clusterknoten ausfällt, gehen die auf ihm ausgeführten Ressourcen nicht verloren, sondern werden auf einen anderen Knoten verschoben (Failover).

In SUSE Linux Enterprise High Availability ist der Cluster-Ressourcenmanager (CRM) Pacemaker, der alle Clusterdienste verwaltet und koordiniert. Pacemaker verwendet Ressourcenagenten (RAs), um Ressourcen zu starten, anzuhalten und zu überwachen. Ein Ressourcenagent abstrahiert die von ihm verwaltete Ressource und präsentiert dem Cluster ihren Status. SUSE Linux Enterprise High Availability unterstützt viele verschiedene Ressourcenagenten, die für die Verwaltung bestimmter Anwendungs- oder Diensttypen konzipiert sind.

Bei einem Split Brain-Szenario werden Clusterknoten in zwei oder mehr Gruppen (oder Partitionen) unterteilt, die sich gegenseitig nicht erkennen können. Dies kann beispielsweise durch einen Hardware- oder Softwarefehler oder eine fehlerhafte Netzwerkverbindung erfolgen. Ein Split Brain-Szenario kann durch das Fencing (Zurücksetzen oder Ausschalten) eines oder mehrerer Knoten aufgelöst werden. Beim Fencing auf Knotenebene wird verhindert, dass ein ausgefallener Knoten auf gemeinsam genutzte Ressourcen zugreift und dass Clusterressourcen auf einem Knoten mit unsicherem Status ausgeführt werden.

SUSE Linux Enterprise High Availability verwendet STONITH als Fencing-Mechanismus für Knoten. Damit sie unterstützt werden, müssen alle SUSE Linux Enterprise High Availability-Cluster über mindestens ein STONITH-Gerät verfügen. Für kritische Workloads wird die Verwendung von zwei oder drei STONITH-Geräten empfohlen: Als STONITH-Gerät kann entweder ein physisches Gerät (ein Netzschalter) oder ein Softwaremechanismus (SBD in Kombination mit einem Watchdog) verwendet werden.

Wenn die Kommunikation zwischen einem oder mehreren Knoten und dem Rest des Clusters ausfällt (ein Split Brain-Szenario, entsteht eine Clusterpartition. Die Knoten können nur mit anderen Knoten in derselben Partition kommunizieren und erkennen die anderen Knoten nicht. Eine Clusterpartition hat ein Quorum (oder ist „quorumfähig“), wenn sie über die Mehrheit der Knoten (oder „Stimmen“) verfügt. Dies wird durch die Berechnung des Quorums bestimmt. Das Quorum muss berechnet werden, um das Fencing von nicht quorumfähigen Knoten zu ermöglichen.

Corosync berechnet das Quorum anhand der folgenden Formel:

N ≥ C/2 + 1

N = minimum number of operational nodes
C = number of cluster nodes

Ein Cluster mit fünf Knoten benötigt beispielsweise mindestens drei betriebsbereite Knoten, um das Quorum aufrechtzuerhalten.

Bei Clustern mit einer geraden Anzahl von Knoten, insbesondere bei Clustern mit zwei Knoten, kann es sein, dass die Anzahl der Knoten in jeder Partition gleich ist und daher keine Mehrheit besteht. Um diese Situation zu vermeiden, können Sie den Cluster so konfigurieren, dass er QDevice in Kombination mit QNetd verwendet. QNetd ist ein Vermittler, der außerhalb des Clusters ausgeführt wird. Er kommuniziert mit dem QDevice-Daemon, der auf den Clusterknoten ausgeführt wird, um eine konfigurierbare Anzahl von Stimmen für die Berechnung des Quorums bereitzustellen. Dadurch kann ein Cluster mehr Knotenausfälle verkraften, als die Standard-Quorum-Regeln zulassen.

High Availability-Cluster können ein gemeinsam genutztes Festplatten-Subsystem enthalten, das über Fibre Channel oder iSCSI verbunden ist. Bei Ausfall eines Knotens werden die zuvor auf diesem ausgefallenen Knoten eingebundenen Festplattenverzeichnisse automatisch auf einem anderen Knoten im Cluster eingebunden. Auf diese Weise können die Benutzer kontinuierlich auf die Verzeichnisse des gemeinsamen genutzten Festplatten-Subsystems zugreifen. Zu den auf der gemeinsam genutzten Festplatte gespeicherten Inhalten können Daten, Anwendungen und Dienste gehören.

Die folgende Abbildung zeigt, wie eine typische Konfiguration eines Fibre Channel-Clusters aussehen könnte. Die grünen Linien stellen Verbindungen mit einem Ethernet-Netzschalter dar, der einen Knoten neu starten kann, wenn bei einer Ping-Anfrage ein Fehler auftritt.

Abbildung 3: Typische Fibre Channel-Clusterkonfiguration #

 

Die folgende Abbildung zeigt, wie eine typische Konfiguration eines iSCSI-Clusters aussehen könnte.

Abbildung 4: Typische Konfiguration eines iSCSI-Clusters #

 

Obwohl die meisten Cluster ein gemeinsam genutztes Festplatten-Subsystem enthalten, können Sie auch einen Cluster ohne ein gemeinsam genutztes Festplatten-Subsystem erstellen. Die folgende Abbildung zeigt, wie ein Cluster ohne ein gemeinsam genutztes Festplatten-Subsystem aussehen könnte.

Abbildung 5: Typische Clusterkonfiguration ohne gemeinsam genutzten Speicher #

 

SUSE Linux Enterprise High Availability verfügt über eine mehrschichtige Architektur. Die folgende Abbildung zeigt die verschiedenen Schichten und ihre jeweiligen Komponenten.

Abbildung 6: Architektur eines SUSE Linux Enterprise High Availability-Clusters #

 

Viele Aktionen, die im Cluster ausgeführt werden, führen zur einer clusterweiten Änderung, z. B. das Hinzufügen oder Entfernen einer Clusterressource oder das Ändern von Ressourcenbeschränkungen. Im folgenden Beispiel wird erläutert, was im Cluster geschieht, wenn Sie eine solche Aktion ausführen: