SQL Server-Cluster unter Linux mit Always On-Verfügbarkeitsgruppen und Pacemaker einrichten

In dieser Anleitung wird beschrieben, wie Sie ein Microsoft SQL Server-Datenbanksystem unter Linux mit einer Always On-Verfügbarkeitsgruppe (AOAG) und Pacemaker als Hochverfügbarkeitslösung und DR-Lösung bereitstellen können. Im Rahmen dieses Dokuments ist ein Notfall ein Ereignis, bei dem eine primäre Datenbank ausfällt bzw. unzulänglich wird.

Eine primäre Datenbank kann ausfallen, wenn die Region, in der sie sich befindet, ausfällt bzw. unzugänglich wird. Selbst wenn eine Region verfügbar ist und ordnungsgemäß funktioniert, kann eine primäre Datenbank aufgrund eines Systemfehlers ausfallen. In diesen Fällen besteht die Notfallwiederherstellung darin, Clients zur weiteren Verarbeitung eine sekundäre Datenbank zur Verfügung zu stellen.

Diese Anleitung richtet sich an Datenbankarchitekten, Administratoren und Entwickler.

Lernziele

Kosten

In dieser Anleitung werden kostenpflichtige Komponenten von Google Cloud verwendet, darunter:

Sie können mithilfe des Preisrechners eine Kostenschätzung für Ihre voraussichtliche Nutzung erstellen.

Hinweise

Für diese Anleitung benötigen Sie ein Google Cloud-Projekt. Sie können ein neues Projekt erstellen oder ein vorhandenes Projekt auswählen:

  1. In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

    Go to project selector

  2. Die Abrechnung für das Google Cloud-Projekt muss aktiviert sein.

  3. Achten Sie darauf, dass die NetApp Cloud Volumes API für Ihr Google Cloud-Projekt aktiviert ist.

  4. Aktivieren Sie Cloud Shell in der Google Cloud Console.

    Cloud Shell aktivieren

Projekt und Netzwerk vorbereiten

So bereiten Sie Ihr Google Cloud-Projekt und Ihre VPC für die Bereitstellung von SQL Server AlwaysOn-Verfügbarkeitsgruppen vor:

  1. Öffnen Sie Cloud Shell in der Google Cloud Console. Klicken Sie hierzu auf die Schaltfläche Cloud Shell aktivieren Aktivieren Sie Cloud Shell..

    Weiter zur Google Cloud Console

  2. Legen Sie Ihre standardmäßige Projekt-ID fest:

    gcloud config set project PROJECT_ID

    Ersetzen Sie PROJECT_ID durch die ID Ihres Google Cloud-Projekts.

  3. Legen Sie Ihre Standardregion fest:

    gcloud config set compute/region REGION

    Ersetzen Sie REGION durch die ID der Region, in der die Bereitstellung erfolgen soll.

  4. Legen Sie Ihre Standardzone fest:

    gcloud config set compute/zone ZONE

    Ersetzen Sie ZONE durch die ID der Zone, in der die Bereitstellung erfolgen soll. Es sollte eine gültige Zone in der im vorherigen Schritt angegebenen Region sein.

Linux-VMs erstellen

Um Hochverfügbarkeit und Quorum für den SQL Server-Cluster zu erreichen, stellen Sie drei virtuelle Linux-Maschinen (VMs) bereit, auf denen der SQL Server-Cluster gehostet wird.

  1. Initialisieren Sie die folgenden Variablen:

    PD_SIZE=30
MACHINE_TYPE=n2-standard-8

  2. Erstellen Sie die Linux-VMs:

    gcloud compute instances create node-1 \
--project=PROJECT_ID \
--zone REGION-a \
--machine-type $MACHINE_TYPE \
--subnet SUBNET_NAME \
--create-disk=auto-delete=yes,boot=yes,device-name=node-1,image=projects/ubuntu-os-cloud/global/images/ubuntu-2004-focal-v20240426,mode=rw,size=$PD_SIZE,type=projects/PROJECT_ID/zones/ZONE/diskTypes/pd-balanced \
--scopes=https://www.googleapis.com/auth/compute,https://www.googleapis.com/auth/servicecontrol,https://www.googleapis.com/auth/service.management.readonly,https://www.googleapis.com/auth/logging.write,https://www.googleapis.com/auth/monitoring.write,https://www.googleapis.com/auth/trace.append,https://www.googleapis.com/auth/devstorage.read_write

gcloud compute instances create node-2 \
--project=PROJECT_ID \
--zone REGION-b \
--machine-type $MACHINE_TYPE \
--subnet SUBNET_NAME \
--create-disk=auto-delete=yes,boot=yes,device-name=node-2,image=projects/ubuntu-os-cloud/global/images/ubuntu-2004-focal-v20240426,mode=rw,size=$PD_SIZE,type=projects/PROJECT_ID/zones/ZONE/diskTypes/pd-balanced \
--scopes=https://www.googleapis.com/auth/compute,https://www.googleapis.com/auth/servicecontrol,https://www.googleapis.com/auth/service.management.readonly,https://www.googleapis.com/auth/logging.write,https://www.googleapis.com/auth/monitoring.write,https://www.googleapis.com/auth/trace.append,https://www.googleapis.com/auth/devstorage.read_write

gcloud compute instances create node-3 \
--project=PROJECT_ID \
--zone REGION-c \
--machine-type $MACHINE_TYPE \
--subnet SUBNET_NAME \
--create-disk=auto-delete=yes,boot=yes,device-name=node-3,image=projects/ubuntu-os-cloud/global/images/ubuntu-2004-focal-v20240426,mode=rw,size=$PD_SIZE,type=projects/PROJECT_ID/zones/ZONE/diskTypes/pd-balanced \
--scopes=https://www.googleapis.com/auth/compute,https://www.googleapis.com/auth/servicecontrol,https://www.googleapis.com/auth/service.management.readonly,https://www.googleapis.com/auth/logging.write,https://www.googleapis.com/auth/monitoring.write,https://www.googleapis.com/auth/trace.append,https://www.googleapis.com/auth/devstorage.read_write

    Ersetzen Sie das Subnetz SUBNET_NAME durch den Namen Ihres VPC-Subnetzes.

  3. Aktualisieren Sie die Datei „hosts“ auf node-1, node-2 und node-3:

    1. Stellen Sie eine SSH-Verbindung zu den einzelnen VMs her. Weitere Informationen finden Sie in der Dokumentation zu „Mit Linux-VMs verbinden“.

    2. Öffnen Sie die Hostdatei zur Bearbeitung.

      sudo vi /etc/hosts

    3. Suchen Sie die interne IP-Adresse für jede Linux-VM und hängen Sie die Hosteinträge an das Ende der Datei an.

      Zu Compute Engine 

      NODE1_INTERNAL_IP node-1
