Share via

Pacemaker für Verfügbarkeitsgruppen und Failoverclusterinstanzen unter Linux

  • Artikel

Gilt für:SQL Server – Linux

Ab SQL Server 2017 (14.x) wird SQL Server sowohl unter Linux als auch Windows unterstützt. Ebenso wie bei Windows-basierten SQL Server-Bereitstellungen müssen auch SQL Server-Datenbanken und -Instanzen unter Linux hochverfügbar sein. In diesem Artikel werden grundlegende Informationen zum Verständnis von Pacemaker mit Corosync bereitgestellt. Außerdem wird deren Planung und Bereitstellung für SQL Server-Konfigurationen behandelt.

Grundlagen zu Hochverfügbarkeits-Add-Ons und -erweiterungen

Alle derzeit unterstützten Distributionen verfügen über ein Hochverfügbarkeits-Add-On oder eine -erweiterung, die auf dem Pacemaker-Clusteringstapel basiert. Dieser enthält zwei Hauptkomponenten: Pacemaker und Corosync. Insgesamt umfasst der Stapel die folgenden Komponenten:

  • Pacemaker: Die Hauptkomponente für das Clustering, die für die Koordination zwischen den Clustercomputern sorgt
  • Corosync: Ein System, das aus einem Framework und aus mehreren APIs besteht, die beispielsweise das Quorum bereitstellen oder fehlgeschlagene Prozesse neu starten können
  • libQB: Eine Bibliothek, die beispielsweise Protokollierungsfunktionen bereitstellt
  • Ressourcen-Agent: Ein Feature, das spezifische Funktionen zur Anwendungsintegration mit Pacemaker bereitstellt
  • Fence-Agent: Ein Agent, der Skripte und Funktionen umfasst, mit denen sich Knoten isolieren und fehlerhafte Knoten verwalten lassen

Hinweis

Der Clusterstapel wird unter Linux üblicherweise als Pacemaker bezeichnet.

Diese Lösung ähnelt zwar in gewisser Weise der Bereitstellung von Clusterkonfigurationen mit Windows, weist aber gleichzeitig zahlreiche Unterschiede auf. Unter Windows wird für das Clustering der Windows Server-Failovercluster (WSFC) verwendet, der in das Betriebssystem integriert ist. Das Feature zur Erstellung eines WSFC (Failoverclustering) ist standardmäßig deaktiviert. Verfügbarkeitsgruppen und Failoverclusterinstanzen basieren in Windows auf einem WSFC. In diesen sind sie aufgrund der spezifischen Ressourcen-DLL, die von SQL Server bereitgestellt wird, fest integriert. Eine Lösung mit einer solch engen Kopplung ist vor allem deshalb möglich, weil sie von nur einem Anbieter bereitgestellt wird.

Diagram of high availability basics.

Pacemaker ist für jede unterstützte Linux-Distribution verfügbar. Die Clusteringkomponente kann allerdings an verschiedene Distributionen angepasst sein und unterschiedliche Implementierungen und Versionen aufweisen. Auf einige Unterschiede wird in den Anweisungen in diesem Artikel eingegangen. Die Clusteringebene ist eine Open-Source-Komponente. Sie ist zwar Bestandteil der Distributionen, allerdings nicht so nahtlos integriert wie WSFC unter Windows. Aus diesem Grund stellt Microsoft mssql-server-ha zur Verfügung. Dadurch können SQL Server und der Pacemaker-Stapel fast die gleichen Funktionen für Verfügbarkeitsgruppen und Failoverclusterinstanzen wie unter Windows bereitstellen.

Die vollständige Pacemaker-Dokumentation mit ausführlichen Beschreibungen und Referenzinformationen für RHEL und SLES finden Sie unter:

Für Ubuntu steht kein Leitfaden zum Thema Verfügbarkeit bereit.

Weitere Informationen zum gesamten Stapel finden Sie auch in der offiziellen Pacemaker-Dokumentation auf der Website von ClusterLabs.

Pacemaker-Konzepte und -Terminologie

In diesem Abschnitt werden allgemeine Konzepte und die Terminologie einer Pacemaker-Implementierung beschrieben.

Node

Ein Knoten ist ein Server in einem Cluster. Ein Pacemaker-Cluster unterstützt nativ bis zu 16 Knoten. Diese Zahl kann überschritten werden, wenn Corosync nicht auf zusätzlichen Knoten ausgeführt wird. Da Corosync aber für SQL Server erforderlich ist, ist die maximale Anzahl von Knoten, über die ein Cluster für eine SQL Server-basierte Konfiguration verfügen kann, auf 16 beschränkt. Dieses Limit wird von Pacemaker vorgegeben und hat nichts mit den maximalen Werten für Verfügbarkeitsgruppen oder Failoverclusterinstanzen zu tun, die von SQL Server erzwungen werden.

