Questo documento illustra le strategie di ripristino di emergenza (RE) per Microsoft SQL Server per architetti e responsabili tecnici responsabili della progettazione e l'implementazione del ripristino di emergenza su Google Cloud.
I database possono non essere più disponibili per vari motivi, ad esempio per hardware o errori di rete. Per garantire l'accesso continuo al database durante gli errori, viene mantenuto, ovvero una replica di un per configurare un database. Se il database secondario si trova in una località diversa aumenta è probabile che sia disponibile quando il database principale non è più disponibile.
Se il database principale non è disponibile, la tua app mission-critical si connette a un database secondario, partendo dai dati coerenti noti più recenti per fornire servizi agli utenti con tempi di inattività minimi o nulli.
Il processo per rendere disponibile un database secondario in caso di errore dell'istanza principale il ripristino di emergenza (RE) del database. Il database secondario a causa dell'indisponibilità del database primario. 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 è 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 offre funzionalità di ripristino di emergenza, tra cui Microsoft SQL Server. Questo documento sull'architettura illustra come 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 DR
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. Clienti accedono all'app eseguita 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, sia disponibile nel database secondario il prima possibile, quindi i client potrebbero non subirà alcuna interruzione. 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ù veloce risolvere anziché eseguire il failover.
Database primari 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 una 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 a causa di ritardi nell'applicazione delle modifiche transazionali apportate in e il database principale. È possibile associare più di un database secondario con un database primario, a seconda della tecnologia del database. SQL Server supporta l'associazione di più di un database secondario a un database principale.
Ripristino di emergenza
Se un database principale non è disponibile, il piano di ripristino dei dati 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 riconnettersi al nuovo database principale per continuare accede al proprio stato. Se il nuovo database principale non era sincronizzato con ultimo stato noto dell'ex database principale, l'app inizia da un (noto anche come flashback).
È importante avere sempre almeno un database secondario per ogni database principale. Dopo un piano di ripristino dei disastri, assicurati di configurare un nuovo database secondario per gestire futuri scenari di questo tipo.
Failover, switchover e fallback
Esistono diversi scenari per cambiare il ruolo tra i database principale e secondario:
- Failover: il processo di modifica del ruolo di un database secondario. come nuovo database principale a cui collegare 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 ripristino di emergenza con un passaggio periodico regolare per garantire la continua affidabilità del ripristino di emergenza.
- Di riserva: la procedura di riserva inverte la procedura in cui la nuova diventa il database secondario, dopo che il database primario riparato. 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 eseguita in base ai requisiti di disaster recovery, 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 corrispondente database secondario si trova in un'altra regione.
Modalità attive: attivo-passivo e attivo-attivo
Un database primario è un database aperto per operazioni di lettura e scrittura (DML operazioni) 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 un cambio, il database secondario diventa il nuovo database primario e diventa attivo per configurare un database.
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à standby: caldo, caldo, freddo e nessun standby
Affinché il database principale sia il database attivo, deve essere in esecuzione e in grado di eseguire istruzioni DML. Non è necessario che il database secondario in esecuzione. può essere arrestata. Se non è in esecuzione, il tempo necessario il ripristino da un'emergenza aumenta perché il nuovo database in esecuzione prima di assumere il ruolo per configurare un database.
Esistono diverse varianti di configurazione del database secondario:
- Hot standby: il database secondario è attivo e in esecuzione e pronto per a cui possono connettersi i clienti. La modifica più recente disponibile dal database primario viene sempre applicata non appena diventa disponibile.
- Standby a 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 standby: il software del database deve essere prima installato e successivamente avviato prima che tutte le modifiche dal database principale applicati. Questa è la modalità meno costosa perché non consuma le risorse quando non servono, ma rispetto alle altre modalità richiede più lungo per diventare un nuovo database principale.
Strategie di RE
Nelle sezioni seguenti, le strategie di RE supportate da Microsoft SQL Server sono: è stata spiegata.
Dimensioni della strategia di recupero
Ci sono diverse dimensioni chiave da considerare quando selezioni o implementi un la strategia di ripristino di emergenza del database. Ogni dimensione ha uno spettro e il comportamento e le aspettative della strategia di ripristino di emergenza dipendono dalla selezione dei punti dello spettro. Le dimensioni principali sono le seguenti:
- RPO (Recovery Point Objective): Il periodo di tempo massimo accettabile durante il quale i dati possono 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 in cui il database primario non è più disponibile o possono essere espresse come stati di elaborazione identificabili (ultimo backup completo l'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'ultimo transazione, il che significa nessuna perdita dal database principale a quello secondario del database.
- 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. L'RTO di solito è espresso in termini di durata dal momento della configurazione indisponibilità del database, 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 dei dati 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 piano di risposta agli incidenti. Se una regione è un single point of dominio in errore per il ripristino di emergenza deve essere configurato in modo che due o più regioni sono coinvolti 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 un di emergenza, il ripristino di emergenza può essere configurato in più zone all'interno di regione. Se una zona non funziona, il ripristino di emergenza utilizza una seconda zona e nuovo database primario disponibile 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 disponibilità sono disponibili su Linux. SQL Server ha diverse versioni, ma non tutte le funzioni di disponibilità sono disponibili completamente gestita.
SQL Server distingue le istanze dai database. Un'istanza è l'esecuzione il software SQL Server, mentre un database è l'insieme di dati gestito da una SQL Server.
Gruppi di disponibilità sempre attivi
I gruppi di disponibilità sempre attivi forniscono protezione a livello di database. Un gruppo di disponibilità ha due o più repliche. Una replica è quella principale con accesso in lettura e scrittura e le repliche rimanenti sono repliche secondarie che possono fornire accesso in lettura. Ogni replica del database è gestita da un'istanza SQL Server autonoma. Un gruppo di disponibilità può contenere uno o più database. Il numero di database che possono essere inclusi in un gruppo di disponibilità e il di repliche secondarie supportate dipende dalla versione di SQL Server. Tutti i database di un gruppo di disponibilità subiscono le stesse modifiche del ciclo di vita contemporaneamente. 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 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 a livello di database e di istanze SQL Server, devi per configurare le istanze cluster di failover (FCI). Questa architettura di deployment di cui parleremo più avanti 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 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 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 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. 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 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. Secondaria sono hot standby, quindi ognuna di queste può essere utilizzata immediatamente come per configurare un database.
Il failover può essere automatico o manuale. È possibile un failover automatico 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à sempre attivo in una singola 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 evitare errori dei nodi, puoi utilizzare le istanze cluster di failover (FCI) anziché istanze SQL Server autonome. Due o più nodi vengono eseguiti 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 nodi non eseguono istanze SQL Server. In caso di errore del nodo che esegue l'istanza SQL Server, un cluster avvia un'istanza SQL Server, assumendo la gestione (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 vedrai il failover tra nodi, tranne forse per un breve periodo indisponibilità. Non si verifica alcuna perdita di dati quando si verifica un failover del nodo. Tutto in esecuzione all'interno dell'istanza SQL Server non riuscita viene spostata in un altro 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 fornisce alta disponibilità in caso di errore del nodo, ma anche per gli errori di zona. Un esempio di deployment di questa strategia è discusso nella Sezione Alternative al deployment di RE.
Anche se nodi diversi gestiscono lo stesso database e lo condividono, non c'è uno spazio di archiviazione comune richiesto 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à sempre attivi di Compute Engine, anziché istanze SQL Server autonome è illustrata di seguito figura stilizzata. 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. Questa immagine è solo a scopo illustrativo per indicare che tutti i nodi appartengono allo stesso gruppo di istanze flessibili. Una FCI non è una risorsa cloud e, come tale, non è implementata in un nodo o 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à 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 sincrona e asincrona, dal gruppo di disponibilità principale il gruppo di disponibilità secondario.
Anche se ogni gruppo di disponibilità ha il proprio database principale, non si tratta di un deployment active-active. Solo il database principale dell'istanza principale può ricevere operazioni di scrittura. Il database principale un gruppo di disponibilità secondario viene chiamato forwarding. 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à primario e secondario non devono essere necessariamente nello stesso e non devono necessariamente 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. Disponibilità distribuita non richiedono che i due gruppi di disponibilità siano 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 di componenti sottostanti.
Un gruppo di disponibilità distribuito si estende su esattamente due gruppi di disponibilità. Un Il gruppo di disponibilità può far parte di due gruppi di disponibilità distribuita. Questo più probabilità supporta diverse topologie. Uno è una topologia a daisy chain da un gruppo di disponibilità a un gruppo di disponibilità in diverse 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à distribuita sono il mezzo principale per implementare le emergenze il ripristino dei dati su diversi 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à distribuite.
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. a scopo puramente illustrativo per indicare che I gruppi di disponibilità appartengono tutti allo stesso gruppo di disponibilità distribuita. 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, vedi Gruppi di disponibilità distribuita.
Spedizione 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 di log delle transazioni vengono creati dal database principale e ne viene eseguito il backup, ad esempio ad esempio in Cloud Storage. Ogni file di log delle transazioni viene copiato un database secondario e applicato a quest'ultimo. Poiché il database secondario è in ritardo rispetto al database principale, sono in modalità di attesa attiva. Oggetti e modifiche che non vengono acquisiti dai log delle transazioni devono essere applicati manualmente i database per una sincronizzazione completa senza perdite.
L'agente SQL Server automatizza il processo complessivo di creazione, copia e applicando i log delle transazioni. Il trasferimento dei log deve essere configurato singolarmente per ogni database. Se un gruppo di disponibilità gestisce più di un database, come è necessario configurare molti processi di spedizione dei log.
In caso di errore, la procedura di disaster recovery 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. Nel in caso di failover, i client devono essere in grado di gestire dal ruolo secondario al nuovo ruolo principale autonomamente e la connessione alla nuova rete 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é la spedizione dei log è in parte un processo manuale, puoi ritardare l'applicazione della copia di registrare intenzionalmente i file nei database secondari (contrariamente alla disponibilità e gruppi di disponibilità distribuita a cui vengono applicate le modifiche immediatamente). Un possibile caso d'uso è evitare errori di modifica dei dati nella da applicare ai database secondari fino a quando i dati la correzione degli errori di modifica. In questo caso, un database secondario non ancora l'applicazione di un errore di modifica dei dati potrebbe diventare il database principale finché l'errore di modifica dei dati 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 log spedizione. Tieni presente che non esiste una configurazione comune tra regioni, ad esempio un gruppo di disponibilità distribuita in questa topologia.
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 eseguire il deployment delle funzionalità di disponibilità di SQL Server in diverse combinazioni. Ad esempio, nel caso d'uso precedente, è stata utilizzata la spedizione dei log con 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 i gruppi di disponibilità installati sullo stesso un intero sistema operativo.
- Avere un gruppo di disponibilità principale che utilizza FCI con un che utilizza solo istanze SQL Server autonome.
- 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 disponibilità di SQL Server le funzionalità di machine learning.
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 SQL Server
La replica di SQL Server non è generalmente considerata una funzionalità di disponibilità, ma questa sezione descrive brevemente come può essere utilizzata per il disaster recovery.
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, per trasmettere le modifiche acquisite 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 ripristino di emergenza, il database di produzione è il database principale 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 da implementare separatamente dalla funzionalità SQL Server ed eseguire organizzazione che implementa l'implementazione in assenza di astrazioni dell'accesso client.
Spedizione del file di backup
L'invio di file di backup è un'altra strategia di implementazione del ripristino di emergenza. R approccio standard alla configurazione e all'aggiornamento continuo di un database secondario esegue un backup iniziale completo del database principale e backup incrementali se ne va. Tutti i backup incrementali vengono applicati ai database secondari nell'ordine corretto. Ci sono molte varianti a questo approccio a seconda del frequenza dei backup incrementali e quindi della posizione di archiviazione dei file di backup (globale posizione geografica o che sono stati copiati da una località all'altra).
Questa strategia non prevede alcuna funzionalità di disponibilità di SQL Server quando replicando 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 su Esempio: strategia 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. Per quanto riguarda la spedizione delle modifiche acquisite, la replica di SQL Server in quanto implementa questa parte automaticamente per mezzo di SQL Server, Agenti.
Nota sull'interazione tra il ciclo di vita del database e il ciclo di vita dell'app
Un failover del database non è completamente separato e indipendente dalle app che accedono del database. In linea di principio, esistono due scenari di errore.
Per prima cosa, 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 della transazione (dati) che si è verificata durante il failover, la cache potrebbe coerente rispetto al nuovo database primario. La discussione analoga si applica allo stato condiviso quando, ad esempio, alcuni dati nel database sono anche parte dei messaggi in code o file nel file system. Questo aspetto di la coerenza dei dati non rientra nell'ambito di questo documento perché non riguarda relative 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. Insieme al disastro del database devi avviare una procedura di recupero dell'app simile. La l'app recuperata deve connettersi al nuovo database principale ed essere riconfigurata (ad (ad esempio gli indirizzi IP mobili). Il recupero delle app non rientra nell'ambito di questa procedura documento.
Relazione tra backup e ripristino nel ripristino di emergenza
Backup di un database è indipendente e ortogonale al ripristino di emergenza del database. Lo scopo di backup del database consiste nel ripristinare uno stato coerente, ad esempio se un database viene perso o danneggiato oppure se deve essere stato eseguito uno stato precedente il ripristino a causa di errori o bug dell'app.
La sezione seguente illustra come utilizzare i backup come possibile meccanismo di implementazione del 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 le emergenze recovery; la precedente discussione sulle funzionalità di disponibilità presentate 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 primario diventa non disponibile, un database secondario diventa il nuovo database primario coerente e disponibile.
La differenza tra l'alta disponibilità e il ripristino di emergenza è la singola il dominio point of failure. 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. Un'alta disponibilità fornisce un nuovo database principale in un'altra zona della stessa regione. Nel inoltre, errori nei nodi degli indirizzi ad alta disponibilità, non solo errori 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 interessa almeno due regioni. Riguarda il caso in cui un'intera regione non sia più disponibile. Il ripristino di emergenza può fornire un nuovo in una regione diversa.
Le funzionalità ad alta disponibilità di SQL Server supportano soluzioni per l'alta disponibilità la disponibilità e il ripristino di emergenza. Un unico gruppo di disponibilità possono estendersi sia sulle zone all'interno di una regione sia sulle 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 e gli errori nelle zone, nonché combinarli con la spedizione dei log nelle varie regioni. per risolvere i problemi di ripristino di emergenza.
Alternative al deployment di RE
Nelle sezioni seguenti sono riportate alcune possibili topologie per il ripristino di emergenza mostrati in aggiunta a quelli trattati finora. Queste topologie soddisfano diversi requisiti RPO e RTO. L'elenco non è esaustivo.
RE e alta disponibilità 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 FCI è composto 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 disaster recovery.
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. Esistono altre due istanze SQL Server che non sono in esecuzione in ogni FCI che può essere avviata in caso di errore di una zona. I database vengono mostrato nelle varie 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 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.
RE tra regioni: trasferimento file di backup
Questo scenario utilizza il trasferimento di 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, di conseguenza, le repliche secondarie di ogni regione sono in un hot standby configurazione.
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 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 modo più dettagliato nella sezione seguente, Esempio: strategia di RP di backup e ripristino.
Topologia con doppia posizione e posizione terziaria
Se sono presenti solo due database, uno principale e uno secondario ognuna in una regione a parte, esiste una durata non protetta dopo che il failover dal momento in cui il nuovo database principale è in esecuzione e il nuovo è pronto. Se il nuovo database principale non è più disponibile mentre non è ancora in esecuzione, si verifica un tempo di inattività rigido che può da ripristinare quando viene stabilito un nuovo database primario. Lo stesso vale ai 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 prima lo stesso vale per i gruppi di disponibilità.
Ciclo di vita del DR
Indipendentemente dalla soluzione di ripristino di emergenza scelta, esistono passaggi del ciclo di vita applicabili.
In una situazione reale di ripristino di emergenza, tutte le parti interessate (proprietari di app, gruppi operativi e amministratori di database) devono essere disponibili e attivamente nella gestione del ripristino di emergenza. Gli stakeholder devono decidere presso l'autorità decisionale (a volte indicato come maestro di cerimonia) e i processi decisionali che seguono. 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 per avviare un failover. I vari stakeholder devono coordinano la 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 dei disastri 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 primario è un'opzione fattibile.
Più viene testata la strategia di ripristino di emergenza e più veloce implementato, più facile sarà avviare il processo di failover perché l'incertezza deve essere considerata nella decisione.
Esecuzione del processo di failover
Idealmente, il processo di failover viene testato regolarmente e, pertanto, è ben noto tra i 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 processo di failover improvement; tra cui la durata delle attività, i problemi emersi e qualsiasi nei passaggi del processo di failover.
Protezione mancante
Se hai un solo database secondario, non esiste alcuna protezione di DR dal momento in cui il nuovo database primario è disponibile e operativo fino alla configurazione di un nuovo database secondario. Se la disponibilità non è disponibile in questo periodo di tempo, perché non è possibile eseguire il failover a un altro database. Se la situazione un altro database primario deve essere configurato e l'RPA è l'ultimo punto che possono essere ricostruiti in base ai backup disponibili.
A meno che la strategia di ripristino di emergenza non sia impostata in modo da garantire protezione sempre, ogni stakeholder deve essere consapevole di questa durata di sicurezza per adottare precauzioni aggiuntive durante la configurazione o la configurazione dell'ambiente modifiche.
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 del database principale, questo è disponibile per le applicazioni. Sebbene questo approccio eviti che le app non siano protette dal piano di ripristino dei disastri, ritarda il completamento della procedura di ripristino dei disastri.
Evita situazioni di split-brain
È importante che le app non possano accedere a un database principale e a un database contemporaneamente, eseguendo 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 al 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.
L'accesso alle app viene disattivato per qualsiasi database durante il processo di failover, per impedire che lo stato cambi in nessuno dei database. Dopo il failover, per le operazioni di scrittura è disponibile un solo database: il nuovo database principale.
Dichiarazione di completamento
Al termine del processo di failover, tutti gli stakeholder devono informati dall'autorità decisionale che il processo è completato. Qualsiasi problema visualizzato una volta completato, deve essere trattato come un incidente separato del processo di failover, ma che fa parte dell'elaborazione regolare. Il problema potrebbe essere una conseguenza di un problema con il processo di failover oppure un problema del tutto. Tuttavia, l'approccio per risolvere il problema dopo il failover processo completato potrebbe essere diverso da come viene gestito durante nell'esecuzione del processo di failover.
Analisi e report post mortem
Come riferimento futuro e per migliorare il processo di failover, organizzare una sessione mortem per prendere nota di aspetti importanti, risultati e attività.
Scrivi un report che riassuma l'evento di ripristino di emergenza, le cause principali e tutto azioni intraprese. Questo report potrebbe essere obbligatorio se stai implementando i requisiti previsti dalle normative.
Test e verifica RE
Poiché il disaster recovery non fa parte delle normali operazioni quotidiane, la soluzione di DR deve essere testata regolarmente per assicurarne il corretto funzionamento quando è effettivamente necessaria.
La frequenza dei test dipende dai requisiti operativi e varia per database, app e 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 ripristino di emergenza 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. Alcune le statistiche più importanti da prendere in considerazione sono le seguenti:
- Tempo di recupero effettivo: misura il tempo di recupero effettivo e confrontalo con il RTO.
- Punto di ripristino effettivo: osservare il punto di recupero effettivo e confrontarlo con l'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 di RPO e RTO.
Esempio: strategia di DR di backup e ripristino
Le sezioni seguenti descrivono un esempio di ripristino di emergenza di backup e ripristino strategia. 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 dei disastri 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à Sempre attivo secondario viene aggiunto nella regione R2 per tra regioni diverse e disponibile come destinazione di failover o cambio.
Strategia
La strategia di ripristino di emergenza si basa sui backup del database. Il file iniziale completo viene eseguito, seguito dai successivi backup differenziali. 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 utilizzare i servizi di riserva poiché il gruppo di disponibilità "Sempre attivo" in ciascuno dei di regioni ha la stessa qualifica per offrire i servizi di produzione come disponibilità gruppo.
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 configurato 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 RP di alto livello
Le sezioni seguenti descrivono la strategia di RE. Si tratta di un titolo breve, 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 consente di stabilire il corretto ordine cronologico in base alla data e all'ora che fanno parte dei vari nomi di file.
Strategia di lancio
- Applica il backup completo al gruppo di disponibilità Always On secondario nella regione R2.
- Man mano che i backup differenziali diventano disponibili, applicali immediatamente al gruppo di disponibilità AlwaysOn secondario in R2. L'applicazione immediata è necessarie per affrontare l'RTO.
- Dopo aver applicato il backup completo iniziale e tutti i backup incrementali, il gruppo di disponibilità Sempre attivo secondario è pronto.
- Testare la strategia di RE eseguendo il cambio dall'istanza principale gruppo di disponibilità secondario al gruppo di disponibilità secondario. Durante i test deve essere disponibile almeno un backup incrementale.
Richiesta di failover o cambio
In R2, i passaggi essenziali sono i seguenti:
- Assicurati di aver applicato l'ultimo backup differenziale gruppo di disponibilità Sempre attivo 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à Sempre attivo in R1 diventa disponibile (come nuovo gruppo di disponibilità Sempre attivo secondario), impedisci l'accesso e rimuovere tutti i dati dal database o reimpostarlo stato iniziale (vuoto) (a meno che non sia stato creato di recente).
- Applica il backup completo dal nuovo sistema principale sempre attivo gruppo di disponibilità in R2 e continuare ad applicare backup differenziali immediatamente quando 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 aggiungere al bucket. Il nuovo gruppo di disponibilità secondario applica semplicemente 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 stato di nuovo disponibile, un recupero point-in-time fino all'ultima il backup differenziale evita di doverlo ripristinare completamente dall'ultimo backup completo come descritto in Ripristina un database SQL Server in un momento specifico (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 utilizzate degli oggetti prima dell'implementazione.
Fino a quando un nuovo gruppo di disponibilità Sempre attivo secondario non diventa operativo dopo un di failover, c'è un momento in cui RE non è protetto. Dovresti 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 è indispensabili per una soluzione di ripristino di emergenza funzionante.
Passaggi successivi
- Configurazione dei gruppi di disponibilità AlwaysOn di SQL Server.
- Deployment di un gruppo di disponibilità SQL Server 2016 Always On con più subnet su Compute Engine.
- Configurazione delle istanze del cluster di failover 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. Dai un'occhiata al nostro Centro architetture cloud.