NODE2_INTERNAL_IP node-2
NODE3_INTERNAL_IP node-3

      Ersetzen Sie NODE1_INTERNAL_IP, NODE2_INTERNAL_IP und NODE3_INTERNAL_IP durch die interne IP-Adresse jeder Linux-VM.

  4. Prüfen Sie die Kommunikation zwischen Ihren VMs. Alle VMs, die zur Always On-Verfügbarkeitsgruppe gehören, müssen mit anderen VMs kommunizieren können:

    1. Kehren Sie zu jeder Linux-VM zurück, führen Sie die Befehle von jeder VM aus und prüfen Sie, ob alle VMs miteinander kommunizieren können.

      ping -c 4 node-1
ping -c 4 node-2
ping -c 4 node-3

SQL Server installieren und konfigurieren

Laden Sie die SQL Server-Engine auf die drei Linux-VMs herunter, die Teil der Always On-Verfügbarkeitsgruppe sind, und installieren und konfigurieren Sie sie.

  1. Stellen Sie eine SSH-Verbindung zu node-1, node-2 und node-3 her und führen Sie die folgenden Schritte aus:

    1. Importieren Sie die öffentlichen Repository-Schlüssel.

      wget -qO- https://packages.microsoft.com/keys/microsoft.asc \
| sudo tee /etc/apt/trusted.gpg.d/microsoft.asc

    2. Registrieren Sie das SQL Server-Ubuntu-Repository.

      sudo add-apt-repository \
"$(wget -qO- https://packages.microsoft.com/config/ubuntu/20.04/mssql-server-2019.list)"

    3. Aktualisieren Sie die Paketindexdateien und installieren Sie SQL Server.

      sudo apt-get update
sudo apt-get install -y mssql-server

  2. Konfigurieren Sie SQL Server:

    1. Führen Sie das Tool mssql-conf aus.

      sudo /opt/mssql/bin/mssql-conf setup

    2. Wählen Sie die Entwicklerversion für die SQL Server-Version aus und akzeptieren Sie die Lizenzvereinbarung.

      Die Developer-Edition enthält alle Unternehmensfunktionen. Sie können sie jedoch nur für Nicht-Produktionsumgebungen verwenden. Weitere Informationen zu SQL Server-Versionen und Microsoft-Lizenzen finden Sie hier.

    3. Geben Sie ein Passwort für das SA-Konto an.

    4. Prüfen Sie, ob der mssql-server-Dienst ausgeführt wird:

      systemctl status mssql-server --no-pager

  3. Wenn Sie auf Ihren VMs eine Firewall aktiviert haben, öffnen Sie die Firewall für SQL Server:

    1. Prüfen Sie mit dem folgenden Befehl, ob Uncomplicated Firewall installiert und aktiviert ist.

      sudo ufw status

    2. Wenn der Status aktiv ist, führen Sie die folgenden Befehle aus, um die Ports zu öffnen.

      sudo ufw allow 1433
sudo ufw allow 5022
sudo ufw reload

Mit SQL Server verbinden

Jetzt ist SQL Server installiert. Erstellen Sie zum Herstellen einer Verbindung eine Windows-Maschine in derselben VPC und installieren Sie SQL Server Management Studio (SSMS), um eine Verbindung zu Ihrer neu erstellten SQL Server-Instanz auf Ihren VMs herzustellen:

  1. Erstellen Sie eine Windows-VM:

    1. Kehren Sie zu Cloud Shell zurück und führen Sie den folgenden Befehl aus.

      gcloud compute instances create node4 \
--project=PROJECT_ID \
--zone ZONE \
--subnet SUBNET_NAME \
--machine-type=n2-standard-4 \
--create-disk=auto-delete=yes,boot=yes,device-name=node4,image=projects/windows-cloud/global/images/windows-server-2022-dc-v20240415,mode=rw,size=50,type=projects/p3rf-sqlserver/zones/ZONE/diskTypes/pd-balanced

  2. Stellen Sie über Remote Desktop eine Verbindung zur Windows-VM auf node-4 her:

  3. Aktualisieren Sie die Hostdatei auf node-4:

    1. Öffnen Sie den Notizblock im Administratormodus.

    2. Klicken Sie auf File > Open (Datei > Öffnen) und öffnen Sie die Hostdatei.

      c:\Windows\System32\drivers\etc\hosts

    3. Hängen Sie die Hosteinträge an das Ende der Datei an.

      NODE1_INTERNAL_IP node-1
NODE2_INTERNAL_IP node-2
NODE3_INTERNAL_IP node-3

      Ersetzen Sie NODE1_INTERNAL_IP, NODE2_INTERNAL_IP und NODE3_INTERNAL_IP durch die entsprechende interne IP-Adresse jeder VM.

    4. Speichern Sie den Code und schließen Sie den Editor.

  4. Prüfen Sie die Verbindung zu den Linux-VMs:

    1. Stellen Sie eine Verbindung zur Windows-VM auf node-4 her
    2. Klicken Sie auf Start und geben Sie "powershell" in die Suchleiste ein.
    3. Klicken Sie, um die Windows PowerShell ISE-App zu öffnen.

    4. Testet die Verbindung durch Ausführen der folgenden Befehle.

      ping node-1
ping node-2
ping node-3

  5. Installieren Sie Microsoft SQL Server Management Studio (SSMS) mithilfe der folgenden Schritte:

    1. Stellen Sie über Remote Desktop eine Verbindung zur Windows-VM auf node-4 her.

    2. Minimieren Sie in Ihrer RDP-Sitzung alle Fenster und starten Sie die Windows PowerShell ISE-Anwendung.

    3. Laden Sie in der PowerShell-Eingabeaufforderung das SSMS-Installationsprogramm herunter und führen Sie es aus:

      Start-BitsTransfer `
-Source "https://aka.ms/ssmsfullsetup" `
-Destination "$env:Temp\ssms-setup.exe"
& $env:Temp\ssms-setup.exe

    4. Klicken Sie im SSMS-Installationsprogramm auf Installieren.

    5. Akzeptieren Sie die Aufforderung, Änderungen zuzulassen.

    6. Klicken Sie nach Abschluss der Installation auf Neu starten, um den Remotecomputer neu zu starten. Dadurch wird die RDP-Sitzung beendet.

  6. Stellen Sie eine Verbindung zur SQL Server-Instanz auf node-1 her:

    1. Kehren Sie mit RDP zur VM node-4 zurück.

    2. Öffnen Sie SSMS und stellen Sie mit den folgenden Parametern eine Verbindung zu node-1 her.

      Server name: node-1
Authentication: SQL Server Authentication
Login: sa

      Weitere Informationen finden Sie in der Dokumentation zu SQL Server Management Studio unter Verbindung zu einer SQL Server-Instanz herstellen.

    3. Geben Sie das Passwort für das SA-Konto ein, das während der Installation erstellt wurde.

    4. Wählen Sie Serverzertifikat vertrauen aus.

    5. Klicken Sie auf Verbinden.

