Questo tutorial descrive come attivare la replica asincrona del disco permanente (PD Async Replication) in due Google Cloud regioni come soluzione di disaster recovery (DR) e come avviare le istanze DR in caso di disastro. Ai fini di questo documento, un disastro è un evento in cui un cluster ad alta affidabilità (HA) del database principale si arresta in modo anomalo o diventa non disponibile. Un database primario può non funzionare quando la regione in cui si trova non funziona o diventa inaccessibile.
Questo tutorial è rivolto ad architetti, amministratori e database engineer.
Obiettivi
- Attiva la replica asincrona dei dischi permanenti per tutti i 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 disaster recovery per convalidare la configurazione di questo tipo di ripristino.
Costi
In questo documento utilizzi i seguenti componenti fatturabili di Google Cloud:
Per generare una stima dei costi in base all'utilizzo previsto,
utilizza il calcolatore prezzi.
Al termine delle attività descritte in questo documento, puoi evitare l'addebito di ulteriori costi eliminando le risorse che hai creato. Per ulteriori informazioni, vedi Pulizia.
Prima di iniziare
Per questo tutorial, è necessario un progetto Google Cloud . Puoi crearne uno nuovo o selezionarne uno già esistente:
-
In the Google Cloud console, on the project selector page, select or create a Google Cloud project.
-
Verify that billing is enabled for your Google Cloud project.
-
In the Google Cloud console, activate Cloud Shell.
Disaster recovery in Google Cloud
In Google Cloud, il DR è un processo che garantisce la continuità dell'elaborazione, in particolare quando una regione non funziona o diventa inaccessibile. Esistono diverse opzioni di implementazione per il sito di DR e queste saranno determinate dai requisiti del Recovery Point Objective (RPO) e del Recovery Time Objective (RTO). Questo tutorial illustra una delle opzioni in cui i dischi delle macchine virtuali (VM) vengono replicati dalla regione principale a quella di DR.
Disaster recovery per la replica asincrona dei dischi permanenti
La replica asincrona del disco permanente (PD Async Replication) fornisce una replica dell'archiviazione a blocchi con RPO e RTO bassi per il DR attivo-passivo tra regioni
PD Async Replication è un'opzione di archiviazione che fornisce la replica asincrona dei dati tra due regioni. Nell'improbabile caso di un'interruzione in una regione, PD Async Replication consente di eseguire il failover dei dati in una regione secondaria e di riavviare i workload in quella regione.
PD Async Replication replica i dati da un disco collegato a un workload 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 garantire che le repliche di tutti i dischi collegati a ogni nodo SQL Server contengano i dati dello stesso istante, i dischi vengono aggiunti a un gruppo di coerenza. I gruppi di coerenza ti consentono di eseguire test di DR e DR su più dischi.
Architettura del disaster recovery
Per la replica asincrona del disco permanente, il seguente diagramma mostra un'architettura minima che supporta l'alta affidabilità del database in una regione principale e la replica del disco dalla regione principale alla regione di DR.
Figura 1. Architettura di disaster recovery con Microsoft SQL Server e PD Async Replication
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 utilizzando la modalità commit sincrono. La modalità sincrona viene utilizzata perché supporta un'elevata affidabilità e mantiene uno stato dei dati coerente.
- I dischi di entrambi i nodi SQL vengono aggiunti ai gruppi di coerenza e replicati nella regione di DR R2. I dati vengono replicati in modo asincrono dall'infrastruttura di base.
- Solo i dischi vengono replicati nella regione R2. Durante il DR, vengono create nuove VM e i dischi replicati esistenti vengono collegati alle VM per mettere online i nodi.
Procedura di disaster recovery
Il processo di DR inizia quando una regione non è più disponibile. Il processo di DR definisce i passaggi operativi da seguire, manualmente o automaticamente, per mitigare l'errore della regione e stabilire un'istanza primaria in esecuzione in una regione disponibile.
Un processo di base di DR del database prevede i seguenti passaggi:
- La prima regione (R1), in cui è in esecuzione l'istanza del database primaria, diventa non disponibile.
- Il team operativo riconosce e conferma formalmente l'emergenza e decide se è necessario eseguire un failover.
- Se è necessario un failover, la replica dei dischi dalla regione principale a quella di DR viene interrotta. Viene creata una nuova VM dalle repliche del disco e messa online.
- Il nuovo database principale nella regione di DR (R2) viene convalidato e messo online per abilitare la connettività.
- Gli utenti riprendono l'elaborazione nel nuovo database primario e accedono all'istanza primaria in R2.
Sebbene questo processo di base ristabilisca un database principale funzionante, non consente di creare un'architettura ad alta affidabilità completa, in cui il nuovo database principale disponga di un nodo di riserva.
Figura 2. Deployment di SQL Server dopo il disaster recovery con la replica asincrona dei dischi permanenti
Ripristino di una regione recuperata
Quando la regione principale (R1) viene ripristinata online, puoi pianificare ed eseguire il processo di failback. La procedura di failback è composta da tutti i passaggi descritti in questo tutorial, ma in questo caso R2 è la regione di origine e R1 è la regione di recupero.
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 principale Microsoft SQL Server ad alta affidabilità e una singola istanza di database è sufficiente come istanza primaria, 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 sono dotate di Microsoft SQL Server Management Studio installato nell'immagine; non devi quindi installare il programma separatamente. Tuttavia, in un ambiente di produzione, ti consigliamo di installare un'istanza di Microsoft SQL Server Management Studio su una VM separata in ogni regione. Se configuri un ambiente ad alta affidabilità, devi installare Microsoft SQL Server Management Studio una volta per ciascuna zona per assicurarti che rimanga disponibile laddove una zona non fosse più accessibile.
Configura il disaster recovery per Microsoft SQL Server
Questo tutorial utilizza l'immagine sql-ent-2022-win-2022 per Microsoft SQL Server
Enterprise.
Per un elenco completo delle immagini, consulta Immagini sistema operativo.
Configura un cluster ad alta affidabilità con due istanze
Per configurare la replica dei dischi nella regione di DR per SQL Server, innanzitutto
crea un cluster ad alta affidabilità a due istanze in una regione.
Un'istanza
fungerà da istanza principale e l'altra da istanza 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 primaria (indicata come R1).
Se hai seguito i passaggi descritti in
Configurazione dei gruppi di disponibilità AlwaysOn di SQL Server,
avrai creato due istanze SQL Server nella stessa regione (us-central1) e avrai eseguito il deployment di un'istanza SQL Server principale (node-1) in
us-central1-a e di un'istanza in standby (node-2) in us-central1-b.
Attiva la replica asincrona dei dischi
Dopo aver creato e configurato tutte le VM, attiva la copia dei dischi tra le regioni creando un gruppo di coerenza per tutti i dischi collegati alle VM. I dati vengono copiati dai dischi di origine ai nuovi dischi vuoti appena creati nella regione designata.
Crea un gruppo di coerenza sia per i nodi SQL sia per il domain controller. Uno dei limiti di un disco zonale è che i gruppi di coerenza non possono estendersi a 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 di 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 principale al disco vuoto appena creato nella regione di DR.
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 della replica per ogni disco dovrebbe essere Active.
Simula un disaster recovery
In questa sezione, testerai l'architettura di disaster recovery configurata in questo tutorial.
Simula un'interruzione del servizio ed esegui un failover di disaster recovery
Durante un failover di DR, crei nuove VM nella regione di DR e colleghi i dischi replicati. Per semplificare il failover, puoi utilizzare un altro Virtual Private Cloud (VPC) nella regione di ripristino 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 il
gruppo di disponibilità AlwaysOn che hai creato. Avvia il domain controller e il
nodo SQL Server principale per evitare problemi di sincronizzazione dei dati, poiché
i due nodi sono protetti da due gruppi di coerenza distinti.
Per simulare un'interruzione, segui questi passaggi:
Crea una VPC di recupero.
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 la 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
Crea le VM nella regione di DR utilizzando le repliche dei 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 che il server funzioni 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 attuale.
USE [bookshelf]; SELECT * FROM Books;
Esegui la pulizia
Per evitare che al tuo account Google Cloud vengano addebitati costi relativi alle risorse utilizzate 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 architetture di riferimento, diagrammi e best practice su Google Cloud. Consulta il nostro Cloud Architecture Center.