Questo documento introduce le strategie di ripristino di emergenza (RE) per Microsoft SQL Server per gli architetti e i responsabili tecnici responsabili della progettazione e dell'implementazione del ripristino di emergenza su Google Cloud.
I database possono non essere più disponibili per vari motivi, ad esempio a causa di errori dell'hardware o di rete. Per fornire accesso continuo al database durante gli errori, viene gestito un database secondario che è una replica di un database principale. Avere il database secondario in una località diversa aumenta le possibilità che sia disponibile quando il database primario non è più disponibile.
Se il database principale non è più disponibile, l'app mission critical si connette a un database secondario, continuando dallo stato dei dati coerente noto più di recente per fornire servizi agli utenti con tempi di inattività minimi o nulli.
Il processo per rendere disponibile un database secondario in caso di errore del database principale è chiamato ripristino di emergenza (RE) del database. Il database secondario ripristina la disponibilità del database primario. Il database secondario presenta idealmente lo stesso stato coerente esatto del database primario quando non è disponibile o quando manca solo un insieme minimo di transazioni recenti del database primario.
Il ripristino di emergenza del database è una funzionalità essenziale per i clienti aziendali. Il motore principale è la continuità aziendale per le app mission-critical. Ad esempio, un'app mission critical genera entrate (e-commerce), fornisce servizi affidabili e continui (gestione di voli o centrali elettriche) o supporta funzionalità che salvaguardano la vita (monitoraggio dei pazienti). In tutti questi esempi, è della massima importanza che l'app sia continuamente disponibile, poiché è considerata mission critical.
La maggior parte dei sistemi di gestione dei database offre funzionalità di ripristino di emergenza, tra cui Microsoft SQL Server. Questo documento sull'architettura illustra il modo in cui le funzionalità di RE fornite da SQL Server vengono implementate nel contesto di Google Cloud.
Terminologia
Le seguenti sezioni illustrano i termini utilizzati in questo documento.
Architettura di RE generale
Il seguente diagramma illustra la topologia generale dell'architettura RE.
Nel diagramma precedente, un'app accede a un database primario mentre un database secondario è in standby e ne esegue il mirroring. I client accedono all'app in esecuzione su Google Cloud.
Se il database principale non è più disponibile, gli amministratori del database o il team operativo devono decidere di avviare il processo di ripristino di emergenza. Se viene avviato il ripristino di emergenza del database, l'app viene ricollegata al database secondario. Dopo la connessione, l'app può servire di nuovo i suoi client. In una situazione ideale, l'app è disponibile nel database secondario il prima possibile, quindi i client potrebbero non verificarsi nemmeno un'interruzione. Un'alternativa è attendere che il database principale diventi di nuovo accessibile, anziché avviare il ripristino di emergenza. Ad esempio, se il disastro è intermittente, la risoluzione del problema potrebbe essere più rapida anziché fallire.
Database primari e secondari
Una o più app possono accedere a un database principale per fornire servizi di persistenza per la gestione dello stato dell'app. Un database secondario è correlato a un database primario e contiene una replica del database primario. Idealmente, il contenuto del database secondario corrisponde esattamente a quello del database principale in qualsiasi momento. In molti casi, il database secondario è in ritardo rispetto al database principale a causa di ritardi nell'applicazione delle modifiche transazionali apportate al database principale. È possibile associare più di un database secondario a un database primario, a seconda della tecnologia del database. SQL Server supporta l'associazione di più di un database secondario a un database primario.
Ripristino di emergenza
Se un database primario non è più disponibile, RE modifica il ruolo del database secondario per diventare il database primario. Se è presente più di un database secondario, uno di questi viene selezionato manualmente o in base a un elenco di failover preferito. Le app devono riconnettersi al nuovo database primario per continuare ad accedere al loro stato. Se il nuovo database principale non è sincronizzato con l'ultimo stato noto del database principale precedente, l'app viene avviata da uno stato passato (noto anche come Flashback).
È importante avere almeno un database secondario sempre per ogni database primario. Dopo un ripristino di emergenza, assicurati che sia configurato un nuovo database secondario per gestire scenari di ripristino di emergenza futuri.
Failover, passaggio e fallback
Esistono diversi scenari per modificare il ruolo tra database principali e secondari:
- Failover: il processo di modifica del ruolo di un database secondario come nuovo database principale e di connessione di tutte le app al database. Il failover non è intenzionale perché viene attivato quando un database primario sta diventando non disponibile. Puoi configurare il failover in modo che venga attivato automaticamente o manualmente.
- Passaggio: a differenza del failover, il passaggio da un database primario a un database secondario (nuovo database primario) viene attivato intenzionalmente per il test iniziale e la manutenzione pianificata. Testa il tuo sistema di RE con un passaggio periodico regolare per garantire l'affidabilità continua del ripristino di emergenza.
- Riserva: dopo la riparazione del database primario, l'elemento di riserva inverte il processo in cui il nuovo database primario diventa il database secondario. Un elemento di riserva viene attivato intenzionalmente per ristabilire lo stato prima dell'avvio del failover o del passaggio. Non è strettamente necessario, ma può essere fatto in base ai requisiti di ripristino di emergenza, come la località o le risorse disponibili.
Zone e regioni di Google Cloud
Le risorse come i database si trovano in zone e regioni di Google Cloud, dove ogni zona appartiene a una regione. Una zona è un dominio single point of failure. Consigliamo di eseguire il deployment di una risorsa ad alta disponibilità e a tolleranza di errore in più zone all'interno di una regione.
Per proteggerti dall'interruzione di un'intera regione, stabilisci strategie multiregionali per il ripristino di emergenza. Ad esempio, il database principale si trova in una regione e il database secondario corrispondente si trova in un'altra.
Modalità attive: attivo-passivo e attivo-attivo
Un database principale è un database aperto per operazioni di lettura e scrittura (operazioni DML) in modo che le app che vi accedono possano gestirne lo stato. Il database principale è chiamato database attivo. Il database secondario corrispondente è passivo perché replica il database principale, ma non è disponibile da nessuna app per le operazioni di modifica dello stato. Dopo un failover o un passaggio, il database secondario diventa il nuovo database primario e diventa un database attivo.
Il database primario e il database secondario possono essere entrambi attivi se la tecnologia di database supporta questa funzionalità, denominata modalità attivo-attivo. In questo caso, le app possono connettersi all'una o all'altra perché entrambi i database sono disponibili per la gestione dello stato. Il ripristino di emergenza in modalità attivo-attivo non richiede un failover se solo uno dei database attivi diventa non disponibile. Se un database attivo non è disponibile, l'altro database attivo continuerà a esserlo. La modalità Active-active non rientra nell'ambito di questo articolo perché SQL Server non supporta questa modalità.
Modalità standby: caldo, caldo, freddo e non standby
Affinché il database primario sia attivo, deve essere in esecuzione e in grado di eseguire istruzioni DML. Il database secondario non deve essere in esecuzione, può essere arrestato. Se non è in esecuzione, il tempo necessario per il ripristino da un'emergenza aumenta, in quanto il nuovo database primario deve essere in esecuzione prima di assumere il ruolo del nuovo database primario.
Esistono diverse varianti nella configurazione del database secondario:
- Hot standby: il database secondario è in esecuzione e pronto per essere connesso ai client. L'ultima modifica disponibile dal database principale viene sempre applicata non appena diventa disponibile.
- Warm standby: un database secondario è in esecuzione, ma non tutte le modifiche del database primario sono state ancora applicate.
- Cold standby: un database secondario non è in esecuzione. Innanzitutto occorre avviarlo e sincronizzarlo con lo stato più recente disponibile.
- Nessun standby: il software del database deve essere installato e successivamente avviato prima di applicare tutte le modifiche del database principale. Questa è la modalità meno costosa perché non consuma risorse quando non è necessaria, ma rispetto alle altre modalità impiega più tempo per diventare un nuovo database primario.
Strategie di RE
Nelle sezioni seguenti vengono spiegate le strategie di RE supportate da Microsoft SQL Server.
Dimensioni della strategia di recupero
Ci sono diverse dimensioni chiave da considerare quando selezioni o implementi una strategia di ripristino di emergenza del database. Ogni dimensione ha uno spettro e il comportamento e le aspettative della strategia di ripristino di emergenza dipendono dalla selezione dei punti dello spettro. Le dimensioni principali sono le seguenti:
- RPO (Recovery Point Objective): il periodo di tempo massimo accettabile durante il quale i dati potrebbero essere persi dalla tua app a causa di un incidente grave. Questa dimensione varia in base alle modalità di utilizzo dei dati. L'RPO può essere espresso in termini di durata (secondi, minuti o ore) dal momento in cui il database principale non è disponibile oppure può essere espresso come stati di elaborazione identificabili (ultimo backup completo o ultimo backup incrementale). Indipendentemente da come l'RPO sia specificato, la strategia di ripristino di emergenza deve implementare la misura specifica in modo da soddisfare il requisito dell'RPO. Il caso più impegnativo è l'ultima transazione impegnata, il che significa che non deve verificarsi alcuna perdita dal database principale al database secondario.
- RTO (Recovery Time Objective). Il periodo di tempo massimo accettabile in cui la tua app può essere offline. Questo valore viene in genere specificato nell'ambito di un accordo sul livello del servizio più ampio. L'RTO viene solitamente espresso in termini di durata dal momento in cui il database primario non è disponibile. Ad esempio, l'app deve essere completamente operativa entro 5 minuti. Il caso più impegnativo è immediato, per cui gli utenti delle app non si accorgono dell'esecuzione del ripristino di emergenza.
- Dominio single point of failure. Spetta a te decidere se una regione è considerata un dominio single point of failure per i tuoi requisiti di ripristino di emergenza. Se una regione è un dominio single point of failure, devi configurare il ripristino di emergenza in modo che coinvolgano due o più regioni nella configurazione effettiva. In caso di errore della regione contenente il database principale, il database secondario in un'altra regione diventa il nuovo database principale. Se si presume che il dominio single point of failure sia una zona, il ripristino di emergenza può essere configurato in più zone all'interno di una singola regione. In caso di errore in una zona, il ripristino di emergenza utilizza una seconda zona e rende disponibile al suo interno il nuovo database principale.
Scegliere queste dimensioni chiave significa prendere una decisione tra costo e qualità. Più bassi sono l'RTO e l'RPO, più costosa può diventare la soluzione di ripristino di emergenza con l'utilizzo di più risorse attive. Nelle sezioni seguenti vengono descritte diverse strategie di RE alternative che rappresentano punti sulle dimensioni nel contesto del database Microsoft SQL Server.
Strategie di RE per SQL Server
Continuità aziendale e ripristino del database - SQL Server descrive le funzionalità di disponibilità che puoi utilizzare per implementare strategie di ripristino di emergenza.
Preliminari
SQL Server viene eseguito sia su Windows sia su Linux. Tuttavia, non tutte le funzioni di disponibilità sono disponibili su Linux. SQL Server ha diverse versioni, ma non tutte le funzionalità di disponibilità sono disponibili in ogni versione.
SQL Server distingue le istanze dai database. Un'istanza è il software SQL Server in esecuzione, mentre un database è l'insieme di dati gestito da un'istanza di SQL Server.
Gruppi di disponibilità sempre attivi
I gruppi di disponibilità sempre attivi forniscono una protezione a livello di database. Un gruppo di disponibilità ha due o più repliche. Una replica è la replica principale con accesso in lettura e scrittura e le repliche rimanenti sono repliche secondarie che possono fornire accesso in lettura. Ogni replica del database è gestita da un'istanza SQL Server autonoma. Un gruppo di disponibilità può contenere uno o più database. Il numero di database che possono essere inclusi in un gruppo di disponibilità e il numero di repliche secondarie supportate dipende dalla versione di SQL Server. Tutti i database di un gruppo di disponibilità vengono sottoposti contemporaneamente alle stesse modifiche del ciclo di vita. I gruppi di disponibilità implementano la modalità attivo-passivo perché solo il database primario supporta l'accesso in scrittura.
In caso di failover, una replica secondaria diventa la nuova replica principale. Poiché un gruppo di disponibilità include istanze SQL Server autonome, tutte le operazioni acquisite nei log delle transazioni sono disponibili nelle repliche. Qualsiasi modifica non acquisita in un log delle transazioni deve essere sincronizzata manualmente, ad esempio gli accessi a livello di istanza SQL Server o i job di SQL Server Agent. Per fornire una protezione a livello di database e una protezione delle istanze SQL Server, devi configurare le istanze del cluster di failover (FCI). Questa architettura di deployment verrà discussa più avanti nella sezione Istanza cluster di failover sempre attivo.
Puoi proteggere le app dalle modifiche dei ruoli utilizzando un listener. Un listener supporta le app che si connettono al gruppo di disponibilità. Le app non sanno quali istanze SQL Server gestiscono il database principale o le repliche secondarie in qualsiasi momento. I listener richiedono che i client utilizzino almeno una versione .NET pari a 3.5 con un aggiornamento oppure 4.0 e versioni successive, come descritto in Business continuity e ripristino del database - SQL Server.
I gruppi di disponibilità si basano sui livelli di astrazione sottostanti per fornire la loro funzionalità. I gruppi di disponibilità vengono eseguiti in un cluster di failover di Windows Server (WSFC) come descritto in Cluster di failover di Windows Server con SQL Server. Tutti i nodi che eseguono istanze SQL Server devono far parte della stessa WSFC.
Le transazioni vengono inviate dal database principale a tutte le repliche secondarie. Esistono due modalità di invio per inviare le transazioni: sincrono e asincrono. Puoi configurare in modo indipendente ogni replica in modo che utilizzi l'una o l'altra modalità. Nella modalità di invio sincrona, la transazione sul database principale ha esito positivo solo se ha esito positivo su tutte le repliche secondarie collegate in modo sincrono. In modalità asincrona, la transazione sul database principale può avere esito positivo anche se la transazione non è applicata a tutte le repliche secondarie.
La scelta della modalità di invio influenza l'RTO, l'RPO e la modalità standby possibili. Ad esempio, se le transazioni vengono inviate a tutte le repliche in modalità sincrona, tutte le repliche si trovano nello stesso esatto stato. L'RPO (transazione più recente) più impegnativa viene soddisfatta poiché tutte le repliche sono completamente sincronizzate. Le repliche secondarie sono hot standby, quindi ognuna di queste può essere utilizzata immediatamente come database principale.
Il failover può essere automatico o manuale. Se tutte le repliche sono completamente sincronizzate, è possibile un failover automatico. Nell'esempio precedente, ciò è possibile perché tutte le repliche sono sempre completamente sincronizzate.
La figura seguente mostra un gruppo di disponibilità Sempre attivo in una singola regione.
Il gruppo di disponibilità è rappresentato da un rettangolo che comprende varie zone. Questo è a solo scopo illustrativo per indicare che tutti i database appartengono allo stesso gruppo di disponibilità. Il gruppo di disponibilità non è una risorsa cloud e, come tale, non è implementato in un nodo o in qualsiasi altro tipo di risorsa.
Istanza cluster di failover sempre attiva
Per evitare errori dei nodi, puoi utilizzare istanze di cluster di failover (FCI) anziché istanze SQL Server autonome. Sono presenti due o più nodi che eseguono istanze SQL Server per gestire un database (principale o secondario). I nodi che gestiscono un database formano un cluster di failover. Un nodo nel cluster esegue attivamente un'istanza SQL Server, mentre gli altri nodi non eseguono istanze di SQL Server. In caso di errore del nodo che esegue l'istanza SQL Server, un altro nodo nel cluster avvia un'istanza SQL Server, prendendo in carico la gestione del database (failover del nodo). Questo processo di avvio automatico di un'istanza SQL Server fornisce funzionalità ad alta disponibilità.
Il cluster FCI appare come una singola unità e i client che accedono al cluster non vedono il failover tra i nodi, tranne forse per un breve periodo di indisponibilità. Non si verifica alcuna perdita di dati quando si verifica un failover dei nodi. Tutto ciò che è in esecuzione all'interno dell'istanza di SQL Server non riuscita viene spostato in un'altra istanza di SQL Server nello stesso cluster. Ad esempio, i job SQL Server Agent o i server collegati vengono spostati in un'altra istanza.
I nodi dei cluster FCI possono essere configurati in zone Google Cloud diverse. Questa architettura non solo offre disponibilità elevata in caso di errore dei nodi, ma anche per gli errori di zona. Un esempio di deployment di questa strategia è discusso nella sezione relativa alle alternative di deployment di RE.
Anche se nodi diversi gestiscono lo stesso database e lo condividono, non è richiesta alcuna archiviazione comune tra i nodi di un cluster FCI. SQL Server utilizza la funzionalità Storage Space Direct (S2D) per gestire i database sui dischi dei nodi dedicati. Per maggiori informazioni, consulta Configurazione delle istanze del cluster di failover di SQL Server.
La figura seguente mostra l'esempio della sezione precedente Gruppi di disponibilità sempre attivi con FCI anziché istanze SQL Server autonome. Ogni FCI ha un'istanza SQL Server attiva che gestisce il database.
Come nel caso del gruppo di disponibilità, FCI è rappresentato da un rettangolo. Questo è solo a scopo illustrativo per indicare che tutti i nodi appartengono allo stesso FCI. Un FCI non è una risorsa cloud e, come tale, non è implementata in un nodo o in qualsiasi altro tipo di risorsa.
Per una discussione più dettagliata, consulta Istanze dei cluster di failover sempre attive (SQL Server).
Gruppi di disponibilità distribuiti
I gruppi di disponibilità distribuiti sono un tipo speciale di gruppo di disponibilità. Un gruppo di disponibilità distribuito comprende due gruppi di disponibilità: uno nel ruolo del gruppo di disponibilità principale e l'altro nel ruolo del gruppo di disponibilità secondario. I gruppi di disponibilità distribuiti possono inoltrare le transazioni in modalità sincrona e asincrona dal gruppo di disponibilità principale al gruppo di disponibilità secondario.
Anche se ogni gruppo di disponibilità dispone di un proprio database principale, non si tratta di un deployment attivo-attivo. Solo il database primario del gruppo di disponibilità primario può ricevere operazioni di scrittura. Il database principale del gruppo di disponibilità secondario è chiamato forwarding. L'inoltro riceve le transazioni dal gruppo di disponibilità principale e le inoltra ai database secondari del gruppo di disponibilità secondario. Un failover dal gruppo di disponibilità principale al gruppo di disponibilità secondario renderebbe accessibile il database principale del nuovo gruppo di disponibilità principale per le operazioni di scrittura.
I gruppi di disponibilità primari e secondari non devono trovarsi nella stessa località e non è necessario che si trovino nello stesso sistema operativo. Tuttavia, per ogni gruppo di disponibilità deve essere installato un listener. Il gruppo di disponibilità distribuita in sé non ha un listener. I gruppi di disponibilità distribuiti non richiedono che i due gruppi di disponibilità si trovino nello stesso WSFC. Tutte le funzionalità necessarie per far funzionare i gruppi di disponibilità distribuiti sono contenute nella funzionalità SQL Server e non richiede l'installazione aggiuntiva dei componenti sottostanti.
Un gruppo di disponibilità distribuito comprende esattamente due gruppi di disponibilità. Un gruppo di disponibilità può far parte di due gruppi di disponibilità distribuiti. Questa possibilità supporta diverse topologie. Una è una topologia daisy chain dal gruppo di disponibilità al gruppo di disponibilità in più località. Un'altra topologia è una topologia ad albero, in cui il gruppo di disponibilità principale fa parte di due gruppi di disponibilità distribuiti diversi e separati.
I gruppi di disponibilità distribuiti sono lo strumento principale per implementare il ripristino di emergenza nei sistemi operativi. Ad esempio, il gruppo di disponibilità principale può essere configurato su Windows e un secondo gruppo di disponibilità corrispondente su Linux, con entrambi i gruppi di disponibilità che formano un gruppo di disponibilità distribuito.
Il seguente diagramma mostra due gruppi di disponibilità che fanno parte di un gruppo di disponibilità distribuito.
Il gruppo di disponibilità 1 è il gruppo di disponibilità principale e il gruppo di disponibilità 2 è il gruppo di disponibilità secondario.
Come nel caso degli FCI, un gruppo di disponibilità distribuito è rappresentato da un rettangolo. Questo è a solo scopo illustrativo per indicare che i gruppi di disponibilità appartengono tutti allo stesso gruppo di disponibilità distribuito. Un gruppo di disponibilità distribuito, ad esempio un gruppo di disponibilità, non è una risorsa cloud e, di conseguenza, non è implementato in un nodo o in qualsiasi altro tipo di risorsa.
Per maggiori informazioni, consulta Gruppi di disponibilità distribuiti.
Registra spedizione
La spedizione dei log delle transazioni è una funzionalità di disponibilità di SQL Server quando RTO e RPO non sono così rigidi (RTO basso e/o RPO recente) perché la discrepanza di stato tra un database principale e il relativo database secondario è notevolmente maggiore. La discrepanza è maggiore in termini di stato perché un file di log delle transazioni contiene molte modifiche di stato. La discrepanza è maggiore anche in termini di tempo di attesa, perché i file di log delle transazioni vengono trasferiti in modo asincrono e devono essere applicati nella loro interezza a un database secondario.
I file di log delle transazioni vengono creati dal database principale e ne viene eseguito il backup, ad esempio, in Cloud Storage. Ogni file di log delle transazioni viene copiato in ogni database secondario e vi viene applicato. Poiché il database secondario è in ritardo rispetto al database primario, è in modalità standby caldo. Gli oggetti e le modifiche non acquisite dai log delle transazioni devono essere applicati manualmente ai database secondari per consentire una sincronizzazione completa senza perdite.
L'agente SQL Server automatizza il processo complessivo di creazione, copia e applicazione dei log delle transazioni. La spedizione dei log deve essere impostata singolarmente per ogni database. Se un gruppo di disponibilità gestisce più di un database, è necessario configurare molti processi di spedizione dei log.
In caso di errore, il processo di ripristino di emergenza deve essere avviato manualmente poiché non è disponibile assistenza automatica. Inoltre, l'accesso client non è astratto dal database principale e dai database secondari da un listener. In caso di failover, i client devono essere in grado di gestire autonomamente la modifica del ruolo di un database passando dal ruolo secondario al nuovo ruolo principale connettendosi al nuovo ruolo principale dopo un ripristino di emergenza. È possibile creare astrazioni separate indipendentemente dalle istanze SQL Server, ad esempio indirizzi IP mobili come descritto in Best practice per gli indirizzi IP mobili.
Poiché la spedizione dei log è in parte un processo manuale, puoi ritardare l'applicazione intenzionale dei file di log copiati ai database secondari (a differenza dei gruppi di disponibilità e dei gruppi di disponibilità distribuiti in cui le modifiche vengono applicate immediatamente). Un possibile caso d'uso impedisce che gli errori di modifica dei dati nel database principale vengano applicati ai database secondari finché questi ultimi non vengono risolti. In questo caso, un database secondario a cui non è ancora applicato un errore di modifica dei dati potrebbe diventare il database principale fino a quando l'errore di modifica dei dati non viene risolto. Dopodiché potrà riprendere la normale elaborazione.
Come nel caso dei gruppi di disponibilità distribuiti, puoi utilizzare la spedizione dei log per le soluzioni multipiattaforma in cui, ad esempio, il database principale è in esecuzione su Linux, mentre i database secondari su Linux e Windows.
Il seguente diagramma illustra un deployment multipiattaforma con logshipping. Tieni presente che in questa topologia non esiste una configurazione comune in tutte le regioni, ad esempio un gruppo di disponibilità distribuita.
I gruppi di disponibilità si trovano in regioni separate, una in esecuzione su Linux e l'altra su Windows.
Per ulteriori informazioni sulla spedizione dei log di SQL Server, consulta Informazioni sulla spedizione dei log (SQL Server).
Combinazione delle funzionalità di disponibilità di SQL Server
Puoi eseguire il deployment delle funzionalità di disponibilità di SQL Server in diverse combinazioni. Ad esempio, nel caso d'uso precedente, è stata utilizzata la spedizione dei log con diversi gruppi di disponibilità installati su sistemi operativi diversi.
Di seguito è riportato un elenco di possibili combinazioni di funzionalità di disponibilità di SQL Server:
- Utilizza la spedizione dei log tra i gruppi di disponibilità installati sullo stesso sistema operativo.
- Avere un gruppo di disponibilità principale che utilizza gli FCI con un gruppo di disponibilità secondario che utilizza solo istanze autonome di SQL Server.
- Utilizza un gruppo di disponibilità distribuito tra regioni vicine e la spedizione dei log in più regioni in diversi continenti.
Queste sono solo alcune delle possibili combinazioni di funzionalità di disponibilità di SQL Server.
La flessibilità offerta dalle funzionalità di disponibilità di SQL Server per supportare l'ottimizzazione di una strategia di ripristino di emergenza in base ai requisiti indicati.
Replica SQL Server
In genere la replica SQL Server non è considerata una funzionalità di disponibilità, ma questa sezione descrive brevemente come può essere utilizzata per il ripristino di emergenza.
La funzionalità di replica supporta la creazione e la manutenzione di repliche di database. Diversi tipi di agenti SQL Server collaborano per acquisire le modifiche, trasmettere le modifiche acquisite e applicarle alle repliche. Questo processo è asincrono e le repliche di solito sono indietro di vari gradi rispetto al database di replica.
Ad esempio, è possibile avere una replica di un database di produzione. In termini di ripristino di emergenza, il database di produzione è il database principale e la replica è il database secondario. La funzionalità di replica SQL Server non sa che i database assumono ruoli diversi nel contesto del ripristino di emergenza. Quindi, la replica non include operazioni che supportano il processo di ripristino di emergenza, ad esempio le modifiche ai ruoli. Il processo di ripristino di emergenza deve essere implementato separatamente dalla funzionalità SQL Server ed eseguito dall'organizzazione che lo implementa in quanto non ci sono astrazioni di accesso client.
Spedizione dei file di backup
La spedizione dei file di backup è un'altra strategia di implementazione del ripristino di emergenza. Un approccio standard alla configurazione e all'aggiornamento continuo di un database secondario prevede l'esecuzione di un backup iniziale completo del database principale e dei backup incrementali in seguito. Tutti i backup incrementali vengono applicati ai database secondari nell'ordine corretto. Esistono molte varianti di questo approccio a seconda della frequenza dei backup incrementali e della posizione di archiviazione dei file di backup (posizione globale o effettivamente copiata tra le località).
Questa strategia non prevede alcuna funzionalità di disponibilità di SQL Server durante la replica delle modifiche dello stato dal database primario a qualsiasi database secondario. Non utilizza l'agente SQL Server utilizzato nel caso di spedizione dei log.
Per ulteriori informazioni, consulta la sezione Esempio: strategia di RE di backup e ripristino.
Istruzioni dettagliate per il backup e il ripristino di SQL Server sono descritte nella seguente soluzione: Utilizzo dei backup di Microsoft SQL Server per il recupero point-in-time su Compute Engine.
Rispetto all'approccio di replica discusso nella sezione precedente, sia l'invio dei file di replica che quello di backup hanno in comune il fatto che il processo di ripristino di emergenza sia implementato all'esterno e separato dal set di funzionalità di SQL Server. Dal punto di vista dell'invio delle modifiche acquisite, la replica SQL Server è più comoda in quanto implementa automaticamente questa parte tramite agenti SQL Server.
Nota sull'interazione tra il ciclo di vita del database e il ciclo di vita dell'app
Il failover del database non è completamente separato e non indipendente dalle app che accedono al database. In linea di principio, ci sono due scenari di errore.
Innanzitutto, l'app rimane operativa durante l'esecuzione del failover del database. Dal momento in cui il database principale non è disponibile fino al momento in cui il nuovo database primario è operativo, le app non possono accedere affatto al database. Le connessioni esistenti non riescono e non ne vengono stabilite di nuove. Durante questo periodo, l'app non è in grado di gestire i client, almeno nella misura in cui la funzionalità richiede l'accesso al database. Le app devono riconoscere quando è disponibile il nuovo database primario per poter riprendere la normale elaborazione.
Le app potrebbero avere uno stato esterno al database, ad esempio nelle cache della memoria principale. L'app si assicura che la cache sia coerente (sincronizzata) con il nuovo database principale. Se non si è verificata alcuna perdita di transazioni durante il failover, la cache potrebbe essere coerente senza ulteriore manutenzione. Tuttavia, se si verifica la perdita di transazioni (dati) durante il failover, la cache potrebbe non essere coerente in relazione al nuovo database primario. La discussione analoga si applica allo stato condiviso quando, ad esempio, alcuni dati nel database fanno parte anche di messaggi in code o file nel file system. Questo aspetto della coerenza dei dati non rientra nell'ambito di questo documento perché non è direttamente correlato al ripristino di emergenza del database.
In secondo luogo, una o più app potrebbero non essere più disponibili contemporaneamente al momento in cui il database principale diventa non disponibile. Ad esempio, se una regione non è disponibile, un sistema di applicazioni in esecuzione in quella regione non sarà disponibile come il database principale nella stessa regione. In questo caso, deve essere recuperata anche l'app, non solo il sistema di database principale. Insieme al processo di ripristino di emergenza del database, devi avviare una procedura di ripristino dell'app simile. L'app recuperata deve connettersi al nuovo database principale ed essere riconfigurata (ad esempio, indirizzi IP mobili). Il recupero delle app non rientra nell'ambito di questo documento.
Relazione tra backup e ripristino nel ripristino di emergenza
Il backup di un database è indipendente e ortogonale al ripristino di emergenza del database. Lo scopo del backup del database è essere in grado di ripristinare uno stato coerente, ad esempio nel caso in cui un database venga perso o danneggiato oppure sia necessario ripristinare uno stato precedente a causa di errori o bug dell'app. Backup, archiviazione e ripristino nel contesto di Google Cloud sono trattati in Utilizzo dei backup di Microsoft SQL Server per il recupero point-in-time su Compute Engine.
La sezione seguente illustra come utilizzare i backup come un possibile meccanismo per implementare il ripristino di emergenza del database. In questo scenario, dovrai copiare i file di backup nella posizione del database secondario in modo che possa essere ripristinato. Tuttavia, i file di backup non sono un prerequisito per il ripristino di emergenza; la precedente discussione sulle funzionalità di disponibilità ha presentato alternative.
Alta disponibilità e ripristino di emergenza
Sia l'alta disponibilità che il ripristino di emergenza hanno in comune il fatto di fornire soluzioni per la non disponibilità del database. Se un database primario non è disponibile, allora un database secondario diventa il nuovo database primario coerente e disponibile.
La differenza tra alta disponibilità e ripristino di emergenza è il dominio single point of failure. L'alta disponibilità risolve un'interruzione all'interno di una regione, ad esempio in caso di guasto di una singola zona o di un nodo. Una soluzione ad alta disponibilità fornisce un nuovo database primario in un'altra zona nella stessa regione. Inoltre, l'alta disponibilità consente di risolvere gli errori dei nodi, non solo quelli del database. In caso di errore di un nodo che esegue un'istanza SQL Server, viene reso disponibile un nuovo nodo che esegue una nuova istanza SQL Server (consulta la discussione nella sezione Istanza del cluster di failover sempre attiva).
Il ripristino di emergenza coinvolge almeno due regioni. Riguarda il caso in cui un'intera regione non è più disponibile. Il ripristino di emergenza può fornire un nuovo database primario in un'altra regione.
Le funzionalità ad alta disponibilità di SQL Server supportano contemporaneamente soluzioni per l'alta disponibilità e il ripristino di emergenza. Un singolo gruppo di disponibilità può abbracciare le zone di una regione e le regioni stesse. Un gruppo di disponibilità può contenere istanze di cluster di failover per gestire l'alta disponibilità.
SQL Server può stabilire gruppi di disponibilità all'interno di una regione per errori di zona e disponibilità elevata e combinarli con la spedizione dei log tra regioni diverse per affrontare il ripristino di emergenza.
Alternative di deployment di RE
Nelle sezioni seguenti vengono mostrate alcune possibili topologie di ripristino di emergenza in aggiunta a quelle discusse finora. Queste topologie soddisfano requisiti di RPO e RTO diversi. L'elenco non è esaustivo.
RE e alta disponibilità intraregionali
Questo deployment è una variante di un gruppo di disponibilità contenente gli FCI, all'interno di una regione composta da tre zone. In questo scenario, le zone sono considerate il dominio single point of failure.
Rispetto al deployment mostrato in precedenza, ogni FCI è composta da tre nodi in cui ogni nodo è in esecuzione in una zona diversa. Il vantaggio di questa configurazione è che una o due zone possono avere esito negativo senza richiedere un processo di ripristino di emergenza.
Il seguente diagramma mostra questa configurazione.
Gli FCI coprono tutte le zone e ogni FCI ha un'istanza SQL Server in esecuzione che accede al database corrispondente. Esistono altre due istanze SQL Server non in esecuzione in ogni FCI che possono essere avviate in caso di errore di una zona. I database sono mostrati in più zone poiché ogni database utilizza i dischi di tutti i nodi in un determinato FCI. L'app non viene mostrata per chiarezza.
RE interregionale: gruppo di disponibilità che comprende le regioni
In questo scenario, un gruppo di disponibilità viene eseguito su un cluster di failover di Windows Server e copre due regioni. Le regioni sono considerate un dominio single point of failure.
Il seguente diagramma illustra questa configurazione.
Per risolvere potenziali problemi di latenza, puoi configurare le repliche all'interno della regione R1 in modo che utilizzino la propagazione sincrona delle transazioni, mentre le repliche nella regione R2 sono configurate per l'utilizzo della propagazione asincrona delle transazioni.
RE interregionale: trasferimento di file di backup
Questo scenario utilizza il trasferimento di file di backup. Sono collegati due gruppi di disponibilità in due regioni. Ogni gruppo di disponibilità ha le sue repliche che ricevono le transazioni in modo sincrono, perciò le repliche secondarie di ogni regione sono in una configurazione in modalità hot standby.
Il seguente diagramma illustra questa configurazione.
Tuttavia, i due gruppi di disponibilità vengono collegati tramite il trasferimento di file di backup. Il gruppo di disponibilità AG1 è il gruppo di disponibilità principale, mentre il gruppo di disponibilità AG2 è il gruppo di disponibilità secondario. Quando i file di backup sono resi disponibili per il gruppo di disponibilità secondario, vengono applicati lì. Questo scenario è discusso in modo più dettagliato nella sezione seguente, Esempio: strategia di RE di backup e ripristino.
Doppia località e topologia di località terziaria
Se sono presenti solo due database, uno principale e uno secondario, ciascuno in una regione separata, il periodo non protetto dopo un errore dal momento in cui il nuovo database primario è in esecuzione e il nuovo database secondario è pronto. Se il nuovo database principale non è disponibile mentre il database secondario non è ancora in esecuzione, si verifica un tempo di inattività rigido che può essere recuperato solo a partire dalla creazione di un nuovo database primario. Lo stesso vale per i gruppi di disponibilità.
Una terza località che esegue un altro database o gruppo di disponibilità secondario può eliminare la durata non protetta dopo un failover. Questa configurazione deve garantire che uno dei due database secondari rimanga un database secondario e venga riassegnato a un nuovo database primario in modo che non si verifichi alcuna perdita di dati. Lo stesso vale per i gruppi di disponibilità.
Ciclo di vita di ripristino di emergenza
A prescindere dalla soluzione di ripristino di emergenza scelta, esistono passaggi comuni del ciclo di vita.
In una situazione di ripristino di emergenza reale, tutti gli stakeholder (proprietari delle app, gruppi operativi e amministratori di database) devono essere disponibili e partecipare attivamente alla gestione del ripristino di emergenza. Gli stakeholder devono decidere l'autorità decisionale (talvolta definita master of ceremony) e i processi decisionali che seguono. Inoltre, gli stakeholder devono concordare sulla terminologia e sui metodi di comunicazione.
Decisione sull'avvio di un processo di failover
A meno che il failover non venga avviato automaticamente, gli stakeholder devono decidere di avviarlo. I vari stakeholder devono coordinarsi strettamente sulla decisione quando decidono di avviare il failover.
L'avvio di un processo di failover dipende da diversi fattori, principalmente dalla causa principale del database primario che diventa non disponibile.
Se il processo di ripristino di emergenza richiede più tempo del tempo previsto per risolvere l'indisponibilità del database primario, un failover sarebbe dannoso. Innanzitutto, devi valutare se il ripristino del database primario è un'opzione fattibile.
Migliore è la valutazione della strategia di ripristino di emergenza e più rapida viene implementata, più facile sarà l'avvio del processo di failover, poiché la decisione dovrà prendere in considerazione meno incertezze.
Esecuzione del processo di failover
Idealmente, il processo di failover viene testato regolarmente e, pertanto, ben noto ai vari stakeholder.
L'autorità decisionale deve essere a conoscenza di tutti i passaggi in corso e di tutti i problemi imprevisti che si presentano. L'autorità decisionale guida il processo di failover e gli stakeholder sono responsabili del supporto dell'autorità decisionale.
Dovresti conservare le statistiche per l'analisi post mortem e il miglioramento del processo di failover, comprese la durata delle attività, i problemi emersi e l'eventuale confusione nei passaggi del processo.
Protezione mancante
Se hai un solo database secondario, dal momento in cui il nuovo database primario è disponibile e operativo fino alla configurazione di quello secondario, non esiste alcuna protezione RE. Un'indisponibilità durante questo periodo potrebbe causare un tempo di inattività rigido, perché non è possibile alcun failover a un altro database. Se si verifica questa situazione, è necessario configurare un altro database principale e l'RPA è l'ultimo punto che può essere ricostruito in base ai backup disponibili.
A meno che la strategia di ripristino di emergenza non sia impostata in modo da garantire protezione in ogni momento, ogni stakeholder deve essere consapevole di questa durata della mancanza di protezione per adottare precauzioni aggiuntive durante le modifiche alla configurazione o alla configurazione dell'ambiente.
Puoi evitare questo periodo non protetto se l'accesso dell'app al nuovo database primario viene ritardato finché il nuovo database secondario non è in esecuzione. Non appena vengono applicate le modifiche del database primario, il database primario è disponibile per le app. Sebbene questo approccio eviti ogni volta in cui le app non sono protette dal RE, ritarda il completamento del processo di ripristino di emergenza.
Evita situazioni divise
È importante che le app non possano accedere contemporaneamente a un database primario e a un database secondario, eseguendo operazioni DML. In questa situazione si verifica un'incoerenza tra i dati e il database principale e quello secondario non sono d'accordo sui valori dei dati dello stesso elemento di dati (Split-brain). Questa architettura è particolarmente importante se il database primario non è disponibile mentre è in esecuzione e può ricevere operazioni di scrittura. Se l'indisponibilità è causata da un partizionamento di rete intermittente, il partizionamento può interrompersi in qualsiasi momento e un'app potrebbe accedere di nuovo. Se in quel momento è in corso un processo di failover, le modifiche al database primario precedente potrebbero andare perse o alcune app iniziano a funzionare sul nuovo database principale mentre altre accedono ancora al database primario precedente.
L'accesso a tutte le app è disattivato per qualsiasi database durante il processo di failover in modo che non sia possibile modificare lo stato in nessuno dei database. Dopo il failover, è disponibile un solo database per le operazioni di scrittura: il nuovo database primario.
Dichiarazione di completamento
Dopo il completamento del processo di failover, tutti gli stakeholder devono essere informati esplicitamente dall'autorità decisionale dell'esecuzione del processo. Qualsiasi problema che si verifica dopo il completamento deve essere trattato come un incidente separato che non fa più parte del processo di failover, ma parte della normale elaborazione. Il problema potrebbe essere una conseguenza di un problema relativo al processo di failover o un problema indipendente nel complesso. Tuttavia, l'approccio per affrontare il problema dopo il completamento del processo di failover potrebbe essere diverso da come viene gestito durante l'esecuzione del processo di failover.
Analisi e report post mortem
Come riferimento futuro e per migliorare il processo di failover, organizza immediatamente un'analisi post mortem per prendere nota di aspetti, risultati e azioni importanti.
Scrivi un report che riassuma l'evento di ripristino di emergenza, le cause principali e tutte le azioni intraprese. Questo report potrebbe essere obbligatorio se implementi dei requisiti normativi.
Test e verifica di RE
Poiché il ripristino di emergenza non fa parte delle normali operazioni quotidiane, la soluzione di RE deve essere testata regolarmente per verificarne il corretto funzionamento quando è effettivamente necessaria.
La frequenza dei test dipende dai requisiti operativi e varia a seconda del database, dell'app e dell'azienda. Inoltre, modifiche all'ambiente, come modifiche alla configurazione di rete e aggiornamenti dei componenti dell'infrastruttura, dovrebbero attivare un test di ripristino di emergenza se vengono apportate modifiche ai sistemi su cui fa affidamento la soluzione di ripristino di emergenza scelta. Qualsiasi modifica potrebbe causare l'esito negativo della soluzione di ripristino di emergenza o richiedere la modifica del processo di ripristino.
Puoi eseguire test manualmente avviando il processo di commutazione oppure automaticamente seguendo un approccio ingegneristico del caos come descritto nell'ingegneria del caos. Con i test manuali, puoi ridurre al minimo l'impatto sull'attività nel caso in cui sia previsto un tempo di inattività considerevole.
Un aspetto importante dei test è la raccolta di statistiche ben definite. Ecco alcune statistiche importanti da considerare:
- Recupero effettivo: misura il tempo di ripristino effettivo e confrontalo con l'RTO.
- Recovery Point effettivo: osserva il punto di ripristino effettivo e confrontalo con l'RPO.
- Rilevamento del time to failure: il tempo impiegato dal database o dal team operativo per comprendere la necessità del failover.
- Tempo per l'avvio del ripristino: il tempo necessario per avviare il processo di failover dopo il rilevamento dell'errore.
- Affidabilità: quanto è stato seguito il processo di failover o sono state necessarie deviazioni? Si sono verificati problemi imprevisti che hanno bisogno di un'indagine e che potrebbero aver portato a un cambiamento nella strategia di ripristino?
In base alle statistiche raccolte, potrebbe essere necessario adeguare o migliorare il processo di failover per soddisfare meglio le aspettative dell'RPO e dell'RTO.
Esempio: strategia di RE di backup e ripristino
Le seguenti sezioni descrivono una strategia di esempio di ripristino di emergenza di backup e ripristino. Questo scenario riduce al minimo l'uso delle funzionalità di disponibilità di SQL Server per dimostrare lo sforzo richiesto per specificare una strategia di backup e ripristino di RE e per discutere aspetti invisibili in configurazioni più automatizzate. e fa riferimento alla soluzione correlata, Utilizzo dei backup di Microsoft SQL Server per il recupero point-in-time su Compute Engine.
Caso d'uso
Nella regione R1 è presente un gruppo di disponibilità sempre attivo principale, operativo. Il gruppo di disponibilità sempre attivo secondario viene aggiunto nella regione R2 per un'ulteriore protezione tra regioni ed è disponibile come destinazione di failover o commutazione.
Strategia
La strategia di ripristino di emergenza si basa sui backup del database. Viene eseguito un backup iniziale completo seguito dai backup differenziali successivi. I backup vengono applicati al gruppo di disponibilità sempre attivo secondario man mano che vengono eseguiti. Tutti i backup sono archiviati in un bucket Cloud Storage.
In questo esempio, dopo il completamento del failover è accettabile che il nuovo gruppo di disponibilità sempre attivo principale in R2 sia attivo e non protetto per un periodo di tempo limitato finché il nuovo gruppo di disponibilità sempre attivo secondario in R1 non è operativo.
Non deve avvenire alcun elemento di riserva, poiché il gruppo di disponibilità Always On in ciascuna area geografica è idoneo per fungere da gruppo di disponibilità sempre attivo di produzione.
RTO e RPO
In questo esempio, l'RPO è definito come un massimo di 60 minuti, quindi viene eseguito un backup differenziale ogni 60 minuti.
L'RTO non è impostato esplicitamente su una durata di tempo, ma deve essere il più minimo possibile: l'immediato è il caso migliore. Il gruppo di disponibilità secondario deve essere configurato come hot standby. In caso di hot standby, tutti i backup vengono applicati immediatamente, in modo che il failover non subisca ritardi nell'applicazione dei backup.
Strategia generale di RE
Le sezioni seguenti descrivono la strategia di RE. Si tratta di un testo breve per concentrarsi sui passaggi essenziali.
Impostazione iniziale
- Crea un gruppo di disponibilità sempre attivo secondario nella regione R2.
- Impedisci l'accesso dell'app al gruppo di disponibilità secondario in modo che non si verifichi accidentalmente la situazione del cervello diviso.
- Crea il bucket di file di backup B1 in Cloud Storage per contenere il backup completo iniziale del gruppo di disponibilità Always On in R1 e i backup orari differenziali successivi del gruppo di disponibilità Always On in R1. È necessario stabilire l'ordine corretto dei backup differenziali in modo che il processo di applicazione dei backup al gruppo di disponibilità secondario possa dedurre l'ordine corretto. Un approccio potrebbe essere una convenzione di denominazione che consente di stabilire l'ordine cronologico corretto in base alla data e all'ora che fanno parte dei vari nomi di file.
Strategia di lancio
- Applica il backup completo al gruppo di disponibilità sempre attivo secondario nella regione R2.
- Man mano che i backup differenziali diventano disponibili, applicali immediatamente al gruppo di disponibilità sempre attivo secondario in R2. È necessaria un'applicazione immediata per gestire l'RTO.
- Dopo aver applicato il backup completo iniziale e tutti i backup incrementali, il gruppo di disponibilità sempre attivo secondario è pronto.
- Testare la strategia di RE eseguendo un passaggio dal gruppo di disponibilità principale a quello secondario. Durante il test deve essere disponibile almeno un backup incrementale.
Failover o caso di passaggio
In R2, i passaggi essenziali sono i seguenti:
- Assicurati che l'ultimo backup differenziale sia stato applicato al gruppo di disponibilità sempre attivo secondario in R2.
- Specifica R2 come nuovo gruppo di disponibilità sempre attivo principale.
- Crea un nuovo bucket B2, esegui un backup completo come base e apri il nuovo gruppo di disponibilità principale per l'accesso all'app.
- Inizia a eseguire backup differenziali.
In R1, i passaggi essenziali sono i seguenti:
- Rimuovi il bucket B1 perché non è più necessario.
- Quando il gruppo di disponibilità Sempre attivo in R1 diventa di nuovo disponibile (come nuovo gruppo di disponibilità sempre attivo secondario), impedisci l'accesso all'app e rimuovi tutti i dati dal database o reimpostali allo stato iniziale (vuoto) (a meno che non sia stato creato di recente).
- Applica il backup completo dal nuovo gruppo di disponibilità sempre attivo principale in R2 e continua ad applicare i backup differenziali immediatamente non appena diventano disponibili (archiviati nel bucket B2).
Possibili miglioramenti
Un possibile miglioramento alla strategia di RE consiste nell'evitare di eseguire un backup completo dopo un failover o un cambio di versione, pur continuando a configurare rapidamente il nuovo gruppo di disponibilità secondario. Anziché un unico backup completo e backup differenziali successivi, esegui un backup completo ogni settimana e crea un bucket settimanale che contenga il backup completo della settimana e tutti i backup differenziali successivi per quella settimana. Il nuovo gruppo di disponibilità principale deve creare backup differenziali solo dopo il failover (e non un backup completo) e aggiungerli al bucket. Il nuovo gruppo di disponibilità secondario applica semplicemente tutti i backup nel bucket della settimana corrente. Se utilizzi questo approccio settimanale, devi implementare una strategia di pulizia o di eliminazione definitiva per rimuovere i backup obsoleti.
Un altro miglioramento è basato sul fatto che il nuovo gruppo di disponibilità secondario era il precedente gruppo di disponibilità principale. Se il database esiste ed è operativo dopo essere stato di nuovo disponibile, un ripristino point-in-time all'ultimo backup differenziale evita di doverlo ripristinare completamente dall'ultimo backup completo come descritto in Ripristinare un database SQL Server in un momento specifico (modello di recupero completo). Questo scenario riduce l'impegno e il periodo di tempo in cui il nuovo gruppo di disponibilità principale non è protetto.
Best practice per la produzione
Questa soluzione non specifica se le istanze SQL Server nei gruppi di disponibilità sempre attivi sono istanze autonome o FCI. Il tipo di istanze utilizzate deve essere deciso prima dell'implementazione.
Fino a quando un nuovo gruppo di disponibilità sempre attivo secondario non è operativo dopo un failover, c'è un momento in cui RE non è protetto. Devi configurare un terzo gruppo di disponibilità sempre attivo in una terza regione.
Inoltre, devi implementare il monitoraggio per garantire che vengano rilevati guasti o errori. Il monitoraggio non rientra nell'ambito di questo documento, ma è essenziale per una soluzione di ripristino di emergenza funzionante.
Passaggi successivi
- Configurazione dei gruppi di disponibilità sempre attivi di SQL Server.
- Deployment di un gruppo di disponibilità sempre attivo di SQL Server 2016 con più subnet su Compute Engine.
- Configurazione delle istanze del cluster di failover SQL Server.
- Esecuzione del clustering di failover del server Windows.
- Come abilitare Cloud Logging, Cloud Monitoring ed Error Reporting per le app .NET
- Installazione dell'agente Cloud Monitoring.
- Esplora le architetture di riferimento, i diagrammi e le best practice su Google Cloud. Visita il nostro Cloud Architecture Center.