Always On-Verfügbarkeitsgruppe aktivieren

Unter Linux müssen Sie zuerst eine Verfügbarkeitsgruppe erstellen, bevor Sie sie als Ressource hinzufügen können, die von Pacemaker verwaltet werden soll:

  1. Aktivieren Sie die Funktion „Always On-Verfügbarkeitsgruppe“ für jede SQL Server-Instanz, die zur Verfügbarkeitsgruppe gehört. Führen Sie für node-1, node-2 und node-3 die folgenden Befehle aus:

    sudo /opt/mssql/bin/mssql-conf set hadr.hadrenabled 1
sudo systemctl restart mssql-server

  2. Stellen Sie über SSMS eine Verbindung zu der Instanz her, die der primäre Host in der Verfügbarkeitsgruppe ist:

    1. Öffnen Sie ein neues Abfragefenster.

    2. Führen Sie das folgende Code-Snippet aus, um einen Verschlüsselungsschlüssel, ein Zertifikat und einen privaten Schlüssel zu erstellen.

      USE MASTER;

CREATE MASTER KEY ENCRYPTION BY PASSWORD = 'ENCRYPTION_KEY_PASSWORD';
CREATE CERTIFICATE my_ag_certificate WITH SUBJECT = 'my_ag_cert';
BACKUP CERTIFICATE my_ag_certificate
TO FILE = '/var/opt/mssql/data/my_ag_certificate.cer'
WITH PRIVATE KEY (
    FILE = '/var/opt/mssql/data/my_ag_certificate.pvk',
    ENCRYPTION BY PASSWORD = 'PRIVATE_KEY_PASSWORD'
);

      Ersetzen Sie ENCRYPTION_KEY_PASSWORD und PRIVATE_KEY_PASSWORD durch die Passwörter für den Verschlüsselungsschlüssel und den privaten Schlüssel.

Zertifikat und Schlüsseldateien übertragen

Die in den vorherigen Schritten erstellten Zertifikat- und Schlüsseldateien müssen auf die sekundären Knoten von SQL Server verschoben werden. Es gibt mehrere Methoden, um das Zertifikat und die Schlüsseldateien auf die sekundären Knoten von node-2 und node-3 zu verschieben.

Weitere Übertragungsoptionen finden Sie unter Dateien an Linux-VMs übertragen.

Zertifikat- und Schlüsseldateien mit Cloud Storage übertragen

Erstellen Sie einen Cloud Storage, um Dateien vom primären zu den sekundären Clusterknoten zu übertragen.

  1. Erstellen Sie einen Cloud Storage-Bucket:

    1. Kehren Sie zu Cloud Shell zurück und führen Sie den folgenden Befehl aus:

      gcloud storage buckets create gs://BUCKET_NAME \
--project=PROJECT_ID \
--location=REGION \
--public-access-prevention

      Ersetzen Sie dabei BUCKET_NAME durch den Namen des zu erstellenden Buckets. Ersetzen Sie PROJECT_ID durch die ID Ihres Google Cloud-Projekts und REGION durch die ID der Region, in der der Bucket bereitgestellt werden soll.

    Weitere Informationen finden Sie unter Buckets erstellen.

  2. Kehren Sie für node-1, node-2 und node-3 zum SSh zurück, um die Google Cloud CLI zu initialisieren:

    1. Führen Sie den folgenden Befehl aus, um die Google Cloud CLI zu initialisieren:

      gcloud init

    2. Wählen Sie option [1] aus, um das vorinstallierte Dienstkonto zu verwenden.

    3. Geben Sie den Namen Ihres Projekts ein.

    4. Geben Sie n in die Frage ein, um die Standardregion und -zone einzurichten.

  3. Kehren Sie zu node-1 zurück, um die Dateien in Cloud Storage zu kopieren:

    1. Laden Sie die beiden neu erstellten Dateien in Cloud Storage hoch. Deaktivieren Sie dazu die folgenden Befehle.

      sudo gsutil cp /var/opt/mssql/data/my_ag_certificate.cer gs://BUCKET_NAME/
sudo gsutil cp /var/opt/mssql/data/my_ag_certificate.pvk gs://BUCKET_NAME/

      Ersetzen Sie dabei BUCKET_NAME durch den Namen des erstellten Buckets.

  4. Kehren Sie zu node-2 und node-3 zurück, um die Dateien aus Cloud Storage zu kopieren:

    1. Laden Sie die beiden Dateien aus Cloud Storage in node-2 herunter.

      sudo gsutil cp gs://BUCKET_NAME/my_ag_certificate.cer /var/opt/mssql/data/
sudo gsutil cp gs://BUCKET_NAME/my_ag_certificate.pvk /var/opt/mssql/data/

      Ersetzen Sie dabei BUCKET_NAME durch den Namen des erstellten Buckets.

    2. Ändern Sie die Eigentümerschaft der Dateien auf node-2 und node-3, indem Sie den Befehl in einer Root-Shell ausführen.

      chown mssql:mssql /var/opt/mssql/data/my_ag_certificate.*
chmod 660 /var/opt/mssql/data/my_ag_certificate.*

Endpunkt für die Datenbankspiegelung einrichten

In diesem Abschnitt erstellen Sie den Datenbankendpunkt mithilfe eines Verschlüsselungsschlüssels und eines Zertifikats, die von jedem Knoten im SQL Server-Cluster gemeinsam genutzt werden, um eine sichere Datenreplikation zu gewährleisten.

  1. Kehren Sie zur Windows-VM auf node-4 zurück, um die Endpunkte für die Datenbankspiegelung zu erstellen:

    1. Stellen Sie über SSMS eine Verbindung zu den SQL Server-Datenbanken auf node-1, node-2 und node-3 her. Führen Sie die Schritte unter Verbindung zu SQL Server herstellen aus. Verwenden Sie dabei node-1, node-2 und node-3 als Servernamen und die entsprechenden Passwörter, die Sie für das SA-Konto festgelegt haben.

    2. Erstellen Sie das Zertifikat aus den kopierten Dateien auf den sekundären VMs node-2 und node-3. Verwenden Sie die Passwörter, die Sie beim Erstellen des Zertifikats und des Schlüssels auf dem primären Knoten angegeben haben.

      USE MASTER;

CREATE MASTER KEY ENCRYPTION BY PASSWORD = 'ENCRYPTION_KEY_PASSWORD';
CREATE CERTIFICATE my_ag_certificate
FROM FILE = '/var/opt/mssql/data/my_ag_certificate.cer'
WITH PRIVATE KEY (
    FILE = '/var/opt/mssql/data/my_ag_certificate.pvk',
    DECRYPTION BY PASSWORD = 'PRIVATE_KEY_PASSWORD'
);

      Ersetzen Sie ENCRYPTION_KEY_PASSWORD und PRIVATE_KEY_PASSWORD durch die Passwörter für den Verschlüsselungsschlüssel und den privaten Schlüssel.

    3. Kehren Sie zu SSMS zurück, um Endpunkte für die Datenbankspiegelung zu erstellen. Führen Sie dazu den T-SQL-Befehl für node-1, node-2 und node-3 aus.

      CREATE ENDPOINT [my_ag_endpoint]
    AS TCP (LISTENER_PORT = 5022)
    FOR DATABASE_MIRRORING (
        ROLE = ALL,
        AUTHENTICATION = CERTIFICATE my_ag_certificate,
        ENCRYPTION = REQUIRED ALGORITHM AES
    );

