Eseguire il deployment di Microsoft SQL Server per il ripristino di emergenza multiregionale

---

Questo tutorial descrive come eseguire il deployment e gestire un sistema di database Microsoft SQL Server in due regioni Google Cloud come soluzione di ripristino di emergenza (DR) e come eseguire il failover da un'istanza di database non funzionante a un'istanza in normale funzionamento. Ai fini del presente documento, una calamità è un evento in cui un database principale si arresta o non è più disponibile.

Un database principale può non funzionare quando la regione in cui si trova non funziona o diventa inaccessibile. Anche se una regione è disponibile e funziona normalmente, un database principale può non funzionare a causa di un errore di sistema. In questi casi, il ripristino di emergenza è il processo di messa a disposizione di un database secondario per i client per il proseguimento dell'elaborazione.

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

Obiettivi

• Esegui il deployment di un ambiente di ripristino di emergenza multiregionale Google Cloud utilizzando la disponibilità AlwaysOn di Microsoft SQL Server Gruppi.
• 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:

• Compute Engine
• SQL Server VMs

Per generare una stima dei costi basata sull'utilizzo previsto, utilizza il Calcolatore prezzi. I nuovi utenti di Google Cloud potrebbero essere idonei per una prova gratuita.

Una volta completate le attività descritte in questo documento, puoi evitare la fatturazione continua eliminando le risorse che hai creato. Per ulteriori informazioni, consulta la pagina Pulizia.

Prima di iniziare

Per questo tutorial è necessario un progetto Google Cloud. Puoi creare un o seleziona un progetto già creato:

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

   Note: If you don't plan to keep the resources that you create in this procedure, create a project instead of selecting an existing project. After you finish these steps, you can delete the project, removing all resources associated with the 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

Informazioni sul ripristino di emergenza

In Google Cloud, il ripristino di emergenza (RE) consiste nel garantire la continuità dell'elaborazione, in particolare quando una regione non funziona o diventa inaccessibile. Per i sistemi ad esempio un sistema di gestione dei database, implementi RE eseguendo il deployment del sistema in almeno due regioni. Con questa configurazione, il sistema continua a funzionare se regione non è più disponibile.

Ripristino di emergenza del sistema di database

Il processo di impostazione di un database secondario quando l'istanza del database principale non funziona è chiamato ripristino di emergenza del database (o DR del database). Per una discussione dettagliata su questo concetto, consulta Ripristino di emergenza per Microsoft SQL Server. Idealmente, lo stato del database secondario è coerente con quello del database primario nel momento in cui il database principale non è più disponibile oppure nel database secondario manca solo un piccolo insieme di transazioni recenti del database principale.

Architettura per il ripristino di emergenza

Per Microsoft SQL Server, il seguente diagramma mostra un'architettura minima che supporta la RE del database.

Figura 1. Architettura standard per il ripristino di emergenza con Microsoft SQL Server.

Questa architettura funziona nel seguente modo:

• Due istanze di Microsoft SQL Server (un'istanza principale e una in standby dell'istanza) 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 un'elevata disponibilità e mantiene uno stato dei dati coerente.
• Un'istanza di Microsoft SQL Server (l'istanza secondaria o di ripristino di emergenza) si trova in una seconda regione (R2). Per il DR, l'istanza secondaria in R2 si sincronizza con l'istanza principale in R1 utilizzando la modalità di commit asincrono. La modalità asincrona viene utilizzata per le sue prestazioni (non rallenta l'elaborazione dei commit nell'istanza principale).

Nel diagramma precedente, l'architettura mostra un gruppo di disponibilità. Il gruppo di disponibilità, se utilizzato con un ascoltatore, fornisce la stessa stringa di connessione ai clienti se questi sono pubblicati da:

• L'istanza principale
• L'istanza in standby (dopo un errore in una zona)
• L'istanza secondaria (dopo un errore di regione e dopo diventa la nuova istanza principale)

In una variante dell'architettura precedente, esegui il deployment delle due istanze che nella prima regione (R1) nella stessa zona. Questo approccio potrebbe migliorare ma non è ad alta disponibilità; potrebbe essere necessaria un'interruzione in una singola zona per avviare il processo di RE.

Procedura di ripristino di emergenza di base

