Questa pagina è stata tradotta dall'API Cloud Translation.

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

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

Un database principale può avere esito negativo quando la regione in cui è posizionato non funziona o diventa inaccessibili. Anche se una regione è disponibile e funziona normalmente, un database può non riuscire a causa di un errore di sistema. In questi casi, il ripristino di emergenza è il processo per rendere disponibile ai clienti un database secondario e l'elaborazione dei dati.

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

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

Costi

In questo documento vengono utilizzati i seguenti componenti fatturabili di Google Cloud:

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:

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
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) consiste nel garantire la continuità soprattutto quando una regione si arresta o diventa inaccessibile. Per i sistemi ad esempio un sistema di gestione di 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 per rendere disponibile un database secondario quando il database primario un errore dell'istanza è chiamato ripristino di emergenza del database (o RE del database). Per un una discussione dettagliata su questo concetto, vedi Ripristino di emergenza per Microsoft SQL Server. Idealmente, lo stato del database secondario è coerente con l'istanza nel momento in cui quello primario diventa non disponibile, oppure il database secondario manca solo un piccolo insieme di transazioni recenti dal 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.

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

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 modalità di commit sincrona. La modalità sincrona è utilizzata perché supporta alte la disponibilità e lo stato dei dati è coerente.
Un'istanza di Microsoft SQL Server (il sistema di ripristino di emergenza o secondario ) si trova in una seconda regione (R2). Per RE, lo stato secondario in R2 si sincronizza con l'istanza principale in R1 mediante in modalità di commit asincrona. La modalità asincrona è usata a causa dei suoi (non rallenta l'elaborazione del commit nell'istanza ).

Nel diagramma precedente, l'architettura mostra un gruppo di disponibilità. La il gruppo di disponibilità, se utilizzato con un listener, fornisce la stessa stringa di connessione a clienti se sono serviti 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. RE del processo descrive i passaggi operativi da intraprendere, manualmente o automaticamente, per mitigare l'errore della regione e stabilire in una regione disponibile.

Un processo di RE di base del database 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 il disastro e decide se è necessario un failover.
Se è necessario un failover, l'istanza del database secondaria nel secondo (R2) diventa la nuova istanza principale.
I client riprenderanno l'elaborazione nel nuovo database principale e accedono principale in R2.

Sebbene questo processo di base stabilisca di nuovo un database primario funzionante, non stabilisce un'architettura di RE completa, in cui la nuova istanza primaria 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 RE completa dopo un failover. Il seguente diagramma mostra un completa di RE del database.

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

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

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 operativo riconosce e riconosce formalmente il disastro e decide se è necessario un failover.
Se è necessario un failover, l'istanza del database secondaria nel secondo (R2) viene impostata come istanza principale.
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. Il database principale ora consiste di due istanze (principale e standby) a disponibilità elevata.
In una terza regione (R3), viene impostata una nuova istanza di database secondaria (in standby) creato e avviato. Questa istanza secondaria è connessa in modo asincrono la nuova istanza principale in R2. A questo punto, l'originale l'architettura di ripristino di emergenza viene ricreata e operativa.

Esegui il fallback in una regione recuperata

Dopo che la prima regione (R1) viene riportata online, può ospitare la nuova un 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). Nel in questo caso, non c'è bisogno di una terza regione.

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

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

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 di quelli descritti in precedenza nel Completare la procedura di ripristino di emergenza, con la differenza che R1 diventa la località per le istanze secondarie anziché 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
SQL Server 2022 Enterprise Edition

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

Se non hai bisogno di un database Microsoft SQL Server ad alta disponibilità ed è sufficiente un'unica istanza di database come primario, 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, vedi Immagini.

Configura un cluster a due istanze ad alta disponibilità

Per configurare un'architettura di RE di database multiregionali per SQL Server, devi prima un cluster a due istanze ad alta disponibilità in una regione. Un'istanza principale è l'istanza principale e l'altra come 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 la procedura Configurazione dei gruppi di disponibilità AlwaysOn di SQL Server, avrai creato due istanze SQL Server nella stessa regione (us-central1). Devi aver eseguito il deployment dell'istanza SQL Server principale (node-1) in us-central1-a e un'istanza in standby (node-2) in us-central1-b.
Anche se implementi l'architettura nella Figura 4 per questo tutorial, è consigliabile 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.

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

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

Aggiungi 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:

Crea uno script specializzato per i nodi del cluster di failover di Windows Server. Lo script installa la funzionalità di Windows necessaria e crea regole firewall per WSFC e SQL Server. Inoltre, formatta il disco dati 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: nome del tuo VPC
- SUBNET_NAME: 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 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 Compute Engine cluster node-3, seleziona il menu a discesa Imposta password di Windows dall'elenco di lettura.
3. Imposta il nome utente e la password. Prendine nota per utilizzarli in seguito.
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 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:

Connetterti alle istanze node-1 o node-2 tramite RDP e accedi come utente amministratore.
Apri una finestra 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.
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.
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à:

