20 cose da pianificare per un ripristino di emergenza IT

L'implementazione di una soluzione di ripristino di emergenza dipende da tre fattori:1) tempo 2) risorse 3) importo in dollari.

La maggior parte delle organizzazioni non pensa nemmeno al ripristino di emergenza quando l'infrastruttura IT e le applicazioni sono in esecuzione senza problemi. La maggior parte di loro pensa al DR solo quando si rompe qualcosa che ha creato un forte impatto negativo sull'azienda.

Se sei un amministratore di sistema o qualcuno che è responsabile del mantenimento dell'IT in funzione, dovresti lavorare costantemente sul ripristino di emergenza. Indipendentemente dal fatto che la tua azienda abbia assegnato tempo e budget o meno, puoi comunque lavorare su alcuni aspetti del DR.

Di seguito è riportato un elenco di vari elementi che potresti voler prendere in considerazione durante la pianificazione di un DR. Questo elenco non è in alcun modo completo, ma dovrebbe darti abbastanza idee per iniziare a utilizzare DR.

1. Centro dati principale resiliente. Prima di pianificare un data center remoto secondario, è necessario assicurarsi che tutti i componenti del data center principale siano altamente ridondanti. Il tuo obiettivo dovrebbe essere quello di progettare il tuo data center principale il più resiliente possibile in modo da poter riprendere rapidamente dalla maggior parte dei disastri (tranne i disastri naturali) senza dover mai utilizzare il data center remoto secondario. Ad esempio, per il database di produzione, disporre di un database di standby fisico in esecuzione sullo stesso data center, configurare schede NIC doppie e schede HBA su tutti i server di produzione, configurare più server Web con un sistema di bilanciamento del carico, collegare il server a due circuiti di alimentazione utilizzando il ridondante alimentazione sui server, ecc.
2. Centro dati secondario remoto. Se implementi un data center primario resiliente, il tuo obiettivo per l'utilizzo di un data center remoto ridondante è principalmente per disastri naturali come terremoti, incendi, inondazioni, ecc. Anche se questo potrebbe essere molto ovvio, vale la pena affermarlo, come ho visto poche aziende in questo modo, hanno sia il datacenter primario che quello secondario nella stessa città, il che vanifica lo scopo di DR. Se il tuo data center principale si trova in California, configura un data center secondario da qualche parte nella costa orientale.
3. Replica i componenti di produzione nel datacenter di ripristino di emergenza. Non è necessario replicare tutto l'hardware e le applicazioni dal data center primario a quello secondario. Un amministratore di sistema o qualsiasi tecnico può identificare rapidamente tutto l'hardware e il software critici che devono essere replicati nel sito di ripristino di emergenza, ma potrebbe essere necessario l'aiuto di altri dipartimenti per identificare le applicazioni critiche per l'azienda. È necessario mappare le funzioni aziendali critiche ai componenti dell'infrastruttura IT e assicurarsi che tutti questi componenti dell'infrastruttura, insieme alle applicazioni e ai dati, vengano replicati nel sito di ripristino di emergenza.
4. Piano di archiviazione. Se si dispone di un tipo di archiviazione SAN (o archiviazione NAS) che supporta l'applicazione critica nel DR primario, è necessario disporre anche di un archivio SAN (o archiviazione NAS) simile sul sito di DR. Per motivi di prestazioni, i server di produzione nel sito di ripristino di emergenza devono avere le stesse specifiche dei server di produzione nel sito principale. Tuttavia, per lo storage, se si dispone di uno storage SAN di fascia alta di un grande fornitore sul sito principale, prendere in considerazione l'implementazione di uno storage SAN di fascia alta simile da un piccolo fornitore, che potrebbe costare molto meno denaro per la stessa configurazione e prestazioni simili .
5. Replica i dati al sito DR su base continuativa. La sincronizzazione dei dati tra il data center primario e quello di emergenza è un aspetto critico di un'implementazione di successo del ripristino di emergenza. Dopo aver elencato tutte le applicazioni che devono essere replicate sul sito DR, devi capire come sincronizzare i dati tra questi due siti per tutte queste applicazioni. Ad esempio, è possibile replicare il database Oracle a livello di blocco utilizzando le tecnologie di replica fornite dai fornitori di storage oppure è possibile utilizzare datagurad per replicare i dati a livello di Oracle. Entrambi hanno i suoi pro e contro. Devi analizzarli attentamente e scegliere quello che si adatta al tuo budget e all'ambito del DR.
6. Replica i dati iniziali utilizzando il metodo manuale. Quando configuri il sito DR per la prima volta, devi decidere come eseguire la sincronizzazione iniziale dei dati. Ad esempio, se stai replicando un database di data warehouse di dimensioni enormi, non puoi copiare il backup iniziale del database sulla rete sul sito remoto, poiché potrebbe monopolizzare la larghezza di banda. È invece possibile eseguire un backup su nastro nel data center primario e utilizzarlo nel data center secondario per configurare il database iniziale. Una volta completata la configurazione iniziale, puoi implementare una qualche forma di sincronizzazione incrementale automatica tra i siti.
7. RTO sta per Recovery Time Objective. Lavorando con il team di gestione, si identifica l'RTO accettabile per l'azienda. Ad esempio, l'organizzazione può decidere che l'RTO accettabile è di 8 ore. vale a dire dopo un disastro, entro un massimo di 8 ore tutte le applicazioni critiche dovrebbero essere pienamente operative presso il sito DR. L'RTO ha un impatto diretto sull'importo in dollari speso per l'implementazione della soluzione DR. Ad esempio, un RTO di 1 ora potrebbe richiedere una soluzione DR molto sofisticata che è troppo costosa rispetto a quanto richiesto da un RTO di 24 ore.
8. RPO sta per Recovery Point Objective. Proprio come RTO, dovresti collaborare con la direzione per decidere un RPO accettabile per l'azienda. Ad esempio, l'organizzazione può decidere che l'RPO accettabile è di 2 ore. Ad esempio, dopo un disastro, quando si esegue il failover del servizio su DR secondario, 2 ore di perdita di dati sono accettabili per le aziende. Ad esempio, se l'emergenza si verifica alle 15:00, dopo aver ripristinato il sistema nel sito di ripristino di emergenza, conterrà i dati della produzione solo a partire dalle 13:00. Quindi, hai perso i dati dalle 13:00 alle 15:00. In parole povere, se il tuo RPO è di 2 ore, la tua azienda dovrebbe essere disposta a perdere 2 ore di dati durante un disastro.
9. Failover automatico o manuale? È necessario decidere se eseguire il failover automatico o manuale dopo un'emergenza. Nella maggior parte dei casi, un intervento manuale è accettabile, poiché non si desidera eseguire automaticamente il failover su un sito di ripristino di emergenza sulla base di un falso segnale. Tieni presente che una volta eseguito il failover, è necessario molto lavoro per tornare al data center principale.
10. Failover di rete. Ho visto piani di ripristino di emergenza che danno molta attenzione alla replica dei dati, ma meno attenzione agli aspetti di rete del ripristino di emergenza. Lavorando con il tuo team di rete, devi identificare tutte le infrastrutture di rete che devono essere replicate. Ad esempio, il failover del DNA per assicurarsi che l'URL di produzione punti al sito di ripristino di emergenza dopo il failover. Se hai stabilito connessioni VPN per i tuoi clienti, identifica come eseguire il failover delle connessioni VPN. Quando crei/modifichi le regole del firewall (o qualsiasi altra cosa relativa alla sicurezza) nel data center principale, devi identificare in che modo tali politiche di sicurezza possono essere replicate nel sito di ripristino di emergenza su base continuativa.
11. Impostazione manuale remota. È necessario disporre di un piano appropriato per l'accesso al data center remoto per il debug di eventuali problemi. È possibile configurare KVM nel sito DR, per accedere alla console dell'hardware che si trova nel sito DR dal proprio ufficio. Oppure, devi pianificare una qualche forma di servizio manuale remoto manuale, in cui qualcuno può recarsi fisicamente al sito di DR ed eseguire le tue istruzioni.
12. Test DR annuali. Diverse organizzazioni spendono molto tempo e denaro nella creazione di un sito di DR, solo per capire che non funziona davvero come previsto quando si trovano in una vera situazione di DR. Una volta all'anno, dovresti convalidare le tue attuali configurazioni DR per assicurarti che il sito DR funzioni correttamente e soddisfi l'obiettivo originale. Se tutto è configurato correttamente, dovresti essere in grado di eseguire manualmente il failover delle tue applicazioni critiche dal sito principale al sito di ripristino di emergenza e lasciarlo funzionare lì per alcuni giorni. Questo ti aiuta anche a vedere come il sito DR gestisce il caricamento in tempo reale.
13. Sito di DR come piattaforma di controllo qualità. Invece di utilizzare il sito DR solo per situazioni di emergenza, puoi utilizzarli come piattaforma di controllo qualità per eseguire test delle prestazioni e del carico delle tue applicazioni. Questo potrebbe essere utile, poiché non è necessario investire in un'infrastruttura di test aggiuntiva nel data center principale. Quando adotterai questo approccio, sincronizzerai i dati dal sito principale al sito DR su base continuativa. Tuttavia, ogni volta che si esegue un test di carico, è necessario implementare qualche soluzione aggiuntiva in cui si esegue un checkpoint dello stato corrente del sito di ripristino di emergenza, si esegue il test del QA, quindi si torna immediatamente al checkpoint precedente e si continua a sincronizzare i dati del sito principale da lì.
14. Piano di risposta DR. Dopo aver implementato il sito DR, devi avere un piano DR chiaro su come tu e il tuo team risponderete in caso di un vero disastro. Collabora con i vari dipartimenti della tua organizzazione e identifica le risorse chiave che faranno parte del team di risposta DR e identifica il loro ruolo specifico nel piano di risposta DR. Il piano di risposta DR è una semplice istruzione passo passo su cosa è necessario fare quando c'è un DR, chi eseguirà tali attività e in quale sequenza verranno eseguite tali attività.
15. Non hai un sito DR? Molte organizzazioni non hanno un sito DR. Se stai lavorando per uno di loro e sei responsabile delle applicazioni critiche e dell'infrastruttura IT, è tua responsabilità elaborare un piano di ripristino di emergenza ed educare il tuo top management sull'importanza di spendere tempo e denaro per il ripristino di emergenza e ottenere la loro approvazione. Vieni con tre diversi piani di DR:uno che costa $$$, uno che costa $ $, uno che costa $. Come spiegato in precedenza, il piano DR può variare in base a vari fattori e il costo è uno di questi. Dopo aver presentato il tuo piano DR dettagliato alla tua direzione, se ancora non lo approvano, almeno ti sentirai bene per aver dato il meglio di te per elaborare un buon piano DR.
16. Quando dichiarare un disastro? Devi identificarlo chiaramente in anticipo. Devi avere criteri scritti molto chiari su quando passerai al sito DR. vale a dire, quali criteri attivano i criteri di failover di ripristino di emergenza? Quando si avvia un DR? A che punto dichiari che è un DR, aggiungi inizia a lavorare per eseguire il failover sul sito DR? La risposta a queste domande dovrebbe essere chiaramente definita e rivista da ogni dipartimento della tua organizzazione e, infine, questi criteri dovrebbero essere approvati dal top management. Per alcuni, quando la produzione è inattiva, perché qualcuno ha eliminato qualcosa in produzione per errore potrebbe non attivare un DR. Per alcune organizzazioni, probabilmente è meglio ripristinare i dati dal backup sul sito principale stesso. Per le altre organizzazioni, le aziende non possono aspettare fino al ripristino dal backup e devono passare al sito di ripristino di emergenza.
17. Backup, backup e backup. I backup sono un fattore molto importante in un piano di ripristino di emergenza. Come accennato in precedenza, il tuo obiettivo dovrebbe essere quello di non utilizzare mai il sito DR, a meno che non si verifichi un vero disastro naturale. Quindi, una solida strategia di backup nel tuo sito principale è molto fondamentale. Dovresti eseguire il backup di tutte le tue applicazioni critiche. Quando esegui il backup del database, archivia il backup in quattro posizioni. I backup sono praticamente inutili se non li ripristini su un server di prova per verificare che funzionino su base continuativa.
18. Applicazione delle patch. Quando si applicano patch del sistema operativo, si aggiorna il firmware o si esegue qualsiasi tipo di gestione della configurazione all'hardware nel sito principale, è necessario disporre di una strategia per eseguire tali operazioni nel sito di ripristino di emergenza su base continuativa. Non vuoi trovarti in una situazione in cui la configurazione del sistema operativo sul tuo sito principale è diversa da quella del sito di ripristino di emergenza.
19. Il successo del DR dipende da molti fattori. Benedizione del top management, adeguata allocazione del budget, coinvolgimento di tutte le divisioni aziendali, solido piano DR, solide risorse tecniche, implementazione DR completamente testata. Ancora più importante, un ambito DR ben definito e in linea con l'obiettivo aziendale è molto critico per un DR di successo.
20. Documentazione DR. Una corretta pianificazione del DR richiede la definizione di molti processi. Tutti questi processi dovrebbero essere adeguatamente documentati. Ad esempio, un documento che spiega il processo di escalation quando si verifica un DR. Una documentazione tecnica che spiega cosa è necessario fare per eseguire il failover sul sito di ripristino di emergenza. Un documento di comunicazione che elenca tutti i membri del team coinvolti nel DR, di cosa sono responsabili e come possono essere contattati durante il DR. Un documento per il team di assistenza clienti, che sa cosa deve essere comunicato al cliente e come raggiungere i clienti durante un disastro. Un documento di test di ripristino di emergenza che elenca tutto ciò che un team di controllo qualità deve testare dopo che il sito di ripristino di emergenza è attivo, ecc.

Abbiamo solo graffiato la superficie del Disaster Recovery. C'è molto di più rispetto agli elementi di cui sopra. Se sei un amministratore di sistema o qualcuno che è responsabile delle tue applicazioni IT e della tua infrastruttura e se non disponi di un piano di ripristino di emergenza, consideralo come promemoria per avviare la tua strategia di ripristino di emergenza.