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 presenta esattamente lo stesso stato coerente principale quando non è disponibile o manca solo un insieme minimo di dati recenti transazioni del database principale.
Database DR è una funzionalità essenziale per i clienti aziendali. Il fattore principale è continuità aziendale per le app mission-critical. Ad esempio, un modello genera entrate (e-commerce), fornisce servizi continuativi e affidabili (gestione del traffico o del gruppo propulsore) o supporta funzionalità salvavita (monitoraggio del paziente). In tutti questi esempi, è della massima importanza che l'app sia sempre disponibile perché è considerato 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 RE
Il seguente diagramma illustra la topologia dell'architettura di RE generale.
Nel diagramma precedente, un'app accede a un database principale mentre un'app secondaria è in standby e rispecchia lo stato del database principale. Clienti accedono all'app eseguita su Google Cloud.
Se il database principale non è più disponibile, gli amministratori del database o il team delle operazioni debba decidere di avviare la procedura di ripristino di emergenza. In caso di emergenza del database ripristino avviato, l'app viene riconnessa al database secondario. Dopo il giorno è connessa, l'app può tornare a servire i 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 l'istanza principale affinché 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
Una o più app accedono a un database principale per fornire persistenza per la gestione dello stato dell'app. Un database secondario è correlato a una e contiene una replica del database principale. Idealmente, il i contenuti del database secondario corrispondono esattamente ai contenuti del database 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 primario non è più disponibile, RE cambia il ruolo del database secondario in modo che diventi il database principale. Se è presente più di un database, uno di questi database viene selezionato manualmente o in base a una nell'elenco di failover. 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 e il database principale. Dopo un ripristino di emergenza, assicurati che una nuova sia configurato per gestire scenari futuri di ripristino di emergenza.
Failover, cambio e fallback
Esistono diversi scenari per cambiare il ruolo tra principale e database secondari:
- Failover: il processo di modifica del ruolo di un database secondario. come nuovo database principale a cui collegare tutte le app. Il failover è non intenzionale perché viene attivato da un database primario che non disponibile. Puoi configurare il failover in modo che venga attivato automaticamente manualmente.
- Cambio: a differenza del failover, il passaggio da un'istanza a un database secondario (nuovo database primario), sia intenzionalmente per i test iniziali e la manutenzione pianificata. Testa RE il sistema con un cambio periodico regolare per garantire l'affidabilità continua 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. Un fallback viene attivato intenzionalmente per ristabilire lo stato prima dell'inizio del failover o del cambio. Non è strettamente ma può essere eseguita in base ai requisiti di ripristino di emergenza, località o risorse disponibili.
Zone e regioni Google Cloud
Risorse come i database si trovano Zone e regioni di Google Cloud, in cui ogni zona appartiene a una regione. Una zona è un singolo dominio point of failure. Consigliamo di eseguire il deployment di una risorsa ad alta disponibilità e a tolleranza di errore in in più zone all'interno di una regione.
Per evitare l'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 principale è un database attivo. Il database secondario corrispondente è passivo perché replica il database principale, ma non è disponibile qualsiasi 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.
Sia il database principale che quello secondario possono essere attivi se la tecnologia del database supporta questa funzione, denominata attivo-attivo . In questo caso, le app possono connettersi all'una o all'altra perché entrambi i database disponibili per la gestione degli stati. Ripristino di emergenza in modalità attiva-attiva non richiede un failover se solo uno dei database attivi non disponibile. Se un database attivo non è disponibile, l'altro database attivo continua a essere disponibile. La modalità attiva-attiva non rientra nell'ambito di questa perché SQL Server non supporta questa modalità.
Modalità standby: caldo, caldo, freddo e nessun standby
Affinché il database primario sia il database attivo, deve essere in esecuzione ed essere 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. L'ultima modifica disponibile dalla principale viene sempre applicato non appena diventa disponibile.
- standby caldo: un database secondario è attivo e in esecuzione, ma non tutte le modifiche apportate al database principale sono già state necessariamente applicate.
- Cold standby: un database secondario non è in esecuzione. Innanzitutto, per poi essere sincronizzati nell'ultimo stato 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: come spiegato in precedenza.
Dimensioni della strategia di ripristino
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 comportamento e le aspettative della strategia di ripristino di emergenza dipendono la 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 a le modalità di utilizzo dei 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 l'RPO, il disastro strategia di ripristino deve implementare la misura specifica in modo che l'RPO di Google Cloud. 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 durante il quale la tua app può rimanere offline. Questo valore viene solitamente specificato come parte di un Accordo sul livello del servizio (SLA). 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 è immediato, in modo che gli utenti dell'app non noti che è avvenuto il ripristino di emergenza.
- Dominio single point of failure. Spetta a te decidere se un regione è considerata un single point of dominio in errore per il tuo disastro per il ripristino di emergenza. 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 principale un errore del database, il database secondario in una regione diversa è il nuovo e il 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 fondamentali comporta la scelta tra costo e qualità. Più bassi sono i valori RTO e RPO, più costosa può essere la soluzione di ripristino di emergenza man mano che vengono utilizzate risorse più attive. Nelle sezioni seguenti, vengono discusse strategie alternative di RE che rappresentano i punti sulle dimensioni nel contesto del database Microsoft SQL Server.
Strategie di RE per SQL Server
Continuità aziendale e ripristino dei database - SQL Server descrive le funzioni di disponibilità che puoi usare per implementare il ripristino di emergenza strategie.
Eliminazioni
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 modello SQL Server. 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à attivo-passivo perché il database principale supporta l'accesso in scrittura.
In caso di failover, una replica secondaria diventa la nuova replica principale. Poiché un gruppo di disponibilità include istanze SQL Server autonome, 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 quale SQL Server le istanze gestiscono il database principale o le repliche secondarie in qualsiasi in un determinato momento. I listener richiedono che i client utilizzino una versione .NET minima di 3.5 un aggiornamento o una versione 4.0 o successiva, come descritto Continuità aziendale e ripristino del database - SQL Server.
I gruppi di disponibilità si basano sui livelli di astrazione sottostanti per fornire funzionalità. I gruppi di disponibilità vengono eseguiti in un cluster di failover di Windows Server (WSFC) come descritto in Cluster di failover di Windows Server con SQL Server. Tutti i nodi che eseguono istanze SQL Server devono far parte dello stesso WSFC.
Le transazioni vengono inviate dal database principale a tutte le repliche secondarie. Esistono due modalità di invio per inviare le transazioni: sincrona e asincrona. Puoi configurare in modo indipendente ogni replica in modo che utilizzi una o l'altra modalità. Nel la modalità di invio sincrona, la transazione solo sul database primario va a buon fine su tutte le repliche secondarie collegate in modo sincrono. Nella modalità asincrona, la transazione sul database principale può avere esito positivo anche se la transazione non è applicata a tutte le repliche secondarie.
La scelta della modalità di invio influenza i possibili RTO, RPO e lo standby . Ad esempio, se le transazioni vengono inviate a tutte le repliche in modalità sincrona, tutte le repliche si trovano nello stesso stato. L'RPO più impegnativo (più recente della transazione) viene completata 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 tutte le repliche sono sempre completamente sincronizzate.
La figura seguente mostra un gruppo di disponibilità sempre attivo in una singola regione.
Il gruppo di disponibilità è rappresentato da un rettangolo che comprende più zone. Questo è a solo scopo illustrativo per indicare che tutti i database appartengono gruppo di disponibilità. Il gruppo di disponibilità non è una risorsa cloud e, come tale, non implementato in un nodo o in qualsiasi altro tipo di risorsa.
Istanza cluster di failover sempre attiva
Per evitare errori dei nodi, puoi utilizzare 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 la gestione di un database da un cluster di failover. Un nodo del cluster è attivo mentre gli altri nodi non eseguono SQL Server di Compute Engine. 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). Questo processo di avvio automatico di SQL Server l'istanza offre funzionalità ad alta disponibilità.
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, job dell'agente SQL Server o collegati vengono spostati su un'altra istanza.
I nodi dei cluster FCI possono essere configurati in zone Google Cloud diverse. Questo architettura non solo offre alta disponibilità in caso di errore dei nodi, ma anche errori nelle zone. 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 Il server utilizza la funzionalità Storage Space Direct (S2D) per gestire i database su dischi dei nodi dedicati. Per ulteriori informazioni, vedi Configurazione delle istanze cluster di failover di 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. a scopo puramente illustrativo per indicare che tutti i nodi appartengono la stessa FCI. 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à. R Il gruppo di disponibilità distribuita include due gruppi di disponibilità, uno dei quali è nel ruolo del gruppo di disponibilità principale e uno nel ruolo del gruppo secondario gruppo di disponibilità. 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. L'inoltro riceve transazioni dal gruppo di disponibilità principale e le inoltra al dei database secondari del gruppo di disponibilità secondario. Un failover dal gruppo di disponibilità principale al gruppo di disponibilità secondario, database primario del nuovo gruppo di disponibilità principale accessibile in scrittura operations.
I gruppi di disponibilità primario e secondario non devono essere necessariamente nello stesso e non devono essere necessariamente sullo stesso sistema operativo. Tuttavia, ogni per il gruppo di disponibilità deve essere installato un listener. L'oggetto distribuito non ha un listener. Disponibilità distribuita non richiedono che i due gruppi di disponibilità siano nello stesso WSFC. Tutti la funzionalità richiesta per far funzionare i gruppi di disponibilità distribuita all'interno della funzionalità di SQL Server e non richiede dei componenti sottostanti.
Un gruppo di disponibilità distribuita comprende 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 altro è una topologia ad albero in cui il gruppo di disponibilità principale fa parte 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 su Windows e un secondo gruppo di disponibilità corrispondente Linux, in cui entrambi i gruppi di disponibilità formano un gruppo di disponibilità distribuita.
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à distribuita è rappresentato come un rettangolo. a scopo puramente illustrativo per indicare che I gruppi di disponibilità appartengono tutti allo stesso gruppo di disponibilità distribuita. R come un gruppo di disponibilità, non è un gruppo risorsa e, come tale, non implementata in un nodo o in qualsiasi altro tipo di risorsa.
Per ulteriori informazioni, vedi Gruppi di disponibilità distribuita.
Spedizione log
La spedizione dei log delle transazioni è una funzionalità di disponibilità di SQL Server quando RTO e RPO non sono così rigidi (RTO basso e/o RPO recente) perché la discrepanza di stato tra un database primario e il suo database secondario è significativamente più grande. La discrepanza è maggiore in termini di stato poiché un file di log delle transazioni contiene molte modifiche allo stato. La discrepanza è maggiore anche in termini di tempo di attesa dato che i file di log delle transazioni vengono trasportati in modo asincrono e completamente applicati 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 principale, sono in modalità hot standby. 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. È necessario configurare la spedizione dei log per ogni database singolarmente. Se un gruppo di disponibilità gestisce più di un database, come è necessario configurare molti processi di spedizione dei log.
In caso di errore, il processo di ripristino di emergenza deve essere avviato manualmente perché non è previsto un supporto automatico. Inoltre, l'accesso client non estratto dal database principale e da quelli 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 separate indipendentemente dalle istanze SQL Server, ad esempio gli indirizzi IP mobili come descritto Best practice per gli indirizzi IP mobili.
Poiché la spedizione dei log è in parte un processo manuale, puoi ritardare l'applicazione della copia 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 finché 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é viene risolto l'errore di modifica dei dati. In seguito, la normale elaborazione può riprendi.
Come nel caso dei gruppi di disponibilità distribuiti, puoi utilizzare la spedizione dei log per soluzioni multipiattaforma in cui, ad esempio, il database principale è in esecuzione su Linux, mentre i database secondari si trovano 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, di cui uno in esecuzione su Linux e su Windows.
Per saperne di più sulla spedizione dei log di SQL Server, leggi Informazioni sulla spedizione dei log (SQL Server).
Combinazione delle funzionalità di disponibilità di SQL Server
Puoi eseguire il deployment delle funzionalità di disponibilità di SQL Server in diverse combinazioni. Per nel caso d'uso precedente, la spedizione dei log è stata usata con gruppi di disponibilità installati su diversi sistemi operativi.
Di seguito è riportato un elenco di possibili combinazioni di disponibilità di SQL Server caratteristiche:
- 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.
- Usa un gruppo di disponibilità distribuita tra le regioni vicine e registra delle spedizioni in regioni di diversi continenti.
Queste sono solo alcune delle possibili combinazioni di disponibilità di SQL Server le funzionalità di machine learning.
La flessibilità fornita dalle funzionalità di disponibilità di SQL Server consente di l'ottimizzazione di una strategia di ripristino di emergenza in base ai requisiti dichiarati.
Replica SQL Server
La replica di SQL Server non è generalmente considerata una disponibilità funzione, ma questa sezione descrive brevemente come questa funzione può essere utilizzata ripristino di emergenza.
La funzionalità di replica supporta la creazione e la manutenzione delle repliche o Microsoft SQL Server. Diversi tipi di agenti SQL Server collaborano per acquisire le modifiche, per trasmettere le modifiche acquisite e applicarle alle repliche. Questo è asincrono e di solito le repliche sono in ritardo rispetto alla replica del database 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 sapete che i database assumono ruoli diversi nel contesto dei disastri e il ripristino di emergenza. Di conseguenza, la replica non ha operazioni che supportano il disastro di recupero, ad esempio le modifiche ai 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 dei file di backup
La spedizione dei 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 in 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 della spedizione dei log.
Per ulteriori informazioni, consulta la sezione su Esempio: strategia RE di backup e ripristino.
Le istruzioni dettagliate per il backup e il ripristino di SQL Server sono illustrate nell' la seguente soluzione: Utilizzo dei backup di Microsoft SQL Server per il recupero point-in-time su Compute Engine.
Rispetto all'approccio di replica discusso nella sezione precedente, la spedizione di file di replica e di backup ha in comune che il ripristino di emergenza è implementato all'esterno e separato dal set di funzionalità di SQL Server. Per quanto riguarda la spedizione delle modifiche acquisite, la replica di SQL Server in quanto implementa questa parte automaticamente per mezzo di SQL Server, Agenti.
Nota sull'interazione tra il ciclo di vita del database e quello dell'app
Un failover del database non è completamente separato e indipendente dalle app che accedono del database. In linea di principio, esistono due scenari di errore.
Innanzitutto, l'app rimane operativa durante il failover del database. Da data e ora dell'indisponibilità del database primario fino al punto del nuovo database primario essendo operative, le app non possono accedere al database. Esistente le connessioni non vanno a buon fine e non ne vengono stabilite di nuove. Durante questo periodo, non sia in grado di servire i propri clienti, almeno nella misura in cui la funzionalità richiede l'accesso al database. Le app devono riconoscere quando viene inviata un database in modo che possa riprendere la normale elaborazione.
Le app potrebbero avere stato al di fuori del database, ad esempio nella memoria principale . L'app fa in modo che la cache sia coerente (sincronizzata) con il nuovo e il database principale. Se le transazioni non si sono verificate durante il failover, 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 diventa non disponibile. Ad esempio, se una regione passa alla modalità offline, di applicazioni in esecuzione in quella regione sarà non disponibile quanto nella stessa regione. In questo caso, è necessario recuperare l'app non solo il sistema di database primario. 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. Backup, archiviazione e ripristino nel contesto di Google Cloud è discusso Utilizzo dei backup di Microsoft SQL Server per il recupero point-in-time su Compute Engine.
La sezione seguente illustra come utilizzare i backup come possibile meccanismo di implementazione del ripristino di emergenza del database. In questo scenario, devi copiare eseguire il backup dei file nella posizione del database secondario in modo che possono essere ripristinati. 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
L'alta disponibilità e il ripristino di emergenza hanno in comune il fatto offrono soluzioni per l'indisponibilità dei 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. In caso di errore di un nodo che esegue un'istanza SQL Server, viene reso disponibile un nuovo nodo eseguire una nuova istanza SQL Server (vedi la discussione nella Istanza cluster di failover sempre attiva).
Il ripristino di emergenza interessa almeno due regioni. Risolve i casi in cui l'intera regione diventa non 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 il gruppo di disponibilità può contenere istanze cluster di failover per la disponibilità del servizio.
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 diverse Requisiti RPO e RTO. L'elenco non è esaustivo.
RE e alta disponibilità intraregionali
Questo deployment è una variante di un gruppo di disponibilità contenente FCI, all'interno di una regione composta da tre zone. Le zone sono considerate il singolo punto 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 possano non funzionare senza richiedere un ripristino di emergenza e il processo di sviluppo.
Il seguente diagramma mostra questa configurazione.
Gli FCI coprono tutte le zone e ogni FCI ha un'istanza SQL Server in esecuzione che accede nel 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 failover di Windows Server Cluster e copre due regioni. Le regioni sono considerate un single point of failure dominio.
Il seguente diagramma illustra questa configurazione.
Per risolvere potenziali problemi di latenza, puoi configurare le repliche all'interno della regione R1 per utilizzare la propagazione delle transazioni sincrone, mentre le repliche nella regione R2 sono configurate per utilizzare la propagazione delle transazioni asincrona.
RE tra regioni: trasferimento file di backup
Questo scenario utilizza il trasferimento di file di backup. 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. La il gruppo di disponibilità AG1 è il gruppo di disponibilità principale e la disponibilità Il gruppo AG2 è il gruppo di disponibilità secondario. Quando vengono creati i file di backup disponibili per il gruppo di disponibilità secondario, vengono applicate lì. Questo di questo scenario è discusso più in dettaglio nella sezione seguente, Esempio: strategia RE 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à che esegue un altro database o gruppo di disponibilità secondario può per eliminare la durata non protetta dopo un failover. Questa configurazione deve garantire che uno dei due database secondari rimane un database secondario e riassegnate 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 di RE
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 la terminologia e i metodi di comunicazione.
Decisione di avviare 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 causa della mancata disponibilità del database principale.
Se il processo di ripristino di emergenza richiede più tempo del previsto indisponibilità del database primario, il failover sarebbe negativo. 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 conoscere tutte le fasi che vengono e di tutti i problemi imprevisti che si presentano. L'autorità decisionale guida di failover e gli stakeholder sono responsabili del supporto l'autorità decisionale.
Devi conservare le statistiche per l'analisi post-mortem e il processo di failover miglioramento; 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, dal momento in cui il nuovo database principale è disponibile e operativo finché non viene configurato un nuovo database secondario, nessun RE protezione esistente. 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 delle app al nuovo database principale viene viene ritardata fino a quando il nuovo database secondario non è in esecuzione. Non appena cambia del database principale, il database primario è disponibile app. Sebbene questo approccio eviti i casi in cui le app non siano protette da RE, ritarda il completamento del processo di ripristino di emergenza.
Evitare situazioni di scomposizione
È importante che le app non possano accedere a un database principale e a un database contemporaneamente, eseguendo operazioni DML. In questa situazione, si verificano incoerenze nei casi in cui sia il database principale sia quello secondario non essere d'accordo sui valori dei dati dello stesso elemento di dati (cervello divisa). Questa architettura è particolarmente importante se il database primario non è disponibile mentre è in esecuzione e può ricevere operazioni di scrittura. Se l'indisponibilità è causata da un partizionamento della rete intermittente, il partizionamento può interrompersi in qualsiasi momento e un'app potrebbe avere di nuovo accesso. Se di failover è in corso, quindi le modifiche ai precedenti processi di failover il database potrebbe andare perso o alcune app inizieranno a funzionare sul nuovo database principale mentre altri 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 post mortem e report
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 implementi le normative i tuoi requisiti.
Test e verifica RE
Poiché il ripristino di emergenza non fa parte delle normali operazioni quotidiane, di una soluzione deve essere testata regolarmente per verificarne il corretto funzionamento quando necessario.
La frequenza dei test dipende dai requisiti operativi e varia per database, app e azienda. Inoltre, le modifiche all'ambiente, come in quanto la configurazione di rete e gli aggiornamenti dei componenti dell'infrastruttura attivare un test di ripristino di emergenza se vengono apportate modifiche ai sistemi soluzione di ripristino di emergenza prescelta. Qualsiasi modifica potrebbe causare il disastro di ripristino di emergenza se non riesce o potrebbe richiedere la modifica del e il processo di sviluppo.
Puoi eseguire il test manualmente avviando il processo di cambio o automaticamente un approccio all'ingegneria del caos come descritto in Ingegneria del caos. Con i test manuali, puoi ridurre al minimo l'impatto sull'attività in caso di è previsto un tempo di inattività.
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: misurare il tempo di recupero effettivo e confrontarlo con l'RTO.
- Punto di ripristino effettivo: osservare il punto di recupero effettivo e confrontarlo con l'RPO.
- Time to failure Detection: il tempo impiegato per gli DBA o per le operazioni per comprendere la necessità del failover.
- Tempo di avvio del ripristino: il tempo necessario per avviare il failover processo dopo il rilevamento dell'errore.
- Affidabilità: quanto è stato seguito o quanto è stato seguito il processo di failover deviazioni dal progetto? Si sono verificati problemi imprevisti indagato, magari con un cambiamento nella strategia di ripristino?
In base alle statistiche raccolte, il processo di failover potrebbe dover essere modificati o migliorati per soddisfare meglio le aspettative di RPO e RTO.
Esempio: strategia RE 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 l'impegno richiesto per specificare una procedura di backup e ripristino per RE e discutere di aspetti invisibili in configurazioni più automatizzate. it si riferisce alla soluzione correlata, Utilizzo dei backup di Microsoft SQL Server per il recupero point-in-time su Compute Engine.
Caso d'uso
Un gruppo di disponibilità principale sempre attivo si trova e è operativo nella regione R1. Il gruppo di disponibilità Sempre attivo secondario viene aggiunto nella regione R2 per 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. Le copie di backup vengono applicati al gruppo di disponibilità Sempre attivo secondario nel momento in cui vengono utilizzati. Tutti i backup sono archiviati in un bucket Cloud Storage.
In questo esempio, dopo il completamento del failover è accettabile che il nuovo Il gruppo di disponibilità sempre attivo in R2 è attivo e non protetto per un periodo di tempo limitato finché non diventa operativo il nuovo gruppo di disponibilità Sempre attivo secondario in R1.
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, l'RPO è definito come una durata massima di 60 minuti, quindi un viene eseguito ogni 60 minuti.
L'RTO non è impostato esplicitamente su una durata di tempo, ma deve essere il più possibile: l'immediato è meglio. Il gruppo di disponibilità secondario deve essere configurato come hot standby. In caso di hot standby, tutti i backup vengono immediatamente per evitare che il failover venga ritardato durante l'applicazione dei backup.
Strategia di alto livello di RE
Le sezioni seguenti descrivono la strategia di RE. Si tratta di un titolo breve, i passaggi essenziali.
Impostazione iniziale
- Crea un gruppo di disponibilità Sempre attivo secondario nella regione R2.
- Impedisci alle app di accedere al gruppo di disponibilità secondario in modo da non suddividere il cervello può verificarsi per errore.
- Crea il bucket di file di backup B1 in Cloud Storage per contenere il backup completo iniziale del gruppo di disponibilità Sempre attivo in R1 e backup differenziali orari successivi del gruppo di disponibilità sempre attivo in R1. È necessario stabilire l'ordine corretto dei backup differenziali il processo di applicazione dei backup al gruppo di disponibilità secondario possano dedurre l'ordine corretto. Un approccio potrebbe essere una convenzione di denominazione consente di stabilire l'ordine cronologico corretto in base alla data e all'ora che fanno parte dei vari nomi di file.
Strategia di lancio
- Applica il backup completo al gruppo di disponibilità Sempre attivo secondario in regione R2.
- Quando i backup differenziali diventano disponibili, applicali immediatamente gruppo di disponibilità Sempre attivo 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 passaggio dall'istanza principale gruppo di disponibilità secondario al gruppo di disponibilità secondario. Almeno uno il backup incrementale deve essere disponibile durante il test.
Richiesta di failover o cambio
In R2, i passaggi essenziali sono i seguenti:
- Assicurati che il backup differenziale più recente sia stato applicato gruppo di disponibilità Sempre attivo secondario in R2.
- Designa R2 come nuovo gruppo di disponibilità Sempre attivo principale.
- Creare un nuovo bucket B2, eseguire un backup completo come riferimento 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 cambio, rimanendo comunque in grado di configurare il nuovo un gruppo di disponibilità secondario. Invece di un unico backup completo differenziali successivi, eseguire un backup completo ogni settimana e creare bucket settimanale che contiene il backup completo della settimana e tutte le successive di backup differenziali 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 utilizzi questo approccio settimanale, devi implementare una strategia di pulizia o di eliminazione definitiva per rimuovere i backup obsoleti.
Un altro miglioramento è basato sul fatto che la nuova disponibilità secondaria era il precedente 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 l'impegno e la quantità di tempo gruppo di disponibilità non è protetto.
Best practice per la produzione
Questa soluzione non specifica se le istanze SQL Server nella casella di controllo Sempre I gruppi di disponibilità sono istanze autonome o FCI. 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, è necessario implementare il monitoraggio per garantire che eventuali errori o viene rilevato un errore. 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à Always On di SQL Server.
- Deployment di un gruppo di disponibilità SQL Server 2016 Always On con più subnet su Compute Engine.
- Configurazione delle istanze cluster di failover di SQL Server.
- Esecuzione del clustering di failover di Windows Server.
- Come abilitare Cloud Logging, Cloud Monitoring ed Error Reporting per le app .NET
- Installazione dell'agente Cloud Monitoring.
- Esplora le architetture di riferimento, i diagrammi e le best practice su Google Cloud. Dai un'occhiata al nostro Centro architetture cloud.