ALTER ENDPOINT [my_ag_endpoint] STATE = STARTED;

Always On-Verfügbarkeitsgruppe erstellen und konfigurieren

Erstellen Sie als Nächstes die immer aktive SQL Server-Verfügbarkeitsgruppe mithilfe von SQL Server Management Studio und verwenden Sie die zuvor erstellten Endpunkte für die Replikation.

  1. Kehren Sie zur Windows-VM zurück und öffnen Sie SSMS:

    1. Stellen Sie eine Verbindung zum SQL Server-Datenbankmodul auf node-1 her und öffnen Sie ein neues Abfragefenster.

  2. Erstellen Sie eine Datenbank und sichern Sie sie zur Vorbereitung auf die Replikation:

    USE MASTER;

CREATE DATABASE [bookshelf];
ALTER DATABASE [bookshelf] SET RECOVERY FULL;
BACKUP DATABASE [bookshelf]
TO DISK = N'/var/opt/mssql/data/bookshelf.bak';

  3. Erstellen Sie die Always On-Verfügbarkeitsgruppe:

    1. Führen Sie den folgenden T-SQL-Befehl in SSMS für node-1, node-2 und node-3 aus. Dadurch wird sichergestellt, dass die Endpunkte aktiviert und SQL Server auf jedem Knoten für die Datenreplikation bereit ist.

      IF (SELECT state FROM sys.endpoints WHERE name = N'my_ag_endpoint') <> 0
BEGIN
    ALTER ENDPOINT [my_ag_endpoint] STATE = STARTED
END
GO

IF EXISTS(SELECT * FROM sys.server_event_sessions WHERE name='AlwaysOn_health')
BEGIN
    ALTER EVENT SESSION [AlwaysOn_health] ON SERVER WITH (STARTUP_STATE=ON);
END
IF NOT EXISTS(SELECT * FROM sys.dm_xe_sessions WHERE name='AlwaysOn_health')
BEGIN
    ALTER EVENT SESSION [AlwaysOn_health] ON SERVER STATE=START;
END
GO

    2. Führen Sie den folgenden T-SQL-Befehl in node-1 aus, um die AOAG zu erstellen.

      USE [master]
GO

CREATE AVAILABILITY GROUP [aoag1]
WITH (
    AUTOMATED_BACKUP_PREFERENCE = SECONDARY,
    DB_FAILOVER = OFF,
    DTC_SUPPORT = NONE,
    CLUSTER_TYPE = EXTERNAL,
    REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT = 0
)
FOR DATABASE [bookshelf]
REPLICA ON N'node-1' WITH (
    ENDPOINT_URL = N'TCP://node-1:5022', FAILOVER_MODE = EXTERNAL, AVAILABILITY_MODE = SYNCHRONOUS_COMMIT, BACKUP_PRIORITY = 50, SEEDING_MODE = AUTOMATIC, SECONDARY_ROLE(ALLOW_CONNECTIONS = NO)),
    N'node-2' WITH (ENDPOINT_URL = N'TCP://node-2:5022', FAILOVER_MODE = EXTERNAL, AVAILABILITY_MODE = SYNCHRONOUS_COMMIT, BACKUP_PRIORITY = 50, SEEDING_MODE = AUTOMATIC, SECONDARY_ROLE(ALLOW_CONNECTIONS = NO)),
    N'node-3' WITH (ENDPOINT_URL = N'TCP://node-3:5022', FAILOVER_MODE = EXTERNAL, AVAILABILITY_MODE = SYNCHRONOUS_COMMIT, BACKUP_PRIORITY = 50, SEEDING_MODE = AUTOMATIC, SECONDARY_ROLE(ALLOW_CONNECTIONS = NO)
);
GO

    3. Führen Sie den folgenden T-SQL-Befehl für node-2 und node-3 für jede SQL Server-Instanz aus, um der neuen Verfügbarkeitsgruppe beizutreten.

      ALTER AVAILABILITY GROUP [aoag1] JOIN WITH (CLUSTER_TYPE = EXTERNAL);
GO

ALTER AVAILABILITY GROUP [aoag1] GRANT CREATE ANY DATABASE;
GO

    Sie haben eine neue Datenbank mit dem Namen Bücherregal erstellt und die neue Datenbank einer neuen Verfügbarkeitsgruppe mit dem Namen aoag1 auf der SQL Server-Instanz hinzugefügt, die auf node-1 ausgeführt wird. Node-2 und node-3 wurden zur Verfügbarkeitsgruppe hinzugefügt und die Daten in der bookshelf-Datenbank werden synchron über die SQL Server-Instanzen in allen drei Knoten repliziert.

Pacemaker installieren und konfigurieren

Pacemaker ist eine Open-Source-Software für Hochverfügbarkeitsressourcen, die mit der Cluster-Engine Corosync verwendet wird. In diesem Abschnitt installieren und konfigurieren Sie Pacemaker auf jeder Ihrer VMs.

SQL Server-Anmeldung für den Pacemaker-Clustermanager erstellen

In diesem Abschnitt erstellen Sie ein neues SQL Server-Konto für Pacemaker, mit dem Sie sich bei jeder SQL Server-Instanz anmelden und die Verfügbarkeitsgruppe verwalten können.

  1. Führen Sie den folgenden T-SQL-Befehl für node-1, node-2 und node-3 aus:

    USE [master];

CREATE LOGIN [pacemaker] with PASSWORD= N'PACEMAKER_LOGIN_PASSWORD';
GO

    Ersetzen Sie PACEMAKER_LOGIN_PASSWORD durch ein Passwort für das Pacemaker-Konto.

  2. Führen Sie den T-SQL-Befehl aus, um der Verfügbarkeitsgruppe Anmeldeberechtigungen für den Pacemaker zu gewähren:

    GRANT ALTER, CONTROL, VIEW DEFINITION ON AVAILABILITY GROUP::[aoag1] TO [pacemaker];
GRANT VIEW SERVER STATE TO [pacemaker];
GO

  3. Kehren Sie zu SSH auf node-1, node-2 und node-3 zurück, um die Befehle zum Speichern der Pacemaker-Anmeldung und des Passworts im Ordner "SQL Server-Secrets" auszuführen:

    echo 'pacemaker' >> ~/pacemaker-passwd
