Google verwendet KI-Technologie, um Inhalte in Ihre bevorzugte Sprache zu übersetzen. KI-Übersetzungen können Fehler enthalten.

Eine SQL Server-Failovercluster-Instanz unter Linux mit einem Datenträger für mehrere Autoren konfigurieren

Um eine Hochverfügbarkeit für SQL Server in zwei verschiedenen Zonen in Compute Engine zu erreichen, können Sie eine SQL Server-Failovercluster-Instanz (FCI) unter Linux bereitstellen, die Multi-Writer-Laufwerke verwendet. Im Gegensatz zu herkömmlichen Shared-Nothing-Architekturen können Sie mit dieser Konfiguration Knoten in verschiedenen Zonen gleichzeitig an denselben Datenträger anhängen. In dieser Anleitung wird beschrieben, wie Sie eine hochverfügbare SQL Server-FCI unter Linux in Compute Engine mit der synchronen Replikation von Google Cloud Hyperdisk mit geringer Latenz bereitstellen.

Dieses Design sorgt dafür, dass SQL Server auch im unwahrscheinlichen Fall eines Zonenausfalls verfügbar bleibt. Die Kombination von Pacemaker für die Clusterorchestrierung mit der zonenübergreifenden Resilienz von Compute Engine bietet eine robuste, leistungsstarke Lösung für geschäftskritische Datenbankarbeitslasten, die eine einfache gemeinsame Speicherung erfordern.

Vorteile der Implementierung von Hochverfügbarkeit mit Laufwerken für mehrere Autoren

Wenn Sie eine SQL Server-Failovercluster-Instanz mit Datenträgern für mehrere Autoren anstelle von Always On-Verfügbarkeitsgruppen (AGs) unter Linux verwenden, entfällt die Komplexität der Verwaltung mehrerer Datenkopien und der Synchronisierungsaufwand, der bei AG-Konfigurationen entsteht.

Eine Architektur mit gemeinsam genutzten Volumes ist auch speichereffizienter als AG-Architekturen, bei denen auf jedem Knoten vollständige Datenreplikate verwendet werden. Gemeinsam genutzte Volumes können auch die Festplattenkosten in Spiegelungsszenarien senken.

Wichtige Highlights dieser Architektur

Zonale Redundanz: Schutz von Daten im seltenen Fall eines Knotenausfalls oder eines zonalen Ausfalls.
Vereinfachte Verwaltung: Die Verwaltung mehrerer Datenkopien ist weniger komplex als bei Always On-Verfügbarkeitsgruppen.
Speichereffizienz: Es wird ein einzelnes freigegebenes Volume für Daten und Logs verwendet, das durch die Funktion für mehrere Schreibvorgänge optimiert wird.
Native Linux-Orchestrierung: Verwendet branchenübliche Hochverfügbarkeitserweiterungen (HAE) für nahtloses Failover.

In einer lokalen Umgebung können Sie WSFC ARP-Ankündigungen ausführen lassen, wenn ein Failover auftritt, um Netzwerkgeräte über eine IP-Adressänderung zu benachrichtigen. Google Cloudignoriert jedoch ARP-Ankündigungen. Daher müssen Sie einen internen Load Balancer implementieren (siehe Windows Server Failover Clustering ausführen).

Architektur

In diesem Artikel wird davon ausgegangen, dass Sie über Grundkenntnisse zu SQL Server, Active Directory und Compute Engine verfügen.

Ziele

In dieser Anleitung erfahren Sie, wie Sie die folgenden Aufgaben ausführen, um Ihr Ziel zu erreichen:

SQL Server-Bereitstellung unter Linux erstellen
Nichtflüchtige Speicher mit mehreren Autoren erstellen, anhängen und konfigurieren
Konfigurieren Sie den Pacemaker-Cluster.
Load-Balancer einrichten
Führen Sie einen Failover-Test durch.

Kosten

In dieser Anleitung werden kostenpflichtige Komponenten von Google Cloudverwendet, darunter:

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

Hinweis

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. Wählen Sie in der Google Cloud Console auf der Seite für die Projektauswahl ein Google Cloud -Projekt aus oder erstellen Sie eines.
  Rollen, die zum Auswählen oder Erstellen eines Projekts erforderlich sind
  - Projekt auswählen: Für die Auswahl eines Projekts ist keine bestimmte IAM-Rolle erforderlich. Sie können jedes Projekt auswählen, für das Ihnen eine Rolle zugewiesen wurde.
  - Projekt erstellen: Zum Erstellen eines Projekts benötigen Sie die Rolle „Projektersteller“ (roles/resourcemanager.projectCreator), die die Berechtigung resourcemanager.projects.create enthält. Weitere Informationen zum Zuweisen von Rollen
  Hinweis: Wenn Sie die Ressourcen, die Sie in diesem Verfahren erstellen, nicht behalten möchten, erstellen Sie ein Projekt, anstatt ein vorhandenes Projekt auszuwählen. Wenn Sie fertig sind, können Sie das Projekt löschen und dadurch alle mit dem Projekt verknüpften Ressourcen entfernen.
  
  Zur Projektauswahl
2. Prüfen Sie, ob die Abrechnung für Ihr Google Cloud Projekt aktiviert ist.
3. 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 FCI vor:

Öffnen Sie in der Google Cloud Console Cloud Shell. Klicken Sie hierzu auf den Button Cloud Shell aktivieren .

Rufen Sie die Google Cloud Console auf.
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.
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.

Clusterknoten erstellen

Stellen Sie zwei VMs als Clusterknoten und eine dritte als dedizierten Client bereit, um die Konnektivität und Failover-Leistung zu validieren.

Initialisieren Sie die folgenden Variablen, die für die verbleibenden Befehle verwendet werden.