Resource

Sowohl bei WSFCs als auch bei Pacemaker-Clustern gibt es das Konzept einer Ressource. Eine Ressource ist eine bestimmte Funktion, die im Kontext des Clusters ausgeführt wird. Dies kann beispielsweise ein Datenträger oder eine IP-Adresse sein. In Pacemaker können z. B. sowohl Ressourcen für Failoverclusterinstanzen als auch für Verfügbarkeitsgruppen erstellt werden. Diese Vorgehensweise ähnelt der für einen WSFC, da beim Konfigurieren einer Verfügbarkeitsgruppe eine SQL Server-Ressource für eine Failoverclusterinstanz oder Verfügbarkeitsgruppenressource verwendet wird. Der Unterschied besteht jedoch darin, dass die SQL Server-Integration mit Pacemaker anders funktioniert.

In Pacemaker gibt es Standard- und Klonressourcen. Klonressourcen werden auf allen Knoten gleichzeitig ausgeführt. Ein Beispiel ist eine IP-Adresse, die für den Lastenausgleich auf mehreren Knoten verwendet wird. Für Failoverclusterinstanzen wird eine Standardressource erstellt, da jeweils nur ein Knoten eine Failoverclusterinstanz hosten kann.

Hinweis

Vorurteilsfreie Kommunikation

In diesem Artikel wird der Begriff Slave (Sklave) verwendet, der in diesem Kontext von Microsoft als beleidigend eingestuft wird. Der Begriff wird in diesem Artikel verwendet, weil er derzeit in der Software verwendet wird. Sobald der Begriff aus der Software entfernt wird, wird er auch aus dem Artikel entfernt.

Wenn eine Verfügbarkeitsgruppe erstellt wird, ist eine besondere Art der Klonressource erforderlich, die als Ressource mit mehreren Zuständen bezeichnet wird. Eine Verfügbarkeitsgruppe enthält zwar nur ein primäres Replikat, wird aber auf allen Knoten ausgeführt, für die sie konfiguriert wurde. Außerdem kann sie möglicherweise Vorgänge wie schreibgeschützte Zugriffe zulassen. Da hierbei Knoten in Echtzeit verwendet werden, gibt es für Ressourcen die beiden Zustände Höhergestuft (vormals Master) und Nicht höhergestuft (vormals Slave). Weitere Informationen finden Sie unter Multi-state resources: Resources that have multiple modes (Ressourcen mit mehreren Zuständen: Ressourcen, die über mehrere Modi verfügen).

Ressourcengruppen und -sets

In Pacemaker gibt es das Konzept einer Ressourcengruppe, das mit Rollen auf einem WSFC vergleichbar ist. Eine Ressourcengruppe (unter SLES auch als Set bezeichnet) ist eine Sammlung von Ressourcen, die zusammenarbeiten und als Einheit ein Failover von einem Knoten auf einen anderen ausführen können. Ressourcengruppen dürfen keine Ressourcen enthalten, die als Höhergestuft oder Nicht höhergestuft konfiguriert sind. Daher können sie nicht für Verfügbarkeitsgruppen verwendet werden. Eine Ressourcengruppe kann prinzipiell für Failoverclusterinstanzen verwendet werden. Diese Konfiguration wird jedoch nicht empfohlen.

Einschränkungen

Auf einem WSFC gibt es verschiedene Ressourcenparameter und Abhängigkeiten. Mit Letzteren wird für den WSFC die Beziehung zwischen einer unter- und einer übergeordneten Ressource definiert. Eine Abhängigkeit ist eine Regel, die dem WSFC mitteilt, welche Ressource zuerst online sein muss.

Auf einem Pacemaker-Cluster gibt es zwar keine Abhängigkeiten, dafür jedoch Einschränkungen. Unterschieden werden Kollokations-, Orts- und Sortierungseinschränkungen.

  • Mit einer Kollokationseinschränkung wird festgelegt, ob die Ausführung von Ressourcen auf demselben Knoten erzwungen werden soll.
  • Mit einer Ortseinschränkung wird dem Pacemaker-Cluster mitgeteilt, an welcher Stelle eine Ressource ausgeführt oder nicht ausgeführt werden darf.
  • Mit einer Sortierungseinschränkung wird dem Pacemaker-Cluster die Reihenfolge mitgeteilt, in der die Ressourcen gestartet werden sollen.

Hinweis

Für Ressourcen in einer Ressourcengruppe sind keine Kollokationseinschränkungen erforderlich, da diese Ressourcen als Einheit betrachtet werden.

Quorum, Fence-Agents und STONITH

