La pianificazione e l'implementazione di un piano di disponibilità elevata e ripristino di emergenza che soddisfi tutti i contratti di servizio è un'impresa non banale e richiede una comprensione molto chiara dei punti di forza e di debolezza nativi di SQL Server. Quando si confrontano i requisiti con una combinazione di funzionalità, alcuni dei dettagli critici potrebbero essere ignorati e in questo post illustrerò alcune distorsioni comuni e ipotesi sbagliate che possono insinuarsi in una soluzione, facendoci infine perdere il bersaglio sui nostri obiettivi di punto di ripristino e tempo di ripristino. Alcuni degli esempi di distorsioni o auto-illusioni che descrivo in dettaglio qui possono essere generalizzati a diverse caratteristiche e alcuni sono specifici per le caratteristiche.
"Abbiamo testato il nostro piano di ripristino di emergenza quando abbiamo lanciato il nostro progetto per la prima volta e sappiamo che funzionerà"
Ho lavorato con clienti che hanno effettivamente ottenuto il loro approccio di ripristino di emergenza "giusto" - una volta. Ma una volta che tutti si sono sentiti sicuri dell'efficacia della soluzione, non sono stati eseguiti altri esercizi di ripristino di emergenza. Naturalmente, nel frattempo il livello dati e l'applicazione continuano a cambiare nel tempo. Tali modifiche introducono nuovi oggetti e processi critici per l'applicazione. E anche se tutto rimane statico dopo il lancio, devi comunque tenere conto del ricambio del personale e dei vari set di abilità. Il personale di oggi può eseguire con successo un esercizio di ripristino di emergenza? E anche il miglior personale ha bisogno di pratica continua.
"Non avremo alcuna perdita di dati perché stiamo utilizzando il mirroring sincrono del database"
Supponiamo che tu stia utilizzando il mirroring sincrono del database tra due istanze di SQL Server, con ciascuna istanza in un data center separato. In questo esempio, si supponga che la latenza della transazione sia accettabile nonostante si tratti di una sessione di mirroring del database sincrona con poche miglia tra i data center. Non hai un testimone nel mix perché vuoi controllare manualmente il failover del mirroring del database.
Ora supponiamo che il tuo data center per il ripristino di emergenza scompaia, ma il tuo data center principale è ancora disponibile. Il database principale è disconnesso dal database mirror, ma accetta ancora connessioni e modifiche ai dati. Che dire del requisito "nessuna perdita di dati" ora? Se le transazioni sono state eseguite contro il principale disconnesso per un'altra ora, qual è il tuo piano se anche il data center principale viene perso?
"Il nostro imprenditore afferma che possiamo perdere fino a 12 ore di dati"
È importante porre alcune domande più di una volta ea più di un individuo in un'organizzazione. Se qualcuno ti dice che "12 ore di perdita di dati sono accettabili", chiedi loro di nuovo o chiedi loro quale sarebbe la conseguenza di quella perdita di dati. Chiedi anche ad altre persone. Potrebbero darti un requisito molto più severo. Ho scoperto che gli obiettivi del punto di ripristino richiedono alcuni negoziati e più di alcune discussioni ponderate e deliberate.
"Utilizziamo [mirroring del database o gruppi di disponibilità] e quindi siamo coperti per ciò di cui abbiamo bisogno in caso di emergenza"
Il mirroring del database e i gruppi di disponibilità possono sicuramente essere utilizzati per proteggerti a livello di database, ma per quanto riguarda tutto il resto? E i tuoi accessi? Pacchetti SSIS? Lavori? Database dei modelli di ripristino non COMPLETI? Server collegati?
"Stiamo utilizzando la funzione XYZ di SQL Server, quindi non perderemo alcuna transazione in corso"
No scusa. Sebbene alcune funzionalità consentano un reindirizzamento trasparente, ciò non equivale a mantenere e mantenere le transazioni aperte al momento del failover. Nessuna funzionalità di SQL Server offre questa funzionalità oggi.
"Il team che supporta il livello dati per questa applicazione odia la funzionalità XYZ di SQL Server, ma stiamo andando avanti perché è ciò che ci è stato consigliato da un consulente esterno"
Anche se sarebbe bello se le persone non sviluppassero pregiudizi specifici sulle funzionalità di SQL Server, spesso non è così. Se provi a imporre soluzioni a uno staff che non è a bordo con loro, corri il rischio di un fallimento predeterminato. Come parte degli esercizi HA/DR con cui ho aiutato in passato, sono sempre interessato a conoscere le esperienze passate delle persone con caratteristiche specifiche. Ad esempio, alcune aziende sfruttano molto bene centinaia di istanze del cluster di failover, mentre altre le evitano a causa di esperienze negative delle versioni precedenti. Quando si pianifica una soluzione, non si può ignorare la cronologia o le predisposizioni del personale che sarà in ultima analisi responsabile dell'implementazione e del supporto della soluzione consigliata.
"In qualità di DBA, decido quale tecnologia HA/DR utilizzare per il livello dati, quindi utilizzeremo i gruppi di disponibilità in futuro"
Un amministratore di database potrebbe potenzialmente impostare il mirroring del database con un coinvolgimento minimo o nullo con altri team. Ora con i gruppi di disponibilità, anche se un amministratore di database potrebbe fare tutto da solo, potrebbe non essere saggio farlo. Dopotutto, se stai distribuendo gruppi di disponibilità per scopi di ripristino di emergenza, vorrai che tutte le persone coinvolte in un'operazione di ripristino di emergenza siano a conoscenza della tua soluzione e dei requisiti necessari per tornare online e ripristinare i dati con successo. Con i gruppi di disponibilità dovrai pensare al cluster di failover di Windows Server, alle configurazioni del quorum, ai voti dei nodi, al listener del gruppo di disponibilità e altro ancora. Se avrai bisogno di altre persone per facilitare una soluzione, assicurati che siano coinvolte nella raccomandazione iniziale.
"Utilizziamo i gruppi di disponibilità in modo da poter disporre della disponibilità di sola lettura in caso di interruzione della nostra replica di lettura e scrittura"
Questo è solo un esempio di uno scenario "e se". Con qualsiasi implementazione di funzionalità, ti consigliamo di immaginare i vari modi in cui può verificarsi un errore e quindi assicurati di testarlo per assicurarti che i tuoi requisiti siano ancora soddisfatti. Ad esempio, se ritieni che le repliche di sola lettura asincrone del gruppo di disponibilità di SQL Server 2012 saranno disponibili quando la replica di lettura e scrittura non è disponibile, rimarrai spiacevolmente sorpreso di vedere il Unable to access database 'XYZ' because its replica role is RESOLVING which does not allow connections messaggio in produzione.
"Abbiamo testato la funzionalità XYZ di SQL Server e il failover è stato rapido, quindi abbiamo stabilito che possiamo raggiungere facilmente i nostri obiettivi di tempo di ripristino"
Supponiamo che tu decida di utilizzare il mirroring del database per la disponibilità elevata a livello di database utente. Vuoi un failover rapido (misurato in secondi) e durante il test vedrai effettivamente un failover rapido. Ma era un test realistico? Stavi spingendo un carico di lavoro significativo? Nell'esempio del mirroring del database, la parte più lunga dell'operazione di failover può riguardare le operazioni di ripristino. Se non stai guidando carichi di lavoro realistici, non puoi davvero dire che il tuo failover sarà effettivamente "veloce".
"Se abbiamo un disastro e dobbiamo recuperare e riconciliare i dati, lo scopriremo quando sarà il momento"
Questa è dura. Supponiamo che tu abbia un disastro e devi rendere operativo il tuo data center secondario. Decidi di forzare il servizio per i database più critici nel data center secondario e ora hai una divisione nella derivazione delle modifiche dei dati (alcune righe non riconciliate nel data center primario e ora nuove modifiche nel data center secondario). Alla fine il tuo data center principale viene portato online, ma ora hai i dati che devono essere recuperati e riconciliati prima di poter ristabilire la soluzione HA/DR complessiva. Cosa fai? Cosa sai fare? Questa discussione è raramente facile da avere e può dipendere da diversi fattori come i pacchetti software che hai acquistato, la complessità del livello dati e gli strumenti di convergenza dei dati a tua disposizione. In effetti, la discussione di solito è così difficile che le persone non ce l'hanno affatto. Ma se i dati sono sufficientemente critici da consentire la creazione di un data center secondario, una parte fondamentale della discussione dovrebbe includere il modo migliore per salvare i dati e riconciliarli dopo che si è verificato un disastro.
Riepilogo
Questo articolo includeva solo alcuni esempi di come possiamo illuderci di pensare che una soluzione soddisfi pienamente i loro requisiti. Sebbene sia la natura umana a farlo, quando si tratta di perdita di dati e continuità aziendale, il nostro lavoro dipenderà dal fatto che saremo più aggressivi nel testare le nostre convinzioni e ipotesi.