BOOT_DISK_SIZE=50
BOOT_IOPS=10000
BOOT_THROUGHPUT=400
DATA_IOPS=10000
DATA_THROUGHPUT=400
DATA_DISK_SIZE=200
REGION=$(gcloud config get-value compute/region)
ZONE1=$REGION-a
ZONE2=$REGION-b
SUBNET=SUBNET_NAME
MACHINE_TYPE=c3-standard-8
VPC_NAME=VPC_NAME

Erstellen Sie zwei regionale Laufwerke, ein Datenlaufwerk und ein weiteres für das Log. Damit beide Instanzen auf die Laufwerke zugreifen können, aktivieren Sie den Modus für mehrere Autoren für beide Laufwerke mit dem Flag --access-mode=READ_WRITE_MANY.

gcloud compute disks create sqlfci-mw-data-disk \
--size=$DATA_DISK_SIZE \
--type=hyperdisk-balanced-high-availability \
--region=$REGION \
--replica-zones=$ZONE1,$ZONE2 \
--provisioned-iops=$DATA_IOPS \
--provisioned-throughput=$DATA_THROUGHPUT \
--access-mode=READ_WRITE_MANY

gcloud compute disks create sqlfci-mw-log-disk \
--size=$DATA_DISK_SIZE \
--type=hyperdisk-balanced-high-availability \
--region=$REGION \
--replica-zones=$ZONE1,$ZONE2 \
--provisioned-iops=$DATA_IOPS \
--provisioned-throughput=$DATA_THROUGHPUT \
--access-mode=READ_WRITE_MANY

Erstellen Sie die Linux-VMs und hängen Sie die erstellten Multi-Writer-Laufwerke an.

gcloud compute instances create node-1 \
--boot-disk-size=$BOOT_DISK_SIZE \
--boot-disk-type=hyperdisk-balanced \
--boot-disk-provisioned-iops=$BOOT_IOPS \
--boot-disk-provisioned-throughput=$BOOT_THROUGHPUT \
--zone $ZONE1 \
--machine-type $MACHINE_TYPE \
--subnet $SUBNET \
--image-family ubuntu-2204-lts \
--image-project ubuntu-os-cloud \
--disk="name=sqlfci-mw-data-disk,scope=regional,mode=rw" \
--disk="name=sqlfci-mw-log-disk,scope=regional,mode=rw" \
--scopes=compute-rw,trace,service-control,service-management,pubsub,monitoring-write,logging-write,storage-rw \
--tags=sqlfci

gcloud compute instances create node-2 \
--boot-disk-size=$BOOT_DISK_SIZE \
--boot-disk-type=hyperdisk-balanced \
--boot-disk-provisioned-iops=$BOOT_IOPS \
--boot-disk-provisioned-throughput=$BOOT_THROUGHPUT \
--zone $ZONE2 \
--machine-type $MACHINE_TYPE \
--subnet $SUBNET \
--image-family ubuntu-2204-lts \
--image-project ubuntu-os-cloud \
--disk="name=sqlfci-mw-data-disk,scope=regional,mode=rw" \
--disk="name=sqlfci-mw-log-disk,scope=regional,mode=rw" \
--scopes=compute-rw,trace,service-control,service-management,pubsub,monitoring-write,logging-write,storage-rw \
--tags=sqlfci

Erstellen Sie die Windows-Client-VM cl-node, mit der Sie die Verbindung testen.

gcloud compute instances create cl-node \
--boot-disk-size=100 \
--boot-disk-type=hyperdisk-balanced \
--machine-type $MACHINE_TYPE \
--image-family windows-2025 \
--image-project windows-cloud \
--zone $ZONE1 \
--subnet $SUBNET \
--scopes=compute-rw,trace,service-control,service-management,pubsub,monitoring-write,logging-write,storage-rw

Internen Load Balancer erstellen

Reservieren Sie eine IP-Adresse für den Cluster und den Load-Balancer.

gcloud compute addresses create sqlfci-lb-ipaddress \
--region=$REGION \
--subnet=$SUBNET \
--purpose="SHARED_LOADBALANCER_VIP"
CLUSTER_ADDRESS=$(gcloud compute addresses describe sqlfci-lb-ipaddress \
--region $REGION \
--format=value\(address\)) && \
echo "Cluster IP address: $CLUSTER_ADDRESS"

Erstellen Sie eine Systemdiagnose für den Cluster.

gcloud compute health-checks create tcp sqlfci-healthcheck \
--port="60008" \
--region=$REGION \
--check-interval=3 \
--timeout=2 \
--unhealthy-threshold=2 \
--healthy-threshold=5

Erstellen Sie eine Firewallregel, um eine Verbindung zum Systemdiagnoseport zuzulassen.

gcloud compute firewall-rules create "allow-sqlfci-healthcheck-60008" \
--allow "tcp:60008" \
--target-tags sqlfci \
--network $VPC_NAME \
--source-ranges="35.191.0.0/16,130.211.0.0/22" \
--priority="1000"

Weitere Informationen finden sich unter Firewallregeln für Systemdiagnosen.

Erstellen Sie Instanzgruppen für die Clusterknoten.

gcloud compute instance-groups unmanaged create sqlfci-1-uig \
--zone=$ZONE1
gcloud compute instance-groups unmanaged add-instances sqlfci-1-uig \
--zone=$ZONE1 \
--instances=node-1

gcloud compute instance-groups unmanaged create sqlfci-2-uig \
--zone=$ZONE2
gcloud compute instance-groups unmanaged add-instances sqlfci-2-uig \
--zone=$ZONE2 \
--instances=node-2

Erstellen Sie den Backend-Dienst des Load-Balancers.

gcloud compute backend-services create sqlfci-backend-services \
--region=$REGION \
--load-balancing-scheme="INTERNAL" \
--protocol="TCP" \
--health-checks=sqlfci-healthcheck \
--health-checks-region=$REGION

gcloud compute backend-services add-backend sqlfci-backend-services \
--region=$REGION \
--instance-group=sqlfci-1-uig \
--instance-group-zone=$ZONE1

gcloud compute backend-services add-backend sqlfci-backend-services \
--region=$REGION \
--instance-group=sqlfci-2-uig \
--instance-group-zone=$ZONE2