Ein Quorum in Pacemaker ähnelt konzeptionell dem eines WSFC. Mit einem Clusterquorum soll sichergestellt werden, dass der Cluster dauerhaft ausgeführt wird. Sowohl WSFCs als auch Hochverfügbarkeits-Add-Ons für Linux-Distributionen nutzen Abstimmungen, bei denen jeder Knoten für das Quorum berücksichtigt wird. Dabei sollte immer eine Mehrheit der Stimmen angestrebt werden, da ansonsten im schlimmsten Fall der Cluster heruntergefahren wird.

Anders als bei einem WSFC gibt es keine Zeugenressource für das Quorum. Das Ziel besteht aber ebenso wie bei einem WSFC darin, eine ungerade Anzahl abstimmender Knoten sicherzustellen. Die Quorumkonfiguration für Verfügbarkeitsgruppen unterscheidet sich von der für Failoverclusterinstanzen.

WSFCs überwachen den Teilnahmestatus von Knoten und greifen bei Problemen ein. In neueren WSFC-Versionen gibt es beispielsweise Features, mit denen ein Knoten in die Quarantäne verschoben werden kann, wenn sich dieser nicht wie erwartet verhält oder nicht verfügbar ist (etwa dann, wenn der Knoten inaktiv oder die Netzwerkverbindung unterbrochen ist). Unter Linux wird diese Funktion von einem Fence-Agent bereitgestellt. Dieses Konzept wird manchmal als Fencing (Umgrenzung) bezeichnet. Fence-Agents sind jedoch an die Bereitstellung angepasst und werden häufig von Hardwareanbietern und einigen Softwareanbietern (beispielsweise Anbietern von Hypervisoren) bereitgestellt. VMware stellt beispielsweise einen Fence-Agent zur Verfügung, der für Linux-VMs verwendet werden kann, die mit vSphere virtualisiert werden.

Quorum und Fencing sind eng mit einem weiteren Konzept verknüpft, das unter dem Namen STONITH (Shoot the Other Node in the Head) bekannt ist. STONITH ist erforderlich, damit ein Pacemaker-Cluster auf allen Linux-Distributionen unterstützt wird. Weitere Informationen finden Sie unter Fencing in a Red Hat High Availability Cluster (Fencing in einem Red Hat-Hochverfügbarkeitscluster) (RHEL).

corosync.conf

Die Datei corosync.conf enthält die Konfiguration des Clusters und befindet sich im Verzeichnis /etc/corosync. Wenn der Cluster richtig eingerichtet wurde, müssen Sie die Datei für Routinevorgänge nicht ändern.

Speicherort der Clusterprotokolldatei

Die Speicherorte für Protokolle von Pacemaker-Clustern unterscheiden sich je nach Distribution.

  • RHEL und SLES: /var/log/cluster/corosync.log
  • Ubuntu: /var/log/corosync/corosync.log

Wenn Sie den Standardspeicherort für Protokolle ändern möchten, müssen Sie corosync.conf anpassen.

Planen von Pacemaker-Clustern für SQL Server

In diesem Abschnitt werden die wichtigen Punkte beschrieben, die Sie bei der Planung eines Pacemaker-Clusters berücksichtigen müssen.

Virtualisieren von Linux-basierten Pacemaker-Clustern für SQL Server

Wenn Sie virtuelle Computer für Linux-basierte SQL Server-Bereitstellungen für Verfügbarkeitsgruppen und Failoverclusterinstanzen nutzen, gelten dieselben Regeln wie für ihre Windows-basierten Gegenstücke. Es gibt grundlegende Regeln für die Unterstützungsmöglichkeiten virtualisierter SQL Server-Bereitstellungen, die von Microsoft in der Supportrichtlinie für Microsoft SQL Server-Produkte bereitgestellt werden, die in einer Virtualisierungsumgebung für Hardware ausgeführt werden. Darüber hinaus gelten für verschiedene Hypervisoren wie Microsoft Hyper-V und VMware ESXi möglicherweise noch andere Regeln aufgrund plattformspezifischer Unterschiede.

Bei der Virtualisierung von Verfügbarkeitsgruppen und Failoverclusterinstanzen müssen Sie sicherstellen, dass für die Knoten eines bestimmten Pacemaker-Clusters Antiaffinität festgelegt ist. Wenn in einer Verfügbarkeitsgruppe oder Failoverclusterinstanz die VMs, die SQL Server hosten, für Hochverfügbarkeit konfiguriert sind, sollten diese niemals auf demselben Hypervisorhost ausgeführt werden. Wenn z. B. eine Failoverclusterinstanz mit zwei Knoten bereitgestellt wird, müssen mindestens drei Hypervisorhosts vorhanden sein, damit eine VM, die einen Knoten hostet, bei einem Hostausfall an anderer Stelle platziert werden kann. Das ist vor allem dann wichtig, wenn Features wie die Livemigration oder vMotion verwendet werden.

