Pianificazione e progettazione di un piano che non è pronto per la produzione

La capacità dell'infrastruttura di DR deve essere in grado di gestire i carichi di lavoro di produzione, a meno che il piano non preveda diversamente. L'implementazione della DR con risorse che non corrispondono all'ambiente di produzione può sembrare interessante dal punto di vista dei costi, ma può rendere gli effetti di un disastro molto più gravi.

Durante la pianificazione e l'implementazione del vostro ambiente di disaster recovery, considerate i suoi requisiti di resilienza. Non cercate di tagliare i costi riducendo i requisiti di alta disponibilità dell'implementazione DR. In caso di disastro, i carichi di lavoro di produzione hanno bisogno di un ambiente resiliente. I servizi nel cloud sono scalabili, quindi è possibile aggiungere capacità in un secondo momento, ma l'aumento della domanda regionale causato da un disastro può causare carenze di capacità a breve termine.

Dimenticare i singoli punti di errore non tecnici

I single-points-of-failure (SPOF) possono trovarsi ovunque in una soluzione, non solo nella tecnologia. La vostra soluzione potrebbe dipendere da persone, venditori, fornitori e altre dipendenze esterne. Identificate chiaramente i vostri SPOF e riducete le vostre dipendenze. Preparatevi a scoprire gli SPOF durante le prime sessioni del test di disaster recovery.

Tra gli SPOF, il rischio del fornitore è una condizione da considerare nel vostro piano di DR. Quando si hanno sia la produzione che la DR presso lo stesso fornitore, le condizioni di rischio aumentano e devono essere considerate con attenzione.

Avere solo un piano A

Le catastrofi possono assumere molte forme, per cui la pianificazione per uno specifico scenario di disastro vi lascia vulnerabili ad altri. Nel concepire il piano di DR, considerate diversi scenari di disastro e dimostrate come il piano sia flessibile.

Testare male il piano

Una soluzione DR non testata aumenta le probabilità di incontrare un ostacolo quando il successo è più critico. I test sono essenziali per convalidare una soluzione funzionante. Anche le condizioni da testare sono importanti e richiedono la creazione di diversi scenari di test.

L'esecuzione di un test di DR con una chiusura pianificata delle operazioni in una sede e un riavvio ben organizzato nell'altra vi aiuta a garantire che il test di DR funzioni. Tuttavia, un semplice spegnimento completo non è sempre possibile in caso di vera emergenza.

Progettate i vostri test in modo da imitare il più possibile le potenziali condizioni di emergenza, simulando una "condizione di disastro mobile", in cui il carico di lavoro viene progressivamente influenzato dall'emergenza. L'impatto progressivo mette alla prova la resilienza della soluzione e fornisce indicazioni sulla capacità di resistere alle condizioni di stress.

Alta disponibilità

Alta disponibilità non equivale a disaster recovery. IBM Cloud consiglia ai clienti di verificare che le loro implementazioni siano altamente disponibili, sfruttando le Regioni Multizona (MZR) di IBM Cloud. Ogni MZR ha un minimo di tre zone, che sono altamente interconnesse, ma con data center operativamente separati. Spesso i problemi e le interruzioni riguardano solo una singola zona, non l'intera regione. La distribuzione predefinita dei carichi di lavoro in tutte le zone di un MZR può ridurre i tempi di inattività e la necessità di chiamare un disaster. Il failover a una seconda regione può essere un processo importante, così come il failover al contrario, quindi è necessario adottare tutte le misure possibili per evitare di doverlo fare. Tuttavia, gli MZR non prevengono disastri come il danneggiamento dei dati o danni dolosi.

Regolamentazione e conformità

Alcuni carichi di lavoro e dati sono soggetti a rigide normative di settore e a standard di conformità, che possono influire sul luogo fisico in cui possono essere eseguiti o archiviati. Quando si sceglie una sede per il disaster recovery, verificare che la regione scelta soddisfi tutte le normative e le conformità necessarie. Anche le sedi in cui si sceglie di replicare i dati devono essere verificate.

I bucket interregionali Object Storage offrono un modo per replicare i dati in diverse regioni, ma vanno usati con cautela se i dati sono soggetti a restrizioni territoriali. Verificate che i vostri dati non vengano trasferiti in una regione di un Paese o territorio che violi le norme di conformità organizzativa o di settore.

Capacità nella regione di recupero dei disastri