echo 'PACEMAKER_LOGIN_PASSWORD' >> ~/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

    Ersetzen Sie PACEMAKER_LOGIN_PASSWORD durch das Passwort für das Pacemaker-Konto.

Pacemaker installieren

Installieren Sie als Nächstes Pacemaker und richten Sie auf allen Linux-VMs ein Anmeldekonto für die Ressourcenverwaltung ein.

  1. Öffnen Sie Firewallports für Pacemaker:

    1. Prüfen Sie, ob Uncomplicated Firewall installiert und aktiviert ist. Führen Sie dazu den folgenden Befehl für node-1, node-2 und node-3 aus.

      sudo ufw status

    2. Wenn ufw aktiviert ist, öffnen Sie die Firewallports auf node-1, node-2 und node-3.

      sudo ufw allow 2224/tcp
sudo ufw allow 3121/tcp
sudo ufw allow 5405/udp
sudo ufw allow 21064/tcp
sudo ufw allow 1433/tcp
sudo ufw allow 5022/tcp
sudo ufw reload

  2. Installieren Sie Pacemaker auf node-1, node-2 und node-3:

    sudo apt-get install -y pacemaker pacemaker-cli-utils crmsh resource-agents  fence-agents corosync python3-azure pcs

  3. Legen Sie ein neues Passwort für den Nutzer hacluster auf node-1, node-2 und node-3 fest:

    sudo passwd hacluster

Corosync einrichten

Als Nächstes konfigurieren Sie Corosync, um die Clustermitgliedschaft und die Nachrichtenfunktion im gesamten Cluster zu verwalten.

  1. Erstellen Sie einen Authentifizierungsschlüssel für Corosync auf node-1:

    sudo corosync-keygen

  2. Ändern Sie die Corosync-Konfigurationsdatei:

    1. Kehren Sie zu node-1 zurück und ändern Sie die Datei corosync.conf.

      sudo vi /etc/corosync/corosync.conf

    2. Aktualisieren Sie die markierten Bereiche. Nach der Bearbeitung sollte die Datei wie im folgenden Beispiel aussehen.

      # Please read the corosync.conf.5 manual page
totem {
    version: 2

    # Corosync itself works without a cluster name, but DLM needs one.
    # The cluster name is also written into the VG metadata of newly
    # created shared LVM volume groups, if lvmlockd uses DLM locking.
    cluster_name: my_agcluster

    # crypto_cipher and crypto_hash: Used for mutual node authentication.
    # If you choose to enable this, then do remember to create a shared
    # secret with "corosync-keygen".
    # enabling crypto_cipher, requires also enabling of crypto_hash.
    # crypto works only with knet transport
    transport: udpu
    crypto_cipher: none
    crypto_hash: none
}

logging {
    # Log the source file and line where messages are being
    # generated. When in doubt, leave off. Potentially useful for
    # debugging.
    fileline: off
    # Log to standard error. When in doubt, set to yes. Useful when
    # running in the foreground (when invoking "corosync -f")
    to_stderr: yes
    # Log to a log file. When set to "no", the "logfile" option
    # must not be set.
    to_logfile: yes
    logfile: /var/log/corosync/corosync.log
    # Log to the system log daemon. When in doubt, set to yes.
    to_syslog: yes
    # Log debug messages (very verbose). When in doubt, leave off.
    debug: off
    # Log messages with time stamps. When in doubt, set to hires (or on)
    #timestamp: hires
    logger_subsys {
        subsys: QUORUM
        debug: off
    }
}
quorum {
    # Enable and configure quorum subsystem (default: off)
    # see also corosync.conf.5 and votequorum.5
    provider: corosync_votequorum
}
nodelist {
    # Change/uncomment/add node sections to match cluster configuration

    node {
        # Hostname of the node
        name: node-1
        # Cluster membership node identifier
        nodeid: 1
        # Address of first link
        ring0_addr: NODE1_INTERNAL_IP
        # When knet transport is used it's possible to define up to 8 links
        #ring1_addr: 192.168.1.1
    }
    node {
        name: node-2
        nodeid: 2
        ring0_addr: NODE2_INTERNAL_IP
    }
    node {
        name: node-3
        nodeid: 3
        ring0_addr: NODE3_INTERNAL_IP
    }
    # ...
}

      Ersetzen Sie NODE1_INTERNAL_IP, NODE2_INTERNAL_IP und NODE3_INTERNAL_IP durch die internen IP-Adressen jedes Knotens.

Konfigurationsdateien mit Cloud Storage übertragen

  1. Laden Sie den generierten Authentifizierungsschlüssel und die Corosync-Konfigurationsdateien aus node-1 in Ihren Cloud Storage-Bucket hoch:

    sudo gsutil cp /etc/corosync/authkey gs://BUCKET_NAME/
sudo gsutil cp  /etc/corosync/corosync.conf gs://BUCKET_NAME/

    Ersetzen Sie BUCKET_NAME durch den Namen des zuvor erstellten Buckets.

  2. Laden Sie die Authkey- und Konfigurationsdateien in node-2 und node-3 herunter:

    sudo gsutil cp gs://BUCKET_NAME/authkey /etc/corosync/
sudo gsutil cp gs://BUCKET_NAME/corosync.conf /etc/corosync/

    Ersetzen Sie BUCKET_NAME durch den Namen des Buckets, in den die Corosync-Konfigurationsdateien übertragen wurden.

  3. Aktualisieren Sie die Berechtigungen der Dateien für node-2 und node-3:

    sudo chmod 400 /etc/corosync/authkey
sudo chmod 400 /etc/corosync/corosync.conf

Clusterkommunikation neu starten und prüfen

  1. Starten Sie die Pacemaker- und Corosync-Dienste auf node-1, node-2 und node-3 neu:

    sudo systemctl restart pacemaker corosync

  2. Bestätigen Sie den Status des Clusters, indem Sie den Befehl auf node-1 ausführen:

    sudo crm status

    Alle drei Knoten sollten online angezeigt werden.

Cluster einrichten

Als Nächstes richten Sie den Pacemaker-Cluster ein, indem Sie eine neue Ressource für die SQL Server-AlwaysOn-Verfügbarkeitsgruppe erstellen.

  1. Führen Sie für node-1 den folgenden Befehl aus, um die Clusterattribute festzulegen:

    sudo crm configure property stonith-enabled=false
sudo crm configure property cluster-recheck-interval=2min
sudo crm configure property start-failure-is-fatal=true

    Weitere Informationen finden Sie unter Clusteroptionen.

  2. Autorisieren Sie die Knoten im Cluster mit dem Befehl auf node-1. Verwenden Sie das zuvor für das Konto hacluster festgelegte Passwort:

    sudo pcs cluster auth -u hacluster

    Sie sollten sehen, dass alle drei Knoten autorisiert sind.

  3. Installieren Sie den SQL Server-Ressourcen-Agent für die Integration in Pacemaker auf node-1, node-2 und node-3:

    sudo apt-get install mssql-server-ha

  4. Kehren Sie zu node-1 zurück und erstellen Sie eine Verfügbarkeitsgruppenressource im Cluster:

    1. Führen Sie den Clusterressourcen-Manager aus.

      sudo crm

    2. Geben Sie configure ein, um das Konfigurationsmenü zu öffnen.

    3. Geben Sie die folgende Konfiguration ein.

      primitive aoag1-cluster \