Il processo di RE inizia quando una regione diventa non disponibile e esegue il failover del database per riprendere l'elaborazione in un'altra regione operativa. La procedura di RP 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.

Un processo di RE di base del database prevede i seguenti passaggi:

1. La prima regione (R1), che esegue l'istanza del database principale, diventa non disponibile.
2. Il team operativo riconosce e riconosce formalmente il disastro e decide se è necessario un failover.
3. Se è necessario un failover, l'istanza del database secondaria nel secondo (R2) viene impostata come nuova istanza principale.
4. I client riprenderanno l'elaborazione nel nuovo database principale e accedono principale in R2.

Sebbene questa procedura di base ristabilisca un database principale funzionante, non consente di creare un'architettura di DR completa, in cui la nuova istanza principale ha un'istanza di database standby e secondaria.

Completa la procedura di ripristino di emergenza

Un processo di RE completo estende il processo di RE di base aggiungendo passaggi per stabilire un'architettura RE completa dopo un failover. Il seguente diagramma mostra un'architettura completa di DR del database.

Figura 2. Ripristino di emergenza con una regione principale (R1) non disponibile.

Questa architettura completa di DR del database funziona nel seguente modo:

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 il disastro e decide se è necessario un failover.
3. Se è necessario un failover, l'istanza del database secondaria nel secondo (R2) viene impostata come istanza principale.
4. Viene creata un'altra istanza secondaria, la nuova istanza in standby avviato in R2 e aggiunto all'istanza principale. L'istanza in standby è in in una zona diversa dall'istanza principale. Ora il database principale è costituito da due istanze (principale e di standby) ad alta disponibilità.
5. In una terza regione (R3), viene creata e avviata una nuova istanza di database secondaria (in standby). Questa istanza secondaria è collegata in modo asincrono alla nuova istanza principale in R2. A questo punto, l'originale l'architettura di ripristino di emergenza viene ricreata e operativa.

Ripristino di una regione recuperata

Una volta ripristinata la prima regione (R1), questa può ospitare il nuovo database secondario. Se R1 diventa disponibile abbastanza presto, puoi implementare il passaggio 5 nel processo di recupero completo in R1 anziché R3 (la terza regione). Nella in questo caso, non c'è bisogno di una terza regione.

Il seguente diagramma mostra l'architettura se R1 diventa disponibile in tempo.

Figura 3. Ripristino di emergenza dopo che è disponibile la regione R1 con errore di nuovo.

In questa architettura, i passaggi di ripristino sono gli stessi descritti in precedenza in Procedura completa di disaster recovery, con la differenza che R1 diventa la posizione delle istanze secondarie invece di R3.

Scegliere 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à Gruppi di disponibilità AlwaysOn in SQL Server.

Se non hai bisogno di un database principale Microsoft SQL Server ad alta disponibilità (HA) 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, consigliamo di installare un'istanza di Microsoft SQL Server Management Studio su una VM separata 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.

Configurazione di Microsoft SQL Server per RE multiregionale

Questa sezione utilizza le seguenti immagini per Microsoft SQL Server:

• sql-ent-2016-win-2016 per Microsoft SQL Server 2016 Enterprise Edition
• sql-ent-2017-win-2016 per Microsoft SQL Server 2017 Enterprise Edition
• sql-ent-2019-win-2019 per Microsoft SQL Server 2019 Enterprise Edition
• sql-ent-2022-win-2022 per Microsoft SQL Server 2022 Enterprise Edition

Per un elenco completo delle immagini, consulta Immagini.

Configurare un cluster ad alta disponibilità con due istanze

Per configurare un'architettura di ripristino di emergenza del database multiregionale per SQL Server, devi prima creare un cluster ad alta disponibilità (HA) con due istanze in una regione. Un'istanza fungerà da principale e l'altra da secondaria. A completare questo passaggio, segui le istruzioni in Configurazione di gruppi di disponibilità AlwaysOn SQL Server. Questo tutorial utilizza us-central1 per la regione principale (indicata come R1). Prima di iniziare, esamina le seguenti considerazioni:

• 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 dell'istanza SQL Server principale (node-1) in us-central1-a e di un'istanza di standby (node-2) in us-central1-b.

