Questo documento illustra le strategie di ripristino di emergenza (RE) per Microsoft SQL Server per architetti e responsabili tecnici incaricati di progettare e implementare il ripristino di emergenza su Google Cloud.
I database possono non essere disponibili per vari motivi, ad esempio guasti hardware o della rete. Per fornire accesso continuo al database in caso di errori, viene mantenuto un database secondario che è una replica di un database primario. Avere il database secondario in una posizione diversa aumenta le probabilità che sia disponibile quando il database principale non è disponibile.
Se il database principale non è disponibile, l'app mission-critical si connette a un database secondario, continuando dall'ultimo stato dei dati coerenti noto per fornire servizi agli utenti con tempi di inattività minimi o nulli.
La procedura per rendere disponibile un database secondario in caso di guasto del database primario è chiamata ripristino di emergenza del database (RE). Il database secondario si riprende dalla mancata disponibilità del database principale. Idealmente, il database secondario ha lo stesso stato coerente del database primario quando non è disponibile o manca solo un insieme minimo di transazioni recenti del database principale.
Il ripristino dei dati di un database è una funzionalità essenziale per i clienti aziendali. Il fattore principale è la continuità aziendale per le app mission critical. Ad esempio, un'app di importanza fondamentale genera entrate (e-commerce), fornisce servizi affidabili e continui (gestione di voli o impianti di potenza) o supporta funzionalità di salvataggio della vita (monitoraggio dei pazienti). In tutti questi esempi, è di fondamentale importanza che l'app sia disponibile continuamente perché è considerata mission critical.
La maggior parte dei sistemi di gestione dei database fornisce funzionalità di ripristino di emergenza, incluso Microsoft SQL Server. Questo documento sull'architettura illustra come le funzionalità di RE fornite da SQL Server vengono implementate nel contesto di Google Cloud.
Terminologia
Le sezioni seguenti spiegano i termini utilizzati in questo documento.
Architettura generale di DR
Il seguente diagramma illustra la topologia generale dell'architettura di RE.
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 è disponibile, gli amministratori del database o il team operativo devono decidere di avviare il processo di ripristino di emergenza. Se viene avviato il recupero di emergenza del database, l'app viene ricollegata al database secondario. Una volta collegata, l'app può tornare a servire i suoi clienti. In una situazione ideale, l'app è disponibile nel database secondario il prima possibile, quindi i clienti potrebbero persino non riscontrare un'interruzione del servizio. Un'alternativa è attendere che il database primario diventi di nuovo accessibile, anziché avviare il ripristino di emergenza. Ad esempio, se il disastro è intermittente, potrebbe essere più rapido risolvere il problema anziché eseguire il failover.
Database principali e secondari
Un database principale viene utilizzato da una o più app 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 principale. Idealmente, i contenuti del database secondario corrispondono esattamente a quelli del database principale in qualsiasi momento. In molti casi, il database secondario è in ritardo rispetto al database primario a causa di ritardi nell'applicazione delle modifiche transazionali apportate al database primario. È possibile associare più di un database secondario a un database principale, a seconda della tecnologia del database. SQL Server supporta l'associazione di più database secondari a un database principale.
Ripristino di emergenza
Se un database principale non è disponibile, RE modifica il ruolo del database secondario in modo che diventi il database principale. Se sono presenti più database secondari, uno di questi viene selezionato manualmente o in base a un elenco di failover preferito. Le app devono ricollegarsi al nuovo database principale per continuare a accedere al loro stato. Se il nuovo database principale non era sincronizzato con lo stato conosciuto più recente del precedente database principale, l'app viene avviata 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 di configurare un nuovo database secondario per gestire futuri scenari di ripristino di emergenza tipo.
Failover, switchover e fallback
Esistono diversi scenari per cambiare il ruolo tra i database principale e secondario:
- Failover: la procedura di modifica del ruolo di un database secondario in modo che diventi il nuovo database principale e di connessione di tutte le app. Il failover è involontario perché viene attivato dal mancato funzionamento di un database primario. Puoi configurare il failover in modo che venga attivato automaticamente o manualmente.
- Switchover: a differenza del failover, uno switchover da un database principale a un database secondario (nuovo database principale) viene attivato intenzionalmente per i test iniziali e la manutenzione pianificata. Testa il sistema di RE con un passaggio periodico regolare per garantire la continua affidabilità del ripristino di emergenza.
- Ripristino: il ripristino consiste nell'invertire il processo in cui il nuovo database principale diventa il database secondario dopo la riparazione del database principale. Viene attivato intenzionalmente un piano di riserva per ristabilire lo stato prima dell'avvio del failover o dello switchover. Non è strettamente necessario, ma può essere eseguito in base ai requisiti di ripristino di emergenza, ad esempio la località o le risorse disponibili.
Zone e regioni Google Cloud
Risorse come i database si trovano in zone e regioni Google Cloud, dove ogni zona appartiene a una regione. Una zona è un dominio con un singolo punto di errore. Ti 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, definisci 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 regione.
Modalità attive: attiva/passiva e attiva/attiva
Un database principale è un database aperto per le operazioni di lettura e scrittura (operazioni DML) in modo che le app che vi accedono possano gestire il proprio stato. Il database primario è chiamato database attivo. Il database secondario corrispondente è passivo perché replica il database principale, ma non è disponibile per nessuna app per le operazioni di modifica dello stato. Dopo un failover o uno switchover, il database secondario diventa il nuovo database principale e diventa un database attivo.
Il database principale e quello secondario possono essere entrambi database attivi se la tecnologia del database supporta questa funzionalità, chiamata modalità attiva-attiva. In questo caso, le app possono connettersi a uno o all'altro perché entrambi i database sono disponibili per la gestione dello stato. Il disaster recovery in modalità attiva-attiva non richiede un failover se solo uno dei database attivi diventa disponibile. Se un database attivo non è disponibile, l'altro database attivo rimane disponibile. La modalità attiva-attiva non rientra nell'ambito di questo articolo perché SQL Server non la supporta.
Modalità di standby: caldo, tiepido, freddo e nessuna
Affinché il database principale sia il database 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 recuperare da un disastro aumenta perché il nuovo database principale deve prima essere portato a uno stato di esecuzione prima di assumere il ruolo del nuovo database principale.
Esistono diverse varianti per configurare il database secondario:
- Hot standby: il database secondario è attivo e pronto per essere collegato dai client. La modifica più recente disponibile dal database primario viene sempre applicata non appena diventa disponibile.
- Standby caldo: un database secondario è attivo e funzionante, ma non tutte le modifiche del database principale sono state necessariamente applicate.
- Cold standby: un database secondario non è in esecuzione. Innanzitutto, deve essere avviato e poi sincronizzato con lo stato più recente disponibile.
- Nessun database di standby: il software del database deve essere installato e successivamente avviato prima che tutte le modifiche del database principale vengano applicate. Questa modalità è la meno costosa perché non consuma risorse quando non è necessaria, ma rispetto alle altre modalità richiede più tempo per diventare un nuovo database principale.
Strategie RE
Nelle sezioni seguenti vengono descritte le strategie di RE supportate da Microsoft SQL Server.
Dimensioni della strategia di recupero
Esistono diverse dimensioni chiave da considerare quando si seleziona o implementa 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:
- Recovery Point Objective (RPO): la durata massima accettabile durante la quale i dati potrebbero essere persi dalla tua app a causa di un incidente grave. Questa dimensione varia in base ai modi in cui vengono utilizzati i dati. L'RPO può essere espresso in durata (secondi, minuti o ore) dal momento della mancata disponibilità del database principale o in stati di elaborazione identificabili (ultimo backup completo o ultimo backup incrementale). Indipendentemente da come viene specificato il RPO, la strategia di recupero del disastro deve implementare la misura specifica in modo che il requisito RPO possa essere soddisfatto. Il caso più impegnativo è l'ultima transazione committata, 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 per cui la tua app può essere offline. Questo valore viene solitamente specificato nell'ambito di un accordo sul livello del servizio più ampio. Il RTO viene solitamente espresso in termini di durata dal momento dell'indisponibilità del database principale, ad esempio l'app deve essere completamente operativa entro 5 minuti. Il caso più impegnativo è quello immediato, in modo che gli utenti dell'app non notino che è stato eseguito il ripristino di emergenza.
- Dominio con single point of failure. Sta a te decidere se una regione è considerata un dominio con un singolo punto di errore per i tuoi requisiti di recupero in caso di disastro. Se una regione è un dominio con un singolo punto di errore per te, il ripristino di emergenza deve essere configurato in modo che due o più regioni siano coinvolte nella configurazione effettiva. Se la regione contenente il database principale non funziona, 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. Se una zona non funziona, ripristino di emergenza utilizza una seconda zona e rende disponibile il nuovo database principale al suo interno.
La scelta di queste dimensioni chiave comporta una decisione tra costo e qualità. Più bassi sono RTO e RPO, più costosa può diventare la soluzione di ripristino di emergenza man mano che vengono utilizzate 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 recupero del database - SQL Server descrive le funzionalità di disponibilità che puoi utilizzare per implementare le strategie di ripristino di emergenza.
Turni preliminari
SQL Server viene eseguito sia su Windows che su Linux. Tuttavia, non tutte le funzionalità di disponibilità sono disponibili su Linux. SQL Server è disponibile in 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 SQL Server.
Gruppi di disponibilità AlwaysOn
I gruppi di disponibilità Always On offrono 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 altre repliche sono repliche secondarie che possono fornire l'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à subiscono contemporaneamente le stesse modifiche del ciclo di vita. I gruppi di disponibilità implementano la modalità attiva-passiva perché solo il database principale supporta l'accesso in scrittura.
Quando si verifica un 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 variazione 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 protezione a livello di database e protezione delle istanze SQL Server, devi configurare le istanze del cluster di failover (FCI). Questa architettura di deployment è discussa più avanti nella sezione relativa all'istanza del cluster di failover sempre attivo.
Puoi proteggere le app dalle modifiche ai ruoli utilizzando un ascoltatore. Un listener supporta le app che si connettono al gruppo di disponibilità. Le app non sono a conoscenza di quali istanze SQL Server gestiscono il database principale o le repliche secondarie in un determinato momento. Gli ascoltatori richiedono che i client utilizzino una versione .NET minima di 3.5 con un aggiornamento o 4.0 e versioni successive, come descritto in Continuità aziendale e ripristino del database - SQL Server.
I gruppi di disponibilità si basano su 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 Clustering di failover di Windows Server con SQL Server. Tutti i nodi che eseguono istanze di 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 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 sincrono, la transazione nel database principale va a buon fine solo se va a buon fine in tutte le repliche secondarie collegate in modo sincrono. In modalità asincrona, la transazione sul database principale può andare a buon fine anche se non a tutte le repliche secondarie è stata applicata la transazione.
La scelta della modalità di invio influisce sui possibili RTO, RPO e sulla modalità di standby. Ad esempio, se le transazioni vengono inviate a tutte le repliche in modalità sincrona, tutte le repliche sono nello stesso stato esatto. Il RPO (transaction most recent) più esigente viene soddisfatto poiché tutte le repliche sono completamente sincronizzate. Le repliche secondarie sono hot standby, quindi possono essere utilizzate immediatamente come database principale.
Il failover può essere automatico o manuale. È possibile un failover automatico se tutte le repliche sono completamente sincronizzate. Nell'esempio precedente, questo è possibile perché tutte le repliche sono sempre completamente sincronizzate.
La figura seguente mostra un gruppo di disponibilità Always On in un'unica regione.
Il gruppo di disponibilità è rappresentato da un rettangolo che si estende su 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 del cluster di failover Always On
Per proteggerti dai guasti dei nodi, puoi utilizzare le istanze del cluster di failover (FCI) instead of standalone SQL Server instances. 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 del cluster esegue attivamente un'istanza SQL Server, mentre gli altri nodi non eseguono istanze SQL Server. Quando il nodo che esegue l'istanza SQL Server non funziona, un altro nodo del cluster avvia un'istanza SQL Server, assumendo la gestione del database (failover del nodo). Questa procedura di avvio automatico di un'istanza SQL Server fornisce funzionalità di disponibilità elevata.
Il cluster FCI viene visualizzato 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 disattivazione. Non si verifica alcuna perdita di dati quando si verifica un failover del nodo. Tutto ciò che viene eseguito all'interno dell'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 del cluster FCI possono essere configurati in zone Google Cloud diverse. Questa architettura non solo fornisce alta disponibilità in caso di errore del nodo, ma anche per errori di zona. Un esempio di deployment di questa strategia è descritto nella sezione sulle alternative di deployment del piano di ripristino.
Anche se diversi nodi gestiscono e condividono lo stesso database, non è richiesto uno spazio di archiviazione comune tra i nodi di un cluster FCI. SQL Server utilizza la funzionalità Storage Spaces Direct (S2D) per gestire i database sui dischi dei nodi dedicati. Per ulteriori informazioni, consulta Configurazione delle istanze del cluster di failover SQL Server.
L'esempio della sezione precedente Gruppi di disponibilità AlwaysOn con istanze del cluster di failover anziché istanze SQL Server autonome è mostrato nella seguente figura. Ogni FCI ha un'istanza SQL Server attiva che gestisce il database.
Come nel caso del gruppo di disponibilità, un gruppo di istanze flessibili è rappresentato da un rettangolo. Questa immagine è solo a scopo illustrativo per indicare che tutti i nodi appartengono allo stesso gruppo di istanze flessibili. Un gruppo di istanze flessibili non è una risorsa cloud e, pertanto, non è implementato in un nodo o in qualsiasi altro tipo di risorsa.
Per una discussione più dettagliata, consulta Istanze del cluster di failover AlwaysOn (SQL Server).
Gruppi di disponibilità distribuiti
I gruppi di disponibilità distribuiti sono un tipo speciale di gruppo di disponibilità. Un gruppo di disponibilità distribuito si estende su due gruppi di disponibilità, uno nel ruolo del gruppo di disponibilità principale e uno nel ruolo del gruppo di disponibilità secondario. I gruppi di disponibilità distribuita possono inoltrare le transazioni in modalità sia sincrona sia asincrona dal gruppo di disponibilità principale al gruppo di disponibilità secondario.
Anche se ogni gruppo di disponibilità ha il proprio database principale, non si tratta di 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 forwarder. Il forwarder 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à principali e secondari non devono trovarsi nella stessa posizione e non devono essere sullo stesso sistema operativo. Tuttavia, in ogni gruppo di disponibilità deve essere installato un listener. Il gruppo di disponibilità distribuito stesso non ha un ascoltatore. I gruppi di disponibilità distribuita non richiedono che i due gruppi di disponibilità si trovino nello stesso WSFC. Tutte le funzionalità richieste per il funzionamento dei gruppi di disponibilità distribuiti sono contenute nella funzionalità di SQL Server e non richiedono l'installazione aggiuntiva dei componenti sottostanti.
Un gruppo di disponibilità distribuito si estende su 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 a catena da un gruppo di disponibilità all'altro in più località. Un'altra topology è 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 il mezzo principale per implementare il piano di risposta ai disastri su più 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 come un rettangolo. Questo esempio è solo a scopo illustrativo per indicare che tutti i gruppi di disponibilità appartengono allo stesso gruppo di disponibilità distribuito. Un gruppo di disponibilità distribuito, come un gruppo di disponibilità, non è una risorsa cloud e, come tale, non è implementato in un nodo o in qualsiasi altro tipo di risorsa.
Per ulteriori informazioni, consulta Gruppi di disponibilità distribuiti.
Spedizione dei log
Il trasferimento 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 è molto più grande. La discrepanza è maggiore in termini di stato perché un file di log delle transazioni contiene molte modifiche dello stato. La discrepanza è maggiore anche in termini di tempo di latenza perché i file dei log delle transazioni vengono trasportati in modo asincrono e devono essere applicati nella loro interezza a un database secondario.
I file dei log delle transazioni vengono creati dal database principale e di cui viene eseguito il backup, ad esempio, in Cloud Storage. Ogni file di log delle transazioni viene copiato in ogni database secondario e applicato. Poiché il database secondario è in ritardo rispetto al database principale, sono in modalità di attesa attiva. Gli oggetti e le modifiche che non vengono acquisiti dai log delle transazioni devono essere applicati manualmente ai database secondari per stabilire una sincronizzazione completa senza perdita.
L'agente SQL Server automatizza il processo complessivo di creazione, copia e applicazione dei log delle transazioni. Il trasferimento dei log deve essere configurato singolarmente per ogni database. Se un gruppo di disponibilità gestisce più di un database, devono essere configurate altrettante procedure di invio dei log.
In caso di errore, la procedura di ripristino di emergenza deve essere avviata manualmente perché non è disponibile l'assistenza automatica. Inoltre, l'accesso dei 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 collegandosi al nuovo database principale dopo un ripristino di emergenza. È possibile creare astratti separate indipendentemente dalle istanze di SQL Server, ad esempio gli indirizzi IP mobili come descritto nella sezione Best practice per gli indirizzi IP mobili.
Poiché il trasferimento dei log è in parte una procedura manuale, puoi ritardare intenzionalmente l'applicazione dei file 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 è impedire 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 è stato ancora applicato un errore di modifica dei dati potrebbe diventare il database principale finché l'errore non viene risolto. Dopodiché, l'elaborazione normale può riprendere.
Come nel caso dei gruppi di disponibilità distribuiti, puoi utilizzare il trasferimento 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 in questa topologia non esiste una configurazione comune tra le regioni, come un gruppo di disponibilità distribuito.
I gruppi di disponibilità si trovano in regioni separate, uno su Linux e l'altro su Windows.
Per ulteriori informazioni sul trasferimento dei log di SQL Server, consulta Informazioni sul trasferimento dei log (SQL Server).
Combinazione delle funzionalità di disponibilità di SQL Server
Puoi implementare le funzionalità di disponibilità di SQL Server in combinazioni diverse. Ad esempio, nel caso d'uso precedente, è stata utilizzata la spedizione dei log con gruppi di disponibilità diversi 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 gruppi di disponibilità installati sullo stesso sistema operativo.
- Avere un gruppo di disponibilità principale che utilizza istanze 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 registra la spedizione tra regioni situate in continenti diversi.
Queste sono solo alcune delle possibili combinazioni di funzionalità di disponibilità di SQL Server.
La flessibilità offerta dalle funzionalità di disponibilità di SQL Server supporta la messa a punto di una strategia di ripristino di emergenza in base ai requisiti dichiarati.
Replica di SQL Server
La replica di SQL Server non è generalmente considerata una funzionalità di disponibilità, ma questa sezione descrive brevemente come può essere utilizzata per ripristino di emergenza.
La funzionalità di replica supporta la creazione e la manutenzione delle repliche dei database. Diversi tipi di agenti SQL Server collaborano per acquisire le modifiche, trasmetterle e applicarle alle repliche. Questo procedura è asincrona e le repliche in genere sono in ritardo rispetto al database sottoposto a replica in vari gradi.
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 è consapevole del fatto che i database assumono ruoli diversi nel contesto del piano di risposta ai disastri. Di conseguenza, la replica non dispone di operazioni che supportano il processo di recupero calamitoso, ad esempio le modifiche dei ruoli. Il processo di ripristino di emergenza deve essere implementato separatamente dalla funzionalità di SQL Server ed eseguito dall'organizzazione che lo esegue perché non sono presenti astratti per l'accesso client.
Spedizione del file di backup
L'invio di file di backup è un'altra strategia di implementazione del ripristino di emergenza. Un approccio standard per configurare e aggiornare continuamente un database secondario consiste nell'eseguire un backup completo iniziale del database primario e successivamente backup incrementali. 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 copia effettiva tra posizioni).
Questa strategia non prevede alcuna funzionalità di disponibilità di SQL Server quando si replicano le modifiche dello stato dal database principale a qualsiasi database secondario. Non utilizza l'agente SQL Server utilizzato nel caso del trasferimento dei log.
Per ulteriori informazioni, consulta la sezione Esempio: strategia di RE di backup e ripristino.
Rispetto all'approccio di replica discusso nella sezione precedente, sia la replica sia l'invio dei file di backup hanno in comune il fatto che il processo di ripristino di emergenza viene implementato al di fuori e separatamente dall'insieme di funzionalità di SQL Server. Dal punto di vista dell'invio delle modifiche acquisite, la replica di SQL Server è più comoda in quanto implementa questa parte automaticamente tramite gli agenti SQL Server.
Nota sull'interazione tra il ciclo di vita del database e il ciclo di vita dell'app
Il failover di un database non è completamente separato e indipendente dalle app che accedono al database. In linea di principio, esistono due scenari di errore.
Innanzitutto, l'app rimane operativa durante il failover del database. Dal momento in cui il database principale non è disponibile fino al momento in cui il nuovo database principale è operativo, le app non possono accedere al database. Le connessioni esistenti non vanno a buon fine e non vengono stabilite nuove connessioni. Durante questo periodo, l'app non è in grado di servire i propri clienti, 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 l'elaborazione normale.
Le app potrebbero avere uno stato esterno al database, ad esempio nelle cache della memoria principale. L'app assicura che la cache sia coerente (sincronizzata) con il nuovo database primario. Se non si è verificata alcuna perdita di transazioni durante il failover, la cache potrebbe essere coerente senza ulteriore manutenzione. Tuttavia, se si è verificata una perdita di transazioni (dati) 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 dei dati nel database fanno parte anche dei messaggi nelle code o dei 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 database primario. Ad esempio, se una regione viene messa 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 recupero del database in caso di calamità, devi avviare una procedura di recupero dell'app simile. L'app recuperata deve connettersi al nuovo database principale ed essere riconfigurata (ad esempio, indirizzi IP flottanti). Il recupero delle app non rientra nell'ambito di questo documento.
Relazione tra backup e ripristino per il 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 debba essere recuperato uno stato precedente a causa di errori o arresti anomali dell'app.
La sezione seguente illustra come utilizzare i backup come possibile meccanismo per implementare il ripristino di emergenza del database. In questo scenario, copi 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 recupero di emergenza. La discussione precedente sulle funzionalità di disponibilità ha presentato delle alternative.
Alta disponibilità e ripristino di emergenza
Sia l'alta disponibilità sia il ripristino di emergenza hanno in comune il fatto che forniscono soluzioni per l'indisponibilità del database. Se un database principale diventa disponibile, un database secondario diventa il nuovo database principale, coerente e disponibile.
La differenza tra l'alta disponibilità e il ripristino di emergenza è il dominio singolo punto di errore. L'alta disponibilità risolve un'interruzione all'interno di una regione, ad esempio quando si verifica un errore in una singola zona o in un nodo. Una soluzione ad alta disponibilità fornisce un nuovo database principale in un'altra zona della stessa regione. Inoltre, l'alta disponibilità risolve i guasti dei nodi, non solo quelli del database. Se un nodo che esegue un'istanza SQL Server non funziona, viene reso disponibile un nuovo nodo che esegue una nuova istanza SQL Server (consulta la sezione Istanza del cluster di failover AlwaysOn).
Il ripristino di emergenza coinvolge almeno due regioni. Riguarda il caso in cui un'intera regione non sia più disponibile. Il ripristino di emergenza può fornire un nuovo database primario in una regione diversa.
Le funzionalità di alta disponibilità di SQL Server supportano contemporaneamente soluzioni per l'alta disponibilità e il ripristino di emergenza. Un singolo gruppo di disponibilità può includere le zone all'interno di una regione e le regioni stesse. Un gruppo di disponibilità può contenere istanze di cluster di failover per garantire un'alta disponibilità.
SQL Server può stabilire gruppi di disponibilità all'interno di una regione per l'alta disponibilità e i guasti delle zone e combinarli con il trasferimento dei log tra regioni per gestire il ripristino di emergenza.
Alternative di deployment per RE
Nelle sezioni seguenti sono riportate alcune possibili topologie di ripristino di emergenza, oltre a quelle discusse finora. Queste topologie soddisfano diversi requisiti RPO e RTO. Questo elenco non è esaustivo.
RE e HA intraregionali
Questo deployment è una variante di un gruppo di disponibilità contenente istanze FCI all'interno di una regione composta da tre zone. In questo scenario, le zone sono considerate il singolo punto di dominio in errore.
Rispetto al deployment mostrato in precedenza, ogni gruppo di istanze flessibili è costituito da tre nodi in cui ogni nodo è in esecuzione in una zona diversa. Il vantaggio di questa configurazione è che una o due zone possono non funzionare senza richiedere un processo di ripristino di emergenza.
Il seguente diagramma mostra questa configurazione.
Gli FCI si estendono a tutte le zone e ogni FCI ha un'istanza SQL Server in esecuzione che accede al database corrispondente. In ogni gruppo di istanze flessibili sono presenti altre due istanze SQL Server non in esecuzione che possono essere avviate in caso di guasto di una zona. I database vengono visualizzati nelle varie zone perché ogni database utilizza i dischi di tutti i nodi di un determinato gruppo di istanze flessibili. Un'app non viene mostrata per chiarezza.
DR interregionale: gruppo di disponibilità che si estende su più regioni
In questo scenario, un gruppo di disponibilità viene eseguito su un cluster di failover di Windows Server e si estende su due regioni. Le regioni sono considerate un dominio con un singolo punto di défaillance.
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 delle transazioni sincrone, mentre le repliche nella regione R2 sono configurate per utilizzare la propagazione delle transazioni asincrone.
DR interregionale: trasferimento dei file di backup
Questo scenario utilizza il trasferimento dei file di backup. Due gruppi di disponibilità in due regioni sono collegati. Ogni gruppo di disponibilità ha le sue repliche che ricevono le transazioni in modo sincrono, pertanto le repliche secondarie di ogni regione sono in una configurazione di hot standby.
Il seguente diagramma illustra questa configurazione.
Tuttavia, i due gruppi di disponibilità sono collegati tramite il trasferimento dei file di backup. Il gruppo di disponibilità AG1 è il gruppo di disponibilità principale e il gruppo di disponibilità AG2 è il gruppo di disponibilità secondario. Poiché i file di backup vengono resi disponibili per il gruppo di disponibilità secondario, vengono applicati lì. Questo scenario è descritto in maggiore dettaglio nella sezione Esempio: strategia di RE di backup e ripristino.
Topologia con due località e località terziarie
Se sono presenti solo due database, uno principale e uno secondario, ciascuno in una regione separata, dopo un failover esiste un periodo di tempo non protetto dal momento in cui il nuovo database principale è 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 riposo forzato da cui è possibile recuperare solo quando viene stabilito un nuovo database principale. Lo stesso vale per i gruppi di disponibilità.
Una terza località con un altro database secondario o gruppo di disponibilità 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 RE
Indipendentemente dalla soluzione di ripristino di emergenza scelta, esistono passaggi di ciclo di vita comuni.
In una situazione di ripristino di emergenza reale, tutti gli stakeholder (proprietari di app, gruppi di operazioni e amministratori di database) devono essere disponibili e partecipare attivamente alla gestione del ripristino di emergenza. Gli stakeholder devono decidere sull'autorità decisionale (a volte indicata come master of ceremony) e sulle procedure decisionali da seguire. Inoltre, gli stakeholder devono trovare un accordo 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 prendere la decisione di avviare un failover. 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 principale.
Se la procedura di ripristino di emergenza richiede più tempo del previsto per risolvere la mancata disponibilità del database principale, un failover sarebbe dannoso. Innanzitutto, devi valutare se il ripristino del database principale è un'opzione fattibile.
Quanto più la strategia di ripristino di emergenza è testata e quanto più è rapida la sua implementazione, più è facile avviare il processo di failover perché occorre prendere in considerazione meno incertezza nella decisione.
Esecuzione del processo di failover
Idealmente, il processo di failover viene testato regolarmente ed è quindi 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 verificano. L'autorità decisionale gestisce il processo di failover e gli stakeholder sono responsabili del supporto dell'autorità decisionale.
Devi conservare le statistiche per l'analisi post mortem e il miglioramento del processo di failover, incluse le durate delle attività, i problemi riscontrati e eventuali confusioni nei passaggi del processo di failover.
Protezione mancante
Se hai un solo database secondario, non esiste alcuna protezione di RE dal momento in cui il nuovo database principale è disponibile e operativo fino alla configurazione di un nuovo database secondario. Un'interruzione del servizio durante questo periodo potrebbe causare un tempo di riposo forzato perché non è possibile eseguire il failover su 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 configurata in modo da garantire la protezione in qualsiasi momento, tutti gli stakeholder devono essere a conoscenza di questa durata della protezione mancante per adottare 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 non è attivo e funzionante. Non appena vengono applicate le modifiche dal database principale, questo diventa disponibile per le app. Sebbene questo approccio eviti che le app non siano protette dal RE, ritarda il completamento della procedura di ripristino di emergenza.
Evita situazioni di split-brain
È importante che le app non possano accedere contemporaneamente a un database principale e a un database secondario, emettendo operazioni DML. In questa situazione si verifica un'incongruenza dei dati quando sia il database principale sia quello 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 continua a funzionare e può ricevere operazioni di scrittura. Se la mancata disponibilità è causata da una partizione di rete intermittente, la partizione 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 principale potrebbero andare perse oppure alcune app potrebbero iniziare a operare sul nuovo database principale mentre altre accedono ancora al vecchio database principale.
Durante il processo di failover, l'accesso di tutte le app a qualsiasi database viene disattivato in modo che non si verifichino modifiche dello stato in nessuno dei database. Dopo il failover, per le operazioni di scrittura è disponibile un solo database, ovvero il nuovo database principale.
Dichiarazione di completamento
Al termine della procedura di failover, tutti gli stakeholder devono essere informati esplicitamente dall'autorità decisionale del completamento della procedura. Qualsiasi problema rilevato dopo il completamento deve essere trattato come un incidente separato che non fa più parte del processo di failover, ma dell'elaborazione regolare. Il problema potrebbe essere una conseguenza di un problema con il processo di failover o un problema indipendente. Tuttavia, l'approccio per risolvere il problema al termine del processo di failover potrebbe essere diverso da come viene risolto durante l'esecuzione del processo di failover.
Analisi e report post mortem
Per riferimento futuro e per migliorare la procedura di failover, organizza immediatamente un'analisi postmortem per prendere nota di aspetti, risultati e attività importanti.
Scrivi un report che riepiloghi l'evento di ripristino di emergenza, le cause principali e tutte le azioni intraprese. Questo report potrebbe essere obbligatorio se stai implementando i requisiti previsti dalle normative.
Test e verifica della RE
Poiché ripristino di emergenza non fa parte delle normali operazioni quotidiane, la soluzione di RE deve essere testata regolarmente per assicurarne il corretto funzionamento quando è effettivamente necessaria.
La frequenza dei test dipende dai requisiti operativi e varia in base al database, all'app e all'azienda. Inoltre, le modifiche all'ambiente, come le modifiche alla configurazione di rete e gli aggiornamenti dei componenti dell'infrastruttura, devono attivare un test di ripristino di emergenza se le modifiche vengono apportate ai sistemi su cui si basa la soluzione di ripristino di emergenza scelta. Qualsiasi modifica potrebbe causare l'esito negativo della soluzione di disaster recovery o richiedere l'aggiustamento del processo di ripristino di emergenza.
Puoi eseguire il test manualmente avviando la procedura di passaggio o automaticamente seguendo un approccio di chaos engineering come descritto in Chaos engineering. Con i test manuali, puoi ridurre al minimo l'impatto sull'attività nel caso in cui si preveda un tempo di inattività significativo.
Un aspetto importante dei test è la raccolta di statistiche ben definite. Di seguito sono riportate alcune statistiche importanti da considerare:
- Tempo di recupero effettivo: misura il tempo di recupero effettivo e confrontalo con il RTO.
- Punto di ripristino effettivo: osserva il punto di ripristino effettivo e confrontalo con il RPO.
- Tempo di rilevamento dell'errore: il tempo necessario ai DBA o al team operativo per rendersi conto della necessità del failover.
- Tempo di inizio del recupero: il tempo necessario per avviare il processo di failover dopo il rilevamento dell'errore.
- Affidabilità: con quale attenzione è stata seguita la procedura di failover o sono state richieste deviazioni? Si sono verificati problemi imprevisti che devono essere esaminati, con possibile conseguente modifica della strategia di recupero?
In base alle statistiche raccolte, la procedura di failover potrebbe dover essere aggiustata o migliorata per soddisfare meglio le aspettative relative a RPO e RTO.
Esempio: strategia di RE di backup e ripristino
Le sezioni seguenti descrivono un esempio di strategia di backup e ripristino di emergenza. Questo scenario riduce al minimo l'utilizzo delle funzionalità di disponibilità di SQL Server per dimostrare lo sforzo necessario per specificare una strategia di backup e ripristino del piano di recupero RE e per discutere di aspetti invisibili in configurazioni più automatizzate.
Caso d'uso
Un gruppo di disponibilità Always On principale è operativo nella regione R1. Il gruppo di disponibilità Always On secondario viene aggiunto nella regione R2 per una protezione tra regioni aggiuntiva ed è disponibile come destinazione di failover o switchover.
Strategia
La strategia di ripristino di emergenza si basa sui backup del database. Viene eseguito un backup completo iniziale seguito da backup differenziali successivi. I backup vengono applicati al gruppo di disponibilità Always On secondario man mano che vengono eseguiti. 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à Always On principale in R2 sia attivo e non protetto per un periodo di tempo limitato fino a quando il nuovo gruppo di disponibilità Always On secondario in R1 non è operativo.
Non è necessario eseguire il fallback perché il gruppo di disponibilità AlwaysOn in ciascuna delle regioni è ugualmente idoneo a fungere da gruppo di disponibilità AlwaysOn di produzione.
RTO e RPO
In questo esempio, il RPO è definito come massimo 60 minuti, pertanto viene eseguito un backup differenziale ogni 60 minuti.
Il tempo di risposta obiettivo non è impostato esplicitamente su una durata, ma deve essere il più breve possibile: il valore migliore è immediato. Il gruppo di disponibilità secondario deve essere impostato come hot standby. In caso di hot standby, tutti i backup vengono applicati immediatamente in modo che il failover non venga ritardato dall'applicazione dei backup.
Strategia di RE di alto livello
Le sezioni seguenti descrivono la strategia di RE. È breve per concentrarsi su i passaggi essenziali.
Impostazione iniziale
- Crea un gruppo di disponibilità AlwaysOn secondario nella regione R2.
- Impedisci all'app di accedere al gruppo di disponibilità secondario in modo che non si verifichi accidentalmente una situazione di split brain.
- 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 differenziali orari 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 dei file.
Strategia di lancio
- Applica il backup completo al gruppo di disponibilità Always On secondario nella regione R2.
- Quando i backup differenziali diventano disponibili, applicali immediatamente al gruppo di disponibilità AlwaysOn secondario in R2. L'applicazione immediata è necessaria per risolvere il problema RTO.
- Dopo aver applicato il backup completo iniziale e tutti i backup incrementali, il gruppo di disponibilità Always On secondario è pronto.
- Testa la strategia di RE eseguendo il passaggio dal gruppo di disponibilità principale al gruppo di disponibilità secondario. Durante i test deve essere disponibile almeno un backup incrementale.
Richiesta di failover o switchover
In R2, i passaggi essenziali sono i seguenti:
- Assicurati che l'ultimo backup differenziale sia stato applicato al gruppo di disponibilità Always On secondario in R2.
- Designa R2 come nuovo gruppo di disponibilità AlwaysOn principale.
- Crea un nuovo bucket B2, esegui un backup completo come riferimento e apri il nuovo gruppo di disponibilità principale per l'accesso alle 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à Always On in R1 diventa nuovamente disponibile (come nuovo gruppo di disponibilità Always On secondario), impedisci l'accesso alle app e rimuovi tutti i dati dal database o reimpostalo allo stato iniziale (vuoto) (a meno che non debba essere creato di nuovo).
- Applica il backup completo dal nuovo gruppo di disponibilità Always On primario in R2 e continua ad applicare i backup differenziali subito 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 passaggio, pur essendo in grado di configurare rapidamente il nuovo gruppo di disponibilità secondario. Anziché un singolo backup completo e i backup differenziali successivi, esegui un backup completo ogni settimana e crea un bucket settimanale contenente 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 viene utilizzato questo approccio settimanale, devi implementare una strategia di pulizia o eliminazione per rimuovere i backup obsoleti.
Un altro miglioramento si basa sul fatto che il nuovo gruppo di disponibilità secondario era l'ex gruppo di disponibilità principale. Se il database esiste ed è operativo dopo essere tornato disponibile, un recupero 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 punto nel tempo (modello di recupero completo). Questo scenario riduce lo sforzo e il tempo durante il quale il nuovo gruppo di disponibilità primario non è 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 del cluster di failover. Il tipo di istanze da utilizzare deve essere deciso prima dell'implementazione.
Fino a quando un nuovo gruppo di disponibilità Always On secondario non è operativo dopo un failover, esiste 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 assicurarti che eventuali errori o guasti vengano rilevati. 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à AlwaysOn di SQL Server.
- Esegui il deployment di un gruppo di disponibilità SQL Server 2016 AlwaysOn con più subnet su Compute Engine.
- Configurazione delle istanze del cluster di failover SQL Server.
- Eseguire il clustering di failover di Windows Server.
- Come attivare Cloud Logging, Cloud Monitoring ed Error Reporting per le app .NET
- Installazione dell'agente Cloud Monitoring.
- Esplora architetture di riferimento, diagrammi e best practice su Google Cloud. Consulta il nostro Cloud Architecture Center.