ocf:mssql:ag \
params ag_name="aoag1" \
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 aoag1-cluster \
meta master-max="1" master-node-max="1" clone-max="3" \
clone-node-max="1" notify="true"

    4. Geben Sie commit ein, um die Änderungen zu übernehmen.

    5. Geben Sie exit ein, um den Clusterressourcenmanager zu beenden.

    6. Prüfen Sie die Konfiguration.

      sudo crm status

      Sie sollten sehen, dass node-1 zum primären Knoten hochgestuft wurde. Node-2 und node-3 sollten als sekundäre Knoten festgelegt werden.

Load-Balancer und Verfügbarkeitsgruppen-Listener einrichten

In diesem Abschnitt erstellen Sie eine virtuelle IP-Adresse und eine Systemdiagnose-Ressource im Cluster mithilfe eines internen Passthrough-TCP-Load-Balancers, der Traffic an die Verfügbarkeitsgruppe weiterleitet.

  1. Kehren Sie zu Cloud Shell zurück und reservieren Sie eine statische IP-Adresse, die Sie als Cluster-IP-Adresse verwenden:

    gcloud compute addresses create aoag1-cluster \
--region REGION \
--subnet SUBNET_NAME
CLUSTER_ADDRESS=$(gcloud compute addresses describe aoag1-cluster \
--region $(gcloud config get-value compute/region) \
--format=value\(address\)) && \
echo "Cluster IP address: $CLUSTER_ADDRESS"

    Ersetzen Sie REGION und SUBNET_NAME durch die Region und das Subnetz, in denen die Linux-VMs bereitgestellt werden.

  2. Erstellen Sie nicht verwaltete Instanzgruppen für jeden Ihrer Clusterknoten und weisen Sie sie der neu erstellten Instanzgruppe zu. Führen Sie die folgenden Befehle in Cloud Shell aus:

    gcloud compute instance-groups unmanaged create node-1-uig \
--zone=REGION-a
gcloud compute instance-groups unmanaged add-instances node-1-uig \
--zone=REGION-a \
--instances=node-1

gcloud compute instance-groups unmanaged create node-2-uig \
--zone=REGION-b
gcloud compute instance-groups unmanaged add-instances node-2-uig \
--zone=REGION-b \
--instances=node-2

gcloud compute instance-groups unmanaged create node-3-uig \
--zone=REGION-c
gcloud compute instance-groups unmanaged add-instances node-3-uig \
--zone=REGION-c \
--instances=node-3

    Ersetzen Sie REGION durch die Region, in der die Linux-VMs bereitgestellt sind.

  3. TCP-Systemdiagnose erstellen Load-Balancer ermitteln mithilfe von Systemdiagnosen, welche Back-End-Instanzen ordnungsgemäß auf den Traffic reagieren.

    gcloud compute health-checks create tcp aoag1-healthcheck \
--port=HEALTH_CHECK_PORT --proxy-header=NONE \
--check-interval=10 --timeout=10 --unhealthy-threshold=2 \
--healthy-threshold=2

    Wählen Sie HEALTH_CHECK_PORT aus und ersetzen Sie ihn durch den Wert eines freien Ports im privaten Bereich 49152–65535 . Beispiel: 60000.

    Weitere Informationen finden Sie in der Übersicht über Systemdiagnosen.

  4. Fügen Sie Ihren Clusterknoten Netzwerk-Tags hinzu. Das Netzwerk-Tag wird von der Firewallregel für die Systemdiagnose verwendet:

    gcloud compute instances add-tags node-1 \
--tags NETWORK_TAG_NAME \
--zone REGION-a
gcloud compute instances add-tags node-2 \
--tags NETWORK_TAG_NAME \
--zone REGION-b
gcloud compute instances add-tags node-3 \
--tags NETWORK_TAG_NAME \
--zone REGION-c

    Ersetzen Sie NETWORK_TAG_NAME durch einen Namen für den Netzwerktag.

  5. Erstellen Sie eine Firewallregel, damit die Systemdiagnosen die Clusterknoten basierend auf dem Tag-Namen erreichen können:

    gcloud compute firewall-rules create mssql-aoag1-fw-rule \
--network VPC_NAME \
--action ALLOW \
--direction INGRESS \
--source-ranges 35.191.0.0/16,130.211.0.0/22 \
--target-tags NETWORK_TAG_NAME \
--rules tcp:HEALTH_CHECK_PORT

    Weitere Informationen finden sich unter Firewallregeln für Systemdiagnosen.

  6. Erstellen Sie den Back-End-Dienst des Load-Balancers:

    gcloud compute backend-services create aoag1-backend \
--load-balancing-scheme internal \
--health-checks aoag1-healthcheck \
--no-connection-drain-on-failover \
--drop-traffic-if-unhealthy \
--failover-ratio 1.0 \
--region REGION \
--global-health-checks

  7. Fügen Sie dem Back-End-Dienst die drei nicht verwalteten Instanzgruppen hinzu:

    gcloud compute backend-services add-backend aoag1-backend \
--instance-group node-1-uig \
--instance-group-zone REGION-a \
--region REGION

gcloud compute backend-services add-backend aoag1-backend \
--instance-group node-2-uig \
--instance-group-zone REGION-b \
--failover \
--region REGION

gcloud compute backend-services add-backend aoag1-backend \
--instance-group node-3-uig \
--instance-group-zone REGION-c \
--failover \
--region REGION

  8. Definieren Sie eine Weiterleitungsregel für den Load-Balancer. Mit einer Weiterleitungsregel werden das Protokoll und die Ports angegeben, über die der Load-Balancer den Traffic annimmt.

    gcloud compute forwarding-rules create aoag1-fwd-rule \
--load-balancing-scheme internal \
--address CLUSTER_ADDRESS \
--subnet SUBNET_NAME \
--region REGION \
--backend-service aoag1-backend \
--ports ALL

    Ersetzen Sie CLUSTER_ADDRESS durch die zuvor reservierte IP-Adresse.

    Weitere Informationen finden Sie unter Weiterleitungsregeln.

  9. Um die Einrichtung abzuschließen und zu testen, ob der Netzwerk-Load-Balancer richtig eingerichtet ist, installieren und konfigurieren Sie HAProxy tcp listener auf node-1, node-2 und node-3:

    1. Installieren Sie den HAProxy. 

      sudo apt-get install haproxy

    2. Wählen Sie Y aus, um die Installation abzuschließen.

    3. Bearbeiten Sie die Datei haproxy.cfg.

      sudo vi /etc/haproxy/haproxy.cfg

    4. Ändern Sie im Defaults-Abschnitt der haproxy.cfg file den Modus in tcp.

    5. Hängen Sie folgenden Abschnitt an das Ende der Datei haproxy.cfg an:

      #---------------------------------------------------------------