• Sebbene per questo tutorial venga implementata l'architettura indicata nella Figura 4, è buona pratica configurare un controller di dominio in più di una zona. Questo approccio assicura di stabilire un'architettura di database abilitata per HA e RE. Per Ad esempio, se si verifica un'interruzione in una zona, questa non diventa una singola il punto di errore per l'architettura di cui hai eseguito il deployment.

Figura 4. Architettura di ripristino di emergenza standard implementata in questo tutorial.

Aggiungere un'istanza secondaria per il ripristino di emergenza

Quindi, configurerai una terza istanza SQL Server (un'istanza secondaria denominata node-3) e configura la rete come segue:

1. Crea uno script di specializzazione per i nodi del cluster di failover di Windows Server. Lo script installa la funzionalità Windows necessaria e crea le regole firewall per WSFC e SQL Server. Formatta anche il disco di dati e crea cartelle di dati e log per SQL Server:

   cat << "EOF" > specialize-node.ps1
   
   $ErrorActionPreference = "stop"
   
   # Install required Windows features
   Install-WindowsFeature Failover-Clustering -IncludeManagementTools
   Install-WindowsFeature RSAT-AD-PowerShell
   
   # Open firewall for WSFC
   netsh advfirewall firewall add rule name="Allow SQL Server health check" dir=in action=allow protocol=TCP localport=59997
   
   # Open firewall for SQL Server
   netsh advfirewall firewall add rule name="Allow SQL Server" dir=in action=allow protocol=TCP localport=1433
   
   # Open firewall for SQL Server replication
   netsh advfirewall firewall add rule name="Allow SQL Server replication" dir=in action=allow protocol=TCP localport=5022
   
   # Format data disk
   Get-Disk |
    Where partitionstyle -eq 'RAW' |
    Initialize-Disk -PartitionStyle MBR -PassThru |
    New-Partition -AssignDriveLetter -UseMaximumSize |
    Format-Volume -FileSystem NTFS -NewFileSystemLabel 'Data' -Confirm:$false
   
   # Create data and log folders for SQL Server
   md d:\Data
   md d:\Logs
   EOF
   

2. Inizializza le seguenti variabili:

   VPC_NAME=VPC_NAME
   SUBNET_NAME=SUBNET_NAME
   REGION=us-east1
   PD_SIZE=200
   MACHINE_TYPE=n2-standard-8
   

   Dove:

   • VPC_NAME: nome del VPC
   • SUBNET_NAME: nome della subnet per la regione us-east1

3. Crea un'istanza SQL Server:

   gcloud compute instances create node-3 \
   --zone $REGION-b \
   --machine-type $MACHINE_TYPE \
   --subnet $SUBNET_NAME \
   --image-family sql-ent-2022-win-2022 \
   --image-project windows-sql-cloud \
   --tags wsfc,wsfc-node \
   --boot-disk-size 50 \
   --boot-disk-type pd-ssd \
   --boot-disk-device-name "node-3" \
   --create-disk=name=node-3-datadisk,size=$PD_SIZE,type=pd-ssd,auto-delete=no \
   --metadata enable-wsfc=true \
   --metadata-from-file=sysprep-specialize-script-ps1=specialize-node.ps1
   

4. Imposta una password di Windows per la nuova istanza SQL Server:

   1. Nella console Google Cloud, vai alla pagina Compute Engine.

      Vai a Compute Engine

   2. Nella colonna Connetti per il cluster Compute Engine node-3, seleziona l'elenco a discesa Imposta password di Windows.

   3. Imposta il nome utente e la password. Prendine nota per un uso futuro.

5. Fai clic su RDP per connetterti all'istanza node-3.

6. Inserisci il nome utente e la password del passaggio precedente, quindi fai clic su OK.

7. Aggiungi l'istanza al dominio Windows:

   1. Fai clic con il pulsante destro del mouse sul pulsante Start (o premi Win+X) e fai clic su Windows PowerShell (Amministratore).

   2. Conferma la richiesta di elevazione facendo clic su Sì.

   3. Unisci il computer al tuo dominio Active Directory e riavvia:

      Add-Computer -Domain DOMAIN -Restart
      

      Sostituisci DOMAIN con il nome DNS del tuo dominio Active Directory.

      Attendi circa 1 minuto per il completamento del riavvio.

Aggiungi l'istanza secondaria al cluster di failover

Successivamente, aggiungi l'istanza secondaria (node-3) al failover di Windows cluster:

1. Connettersi alle istanze node-1 o node-2 tramite RDP e accedi come utente amministratore.

2. Apri una finestra di PowerShell come utente amministratore e imposta le variabili per il in questo tutorial:

   $node3 = "node-3"
   $nameWSFC = "SQLSRV_CLUSTER" # Name of cluster 
   

   Sostituisci SQLSRV_CLUSTER con il nome del cluster SQL Server.

3. Aggiungi l'istanza secondaria al cluster:

   Get-Cluster | WHERE Name -EQ $nameWSFC | Add-ClusterNode -NoStorage -Name $node3
   

   L'esecuzione di questo comando potrebbe richiedere un po' di tempo. Poiché il processo può interrompersi rispondere e non tornare automaticamente, a volte premi Enter.

4. Nel nodo, abilita la funzionalità Alta disponibilità AlwaysOn:

   Enable-SqlAlwaysOn -ServerInstance $node3 -Force
   

Ora il nodo fa parte del cluster di failover.

Aggiungi l'istanza secondaria al gruppo di disponibilità esistente

Quindi, aggiungi l'istanza SQL Server (l'istanza secondaria) e il database alla gruppo di disponibilità:

