Questa pagina è stata tradotta dall'API Cloud Translation.

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 (RE) e come eseguire il failover da un'istanza di database non funzionante a un'istanza in normale funzionamento. Ai fini di questo documento, un disastro è un evento in cui un database principale non funziona o non è 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, ripristino di emergenza è il processo di messa a disposizione di un database secondario per i client per l'elaborazione continua.

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

Obiettivi

Esegui il deployment di un ambiente di ripristino di emergenza multiregionale su Google Cloud utilizzando i gruppi di disponibilità AlwaysOn di Microsoft SQL Server.
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 utenti di Google Cloud potrebbero essere idonei per 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:

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
Make sure that billing is enabled for your Google Cloud project.
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, soprattutto quando una regione non funziona o diventa inaccessibile. Per i sistemi come un sistema di gestione del database, implementi il RE dispiegando il sistema in almeno due regioni. Con questa configurazione, il sistema continua a funzionare se una 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 di disaster recovery

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

Le istanze principali e di standby si trovano in due zone della regione R1 e un'istanza secondaria si trova nella regione R2.

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

Questa architettura funziona nel seguente modo:

Due istanze di Microsoft SQL Server (un'istanza principale e un'istanza di standby) 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 listener, fornisce la stessa stringa di connessione ai client se questi sono pubblicati da quanto segue:

L'istanza principale
L'istanza in standby (dopo un errore di zona)
L'istanza secondaria (dopo un errore nella regione e dopo che l'istanza secondaria diventa la nuova istanza principale)

In una variante dell'architettura sopra riportata, esegui il deployment delle due istanze situate nella prima regione (R1) nella stessa zona. Questo approccio potrebbe migliorare le prestazioni, ma non è ad alta disponibilità. Per avviare il processo di RE potrebbe essere necessaria un'interruzione del servizio in una singola zona.

Procedura di base di ripristino di emergenza

Il processo di DR inizia quando una regione non è più disponibile e viene eseguito il failover del database principale per riprendere l'elaborazione in un'altra regione operativa. 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 RE di base del database prevede i seguenti passaggi:

La prima regione (R1), in cui è in esecuzione 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, l'istanza del database secondario nella seconda regione (R2) diventa la nuova istanza principale.
I client 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 di RE 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 la procedura di RE di base aggiungendo passaggi per stabilire un'architettura di RE completa dopo un failover. Il seguente diagramma mostra un'architettura completa di RE del database.

In un'architettura di RE del database completa, l'istanza secondaria nella regione R2 diventa principale e viene creata una nuova istanza secondaria nella regione R3.

Figura 2. Disaster recovery con una regione principale non disponibile (R1).

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

La prima regione (R1), in cui è in esecuzione l'istanza del database principale, diventa non disponibile.
Il team operativo riconosce e conferma formalmente il disastro e decide se è necessario un failover.
Se è necessario un failover, l'istanza del database secondario nella seconda regione (R2) diventa l'istanza principale.
Un'altra istanza secondaria, la nuova istanza in standby, viene creata e avviata in R2 e aggiunta all'istanza principale. L'istanza di standby si trova in una zona diversa dall'istanza principale. Ora il database principale è costituito da due istanze (principale e di riserva) ad alta disponibilità.
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'architettura di disaster recovery originale 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 in tempo, puoi implementare il passaggio 5 della procedura di recupero completa in R1 anziché in R3 (la terza regione). In questo caso, non è necessaria una terza regione.

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

Se la regione R1 viene recuperata in tempo, le istanze secondarie vengono create nella regione R1.

Figura 3. Il ripristino di emergenza dopo il guasto della regione R1 diventa di nuovo disponibile.

In questa architettura, i passaggi di ripristino sono gli stessi descritti in precedenza in Procedura ripristino di emergenza recovery, con la differenza che R1 diventa la posizione per le 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, 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.

Configurazione di Microsoft SQL Server per il 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 RE 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. Per eseguire 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). 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 ti consente di stabilire un'architettura di database compatibile con HA e RE. Ad esempio, se si verifica un'interruzione in una zona, questa non diventa un singolo punto di défaillance per l'architettura di cui è stato eseguito il deployment.

Le istanze principali e di standby in modalità sincrona si trovano in zone diverse in una regione e un'istanza secondaria in modalità asincrona si trova in un'altra regione.

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

