Configurare il ripristino di emergenza per SQL Server
A questo punto, si esaminerà come proteggere il back-end SQL Server di un'applicazione usando una combinazione di Azure Site Recovery e delle tecnologie di continuità aziendale e ripristino di emergenza di SQL Server.
È possibile distribuire SQL Server in diversi modi:
- SQL Server autonomo: SQL Server e tutti i database sono ospitati in un singolo computer (fisico o una macchina virtuale). Se è virtualizzato, il clustering dell'host viene usato per la disponibilità elevata. La disponibilità elevata a livello di guest non viene implementata.
- Istanze di clustering di failover di SQL Server (AlwaysOn): due o più nodi che eseguono istanze di SQL Server con dischi condivisi vengono configurati in un cluster di failover di Windows. Se un nodo è inattivo, il cluster può effettuare il failover di SQL Server in un'altra istanza. Questa configurazione viene in genere usata per implementare la disponibilità elevata in un sito primario. Questa distribuzione non offre la protezione da errori o interruzioni nel livello dell'archiviazione condivisa. Un disco condiviso può essere implementato con iSCSI, Fibre Channel o VHDX condiviso.
- Gruppi di disponibilità SQL AlwaysOn: due o più nodi vengono configurati in un cluster non condiviso con i database SQL Server configurati in un gruppo di disponibilità con replica sincrona e failover automatico.
Per ripristinare i database in un sito remoto, questo processo usa le tecnologie di ripristino di emergenza native di SQL riportate di seguito:
- Gruppi di disponibilità Always On di SQL, per fornire il ripristino di emergenza per SQL Server Enterprise 2012 o versioni successive (incluso SQL Server 2017 Standard Edition)
- Mirroring del database SQL in modalità a sicurezza elevata, per altre distribuzioni di SQL Server.
Scenari supportati
Site Recovery può proteggere SQL Server, come riepilogato nella tabella.
| Scenario | In un sito secondario | In Azure |
|---|---|---|
| Hyper-V | Sì | Sì |
| VMware | Sì | Sì |
| Server fisico | Sì | Sì |
| Azure | N/D | Sì |
Versioni di SQL Server supportate
Per gli scenari supportati, è possibile usare le versioni di SQL Server seguenti:
- SQL Server 2017 Enterprise e Standard
- SQL Server 2016 Enterprise e Standard
- SQL Server 2014 Enterprise e Standard
- SQL Server 2012 Enterprise e Standard
- SQL Server 2008 R2 Enterprise e Standard
Supporto dell'integrazione con SQL Server
Site Recovery può essere integrato con le tecnologie di continuità aziendale e ripristino di emergenza native di SQL Server riepilogate nella tabella per fornire una soluzione di ripristino di emergenza.
| Funzionalità | Dettagli funzionalità | SQL Server |
|---|---|---|
| Gruppo di disponibilità AlwaysOn | Ognuna delle istanze autonome multiple di SQL Server viene eseguita in un cluster di failover con più nodi. I database possono essere raggruppati in gruppi di failover che possono essere copiati (con mirroring) in istanze di SQL Server in modo che non sia necessaria alcuna archiviazione condivisa. Fornisce il ripristino di emergenza tra un sito primario e uno o più siti secondari. Due nodi possono essere configurati in un cluster non condiviso con i database di SQL Server configurati in un gruppo di disponibilità con replica sincrona e failover automatico. | SQL Server (tutte le versioni supportate) |
| Clustering di failover (istanza del cluster di failover AlwaysOn) | SQL Server usa il clustering di failover di Windows per l'elevata disponibilità dei carichi di lavoro SQL Server locali. I nodi che eseguono le istanze di SQL Server con dischi condivisi sono configurati in un cluster di failover. Se un'istanza non è attiva, il cluster esegue il failover in un'altra istanza. Il cluster non protegge da errori o interruzioni nell'archiviazione condivisa. Il disco condiviso può essere implementato con iSCSI, fibre channel o VHDX condivisi. | SQL Server (tutte le versioni supportate) |
| Mirroring del database (modalità di protezione elevata) | Protegge un singolo database in una singola copia secondaria. Disponibile nelle modalità di replica a protezione elevata (sincrona) e a prestazione elevata (asincrona). Non richiede un cluster di failover. | SQL Server (tutte le versioni supportate) |
| Istanza di SQL Server autonoma | SQL Server e il database si trovano in un singolo server (fisico o virtuale). Il clustering dell'host viene usato per la disponibilità elevata se il server è virtuale. Nessuna disponibilità elevata a livello di guest. | Edizione Enterprise o Standard |
Prerequisiti per la distribuzione
- Distribuzione di SQL Server locale che esegue una versione supportata di SQL Server. In genere è necessario anche Active Directory per il server SQL.
- Requisiti per lo scenario che si vuole distribuire.
Configurare Active Directory
Per garantire la corretta esecuzione di SQL Server, configurare Active Directory nel sito di ripristino secondario.
- Organizzazione di piccole dimensioni: in presenza di un numero ridotto di applicazioni e di un singolo controller di dominio per il sito locale, se si vuole effettuare il failover dell'intero sito è consigliabile usare la replica di Site Recovery per replicare il controller di dominio nel data center secondario o in Azure.
- Organizzazione di medie o grandi dimensioni: se si dispone di un numero elevato di applicazioni e di una foresta Active Directory e si vuole effettuare il failover per applicazione o carico di lavoro, è consigliabile configurare un controller di dominio aggiuntivo nel data center secondario o in Azure. Se si usano gruppi di disponibilità AlwaysOn per il ripristino in un sito remoto, è consigliabile configurare un altro controller di dominio aggiuntivo nel sito secondario o in Azure, da usare per l'istanza di SQL Server ripristinata.
Le istruzioni presuppongono che sia disponibile un controller di dominio nella posizione secondaria.
Eseguire l'integrazione con SQL Server AlwaysOn per la replica in Azure
È necessario eseguire queste operazioni:
- Importare gli script disponibili all'indirizzo https://raw.githubusercontent.com/Azure/azure-quickstart-templates/master/demos/asr-automation-recovery/scripts/ASR-SQL-FailoverAG.ps1 nell'account di Automazione di Azure. Questo repository contiene gli script per il failover del gruppo di disponibilità SQL.
- Aggiungere lo script ASR-SQL-FailoverAG come azione preliminare del primo gruppo del piano di ripristino.
- Seguire le istruzioni disponibili nello script per creare una variabile di automazione in modo da specificare il nome dei gruppi di disponibilità.
SQL AlwaysOn non supporta il failover di test in modo nativo. Per eseguire un failover di test, seguire questa procedura:
- Configurare il backup della macchina virtuale di Azure nella macchina virtuale che ospita la replica del gruppo di disponibilità in Azure.
- Prima di attivare il failover di test del piano di ripristino, ripristinare la macchina virtuale dal backup creato nel passaggio precedente nella rete virtuale di test.
- Forzare un quorum nella macchina virtuale ripristinata dal backup.
- Aggiornare l'indirizzo IP del listener a un indirizzo IP disponibile nella rete di failover di test.
- Portare online il listener.
- Creare un servizio di bilanciamento del carico con un indirizzo IP creato nel pool di indirizzi IP front-end corrispondente al listener di ogni gruppo di disponibilità e con la macchina virtuale SQL aggiunta nel pool back-end.
- Eseguire un failover di test del piano di ripristino.
Dopo aver aggiunto lo script nel piano di ripristino e aver convalidato il piano di ripristino eseguendo un failover di test, è possibile eseguire un failover pianificato.