1. Connettiti a node-3 utilizzando Remote Desktop. Accedi con il tuo account utente del dominio.

2. Apri SQL Server Configuration Manager.

3. Nel riquadro di navigazione, seleziona SQL Server Services (Servizi SQL Server)

4. Nell'elenco dei servizi, fai clic con il tasto destro del mouse su SQL Server (MSSQLSERVER) e seleziona Proprietà.

5. In Accedi come, modifica l'account:

   • Nome account: DOMAIN\sql_server dove DOMAIN è il nome NetBIOS del tuo dominio Active Directory.
   • Password: inserisci la password scelta in precedenza per l'account del dominio sql_server.

6. Fai clic su OK.

7. Quando ti viene richiesto di riavviare SQL Server, seleziona Sì.

8. In uno dei tre nodi istanza node-1, node-2 o node-3, apri Microsoft SQL Server Management Studio e connettiti all'istanza principale node-1.

   1. Vai a Esplora oggetti.
   2. Seleziona l'elenco a discesa Connetti.
   3. Seleziona Motore del database.
   4. Nell'elenco a discesa Nome server, seleziona node-1. Se il cluster non è nell'elenco, inseriscilo nel campo.

9. Fai clic su Nuova query.

   Nota: i passaggi 9 e 10 non sono necessari se è stato utilizzato un nome di rete distribuita per configurare il gruppo di disponibilità AlwaysOn.

10. Incolla il comando seguente per aggiungere un indirizzo IP al listener che utilizzata per il nodo, quindi fai clic su Esegui:

    ALTER AVAILABILITY GROUP [bookshelf-ag] MODIFY LISTENER 'bookshelf' (ADD IP ('LOAD_BALANCER_IP_ADDRESS', '255.255.255.0'))
    

    Sostituisci LOAD_BALANCER_IP_ADDRESS con l'indirizzo IP del bilanciatore del carico nella regione us-east1.

11. In Esplora oggetti, espandi il nodo sempre elevata disponibilità, ed espandi il nodo Gruppi di disponibilità.

12. Fai clic con il tasto destro del mouse sul gruppo di disponibilità denominato bookshelf-ag, e seleziona Aggiungi replica.

13. Nella pagina Introduction (Introduzione), fai clic sul pulsante AlwaysOn Highavailability (Disponibilità elevata sempre attiva). quindi fai clic sul nodo Gruppi di disponibilità.

14. Nella pagina Connetti a repliche, fai clic su Connetti per collegarti alla replica secondaria esistente node-2.

15. Nella pagina Specifica repliche, fai clic su Aggiungi replica e poi aggiungi il nuovo nodo node-3. Non selezionare Failover automatico poiché il failover automatico causa un commit sincrono. Questa configurazione attraversa i confini regionali, il che non è consigliabile.

16. Nella pagina Seleziona sincronizzazione dati, scegli Seeding automatico.

    In assenza di un listener, la pagina di Convalida genera una avviso, che puoi ignorare.

17. Completa i passaggi della procedura guidata.