# Set up health check listener for SQL Server Availability Group
#---------------------------------------------------------------
listen healthcheck
bind *:HEALTH_CHECK_PORT

      Ersetzen Sie HEALTH_CHECK_PORT durch den zuvor ausgewählten Port der Systemdiagnose. Beispiel: 6000.

    6. Starten Sie den Dienst, um zu prüfen, ob er richtig konfiguriert ist:

      sudo systemctl start haproxy.service
sudo systemctl enable haproxy.service
sudo systemctl restart haproxy.service

    7. Öffnen Sie die Seite "Load-Balancing" und klicken Sie auf Ihren Load-Balancer. Beachten Sie, dass Ihre drei nicht verwalteten Instanzgruppen jetzt als fehlerfrei gemeldet werden sollten.

      Load-Balancing aufrufen

      • Alternativ können Sie den folgenden Befehl in Cloud Shell ausführen, um den Status des Back-End-Dienstes zu sehen.

        gcloud compute backend-services get-health aoag1-backend \
--region REGION

        Ersetzen Sie REGION durch die Region, in der die Linux-VMs bereitgestellt sind.

    8. Wenn alle drei nicht verwalteten Instanzgruppen als fehlerfrei gemeldet werden, fahren Sie mit dem nächsten Schritt fort.

      sudo systemctl restart haproxy.service

  10. Erstellen Sie die Systemdiagnoseressource in Pacemaker:

    1. Stellen Sie eine SSH-Verbindung zu node-1 her und erstellen Sie eine Systemdiagnose-Ressource für den HAProxy-Dienst in Ihrem Schrittmachercluster:

      sudo pcs resource create aoag1-healthcheck \
service:haproxy \
op monitor interval=10s timeout=20s

    2. Prüfen Sie, ob die Systemressource auf dem primären Knoten node-1 gestartet wurde:

      sudo crm status

    3. Wenn die Systemdiagnoseressource nicht auf dem primären Knoten gestartet wurde, verschieben Sie sie mit den folgenden Befehlen:

      sudo pcs resource move aoag1-healthcheck node-1
sudo pcs resource clear aoag1-healthcheck

      Sie sehen, dass die Systemdiagnose für den Load-Balancer nur für node-1 fehlerfrei ist.

      Load-Balancing aufrufen

  11. Erstellen Sie eine virtuelle IP-Adressressource in Ihrem Pacemaker-Cluster:

    1. Kehren Sie auf node-1 zu SSH zurück und suchen Sie den Namen der Netzwerkschnittstelle Ihres Knotens. Sie benötigen sie im nächsten Schritt.

      ip -c link

    2. Erstellen Sie die virtuelle IP-Adressressource.

      sudo pcs resource create aoag1-vip ocf:heartbeat:IPaddr2 \
ip="CLUSTER_ADDRESS" nic=NIC_NAME cidr_netmask=32 \
op monitor interval=3600s timeout=60s

      Ersetzen Sie NIC_NAME durch den Namen der Netzwerkschnittstelle aus dem vorherigen Schritt und CLUSTER_ADDRESS durch die reservierte IP-Adresse.

    3. Prüfen Sie, ob die virtuelle IP-Adressressource auf dem primären Host gestartet wurde.

      sudo crm status

    4. Wenn die virtuelle IP-Adressressource nicht auf dem primären Knoten gestartet wird, verschieben Sie sie mit den folgenden Befehlen.

      sudo pcs resource move aoag1-vip node-1

    5. Gruppieren Sie die Ressourcen für die Systemdiagnose und virtuelle IP-Adressen.

      sudo pcs resource group add aoag1-group \
aoag1-healthcheck aoag1-vip

    6. Erstellen Sie eine Einschränkung, die die neue Gruppe demselben Knoten zuweist wie die primäre Gruppe.

      sudo pcs constraint colocation add master aoag1-group with master ms-ag1 score=INFINITY

Listener für die SQL Server-Verfügbarkeitsgruppe erstellen

Bei Verbindungen zu SQL Server mit Verfügbarkeitsgruppen sollten Sie anstelle des Servernamens den Listener-Namen der Verfügbarkeitsgruppe verwenden. Wenn ein Failover auftritt, leitet der Listener Verbindungen automatisch zum neuen primären Knoten im Cluster um.

  1. Kehren Sie zu SSMS zurück und stellen Sie eine Verbindung zur Datenbank node-1 her.

  2. Führen Sie die folgende Abfrage aus:

    ALTER AVAILABILITY GROUP aoag1
ADD LISTENER 'aoag1-listener' (
    WITH IP (('CLUSTER_ADDRESS','255.255.255.0')), PORT=1433
);
GO

    Ersetzen Sie CLUSTER_ADDRESS durch die reservierte IP-Adresse.

STONITH-Zäune einrichten

STONITH ist eine Fencing-Strategie zur Aufrechterhaltung der Integrität von Knoten in einem HA-Cluster. Der STONITH-Dienst arbeitet auf Knotenebene und schützt den Cluster vor Knoten, die entweder nicht reagieren oder sich in einem unbekannten Zustand befinden. Wir empfehlen das Fencing-Gerät fence_gce, das für Compute Engine in Google Cloud spezialisiert ist.

Fencing-Geräte einrichten

  1. Prüfen Sie, ob der Fence-Agent fence_gce für Compute Engine auf node1 installiert ist:

    sudo pcs stonith list | grep fence_gce

    Weitere Informationen finden Sie unter:

  2. Erstellen Sie auf node-1 die Fencing-Typ-Ressourcen fence_gce für jeden der beteiligten Knoten:

    sudo pcs stonith create node-1-fence fence_gce \
plug=node-1 \
zone=REGION-a \
project=PROJECT_ID \
pcmk_reboot_timeout=300 pcmk_monitor_retries=4 pcmk_delay_max=30 \
op monitor interval="300s" timeout="120s" \
op start interval="0" timeout="60s"

sudo pcs stonith create node-2-fence fence_gce \
plug=node-2 \
zone=REGION-b \
project=PROJECT_ID \
pcmk_reboot_timeout=300 pcmk_monitor_retries=4 pcmk_delay_max=30 \
op monitor interval="300s" timeout="120s" \
op start interval="0" timeout="60s"