Aggiungere un'istanza secondaria per il ripristino di emergenza

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

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

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: il nome della tua VPC
- SUBNET_NAME: il nome della subnet per la regione us-east1

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

Imposta una password 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 utilizzarli in un secondo momento.
Fai clic su RDP per connetterti all'istanza node-3.
Inserisci il nome utente e la password del passaggio precedente, quindi fai clic su OK.
Aggiungi l'istanza al dominio Windows:
1. Fai clic con il tasto destro del mouse sul pulsante Start (o premi Win+X) e poi su Windows PowerShell (amministratore).
2. Conferma la richiesta di altezza facendo clic su Sì.
3. Collega il computer al dominio Active Directory e riavvialo:
```
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 failover

Aggiungi l'istanza secondaria (node-3) al cluster di failover Windows:

Connettiti alle istanze node-1 o node-2 utilizzando RDP e accedi come utente amministratore.
Apri una finestra PowerShell come utente amministratore e imposta le variabili per l'ambiente del cluster in questo tutorial:
```
$node3 = "node-3"
$nameWSFC = "SQLSRV_CLUSTER" # Name of cluster 
```
Sostituisci SQLSRV_CLUSTER con il nome del cluster SQL Server.
Aggiungi l'istanza secondaria al cluster:
```
Get-Cluster | WHERE Name -EQ $nameWSFC | Add-ClusterNode -NoStorage -Name $node3
```
L'esecuzione di questo comando potrebbe richiedere del tempo. Poiché la procedura può smettere di rispondere e non tornare automaticamente, premi di tanto in tanto Enter.
Nel nodo, attiva la funzionalità di alta disponibilità AlwaysOn:
```
Enable-SqlAlwaysOn -ServerInstance $node3 -Force
```

Il nodo ora fa parte del cluster di failover.

Aggiungi l'istanza secondaria al gruppo di disponibilità esistente

Aggiungi l'istanza SQL Server (l'istanza secondaria) e il database al gruppo di disponibilità:

Connettiti a node-3 utilizzando Remote Desktop. Accedi con il tuo account utente del dominio.
Apri SQL Server Configuration Manager.
Nel riquadro di navigazione, seleziona Servizi SQL Server.
Nell'elenco dei servizi, fai clic con il tasto destro del mouse su SQL Server (MSSQLSERVER) e seleziona Proprietà.
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 di dominio sql_server.
Fai clic su OK.
Quando ti viene chiesto di riavviare SQL Server, seleziona Sì.
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 è elencato, inseriscilo nel campo.
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.
Incolla il seguente comando per aggiungere un indirizzo IP all'ascoltatore utilizzato 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.
In Esplora oggetti, espandi il nodo Alta disponibilità AlwaysOn, quindi espandi il nodo Gruppi di disponibilità.
Fai clic con il tasto destro del mouse sul gruppo di disponibilità denominato bookshelf-ag, poi seleziona Aggiungi replica.
Nella pagina Introduzione, fai clic sul nodo AlwaysOn High Availability e poi sul nodo Availability Groups.
Nella pagina Connetti a repliche, fai clic su Connetti per collegarti alla replica secondaria esistente node-2.
Nella pagina Specifica repliche, fai clic su Aggiungi replica e poi aggiungi il nuovo nodo node-3. Non selezionare Failover automatico perché il failover automatico causa un commit sincrono. Questa configurazione attraversa i confini regionali, il che non è consigliabile.
Nella pagina Seleziona la sincronizzazione dei dati, seleziona Seeding automatico.

Poiché non è presente alcun ascoltatore, la pagina Convalida genera un avviso che puoi ignorare.
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 l'alta 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 prenderai in considerazione le implementazioni facoltative del RE.

Simula un'interruzione del servizio ed esegui un failover RE

Simula un errore o un'interruzione del servizio 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, verifica che la replica funzioni controllando se questa tabella è presente.
```
USE bookshelf
GO
CREATE TABLE dbo.TestTable_Before_DR (ID INT NOT NULL)
GO
```
3. In Cloud Shell, arresta entrambi i server nella regione principaleus-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 eseguono node-1 e node-2. Questo approccio simula un guasto grave anziché un normale arresto dell'istanza.
In Microsoft SQL Server Management Studio su node-3, connettiti a node-3.
Esegui un failover e imposta la modalità di disponibilità su commit-sincronico. È 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.
(Facoltativo) Crea una nuova tabella in node-3. Dopo aver sincronizzato le repliche con la nuova principale, controlla se questa tabella è replicata 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 RE completa. La sezione successiva discute queste opzioni.

(Facoltativo) Ricrea un'architettura di RE che replichi 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 scenario ideale, non si verifica alcuna perdita di dati; lo stato della risorsa secondaria è coerente con quello della risorsa principale al momento del guasto.

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

Ripristina il gruppo principale e il gruppo di standby originali (se disponibili).
Crea un nuovo account di riserva e secondario per node-3 nel caso in cui quelli principali e di riserva originali non siano disponibili.

Approccio 1: ripristina le impostazioni originali di principale e di standby

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

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

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

Su node-1, riavvia la sincronizzazione dei database:

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

Su node-2, riavvia la sincronizzazione dei database:

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

Imposta di nuovo node-1 come principale:

In node-3, modifica la modalità di disponibilità di node-1 in commit-sincronico. 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

In node-1, imposta node-1 come nodo 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 sono andati a buon fine, node-1 è il nodo principale e gli altri nodi sono secondari, come mostrato nel seguente diagramma.

Object Explorer mostra i gruppi di disponibilità.

Approccio 2: configura un nuovo account principale e uno 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 creare una nuova istanza in standby e una nuova istanza secondaria, come mostrato nel seguente diagramma.

L'istanza di standby viene creata in una zona separata, ma nella stessa regione dell'istanza principale, e un'istanza secondaria viene creata in una regione separata.

Figura 5. Disaster recovery con regione principale originale R1 non disponibile.

Questa implementazione richiede quanto segue:

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 il recupero calamitoso. Il deployment complessivo è stato completato. L'architettura del database supporta completamente HA e RE.

(Facoltativo) Eseguire un piano di riserva quando mancano le transazioni

Un errore non ideale si verifica quando una o più transazioni committate sul primario non vengono replicate sul secondario nel punto di errore (noto anche come errore grave). In caso di failover, tutte le transazioni committate che non vengono replicate andranno perse.

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

Modifica la rete in modo che non sia presente alcuna connettività tra le istanze principale e secondaria.
Modifica la colonna principale in qualche modo, ad esempio aggiungendo una tabella o inserendo alcuni dati.
Segui la procedura di failover descritta in precedenza in modo che il secondario diventi 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 ne modifica lo stato in modo che corrisponda a quello secondario. Eventuali transazioni non replicate prima dell'errore andranno perse.

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 è la 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 l'istanza SQL Server al gruppo di disponibilità.

A questo punto, node-3 è il canale principale e node-1 e node-2 sono secondari. Ora è possibile eseguire il fallback su node-1, impostare node-2 come modalità standby e node-3 come 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. Una volta che il database principale originale diventa di nuovo disponibile, può verificarsi una situazione di split-brain se alcuni client accedono al database secondario mentre altri scrivono nel database principale ripristinato. In questo caso, è possibile che la proprietà 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 una delle istanze configurate sia principale e possa essere modificata. Qualsiasi istanza di standby o secondaria non deve fornire l'accesso in scrittura a nessun client (tranne all'istanza 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 di ripristino di emergenza affidabile. Per le procedure di failover automatico, puoi implementare misure di salvaguardia contro scenari problematici come questi e, se necessario, coinvolgere anche un amministratore di database per le decisioni complesse.

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.

Le istanze principali e di standby in modalità sincrona si trovano in zone diverse in una regione e un'istanza secondaria in modalità asincrona si trova in un'altra regione.

Figura 6. Architettura di ripristino di emergenza standard che utilizza 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 RE).

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

Le due istanze secondarie si trovano in zone separate nella regione R2.

Figura 7. Architettura di ripristino di emergenza standard con due istanze secondarie.

Dopo il failover, una delle istanze secondarie nella regione R2 diventa un'istanza di standby.

Figura 8. Architettura di ripristino di emergenza standard con due istanze secondarie 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 che utilizza due istanze secondarie. Oltre ad avere due secondari in una seconda regione (Figura 7), puoi implementare altri due secondari 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

In the Google Cloud console, go to the Manage resources page.
Go to Manage resources
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.