La modalità di failover per node-1 e node-2 è automatica, mentre è manuale per node-3. Questa differenza è un modo per distinguere le la disponibilità dal ripristino di emergenza.

Il gruppo di disponibilità è ora pronto. Hai configurato due nodi per l'alta disponibilità e un terzo nodo per il ripristino di emergenza.

Simulazione di un ripristino di emergenza

In questa sezione testerai l'architettura di ripristino di emergenza per questo tutorial e considerare le implementazioni facoltative di RE.

Simula un'interruzione del servizio ed esegui un failover DR

1. Simula un errore o un'interruzione nella regione principale:

   1. In Microsoft SQL Server Management Studio su node-1, connettiti a node-1.

   2. Creare una tabella. Dopo aver aggiunto le repliche nei passaggi successivi, e che la replica funzioni controllando se è presente questa tabella.

      USE bookshelf
      GO
      CREATE TABLE dbo.TestTable_Before_DR (ID INT NOT NULL)
      GO
      

   3. In Cloud Shell, arresta entrambi i server nella regione principale us-central1:

      gcloud compute instances stop node-2 --zone us-central1-b --quiet
      gcloud compute instances stop node-1 --zone us-central1-a --quiet
      

   Nota: un modo alternativo per creare un errore è arrestare le VM che eseguire node-1 e node-2. Questo approccio simula una dell'errore invece di un normale arresto dell'istanza.

2. In Microsoft SQL Server Management Studio su node-3, connettiti a node-3.

3. Esegui un failover e imposta la modalità di disponibilità su commit sincrono. È necessario forzare un failover perché il nodo è in modalità di commit asincrono.

   ALTER AVAILABILITY GROUP [bookshelf-ag] FORCE_FAILOVER_ALLOW_DATA_LOSS
   GO
   ALTER AVAILABILITY GROUP [bookshelf-ag]
   MODIFY REPLICA ON 'node-3' WITH (AVAILABILITY_MODE = SYNCHRONOUS_COMMIT)
   GO
   

   Puoi riprendere l'elaborazione. node-3 è ora l'istanza principale.

4. (Facoltativo) Crea una nuova tabella in node-3. Dopo la sincronizzazione alle repliche con la nuova istanza principale, controlla se questa tabella è replicato nelle repliche.

   USE bookshelf
   GO
   CREATE TABLE dbo.TestTable_After_DR (ID INT NOT NULL)
   GO
   

Anche se node-3 è l'istanza principale in questo momento, ti consigliamo di tornare alla regione originale o di configurare una nuova istanza secondaria e un'istanza di standby per ricreare un'architettura di DR completa. La sezione successiva discute queste opzioni.

(Facoltativo) Ricreare un'architettura di RE che replica completamente le transazioni

Questo caso d'uso riguarda un errore in cui tutte le transazioni vengono replicate dal database principale a quello secondario prima che si verifichi l'errore nel database principale. In questo ideale dello scenario, nessun dato viene perso; lo stato del secondario sia coerente principale nel punto di errore.

In questo scenario, è possibile ricreare un'architettura di RE completa in due modi:

• Utilizza l'impostazione principale e lo standby originale (se sono disponibili).
• Crea un nuovo standby e un secondario per node-3 nel caso in cui le reti principali e in standby originali non sono disponibili.

Approccio 1: utilizza l'impostazione principale e di riserva originali

1. In Cloud Shell, avvia il principale (vecchio) e il master di standby originali:

   gcloud compute instances start node-1 --zone us-central1-a --quiet
   gcloud compute instances start node-2 --zone us-central1-b --quiet
   

2. In Microsoft SQL Server Management Studio, aggiungi node-1 e node-2 indietro come repliche secondarie:

   1. Su node-3, aggiungi i due server in modalità di commit asincrono:

      USE [master]
      GO
      ALTER AVAILABILITY GROUP [bookshelf-ag]
      MODIFY REPLICA ON 'node-1' WITH (FAILOVER_MODE = MANUAL)
      GO
      ALTER AVAILABILITY GROUP [bookshelf-ag]
      MODIFY REPLICA ON 'node-1' WITH (AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT)
      GO
      ALTER AVAILABILITY GROUP [bookshelf-ag]
      MODIFY REPLICA ON 'node-2' WITH (FAILOVER_MODE = MANUAL)
      GO
      ALTER AVAILABILITY GROUP [bookshelf-ag]
      MODIFY REPLICA ON 'node-2' WITH (AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT)
      GO
      

   2. Il giorno node-1, riavvia la sincronizzazione dei database:

      USE [master]
      GO
      ALTER DATABASE [bookshelf] SET HADR RESUME;
      GO
      

   3. Il giorno node-2, riavvia la sincronizzazione dei database:

      USE [master]
      GO
      ALTER DATABASE [bookshelf] SET HADR RESUME;
      GO
      

