Deployment di Microsoft SQL Server per il ripristino di emergenza in più regioni

Last reviewed 2020-08-21 UTC

Questo tutorial descrive come eseguire il deployment e gestire un sistema di database Microsoft SQL Server in due regioni di Google Cloud come soluzione di ripristino di emergenza (RE) e come eseguire il failover da un'istanza di database con errori a un'istanza normalmente in funzione. Ai fini di questo documento, un calamità è un evento in cui un database principale ha esito negativo o diventa non disponibile.

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

Questo tutorial è destinato ad architetti di database, amministratori e ingegneri.

Obiettivi

Esegui il deployment di un ambiente di ripristino di emergenza in più regioni su Google Cloud utilizzando i gruppi di disponibilità AlwaysOn di Microsoft SQL Server.
Simula un evento di emergenza ed esegui un processo di ripristino di emergenza completo per convalidare la configurazione di ripristino.

Costi

In questo documento vengono utilizzati 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 possono essere idonei a una prova senza costi aggiuntivi.

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 crearne uno nuovo o selezionare un progetto che hai già creato:

Nella pagina del selettore di progetti della console Google Cloud, seleziona o crea un progetto Google Cloud.

Nota: se non prevedi di conservare le risorse create in questa procedura, crea un progetto anziché selezionarne uno esistente. Dopo aver completato questi passaggi, puoi eliminare il progetto, rimuovendo tutte le risorse associate.

Vai al selettore progetti
Assicurati che la fatturazione sia attivata per il tuo progetto Google Cloud.
Nella console Google Cloud, attiva Cloud Shell.

Attiva Cloud Shell

Informazioni sul ripristino di emergenza

In Google Cloud, il ripristino di emergenza (RE) riguarda la continuità dell'elaborazione, soprattutto quando una regione presenta errori o diventa inaccessibile. Per sistemi come un sistema di gestione di database, puoi implementare RE eseguendo il deployment del sistema in almeno due regioni. Con questa configurazione, il sistema continua a funzionare se una regione diventa non disponibile.

Ripristino di emergenza del sistema di database

Il processo per rendere disponibile un database secondario in caso di errore dell'istanza di database principale è chiamato ripristino di emergenza del database (o RE del database). Per una discussione dettagliata su questo concetto, vedi Ripristino di emergenza per Microsoft SQL Server. Idealmente, lo stato del database secondario è coerente con quello del database primario nel momento in cui l'unità principale non è più disponibile oppure nel database secondario manca solo un piccolo insieme di transazioni recenti del database primario.

Architettura di ripristino di emergenza

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

Le istanze primarie e in standby si trovano in due zone nella regione R1, mentre un'istanza secondaria si trova nella regione R2.

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

Questa architettura funziona come segue:

Due istanze di Microsoft SQL Server (un'istanza principale e un'istanza in standby) si trovano nella stessa regione (R1), ma in zone diverse (zone A e B). Le due istanze in R1 coordinano i propri stati utilizzando la modalità di commit sincrono. Viene utilizzata la modalità sincrona perché supporta l'alta 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 ripristino di emergenza, 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 del 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 vengono gestiti da quanto segue:

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

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

Procedura di base per il ripristino di emergenza

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

La prima regione (R1), che esegue l'istanza del database principale, diventa non disponibile.
Il team operativo riconosce e riconosce formalmente l'emergenza e decide se è necessario un failover.
Se è richiesto un failover, l'istanza di database secondaria nella seconda area geografica (R2) diventa la nuova istanza principale.
I client riprendono l'elaborazione nel nuovo database principale e accedono all'istanza principale in R2.

Anche se questo processo di base stabilisce di nuovo un database primario funzionante, non stabilisce un'architettura di RE completa in cui la nuova istanza principale ha un'istanza di database in standby e un'istanza di database secondaria.

Completa il processo di ripristino di emergenza

Un processo di RE completo estende il processo 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 completa di RE del database, l'istanza secondaria nella regione R2 diventa quella primaria e viene creata una nuova istanza secondaria nella regione R3.

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

Questa architettura completa di RE del database funziona come segue:

