In diesem Artikel wird erläutert, wie ein Cluster mit drei Knoten unter Linux mithilfe von Pacemaker erstellt und eine zuvor erstellte Verfügbarkeitsgruppe als Ressource im Cluster hinzugefügt wird. Zur Gewährleistung von Hochverfügbarkeit benötigt eine Verfügbarkeitsgruppe unter Linux drei Knoten. Weitere Informationen hierzu finden Sie unter Hochverfügbarkeit und Schutz von Daten für Verfügbarkeitsgruppenkonfigurationen.
SQL Server ist unter Linux nicht so eng in Pacemaker integriert wie beim Windows Server-Failoverclustering (WSFC). Das Cluster ist keiner SQL-Serverinstanz bekannt, und die gesamte Orchestrierung erfolgt von außen. Pacemaker bietet eine Clusterressourcenorchestrierung. Der virtuelle Netzwerkname ist außerdem spezifisch für das Windows Server-Failoverclustering. In Pacemaker gibt es hierfür keine Entsprechung. Dynamische Verwaltungssichten der Verfügbarkeitsgruppen (DMVs), die Clusterinformationen abfragen, geben in Pacemaker leere Zeilen zurück. Registrieren Sie in DNS den Listenernamen manuell mit der zum Erstellen der virtuellen IP-Ressource verwendeten IP-Adresse, um nach einem Failover einen Listener für eine transparente Neuverbindung zu erstellen.
In den folgenden Abschnitten werden die Schritte zum Einrichten eines Pacemaker-Clusters und Hinzufügen einer Verfügbarkeitsgruppe für jede unterstützte Linux-Verteilung als Ressource im Cluster für Hochverfügbarkeit beschrieben.
Die Clusteringebene basiert auf einem Hochverfügbarkeits-Add-On für Red Hat Enterprise Linux (RHEL), das auf Pacemaker aufbaut.
Hinweis
Für den Zugriff auf die vollständige Red Hat-Dokumentation ist ein gültiges Abonnement erforderlich.
Weitere Informationen zur Clusterkonfiguration, den Optionen für Ressourcen-Agents und der Verwaltung finden Sie in der Referenzdokumentation von RHEL.
Roadmap
Die Schritte zum Erstellen einer Verfügbarkeitsgruppe auf Linux-Servern für Hochverfügbarkeit unterscheiden sich von den Schritten in Windows Server-Failoverclustern. Die allgemeinen Schritte werden in der folgenden Liste beschrieben:
Konfigurieren Sie SQL Server in den Clusterknoten.
Erstellen Sie die Verfügbarkeitsgruppe.
Konfigurieren Sie einen Cluster Resource Manager wie Pacemaker. Diese Anweisungen finden Sie in diesem Artikel.
Die Art und Weise des Konfigurierens eines Clusterressourcen-Managers hängt von der jeweiligen Linux-Distribution ab.
Wichtig
In Produktionsumgebungen wird zur Gewährleistung von Hochverfügbarkeit ein Fencing-Agent benötigt. In den Demos dieser Dokumentation werden keine Fencing-Agents verwendet. Die Demos dienen lediglich zu Testzwecken und Überprüfungen.
Ein Linux-Cluster verwendet Fencing, um den Cluster in einen bekannten Zustand zurückzusetzen. Wie das Fencing konfiguriert wird, hängt von der Verteilung und der Umgebung ab. Derzeit ist Fencing in einigen Cloudumgebungen nicht verfügbar. Weitere Informationen finden Sie unter Supportrichtlinien für RHEL-Hochverfügbarkeitscluster – Virtualisierungsplattformen.
Fügen Sie die Verfügbarkeitsgruppe als Ressource im Cluster hinzu.
Aktivieren Sie das Hochverfügbarkeitsabonnement, und konfigurieren Sie dann Pacemaker, um die Hochverfügbarkeit für RHEL zu konfigurieren.
Aktivieren des Hochverfügbarkeitsabonnements für RHEL
Jeder Knoten im Cluster muss über ein entsprechendes Abonnement für RHEL und das Hochverfügbarkeits-Add-On verfügen. Überprüfen Sie die Anforderungen unter Installieren von Hochverfügbarkeitsclusterpaketen in Red Hat Enterprise Linux. Führen Sie die folgenden Schritte aus, um das Abonnement un die Repositorys zu konfigurieren:
Registrieren Sie das System.
sudo subscription-manager register
Geben Sie Ihren Benutzernamen und Ihr Kennwort ein.
Listen Sie die verfügbaren Pools für die Registrierung auf.
sudo subscription-manager list --available
Notieren Sie sich aus der Liste der verfügbaren Pools die Pool-ID für das Hochverfügbarkeitsabonnement.
Aktualisieren Sie das folgende Skript. Ersetzen Sie <pool id>
durch die Pool-ID für Hochverfügbarkeit aus dem vorherigen Schritt. Führen Sie das Skript aus, um das Abonnement anzufügen.
sudo subscription-manager attach --pool=<pool id>
Aktivieren Sie das Repository.
RHEL 7
sudo subscription-manager repos --enable=rhel-ha-for-rhel-7-server-rpms
RHEL 8
sudo subscription-manager repos --enable=rhel-8-for-x86_64-highavailability-rpms
Weitere Informationen finden Sie unter Pacemaker – der hochverfügbare Open-Source-Cluster.
Führen Sie nach dem Konfigurieren des Abonnements die folgenden Schritte aus, um Pacemaker zu konfigurieren:
Führen Sie die folgenden Schritte aus, um nach der Registrierung des Abonnements Pacemaker zu konfigurieren:
Öffnen Sie auf allen Clusterknoten die Pacemaker-Firewallports. Führen Sie zum Öffnen dieser Ports mit firewalld
folgenden Befehl aus:
sudo firewall-cmd --permanent --add-service=high-availability
sudo firewall-cmd --reload
Wenn die Firewall nicht über eine integrierte Konfiguration mit hoher Verfügbarkeit verfügt, öffnen Sie die folgenden Ports für Pacemaker.
- TCP: Ports 2224, 3121, 21064
- UDP: Port 5405
Installieren Sie Pacemaker-Pakete auf allen Knoten.
sudo yum install pacemaker pcs fence-agents-all resource-agents
Legen Sie das Kennwort für den Standardbenutzer fest, der beim Installieren von Pacemaker und Corosync-Paketen erstellt wird. Verwenden Sie auf allen Knoten dasselbe Kennwort.
sudo passwd hacluster
Aktivieren und starten Sie den pcsd
-Dienst und Pacemaker, um den Knoten nach dem Neustart einen erneuten Beitritt zum Cluster zu erlauben. Führen Sie den folgenden Befehl auf allen Knoten aus.
sudo systemctl enable pcsd
sudo systemctl start pcsd
sudo systemctl enable pacemaker
Erstellen Sie den Cluster. Führen Sie den folgenden Befehl aus, um den Cluster zu erstellen:
RHEL 7
sudo pcs cluster auth <node1> <node2> <node3> -u hacluster -p <password for hacluster>
sudo pcs cluster setup --name <clusterName> <node1> <node2> <node3>
sudo pcs cluster start --all
sudo pcs cluster enable --all
RHEL 8
Bei RHEL 8 müssen Sie die Knoten separat authentifizieren. Geben Sie den Benutzernamen und das Kennwort für „hacluster“ manuell ein, wenn Sie dazu aufgefordert werden.
sudo pcs host auth <node1> <node2> <node3>
sudo pcs cluster setup <clusterName> <node1> <node2> <node3>
sudo pcs cluster start --all
sudo pcs cluster enable --all
Hinweis
Wenn Sie vorher einen Cluster auf denselben Knoten konfiguriert haben, müssen Sie die Option --force
verwenden, wenn Sie pcs cluster setup
ausführen. Diese Option entspricht der Ausführung von pcs cluster destroy
. Führen Sie sudo systemctl enable pacemaker
aus, um Pacemaker erneut zu aktivieren.
Installieren Sie den SQL Server-Ressourcenagent für SQL Server. Führen Sie die folgenden Befehle auf allen Knoten aus.
sudo yum install mssql-server-ha
Verwenden Sie nach dem Konfigurieren von Pacemaker pcs
, um mit dem Cluster zu interagieren. Führen Sie alle Befehle auf einem Knoten aus dem Cluster aus.
Überlegungen zu mehreren Netzwerkschnittstellen (NICs)
Folgen Sie den folgenden Vorschlägen, wenn Sie hohe Verfügbarkeit auf Servern mit mehreren NICs einrichten:
Stellen Sie sicher, dass die hosts
Datei so eingerichtet ist, dass die Server-IP-Adressen für die verschiedenen NICs auf dem Hostnamen des Linux-Servers auf jedem Knoten aufgelöst werden.
Wenn Sie den Cluster mithilfe von Pacemaker einrichten, sollte zur Verwendung des Hostnamens des Servers Corosync konfiguriert werden, um die Konfiguration für alle NICs festzulegen. Wir wollen nur die Pacemaker/Corosync-Kommunikation über eine einzelne NIC. Nachdem der Pacemaker-Cluster konfiguriert wurde, ändern Sie die Konfiguration in der Datei corosync.conf
, und aktualisieren Sie die IP-Adresse für die dedizierte NIC, die Sie für die Pacemaker/Corosync-Kommunikation verwenden möchten.
Der <hostname>
in der Datei corosync.conf
sollte mit der Ausgabe identisch sein, die beim umgekehrten Nachschlagen (ping -a <ip_address>
) erfolgt. Außerdem sollte es der auf dem Host konfigurierte kurze Name sein. Stellen Sie sicher, dass die Date hosts
auch die richtige IP-Adresse für die Namensauflösung darstellt.
Die Änderungen am corosync.conf
-Dateibeispiel sind nachfolgend markiert:
nodelist {
node {
ring0_addr: <ip_address_of_node1_NIC1>
name: <hostname_of_node1>
nodeid: 1
}
node {
ring0_addr: <ip_address_of_node2_NIC1>
name: <hostname_of_node2>
nodeid: 2
}
node {
ring0_addr: <ip_address_of_node3_NIC1>
name: <hostname_of_node3>
nodeid: 3
}
}
Bei Anbietern von Pacemaker-Clustern muss ein ausgefallener Knoten mit einem Fencinggerät, das für eine unterstützte Clustereinrichtung konfiguriert ist, gesichert werden. Wenn der Clusterressourcen-Manager den Status eines Knotens oder einer Ressource auf einem Knoten nicht ermitteln kann, wird der Cluster mithilfe von Fencing wieder in einen bekannten Status versetzt.
Ein Fencinggerät stellt einen Fencing-Agent bereit. Ein Beispiel für das Erstellen eines Fencinggeräts für diesen Cluster in Azure finden Sie unter Einrichten von Pacemaker unter Red Hat Enterprise Linux in Azure. Ändern Sie die Anweisungen für Ihre Umgebung.
Durch Fencing auf Ressourcenebene wird sichergestellt, dass bei einem Ausfall durch die Konfiguration einer Ressource keine Daten beschädigt werden. Sie können Fencing auf Ressourcenebene beispielsweise dazu verwenden, den Datenträger auf einem Knoten bei einem Ausfall der Kommunikationsverbindung als veraltet zu markieren.
Mit dem Fencing auf Knotenebene wird sichergestellt, dass ein Knoten keine Ressourcen ausführt. Dies erfolgt durch Zurücksetzen des Knotens. Pacemaker unterstützt eine Vielzahl von Fencinggeräten. Beispiele hierfür sind eine unterbrechungsfreie Stromversorgung oder Verwaltungsschnittstellenkarten für Server.
Weitere Informationen zum Fencing für fehlerhafte Knoten finden Sie in den folgenden Artikeln:
Hinweis
Da die Fencingkonfiguration auf Knotenebene stark von Ihrer Umgebung abhängt, wird sie für dieses Tutorial deaktiviert (sie kann später konfiguriert werden). Mit dem folgenden Skript wird Fencing auf Knotenebene deaktiviert:
sudo pcs property set stonith-enabled=false
Das Fencing wird lediglich zu Testzwecken deaktiviert. Wenn Sie Pacemaker in einer Produktionsumgebung verwenden möchten, sollten Sie je nach Ihrer Umgebung eine Fencingimplementierung planen und immer aktivieren.
Festlegen der Clustereigenschaft „cluster-recheck-interval“
cluster-recheck-interval
gibt das Abrufintervall an, mit dem der Cluster prüft, ob Änderungen in den Ressourcenparametern, Einschränkungen oder anderen Clusteroptionen vorliegen. Wenn ein Replikat ausfällt, versucht der Cluster, das Replikat in einem Intervall neu zu starten, das durch den Wert failure-timeout
und den Wert cluster-recheck-interval
gebunden ist. Wenn failure-timeout
beispielsweise auf 60 Sekunden und cluster-recheck-interval
auf 120 Sekunden festgelegt ist, wird der Neustart in einem Intervall versucht, das größer als 60 Sekunden, aber kleiner als 120 Sekunden ist. Es wird empfohlen, „failure-timeout“ auf 60 Sekunden und cluster-recheck-interval
auf einen Wert größer als 60 Sekunden festzulegen. cluster-recheck-interval
auf einen kleinen Wert festzulegen, wird nicht empfohlen.
So aktualisieren Sie den Eigenschaftswert auf ein Ausführungsintervall von 2 minutes
:
sudo pcs property set cluster-recheck-interval=2min
Wenn Sie bereits über eine Verfügbarkeitsgruppenressource verfügen, die von einem Pacemaker-Cluster verwaltet wird, hat das Pacemaker-Paket 1.1.18-11.el7 einen Behavior Change für die Clustereinstellung start-failure-is-fatal
für den Fall eingeführt, dass ihr Wert false
ist. Diese Änderung wirkt sich auf den Failoverworkflow aus. Wenn ein primäres Replikat ausfällt, wird für den Cluster ein Failover auf eines der verfügbaren sekundären Replikate erwartet. Stattdessen werden die Benutzer bemerken, dass der Cluster weiterhin versucht, das ausgefallene primäre Replikat zu starten. Wenn dieses primäre Replikat (aufgrund eines dauerhaften Ausfalls) nicht online geschaltet wird, führt der Cluster kein Failover zu einem anderen verfügbaren sekundären Replikat durch. Aufgrund dieser Änderung ist eine zuvor empfohlene Konfiguration zum Festlegen von start-failure-is-fatal
nicht mehr gültig, und für die Einstellung muss der Standardwert true
wiederhergestellt werden.
Darüber hinaus muss die Verfügbarkeitsgruppenressource aktualisiert werden, um die Eigenschaft failure-timeout
einzubeziehen.
So aktualisieren Sie den Eigenschaftswert auf ein Ausführungsintervall von true
:
sudo pcs property set start-failure-is-fatal=true
So aktualisieren Sie die ag_cluster
-Ressourceneigenschaft failure-timeout
auf 60s
:
pcs resource update ag_cluster meta failure-timeout=60s
Weitere Informationen zu Pacemaker-Clustereigenschaften finden Sie unter Pacemaker-Clustereigenschaften.
Erstellen einer SQL Server-Anmeldung für Pacemaker
Erstellen Sie in allen SQL Server-Instanzen eine Server-Anmeldung für Pacemaker.
Die folgende Transact-SQL erstellt eine Anmeldung:
USE [master]
GO
CREATE LOGIN [pacemakerLogin] with PASSWORD= N'ComplexP@$$w0rd!';
ALTER SERVER ROLE [sysadmin] ADD MEMBER [pacemakerLogin];
Für die Erstellung der Verfügbarkeitsgruppe benötigt der Pacemaker-Benutzer die Berechtigungen ALTER
, CONTROL
und VIEW DEFINITION
für die Verfügbarkeitsgruppe, nachdem diese erstellt wurde, aber bevor ihr irgendwelche Knoten hinzugefügt werden.
Speichern Sie in allen SQL Server-Instanzen die Anmeldeinformationen für die SQL Server-Anmeldung.
echo 'pacemakerLogin' >> ~/pacemaker-passwd
echo 'ComplexP@$$w0rd!' >> ~/pacemaker-passwd
sudo mv ~/pacemaker-passwd /var/opt/mssql/secrets/passwd
sudo chown root:root /var/opt/mssql/secrets/passwd
sudo chmod 400 /var/opt/mssql/secrets/passwd # Only readable by root
Erstellen von Verfügbarkeitsgruppenressourcen
Verwenden Sie den Befehl pcs resource create
, und legen Sie die Ressourceneigenschaften fest, um die Verfügbarkeitsgruppenressource zu erstellen. Mit dem folgenden Befehl wird eine ocf:mssql:ag
-Ressource vom Typ Master/untergeordnet für die Verfügbarkeitsgruppe mit dem Namen ag1
erstellt.
RHEL 7
sudo pcs resource create ag_cluster ocf:mssql:ag ag_name=ag1 meta failure-timeout=60s master notify=true
RHEL 8
Mit der Verfügbarkeit von RHEL 8 hat sich die Syntax für das Erstellen geändert. Wenn Sie RHEL 8 verwenden, ist die Terminologie nun nicht mehr master
, sondern promotable
. Verwenden Sie anstelle des obigen Befehls den folgenden Befehl zum Erstellen:
sudo pcs resource create ag_cluster ocf:mssql:ag ag_name=ag1 meta failure-timeout=60s promotable notify=true
Erstellen einer virtuellen IP-Ressource
Führen Sie den folgenden Befehl auf einem Knoten aus, um die virtuelle IP-Adressressource zu erstellen. Verwenden Sie eine verfügbare statische IP-Adresse aus dem Netzwerk. Ersetzen Sie die IP-Adresse zwischen <10.128.16.240>
durch eine gültige IP-Adresse.
sudo pcs resource create virtualip ocf:heartbeat:IPaddr2 ip=<10.128.16.240>
In Pacemaker ist der Name eines virtuellen Servers nicht gleichwertig. Registrieren Sie die virtuelle IP-Ressourcenadresse und den gewünschten Namen des virtuellen Servers in DNS, wenn Sie anstelle einer IP-Adresse eine Verbindungszeichenfolge verwenden möchten, die auf einen Zeichenfolgenservernamen verweist. Registrieren Sie für Notfallwiederherstellungskonfigurationen den gewünschten Namen des virtuellen Servers und die IP-Adresse bei den DNS-Servern am primären Standort und dem Standort für die Notfallwiederherstellung.
Hinzufügen einer Kollokationseinschränkung
Fast jede Entscheidung in einem Pacemaker-Cluster, wie etwa die Auswahl des Orts, an dem eine Ressource ausgeführt werden soll, erfolgt durch Vergleichen von Bewertungen. Die Bewertungen werden pro Ressource berechnet. Der Clusterressourcen-Manager wählt den Knoten mit der höchsten Bewertung für eine bestimmte Ressource aus. Wenn ein Knoten eine negative Bewertung für eine Ressource aufweist, kann die Ressource auf diesem Knoten nicht ausgeführt werden.
Auf einem Pacemaker-Cluster können Sie die Entscheidungen des Clusters mit Einschränkungen beeinflussen. Einschränkungen weisen eine Bewertung auf. Wenn eine Einschränkung eine Bewertung unter INFINITY
aufweist, wird diese von Pacemaker lediglich als Empfehlung angesehen. Eine Bewertung von INFINITY
ist obligatorisch.
Definieren Sie eine Kollokationseinschränkung mit der Bewertung INFINITY, um sicherzustellen, dass das primäre Replikat und die virtuellen IP-Ressourcen auf demselben Host ausgeführt werden. Führen Sie den folgenden Befehl auf einem Knoten aus, um eine Kollokationseinschränkung hinzuzufügen.
RHEL 7
Beim Erstellen der ag_cluster
-Ressource in RHEL 7 wird die Ressource als ag_cluster-master
erstellt. Verwenden Sie den folgenden Befehl für RHEL 7:
sudo pcs constraint colocation add virtualip ag_cluster-master INFINITY with-rsc-role=Master
RHEL 8
Beim Erstellen der ag_cluster
-Ressource in RHEL 8 wird die Ressource als ag_cluster-clone
erstellt. Verwenden Sie den folgenden Befehl für RHEL 8:
sudo pcs constraint colocation add virtualip with master ag_cluster-clone INFINITY with-rsc-role=Master
Hinzufügen einer Sortierungseinschränkung
Die Kollokationseinschränkung weist eine implizite Sortierungseinschränkung auf. Damit wird die virtuelle IP-Adressressource verschoben, bevor diese die Verfügbarkeitsgruppenressource verschiebt. Die Ereignisse laufen standardmäßig wie folgt ab:
Der Benutzer gibt den Befehl pcs resource move
aus, um die primäre Verfügbarkeitsgruppe von node1 zu node2 zu verschieben.
Die virtuelle IP-Ressource wird auf Knoten 1 angehalten.
Die virtuelle IP-Ressource wird auf Knoten 2 gestartet.
Hinweis
Zu diesem Zeitpunkt verweist die IP-Adresse vorübergehend auf Knoten 2, während Knoten 2 noch ein sekundäres Replikat vor dem Failover darstellt.
Die primäre Verfügbarkeitsgruppe auf Knoten 1 wird auf sekundär herabgestuft.
Die sekundäre Verfügbarkeitsgruppe auf Knoten 2 wird auf primär heraufgestuft.
Fügen Sie eine Sortierungseinschränkung hinzu, um zu vermeiden, dass die IP-Adresse vorübergehend auf den Knoten mit dem sekundären Replikat vor dem Failover verweist.
Führen Sie den folgenden Befehl auf einem Knoten aus, um eine Sortierungseinschränkung hinzuzufügen:
RHEL 7
sudo pcs constraint order promote ag_cluster-master then start virtualip
RHEL 8
sudo pcs constraint order promote ag_cluster-clone then start virtualip
Wichtig
Nachdem Sie den Cluster konfiguriert und die Verfügbarkeitsgruppe als Clusterressource hinzugefügt haben, können Sie ein Failover der Verfügbarkeitsgruppenressourcen nicht mehr mit Transact-SQL durchführen. SQL Server-Clusterressourcen unter Linux sind nicht so eng mit dem Betriebssystem gekoppelt wie in einem Windows Server-Failovercluster (WSFC). Der SQL Server-Dienst kann das Vorhandensein des Clusters nicht erkennen. Die gesamte Orchestrierung erfolgt über die Clusterverwaltungstools. Verwenden Sie in RHEL oder unter Ubuntu pcs
-Tools und in SLES crm
-Tools.
Führen Sie für die Verfügbarkeitsgruppe ein Failover mit pcs
aus. Initiieren Sie kein Failover mit Transact-SQL. Anweisungen finden Sie unter Failover.
Zugehöriger Inhalt
Die Clusteringebene basiert auf der SUSE High Availability Extension (HAE), die auf Pacemaker aufbaut.
Weitere Informationen zu Clusterkonfiguration, Ressourcen-Agent-Optionen, Verwaltung, Best Practices und Empfehlungen finden Sie unter SUSE Linux Enterprise High Availability Extension.
Roadmap
Beim Erstellen einer Verfügbarkeitsgruppe zur Gewährleistung von Hochverfügbarkeit müssen Sie bei Linux-Servern anders vorgehen als bei einem Windows Server-Failovercluster. Die allgemeinen Schritte werden in der folgenden Liste beschrieben:
Konfigurieren Sie SQL Server in den Clusterknoten.
Erstellen Sie die Verfügbarkeitsgruppe.
Konfigurieren Sie einen Cluster Resource Manager wie Pacemaker. Diese Anweisungen finden Sie in diesem Artikel.
Die Art und Weise des Konfigurierens eines Clusterressourcen-Managers hängt von der jeweiligen Linux-Distribution ab.
Wichtig
In Produktionsumgebungen wird zur Gewährleistung von Hochverfügbarkeit ein Fencing-Agent benötigt. In den Beispielen in diesem Artikel werden keine Fencing-Agents verwendet. Sie werden lediglich für Tests und Überprüfungen verwendet.
Ein Linux-Cluster verwendet Fencing, um den Cluster in einen bekannten Zustand zurückzusetzen. Wie das Fencing konfiguriert wird, hängt von der Verteilung und der Umgebung ab. Derzeit ist Fencing in einigen Cloudumgebungen nicht verfügbar. Weitere Informationen finden Sie unter SUSE Linux Enterprise High Availability Extension.
Fügen Sie die Verfügbarkeitsgruppe als Ressource im Cluster hinzu.
Voraussetzungen
Für das folgende End-to-End-Szenario benötigen Sie drei Computer, um den Cluster mit drei Knoten bereitzustellen. In den folgenden Schritten wird beschrieben, wie Sie diese Server konfigurieren.
Der erste Schritt besteht darin, das Betriebssystem auf den Clusterknoten zu konfigurieren. Verwenden Sie für diese exemplarische Vorgehensweise SLES 12 SP3 mit einem gültigen Abonnement für das Hochverfügbarkeits-Add-On.
Installieren Sie den SQL Server-Dienst auf allen Knoten, und richten Sie ihn ein. Ausführliche Anweisungen finden Sie unter Leitfaden für die Installation von SQL Server unter Linux.
Legen Sie einen Knoten als primäres Replikat und andere Knoten als sekundäre Replikate fest. Verwenden Sie diese Begriffe in der gesamten Anleitung.
Stellen Sie sicher, dass Knoten, die Teil des Clusters sein werden, miteinander kommunizieren können.
Das folgende Beispiel zeigt /etc/hosts
mit Ergänzungen für drei Knoten mit den Namen SLES1, SLES2 und SLES3.
127.0.0.1 localhost
10.128.16.33 SLES1
10.128.16.77 SLES2
10.128.16.22 SLES3
Alle Clusterknoten müssen in der Lage sein, über SSH aufeinander zuzugreifen. Tools wie hb_report
oder crm_report
(zur Problembehandlung) und Hawk's History Explorer erfordern kennwortlosen SSH-Zugriff zwischen den Knoten, andernfalls können sie nur Daten vom aktuellen Knoten sammeln. Falls Sie keinen nicht-standardmäßigen SSH-Port verwenden, nutzen Sie die Option „-X“ (siehe Seite man
). Wenn Ihr SSH-Port z. B. 3479 ist, rufen Sie crm_report
mit Folgendem auf:
sudo crm_report -X "-p 3479" [...]
Weitere Informationen finden Sie im SLES Administration Guide (SLES-Administratorhandbuch) im Abschnitt „Miscellaneous“ (Sonstiges).
Erstellen einer SQL Server-Anmeldung für Pacemaker
Erstellen Sie in allen SQL Server-Instanzen eine Server-Anmeldung für Pacemaker.
Die folgende Transact-SQL erstellt eine Anmeldung:
USE [master]
GO
CREATE LOGIN [pacemakerLogin] with PASSWORD= N'ComplexP@$$w0rd!';
ALTER SERVER ROLE [sysadmin] ADD MEMBER [pacemakerLogin];
Für die Erstellung der Verfügbarkeitsgruppe benötigt der Pacemaker-Benutzer die Berechtigungen ALTER
, CONTROL
und VIEW DEFINITION
für die Verfügbarkeitsgruppe, nachdem diese erstellt wurde, aber bevor ihr irgendwelche Knoten hinzugefügt werden.
Speichern Sie in allen SQL Server-Instanzen die Anmeldeinformationen für die SQL Server-Anmeldung.
echo 'pacemakerLogin' >> ~/pacemaker-passwd
echo 'ComplexP@$$w0rd!' >> ~/pacemaker-passwd
sudo mv ~/pacemaker-passwd /var/opt/mssql/secrets/passwd
sudo chown root:root /var/opt/mssql/secrets/passwd
sudo chmod 400 /var/opt/mssql/secrets/passwd # Only readable by root
Konfigurieren auf Linux-Servern zunächst die Verfügbarkeitsgruppe und anschließend die Clusterressourcen. Informationen zum Konfigurieren der Verfügbarkeitsgruppe finden Sie unter Konfigurieren von SQL Server-Always On-Verfügbarkeitsgruppen für Hochverfügbarkeit unter Linux
Installieren der High Availability Extension
Informationen hierzu finden Sie unter Installing SUSE Linux Enterprise Server and High Availability Extension (Installieren von SUSE Linux Enterprise Server und High Availability Extension)
Installieren Sie das SQL Server-Ressourcen-Agent-Paket auf beiden Knoten.
sudo zypper install mssql-server-ha
Einrichten des ersten Knotens
Informationen hierzu finden Sie unter SLES installation instructions (SLES-Installationsanweisungen).
Melden Sie sich bei dem physischen oder virtuellen Computer, den Sie als Clusterknoten verwenden möchten, als root
an.
Starten Sie das Bootstrapskript, indem Sie folgenden Befehl ausführen:
sudo ha-cluster-init
Wenn NTP nicht so konfiguriert wurde, das es zur Startzeit startet, wird eine Meldung angezeigt.
Wenn Sie den Vorgang dennoch fortsetzen möchten, werden vom Skript automatisch Schlüssel für den SSH-Zugriff und das Synchronisierungstool Csync2 erstellt, und die dafür erforderlichen Dienste werden gestartet.
So konfigurieren Sie die Clusterkommunikationsebene (Corosync):
Geben Sie eine Netzwerkadresse für die Bindung ein. Standardmäßig schlägt das Skript die Netzwerkadresse von eth0 vor. Geben Sie alternativ eine andere Netzwerkadresse ein, z. B. die Adresse von bond0.
Geben Sie eine Multicastadresse ein. Das Skript schlägt eine zufällige Adresse vor, die Sie als Standard verwenden können.
Geben Sie einen Multicastport ein. Das Skript schlägt 5405 als Standardwert vor.
Geben Sie zum Konfigurieren von SBD ()
einen permanenten Pfad zur Partition Ihres Blockgeräts ein, das Sie für die SBD verwenden möchten. Der Pfad muss auf allen Knoten im Cluster einheitlich sein.
Schließlich startet das Skript den Dienst Pacemaker, um den Cluster mit einem Knoten online zu schalten und die Webverwaltungsschnittstelle Hawk2 zu aktivieren. Die URL, die für Hawk2 verwendet werden soll, wird auf dem Bildschirm angezeigt.
Weitere Informationen zum Einrichtungsvorgang finden Sie unter /var/log/sleha-bootstrap.log
. Der Cluster mit einem Knoten wird nun ausgeführt. Überprüfen Sie den Status des Clusters mit „crm status“.
sudo crm status
Die Clusterkonfiguration können Sie auch mit crm configure show xml
oder crm configure show
anzeigen.
Mit der Bootstrapprozedur wird ein Linux-Benutzer mit dem Namen „hacluster“ und dem Kennwort „linux“ erstellt. Ersetzen Sie das Standardkennwort so bald wie möglich durch ein sicheres Kennwort:
sudo passwd hacluster
Hinzufügen von Knoten zum vorhandenen Cluster
Wenn Sie über einen Cluster verfügen, der mit einem oder mehreren Knoten ausgeführt wird, fügen Sie mit dem Bootstrapskript „ha-cluster-join“ weitere Clusterknoten hinzu. Das Skript benötigt lediglich Zugriff auf einen vorhandenen Clusterknoten und nimmt die grundlegende Einrichtung auf dem aktuellen Computer automatisch vor. Führen Sie die folgenden Schritte durch:
Wenn Sie die vorhandenen Clusterknoten mit dem Clustermodul YaST
konfiguriert haben, stellen Sie sicher, dass die folgenden Voraussetzungen erfüllt sind, bevor Sie ha-cluster-join
ausführen:
- Der Root-Benutzer auf den vorhandenen Knoten verfügt über SSH-Schlüssel für die Anmeldung ohne Kennwort.
Csync2
ist auf den vorhandenen Knoten konfiguriert. Weitere Informationen hierzu finden Sie unter Konfigurieren von Csync2 mit YaST.
Melden Sie sich bei dem physischen oder virtuellen Computer, der dem Cluster beitreten soll, als root
-Benutzer an.
Starten Sie das Bootstrapskript, indem Sie folgenden Befehl ausführen:
sudo ha-cluster-join
Wenn NTP nicht so konfiguriert wurde, das es zur Startzeit startet, wird eine Meldung angezeigt.
Wenn Sie den Vorgang dennoch fortsetzen möchten, werden Sie aufgefordert, die IP-Adresse eines vorhandenen Knotens einzugeben. Geben Sie die IP-Adresse ein.
Wenn Sie nicht bereits einen SSH-Zugriff ohne Kennwort zwischen den beiden Computern konfiguriert haben, werden Sie zudem aufgefordert, das Stammkennwort des vorhandenen Knotens einzugeben.
Nach der Anmeldung beim angegebenen Knoten kopiert das Skript die Corosync-Konfiguration, konfiguriert SSH und Csync2
und schaltet den aktuellen Computer als neuen Clusterknoten online. Zudem startet es den für Hawk benötigten Dienst. Wenn Sie den freigegebenen Speicher mit OCFS2
konfiguriert haben, wird automatisch das Bereitstellungspunktverzeichnis für das Dateisystem OCFS2
erstellt.
Wiederholen Sie die vorherigen Schritte für alle Computer, die Sie dem Cluster hinzufügen möchten.
Weitere Informationen zu diesem Vorgang finden Sie unter /var/log/ha-cluster-bootstrap.log
.
Überprüfen Sie den Status des Clusters mit sudo crm status
. Wenn Sie einen zweiten Knoten erfolgreich hinzugefügt haben, sieht die Ausgabe ähnlich der folgenden aus:
sudo crm status
Ihnen wird daraufhin eine Ausgabe angezeigt, die in etwa wie im folgenden Beispiel aussieht:
3 nodes configured
1 resource configured
Online: [ SLES1 SLES2 SLES3]
Full list of resources:
admin_addr (ocf::heartbeat:IPaddr2): Started node1
Hinweis
admin_addr
ist die virtuelle IP-Clusterressource, die während der anfänglichen Einrichtung des Clusters mit einem Knoten konfiguriert wird.
Nachdem Sie alle Knoten hinzugefügt haben, überprüfen Sie, ob Sie die Option „no-quorum-policy“ in den globalen Clusteroptionen anpassen müssen. Dies ist besonders wichtig für Cluster mit zwei Knoten.
Festlegen der Clustereigenschaft „cluster-recheck-interval“
cluster-recheck-interval
gibt das Abrufintervall an, mit dem der Cluster prüft, ob Änderungen in den Ressourcenparametern, Einschränkungen oder anderen Clusteroptionen vorliegen. Wenn ein Replikat ausfällt, versucht der Cluster, das Replikat in einem Intervall neu zu starten, das durch den Wert failure-timeout
und den Wert cluster-recheck-interval
gebunden ist. Wenn failure-timeout
beispielsweise auf 60 Sekunden und cluster-recheck-interval
auf 120 Sekunden festgelegt ist, wird der Neustart in einem Intervall versucht, das größer als 60 Sekunden, aber kleiner als 120 Sekunden ist. Es wird empfohlen, „failure-timeout“ auf 60 Sekunden und cluster-recheck-interval
auf einen Wert größer als 60 Sekunden festzulegen. cluster-recheck-interval
auf einen kleinen Wert festzulegen, wird nicht empfohlen.
So aktualisieren Sie den Eigenschaftswert auf ein Ausführungsintervall von 2 minutes
:
crm configure property cluster-recheck-interval=2min
Wenn Sie bereits über eine Verfügbarkeitsgruppenressource verfügen, die von einem Pacemaker-Cluster verwaltet wird, hat das Pacemaker-Paket 1.1.18-11.el7 einen Behavior Change für die Clustereinstellung start-failure-is-fatal
für den Fall eingeführt, dass ihr Wert false
ist. Diese Änderung wirkt sich auf den Failoverworkflow aus. Wenn ein primäres Replikat ausfällt, wird für den Cluster ein Failover auf eines der verfügbaren sekundären Replikate erwartet. Stattdessen werden die Benutzer bemerken, dass der Cluster weiterhin versucht, das ausgefallene primäre Replikat zu starten. Wenn dieses primäre Replikat (aufgrund eines dauerhaften Ausfalls) nicht online geschaltet wird, führt der Cluster kein Failover zu einem anderen verfügbaren sekundären Replikat durch. Aufgrund dieser Änderung ist eine zuvor empfohlene Konfiguration zum Festlegen von start-failure-is-fatal
nicht mehr gültig, und für die Einstellung muss der Standardwert true
wiederhergestellt werden.
Darüber hinaus muss die Verfügbarkeitsgruppenressource aktualisiert werden, um die Eigenschaft failure-timeout
einzubeziehen.
So aktualisieren Sie den Eigenschaftswert auf ein Ausführungsintervall von true
:
crm configure property start-failure-is-fatal=true
Aktualisieren Sie die Eigenschaft failure-timeout
Ihrer vorhandenen Verfügbarkeitsgruppenressource auf ein Ausführungsintervall von 60s
(ersetzen Sie hierzu ag1
durch den Namen Ihrer Verfügbarkeitsgruppenressource):
crm configure edit ag1
Fügen Sie im Text-Editor meta failure-timeout=60s
nach allen param
n und vor allen op
s hinzu.
Weitere Informationen zu Pacemaker-Clustereigenschaften finden Sie unter Configuring Cluster Resources (Konfigurieren von Clusterressourcen).
Überlegungen zu mehreren Netzwerkschnittstellen (NICs)
Folgen Sie den folgenden Vorschlägen, wenn Sie hohe Verfügbarkeit auf Servern mit mehreren NICs einrichten:
Stellen Sie sicher, dass die hosts
Datei so eingerichtet ist, dass die Server-IP-Adressen für die verschiedenen NICs auf dem Hostnamen des Linux-Servers auf jedem Knoten aufgelöst werden.
Wenn Sie den Cluster mithilfe von Pacemaker einrichten, sollte zur Verwendung des Hostnamens des Servers Corosync konfiguriert werden, um die Konfiguration für alle NICs festzulegen. Wir wollen nur die Pacemaker/Corosync-Kommunikation über eine einzelne NIC. Nachdem der Pacemaker-Cluster konfiguriert wurde, ändern Sie die Konfiguration in der Datei corosync.conf
, und aktualisieren Sie die IP-Adresse für die dedizierte NIC, die Sie für die Pacemaker/Corosync-Kommunikation verwenden möchten.
Der <hostname>
in der Datei corosync.conf
sollte mit der Ausgabe identisch sein, die beim umgekehrten Nachschlagen (ping -a <ip_address>
) erfolgt. Außerdem sollte es der auf dem Host konfigurierte kurze Name sein. Stellen Sie sicher, dass die Date hosts
auch die richtige IP-Adresse für die Namensauflösung darstellt.
Die Änderungen am corosync.conf
-Dateibeispiel sind nachfolgend markiert:
nodelist {
node {
ring0_addr: <ip_address_of_node1_NIC1>
name: <hostname_of_node1>
nodeid: 1
}
node {
ring0_addr: <ip_address_of_node2_NIC1>
name: <hostname_of_node2>
nodeid: 2
}
node {
ring0_addr: <ip_address_of_node3_NIC1>
name: <hostname_of_node3>
nodeid: 3
}
}
Bei Anbietern von Pacemaker-Clustern muss ein ausgefallener Knoten mit einem Fencinggerät, das für eine unterstützte Clustereinrichtung konfiguriert ist, gesichert werden. Wenn der Clusterressourcen-Manager den Status eines Knotens oder einer Ressource auf einem Knoten nicht ermitteln kann, wird der Cluster mithilfe von Fencing wieder in einen bekannten Status versetzt.
Durch das Fencing auf Ressourcenebene wird vor allem sichergestellt, dass während eines Ausfalls durch die Konfiguration einer Ressource keine Daten beschädigt werden. Das Fencing auf Ressourcenebene können Sie beispielsweise mit DRBD (Distributed Replicated Block Device) verwenden, damit die Festplatte auf einem Knoten bei einem Ausfall der Kommunikationsverbindung als veraltet markiert wird.
Mit dem Fencing auf Knotenebene wird sichergestellt, dass ein Knoten keine Ressourcen ausführt. Dies erfolgt durch Zurücksetzen des Knotens. Die Pacemaker-Implementierung wird als STONITH bezeichnet. Pacemaker unterstützt eine Vielzahl von Fencinggeräten, z. B. eine unterbrechungsfreie Stromversorgung oder Verwaltungsschnittstellenkarten für Server.
Weitere Informationen finden Sie unter
Zum Zeitpunkt der Clusterinitialisierung ist Fencing deaktiviert, wenn keine Konfiguration erkannt wird. STONITH kann später durch Ausführen des folgenden Befehls aktiviert werden:
sudo crm configure property stonith-enabled=true
Wichtig
Das Fencing wird lediglich zu Testzwecken deaktiviert. Wenn Sie Pacemaker in einer Produktionsumgebung verwenden möchten, sollten Sie je nach Ihrer Umgebung eine Fencingimplementierung planen und immer aktivieren. SUSE bietet keine Fencing-Agents für Cloudumgebungen (wie Azure) oder Hyper-V. Folglich bietet der Clusteranbieter keine Unterstützung für die Ausführung von Produktionsclustern in diesen Umgebungen. Wir arbeiten an einer in zukünftigen Versionen verfügbaren Lösung zum Schließen dieser Lücke.
Informationen finden Sie im SLES-Administratorhandbuch.
Aktivieren von Pacemaker
Aktivieren Sie Pacemaker so, dass die Software automatisch gestartet wird.
Führen Sie den folgenden Befehl auf allen Knoten im Cluster aus.
systemctl enable pacemaker
Erstellen von Verfügbarkeitsgruppenressourcen
Mit dem folgenden Befehl wird die Verfügbarkeitsgruppenressource für drei Replikate der Verfügbarkeitsgruppe [ag1] erstellt und konfiguriert. Aufgrund der Tatsache, dass Zeitlimits stark von der Arbeitsauslastung abhängen und für jede Bereitstellung sorgfältig angepasst werden müssen, müssen die Überwachungsvorgänge und -zeitlimits in SLES explizit angegeben werden.
Führen Sie den Befehl auf einem Knoten im Cluster aus:
Führen crm configure
Sie aus, um die CRM-Eingabeaufforderung zu öffnen:
sudo crm configure
Führen Sie in der CRM-Eingabeaufforderung den folgenden Befehl aus, um die Ressourceneigenschaften zu konfigurieren.
primitive ag_cluster \
ocf:mssql:ag \
params ag_name="ag1" \
meta failure-timeout=60s \
op start timeout=60s \
op stop timeout=60s \
op promote timeout=60s \
op demote timeout=10s \
op monitor timeout=60s interval=10s \
op monitor timeout=60s interval=11s role="Master" \
op monitor timeout=60s interval=12s role="Slave" \
op notify timeout=60s
ms ms-ag_cluster ag_cluster \
meta master-max="1" master-node-max="1" clone-max="3" \
clone-node-max="1" notify="true" \
commit
Erstellen einer virtuellen IP-Ressource
Wenn Sie beim Ausführen von ha-cluster-init
die virtuelle IP-Ressource nicht erstellt haben, können Sie diese Ressource jetzt erstellen. Mit dem folgenden Befehl wird eine virtuelle IP-Ressource erstellt. Ersetzen Sie <**0.0.0.0**>
durch eine verfügbare Adresse aus Ihrem Netzwerk und <**24**>
durch die Anzahl der Bits in der CIDR-Subnetzmaske. Führen Sie den Befehl auf einem Knoten aus.
crm configure \
primitive admin_addr \
ocf:heartbeat:IPaddr2 \
params ip=<**0.0.0.0**> \
cidr_netmask=<**24**>
Hinzufügen einer Kollokationseinschränkung
Fast jede Entscheidung in einem Pacemaker-Cluster, wie etwa die Auswahl des Orts, an dem eine Ressource ausgeführt werden soll, erfolgt durch Vergleichen von Bewertungen. Dabei werden Bewertungen pro Ressource berechnet, und der Cluster Resource Manager wählt den Knoten mit der höchsten Bewertung für eine bestimmte Ressource aus. (Wenn ein Knoten eine negative Bewertung für eine Ressource aufweist, kann die Ressource auf diesem Knoten nicht ausgeführt werden.) Wir können die Entscheidungen des Clusters mit Einschränkungen beeinflussen. Einschränkungen weisen eine Bewertung auf. Wenn eine Einschränkung eine Bewertung unter INFINITY aufweist, ist dies lediglich eine Empfehlung. Die Bewertung INFINITY steht für eine obligatorische Einschränkung. Wir möchten sicherstellen, dass das primäre Replikat der Verfügbarkeitsgruppe und die virtuelle IP-Ressource auf demselben Host ausgeführt werden. Daher definieren wir eine Kollokationseinschränkung mit der Bewertung INFINITY.
Führen Sie den folgenden Befehl auf einem Knoten aus, um die Kollokationseinschränkung für die virtuelle IP-Adresse festzulegen, sodass diese auf demselben Knoten wie der primäre Knoten ausgeführt wird:
crm configure
colocation vip_on_master inf: \
admin_addr ms-ag_cluster:Master
commit
Hinzufügen einer Sortierungseinschränkung
Die Kollokationseinschränkung weist eine implizite Sortierungseinschränkung auf. Damit wird die virtuelle IP-Adressressource verschoben, bevor diese die Verfügbarkeitsgruppenressource verschiebt. Die Ereignisse laufen standardmäßig wie folgt ab:
- Der Benutzer gibt den Befehl
resource migrate
aus, um die primäre Verfügbarkeitsgruppe von node1 zu node2 zu verschieben.
- Die virtuelle IP-Ressource wird auf Knoten 1 angehalten.
- Die virtuelle IP-Ressource wird auf Knoten 2 gestartet. Zu diesem Zeitpunkt verweist die IP-Adresse vorübergehend auf Knoten 2, während Knoten 2 noch ein sekundäres Replikat vor dem Failover darstellt.
- Der Verfügbarkeitsgruppen-Master auf Knoten 1 wird herabgestuft.
- Die Verfügbarkeitsgruppe auf Knoten 2 wird zum Master heraufgestuft.
Fügen Sie eine Sortierungseinschränkung hinzu, um zu vermeiden, dass die IP-Adresse vorübergehend auf den Knoten mit dem sekundären Replikat vor dem Failover verweist.
Führen Sie den folgenden Befehl auf einem Knoten aus, um eine Sortierungseinschränkung hinzuzufügen:
sudo crm configure \
order ag_first inf: ms-ag_cluster:promote admin_addr:start
Wichtig
Nachdem Sie den Cluster konfiguriert und die Verfügbarkeitsgruppe als Clusterressource hinzugefügt haben, können Sie ein Failover der Verfügbarkeitsgruppenressourcen nicht mehr mit Transact-SQL durchführen. SQL Server-Clusterressourcen unter Linux sind nicht so eng mit dem Betriebssystem gekoppelt wie in einem Windows Server-Failovercluster (WSFC). Der SQL Server-Dienst kann das Vorhandensein des Clusters nicht erkennen. Die gesamte Orchestrierung erfolgt über die Clusterverwaltungstools. Verwenden Sie in SLES crm
.
Führen Sie für die Verfügbarkeitsgruppe ein Failover mit crm
aus. Initiieren Sie kein Failover mit Transact-SQL. Weitere Informationen finden Sie unter Failover.
Weitere Informationen finden Sie unter:
Zugehöriger Inhalt
Roadmap
Die Schritte zum Erstellen einer Verfügbarkeitsgruppe auf Linux-Servern für Hochverfügbarkeit unterscheiden sich von den Schritten in Windows Server-Failoverclustern. Die allgemeinen Schritte werden in der folgenden Liste beschrieben:
Leitfaden für die Installation von SQL Server für Linux.
Konfigurieren von SQL Server-Always On-Verfügbarkeitsgruppen für Hochverfügbarkeit unter Linux
Konfigurieren Sie einen Cluster Resource Manager wie Pacemaker. Diese Anweisungen finden Sie in diesem Artikel.
Die Art und Weise des Konfigurierens eines Clusterressourcen-Managers hängt von der jeweiligen Linux-Distribution ab.
Wichtig
In Produktionsumgebungen wird zur Gewährleistung von Hochverfügbarkeit ein Fencing-Agent benötigt. In den Beispielen in diesem Artikel werden keine Fencing-Agents verwendet. Sie werden lediglich für Tests und Überprüfungen verwendet.
Ein Linux-Cluster verwendet Fencing, um den Cluster in einen bekannten Zustand zurückzusetzen. Wie das Fencing konfiguriert wird, hängt von der Verteilung und der Umgebung ab. Derzeit ist Fencing in einigen Cloudumgebungen nicht verfügbar.
Das Fencing wird in der Regel im Betriebssystem implementiert und ist von der Umgebung abhängig. Anweisungen für das Fencing finden Sie in der Verteilerdokumentation des Betriebssystems.
Fügen Sie die Verfügbarkeitsgruppe als Ressource im Cluster hinzu.
Öffnen Sie auf allen Knoten die Firewallports. Öffnen Sie den Port für den Pacemaker-Dienst für hohe Verfügbarkeit, die SQL Server-Instanz und den Endpunkt der Verfügbarkeitsgruppe. Der Standard-TCP-Port für den Server, auf dem SQL Server ausgeführt wird, ist 1433
.
sudo ufw allow 2224/tcp
sudo ufw allow 3121/tcp
sudo ufw allow 21064/tcp
sudo ufw allow 5405/udp
sudo ufw allow 1433/tcp # Replace with TDS endpoint
sudo ufw allow 5022/tcp # Replace with DATA_MIRRORING endpoint
sudo ufw reload
Alternativ können Sie die Firewall deaktivieren, aber dies wird in einer Produktionsumgebung nicht empfohlen:
sudo ufw disable
Installieren Sie Pacemaker-Pakete. Führen Sie die folgenden Befehle für Ubuntu 20.04 auf allen Knoten aus. Weitere Informationen zum Installieren unter früheren Versionen finden Sie unter Ubuntu HA – MS SQL Server in Azure.
sudo apt-get install -y pacemaker pacemaker-cli-utils crmsh resource-agents fence-agents corosync python3-azure
Legen Sie das Kennwort für den Standardbenutzer fest, der beim Installieren von Pacemaker und Corosync-Paketen erstellt wird. Verwenden Sie auf allen Knoten dasselbe Kennwort.
sudo passwd hacluster
Erstellen Sie den Cluster.
Bevor Sie einen Cluster erstellen, müssen Sie einen Authentifizierungsschlüssel für den primären Server erstellen und ihn auf die anderen an der Verfügbarkeitsgruppe beteiligten Server kopieren.
Verwenden Sie das folgende Skript, um einen Authentifizierungsschlüssel für den primären Server zu erstellen:
sudo corosync-keygen
Sie können scp
verwenden, um den generierten Schlüssel auf andere Server zu kopieren:
sudo scp /etc/corosync/authkey dbadmin@server-02:/etc/corosync
sudo scp /etc/corosync/authkey dbadmin@server-03:/etc/corosync
Zum Erstellen des Clusters bearbeiten Sie die Datei /etc/corosync/corosync.conf
auf dem primären Server:
sudo vim /etc/corosync/corosync.conf
Die Datei corosync.conf
sollte dem folgenden Beispiel ähneln:
totem {
version: 2
cluster_name: agclustername
transport: udpu
crypto_cipher: none
crypto_hash: none
}
logging {
fileline: off
to_stderr: yes
to_logfile: yes
logfile: /var/log/corosync/corosync.log
to_syslog: yes
debug: off
logger_subsys {
subsys: QUORUM
debug: off
}
}
quorum {
provider: corosync_votequorum
}
nodelist {
node {
name: server-01
nodeid: 1
ring0_addr: 10.0.0.4
}
node {
name: server-02
nodeid: 2
ring0_addr: 10.0.0.5
}
node {
name: server-03
nodeid: 3
ring0_addr: 10.0.0.6
}
}
Ersetzen Sie die Datei corosync.conf
auf anderen Knoten:
sudo scp /etc/corosync/corosync.conf dbadmin@server-02:/etc/corosync
sudo scp /etc/corosync/corosync.conf dbadmin@server-03:/etc/corosync
Starten Sie die Dienste pacemaker
und corosync
neu:
sudo systemctl restart pacemaker corosync
Bestätigen Sie den Status des Clusters, und überprüfen Sie die Konfiguration:
sudo crm status
Überlegungen zu mehreren Netzwerkschnittstellen (NICs)
Folgen Sie den folgenden Vorschlägen, wenn Sie hohe Verfügbarkeit auf Servern mit mehreren NICs einrichten:
Stellen Sie sicher, dass die hosts
Datei so eingerichtet ist, dass die Server-IP-Adressen für die verschiedenen NICs auf dem Hostnamen des Linux-Servers auf jedem Knoten aufgelöst werden.
Wenn Sie den Cluster mithilfe von Pacemaker einrichten, sollte zur Verwendung des Hostnamens des Servers Corosync konfiguriert werden, um die Konfiguration für alle NICs festzulegen. Wir wollen nur die Pacemaker/Corosync-Kommunikation über eine einzelne NIC. Nachdem der Pacemaker-Cluster konfiguriert wurde, ändern Sie die Konfiguration in der Datei corosync.conf
, und aktualisieren Sie die IP-Adresse für die dedizierte NIC, die Sie für die Pacemaker/Corosync-Kommunikation verwenden möchten.
Der <hostname>
in der Datei corosync.conf
sollte mit der Ausgabe identisch sein, die beim umgekehrten Nachschlagen (ping -a <ip_address>
) erfolgt. Außerdem sollte es der auf dem Host konfigurierte kurze Name sein. Stellen Sie sicher, dass die Date hosts
auch die richtige IP-Adresse für die Namensauflösung darstellt.
Die Änderungen am corosync.conf
-Dateibeispiel sind nachfolgend markiert:
nodelist {
node {
ring0_addr: <ip_address_of_node1_NIC1>
name: <hostname_of_node1>
nodeid: 1
}
node {
ring0_addr: <ip_address_of_node2_NIC1>
name: <hostname_of_node2>
nodeid: 2
}
node {
ring0_addr: <ip_address_of_node3_NIC1>
name: <hostname_of_node3>
nodeid: 3
}
}
Bei Anbietern von Pacemaker-Clustern muss ein ausgefallener Knoten mit einem Fencinggerät, das für eine unterstützte Clustereinrichtung konfiguriert ist, gesichert werden. Wenn der Clusterressourcen-Manager den Status eines Knotens oder einer Ressource auf einem Knoten nicht ermitteln kann, wird der Cluster mithilfe von Fencing wieder in einen bekannten Status versetzt.
Durch das Fencing auf Ressourcenebene wird sichergestellt, dass ein Ausfall keine Datenbeschädigung verursacht. Das Fencing auf Ressourcenebene können Sie beispielsweise mit DRBD (Distributed Replicated Block Device) verwenden, damit die Festplatte auf einem Knoten bei einem Ausfall der Kommunikationsverbindung als veraltet markiert wird.
Mit dem Fencing auf Knotenebene wird sichergestellt, dass ein Knoten keine Ressourcen ausführt. Dies erfolgt durch Zurücksetzen des Knotens. Die Pacemaker-Implementierung wird als STONITH bezeichnet. Pacemaker unterstützt eine Vielzahl von Fencinggeräten, z. B. eine unterbrechungsfreie Stromversorgung oder Verwaltungsschnittstellenkarten für Server.
Weitere Informationen finden Sie unter Pacemaker Clusters from Scratch (Pacemaker-Cluster völlig neu erstellen) und Fencing and Stonith (Fencing und STONITH).
Da die Umgrenzungskonfiguration auf Knotenebene stark von Ihrer Umgebung abhängt, wird sie für dieses Tutorial deaktiviert (sie kann zu einem späteren Zeitpunkt konfiguriert werden). Führen Sie das folgende Befehlsskript auf dem primären Knoten aus:
sudo crm configure property stonith-enabled=false
In diesem Beispiel wird das Fencing lediglich zu Testzwecken deaktiviert. Wenn Sie Pacemaker in einer Produktionsumgebung verwenden möchten, sollten Sie je nach Ihrer Umgebung eine Fencingimplementierung planen und immer aktivieren. Informationen zu Fencing-Agents für eine bestimmte Verteilung erhalten Sie beim Hersteller des Betriebssystems.
Festlegen der Clustereigenschaft „cluster-recheck-interval“
Die Eigenschaft cluster-recheck-interval
gibt das Abrufintervall an, in dem der Cluster prüft, ob Änderungen in den Ressourcenparametern, Einschränkungen oder anderen Clusteroptionen vorliegen. Wenn ein Replikat ausfällt, versucht der Cluster, das Replikat in einem Intervall neu zu starten, das durch den Wert failure-timeout
und den Wert cluster-recheck-interval
gebunden ist. Wenn failure-timeout
beispielsweise auf 60 Sekunden und cluster-recheck-interval
auf 120 Sekunden festgelegt ist, wird der Neustart in einem Intervall versucht, das größer als 60 Sekunden, aber kleiner als 120 Sekunden ist. Sie sollten failure-timeout
auf 60 Sekunden und cluster-recheck-interval
auf einen Wert über 60 Sekunden festlegen. cluster-recheck-interval
auf einen kleineren Wert festzulegen, wird nicht empfohlen.
So aktualisieren Sie den Eigenschaftswert auf ein Ausführungsintervall von 2 minutes
:
sudo crm configure property cluster-recheck-interval=2min
Wenn Sie bereits über eine Verfügbarkeitsgruppenressource verfügen, die von einem Pacemaker-Cluster verwaltet wird, hat das Pacemaker-Paket 1.1.18-11.el7 einen Behavior Change für die Clustereinstellung start-failure-is-fatal
für den Fall eingeführt, dass ihr Wert false
ist. Diese Änderung wirkt sich auf den Failoverworkflow aus. Wenn ein primäres Replikat ausfällt, wird für den Cluster ein Failover auf eines der verfügbaren sekundären Replikate erwartet. Stattdessen werden die Benutzer bemerken, dass der Cluster weiterhin versucht, das ausgefallene primäre Replikat zu starten. Wenn dieses primäre Replikat (aufgrund eines dauerhaften Ausfalls) nicht online geschaltet wird, führt der Cluster kein Failover zu einem anderen verfügbaren sekundären Replikat durch. Aufgrund dieser Änderung ist eine zuvor empfohlene Konfiguration zum Festlegen von start-failure-is-fatal
nicht mehr gültig, und für die Einstellung muss der Standardwert true
wiederhergestellt werden.
Darüber hinaus muss die Verfügbarkeitsgruppenressource aktualisiert werden, um die Eigenschaft failure-timeout
einzubeziehen.
So aktualisieren Sie den Eigenschaftswert auf ein Ausführungsintervall von true
:
sudo crm configure property start-failure-is-fatal=true
Aktualisieren Sie die Eigenschaft failure-timeout
Ihrer vorhandenen Verfügbarkeitsgruppenressource auf ein Ausführungsintervall von 60s
(ersetzen Sie hierzu ag1
durch den Namen Ihrer Verfügbarkeitsgruppenressource):
sudo crm configure meta failure-timeout=60s
Installieren des SQL Server-Ressourcen-Agent für die Integration in Pacemaker
Führen Sie die folgenden Befehle auf allen Knoten aus.
sudo apt-get install mssql-server-ha
Erstellen einer SQL Server-Anmeldung für Pacemaker
Erstellen Sie in allen SQL Server-Instanzen eine Server-Anmeldung für Pacemaker.
Die folgende Transact-SQL erstellt eine Anmeldung:
USE [master]
GO
CREATE LOGIN [pacemakerLogin] with PASSWORD= N'ComplexP@$$w0rd!';
ALTER SERVER ROLE [sysadmin] ADD MEMBER [pacemakerLogin];
Für die Erstellung der Verfügbarkeitsgruppe benötigt der Pacemaker-Benutzer die Berechtigungen ALTER
, CONTROL
und VIEW DEFINITION
für die Verfügbarkeitsgruppe, nachdem diese erstellt wurde, aber bevor ihr irgendwelche Knoten hinzugefügt werden.
Speichern Sie in allen SQL Server-Instanzen die Anmeldeinformationen für die SQL Server-Anmeldung.
echo 'pacemakerLogin' >> ~/pacemaker-passwd
echo 'ComplexP@$$w0rd!' >> ~/pacemaker-passwd
sudo mv ~/pacemaker-passwd /var/opt/mssql/secrets/passwd
sudo chown root:root /var/opt/mssql/secrets/passwd
sudo chmod 400 /var/opt/mssql/secrets/passwd # Only readable by root
Erstellen von Verfügbarkeitsgruppenressourcen
Erstellen Sie die Ressource der Verfügbarkeitsgruppe mit dem Befehl sudo crm configure
, um die Eigenschaften der Ressource festzulegen. Im folgenden Beispiel wird eine ocf:mssql:ag
-Ressource des Typs primär/Replikat für eine Verfügbarkeitsgruppe mit dem Namen ag1
erstellt.
~$ sudo crm
configure
primitive ag1_cluster \
ocf:mssql:ag \
params ag_name="ag1" \
meta failure-timeout=60s \
op start timeout=60s \
op stop timeout=60s \
op promote timeout=60s \
op demote timeout=10s \
op monitor timeout=60s interval=10s \
op monitor timeout=60s on-fail=demote interval=11s role="Master" \
op monitor timeout=60s interval=12s role="Slave" \
op notify timeout=60s
ms ms-ag1 ag1_cluster \
meta master-max="1" master-node-max="1" clone-max="3" \
clone-node-max="1" notify="true"
commit
Erstellen einer virtuellen IP-Ressource
Führen Sie den folgenden Befehl auf einem Knoten aus, um die virtuelle IP-Adressressource zu erstellen. Verwenden Sie eine verfügbare statische IP-Adresse aus dem Netzwerk. Bevor Sie das Skript ausführen, ersetzen Sie die Werte zwischen < ... >
durch eine gültige IP-Adresse.
sudo crm configure primitive virtualip \
ocf:heartbeat:IPaddr2 \
params ip=10.128.16.240
In Pacemaker ist der Name eines virtuellen Servers nicht gleichwertig. Wenn Sie eine Verbindungszeichenfolge verwenden möchten, die auf einen Zeichenfolgen-Servernamen verweist, und nicht die IP-Adresse verwenden, registrieren Sie die IP-Ressourcenadresse und den gewünschten Namen des virtuellen Servers in DNS. Registrieren Sie für Notfallwiederherstellungskonfigurationen den gewünschten Namen des virtuellen Servers und die IP-Adresse bei den DNS-Servern am primären Standort und dem Standort für die Notfallwiederherstellung.
Hinzufügen einer Kollokationseinschränkung
Fast jede Entscheidung in einem Pacemaker-Cluster, wie etwa die Auswahl des Orts, an dem eine Ressource ausgeführt werden soll, erfolgt durch Vergleichen von Bewertungen. Dabei werden Bewertungen pro Ressource berechnet, und der Cluster Resource Manager wählt den Knoten mit der höchsten Bewertung für eine bestimmte Ressource aus. (Wenn ein Knoten eine negative Bewertung für eine Ressource aufweist, kann die Ressource auf diesem Knoten nicht ausgeführt werden.)
Verwenden Sie Einschränkungen, um die Entscheidungen des Clusters zu konfigurieren. Einschränkungen weisen eine Bewertung auf. Wenn eine Einschränkung eine Bewertung unter INFINITY aufweist, ist dies lediglich eine Empfehlung. Die Bewertung INFINITY steht für eine obligatorische Einschränkung.
Um sicherzustellen, dass das primäre Replikat und die virtuelle IP-Ressource sich auf demselben Host befinden, definieren Sie eine Kollokationseinschränkung mit der Bewertung INFINITY. Führen Sie den folgenden Befehl auf einem Knoten aus, um eine Kollokationseinschränkung hinzuzufügen.
sudo crm configure colocation ag-with-listener INFINITY: virtualip-group ms-ag1:Master
Hinzufügen einer Sortierungseinschränkung
Die Kollokationseinschränkung weist eine implizite Sortierungseinschränkung auf. Damit wird die virtuelle IP-Adressressource verschoben, bevor diese die Verfügbarkeitsgruppenressource verschiebt. Die Ereignisse laufen standardmäßig wie folgt ab:
Der Benutzer gibt den Befehl pcs resource move
aus, um die primäre Verfügbarkeitsgruppe von node1
zu node2
zu verschieben.
Die virtuelle IP-Ressource wird auf node1
angehalten.
Die virtuelle IP-Ressource wird auf node2
gestartet.
Zu diesem Zeitpunkt verweist die IP-Adresse vorübergehend auf node2
, während node2
noch ein sekundäres Replikat vor dem Failover darstellt.
Die primäre Verfügbarkeitsgruppe auf node1
wird auf sekundär herabgestuft.
Die sekundäre Verfügbarkeitsgruppe auf node2
wird auf primär heraufgestuft.
Fügen Sie eine Sortierungseinschränkung hinzu, um zu vermeiden, dass die IP-Adresse vorübergehend auf den Knoten mit dem sekundären Replikat vor dem Failover verweist.
Führen Sie den folgenden Befehl auf einem Knoten aus, um eine Sortierungseinschränkung hinzuzufügen:
sudo crm configure order ag-before-listener Mandatory: ms-ag1:promote virtualip-group:start
Nachdem Sie den Cluster konfiguriert und die Verfügbarkeitsgruppe als Clusterressource hinzugefügt haben, können Sie ein Failover der Verfügbarkeitsgruppenressourcen nicht mehr mit Transact-SQL durchführen. SQL Server-Clusterressourcen unter Linux sind nicht so eng mit dem Betriebssystem gekoppelt wie in einem Windows Server-Failovercluster (WSFC). Der SQL Server-Dienst kann das Vorhandensein des Clusters nicht erkennen. Die gesamte Orchestrierung erfolgt über die Clusterverwaltungstools.
Zugehöriger Inhalt