3. Imposta di nuovo node-1 come principale:

   1. In node-3, modifica la modalità di disponibilità di node-1 in commit-sincrono. L'istanza node-1 diventa di nuovo principale.

      USE [master]
      GO
      ALTER AVAILABILITY GROUP [bookshelf-ag]
      MODIFY REPLICA ON 'node-1' WITH (AVAILABILITY_MODE = SYNCHRONOUS_COMMIT)
      GO
      

   2. Su node-1, modifica node-1 come principale e gli altri due nodi come secondari:

      USE [master]
      GO
      -- Node 1 becomes primary
      ALTER AVAILABILITY GROUP [bookshelf-ag] FORCE_FAILOVER_ALLOW_DATA_LOSS;
      GO
      
      -- Node 2 has synchronous commit
      ALTER AVAILABILITY GROUP [bookshelf-ag]
      MODIFY REPLICA ON 'node-2' WITH (AVAILABILITY_MODE = SYNCHRONOUS_COMMIT)
      GO
      
      -- Node 3 has asynchronous commit
      ALTER AVAILABILITY GROUP [bookshelf-ag]
      MODIFY REPLICA ON 'node-3' WITH (AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT)
      GO
      

Dopo che tutti i comandi hanno esito positivo, node-1 è il nodo principale, mentre gli altri nodi sono secondarie, come illustrato nel diagramma seguente.

Approccio 2: configura una nuova istanza principale e una nuova modalità di standby

È possibile che non sia possibile recuperare le istanze principali e di standby originali dal guasto, che il recupero richieda troppo tempo o che la regione non sia accessibile. Un approccio è mantenere node-3 come principale e poi crea un nuovo standby e una nuova istanza secondaria, come illustrato nel diagramma seguente.

Figura 5. Ripristino di emergenza con regione principale originale R1 non disponibile.

Per questa implementazione, devi:

• Mantieni node-3 come principale in us-east1.

• Aggiungi una nuova istanza di standby (node-4) in un'altra zona in us-east1. Questo passaggio imposta il nuovo deployment come ad alta disponibilità.

• Crea una nuova istanza secondaria (node-5) in una regione separata, ad esempio us-west2. Questo passaggio configura il nuovo deployment per le emergenze e il ripristino di emergenza. Il deployment complessivo è stato completato. L'architettura del database supporta completamente HA e RE.

(Facoltativo) Eseguire un fallback quando mancano transazioni

Un errore non ottimale si verifica quando una o più transazioni primarie non vengono replicate nel secondario nel punto di errore (note anche come errore permanente). In un failover, tutte le transazioni impegnate che non sono replicati andranno persi.

Per testare i passaggi di failover per questo scenario, devi generare un errore irreversibile. L'approccio migliore per generare un errore fisico è il seguente:

• Modifica la rete in modo che non sia presente connettività tra le istanze principale e secondaria.
• Modifica l'istanza principale in qualche modo, ad esempio aggiungendo una tabella o inserisci alcuni dati.
• Esegui il processo di failover come descritto in precedenza, in modo che secondario diventa il nuovo principale.

I passaggi per la procedura di failover sono identici a quelli dello scenario ideale, tranne che la tabella aggiunta al principale dopo l'interruzione della connettività di rete non è visibile nel secondario.

L'unica opzione per gestire un errore grave è rimuovere le repliche (node-1 e node-2) dal gruppo di disponibilità e sincronizzarle di nuovo. La sincronizzazione cambia il proprio stato in modo che corrisponda secondaria. Qualsiasi transazione non replicata prima dell'errore andrà persa.