La prima regione (R1), che esegue l'istanza del database principale, diventa non disponibile.
Il team Operations riconosce e riconosce formalmente l'emergenza e decide se è necessario un failover.
Se è richiesto un failover, l'istanza di database secondaria nella seconda area geografica (R2) diventa l'istanza principale.
Un'altra istanza secondaria, la nuova istanza standby, viene creata e avviata in R2 e aggiunta all'istanza principale. L'istanza in standby si trova in una zona diversa dall'istanza principale. Il database principale ora è costituito da due istanze (primaria e standby) ad alta disponibilità.
In una terza regione (R3), viene creata e avviata una nuova istanza di database secondario (in standby). Questa istanza secondaria è connessa in modo asincrono alla nuova istanza principale in R2. A questo punto, l'architettura originale di ripristino di emergenza è stata ricreata e operativa.

Esegui il fallback in una regione recuperata

Dopo che la prima regione (R1) è di nuovo online, può ospitare il nuovo database secondario. Se R1 diventerà disponibile abbastanza presto, puoi implementare il passaggio 5 nel processo di ripristino completo in R1 anziché in R3 (la terza regione). In questo caso, non è necessaria una terza regione.

Il seguente diagramma mostra l'architettura se R1 diventerà 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 l'errore della regione R1 diventa nuovamente disponibile.

In questa architettura, i passaggi per il ripristino sono gli stessi descritti in precedenza in Processo di ripristino di emergenza completato, con la differenza che R1 diventa la località delle istanze secondarie invece di R3.

Scelta di 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

Il tutorial utilizza la funzionalità dei gruppi di disponibilità AlwaysOn in SQL Server.

Se non hai bisogno di un database primario Microsoft SQL Server ad alta disponibilità e se è sufficiente una singola istanza di database 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

Le versioni 2016, 2017 e 2019 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 un'istanza di Microsoft SQL Server Management Studio su una VM separata in ogni area geografica. Se configuri un ambiente ad alta disponibilità, devi installare Microsoft SQL Server Management Studio una volta per ogni zona per garantire che rimanga disponibile se un'altra zona non è più disponibile.

Configurazione di Microsoft SQL Server per RE in più regioni

Questa sezione utilizza l'immagine sql-ent-2016-win-2016 per Microsoft SQL Server 2016 Enterprise Edition. Se installi Microsoft SQL Server 2017 Enterprise Edition, utilizza sql-ent-2017-win-2016. Per Microsoft SQL Server 2019 Enterprise Edition, utilizza sql-ent-2019-win-2019. Per un elenco completo delle immagini, consulta la sezione Immagini.

Configura un cluster ad alta disponibilità a due istanze

Per configurare un'architettura di RE di un database su più regioni per SQL Server, devi prima creare un cluster ad alta disponibilità (HA) a due istanze in una regione. Un'istanza funge da principale e l'altra da secondaria. Per completare questo passaggio, segui le istruzioni in Configurare i 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.

Innanzitutto, se segui la procedura descritta in Configurazione dei gruppi di disponibilità AlwaysOn di SQL Server, crei due istanze SQL Server nella stessa zona (us-central1-f). Questa configurazione non ti protegge da un errore di us-central1-f. Di conseguenza, per fornire supporto ad alta disponibilità, devi eseguire il deployment di un'istanza SQL Server (cluster-sql1) in us-central1-c e di una seconda istanza (cluster-sql2) in us-central1-f. I passaggi nella sezione successiva (sull'aggiunta di un'istanza secondaria per il ripristino di emergenza) presuppongono questa configurazione del deployment.

In secondo luogo, i passaggi nella configurazione dei gruppi di disponibilità AlwaysOn di SQL Server includono l'esecuzione di questa istruzione:

BACKUP DATABASE TestDB to disk = '\\cluster-sql2\SQLBackup\TestDB.bak' WITH INIT

Questa istruzione determina l'errore dell'istanza in standby. Esegui invece questo comando (il nome del file di backup è diverso):

BACKUP DATABASE TestDB to disk = '\\cluster-sql2\SQLBackup\TestDB-backup.bak' WITH INIT

In terzo luogo, i passaggi descritti nella Configurazione dei gruppi di disponibilità AlwaysOn di SQL Server consentono di creare directory di backup. Puoi utilizzare questi backup solo quando inizialmente sincronizzi l'istanza principale e lo standby e non successivamente. Un approccio alternativo alla creazione di directory di backup consiste nel scegliere Seeding automatico in questi passaggi. Questo approccio semplifica il processo di configurazione.

