In dieser Anleitung wird beschrieben, wie Sie die asynchrone Replikation von Hyperdisk Balanced über zwei Google Cloud Regionen hinweg als Notfallwiederherstellungslösung (Disaster Recovery, DR) aktivieren, und wie Sie die DR-Instanzen im Falle eines Notfalls starten.
Microsoft SQL Server Failover Clusterinstanzen (FCIs) sind eine einzelne hochverfügbare SQL Server-Instanz, die auf mehreren Windows Server-Failover-Clusterknoten (WSFCs) bereitgestellt wird. Die SQL-Instanz wird immer auf nur einem der Clusterknoten aktiv gehostet. Im Falle eines Zonenausfalls oder eines VM-Problems überträgt der WSFC die Inhaberschaft der Instanzressourcen automatisch auf einen anderen Knoten im Cluster, sodass Clients die Verbindung zu SQL Server FCI wiederherstellen können. SQL Server FCI erfordert, dass sich die relevanten Daten auf freigegebenen Laufwerken befinden, damit der Zugriff über alle WSFC-Knoten möglich ist.
Damit die SQL Server-Bereitstellung einem regionalen Ausfall standhalten kann, replizieren Sie die Laufwerksdaten der primären Region in eine sekundäre Region, indem Sie die asynchrone Replikation aktivieren. In dieser Anleitung werden Hyperdisk Balanced High Availability-Laufwerke mit mehreren Schreibern verwendet, um die asynchrone Replikation über zwei Google Cloud Regionen hinweg als Notfallwiederherstellungslösung (Disaster Recovery, DR) für SQL Server FCI zu aktivieren. Außerdem wird beschrieben, wie Sie die DR-Instanzen im Falle eines Notfalls starten. In diesem Dokument ist ein Notfall ein Ereignis, bei dem ein primärer Datenbankcluster ausfällt oder nicht mehr verfügbar ist, weil die Region des Clusters nicht mehr verfügbar ist, z. B. aufgrund einer Naturkatastrophe.
Diese Anleitung richtet sich an Datenbankarchitekten, Administratoren und Entwickler.
Ziele
- Aktivieren Sie die asynchrone Replikation von Hyperdisk für alle SQL Server FCI-Clusterknoten, die auf ausgeführt werden Google Cloud.
- Simulieren Sie ein Notfallereignis und führen Sie einen vollständigen DR-Prozess aus, um die DR-Konfiguration zu validieren.
Kosten
In diesem Dokument verwenden Sie die folgenden kostenpflichtigen Komponenten von Google Cloud:
Mit dem Preisrechner können Sie eine Kostenschätzung für Ihre voraussichtliche Nutzung vornehmen.
Verwenden Sie den Preisrechner.
Nach Abschluss der in diesem Dokument beschriebenen Aufgaben können Sie weitere Kosten vermeiden, indem Sie die erstellten Ressourcen löschen. Weitere Informationen finden Sie unter Bereinigen.
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:
-
Wählen Sie in der Google Cloud Console auf der Seite für die Projektauswahl ein Projekt vonaus oder erstellen Sie eines Google Cloud .
Erforderliche Rollen zum Auswählen oder Erstellen eines Projekts
- Projekt auswählen: Für die Auswahl eines Projekts ist keine bestimmte IAM-Rolle erforderlich. Sie können ein beliebiges 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 dieresourcemanager.projects.createBerechtigung enthält. Informationen zum Zuweisen von Rollen.
-
Prüfen Sie, ob für Ihr Google Cloud Projekt die Abrechnung aktiviert ist.
-
Aktivieren Sie Cloud Shell in der Google Cloud Console.
-
Richten Sie den SQL Server-Cluster in der primären Region ein. Folgen Sie dazu der Anleitung unter SQL Server FCI-Cluster mit Hyperdisk Balanced High Availability im Modus für mehrere Schreiber konfigurieren. Kehren Sie nach dem Einrichten des Clusters zu dieser Anleitung zurück, um die Notfallwiederherstellung in der sekundären Region zu aktivieren.
Sie benötigen die entsprechenden Berechtigungen in Ihrem Google Cloud-Projekt und in SQL Server, um Sicherungen und Wiederherstellungen durchzuführen.
Notfallwiederherstellung in Google Cloud
Bei der Notfallwiederherstellung in Google Cloud geht es darum, den kontinuierlichen Zugriff auf Daten aufrechtzuerhalten, wenn eine Region ausfällt oder nicht mehr zugänglich ist. Es gibt mehrere Bereitstellungsoptionen für den DR-Standort, die von den Anforderungen an das Recovery Point Objective (RPO) und das Recovery Time Objective (RTO) abhängen. In dieser Anleitung wird eine der Optionen behandelt, bei denen die an die VM angehängten Laufwerke von der primären Region in die DR-Region repliziert werden.
Notfallwiederherstellung mit asynchroner Replikation von Hyperdisk
Die asynchrone Replikation von Hyperdisk ist eine Speicheroption, die eine asynchrone Speicherkopie für die Replikation von Laufwerken zwischen zwei Regionen bietet. Im unwahrscheinlichen Fall eines regionalen Ausfalls können Sie mit der asynchronen Replikation von Hyperdisk einen Daten-Failover zu einer sekundären Region ausführen und die Arbeitslasten in dieser Region neu starten.
Bei der asynchronen Replikation von Hyperdisk werden Daten von einem Laufwerk, das an eine laufende Arbeitslast angehängt ist (das primäre Laufwerk), auf ein separates Laufwerk in einer anderen Region repliziert. Das Laufwerk, auf dem die replizierten Daten empfangen werden, wird als sekundäres Laufwerk bezeichnet. Die Region, in der das primäre Laufwerk ausgeführt wird, wird als primäre Region bezeichnet. Die Region, in der das sekundäre Laufwerk ausgeführt wird, ist die sekundäre Region. Damit die Replikate aller an jeden SQL Server Knoten angeschlossenen Laufwerke Daten vom selben Zeitpunkt enthalten, werden die Laufwerke einer Konsistenzgruppehinzugefügt. Mit Konsistenzgruppen können Sie DR- und DR-Tests auf mehreren Laufwerken durchführen.
Notfallwiederherstellungsarchitektur
Das folgende Diagramm zeigt für die asynchrone Replikation von Hyperdisk eine minimale Architektur, die die Datenbank-Hochverfügbarkeit in einer primären Region (R1) und die Laufwerkreplikation von der primären Region in die sekundäre Region (R2) unterstützt.
Abbildung 1. Architektur für die Notfallwiederherstellung mit Microsoft SQL Server und asynchroner Replikation von Hyperdisk
Diese Architektur funktioniert so:
- Zwei Instanzen von Microsoft SQL Server (eine primäre Instanz und eine Standby-Instanz) sind Teil eines FCI-Clusters und befinden sich in der primären Region (R1), aber in verschiedenen Zonen (Zonen A und B). Beide Instanzen verwenden ein Hyperdisk Balanced High Availability-Laufwerk gemeinsam, sodass von beiden VMs aus auf die Daten zugegriffen werden kann. Eine Anleitung finden Sie unter SQL Server FCI-Cluster mit Hyperdisk Balanced High Availability im Modus für mehrere Schreiber konfigurieren.
- Die Laufwerke von beiden SQL-Knoten werden Konsistenzgruppen hinzugefügt und in die DR-Region (R2) repliziert. Compute Engine repliziert die Daten asynchron von R1 nach R2.
- Bei der asynchronen Replikation werden nur die Daten auf den Laufwerken nach R2 repliziert, nicht die VM-Metadaten. Während der Notfallwiederherstellung werden neue VMs erstellt und die vorhandenen replizierten Laufwerke an die VMs angehängt, um die Knoten online zu schalten.
Notfallwiederherstellungsprozess
Der DR-Prozess umfasst die operativen Schritte, die Sie ausführen müssen, nachdem eine Region nicht mehr verfügbar ist, um die Arbeitslast in einer anderen Region fortzusetzen. Ein grundlegender DR-Prozess für die Datenbank besteht aus den folgenden Schritten:
- Die erste Region (R1), die die primäre Datenbankinstanz ausführt, fällt aus.
- Das operative Team erkennt und bestätigt offiziell den Notfall und entscheidet, ob ein Failover erforderlich ist.
- Wenn ein Failover erforderlich ist, müssen Sie die Replikation zwischen den primären und sekundären Laufwerken beenden. Aus den Laufwerkreplikaten wird eine neue VM erstellt und online gestellt.
- Die Datenbank in der DR-Region (R2) wird validiert und online geschaltet. Die Datenbank in R2 wird zur neuen primären Datenbank, wodurch die Verbindung ermöglicht wird.
- Nutzer setzen die Verarbeitung in der neuen primären Datenbank fort und greifen auf die primäre Instanz in R2 zu.
Dieser grundlegende Prozess richtet zwar eine funktionierende primäre Datenbank neu ein, doch wird keine vollständige HA-Architektur aufgebaut, da die neue primäre Datenbank nicht repliziert wird.
Abbildung 2. SQL Server-Bereitstellung nach der Notfallwiederherstellung mit asynchroner Replikation nichtflüchtiger Speicher
Fallback zu einer wiederhergestellten Region
Sobald die primäre Region (R1) wieder online ist, können Sie den Failback-Prozess planen und ausführen. Der Failback-Prozess besteht aus allen Schritten, die in dieser Anleitung beschrieben sind. In diesem Fall ist R2 jedoch die Quelle und R1 die Wiederherstellungsregion.
SQL Server-Version auswählen
In dieser Anleitung werden die folgenden Versionen von Microsoft SQL Server unterstützt:
- SQL Server 2016 Enterprise und Standard Edition
- SQL Server 2017 Enterprise und Standard Edition
- SQL Server 2019 Enterprise und Standard Edition
- SQL Server 2022 Enterprise und Standard Edition
In dieser Anleitung wird die SQL Server-Failover-Clusterinstanz mit Hyperdisk Balanced High Availability-Laufwerk verwendet.
Wenn Sie keine SQL Server Enterprise Funktionen benötigen, können Sie die Standard Edition von SQL Server verwenden:
Bei den Versionen 2016, 2017 und 2019 und 2022 von SQL Server ist Microsoft SQL Server Management Studio im Image installiert. Sie müssen das Programm nicht separat installieren. In einer Produktionsumgebung empfehlen wir jedoch, in jeder Region eine Instanz von Microsoft SQL Server Management Studio auf einer separaten VM zu installieren. Wenn Sie eine HA-Umgebung einrichten, sollten Sie Microsoft SQL Server Management Studio für jede Zone einmal installieren. So ist sichergestellt, dass die Instanz auch dann verfügbar bleibt, wenn eine andere Zone ausfällt.
Notfallwiederherstellung für Microsoft SQL Server einrichten
In dieser Anleitung wird das Image sql-ent-2022-win-2022 für Microsoft SQL Server Enterprise verwendet.
Eine vollständige Liste der Images finden Sie unter Betriebssystem-Images.
Hochverfügbarkeits-Cluster mit zwei Instanzen einrichten
Um die Laufwerksreplikation für SQL Server zwischen zwei Regionen einzurichten, müssen Sie zuerst einen HA-Cluster mit zwei Instanzen in einer Region erstellen.
Eine Instanz dient als primäre und die andere als Standby-Instanz. Folgen Sie dazu der Anleitung unter
SQL Server FCI-Cluster mit Hyperdisk Balanced High Availability im Modus für mehrere Schreiber konfigurieren.
In dieser Anleitung wird us-central1 für die primäre Region R1 verwendet.
Wenn Sie die Schritte unter
SQL Server FCI-Cluster mit Hyperdisk Balanced High Availability im Modus für mehrere Schreiber konfigurieren,
ausgeführt haben, haben Sie zwei SQL Server-Instanzen in derselben Region (us-central1) erstellt. Sie haben eine primäre SQL Server-Instanz (node-1) in
us-central1-a und eine Standby-Instanz (node-2) in us-central1-b bereitgestellt.
Asynchrone Laufwerksreplikation aktivieren
Nachdem Sie alle VMs erstellt und konfiguriert haben, aktivieren Sie die Laufwerksreplikation zwischen den beiden Regionen. Führen Sie dazu die folgenden Schritte aus:
Erstellen Sie eine Konsistenzgruppe für beide SQL Server-Knoten und den Knoten, der die Rollen „Zeuge“ und „Domaincontroller“ hostet. Eine der Einschränkungen für Konsistenzgruppen besteht darin, dass sie nicht zonenübergreifend sein können. Daher müssen Sie jeden Knoten einer separaten Konsistenzgruppe hinzufügen.
gcloud compute resource-policies create disk-consistency-group node-1-disk-const-grp \ --region=$REGION gcloud compute resource-policies create disk-consistency-group node-2-disk-const-grp \ --region=$REGION gcloud compute resource-policies create disk-consistency-group witness-disk-const-grp \ --region=$REGION gcloud compute resource-policies create disk-consistency-group multiwriter-disk-const-grp \ --region=$REGION
Fügen Sie die Laufwerke von primären und Standby-VMs den entsprechenden Konsistenzgruppen hinzu.
gcloud compute disks add-resource-policies node-1 \ --zone=$REGION-a \ --resource-policies=node-1-disk-const-grp gcloud compute disks add-resource-policies node-2 \ --zone=$REGION-b \ --resource-policies=node-2-disk-const-grp gcloud compute disks add-resource-policies mw-datadisk-1 \ --region=$REGION \ --resource-policies=multiwriter-disk-const-grp gcloud compute disks add-resource-policies witness \ --zone=$REGION-c \ --resource-policies=witness-disk-const-grp
Erstellen Sie leere sekundäre Laufwerke in der sekundären Region.
DR_REGION="us-west1" gcloud compute disks create node-1-replica \ --zone=$DR_REGION-a \ --size=50 \ --primary-disk=node-1 \ --primary-disk-zone=$REGION-a gcloud compute disks create node-2-replica \ --zone=$DR_REGION-b \ --size=50 \ --primary-disk=node-2 \ --primary-disk-zone=$REGION-b gcloud compute disks create multiwriter-datadisk-1-replica \ --replica-zones=$DR_REGION-a,$DR_REGION-b \ --size=$PD_SIZE \ --type=hyperdisk-balanced-high-availability \ --access-mode READ_WRITE_MANY \ --primary-disk=multiwriter-datadisk-1 \ --primary-disk-region=$REGION gcloud compute disks create witness-replica \ --zone=$DR_REGION-c \ --size=50 \ --primary-disk=witness \ --primary-disk-zone=$REGION-c
Starten Sie die Laufwerksreplikation. Daten werden vom primären Laufwerk auf das neu erstellte leere Laufwerk in der Notfallwiederherstellungs-Region repliziert.
gcloud compute disks start-async-replication node-1 \ --zone=$REGION-a \ --secondary-disk=node-1-replica \ --secondary-disk-zone=$DR_REGION-a gcloud compute disks start-async-replication node-2 \ --zone=$REGION-b \ --secondary-disk=node-2-replica \ --secondary-disk-zone=$DR_REGION-b gcloud compute disks start-async-replication multiwriter-datadisk-1 \ --region=$REGION \ --secondary-disk=multiwriter-datadisk-1-replica \ --secondary-disk-region=$DR_REGION gcloud compute disks start-async-replication witness \ --zone=$REGION-c \ --secondary-disk=witness-replica \ --secondary-disk-zone=$DR_REGION-c
Die Daten sollten jetzt zwischen den Regionen repliziert werden.
Der Replikationsstatus für jedes Laufwerk sollte Active lauten.
Notfallwiederherstellung simulieren
In diesem Abschnitt testen Sie die in dieser Anleitung eingerichtete Notfallwiederherstellungsarchitektur.
Ausfall simulieren und ein Failover zur Notfallwiederherstellung ausführen
Während eines Failovers erstellen Sie neue VMs in der DR-Region und hängen die replizierten Laufwerke an sie an. Zur Vereinfachung des Failovers können Sie eine andere Virtual Private Cloud (VPC) in der DR-Region für die Wiederherstellung verwenden, um dieselbe IP-Adresse zu verwenden.
Bevor Sie mit dem Failover beginnen, prüfen Sie, ob node-1 der primäre Knoten für die von Ihnen erstellte AlwaysOn-Verfügbarkeitsgruppe ist. Rufen Sie den Domaincontroller und den primären SQL Server-Knoten auf, um Probleme bei der Datensynchronisierung zu vermeiden, da die beiden Knoten durch zwei separate Konsistenzgruppen geschützt werden.
So simulieren Sie einen Ausfall:
Erstellen Sie eine VPC für die Wiederherstellung.
DRVPC_NAME="default-dr" DRSUBNET_NAME="default-recovery" gcloud compute networks create $DRVPC_NAME \ --subnet-mode=custom CIDR=$(gcloud compute networks subnets describe default \ --region=$REGION --format=value\(ipCidrRange\)) gcloud compute networks subnets create $DRSUBNET_NAME \ --network=$DRVPC_NAME --range=$CIDR --region=$DR_REGION
Beenden oder stoppen Sie die Datenreplikation.
PROJECT=$(gcloud config get-value project) gcloud compute disks stop-group-async-replication projects/$PROJECT/regions/$REGION/resourcePolicies/node-1-disk-const-grp \ --zone=$REGION-a gcloud compute disks stop-group-async-replication projects/$PROJECT/regions/$REGION/resourcePolicies/node-2-disk-const-grp \ --zone=$REGION-b gcloud compute disks stop-group-async-replication projects/$PROJECT/regions/$REGION/resourcePolicies/multiwriter-disk-const-grp \ --zone=$REGION-c gcloud compute disks stop-group-async-replication projects/$PROJECT/regions/$REGION/resourcePolicies/witness-disk-const-grp \ --zone=$REGION-c
Beenden Sie die Quell-VMs in der primären Region.
gcloud compute instances stop node-1 \ --zone=$REGION-a gcloud compute instances stop node-2 \ --zone=$REGION-b gcloud compute instances stop witness \ --zone=$REGION-c
Benennen Sie die vorhandenen VMs um, um doppelte Namen im Projekt zu vermeiden.
gcloud compute instances set-name witness \ --new-name=witness-old \ --zone=$REGION-c gcloud compute instances set-name node-1 \ --new-name=node-1-old \ --zone=$REGION-a gcloud compute instances set-name node-2 \ --new-name=node-2-old \ --zone=$REGION-b
Erstellen Sie VMs in der DR-Region mit den sekundären Laufwerken. Diese VMs haben die IP-Adresse der Quell-VM.
NODE1IP=$(gcloud compute instances describe node-1-old --zone $REGION-a --format=value\(networkInterfaces[0].networkIP\)) NODE2IP=$(gcloud compute instances describe node-2-old --zone $REGION-b --format=value\(networkInterfaces[0].networkIP\)) WITNESSIP=$(gcloud compute instances describe witness-old --zone $REGION-c --format=value\(networkInterfaces[0].networkIP\)) gcloud compute instances create node-1 \ --zone=$DR_REGION-a \ --machine-type $MACHINE_TYPE \ --network=$DRVPC_NAME \ --subnet=$DRSUBNET_NAME \ --private-network-ip $NODE1IP\ --disk=boot=yes,device-name=node-1-replica,mode=rw,name=node-1-replica \ --disk=boot=no,device-name=mw-datadisk-1-replica,mode=rw,name=mw-datadisk-1-replica,scope=regional gcloud compute instances create witness \ --zone=$DR_REGION-c \ --machine-type=n2-standard-2 \ --network=$DRVPC_NAME \ --subnet=$DRSUBNET_NAME \ --private-network-ip $WITNESSIP \ --disk=boot=yes,device-name=witness-replica,mode=rw,name=witness-replica gcloud compute instances create node-2 \ --zone=$DR_REGION-b \ --machine-type $MACHINE_TYPE \ --network=$DRVPC_NAME \ --subnet=$DRSUBNET_NAME \ --private-network-ip $NODE2IP\ --disk=boot=yes,device-name=node-2-replica,mode=rw,name=node-2-replica \ --disk=boot=no,device-name=mw-datadisk-1-replica,mode=rw,name=mw-datadisk-1-replica,scope=regional
Sie haben einen Ausfall simuliert und ein Failover zur DR-Region ausgeführt. Jetzt können Sie testen, ob die sekundäre Instanz ordnungsgemäß funktioniert.
SQL Server-Verbindung prüfen
Nachdem Sie die VMs erstellt haben, prüfen Sie, ob die Datenbanken erfolgreich wiederhergestellt wurden und der Server wie erwartet funktioniert. Führen Sie zum Testen der Datenbank eine Abfrage aus der wiederhergestellten Datenbank aus.
- Stellen Sie über Remote Desktop eine Verbindung zur SQL Server-VM her.
- Öffnen Sie SQL Server Management Studio.
- Prüfen Sie im Dialogfeld Mit Server verbinden, ob der Servername auf
node-1festgelegt ist, und wählen Sie Verbinden aus. Wählen Sie im Menü „Datei“ die Option Datei > Neu > Abfrage mit der aktuellen Verbindung aus.
USE [bookshelf]; SELECT * FROM Books;
Bereinigen
Mit den folgenden Schritten vermeiden Sie, dass Ihrem Google Cloud -Konto die in dieser Anleitung verwendeten Ressourcen in Rechnung gestellt werden. Löschen Sie dazu die von Ihnen erstellten Ressourcen .
Projekt löschen
- Wechseln Sie in der Google Cloud -Console 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.
Nächste Schritte
- Referenzarchitekturen, Diagramme und Best Practices zu Google Cloud kennenlernen. Weitere Informationen zu Cloud Architecture Center