Erstellen Sie die Weiterleitungsregel für den Load Balancer.

gcloud compute forwarding-rules create "sqlfci-forwarding-rule" \
--load-balancing-scheme=INTERNAL \
--network=$VPC_NAME \
--subnet=$SUBNET \
--region=$REGION \
--address=$CLUSTER_ADDRESS \
--ip-protocol="TCP" \
--ports="ALL" \
--backend-service=sqlfci-backend-services \
--backend-service-region=$REGION

Erstellen Sie einen Cloud Storage-Bucket, um Dateien vom primären zu den sekundären Clusterknoten zu übertragen.
```
gcloud storage buckets create gs://BUCKET_NAME \
--location=$REGION \
--public-access-prevention
```
Ersetzen Sie dabei BUCKET_NAME durch den Namen des zu erstellenden Buckets.

Weitere Informationen finden Sie unter Buckets erstellen.

Erforderliche Software installieren

Laden Sie die SQL Server-Engine und die Clusterverwaltung auf die beiden Linux-VMs node-1 und node-2 herunter, die Teil des Failover-Clusters sind, und installieren und konfigurieren Sie sie.

Stellen Sie eine SSH-Verbindung zu den einzelnen VMs her. Weitere Informationen finden Sie unter Verbindung zu Linux-VMs herstellen und Best Practices für die Steuerung des SSH-Netzwerkzugriffs.
Aktualisieren Sie hosts file auf node-1 und node-2.

