Configura il ripristino di emergenza per Microsoft SQL Server con un PD asincrono


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 disponibilità (HA) del database principale si arresta in modo anomalo o diventa non disponibile. Un database principale può non funzionare quando la regione in cui si trova non funziona o diventa inaccessibile.

Questo tutorial è rivolto ad architetti, amministratori e progettisti di database.

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 ripristino di emergenza per convalidare la configurazione.

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. I nuovi Google Cloud utenti potrebbero avere diritto a una prova gratuita.

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:

  1. In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

    Go to project selector

  2. Make sure that billing is enabled for your Google Cloud project.

  3. In the Google Cloud console, activate Cloud Shell.

    Activate Cloud Shell

Disaster recovery in Google Cloud

In Google Cloud, il DR si occupa di garantire la continuità dell'elaborazione, soprattutto quando una regione non funziona o diventa inaccessibile. Esistono diverse opzioni di implementazione per il sito di RE e queste saranno determinate dai requisiti del punto di ripristino (RPO) e del tempo di ripristino (RTO). Questo tutorial illustra una delle opzioni in cui i dischi delle macchine virtuali (VM) vengono replicati dalla regione principale a quella di DR.

Ripristino di emergenza 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 RE attivo-passivo tra regioni.

La replica asincrona del disco permanente è un'opzione di archiviazione che fornisce la replica asincrona dei dati tra due regioni. Nell'improbabile caso di un'interruzione in una regione, la replica asincrona del disco permanente consente di eseguire il failover dei dati in una regione secondaria e di riavviare i workload in quella regione.

La replica asincrona dei dischi permanenti 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 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 RP su più dischi.

Architettura di disaster recovery

Per la replica asincrona del disco permanente, il seguente diagramma mostra un'architettura minima che supporta l'alta disponibilità del database in una regione principale e la replica del disco dalla regione principale alla regione di RE.

Le istanze principali e in standby si trovano in due zone della regione R1, mentre i dischi sottostanti vengono replicati utilizzando la replica asincrona nella regione R2.

Figura 1. Architettura di ripristino di emergenza con Microsoft SQL Server e la replica asincrona di PD

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à di commit sincrono. La modalità sincrona viene utilizzata perché supporta l'alta disponibilità 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 piano di ripristino dei dati, 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. La procedura di DR prescribe i passaggi operativi da seguire, manualmente o automaticamente, per mitigare l'errore della regione e stabilire un'istanza principale in esecuzione in una regione disponibile.

Una procedura di DR di base del database prevede i seguenti passaggi:

  1. La prima regione (R1), in cui è in esecuzione l'istanza del database principale, diventa non disponibile.
  2. Il team operativo riconosce e conferma formalmente la catastrofe e decide se è necessario un failover.
  3. 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.
  4. Il nuovo database principale nella regione di DR (R2) viene convalidato e messo online per abilitare la connettività.
  5. Gli utenti riprendono l'elaborazione nel nuovo database principale e accedono all'istanza principale in R2.

Sebbene questa procedura di base ristabilisca un database principale funzionante, non consente di creare un'architettura HA completa, in cui il nuovo database principale ha un nodo di riserva.

Le istanze principali e in standby si trovano in due zone della regione R1, mentre i dischi sottostanti vengono replicati utilizzando la replica asincrona nella regione R2.

Figura 2. Deployment di SQL Server dopo il ripristino di emergenza 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 disponibilità e una singola istanza di database è sufficiente come principale, 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 HA, devi installare Microsoft SQL Server Management Studio una volta per ogni zona per assicurarti che rimanga disponibile se un'altra zona diventa non disponibile.

Configurare il ripristino di emergenza 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 del sistema operativo.

Configurare un cluster ad alta disponibilità con due istanze

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 i passaggi descritti in Configurazione dei gruppi di disponibilità AlwaysOn di SQL Server, avrai creato due istanze SQL Server nella stessa regione (us-central1). Avrai eseguito il deployment di un'istanza SQL Server principale (node-1) in us-central1-a e di un'istanza di standby (node-2) in us-central1-b.

Attivare 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 dischi vuoti appena creati nella regione designata.

  1. 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 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
    
  2. 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
    
  3. 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
    
  4. 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 ripristino di emergenza

In questa sezione, testerai l'architettura di disaster recovery configurata in questo tutorial.

Simula un'interruzione del servizio ed esegui un failover di ripristino di emergenza

Durante un failover di DR, crei nuove VM nella regione di DR e vi 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 controller di dominio 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:

  1. 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
    
  2. 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
    
  3. 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
    
  4. 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.

  1. Connettiti alla VM SQL Server utilizzando Remote Desktop.
  2. Apri SQL Server Management Studio.
  3. Nella finestra di dialogo Connettiti al server, verifica che il nome del server sia impostato su NODE-1 e seleziona Connetti.
  4. 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 utilizzate in questo tutorial:

Elimina il progetto

  1. In the Google Cloud console, go to the Manage resources page.

    Go to Manage resources

  2. In the project list, select the project that you want to delete, and then click Delete.
  3. 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.