Questo tutorial descrive come abilitare la replica asincrona del disco permanente (replica PD asincrona) in due regioni Google Cloud come ripristino di emergenza (RE) e su come attivare le istanze RE in caso di emergenza. Ai fini di questo documento, un disastro è un evento in cui un cluster ad alta disponibilità (HA) del database principale si arresta in modo anomalo o diventa non disponibile. Un database principale può avere esito negativo quando la regione in cui è posizionato non funziona o diventa inaccessibili.
Questo tutorial è rivolto ad architetti, amministratori e progettisti di database.
Obiettivi
- Abilita la replica asincrona del Persistent Disk per tutti Nodi del cluster del gruppo di disponibilità AlwaysOn di SQL Server in esecuzione su Google Cloud.
- Simula un evento di emergenza ed esegui un processo completo di ripristino di emergenza per convalidare la relativa configurazione.
Costi
In questo documento utilizzi i seguenti componenti fatturabili di Google Cloud:
Per generare una stima dei costi basata sull'utilizzo previsto,
utilizza il Calcolatore prezzi.
Al termine delle attività descritte in questo documento, puoi evitare la fatturazione continua eliminando le risorse che hai creato. Per ulteriori informazioni, consulta la sezione Pulizia.
Prima di iniziare
Per questo tutorial, hai bisogno di un progetto Google Cloud. Puoi crearne uno nuovo o selezionare un progetto che hai già creato:
-
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.
Ripristino di emergenza in Google Cloud
In Google Cloud, il RE mira a garantire la continuità dell'elaborazione, in particolare quando una regione non funziona o diventa inaccessibile. Esistono più opzioni di implementazione per il sito di RE e saranno dettato dal Recovery Point Objective (RPO) e dal Recovery Time Objective (RTO). Il tutorial illustra una delle opzioni in cui i dischi delle macchine virtuali (VM) vengono replicati dall'istanza principale regione.
Ripristino di emergenza per la replica asincrona dei dischi permanenti
La replica asincrona del disco permanente (PD Async Replication) fornisce basso RPO e RTO replica dell'archiviazione a blocchi per più regioni RE attiva-passiva.
La replica asincrona PD è un'opzione di archiviazione che fornisce la replica dei dati tra due regioni. Nell'improbabile caso in cui un'interruzione del servizio, la replica asincrona PD ti consente di eseguire il failover dei dati regione e riavvia i carichi di lavoro in quella regione.
La replica asincrona del disco permanente replica i dati da un disco collegato a un carico di lavoro in esecuzione, noto come disco principale, a un disco distinto situato in un'altra regione. Il disco che riceve i dati replicati è definito come disco secondario.
per assicurarti che le repliche di tutti i dischi collegati a ogni server SQL contengono dati dello stesso momento, i dischi vengono aggiunti gruppo di coerenza. I gruppi di coerenza ti consentono di eseguire test di DR e RP su più dischi.
Architettura per il ripristino di emergenza
Per la replica asincrona PD, il seguente diagramma mostra un'architettura minima che supporti l'alta disponibilità del database in una regione principale e la replica del disco come regione principale alla regione RE.
Figura 1. Architettura di ripristino di emergenza con Microsoft SQL Server e Replica asincrona DP
Questa architettura funziona nel seguente modo:
- Due istanze di Microsoft SQL Server, un'istanza principale e un'istanza di standby, fanno parte di un gruppo di disponibilità e si trovano nella stessa regione (R1), ma in zone diverse (zone A e B). Le due istanze in R1 coordinano i loro stati usando la modalità di commit sincrono. L'architettura sincrona viene utilizzata perché supporta l'alta disponibilità e mantiene coerente nello stato dei dati.
- I dischi di entrambi i nodi SQL vengono aggiunti ai gruppi di coerenza e replicati la regione RE R2. I dati vengono replicati in modo asincrono dall'elemento dell'infrastruttura.
- Solo i dischi vengono replicati nella regione R2. Durante il ripristino di emergenza, vengono create nuove VM e i dischi replicati esistenti sono collegati alle VM per dei nodi online.
Procedura di ripristino di emergenza
Il processo di RE viene avviato quando una regione non è più disponibile. RE del processo descrive i passaggi operativi da intraprendere, manualmente o automaticamente, per mitigare l'errore della regione e stabilire in una regione disponibile.
Un processo di RE di base del database prevede i seguenti passaggi:
- La prima regione (R1), che esegue l'istanza del database principale, diventa non disponibile.
- Il team operativo riconosce e conferma formalmente la catastrofe e decide se è necessario un failover.
- Se è necessario un failover, la replica dei dischi dalla regione principale a quella di DR viene interrotta. Dalle repliche del disco viene creata una nuova VM, che viene trasferita online.
- Il nuovo database primario nella regione RE (R2) è stato convalidato e trasferito abilitare la connettività online.
- Gli utenti riprendono l'elaborazione nel nuovo database principale e accedono all'istanza principale in R2.
Sebbene questa procedura di base restabilisca un database principale funzionante, non consente di creare un'architettura HA completa, in cui il nuovo database principale ha un nodo di riserva.
Figura 2. Deployment di SQL Server dopo il ripristino di emergenza con replica asincrona del disco permanente
Ripristino di una regione recuperata
Quando la regione principale (R1) viene riportata online, puoi pianificare ed eseguire il processo di fail-back. La procedura di failover consiste in tutti i passaggi descritti In questo caso, R2 è l'origine e R1 è il ripristino. regione.
Scegli una versione di SQL Server
Questo tutorial supporta le seguenti versioni di Microsoft SQL Server:
- SQL Server 2016 Enterprise Edition
- SQL Server 2017 Enterprise Edition
- SQL Server 2019 Enterprise Edition
- SQL Server 2022 Enterprise Edition
Il tutorial utilizza la funzionalità dei gruppi di disponibilità AlwaysOn in SQL Server.
Se non hai bisogno di un database Microsoft SQL Server ad alta disponibilità ed è sufficiente un'unica istanza di database come primario, puoi utilizzare le seguenti versioni di SQL Server:
- SQL Server 2016 Standard Edition
- SQL Server 2017 Standard Edition
- SQL Server 2019 Standard Edition
- SQL Server 2022 Standard Edition
Le versioni 2016, 2017, 2019 e 2022 di SQL Server hanno Microsoft SQL Server Management Studio installato nell'immagine; non è necessario installarlo separatamente. Tuttavia, in un ambiente di produzione, ti consigliamo di installare una istanza di Microsoft SQL Server Management Studio su una VM separata in ogni regione. Se configuri un ambiente ad alta disponibilità, devi installare Microsoft SQL Server Management Studio una volta per ciascuna zona per garantire che rimanga disponibile se un'altra zona diventa non disponibile.
Configura il ripristino di emergenza per Microsoft SQL Server
Questo tutorial utilizza l'immagine sql-ent-2022-win-2022 per Microsoft SQL Server
Aziende.
Per un elenco completo delle immagini, consulta Immagini del sistema operativo.
Configura un cluster a due istanze ad alta disponibilità
Per configurare la replica dei dischi nella regione di DR per SQL Server, innanzitutto
crea un cluster HA a due istanze in una regione.
Un'istanza funge da principale e l'altra da
in standby. Per completare questo passaggio, segui le istruzioni riportate in
Configurazione dei gruppi di disponibilità AlwaysOn di SQL Server.
Questo tutorial utilizza us-central1 per la regione principale (indicata come R1).
Se hai seguito la procedura
Configurazione dei gruppi di disponibilità AlwaysOn di SQL Server,
avrai creato due istanze SQL Server nella stessa regione (us-central1). Devi aver eseguito il deployment di un'istanza SQL Server principale (node-1) in
us-central1-a e un'istanza in standby (node-2) in us-central1-b.
Attivare la replica asincrona dei dischi
Dopo aver creato e configurato tutte le VM, abilita la copia su disco tra regioni creando un gruppo di coerenza per tutti i dischi collegati alle VM. I dati vengono copiati dai dischi di origine ai dischi vuoti appena creati nella regione designata.
Crea un gruppo di coerenza sia per i nodi SQL sia per il controller di dominio. Uno dei limiti di un disco zonale è che i gruppi di coerenza non possono estendersi su più zone.
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
Aggiungi i dischi delle VM principali e di standby ai gruppi con coerenza corrispondenti.
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
Crea dischi secondari vuoti nella regione accoppiata
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
Avvia la replica del disco. I dati vengono replicati dal disco primario al nuovo ha creato un disco vuoto nella regione di RE.
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
A questo punto, i dati dovrebbero essere in fase di replica tra le regioni.
Lo stato di replica di ogni disco dovrebbe essere Active.
Simula un ripristino di emergenza
In questa sezione, testerai l'architettura di disaster recovery configurata in questo tutorial.
Simula un'interruzione ed esegui un failover per ripristino di emergenza
Durante un failover di RE, crei nuove VM nella regione di RE e colleghi replicati. Per semplificare il failover, puoi utilizzare un'altra istanza Virtual Private Cloud (VPC) nella regione RE per il recupero, in modo da utilizzare lo stesso indirizzo IP.
Prima di avviare il failover, assicurati che node-1 sia il nodo principale per l'istanza
Gruppo di disponibilità AlwaysOn creato. Visualizza il controller di dominio e
principale per evitare problemi di sincronizzazione dei dati,
i due nodi sono protetti da due gruppi di coerenza separati.
Per simulare un'interruzione, segui questi passaggi:
Crea una VPC di ripristino.
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
Termina replica dei dati.
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
Arresta le VM di origine nella regione principale.
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
Creare VM nella regione RE utilizzando repliche di dischi. Queste VM avranno l'indirizzo IP della VM di origine.
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
Abbiamo simulato un'interruzione e abbiamo eseguito il failover nella regione di DR. Ora possiamo verificare se l'istanza secondaria funziona correttamente.
Verifica la connettività di SQL Server
Dopo aver creato le VM, verifica che i database siano stati recuperati correttamente e il server funziona come previsto. Per testare il database, esegui una query di selezione dal database recuperato.
- Connettiti alla VM SQL Server utilizzando Remote Desktop.
- Apri SQL Server Management Studio.
- Nella finestra di dialogo Connettiti al server, verifica che il nome del server sia impostato su
NODE-1e seleziona Connetti. Nel menu File, seleziona File > Nuovo > Query con la connessione corrente.
USE [bookshelf]; SELECT * FROM Books;
Esegui la pulizia
Per evitare che al tuo account Google Cloud vengano addebitati costi relativi alle risorse usati in questo tutorial:
Elimina il progetto
- 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.
Passaggi successivi
- Esplora le architetture di riferimento, i diagrammi e le best practice su Google Cloud. Dai un'occhiata al nostro Centro architetture cloud.