Hinweis :In Produktionsumgebungen sollte die Domainauflösung von einem dedizierten DNS-Server (Domain Name System) verwaltet werden.
1. Öffnen Sie hosts file zum Bearbeiten.
```
sudo vi /etc/hosts
```
2. 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
```
  Ersetzen Sie NODE1_INTERNAL_IP und NODE2_INTERNAL_IP durch die interne IP-Adresse jeder Linux-VM.

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: 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

Die Ausgabe sieht in etwa so aus:

PING node-1 (10.128.0.37) 56(84) bytes of data.
64 bytes from node-1 (10.128.0.37): icmp_seq=1 ttl=128 time=1.91 ms
64 bytes from node-1 (10.128.0.37): icmp_seq=2 ttl=128 time=0.234 ms
64 bytes from node-1 (10.128.0.37): icmp_seq=3 ttl=128 time=0.249 ms
64 bytes from node-1 (10.128.0.37): icmp_seq=4 ttl=128 time=0.263 ms

Installieren Sie SQL Server 2025.

Fügen Sie dem System das SQL Server-Repository hinzu.

curl https://packages.microsoft.com/keys/microsoft.asc | sudo tee /etc/apt/trusted.gpg.d/microsoft.asc
curl -fsSL https://packages.microsoft.com/config/ubuntu/22.04/mssql-server-2025.list | sudo tee /etc/apt/sources.list.d/mssql-server-2025.list
sudo apt-get update

Installieren Sie SQL Server.
```
sudo apt-get install -y mssql-server
```

Installieren Sie die SQL Server-Entwicklertools. Laden Sie die SQL Server-Tools auf die beiden Linux-VMs herunter, die Teil des Failoverclusters sind, und installieren Sie sie.

curl https://packages.microsoft.com/config/ubuntu/22.04/prod.list | sudo tee /etc/apt/sources.list.d/mssql-release.list
sudo apt-get update

sudo ACCEPT_EULA=Y apt-get install -y mssql-tools18 unixodbc-dev

Installieren Sie Pacemaker. Pacemaker ist eine Open-Source-Software für Hochverfügbarkeitsressourcen, die mit der Cluster-Engine Corosync verwendet wird. In diesem Abschnitt installieren Sie Pacemaker auf beiden Cluster-VMs.
1. Installieren Sie Pacemaker auf node-1 und node-2.
```
sudo apt-get install -y pacemaker pcs fence-agents resource-agents pacemaker-cli-utils crmsh
```
2. Installieren Sie den SQL Server-Ressourcen-Agent für Pacemaker.
```
sudo apt-get install -y mssql-server-ha
```
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. Wenn der Firewall-Dienst nicht ausgeführt wird, können Sie diesen Schritt ignorieren.
```
sudo ufw allow 1433
sudo ufw allow 5022
sudo ufw reload
```
  Hinweis :Wenn Sie andere Ports für SQL Server oder für den Endpunkt der Verfügbarkeitsgruppe verwenden, ändern Sie die Firewallregeln entsprechend.

Primären Datenbankknoten konfigurieren

In diesem Abschnitt initialisieren Sie die beiden Multi-Writer-Laufwerke und richten jedes Laufwerk mit Volumegruppen und logischen Gruppen ein.

Konfigurieren Sie das LVM.

Konfigurieren Sie die LVM-Einstellungen.

Sichern Sie die vorhandene Konfiguration.

sudo cp /etc/lvm/lvm.conf /etc/lvm/lvm.conf.bak

So aktualisieren Sie die Quelle der System-ID:

sudo sed -i 's/^\(\s*system_id_source\s*=\s*\)"none"/\1"uname"/' /etc/lvm/lvm.conf

Prüfen Sie, ob die Änderung erfolgreich vorgenommen wurde.
```
grep 'system_id_source *= *"uname"' /etc/lvm/lvm.conf
```

Konfigurieren Sie die LVM-Volume-Gruppen und logischen Volumes.

sudo pvcreate /dev/nvme0n2 /dev/nvme0n3
sudo pvs
sudo vgcreate vgdata /dev/nvme0n2
sudo lvcreate -l 100%FREE -n lvdata vgdata
sudo vgcreate vglogtmp /dev/nvme0n3
sudo lvcreate -l 70%FREE  -n lvlog vglogtmp
sudo lvcreate -l 100%FREE -n lvtmp vglogtmp
sudo vgs -o+systemid

Formatieren Sie Volumes mit dem xfs-Dateisystem und einer Blockgröße von 64 KB.

sudo mkfs.xfs -d su=64k,sw=1 -L data /dev/vgdata/lvdata -f
sudo mkfs.xfs -d su=64k,sw=1 -L dblog /dev/vglogtmp/lvlog -f
sudo mkfs.xfs -d su=64k,sw=1 -L tmp /dev/vglogtmp/lvtmp -f

Prüfen Sie, ob die Volumes erstellt wurden.
```
sudo lvs
```

Laufwerke bereitstellen und formatieren

Richten Sie Bereitstellungspunkte für die freigegebenen Laufwerke ein und gewähren Sie dem mssql-Nutzer Zugriff.

Erstellen Sie Bereitstellungspunkte für die neuen Volumes.

sudo mkdir /mssql
sudo mkdir -p /mssql/db_data
sudo mkdir -p /mssql/db_log
sudo mkdir -p /mssql/db_temp

Stellen Sie die LVM-Volumes an Bereitstellungspunkten bereit.

sudo mount /dev/vgdata/lvdata /mssql/db_data
sudo mount /dev/vglogtmp/lvlog /mssql/db_log
sudo mount /dev/vglogtmp/lvtmp /mssql/db_temp

Legen Sie den Nutzer mssql als Eigentümer der Mount-Punkte fest.

sudo chown mssql:mssql /mssql/db_data
sudo chown mssql:mssql /mssql/db_log
sudo chown mssql:mssql /mssql/db_temp

Konfigurieren Sie SQL Server:
1. Legen Sie Variablen fest, mit denen die Masterdatenbank in den freigegebenen Speicher verschoben wird, und führen Sie das Tool mssql-conf aus.
```
sudo MSSQL_MASTER_DATA_FILE="/mssql/db_data/master.mdf" MSSQL_MASTER_LOG_FILE="/mssql/db_data/mastlog.ldf" /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.
  
  Hinweis: Für jede VM-Instanz ist eine SQL Server-Lizenz erforderlich. Wenn Sie Microsoft-Anwendungsserver ausführen, hilft Ihnen License Mobility über Software Assurance bei der Umstellung auf Google Cloud. Weitere Informationen finden Sie unter License Mobility mit Microsoft-Serveranwendungen verwenden. Wenn Sie keine eigene Lizenz verwenden und eine Lizenz über Google (PAYG) erwerben müssen, führen Sie die Schritte unter SQL Server-Lizenz zu einem Bootlaufwerk hinzufügen aus, um eine Lizenz für jede VM-Instanz zu erwerben.
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
```

SQL Server und Pacemaker konfigurieren

SQL Server-Nutzer für Pacemaker erstellen Ersetzen Sie SA_PASSWORD durch das Passwort des SA-Kontos auf SQL Server und PA_PASSWORD durch das Passwort, das für das pacemaker-Konto verwendet wird.

QUERY="
CREATE LOGIN [pacemaker] with PASSWORD= N'PA_PASSWORD';
ALTER SERVER ROLE [sysadmin] ADD MEMBER [pacemaker];
GO"

/opt/mssql-tools18/bin/sqlcmd -No -S localhost -U sa -P 'SA_PASSWORD' -Q "$QUERY"

Fügen Sie die Pacemaker-Anmeldung und das Passwort dem Ordner „SQL Server-Secrets“ hinzu.

{
  echo 'pacemaker'
  echo PA_PASSWORD'
} | sudo tee /var/opt/mssql/secrets/passwd > /dev/null
sudo chown root:root /var/opt/mssql/secrets/passwd
sudo chmod 400 /var/opt/mssql/secrets/passwd

Aktualisieren Sie die SQL Server-Konfiguration, damit die neuen Speicherorte für Daten, Protokolle und temporäre Dateien verwendet werden. Sie legen auch die empfohlenen SQL Server-Einstellungen fest.

sudo /opt/mssql/bin/mssql-conf set filelocation.defaultdatadir /mssql/db_data
sudo /opt/mssql/bin/mssql-conf set filelocation.defaultlogdir /mssql/db_log
sudo /opt/mssql/bin/mssql-conf set filelocation.defaultdumpdir /mssql/db_log
sudo /opt/mssql/bin/mssql-conf traceflag 9944 3979 on
sudo /opt/mssql/bin/mssql-conf set control.alternatewritethrough 0
sudo /opt/mssql/bin/mssql-conf set control.writethrough 1

TempDB auf freigegebene Festplatte verschieben

Rufen Sie eine Liste der TempDB-Dateien ab und verwenden Sie sie, um eine ALTER-Abfrage zu erstellen. Diese Abfrage wird im nächsten Schritt verwendet, um den neuen Speicherort für die TempDB-Dateien festzulegen.

QUERY="
SET NOCOUNT ON;
SELECT 'ALTER DATABASE tempdb MODIFY FILE (NAME = [' + f.name + '],' + ' FILENAME = ''/mssql/db_temp/' + f.name + CASE WHEN f.type = 1 THEN '.ldf' ELSE '.mdf' END + ''');' FROM sys.master_files f WHERE f.database_id = DB_ID(N'tempdb');"

/opt/mssql-tools18/bin/sqlcmd -No -S localhost -U sa -P 'SA_PASSWORD' -Q "$QUERY"

Erfassen Sie die Ausgabe des vorherigen Befehls. Sie verwenden die Ausgabe, um den nächsten auszuführenden Befehl zu erstellen.

QUERY="QUERY_OUTPUT"

Beispielabfrage mit Ausgabe:

QUERY="
ALTER DATABASE tempdb MODIFY FILE (NAME = [tempdev], FILENAME = '/mssql/db_temp/tempdev.mdf');
ALTER DATABASE tempdb MODIFY FILE (NAME = [templog], FILENAME = '/mssql/db_temp/templog.ldf');
ALTER DATABASE tempdb MODIFY FILE (NAME = [tempdev2], FILENAME = '/mssql/db_temp/tempdev2.mdf');
ALTER DATABASE tempdb MODIFY FILE (NAME = [tempdev3], FILENAME = '/mssql/db_temp/tempdev3.mdf');"

Führen Sie den generierten SQL-Befehl aus, um die TempDB-Dateien zu verschieben.

/opt/mssql-tools18/bin/sqlcmd -No -S localhost -U sa -P 'SA_PASSWORD' -Q "$QUERY"

Starten Sie den SQL Server-Dienst neu, damit die Änderungen wirksam werden.
```
sudo systemctl restart mssql-server.service
```
Prüfen Sie, ob die TempDB-Dateien erstellt wurden.
```
ls -l /mssql/db_temp/
```
Prüfen Sie, ob der SQL Server-Dienst ausgeführt wird.
```
systemctl status mssql-server --no-pager
```

HAProxy konfigurieren

Legen Sie ein neues Passwort für hacluster fest.

Hinweis: Legen Sie auf allen drei Knoten dasselbe Passwort fest. Sie benötigen dieses Passwort, wenn Sie den Cluster konfigurieren.
```
sudo passwd hacluster
```
Um die Einrichtung abzuschließen und zu testen, ob der Netzwerk-Load-Balancer richtig eingerichtet ist, installieren und konfigurieren Sie HAProxy tcp listener auf beiden Clusterknoten:
1. Installieren Sie HAProxy.
```
sudo apt-get install haproxy
```
2. Geben Sie Y ein, um die Installation abzuschließen.
3. Bearbeiten Sie die Datei haproxy.cfg.
```
sudo vi /etc/haproxy/haproxy.cfg
```
4. Ändern Sie im Abschnitt defaults 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 *:60008
```