sudo pcs stonith create node-3-fence fence_gce \
plug=node-3 \
zone=REGION-c \
project=PROJECT_ID \
pcmk_reboot_timeout=300 pcmk_monitor_retries=4 pcmk_delay_max=30 \
op monitor interval="300s" timeout="120s" \
op start interval="0" timeout="60s"

    Ersetzen Sie REGION durch die Region, in der die Linux-VMs bereitgestellt werden, und PROJECT_ID durch Ihre Projekt-ID.

  3. Sie können den Status der Fencing-Agents testen, indem Sie den Befehl „status“ ausführen:

    sudo fence_gce -o status -n node-1 --zone=REGION-a
sudo fence_gce -o status -n node-2 --zone=REGION-b
sudo fence_gce -o status -n node-3 --zone=REGION-c

  4. Legen Sie Standortbeschränkungen für Ihre Fencing-Geräte fest, damit sie nur auf den gewünschten Instanzen ausgeführt werden:

    sudo pcs constraint location node-1-fence avoids node-1
sudo pcs constraint location node-2-fence avoids node-2
sudo pcs constraint location node-3-fence avoids node-3

  5. Aktivieren Sie das Fencing in Ihrem Pacemaker-Cluster und legen Sie das Zeitlimit für das Cluster-Fencing fest:

    sudo pcs -f stonith_cfg property set stonith-enabled=true
sudo pcs property set stonith-timeout="300s"

  6. Prüfen Sie den Clusterstatus:

    sudo crm status

Fencing-Geräte testen

Nach der Einrichtung der Fencing-Geräte empfehlen wir Ihnen, diese anhand der folgenden Schritte zu testen.

  1. Beenden Sie den Fencing auf node-2:

    1. Stellen Sie eine Verbindung zu node-1 her und führen Sie den folgenden Befehl aus, um das mit node-2 verknüpfte Fence-Gerät aus Ihrem Cluster zu testen.

      fence_gce -o off -n node-2 --zone=REGION-b

    2. Prüfen Sie den Clusterstatus.

      sudo crm status

    3. Außerdem sehen Sie, dass node-2 in Compute Engine deaktiviert ist.

      Zu Compute Engine

  2. Starten Sie den Fence auf node-2 neu:

    1. Kehren Sie zu node-1 zurück und starten Sie die Instanz mit dem folgenden Befehl noch einmal neu.

      fence_gce -o on -n node-2 --zone=REGION-b

    2. Prüfen Sie den Status des Clusters in Pacemaker und Compute Engine. Nach kurzer Zeit siehst du, dass node-2 wieder online ist.

      sudo crm status

Corosync für verzögerten Neustart konfigurieren

Um Zeitprobleme zu vermeiden und für eine ordnungsgemäße Reihenfolge der Vorgänge bei einer Fencing-Aktion zu sorgen, empfehlen wir, den Neustart des Corosync-Dienstes um 60 Sekunden zu verzögern.

Weitere Informationen finden Sie im Artikel zur Red Hat-Wissensdatenbank.

  1. Erstellen Sie eine systemd-Drop-in-Datei, die eine Verzögerung des Starts des Corosync-Dienstes unter node-1, node-2 und node-3 festlegt:

    1. Öffnen Sie den corosync.service zur Bearbeitung. 

      sudo systemctl edit corosync.service

    2. Hängen Sie die folgenden Zeilen an, speichern Sie die Datei und beenden Sie den Editor.

      [Service]
ExecStartPre=/bin/sleep 60

    3. Aktualisieren Sie den Dienstmanager und prüfen Sie, ob die Konfiguration berücksichtigt wurde.

      sudo systemctl daemon-reload
systemctl status corosync.service --no-pager

      Wenn Sie den Bereich „Drop-in“ sehen, wurden die Einstellungen in der Drop-in-Datei berücksichtigt.

Failover testen

Jetzt können Sie testen, ob das Failover wie erwartet funktioniert.

  1. Stellen Sie über Remote Desktop eine Verbindung zur Windows-VM auf node-4 her:
  2. Öffnen Sie eine PowerShell-Sitzung:

  3. Führen Sie das folgende Skript aus:

    while ($True){
  $Conn = New-Object System.Data.SqlClient.SqlConnection
  $Conn.ConnectionString = "Server=CLUSTER_ADDRESS;User ID=sa;Password=SA_PASSWORD;Initial Catalog=master"
  $Conn.Open()

  $Cmd = New-Object System.Data.SqlClient.SqlCommand
  $Cmd.Connection = $Conn
  $Cmd.CommandText = "SELECT @@SERVERNAME"

  $Adapter = New-Object System.Data.SqlClient.SqlDataAdapter $Cmd
  $Data = New-Object System.Data.DataSet
  $Adapter.Fill($Data) | Out-Null
  $Data.Tables[0] + (Get-Date -Format "MM/dd/yyyy HH:mm:ss")

  Start-Sleep -Seconds 2
}

    Ersetzen Sie CLUSTER_ADDRESS durch die Listener-IP-Adresse und SA_PASSWORD durch das Passwort des SA-Kontos auf SQL Server.

    Alle zwei Sekunden stellt das Skript über den Verfügbarkeitsgruppen-Listener oder DNN-Listener eine Verbindung zu SQL Server her und fragt den Servernamen ab.

    Lassen Sie das Skript laufen.

  4. Kehren Sie auf node-1 zu SSH zurück und führen Sie die Befehle aus, um ein Failover auf node-2 auszulösen:

    sudo pcs resource move ms-ag1 node-2 --master
sudo pcs resource move aoag1-group  node-2
sudo pcs resource move aoag1-vip node-2

  5. Kehren Sie zur PowerShell-Sitzung auf node-4 zurück.

    1. Beobachten Sie die Ausgabe des laufenden Skripts. Der Servername ändert sich aufgrund des Failovers von node-1 in node-2.

  6. Kehren Sie zu node-1 zurück und initiieren Sie ein Failback zu node-1:

    sudo pcs resource move ms-ag1 node-1 --master
sudo pcs resource move aoag1-group  node-1
sudo pcs resource move aoag1-vip node-1

  7. Kehren Sie zu Powershell auf node-4 zurück und beenden Sie das Skript durch Drücken von Ctrl+C.

Bereinigen

Nachdem Sie die Anleitung abgeschlossen haben, können Sie die erstellten Ressourcen bereinigen, damit sie keine Kontingente mehr nutzen und keine Gebühren mehr anfallen. In den folgenden Abschnitten erfahren Sie, wie Sie diese Ressourcen löschen oder deaktivieren.

Projekt löschen

Am einfachsten vermeiden Sie weitere Kosten, wenn Sie das zum Ausführen der Anleitung erstellte Projekt löschen.

So löschen Sie das Projekt:

  1. Wechseln Sie in der Google Cloud Console zur Seite Ressourcen verwalten.

    Zur Seite „Ressourcen verwalten“

  2. Wählen Sie in der Projektliste das Projekt aus, das Sie löschen möchten, und klicken Sie dann auf Löschen.
  3. Geben Sie im Dialogfeld die Projekt-ID ein und klicken Sie auf Shut down (Beenden), um das Projekt zu löschen.