Per aggiungere node-1 come istanza secondaria, puoi seguire gli stessi passaggi per l'aggiunta di node-3 in precedenza (consulta Aggiungere l'istanza secondaria al cluster di failover in precedenza) con la seguente differenza: node-3 ora è il principale, non node-1. Devi sostituire qualsiasi istanza di node-3 con il nome del server che aggiungi al gruppo di disponibilità. Se riutilizzi la stessa VM (node-1 e node-2), non è necessario aggiungere il server al cluster di failover di Windows Server; aggiungi solo SQL Server al gruppo di disponibilità.

Al momento, node-3 è il gruppo principale, mentre node-1 e node-2 sono secondarie. Ora è possibile utilizzare node-1, per impostare node-2 in standby e node-3 quello secondario. Il sistema ora ha lo stesso stato di prima dell'errore.

Failover automatico

Il failover automatico a un'istanza secondaria come principale può creare problemi. Dopo che la scuola primaria originale torna a essere disponibile, questa situazione può verificarsi se alcuni client accedono al server secondario, mentre altri scrivono quella principale ripristinata. In questo caso, è possibile che la risorsa principale e quella secondaria vengano aggiornate in parallelo e i relativi stati divergano. Per evitare questa situazione, questo tutorial fornisce istruzioni per un failover manuale in cui puoi decidere se eseguire il failover (o quando).

Se implementi un failover automatico, devi assicurarti che solo uno dei configurate è l'istanza principale e può essere modificata. Qualsiasi standby o l'istanza secondaria non deve fornire accesso in scrittura a nessun client (ad eccezione del principale per la replica dello stato). Inoltre, devi evitare una rapida catena di failover successivi in breve tempo. Ad esempio, un failover ogni cinque minuti non sarebbe una strategia affidabile per il ripristino di emergenza. Per il failover automatico di sicurezza, puoi integrare misure di salvaguardia contro scenari problematici come e persino coinvolgere un amministratore di database per decisioni complesse, se necessaria.

Architettura di deployment alternativa

Questo tutorial configura un'architettura di ripristino di emergenza con un'istanza secondaria che diventa l'istanza principale in un failover, come mostrato nel diagramma seguente.

Figura 6. Architettura standard per il ripristino di emergenza con Microsoft SQL Server.

Ciò significa che in caso di failover, il deployment risultante avrà una singola istanza finché non sarà possibile un fallback o finché non configuri un'istanza di riserva (per l'HA) e una secondaria (per il DR).

Un'architettura di deployment alternativa consiste nel configurare due istanze secondarie. Entrambe le istanze sono repliche dell'istanza principale. In caso di failover, puoi eseguire e riconfigurare uno dei server secondari come standby. I seguenti diagrammi mostrano di deployment prima e dopo un failover.

Figura 7. Architettura standard per il ripristino di emergenza con due di Compute Engine.

Figura 8. Architettura standard per il ripristino di emergenza con due dopo il failover.

Anche se devi comunque impostare uno dei due secondari come standby (Figura 8), questa procedura è molto più rapida rispetto alla creazione e alla configurazione di un nuovo standby da zero.

Puoi anche risolvere il problema di RE con una configurazione analoga a questa architettura utilizzando due istanze secondarie. Oltre ad avere due secondarie in un secondo (Figura 7), puoi eseguire il deployment di altre due secondarie in una terza regione. Questa configurazione ti consente di creare in modo efficiente un'architettura di deployment ad alta disponibilità e di ripristino dei dati dopo un errore nella regione principale.

Esegui la pulizia

Per evitare che al tuo account Google Cloud vengano addebitati costi relativi alle risorse utilizzate in questo tutorial:

Elimina il progetto

Attenzione: l'eliminazione di un progetto ha i seguenti effetti:
• L'intero contenuto del progetto viene eliminato. Se hai utilizzato un progetto esistente per le attività descritte in questo documento, quando lo elimini elimini anche tutto il lavoro svolto nel progetto.
• Gli ID progetto personalizzati non sono più disponibili. Quando hai creato questo progetto, potresti aver creato un ID progetto personalizzato che vuoi utilizzare in futuro. Per conservare gli URL che utilizzano l'ID progetto, ad esempio un appspot.com URL, elimina le risorse selezionate all'interno del progetto anziché eliminare l'intero 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. Dai un'occhiata al nostro Centro architetture cloud.