Starten Sie den HAProxy-Dienst.

sudo systemctl start haproxy.service
sudo systemctl status haproxy.service

Beenden und deaktivieren Sie den HAProxy-Dienst.

sudo systemctl stop haproxy.service
sudo systemctl disable haproxy.service

Laden Sie die Datei mit dem Maschinenschlüssel mit dem folgenden Befehl in Cloud Storage hoch.
```
sudo gcloud storage cp /var/opt/mssql/secrets/machine-key gs://BUCKET_NAME/
```
Ersetzen Sie BUCKET_NAME durch den Namen des erstellten Buckets.
Beenden und deaktivieren Sie den SQL Server-Dienst. Ab diesem Punkt wird der Dienst vom Cluster gesteuert.
```
sudo systemctl stop mssql-server.service
sudo systemctl disable mssql-server.service
```

Trennen Sie den gemeinsamen Speicher.

sudo umount /mssql/db_data
sudo umount /mssql/db_log
sudo umount /mssql/db_temp

Bereinigen Sie die vorhandene Standardclusterkonfiguration.
```
sudo pcs cluster destroy
```

Sekundären Knoten konfigurieren

Erstellen Sie Bereitstellungspunkte für die LVM-Volumes. Sie müssen das Laufwerk nicht formatieren, da es für node-1 freigegeben ist. Sie haben das Laufwerk bereits formatiert und die LVM-Volumes konfiguriert, als Sie node-1 konfiguriert haben.
```
sudo mkdir /mssql
sudo mkdir -p /mssql/db_data
sudo mkdir -p /mssql/db_log
sudo mkdir -p /mssql/db_temp

sudo chown mssql:mssql /mssql/db_data
sudo chown mssql:mssql /mssql/db_log
sudo chown mssql:mssql /mssql/db_temp
```
Konfigurieren Sie SQL Server.
1. Wenn Sie die Masterdatenbank auf die freigegebene Datenfestplatte verschieben möchten, legen Sie die folgenden Variablen fest und führen Sie dann das Tool mssql-conf aus, um die Änderungen zu übernehmen.
```
sudo MSSQL_MASTER_DATA_FILE="/mssql/db_data/master.mdf" MSSQL_MASTER_LOG_FILE="/mssql/db_data/mastlog.ldf" /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.
  
  Hinweis :Für jede Instanz ist eine SQL Server-Lizenz erforderlich. Wenn Sie Microsoft-Anwendungsserver ausführen, hilft Ihnen License Mobility über Software Assurance bei der Umstellung auf Google Cloud. Weitere Informationen finden Sie unter License Mobility mit Microsoft-Serveranwendungen verwenden. Wenn Sie keine eigene Lizenz verwenden und eine Lizenz über Google (PAYG) erwerben müssen, führen Sie die Schritte unter SQL Server-Lizenz zu einem Bootlaufwerk hinzufügen aus, um eine Lizenz für jede VM-Instanz zu erwerben.
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
```

SQL Server-Nutzer für den Pacemaker-Cluster erstellen Ersetzen Sie SA_PASSWORD durch das Passwort des SA-Kontos auf SQL Server und PA_PASSWORD durch das Passwort, das für das pacemaker-Konto verwendet wird.

QUERY="
CREATE LOGIN [pacemaker] with PASSWORD= N'PA_PASSWORD';
ALTER SERVER ROLE [sysadmin] ADD MEMBER [pacemaker];
GO"

/opt/mssql-tools18/bin/sqlcmd -No -S localhost -U sa -P 'SA_PASSWORD' -Q "$QUERY"

Fügen Sie die Pacemaker-Anmeldung und das Passwort dem Ordner „SQL Server-Secrets“ hinzu.

{
  echo 'pacemaker'
  echo 'PA_PASSWORD'
} | sudo tee /var/opt/mssql/secrets/passwd > /dev/null
sudo chown root:root /var/opt/mssql/secrets/passwd
sudo chmod 400 /var/opt/mssql/secrets/passwd

Aktualisieren Sie die SQL Server-Konfiguration, um die neuen Speicherorte für Daten, Protokolle und temporäre Dateien zu verwenden. Außerdem legen Sie die empfohlenen SQL Server-Einstellungen fest.

