In dieser Anleitung wird beschrieben, wie Sie die asynchrone Replikation von nichtflüchtigem Speicher (Persistent Disk Async Replication, PD Async Replication) in zwei Google Cloud-Regionen als Notfallwiederherstellungslösung aktivieren und wie Sie die Notfallwiederherstellungsinstanzen bei einem Notfall starten. Im Rahmen dieses Dokuments ist ein Notfall ein Ereignis, bei dem ein primärer Hochverfügbarkeitscluster (HA) einer 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.
Diese Anleitung richtet sich an Datenbankarchitekten, Administratoren und Entwickler.
Lernziele
- Aktivieren Sie die asynchrone Replikation von nichtflüchtigem Speicher für alle Clusterknoten der SQL Server AlwaysOn-Verfügbarkeitsgruppe, die in Google Cloud ausgeführt werden.
- Simulieren Sie ein Notfallereignis und führen Sie einen vollständigen Notfallwiederherstellungsprozess aus, um die Konfiguration der Notfallwiederherstellung 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.
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.
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:
-
In the Google Cloud console, on the project selector page, select or create a Google Cloud project.
-
Make sure that billing is enabled for your Google Cloud project.
-
In the Google Cloud console, activate Cloud Shell.
Notfallwiederherstellung in Google Cloud
Bei Google Cloud ist die Notfallwiederherstellung darauf ausgerichtet, die Kontinuität der Verarbeitung zu gewährleisten, insbesondere wenn eine Region ausfällt bzw. unzugänglich wird. Es gibt mehrere Bereitstellungsoptionen für den Notfallwiederherstellungsstandort, die sich nach den Anforderungen an das Recovery Point Objective (RPO) und das Recovery Time Objective (RTO) richten. In dieser Anleitung wird eine der Optionen behandelt, bei denen VM-Laufwerke von der primären Region in die DR-Region repliziert werden.
Notfallwiederherstellung für die asynchrone Replikation nichtflüchtiger Speicher
Die asynchrone Replikation nichtflüchtiger Speicher (Persistent Disk Async Replication, PD Async Replication) bietet eine Blockspeicherreplikation mit niedrigem RPO und RTO für die regionenübergreifende Aktiv-Passiv-Notfallwiederherstellung.
PD Async Replication ist eine Speicheroption, die eine asynchrone Replikation von Daten zwischen zwei Regionen bietet. Im unwahrscheinlichen Fall eines regionalen Ausfalls können Sie mit PD Async Replication für Ihre Daten ein Failover in einer sekundäre Region durchführen und Ihre Arbeitslasten in dieser Region neu starten.
Die PD Async Replication repliziert Daten von einem Laufwerk, das an eine laufende Arbeitslast angehängt ist (das primäre Laufwerk), auf ein separates Laufwerk in einer anderen Region. Das Laufwerk, das replizierte Daten empfängt, wird als sekundäres Laufwerk bezeichnet.
Damit die Replikate aller an jeden SQL Server-Knoten angeschlossenen Laufwerke Daten vom selben Zeitpunkt enthalten, werden die Laufwerke einer Konsistenzgruppe hinzugefügt. Mit Konsistenzgruppen können Sie Notfallwiederherstellungen und Notfallwiederherstellungstests auf mehreren Laufwerken ausführen.
Notfallwiederherstellungsarchitektur
Das folgende Diagramm zeigt für die asynchrone Replikation nichtflüchtiger Speicher eine minimale Architektur, die die Datenbank-Hochverfügbarkeit in einer primären Region und die Laufwerkreplikation von der primären Region in die Notfallwiederherstellungs-Region unterstützt.
Abbildung 1. Architektur für die Notfallwiederherstellung mit Microsoft SQL Server und asynchroner Replikation nichtflüchtiger Speicher
Diese Architektur funktioniert so:
- Zwei Instanzen von Microsoft SQL Server, eine primäre Instanz und eine Standby-Instanz, sind Teil einer Verfügbarkeitsgruppe und befinden sich in derselben Region (R1), aber in verschiedenen Zonen (Zonen A und B). Die beiden Instanzen in R1 koordinieren ihren Zustand mit dem synchronen Commit-Modus. Der synchrone Modus wird verwendet, da er Hochverfügbarkeit unterstützt und einen konsistenten Datenzustand beibehält.
- Laufwerke von beiden SQL-Knoten werden Konsistenzgruppen hinzugefügt und in die Notfallwiederherstellungsregion R2 repliziert. Die Daten werden von der zugrunde liegenden Infrastruktur asynchron repliziert.
- Nur Laufwerke werden in die Region R2 repliziert. Bei der Notfallwiederherstellung werden neue VMs erstellt und die vorhandenen replizierten Laufwerke werden an die VMs angehängt, um die Knoten online zu stellen.
Notfallwiederherstellungsprozess
Der Notfallwiederherstellungsprozess wird gestartet, wenn eine Region nicht mehr verfügbar ist. Der DR-Prozess schreibt die erforderlichen Betriebsschritte vor, die entweder manuell oder automatisch ausgeführt werden müssen, um dem Ausfall einer Region entgegenzuwirken und eine ausgeführte primäre Instanz in einer verfügbaren Region einzurichten.
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, wird die Laufwerkreplikation von der primären in die Notfallwiederherstellungsregion beendet. Aus den Laufwerkreplikaten wird eine neue VM erstellt und online gestellt.
- Die neue primäre Datenbank in der DR-Region (R2) wird validiert und online gestellt, um die Verbindung zu ermöglichen.
- 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, in der die neue primäre Datenbank einen Standby-Knoten hat.
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 umfasst alle in dieser Anleitung beschriebenen Schritte. In diesem Fall ist R2 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 Edition
- SQL Server 2017 Enterprise Edition
- SQL Server 2019 Enterprise Edition
- SQL Server Enterprise Edition 2022
In dieser Anleitung wird die Option "AlwaysOn Verfügbarkeitsgruppen" in SQL Server verwendet.
Wenn Sie keine primäre Microsoft SQL Server-Datenbank mit Hochverfügbarkeit (High Availability, HA) benötigen und eine einzelne Datenbankinstanz als primäre Datenbankdatenbank erforderlich ist, können Sie die folgenden SQL Server-Versionen verwenden:
- SQL Server 2016 Standard Edition
- SQL Server 2017 Standard Edition
- SQL Server 2019 Standard Edition
- SQL Server Standard Edition 2022
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 sql-ent-2022-win-2022-Image 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
Erstellen Sie zuerst einen Hochverfügbarkeits-Cluster mit zwei Instanzen in einer Region, um die Laufwerksreplikation für eine Region zur Notfallwiederherstellung für SQL Server einzurichten.
Eine Instanz dient als primäre und die andere als Standby-Instanz. Folgen Sie der Anleitung unter Always On-Verfügbarkeitsgruppen von SQL Server konfigurieren, um diesen Schritt auszuführen.
In dieser Anleitung wird us-central1 für die primäre Region (mit der Bezeichnung R1) verwendet.
Wenn Sie die Schritte unter SQL Server Always On-Verfügbarkeitsgruppen 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 alle VMs erstellt und konfiguriert wurden, aktivieren Sie die Laufwerkskopien zwischen Regionen, indem Sie eine Konsistenzgruppe für alle an die VMs angeschlossenen Laufwerke erstellen. Die Daten werden von den Quelllaufwerken auf neu erstellte leere Laufwerke in der angegebenen Region kopiert.
Erstellen Sie eine Konsistenzgruppe für beide SQL-Knoten und den Domaincontroller. Eine der Einschränkungen für zonale Laufwerke besteht darin, dass Konsistenzgruppen nicht mehrere Zonen umfassen können.
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
Fügen Sie die Laufwerke der 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-1-datadisk \ --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 node-2-datadisk \ --zone=$REGION-b \ --resource-policies=node-2-disk-const-grp gcloud compute disks add-resource-policies witness \ --zone=$REGION-c \ --resource-policies=witness-disk-const-grp
Leere sekundäre Laufwerke in der gekoppelten Region erstellen
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-1-datadisk-replica \ --zone=$DR_REGION-a \ --size=$PD_SIZE \ --primary-disk=node-1-datadisk \ --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 node-2-datadisk-replica \ --zone=$DR_REGION-b \ --size=$PD_SIZE \ --primary-disk=node-2-datadisk \ --primary-disk-zone=$REGION-b gcloud compute disks create witness-replica \ --zone=$DR_REGION-c \ --size=50 \ --primary-disk=witness \ --primary-disk-zone=$REGION-c
Starten Sie die Laufwerkreplikation. 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-1-datadisk \ --zone=$REGION-a \ --secondary-disk=node-1-datadisk-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 node-2-datadisk \ --zone=$REGION-b \ --secondary-disk=node-2-datadisk-replica \ --secondary-disk-zone=$DR_REGION-b 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 sein.
Notfallwiederherstellung simulieren
In diesem Abschnitt testen Sie die in dieser Anleitung eingerichtete Notfallwiederherstellungsarchitektur.
Ausfall simulieren und ein Notfallwiederherstellungs-Failover ausführen
Bei einem Notfallwiederherstellungs-Failover erstellen Sie neue VMs in der Notfallwiederherstellungsregion und hängen die replizierten Laufwerke an diese an. Zur Vereinfachung des Failovers können Sie eine andere Virtual Private Cloud (VPC) in der Notfallwiederherstellungsregion für die Wiederherstellung verwenden, um dieselbe IP-Adresse zu verwenden.
Achten Sie vor dem Starten des Failovers darauf, dass 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 Wiederherstellungs-VPC.
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 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/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
Erstellen Sie VMs in der Notfallwiederherstellungsregion mit Laufwerkreplikaten. Diese VMs haben die IP-Adresse der Quell-VM.
NODE1IP=$(gcloud compute instances describe node-1 --zone $REGION-a --format=value\(networkInterfaces[0].networkIP\)) NODE2IP=$(gcloud compute instances describe node-2 --zone $REGION-a --format=value\(networkInterfaces[0].networkIP\)) WITNESSIP=$(gcloud compute instances describe witness --zone $REGION-a --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=auto-delete=yes,boot=no,device-name=node-1-datadisk-replica,mode=rw,name=node-1-datadisk-replica 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
Wir haben einen Ausfall simuliert und eine Failover auf die DR-Region ausgeführt. Jetzt können wir testen, ob die sekundäre Instanz ordnungsgemäß funktioniert.
SQL Server-Verbindung prüfen
Prüfen Sie nach dem Erstellen der VMs, ob die Datenbanken erfolgreich wiederhergestellt wurden und der Server wie erwartet funktioniert. Zum Testen der Datenbank führen Sie eine Auswahlabfrage aus der wiederhergestellten Datenbank aus.
- Stellen Sie mithilfe von 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 Dateimenü Datei > Neu > Abfrage mit der aktuellen Verbindung aus.
USE [bookshelf]; SELECT * FROM Books;
Bereinigen
So vermeiden Sie, dass Ihrem Google Cloud-Konto die in dieser Anleitung verwendeten Ressourcen in Rechnung gestellt werden:
Projekt löschen
- In the Google Cloud console, go to the Manage resources page.
- In the project list, select the project that you want to delete, and then click Delete.
- In the dialog, type the project ID, and then click Shut down to delete the project.
Nächste Schritte
- Referenzarchitekturen, Diagramme und Best Practices zu Google Cloud kennenlernen. Weitere Informationen zu Cloud Architecture Center