Le catastrofi possono colpire molti clienti, che quindi mettono in atto i loro piani di disaster recovery. La domanda aggiuntiva potrebbe mettere a dura prova la capacità di una o più delle regioni più vicine a quella fallita. Ciò potrebbe comportare una carenza di risorse disponibili. Per esempio, se us-south si guasta, è probabile che molti clienti scelgano di ripristinare prima la regione us-east. Se eu-gb fallisce, si prevede che una maggiore domanda ricada su eu-de.

In caso di domanda elevata causata da un disastro, l'infrastruttura di prima scelta potrebbe non essere disponibile per il provisioning nella regione di ripristino. Questo include i profili VPC VSI più diffusi. Tenete conto di diverse architetture per la vostra applicazione, che possono tenere conto di situazioni in cui è necessario un profilo VSI alternativo. Se l'applicazione non può tollerare l'uso di un'infrastruttura alternativa, considerate la possibilità di costruire o riservare la capacità necessaria nella regione di disaster recovery prescelta in previsione di un disastro, o di considerare altre sedi più lontane per evitare problemi di capacità.

Verificare che i backup possano essere ripristinati nella regione scelta. Ad esempio, i database non possono essere ripristinati in regioni che superano i confini di conformità. Come best practice, assicuratevi di testare le tempistiche di ripristino dei dati e di tenere conto del fatto che i tempi potrebbero allungarsi nel caso di un grave disastro che colpisca un'intera regione, dato che molti clienti cercheranno di ripristinare i dati contemporaneamente.

Connettività

I servizi di rete possono richiedere un certo tempo per il provisioning e la configurazione, in quanto possono richiedere attività di terze parti o l'installazione di ulteriori infrastrutture fisiche. Nel creare un piano di DR, considerate i tempi di attesa per tali servizi. È ottimale fornire questi servizi in anticipo:

• Direct Link, Transit Gateway Locale e Transit Gateway Globale
• Bordo VPC
• Gateway VPN e connessioni
• DNS privato con configurazione VPC di DNS Hub e Spoke
• VPE per i servizi condivisi
• Regole di restrizione basate sul contesto
• Bilanciatore di carico globale su DNS privato
• CIS con LBaaS, Percorso privato VPE e PPNLB

Sfruttate l'architettura VPC landing zone l'architettura distribuibile e l'architettura di riferimento di FS Cloud per preparare la connettività in anticipo o durante un ripristino di emergenza.

Failover parziale o completo

Il cloud è composto da diversi servizi e le applicazioni possono fare affidamento su più componenti che lavorano insieme. I piani di disaster recovery in genere si preparano a guasti catastrofici a livello regionale e presuppongono la perdita di tutti i servizi della regione. Tuttavia, possono verificarsi interruzioni isolate del servizio senza che ciò influisca su altri servizi nella regione.

In questi casi, è fondamentale valutare se è necessario un failover completo su un'altra regione o se è necessario intervenire solo sul componente guasto.

Ad esempio, se un servizio di database subisce un guasto catastrofico, è necessario eseguire il fail over dell'intero carico di lavoro, compresi i servizi web? Oppure gli altri componenti possono passare facilmente a un database di riserva in lettura-replica in un'altra regione?

La facilità di gestione di questi scenari dipende da come è stato progettato e configurato il carico di lavoro. Evitate di codificare i nomi dei servizi e assicuratevi che la vostra architettura tenga conto di fattori come la latenza di rete per consentire transizioni fluide durante le interruzioni parziali.

Failback

Un'altra considerazione è la posizione di failback dopo che il polverone si è posato su un disastro. La procedura di failback è documentata nel piano di DR. Le considerazioni sul failback includono:

• Si verifica un failback o si continua a funzionare normalmente nella posizione di ripristino?
• Se il failback è obbligatorio, quando lo si tenta?
• Come funziona il failback per creare il minor numero possibile di interruzioni?

Il failback può essere complicato e dannoso quanto un disastro, quindi valutate se il failback è necessario o meno. Invece, i servizi possono continuare a funzionare nella seconda sede? Anche la tempistica del failback è importante. È necessario assicurarsi che le circostanze che hanno causato il disastro siano risolte e che il failback non causi interruzioni prolungate.

Indipendentemente dal fatto che si esegua o meno un failback, la disposizione DR deve essere ricreata o reimpostata.