Weitere Informationen finden Sie in den folgenden Dokumenten:

Netzwerk

Ein Pacemaker-Cluster benötigt im Gegensatz zu einem WSFC keinen dedizierten Namen und auch keine dedizierte IP-Adresse für den Cluster selbst. Für Verfügbarkeitsgruppen und Failoverclusterinstanzen sind IP-Adressen (siehe jeweilige Dokumentation für weitere Informationen), aber keine Namen erforderlich, da keine Netzwerknamensressource vorhanden ist. Unter SLES kann eine IP-Adresse zwar zu Verwaltungszwecken konfiguriert werden, jedoch ist dies nicht erforderlich (siehe Erstellen des Pacemaker-Clusters).

Eine Gemeinsamkeit zwischen einem WSFC und Pacemaker besteht darin, dass Pacemaker prinzipiell redundante Netzwerke und damit verschiedene (virtuelle oder physische) Netzwerkadapter mit unterschiedlichen IP-Adressen bevorzugt. Bei der Clusterkonfiguration verfügt dann jede IP-Adresse über einen eigenen Ring. Ebenso wie im Fall von WSFCs sind viele Implementierungen aktuell jedoch virtualisiert oder befinden in der öffentlichen Cloud, wo nur ein einziger virtueller Netzwerkadapter für den Server verfügbar ist. Wenn alle physischen und virtuellen Netzwerkadapter mit demselben physischen oder virtuellen Switch verbunden sind, gibt es keine tatsächliche Redundanz auf der Netzwerkebene. Genau genommen können deswegen für den virtuellen Computer nicht mehrere Netzwerkadapter konfiguriert werden. Netzwerkredundanz für virtualisierte Bereitstellungen wird in der Regel durch den Hypervisor selbst sichergestellt. Wenn eine öffentliche Cloud genutzt wird, wird die Redundanz immer dort sichergestellt.

Wenn Pacemaker mit mehreren Netzwerkadaptern verwendet wird, besteht ein Unterschied zu einem WSFC darin, dass Pacemaker mehrere IP-Adressen in einem Subnetz zulässt. Das ist bei einem WSFC nicht der Fall. Weitere Informationen zu mehreren Subnetzen und Linux-Clustern finden Sie im Artikel Konfigurieren mehrerer Subnetze.

Quorum und STONITH

Die Quorumkonfiguration und -anforderungen beziehen sich auf spezifische SQL Server-Bereitstellungen für Verfügbarkeitsgruppen und Failoverclusterinstanzen.

Für Pacemaker-Cluster ist STONITH erforderlich. Wie Sie STONITH konfigurieren, erfahren Sie in der Dokumentation Ihrer Distribution. Ein Beispiel für SLES finden Sie unter Storage-based Fencing (Speicherbasiertes Fencing). Für VMware vCenter für ESXI-basierte Lösungen ist auch ein STONITH-Agent verfügbar. Weitere Informationen finden Sie unter STONITH-Plug-In-Agent für SOAP-Fencing in VMware vCenter (inoffiziell).

Interoperabilität

In diesem Abschnitt wird beschrieben, wie ein Linux-basierter Cluster mit einem WSFC oder mit anderen Linux-Distributionen interagieren kann.

WSFC

Derzeit kann ein WSFC nicht direkt mit einem Pacemaker-Cluster interagieren. Es ist daher nicht möglich, eine Verfügbarkeitsgruppe oder Failoverclusterinstanz zu erstellen, die für einen WSFC und für Pacemaker verwendet werden kann. Es gibt jedoch zwei Interoperabilitätslösungen, die für Verfügbarkeitsgruppen entwickelt wurden. Eine Failoverclusterinstanz kann nur dann Teil einer plattformübergreifenden Konfiguration sein, wenn sie als Instanz in einem der folgenden beiden Szenarios verwendet wird:

Andere Linux-Distributionen

Unter Linux müssen sich alle Knoten eines Pacemaker-Clusters auf derselben Distribution befinden. Ein RHEL-Knoten kann beispielsweise nicht Teil eines Pacemaker-Clusters sein, der über einen SLES-Knoten verfügt. Der Hauptgrund dafür wurde bereits erwähnt: Da Distributionen möglicherweise unterschiedliche Versionen und Funktionen aufweisen, kann dies die Funktionsfähigkeit beeinträchtigen. Wenn Sie unterschiedliche Distributionen verwenden, hat dies dieselben Auswirkungen, wie wenn Sie WSFCs und Linux kombinieren. Verwenden Sie daher den Clustertyp „None“ oder verteilte Verfügbarkeitsgruppen.

Zugehöriger Inhalt