Connettiti a node-3 utilizzando Remote Desktop. Accedi con l'account utente del tuo dominio.
Apri SQL Server Configuration Manager.
Nel riquadro di navigazione, seleziona SQL Server Services (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 del dominio sql_server.
Fai clic su OK.
Quando ti viene richiesto di riavviare SQL Server, seleziona Sì.
In uno dei tre nodi di istanza node-1, node-2 o node-3, apri Microsoft SQL Server Management Studio e connettiti a nell'istanza principale, node-1.
1. Vai a Esplorazione oggetti.
2. Seleziona l'elenco a discesa Connetti.
3. Seleziona Motore del database.
4. Dall'elenco a discesa Server Name (Nome server), seleziona node-1 Se il cluster non è nell'elenco, 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à Sempre On.
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.
In Esplora oggetti, espandi il nodo Sempre alta disponibilità, ed espandi il nodo Gruppi di disponibilità.
Fai clic con il tasto destro del mouse sul gruppo di disponibilità denominato bookshelf-ag, e seleziona Aggiungi replica.
Nella pagina Introduction (Introduzione), fai clic sul pulsante AlwaysOn Highavailability (Disponibilità elevata sempre attiva). quindi fai clic sul nodo Gruppi di disponibilità.
Nella pagina Connetti alle repliche, fai clic su Connetti per connetterti a la replica secondaria esistente node-2.
Nella pagina Specifica repliche, fai clic su Aggiungi replica, quindi aggiungi il nuovo nodo node-3. Non selezionare Failover automatico poiché il failover automatico causa un commit sincrono. Una configurazione del genere oltrepassa i confini regionali, cosa che sconsigliamo.
Nella pagina Seleziona sincronizzazione dati, scegli Seeding automatico.

In assenza di un listener, la pagina di Convalida genera una 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 le la disponibilità dal ripristino di emergenza.

Il gruppo di disponibilità è pronto. Hai configurato due nodi per 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 ed esegui un failover di RE

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.
In Microsoft SQL Server Management Studio su node-3, connettiti a node-3.
Esegui un failover e imposta la modalità di disponibilità su commit sincrono. È necessario forzare un failover perché il nodo si trova in modalità di commit asincrona.
```
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 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 è il principale in questo momento, è consigliabile che tornare alla regione originale o configurare una nuova istanza secondaria e uno standby per ricreare di nuovo un'architettura RE completa. La sezione successiva illustra queste opzioni.

(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 da da quello principale a quello secondario prima che quello principale non vada a buon fine. 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

In Cloud Shell, avvia l'istanza principale (precedente) standby:

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 node-1 e node-2 indietro 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

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

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

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

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

Imposta di nuovo node-1 come principale:

Il giorno node-3, modifica la modalità di disponibilità di node-1 al commit sincrono. L'istanza node-1 di nuovo la rete principale.

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

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.

Esplora oggetti mostra i gruppi di disponibilità.

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

È possibile che tu non riesca a ripristinare gli asset principali e di standby originali all'errore o ci vuole troppo tempo per recuperarle oppure la regione è inaccessibile. Un approccio è mantenere node-3 come principale e poi crea un nuovo standby e una nuova istanza secondaria, come illustrato nel diagramma seguente.

L'istanza in 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. 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 in standby (node-4) in un'altra zona in us-east1. Questo passaggio stabilisce l'alta disponibilità del nuovo deployment.
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. Il 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:

Cambia la rete in modo che non ci sia connettività tra la rete principale e alle istanze secondarie.
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 il processo di failover sono identici lo scenario ideale, tranne che la tabella ha aggiunto all'istanza principale dopo l'interruzione della connettività di rete non è visibile nel secondario.

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

Per aggiungere node-1 come istanza secondaria, puoi seguire la stessa procedura per aggiungere node-3 in precedenza (vedi Aggiungi l'istanza secondaria al cluster di failover precedente) con la seguente differenza: node-3 è ora 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. Ora il sistema ha lo stesso stato che aveva prima dell'errore.

Failover automatico

Il failover automatico su un'istanza secondaria come principale può creare per risolvere problemi di produzione e facilità d'uso. Dopo che la scuola principale 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, primaria e secondaria sono probabilmente aggiornati in parallelo e i rispettivi stati divergono. Per evitare questa situazione, il tutorial fornisce istruzioni per un failover manuale in cui decidere se (o quando) fallire.

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, occorre evitare una rapida catena di i successivi failover 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 che diventa l'istanza principale in un failover, come mostrato nel seguente diagramma.

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

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

Ciò significa che, in caso di failover, il deployment risultante ha una singola fino a quando non è possibile un fallback o finché non configuri un 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 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.

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

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

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

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

Anche se è necessario impostare uno dei due secondari in standby (Figura 8), questo è molto più veloce rispetto alla creazione e alla configurazione di un nuovo standby 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 consente di creare in modo efficiente un'architettura di deployment abilitata per HA 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 usati 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 Centro architetture cloud.