In quarto luogo, se i database non si sincronizzano, esegui il comando seguente in cluster-sql2:

ALTER DATABASE [TestDB] SET HADR AVAILABILITY GROUP = [cluster-ag]

Quinto, ai fini di questo tutorial, creerai un controller di dominio in us-central1-f, come illustrato nel seguente diagramma.

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

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

Anche se hai implementato l'architettura precedente per questo tutorial, una best practice consiste nel configurare un controller di dominio in più di una zona. Questo approccio garantisce di stabilire un'architettura di database abilitata per alta disponibilità e RE. Ad esempio, se un'interruzione si verifica in una zona, quella zona non diventa un single point of failure per l'architettura di cui hai eseguito il deployment.

Aggiungi un'istanza secondaria per il ripristino di emergenza

Successivamente, configurerai una terza istanza SQL Server (un'istanza secondaria denominata cluster-sql3), insieme alla rete:

In Cloud Shell, nello stesso virtual private cloud (VPC) utilizzato per la regione principale, crea una subnet nella regione secondaria (us-east1):
```
gcloud compute networks subnets create wsfcsubnet4 --network wsfcnet \
    --region us-east1 --range 10.3.0.0/24
```
Modifica la regola firewall denominata allow-internal-ports per consentire alla nuova subnet di ricevere il traffico:
```
gcloud compute firewall-rules update allow-internal-ports \
    --source-ranges 10.0.0.0/24,10.1.0.0/24,10.2.0.0/24,10.3.0.0/24
```
La regola allow-internal-ports è inclusa nei passaggi delle instructions che hai seguito in precedenza.

Crea un'istanza SQL Server:

gcloud compute instances create cluster-sql3 --machine-type n1-highmem-4 \
    --boot-disk-type pd-ssd --boot-disk-size 200GB \
    --image-project windows-sql-cloud --image-family sql-ent-2016-win-2016 \
    --zone us-east1-b \
    --network-interface "subnet=wsfcsubnet4,private-network-ip=10.3.0.4,aliases=10.3.0.5;10.3.0.6" \
    --can-ip-forward --metadata sysprep-specialize-script-ps1="Install-WindowsFeature Failover-Clustering -IncludeManagementTools;"

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 cluster-sql3, seleziona l'elenco a discesa Imposta password di Windows.
3. Imposta il nome utente e la password. Salvale per utilizzarle in seguito.
Fai clic su RDP per connetterti all'istanza cluster-sql3.
Inserisci il nome utente e la password dal passaggio 4, quindi fai clic su OK.

Apri una finestra di Windows PowerShell come amministratore, quindi configura il DNS e apri le porte:

netsh interface ip set dns Ethernet static 10.2.0.100

netsh advfirewall firewall add rule name="Open Port 5022 for Availability Groups" dir=in action=allow protocol=TCP localport=5022

netsh advfirewall firewall add rule name="Open Port 1433 for SQL Server" dir=in action=allow protocol=TCP localport=1433

Aggiungi l'istanza al dominio Windows:

Add-Computer -DomainName "dbeng.com" -Credential "dbeng.com\Administrator" -Restart -Force

Questo comando termina la connessione RDP.

Aggiungi l'istanza secondaria al cluster di failover

Quindi, aggiungi l'istanza secondaria (cluster-sql3) al cluster di failover di Windows:

Connettiti alle istanze cluster-sql1 o cluster-sql2 tramite RDP e accedi come amministratore.
Apri una finestra di PowerShell come amministratore e imposta le variabili per l'ambiente del cluster in questo tutorial:
```
$node3 = "cluster-sql3"
$nameWSFC = "cluster-dbclus" # Name of cluster
```
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 potrebbe smettere di rispondere e non tornare automaticamente, di tanto in tanto premi Enter.
Nel nodo, abilita la funzionalità AlwaysOn ad alta disponibilità:
```
Enable-SqlAlwaysOn -ServerInstance $node3 -Force
```
Crea due cartelle in C:\SQLData e C:\SQLLog per archiviare i dati del database e i file di log:
```
New-item -ItemType Directory "C:\SQLData"

New-item -ItemType Directory "C:\SQLLog"
```

Il nodo è ora unito al cluster di failover.

Aggiungi l'istanza secondaria al gruppo di disponibilità esistente

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

In uno dei tre nodi di istanza (cluster-sql1, cluster-sql2 o cluster-sql3), apri Microsoft SQL Server Management Studio e connettiti all'istanza principale (cluster-sql1):
1. Vai a Esplora oggetti.
2. Seleziona l'elenco a discesa Connetti.
3. Seleziona Database Engine.
4. Nell'elenco a discesa Nome server, seleziona cluster-sql1. Se il cluster non è presente nell'elenco, inseriscilo nel campo.
Fai clic su Nuova query.
Incolla il comando seguente per aggiungere un indirizzo IP al listener utilizzato per il nodo, quindi fai clic su Esegui:
```
ALTER AVAILABILITY GROUP [cluster-ag] MODIFY LISTENER 'cluster-listene' (ADD IP ('10.3.0.6', '255.255.255.0'))
```
In Esplora oggetti, espandi il nodo AlwaysOn Alta disponibilità, quindi espandi il nodo Gruppi di disponibilità.
Fai clic con il pulsante destro del mouse sul gruppo di disponibilità denominato cluster-ag, quindi seleziona Aggiungi replica.
Nella pagina Introduzione, fai clic sul nodo alwaysOn Alta disponibilità, quindi sul nodo Gruppi di disponibilità.
Nella pagina Connetti alle repliche, fai clic su Connetti per connetterti alla replica secondaria esistente cluster-sql2.
Nella pagina Specifica repliche, fai clic su Aggiungi replica, quindi aggiungi il nuovo nodo cluster-sql3. Non selezionare Failover automatico perché il failover automatico causa un commit sincrono. Questa configurazione supera i confini regionali, cosa che sconsigliamo.
Nella pagina Seleziona sincronizzazione dati, seleziona Seeding automatico.

Poiché non esiste un listener, la pagina Convalida genera un avviso che puoi ignorare.
Completa i passaggi della procedura guidata.

La modalità di failover per cluster-sql1 e cluster-sql2 è automatica, mentre per cluster-sql3 è manuale. Questa differenza è un modo per distinguere l'alta disponibilità dal ripristino di emergenza.

Il gruppo di disponibilità è 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 valuterai le implementazioni facoltative di RE.

Simula un'interruzione ed esegui un failover di RE

Simula un errore (interruzione) nella regione principale:
1. In Microsoft SQL Server Management Studio, su cluster-sql1, connettiti a cluster-sql1.
2. Creare una tabella. Dopo aver aggiunto le repliche nei passaggi successivi, verificherai il funzionamento della replica controllando se questa tabella è presente.
```
USE TestDB
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 cluster-sql2 --zone us-central1-f --quiet
gcloud compute instances stop cluster-sql1 --zone us-central1-c --quiet
```
Nota: un modo alternativo di creare un errore è arrestare le VM che eseguono cluster-sql1 e cluster-sql2. Questo approccio simula un errore grave invece della normale arresto di un'istanza.
In Microsoft SQL Server Management Studio su cluster-sql3, connettiti a cluster-sql3.
Esegui un failover e imposta la modalità di disponibilità su sync-commit. È necessario forzare un failover perché il nodo è in modalità di commit asincrono.
```
ALTER AVAILABILITY GROUP [cluster-ag] FORCE_FAILOVER_ALLOW_DATA_LOSS
GO
ALTER AVAILABILITY GROUP [cluster-ag]
MODIFY REPLICA ON 'CLUSTER-SQL3' WITH (AVAILABILITY_MODE = SYNCHRONOUS_COMMIT)
GO
```
Puoi riprendere l'elaborazione; cluster-sql3 è ora l'istanza principale.
(Facoltativo) Crea una nuova tabella in cluster-sql3. Dopo aver sincronizzato le repliche con la nuova istanza principale, controlla se questa tabella è replicata nelle repliche.
```
USE TestDB
GO
CREATE TABLE dbo.TestTable_After_DR (ID INT NOT NULL)
GO
```

Sebbene cluster-sql3 sia l'istanza principale in questo punto, ti consigliamo di tornare alla regione originale o di configurare una nuova istanza secondaria e un'istanza di standby per ricreare di nuovo un'architettura di RE completa. Queste opzioni vengono trattate nella prossima sezione.

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

Questo caso d'uso risolve un errore in cui tutte le transazioni vengono replicate dal database principale nel database secondario prima dell'errore di quello principale. In questo scenario ideale, i dati non vanno persi; lo stato del secondario è coerente con quello primario al momento del fallimento.

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

Ripristina la posizione principale originale e quella di standby originale (se disponibili).
Crea una nuova modalità standby e una nuova configurazione secondaria per cluster-sql3 nel caso in cui quelle principali e di standby originali non siano disponibili.

Approccio 1: utilizza le opzioni principali e di standby originali

In Cloud Shell, avvia i dispositivi principali originali (precedenti) e in standby:

gcloud compute instances start cluster-sql1 --zone us-central1-c --quiet
gcloud compute instances start cluster-sql2 --zone us-central1-f --quiet

In Microsoft SQL Server Management Studio, aggiungi di nuovo cluster-sql1 e cluster-sql2 come repliche secondarie:

Su cluster-sql3, aggiungi i due server in modalità di commit asincrono:

USE [master]
GO
ALTER AVAILABILITY GROUP [cluster-ag]
MODIFY REPLICA ON 'CLUSTER-SQL1' WITH (FAILOVER_MODE = MANUAL)
GO
ALTER AVAILABILITY GROUP [cluster-ag]
MODIFY REPLICA ON 'CLUSTER-SQL1' WITH (AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT)
GO
ALTER AVAILABILITY GROUP [cluster-ag]
MODIFY REPLICA ON 'CLUSTER-SQL2' WITH (FAILOVER_MODE = MANUAL)
GO
ALTER AVAILABILITY GROUP [cluster-ag]
MODIFY REPLICA ON 'CLUSTER-SQL2' WITH (AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT)
GO

Il giorno cluster-sql1, inizia a sincronizzare di nuovo i database:
```
USE [master]
GO
ALTER DATABASE [TestDB] SET HADR RESUME;
GO
```
Il giorno cluster-sql2, inizia a sincronizzare di nuovo i database:
```
USE [master]
GO
ALTER DATABASE [TestDB] SET HADR RESUME;
GO
```

Imposta di nuovo cluster-sql1 come principale:

Il giorno cluster-sql3, modifica la modalità di disponibilità di cluster-sql1 in commit sincrono. L'istanza cluster-sql1 diventa di nuovo quella principale.
```
USE [master]
GO
ALTER AVAILABILITY GROUP [cluster-ag]
MODIFY REPLICA ON 'CLUSTER-SQL1' WITH (AVAILABILITY_MODE = SYNCHRONOUS_COMMIT)
GO
```

In cluster-sql1, modifica cluster-sql1 in modo che sia il nodo principale e gli altri due nodi siano i secondari:

USE [master]
GO
-- Node 1 becomes primary
ALTER AVAILABILITY GROUP [cluster-ag] FAILOVER;
GO

-- Node 2 has synchronous commit
ALTER AVAILABILITY GROUP [cluster-ag]
MODIFY REPLICA ON 'CLUSTER-SQL2' WITH (AVAILABILITY_MODE = SYNCHRONOUS_COMMIT)
GO

-- Node 3 has asynchronous commit
ALTER AVAILABILITY GROUP [cluster-ag]
MODIFY REPLICA ON 'CLUSTER-SQL3' WITH (AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT)
GO

Una volta che tutti i comandi hanno avuto esito positivo, cluster-sql1 è il principale, mentre gli altri nodi sono secondari, come mostra il seguente diagramma.

Esplora oggetti mostra i gruppi di disponibilità.

Approccio 2: configura una nuova rete principale e una nuova modalità standby

Potresti non riuscire a recuperare le istanze principali e di standby originali dall'errore, potresti impiegare troppo tempo per recuperarle oppure l'area geografica potrebbe non essere accessibile. Un approccio consiste nel mantenere cluster-sql3 come principale e poi creare un nuovo standby e una nuova istanza secondaria, come mostra il seguente diagramma.

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

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

Per questa implementazione:

Mantieni cluster-sql3 come principale in us-east1.
Aggiungi una nuova istanza in standby (cluster-sql4) in una zona diversa in us-east1. Questo passaggio stabilisce ad alta disponibilità il nuovo deployment.
Crea una nuova istanza secondaria (cluster-sql5) in una regione separata, ad esempio us-west2. Questo passaggio consente di configurare il nuovo deployment per il ripristino di emergenza. Il deployment complessivo è stato completato. L'architettura del database supporta completamente alta disponibilità e RE.

(Facoltativo) Esegui un fallback quando mancano transazioni

Un errore non ottimale si verifica quando una o più transazioni impegnate nell'istanza principale non vengono replicate nella secondaria al momento dell'errore (noto anche come errore rigido). In un failover, tutte le transazioni di commit non replicate andranno perse.

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

Modifica la rete in modo che non vi sia connettività tra l'istanza principale e quella secondaria.
Modifica in qualche modo l'indirizzo principale, ad esempio aggiungi una tabella o inserisci alcuni dati.
Esegui il passaggio attraverso il processo di failover come descritto in precedenza in modo che quello secondario diventi il nuovo primario.

I passaggi del processo di failover sono identici a quelli dello scenario ideale, tranne per il fatto che la tabella aggiunta all'istanza principale dopo l'interruzione della connettività di rete non è visibile nell'istanza secondaria.

L'unica opzione per gestire un errore fisico è rimuovere le repliche (cluster-sql1 e cluster-sql2) dal gruppo di disponibilità e sincronizzare di nuovo le repliche. La sincronizzazione cambia il proprio stato per corrispondere a quello secondario. Qualsiasi transazione che non è stata replicata prima dell'errore andrà persa.

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

A questo punto, cluster-sql3 è l'impostazione principale, mentre cluster-sql1 e cluster-sql2 sono secondarie. Ora è possibile tornare a cluster-sql1, impostare cluster-sql2 come standby e cluster-sql3 come secondario. Il sistema ora presenta lo stesso stato che aveva prima dell'errore.

Failover automatico

Il passaggio automatico a un'istanza secondaria come principale può creare problemi. Una volta che l'istanza principale originale torna disponibile, può verificarsi una situazione di suddivisione-cervello se alcuni client accedono a quello secondario, mentre altri scrivono nell'unità principale ripristinata. In questo caso, i campi principali e secondari vengono possibilmente aggiornati in parallelo e i loro stati divergono. Per evitare questa situazione, questo tutorial fornisce istruzioni per un failover manuale in cui puoi decidere se (o quando) eseguire il failover.

Se implementi un failover automatico, devi assicurarti che solo una delle istanze configurate sia quella primaria e possa essere modificata. Qualsiasi istanza in standby o secondaria non deve fornire accesso in scrittura ad alcun client (ad eccezione di quella principale per la replica dello stato). Inoltre, devi evitare una catena rapida di failover successivi in breve tempo. Ad esempio, un failover ogni cinque minuti non sarebbe una strategia affidabile per il ripristino di emergenza. Per i processi di failover automatizzati, puoi creare misure di salvaguardia da scenari problematici come questi e, se necessario, coinvolgere un amministratore di database per 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, mentre un'istanza secondaria in modalità asincrona si trova in un'altra regione.

Figura 6. Architettura standard del ripristino di emergenza che utilizza Microsoft SQL Server.

Ciò significa che, in caso di failover, il deployment risultante ha una singola istanza finché non è possibile un fallback o finché non configuri uno standby (per l'alta disponibilità) e uno secondario (per RE).

Un'architettura di deployment alternativa è la configurazione di due istanze secondarie. Entrambe le istanze sono repliche di quella principale. Se si verifica un failover, puoi riconfigurare una delle 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. un'architettura standard per il ripristino di emergenza con due istanze secondarie.

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

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

Anche se devi comunque rendere una delle due secondarie in standby (Figura 8), questo processo è molto più rapido rispetto alla creazione e alla configurazione di un nuovo standby da scrap.

Puoi anche gestire RE con una configurazione analoga a questa architettura di utilizzo di due istanze secondarie. Oltre ad avere due secondarie in una seconda area geografica (Figura 7), puoi eseguire il deployment di altre due secondarie in una terza regione. Questa configurazione consente di creare in modo efficiente un'architettura di deployment abilitata per alta disponibilità e RE dopo un errore della 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

Nella console Google Cloud, vai alla pagina Gestisci risorse.
Vai a Gestisci risorse
Nell'elenco dei progetti, seleziona il progetto che vuoi eliminare, quindi fai clic su Elimina.
Nella finestra di dialogo, digita l'ID del progetto e fai clic su Chiudi per eliminare il progetto.

Passaggi successivi

Esplora le architetture di riferimento, i diagrammi e le best practice su Google Cloud. Dai un'occhiata al nostro Cloud Architecture Center.