Questo documento illustra le strategie di ripristino di emergenza (RE) per Microsoft SQL Server per architetti e 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 errori dell'hardware o di rete. Per fornire accesso continuo al database durante gli errori, viene mantenuto un database secondario che è una replica di un database primario. Se il database secondario si trova in una località diversa, aumenta le probabilità che sia disponibile quando il database principale non è più disponibile.
Se il database principale non è più disponibile, l'app mission-critical si connette a un database secondario, partendo 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 recupera dall'indisponibilità del database principale. Idealmente, il database secondario presenta esattamente lo stesso stato coerente del database principale quando non è disponibile o manca solo un insieme minimo di transazioni recenti dal database principale.
Database DR è una funzionalità essenziale per i clienti aziendali. Il principale motore è la continuità aziendale per le app mission-critical. Ad esempio, un'app mission-critical genera entrate (e-commerce), fornisce servizi affidabili continui (gestione di voli o impianti elettrici) o supporta funzionalità salvavita (monitoraggio dei pazienti). In tutti questi esempi, è della massima importanza che l'app sia sempre disponibile perché è considerata mission critical.
La maggior parte dei sistemi di gestione dei database offre funzionalità di ripristino di emergenza, incluso Microsoft SQL Server. Questo documento sull'architettura illustra come vengono implementate le funzionalità di RE fornite da SQL Server nel contesto di Google Cloud.
Terminologia
Le sezioni seguenti spiegano i termini utilizzati in questo documento.
Architettura generale di RE
Il seguente diagramma illustra la topologia dell'architettura di RE generale.
Nel diagramma precedente, un'app accede a un database principale mentre un database secondario è in attesa e rispecchia lo stato del database principale. 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 riconnessa al database secondario. Dopo la connessione, l'app può servire di nuovo i client. In una situazione ideale, l'app è disponibile sul database secondario il prima possibile, quindi i client potrebbero non subire interruzioni. Un'alternativa è attendere che il database principale diventi di nuovo accessibile, anziché avviare il ripristino di emergenza. Ad esempio, se l'emergenza è intermittente, la risoluzione del problema potrebbe essere più rapida rispetto al fallimento.
Database primari e secondari
Una o più app accedono a un database principale per fornire servizi di persistenza per la gestione dello stato dell'app. Un database secondario è correlato a un database principale e contiene una replica del database principale. 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 a quello principale a causa di ritardi nell'applicazione delle modifiche transazionali apportate al database principale. A seconda della tecnologia del database, è possibile associare più di un database secondario a un database primario. SQL Server supporta l'associazione di più di un database secondario a un database principale.
Ripristino di emergenza
Se un database primario non è più disponibile, RE modifica il ruolo del database secondario in modo che diventi il database principale. 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 principale per continuare ad accedere al proprio stato. Se il nuovo database principale non era sincronizzato con l'ultimo stato noto del database principale precedente, l'app inizia da uno stato passato (noto anche come flashback).
È importante avere sempre almeno un database secondario per ogni database principale. Dopo un ripristino di emergenza, assicurati che sia configurato un nuovo database secondario per gestire scenari futuri di ripristino di emergenza.
Failover, cambio e fallback
Esistono diversi scenari per la modifica del ruolo tra database primari e secondari:
- Failover: processo di modifica del ruolo di un database secondario in modo che diventi il nuovo database principale e di connessione di tutte le app al database. Il failover è involontario perché viene attivato quando un database principale diventa non disponibile. Puoi configurare il failover in modo che venga attivato automaticamente o manualmente.
- Cambio: a differenza del failover, il cambio da un database primario a un database secondario (nuovo database primario) viene attivato intenzionalmente per i test iniziali e la manutenzione pianificata. Testa il tuo sistema di RE con un cambio periodico regolare per garantire l'affidabilità continua del ripristino di emergenza.
- Di riserva: il fallback inverte il processo in cui il nuovo database primario diventa il database secondario, dopo la riparazione del database principale. Un fallback viene attivato intenzionalmente per ristabilire lo stato prima dell'inizio del failover o del cambio. Non è strettamente necessario, ma può essere eseguito in base ai requisiti di ripristino di emergenza, come la località o le risorse disponibili.
Zone e regioni 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 singolo dominio 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 evitare l'interruzione di un'intera regione, definisci strategie per più regioni 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 primario è un database aperto per operazioni di lettura e scrittura (operazioni DML) in modo che le app che vi accedono possano gestire il proprio 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 cambio, il database secondario diventa il nuovo database principale e diventa un database attivo.
Il database principale e quello secondario possono essere entrambi attivi se la tecnologia del database supporta questa funzionalità, chiamata modalità attiva-attiva. 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à attiva-attiva non richiede un failover se solo uno dei database attivi diventa non disponibile. Se un database attivo non è disponibile, l'altro database attivo continua a essere disponibile. La modalità attiva-attiva non rientra nell'ambito di questo articolo perché SQL Server non supporta questa modalità.
Modalità standby: caldo, caldo, freddo e nessun standby
Affinché il database principale sia attivo, deve essere in esecuzione ed essere in grado di eseguire istruzioni DML. Non è necessario che il database secondario sia in esecuzione, perché può essere arrestato. Se non è in esecuzione, il tempo necessario per recuperare da un'emergenza aumenta perché il nuovo database principale deve essere portato allo stato di esecuzione prima di assumere il ruolo del nuovo database principale.
Esistono diverse varianti di configurazione del database secondario:
- Hot standby: il database secondario è attivo e in esecuzione e pronto per essere connesso dai client. L'ultima modifica disponibile dal database principale viene sempre applicata non appena diventa disponibile.
- standby caldo: un database secondario è attivo e in esecuzione, ma non tutte le modifiche dal database principale sono ancora state applicate necessariamente.
- Cold standby: un database secondario non è in esecuzione. Innanzitutto, deve essere avviato e poi sincronizzato con l'ultimo stato disponibile.
- Nessun standby: il software del database deve essere installato e successivamente avviato prima di applicare tutte le modifiche dal database principale. Questa è la modalità meno costosa perché non consuma risorse quando non sono necessarie, ma rispetto alle altre modalità impiega il più tempo per diventare un nuovo database principale.
Strategie di RE
Nelle sezioni seguenti sono descritte le strategie di RE supportate da Microsoft SQL Server.
Dimensioni della strategia di recupero
Ci sono diverse dimensioni chiave da considerare quando si seleziona o si implementa una strategia di ripristino di emergenza del database. Ogni dimensione ha uno spettro, perciò 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 a come vengono utilizzati i dati. L'RPO può essere espresso in durata (secondi, minuti o ore) dal momento in cui il database primario non è più disponibile oppure può essere espresso come stati di elaborazione identificabili (ultimo backup completo o ultimo backup incrementale). Indipendentemente da come viene specificato l'RPO, la strategia di ripristino di emergenza deve implementare la misura specifica in modo che il requisito RPO possa essere soddisfatto. Il caso più impegnativo è l'ultima transazione di commit, il che significa che non deve verificarsi alcuna perdita dal database principale a quello secondario.
- RTO (Recovery Time Objective). Il periodo di tempo massimo accettabile durante il quale la tua app può rimanere offline. Questo valore viene in genere specificato nell'ambito di un accordo sul livello del servizio più ampio. L'RTO è solitamente espresso in termini di durata dal momento dell'indisponibilità del database primario; ad esempio, l'app deve essere completamente operativa entro 5 minuti. Il caso più impegnativo è immediato, per cui gli utenti dell'app non si accorgono che è avvenuto il ripristino di emergenza.
- Dominio single point of failure. Spetta a te decidere se una regione è considerata un single point of dominio in errore per i tuoi requisiti di ripristino di emergenza. Se una regione rappresenta un single point of dominio in errore per te, il ripristino di emergenza deve essere configurato in modo che due o più regioni siano coinvolte nella configurazione effettiva. In caso di errore della regione contenente il database principale, il database secondario in un'altra regione è 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 di una zona, il ripristino di emergenza utilizza una seconda zona e al suo interno rende disponibile il nuovo database principale.
La scelta di queste dimensioni fondamentali comporta la scelta tra costo e qualità. Più bassi sono gli RTO e l'RPO, più costosa può diventare la soluzione di ripristino di emergenza man mano che vengono utilizzate più risorse attive. Nelle sezioni seguenti vengono illustrate 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 di database: SQL Server descrive le funzionalità di disponibilità che puoi usare per implementare strategie di ripristino di emergenza.
Eliminazioni
SQL Server viene eseguito sia su Windows che su Linux. Tuttavia, non tutte le funzionalità 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 è l'esecuzione del software SQL Server, mentre un database è l'insieme di dati gestito da un'istanza SQL Server.
Gruppi di disponibilità sempre attivi
I gruppi di disponibilità sempre attivi forniscono protezione a livello di database. Un gruppo di disponibilità include due o più repliche. Una replica è la replica principale con accesso in lettura e scrittura, mentre le 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 dipendono 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 principale 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 dell'agente SQL Server. Per fornire la protezione a livello di database e di istanza SQL Server, devi configurare istanze cluster di failover (FCI). Questa architettura di deployment verrà discussa più avanti nella sezione Istanza cluster di failover sempre attiva.
Puoi impedire alle app i cambiamenti di ruolo 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 una versione .NET minima di 3.5 con un aggiornamento o 4.0 o versioni successive, come descritto in Business continuity e recupero di database - SQL Server.
I gruppi di disponibilità si basano sui livelli di astrazione sottostanti per fornire le 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 dello stesso WSFC.
Le transazioni vengono inviate dal database principale a tutte le repliche secondarie. Esistono due modalità di invio per inviare le transazioni: sincrona e asincrona. Puoi configurare in modo indipendente ogni replica in modo che utilizzi una o l'altra modalità. Nella modalità di invio sincrona, la transazione sul database principale ha esito positivo solo se riesce su tutte le repliche secondarie collegate in modo sincrono. Nella 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 i possibili RTO, RPO e la modalità di standby. Ad esempio, se le transazioni vengono inviate a tutte le repliche in modalità sincrona, tutte le repliche si trovano nello stesso stato. L'RPO (transazione più recente) più impegnativo viene soddisfatto 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, 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 più zone. Questo è solo a 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 cluster di failover (FCI) anziché istanze SQL Server autonome. Due o più nodi eseguono istanze SQL Server per gestire un database (primario o secondario). I nodi che gestiscono un database formano un cluster di failover. Un nodo del cluster esegue attivamente un'istanza SQL Server, mentre gli altri non eseguono istanze SQL Server. In caso di errore del nodo che esegue l'istanza SQL Server, un altro nodo del cluster avvia un'istanza SQL Server, assumendo la gestione del database (Failover del nodo). L'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 nodi, tranne forse per un breve periodo di indisponibilità. Non si verifica alcuna perdita di dati quando si verifica un failover del nodo. Tutto ciò che è in esecuzione nell'istanza SQL Server non riuscita viene spostato in un'altra istanza SQL Server nello stesso cluster. Ad esempio, i job dell'agente SQL Server 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 errori dei nodi, ma anche per errori di zona. Un esempio di deployment di questa strategia è discusso nella sezione Alternative di deployment per RE.
Anche se nodi diversi gestiscono lo stesso database e condividono lo stesso, non è richiesta un'archiviazione comune tra i nodi di un cluster FCI. SQL Server utilizza la funzionalità Storage Space Direct (S2D) per gestire i database su dischi dei nodi dedicati. Per ulteriori informazioni, consulta Configurazione delle istanze 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à, una FCI è rappresentata da un rettangolo. Questo è solo a scopo illustrativo per indicare che i nodi appartengono tutti allo stesso FCI. Una 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, vedi Istanze cluster di failover sempre attive (SQL Server).
Gruppi di disponibilità distribuita
I gruppi di disponibilità distribuita sono un tipo speciale di gruppo di disponibilità. Un gruppo di disponibilità distribuita comprende due gruppi di disponibilità: uno ha il ruolo di gruppo di disponibilità principale e l'altro di gruppo di disponibilità secondario. I gruppi di disponibilità distribuita 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à ha il proprio database principale, questo non è un deployment attivo-attivo. Solo il database principale del gruppo di disponibilità principale può ricevere operazioni di scrittura. Il database principale del gruppo di disponibilità secondario è chiamato forwarding. L'utente che esegue l'inoltro riceve le transazioni dal gruppo di disponibilità primario e le inoltra ai database secondari del gruppo di disponibilità secondario. Un failover dal gruppo di disponibilità principale a quello 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 devono necessariamente trovarsi sullo stesso sistema operativo. Tuttavia, in ogni gruppo di disponibilità deve essere installato un listener. Il gruppo di disponibilità distribuita in sé non ha un listener. I gruppi di disponibilità distribuita non richiedono che i due gruppi di disponibilità si trovino nella stessa WSFC. Tutte le funzionalità necessarie per far funzionare i gruppi di disponibilità distribuita sono contenute nelle funzionalità di SQL Server e non richiedono l'installazione aggiuntiva dei componenti sottostanti.
Un gruppo di disponibilità distribuita comprende esattamente due gruppi di disponibilità. Un gruppo di disponibilità può far parte di due gruppi di disponibilità distribuita. Questa possibilità supporta diverse topologie. Uno è una topologia con daisy-chaining, dal gruppo di disponibilità al gruppo di disponibilità in diverse località. Un'altra topologia è una topologia ad albero in cui il gruppo di disponibilità principale fa parte di due gruppi di disponibilità distribuita diversi e separati.
I gruppi di disponibilità distribuita sono il mezzo principale per implementare il ripristino di emergenza nei vari sistemi operativi. Ad esempio, il gruppo di disponibilità principale può essere configurato su Windows e un secondo gruppo di disponibilità corrispondente su Linux, dove entrambi i gruppi di disponibilità formano un gruppo di disponibilità distribuito.
Il seguente diagramma mostra due gruppi di disponibilità che fanno parte di un gruppo di disponibilità distribuita.
Il gruppo di disponibilità 1 è il gruppo di disponibilità principale, mentre il gruppo di disponibilità 2 è il gruppo di disponibilità secondario.
Come nel caso degli FCI, un gruppo di disponibilità distribuita è rappresentato come un rettangolo. A scopo puramente illustrativo, indica che tutti i gruppi di disponibilità appartengono allo stesso gruppo di disponibilità distribuita. Un gruppo di disponibilità distribuita, come 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, vedi Gruppi di disponibilità distribuita.
Spedizione log
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 primario e il relativo database secondario è significativamente maggiore. La discrepanza è maggiore in termini di stato, poiché 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 trasportati 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, ad esempio, sottoposti a backup in Cloud Storage. Ogni file di log delle transazioni viene copiato in ogni database secondario e applicato. Poiché il database secondario è in ritardo rispetto a quello principale, è in modalità hot standby. Gli oggetti e le modifiche che non vengono acquisiti dai log delle transazioni devono essere applicati manualmente ai database secondari per garantire 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 impostare quanti più processi di spedizione dei log.
In caso di errore, il processo di ripristino di emergenza deve essere avviato manualmente perché non è previsto alcun supporto automatico. Inoltre, l'accesso client non viene 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 dal ruolo secondario al nuovo ruolo principale eseguendo la connessione al nuovo ruolo principale dopo un ripristino di emergenza. È possibile creare astrazioni separate indipendentemente dalle istanze di 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 intenzionalmente dei file di log copiati ai database secondari (a differenza dei gruppi di disponibilità e dei gruppi di disponibilità distribuita in cui le modifiche vengono applicate immediatamente). Un possibile caso d'uso è evitare che gli errori di modifica dei dati nel database principale vengano applicati ai database secondari finché 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 finché non viene risolto l'errore di modifica dei dati. In seguito, potrebbe riprendere l'elaborazione normale.
Come nel caso dei gruppi di disponibilità distribuita, è possibile utilizzare la spedizione dei log per le soluzioni multipiattaforma in cui, ad esempio, il database principale è in esecuzione su Linux, mentre i database secondari sono su Linux e Windows.
Il seguente diagramma illustra un deployment multipiattaforma con spedizione dei log. Tieni presente che non esiste una configurazione comune tra le regioni, ad esempio un gruppo di disponibilità distribuita in questa topologia.
I gruppi di disponibilità si trovano in regioni separate, uno in esecuzione su Linux e l'altro su Windows.
Per saperne di più 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, la spedizione dei log è stata utilizzata con diversi gruppi di disponibilità installati su diversi sistemi operativi.
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à primario che utilizza FCI con un gruppo di disponibilità secondario che utilizza solo istanze SQL Server autonome.
- Utilizza un gruppo di disponibilità distribuita tra regioni vicine e spedizione dei log in regioni di diversi continenti.
Queste sono solo alcune delle possibili combinazioni di funzionalità di disponibilità di SQL Server.
La flessibilità che le funzionalità di disponibilità di SQL Server forniscono al fine di ottimizzare una strategia di ripristino di emergenza in base ai requisiti dichiarati.
Replica SQL Server
La replica di SQL Server non è generalmente considerata una funzionalità di disponibilità, ma questa sezione descrive brevemente come questa funzionalità può essere utilizzata per il ripristino di emergenza.
La funzionalità di replica supporta la creazione e la manutenzione di repliche dei database. Diversi tipi di agenti SQL Server collaborano per acquisire le modifiche, trasmettere le modifiche acquisite e applicare queste modifiche alle repliche. Questo processo è asincrono e di solito le repliche sono in ritardo a vari livelli rispetto al database in fase 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 di SQL Server non sa che i database assumono ruoli diversi nel contesto del ripristino di emergenza. Di conseguenza, la replica non include operazioni che supportano il processo di ripristino di emergenza, ad esempio le modifiche dei ruoli. Il processo di ripristino di emergenza deve essere implementato separatamente dalla funzionalità SQL Server ed essere eseguito dall'organizzazione che esegue l'implementazione in quanto non sono presenti astrazioni dell'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 del database 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 copiata effettivamente tra le località).
Questa strategia non prevede alcuna funzionalità di disponibilità di SQL Server quando si replicano le modifiche di stato dal database principale a qualsiasi database secondario. Non utilizza l'agente SQL Server utilizzato nel caso della spedizione dei log.
Per ulteriori informazioni, consulta la sezione Esempio: strategia RE di backup e ripristino.
Le istruzioni dettagliate per il backup e il ripristino di SQL Server sono illustrate in questa 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 la spedizione dei file di replica che di backup hanno in comune il fatto che il processo di ripristino di emergenza è implementato all'esterno e separato dal set di funzionalità di SQL Server. Per quanto riguarda la spedizione delle modifiche acquisite, la replica di SQL Server è più comoda perché implementa questa parte automaticamente per mezzo degli agenti SQL Server.
Nota sull'interazione tra il ciclo di vita del database e quello dell'app
Un failover del database non è completamente separato e indipendente dalle app che vi accedono. In linea di principio, esistono due scenari di errore.
Innanzitutto, l'app rimane operativa durante il failover del database. Dal momento dell'indisponibilità del database primario fino al momento in cui il nuovo database primario è operativo, le app non possono accedere al database. Le connessioni esistenti non vanno a buon fine e non ne vengono stabilite di nuove. Durante questo periodo, l'app non è in grado di servire i propri client, almeno nella misura in cui la funzionalità richiede l'accesso al database. Le app devono riconoscere quando è disponibile il nuovo database principale per poter riprendere la normale elaborazione.
Le app potrebbero avere stato al di fuori del database, ad esempio nelle cache della memoria principale. L'app verifica che la cache sia coerente (sincronizzata) con il nuovo database principale. Se non si sono verificate perdite durante il failover, la cache potrebbe essere coerente senza ulteriore manutenzione. Tuttavia, se la perdita (dati) della transazione si è verificata durante il failover, la cache potrebbe non essere coerente rispetto al nuovo database principale. 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 nello stesso momento in cui il database principale diventa non disponibile. Ad esempio, se una regione passa alla modalità offline, un sistema di applicazioni in esecuzione in quella regione non sarà disponibile quanto il database principale nella stessa regione. In questo caso, deve essere recuperata anche l'app, non solo il sistema di database principale. Oltre alla procedura di ripristino di emergenza del database, devi avviare una procedura simile di ripristino dell'app. L'app recuperata deve connettersi al nuovo database principale e riconfigurata (ad esempio, indirizzi IP mobili). Il ripristino di 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 è poter 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. I dati relativi a backup, archiviazione e ripristino nel contesto di Google Cloud sono illustrati nell'articolo 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, copierai 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 che forniscono soluzioni per l'indisponibilità dei database. Se un database primario non è più disponibile, un database secondario diventa il nuovo database principale coerente e disponibile.
La differenza tra alta disponibilità e ripristino di emergenza è il singolo punto di dominio in errore. L'alta disponibilità risolve un'interruzione all'interno di una regione, ad esempio in caso di errore di una singola zona o di un nodo. Una soluzione ad alta disponibilità fornisce un nuovo database principale in un'altra zona della stessa regione. Inoltre, l'alta disponibilità risolve gli errori dei nodi, non solo quelli del database. Se si verifica un errore in un nodo che esegue un'istanza SQL Server, viene reso disponibile un nuovo nodo che esegue una nuova istanza SQL Server (vedi la discussione nella sezione Istanza cluster di failover sempre attiva).
Il ripristino di emergenza interessa almeno due regioni. Risolve i casi in cui un'intera regione non sia più disponibile. Il ripristino di emergenza può fornire un nuovo database principale 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ò coprire le zone all'interno di una regione e le regioni stesse. Un gruppo di disponibilità può contenere istanze cluster di failover per gestire l'alta disponibilità.
SQL Server può definire gruppi di disponibilità all'interno di una regione per l'alta disponibilità e gli errori di zona e combinarlo con la spedizione dei log in più regioni per far fronte al ripristino di emergenza.
Alternative al deployment di RE
Nelle sezioni seguenti sono mostrate alcune possibili topologie per il ripristino di emergenza in aggiunta a quelle discusse finora. Queste topologie soddisfano diversi requisiti di RPO e RTO. L'elenco non è esaustivo.
RE e alta disponibilità intraregionali
Questo deployment è una variante di un gruppo di disponibilità contenente FCI, all'interno di una regione composta da tre zone. In questo scenario, le zone sono considerate il single point ofdominio in erroreo.
Rispetto al deployment mostrato in precedenza, ogni FCI è costituito da tre nodi, ognuno dei quali è in esecuzione in una zona diversa. Il vantaggio di questa configurazione è che una o due zone possono non riuscire 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 che non sono in esecuzione in ogni FCI, che possono essere avviate in caso di errore di una zona. I database vengono visualizzati in più zone poiché ogni database utilizza i dischi di tutti i nodi in un determinato FCI. Un'app non viene mostrata per chiarezza.
RE tra regioni: gruppo di disponibilità che comprende più 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 singolo dominio 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 da utilizzare la propagazione delle transazioni sincrone, mentre le repliche nella regione R2 sono configurate per utilizzare la propagazione delle transazioni asincrona.
RE tra regioni: trasferimento 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à dispone delle sue repliche che ricevono le transazioni in modo sincrono, di conseguenza le repliche secondarie di ogni regione sono in una configurazione hot_standby.
Il seguente diagramma illustra questa configurazione.
Tuttavia, i due gruppi di disponibilità sono collegati dal 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. Man mano che i file di backup vengono resi disponibili per il gruppo di disponibilità secondario, vengono applicati lì. Questo scenario è discusso più in dettaglio nella sezione seguente, Esempio: strategia di ripristino di emergenza di backup e ripristino.
Topologia con doppia posizione e posizione terziaria
Se esistono solo due database, uno principale e uno secondario, ciascuno in una regione separata, dopo un failover dopo l'esecuzione del nuovo database principale e il nuovo database secondario sarà pronto per una durata non protetta. Se il nuovo database principale non è più disponibile mentre quello secondario non è ancora in esecuzione, si verifica un tempo di inattività rigido che può essere recuperato solo quando viene stabilito un nuovo database principale. 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 principale in modo che non si verifichino perdite di dati. Come in precedenza, lo stesso vale per i gruppi di disponibilità.
Ciclo di vita di RE
Indipendentemente dalla soluzione di ripristino di emergenza scelta, esistono passaggi comuni del ciclo di vita.
In una situazione reale di ripristino di emergenza, tutti gli stakeholder (proprietari di 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 della cerimonia) e i processi decisionali che seguono. Gli stakeholder devono inoltre essere d'accordo sulla loro terminologia e i loro metodi di comunicazione.
Decisione di avviare un processo di failover
A meno che il failover non venga avviato automaticamente, gli stakeholder devono decidere se 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 della mancata disponibilità del database primario.
Se il processo di ripristino di emergenza impiega più tempo del previsto per risolvere l'indisponibilità del database principale, un failover sarebbe negativo. Innanzitutto, devi valutare se il ripristino del database primario è un'opzione fattibile.
Meglio viene testata la strategia di ripristino di emergenza e più rapidamente viene implementata, più facile è avviare il processo di failover, poiché nella decisione viene preso in considerazione meno incertezza.
Esecuzione del processo di failover
Idealmente, il processo di failover viene testato regolarmente e, pertanto, è noto ai vari stakeholder.
L'autorità decisionale deve essere a conoscenza di tutte le fasi in atto e di tutti i problemi imprevisti che si presentano. L'autorità decisionale gestisce il processo di failover e gli stakeholder sono responsabili del supporto dell'autorità decisionale.
Devi conservare le statistiche relative all'analisi post mortem e al miglioramento del processo di failover, tra cui la durata delle attività, i problemi emersi e qualsiasi confusione nei passaggi del processo di failover.
Protezione mancante
Se hai un solo database secondario, dal momento in cui il nuovo database principale diventa disponibile e operativo fino alla configurazione di un nuovo database secondario, non esiste alcuna protezione RE. L'indisponibilità durante questo periodo potrebbe causare tempi di inattività, perché non è possibile il failover a un altro database. Se si verifica questa situazione, è necessario configurare un altro database primario 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 sempre una protezione, tutti gli stakeholder devono essere consapevoli della durata della mancanza di protezione per prendere precauzioni aggiuntive durante la configurazione o le modifiche alla configurazione dell'ambiente.
Puoi evitare questo periodo di tempo non protetto se l'accesso dell'app al nuovo database principale viene ritardato fino a quando il nuovo database secondario è attivo e in esecuzione. Non appena vengono applicate le modifiche apportate al database principale, quest'ultimo diventa disponibile per le app. Anche se questo approccio evita qualsiasi momento in cui le app non siano protette dal RE, ritarda il completamento del processo di ripristino di emergenza.
Evitare situazioni di scomposizione
È importante che le app non possano accedere contemporaneamente a un database principale e a un database secondario, eseguendo operazioni DML. In questo caso, si verifica un'incoerenza nei dati se sia il database principale sia il database secondario non sono d'accordo sui valori dei dati dello stesso elemento di dati (Split-Brain). Questa architettura è particolarmente importante se il database principale diventa non disponibile mentre è in esecuzione e può ricevere operazioni di scrittura. Se l'indisponibilità è causata da un partizionamento della rete intermittente, il partizionamento può interrompersi in qualsiasi momento e un'app potrebbe avere di nuovo accesso. Se in quel momento è in corso un processo di failover, le modifiche al vecchio database primario potrebbero andare perse oppure alcune app iniziano a funzionare sul nuovo database principale mentre altre accedono ancora al vecchio database primario.
L'accesso alle app viene disattivato durante il processo di failover a tutti i database, in modo che non si verifichino cambiamenti di stato in nessun database. Dopo il failover, sarà disponibile un solo database per le operazioni di scrittura: il nuovo database primario.
Dichiarazione di completamento
Una volta completato il processo di failover, tutti gli stakeholder devono essere esplicitamente informati dall'autorità decisionale che il processo è completato. Qualsiasi problema mostrato dopo il completamento deve essere trattato come un incidente separato che non fa più parte del processo di failover, ma parte dell'elaborazione regolare. Il problema potrebbe essere la conseguenza di un problema con il processo di failover o di un problema indipendente nel complesso. Tuttavia, l'approccio per risolvere il problema dopo il completamento del processo di failover potrebbe essere diverso da come viene gestito durante l'esecuzione del processo di failover.
Analisi post mortem e report
Come riferimento per il futuro e per migliorare il processo di failover, organizza immediatamente un'analisi post mortem per prendere nota di aspetti, risultati e attività 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 requisiti normativi.
Test e verifica RE
Poiché il ripristino di emergenza non fa parte delle normali operazioni quotidiane, la soluzione RE deve essere testata regolarmente per verificarne il corretto funzionamento quando è effettivamente necessario.
La frequenza dei test dipende dai requisiti operativi e varia a seconda del database, dell'app e dell'azienda. Inoltre, le modifiche all'ambiente, come le modifiche alla configurazione di rete e gli aggiornamenti dei componenti dell'infrastruttura, dovrebbero attivare un test di ripristino di emergenza se vengono apportate modifiche ai sistemi su cui si basa la soluzione di ripristino di emergenza scelta. Qualsiasi modifica potrebbe causare l'errore della soluzione di ripristino di emergenza o richiedere di modificare la procedura di ripristino di emergenza.
Puoi eseguire i test manualmente avviando il processo di cambio o automaticamente seguendo un approccio di progettazione del caos descritto in Progettazione del caos. Con i test manuali, puoi ridurre al minimo l'impatto aziendale in caso di tempi di inattività rilevanti.
Un aspetto importante dei test è la raccolta di statistiche ben definite. Ecco alcune statistiche importanti da considerare:
- Tempo di recupero effettivo: misura il tempo di recupero effettivo e confrontalo con l'RTO.
- Punto di ripristino effettivo: osserva il punto di ripristino effettivo e confrontalo con l'RPO.
- Tempo prima del rilevamento degli errori: il tempo impiegato dai DBA o dal team delle operazioni per rendersi conto della necessità del failover.
- Tempo di 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 richieste deviazioni? Sono stati riscontrati problemi imprevisti da indagare, che hanno portato a una modifica della strategia di ripristino?
In base alle statistiche raccolte, il processo di failover potrebbe dover essere modificato o migliorato per corrispondere meglio alle aspettative di RPO e RTO.
Esempio: strategia RE di backup e ripristino
Le sezioni seguenti descrivono una strategia 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 necessario per specificare una strategia di backup e ripristino per RE e per discutere di aspetti che non sono visibili nelle configurazioni più automatizzate. Si riferisce alla soluzione correlata Utilizzo dei backup di Microsoft SQL Server per il recupero point-in-time su Compute Engine.
Caso d'uso
Un gruppo di disponibilità principale sempre attivo si trova e è operativo nella regione R1. 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 cambio.
Strategia
La strategia di ripristino di emergenza si basa sui backup del database. Viene eseguito un backup iniziale completo seguito da backup differenziali successivi. I backup vengono applicati al gruppo di disponibilità Sempre attivo secondario nel momento in cui vengono acquisiti. Tutti i backup vengono 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 fino a quando il nuovo gruppo di disponibilità Sempre attivo secondario in R1 non è operativo.
Non devono essere eseguiti servizi di riserva, poiché il gruppo di disponibilità sempre attivo in ciascuna regione è ugualmente qualificato per fungere da gruppo di disponibilità sempre attivo di produzione.
RTO e RPO
In questo esempio, l'RPO deve essere un massimo di 60 minuti, quindi viene eseguito un backup differenziale ogni 60 minuti.
L'RTO non è impostato in modo esplicito su una durata di tempo, ma deve essere il più minimo possibile: immediato è il caso migliore. Il gruppo di disponibilità secondario deve essere configurato come hot standby. Nel caso di un hot standby, tutti i backup vengono applicati immediatamente in modo che l'applicazione dei backup non venga ritardata.
Strategia di alto livello di RE
Le sezioni seguenti descrivono la strategia di RE. Viene brevettata per concentrarsi sui passaggi essenziali.
Impostazione iniziale
- Crea un gruppo di disponibilità Sempre attivo secondario nella regione R2.
- Impedisci alle app di accedere al gruppo di disponibilità secondario in modo che non si verifichino situazioni di tipo "split-brain".
- Crea il bucket di file di backup B1 in Cloud Storage per contenere il backup completo iniziale del gruppo di disponibilità sempre attivo in R1 e i successivi backup differenziali orari del gruppo di disponibilità sempre attivo 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 a data e ora come parte dei vari nomi dei file.
Strategia di lancio
- Applica il backup completo al gruppo di disponibilità Sempre attivo secondario nella regione R2.
- Non appena i backup differenziali diventano disponibili, applicali immediatamente al gruppo di disponibilità sempre attivo secondario in R2. Per affrontare l'RTO è necessaria la richiesta immediata.
- Dopo l'applicazione del backup completo iniziale e di tutti i backup incrementali, il gruppo di disponibilità Sempre attivo secondario è pronto.
- Testa la strategia di RE eseguendo un cambio dal gruppo di disponibilità principale a quello secondario. Durante il test deve essere disponibile almeno un backup incrementale.
Richiesta di failover o cambio
In R2, i passaggi essenziali sono i seguenti:
- Assicurati che sia stato applicato l'ultimo backup differenziale al gruppo di disponibilità sempre attivo secondario in R2.
- Designa 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 reimpostalo allo stato iniziale (vuoto) (a meno che non sia necessario crearlo di recente).
- Applica il backup completo dal nuovo gruppo di disponibilità Sempre attivo principale in R2 e continua ad applicare subito i backup differenziali non appena diventano disponibili (archiviati nel bucket B2).
Possibili miglioramenti
Un possibile miglioramento della strategia di RE è evitare di eseguire un backup completo dopo un failover o un cambio, pur continuando a configurare rapidamente il nuovo gruppo di disponibilità secondario. Anziché un unico backup completo e i successivi backup differenziali, esegui un backup completo ogni settimana e crea un bucket settimanale contenente il backup completo della settimana e tutti i backup differenziali successivi della 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 e diventa operativo dopo essere di nuovo disponibile, un recupero point-in-time per l'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 ripristino completo). Questo scenario riduce l'impegno e la quantità di tempo in cui il nuovo gruppo di disponibilità principale non viene protetto.
Best practice per la produzione
Questa soluzione non specifica se le istanze SQL Server nei gruppi di disponibilità Always On sono istanze autonome o FCI. Il tipo di istanze utilizzate deve essere deciso prima dell'implementazione.
Finché un nuovo gruppo di disponibilità sempre attivo secondario non diventa operativo dopo un failover, c'è un momento in cui la RE non è protetta. Devi configurare un terzo gruppo di disponibilità sempre attivo in una terza regione.
Inoltre, è necessario implementare il monitoraggio per garantire che vengano rilevati errori 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à Always On di SQL Server.
- Deployment di un gruppo di disponibilità SQL Server 2016 Always On con più subnet su Compute Engine.
- Configurazione delle istanze cluster di failover di SQL Server.
- Esecuzione del clustering di failover di Windows Server.
- 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.