sudo /opt/mssql/bin/mssql-conf set filelocation.defaultdatadir /mssql/db_data
sudo /opt/mssql/bin/mssql-conf set filelocation.defaultlogdir /mssql/db_log
sudo /opt/mssql/bin/mssql-conf set filelocation.defaultdumpdir /mssql/db_log
sudo /opt/mssql/bin/mssql-conf traceflag 9944 3979 on
sudo /opt/mssql/bin/mssql-conf set control.alternatewritethrough 0
sudo /opt/mssql/bin/mssql-conf set control.writethrough 1

Verschieben Sie TempDB auf die freigegebene Datenfestplatte.

Rufen Sie eine Liste der TempDB-Dateien ab und verwenden Sie sie, um die ALTER-Abfrage zu erstellen.

QUERY="
SET NOCOUNT ON;
SELECT 'ALTER DATABASE tempdb MODIFY FILE (NAME = [' + f.name + '],' + ' FILENAME = ''/mssql/db_temp/' + f.name + CASE WHEN f.type = 1 THEN '.ldf' ELSE '.mdf' END + ''');' FROM sys.master_files f WHERE f.database_id = DB_ID(N'tempdb');"

/opt/mssql-tools18/bin/sqlcmd -No -S localhost -U sa -P 'SA_PASSWORD' -Q "$QUERY"

Erfassen Sie die Ausgabe des vorherigen Befehls. Sie verwenden die Ausgabe, um den nächsten auszuführenden Befehl zu erstellen.

QUERY="QUERY_OUTPUT"

Beispielabfrage mit Ausgabe:

QUERY="
ALTER DATABASE tempdb MODIFY FILE (NAME = [tempdev], FILENAME = '/mssql/db_temp/tempdev.mdf');
ALTER DATABASE tempdb MODIFY FILE (NAME = [templog], FILENAME = '/mssql/db_temp/templog.ldf');
ALTER DATABASE tempdb MODIFY FILE (NAME = [tempdev2], FILENAME = '/mssql/db_temp/tempdev2.mdf');
ALTER DATABASE tempdb MODIFY FILE (NAME = [tempdev3], FILENAME = '/mssql/db_temp/tempdev3.mdf');"

Führen Sie den generierten SQL-Befehl aus, um die TempDB-Dateien zu verschieben.

/opt/mssql-tools18/bin/sqlcmd -No -S localhost -U sa -P 'SA_PASSWORD' -Q "$QUERY"

Starten Sie den SQL Server-Dienst neu, damit die Änderungen wirksam werden.
```
sudo systemctl restart mssql-server.service
```
Prüfen Sie, ob der SQL Server-Dienst ausgeführt wird.
```
sudo systemctl status mssql-server --no-pager
```
Prüfen Sie, ob TempDB-Dateien erstellt wurden.
```
ls -l /mssql/db_temp/
```

Beenden Sie den SQL Server-Dienst und deaktivieren Sie ihn vorübergehend.

sudo systemctl stop mssql-server.service
sudo systemctl disable mssql-server.service

Damit beide Knoten denselben Schlüssel für SQL Server verwenden, laden Sie die Maschinenschlüsseldatei von node-1 herunter.

sudo rm /var/opt/mssql/secrets/machine-key
sudo gcloud storage cp gs://BUCKET_NAME/machine-key /var/opt/mssql/secrets/machine-key
sudo chown mssql:mssql /var/opt/mssql/secrets/machine-key
sudo chmod 0600  /var/opt/mssql/secrets/machine-key

Konfigurieren Sie die LVM-Einstellungen.

Sichern Sie die vorhandene Konfiguration.

sudo cp /etc/lvm/lvm.conf /etc/lvm/lvm.conf.bak

Aktualisieren Sie die Quelle der System-ID.

sudo sed -i 's/^\(\s*system_id_source\s*=\s*\)"none"/\1"uname"/' /etc/lvm/lvm.conf

Prüfen Sie die Änderung mit dem folgenden Befehl:

cat /etc/lvm/lvm.conf | grep uname

Die Ausgabe sieht in etwa so aus:

#     Set the system ID from the hostname (uname) of the system.
system_id_source = "uname"

Prüfen Sie, ob die Änderung erfolgreich vorgenommen wurde.
```
grep 'system_id_source *= *"uname"' /etc/lvm/lvm.conf
```

Legen Sie ein neues Passwort für hacluster fest.

Hinweis :Legen Sie auf beiden Knoten dasselbe Passwort fest. Dieses Passwort wird für die Einrichtung des Clusters benötigt.
```
sudo passwd hacluster
```
Um die Einrichtung abzuschließen und zu testen, ob der Netzwerk-Load-Balancer richtig eingerichtet ist, installieren und konfigurieren Sie HAProxy tcp listener auf beiden Clusterknoten.
1. Installieren Sie 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 *:60008
```
6. Starten Sie den HAProxy-Dienst.
```
sudo systemctl start haproxy.service
sudo systemctl status haproxy.service
```

Beenden und deaktivieren Sie den HAProxy-Dienst.

sudo systemctl stop haproxy.service
sudo systemctl disable haproxy.service

Vorhandene Standardclusterkonfiguration bereinigen.
```
sudo pcs cluster destroy
```

Clusterkonfiguration abschließen

Kehren Sie zu node-1 zurück, um die Clusterkonfiguration fortzusetzen.

Authentifizieren Sie sich als Nutzer hacluster.

sudo pcs host auth node-1 node-2 -u hacluster -p "HA_PASSWORD"

Erstellen Sie einen Cluster mit dem Namen ubuntu_fci.

sudo pcs cluster setup ubuntu_fci node-1 addr="NODE1_INTERNAL_IP" node-2 addr="NODE2_INTERNAL_IP" --start --enable

Legen Sie die No-Quorum-Richtlinie für einen Cluster mit zwei Knoten fest.
```
sudo pcs property set no-quorum-policy="ignore"
```

Erstellen Sie eine Clusterressource für die virtuelle IP-Adresse.

sudo pcs resource create pcs-cluster-vip ocf:heartbeat:IPaddr2 ip="CLUSTER_ADDRESS" cidr_netmask=32 nic=ens3 op monitor interval=30s

Ersetzen Sie CLUSTER_ADDRESS durch die zuvor reservierte IP-Adresse.

Erstellen Sie Clusterressourcenobjekte für alle freigegebenen Volumes.

sudo pcs resource create vgdata ocf:heartbeat:LVM-activate vgname=vgdata vg_access_mode=system_id activation_mode=exclusive
sudo pcs resource create vglogtmp ocf:heartbeat:LVM-activate vgname=vglogtmp vg_access_mode=system_id activation_mode=exclusive
sudo pcs resource create data_dir ocf:heartbeat:Filesystem device="/dev/mapper/vgdata-lvdata" directory="/mssql/db_data" fstype="xfs"
sudo pcs resource create log_dir ocf:heartbeat:Filesystem device="/dev/mapper/vglogtmp-lvlog" directory="/mssql/db_log" fstype="xfs"
sudo pcs resource create tmp_dir ocf:heartbeat:Filesystem device="/dev/mapper/vglogtmp-lvtmp" directory="/mssql/db_temp" fstype="xfs"

Erstellen Sie eine Ressourcengruppe und fügen Sie alle erstellten Objekte der neuen Gruppe hinzu.
```
sudo pcs resource group add sql_group pcs-cluster-vip vgdata vglogtmp data_dir log_dir tmp_dir
```
Erstellen Sie die Clusterressource für den Microsoft SQL Server-Dienst und fügen Sie sie der vorhandenen Ressourcengruppe hinzu.
```
sudo pcs resource create sql_fci ocf:mssql:fci  op stop timeout=60s --group sql_group
```

Erstellen Sie eine Clusterressource für HAProxy und fügen Sie sie derselben Gruppe hinzu.

sudo pcs resource create pcs-healthcheck systemd:haproxy.service op monitor interval=20s timeout=30s --group sql_group

Erstellen Sie eine Clustereinschränkung, die die Startreihenfolge für Ressourcen steuert.

sudo pcs constraint order set  pcs-cluster-vip vgdata vglogtmp data_dir log_dir tmp_dir sql_fci pcs-healthcheck

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 Cloudspezialisiert ist.

Fencing-Geräte einrichten

Prüfen Sie, ob der Fence-Agent fence_gce für Compute Engine auf node-1 installiert ist.
```
sudo pcs stonith list | grep fence_gce
```
Weitere Informationen finden Sie unter:
- Fence-Agent für Google Compute Engine
- Führen Sie den folgenden Befehl aus, um die mit dem Agent verknüpften Parameter aufzurufen:
```
sudo pcs stonith describe fence_gce
```

Fencing-Ressourcen für den Cluster konfigurieren.

sudo pcs stonith create node-1-fence fence_gce \
plug=node-1 \
zone=ZONE1 \
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=ZONE2 \
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 ZONE1 und ZONE2 durch die Zone, in der die Linux-VMs bereitgestellt werden, und PROJECT_ID durch Ihre Projekt-ID.

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=ZONE1
sudo fence_gce -o status -n node-2 --zone=ZONE2
```
Die Ausgabe sieht in etwa so aus:
```
Status: ON
```

Ersetzen Sie ZONE1 und ZONE2 durch die Zone, in der die Linux-VMs bereitgestellt werden.

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
```
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"
```
Bereinigen Sie den Cluster-Startvorgang.
```
sudo pcs resource cleanup
```

Prüfen Sie den Clusterstatus.

sudo crm status

Die Ausgabe sieht in etwa so aus:

  Cluster Summary:
    * Stack: corosync
    * Current DC: node-1 (version 2.1.2-ada5c3b36e2) - partition with quorum
    * Last updated: Tue Jun  2 21:36:47 2026
    * Last change:  Mon Apr 27 12:31:58 2026 by root via crm_resource on node-1
    * 2 nodes configured
    * 10 resource instances configured

  Node List:
    * Online: [ node-1 node-2 ]

  Full List of Resources:
    * Resource Group: sql_group:
      * pcs-cluster-vip   (ocf:heartbeat:IPaddr2):         Started node-2
      * vgdata    (ocf:heartbeat:LVM-activate):    Started node-2
      * vglogtmp  (ocf:heartbeat:LVM-activate):    Started node-2
      * data_dir  (ocf:heartbeat:Filesystem):      Started node-2
      * log_dir   (ocf:heartbeat:Filesystem):      Started node-2
      * tmp_dir   (ocf:heartbeat:Filesystem):      Started node-2
      * sql_fci   (ocf:mssql:fci):                 Started node-2
      * pcs-healthcheck   (systemd:haproxy.service):       Started node-2
    * node-1-fence       (stonith:fence_gce):     Started node-2
    * node2-fence        (stonith:fence_gce):     Started node-1

Fencing-Geräte testen

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

Beenden Sie den Fence auf node-2.

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=ZONE2
```
Die Ausgabe sieht in etwa so aus:
```
Success: Powered OFF
```
Prüfen Sie den Clusterstatus.
```
sudo crm status
```
Die Ausgabe sieht in etwa so aus:

    Cluster Summary:
      * Stack: corosync
      * Current DC: node-1 (version 2.1.2-ada5c3b36e2) - partition with quorum
      * Last updated: Tue Jun  2 21:52:00 2026
      * Last change:  Mon Apr 27 12:31:58 2026 by root via crm_resource on node-1
      * 2 nodes configured
      * 10 resource instances configured

    Node List:
      * Online: [ node-1 ]
      * OFFLINE: [ node-2 ]

    Full List of Resources:
      * Resource Group: sql_group:
        * pcs-cluster-vip   (ocf:heartbeat:IPaddr2): Started node-1
        * vgdata    (ocf:heartbeat:LVM-activate):    Started node-1
        * vglogtmp  (ocf:heartbeat:LVM-activate):    Started node-1
        * data_dir  (ocf:heartbeat:Filesystem):      Started node-1
        * log_dir   (ocf:heartbeat:Filesystem):      Started node-1
        * tmp_dir   (ocf:heartbeat:Filesystem):      Started node-1
        * sql_fci   (ocf:mssql:fci):                 Started node-1
        * pcs-healthcheck   (systemd:haproxy.service):       Started node-1
      * node-1-fence       (stonith:fence_gce):     Stopped
      * node-2-fence        (stonith:fence_gce):     Started node-1

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

Zu Compute Engine

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=ZONE2
```
  Die Ausgabe sieht in etwa so aus:
```
Success: Powered ON
```
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
```

Failover testen

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

Erstellen Sie einen Nutzernamen und ein Passwort für die VM-Instanz.
Stellen Sie mithilfe von Remote Desktop eine Verbindung zur VM her und melden Sie sich mit dem Nutzernamen und dem Passwort an, den bzw. das Sie im vorherigen Schritt erstellt haben.
Stellen Sie über Remote Desktop eine Verbindung zur Windows-VM auf cl-node her.
Öffnen Sie eine PowerShell-Sitzung.

Stellen Sie mit dem folgenden Skript eine Verbindung zum Server her. Alle fünf Sekunden stellt das Skript über den Verfügbarkeitsgruppen-Listener eine Verbindung zu SQL Server her und fragt den Servernamen ab.

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

    $Cmd =  $Conn.CreateCommand()
    $Cmd.CommandText = "SELECT SERVERPROPERTY('ComputerNamePhysicalNetBIOS')"

    $Result = $Cmd.ExecuteReader()
    if ($Result.Read()) {
      $currentNode = $Result.GetString(0)
      Write-Host "Current Node: $currentNode at $(Get-Date)"
    }

    $Conn.Close()
    Start-Sleep -Seconds 5
  }
  catch {
      Write-Host "SQL Connection Failed at $(Get-Date). Retrying..."
      Start-Sleep -Seconds 15 # Wait before retrying
  }
}

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

Die Ausgabe sieht in etwa so aus:

  Current Node: node-1 at 06/09/2026 20:24:35
  Current Node: node-1 at 06/09/2026 20:24:40
  Current Node: node-1 at 06/09/2026 20:24:45
  Current Node: node-1 at 06/09/2026 20:24:50
  Current Node: node-1 at 06/09/2026 20:24:55

Lassen Sie das Skript laufen.

Lösen Sie ein Failover auf node-2 aus: Kehren Sie von node-1 zum SSH-Terminal zurück und führen Sie den folgenden Befehl aus.
```
sudo pcs resource move sql_group node-2
```

Kehren Sie zur PowerShell-Sitzung auf cl-node zurück.

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

Die Ausgabe sieht in etwa so aus:

  Current Node: node-1 at 06/09/2026 20:28:51
  Current Node: node-1 at 06/09/2026 20:28:56
  SQL Connection Failed at 06/09/2026 20:29:16. Retrying...
  Current Node: node-2 at 06/09/2026 20:29:31
  Current Node: node-2 at 06/09/2026 20:29:36

Leiten Sie ein Failback zu node-1 ein. Führen Sie in der Befehlszeile auf node-1 den folgenden Befehl aus:
```
sudo pcs resource move sql_group node-1
```
Kehren Sie zu Powershell auf cl-node zurück. 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:

Achtung: Das Löschen von Projekten hat folgende Auswirkungen:

Alle Inhalte des Projekts werden gelöscht. Wenn Sie für die Aufgaben in diesem Dokument ein bereits bestehendes Projekt verwendet haben und dieses löschen, werden auch alle anderen im Rahmen des Projekts erstellten Daten gelöscht.
Benutzerdefinierte Projekt-IDs gehen verloren. Beim Erstellen dieses Projekts haben Sie möglicherweise eine benutzerdefinierte Projekt-ID erstellt, die Sie weiterhin verwenden möchten. Damit die URLs, die die Projekt-ID nutzen, zum Beispiel eine appspot.com-URL, erhalten bleiben, sollten Sie ausgewählte Ressourcen innerhalb des Projekts löschen, anstatt das gesamte Projekt.

Wenn Sie mehrere Architekturen, Anleitungen und Kurzanleitungen durcharbeiten möchten, können Sie die Überschreitung von Projektkontingenten verhindern, indem Sie Projekte wiederverwenden.

Wechseln Sie in der Google Cloud -Console zur Seite Ressourcen verwalten.
Zur Seite „Ressourcen verwalten“
Wählen Sie in der Projektliste das Projekt aus, das Sie löschen möchten, und klicken Sie dann auf Löschen.
Geben Sie im Dialogfeld die Projekt-ID ein und klicken Sie auf Shut down (Beenden), um das Projekt zu löschen.

Eine SQL Server-Failovercluster-Instanz unter Linux mit einem Datenträger für mehrere Autoren konfigurieren Mit Sammlungen den Überblick behalten Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.

Vorteile der Implementierung von Hochverfügbarkeit mit Laufwerken für mehrere Autoren

Wichtige Highlights dieser Architektur

Ziele

Kosten

Hinweis

Projekt und Netzwerk vorbereiten

Clusterknoten erstellen

Internen Load Balancer erstellen

Erforderliche Software installieren

Primären Datenbankknoten konfigurieren

Konfigurieren Sie das LVM.

Laufwerke bereitstellen und formatieren

SQL Server und Pacemaker konfigurieren

TempDB auf freigegebene Festplatte verschieben

HAProxy konfigurieren

Sekundären Knoten konfigurieren

Clusterkonfiguration abschließen

STONITH-Zäune einrichten

Fencing-Geräte einrichten

Fencing-Geräte testen

Failover testen

Bereinigen

Projekt löschen

Nächste Schritte

Eine SQL Server-Failovercluster-Instanz unter Linux mit einem Datenträger für mehrere Autoren konfigurieren