Test ed esecuzione del failover

Un piano di ripristino di emergenza che non è mai stato testato è soltanto un'ipotesi. Il test failover consente di verificare che le VM si avviino correttamente, che le applicazioni si avviino e che la connettività di rete funzioni nell'area di destinazione, senza interrompere l'ambiente di origine o compromettere la replica in corso. Molte organizzazioni scoprono che i propri piani di ripristino di emergenza presentano lacune solo quando si verifica un'emergenza reale, cioè proprio nel momento in cui un piano non funzionante può causare i danni maggiori. I test failover regolari sono un requisito di conformità per la maggior parte dei framework normativi.

ASR supporta tre tipi di azioni di failover. Il test failover crea copie delle VM sottoposte a failover in una rete isolata (specificata dall'utente come VNet di destinazione), senza influire sulla replica o sull'ambiente di origine. Il planned failover viene utilizzato per migrazioni o attività di manutenzione pianificate: prima sincronizza le modifiche rimanenti, quindi arresta l'origine ed esegue il failover. L'unplanned failover (utilizzato durante un'emergenza reale) esegue immediatamente il failover dall'ultimo punto di ripristino disponibile, senza attendere una sincronizzazione finale.

Per eseguire un test failover nel portale: selezionate l'elemento protetto, fate clic su Test Failover, scegliete un punto di ripristino (l'ultimo coerente con l'arresto anomalo, l'ultimo coerente con l'applicazione oppure un momento specifico) e selezionate una rete virtuale di destinazione (in genere una VNet di test isolata dedicata). ASR avvia la VM nell'area di destinazione utilizzando i dischi replica. La VM di test viene visualizzata accanto alla replica, ma è completamente indipendente: l'ambiente di produzione non viene interessato. Al termine del test, fate clic su Cleanup test failover per eliminare le VM di test.

Durante il failover selezionate un punto di ripristino dalla finestra di conservazione di ASR. Le opzioni sono: Latest (lowest RPO): il punto di ripristino più recente e coerente con l'arresto anomalo, che riduce al minimo la perdita di dati. Latest processed: il punto elaborato più di recente, che potrebbe avere un ritardo di alcuni minuti. Latest app-consistent: il punto di ripristino più recente coerente con l'applicazione, che potrebbe essere meno recente ma garantisce un ripristino pulito dell'applicazione. Custom: un punto di ripristino specifico e meno recente, per eseguire il ripristino a uno stato noto e integro precedente a un incidente.

Un recovery plan raggruppa più VM protette e definisce la sequenza e la tempistica del loro failover. È possibile specificare quali VM devono essere avviate per prime (ad esempio, i server di database prima dei server applicazioni), aggiungere manual approval gates per mettere in pausa il failover e consentire la convalida da parte di un operatore e inserire Azure Automation runbooks per eseguire script prima e dopo il failover (ad esempio, aggiornare i record DNS, configurare i bilanciatori del carico o inviare notifiche). I piani di ripristino possono essere testati indipendentemente con un test failover.

Un test failover consente di misurare l'RTO (Recovery Time Objective) effettivo. Avviate un cronometro quando iniziate il failover e fermatelo quando l'applicazione è completamente operativa e accessibile agli utenti. In genere, il failover da Azure ad Azure per una singola VM viene completato in 15–30 minuti, ma le applicazioni multi-livello con dipendenze possono richiedere più tempo. Documentate tutti i passaggi che aggiungono tempi imprevisti (ad esempio, la propagazione DNS o l'avvio a regime dell'applicazione) e risolveteli prima del test successivo.

Dopo un planned failover (ad esempio, una migrazione verso una nuova area), eseguite Commit per finalizzare il failover. Il commit interrompe la replica dall'origine e contrassegna le VM di destinazione come nuove primarie. Dopo il commit, potete abilitare la re-protection per invertire la direzione della replica, rendendo l'area di origine precedente la nuova destinazione di ripristino di emergenza. In questo modo potete eseguire il failback verso l'area originale dopo la risoluzione dell'incidente.

Il failback è il processo di restituzione dei carichi di lavoro all'area originale dopo un'emergenza o una migrazione pianificata. I passaggi sono: eseguire la reprotezione delle VM sottoposte a failover (invertendo la replica per replicare dalla nuova primaria verso l'area originale), attendere il completamento della sincronizzazione iniziale e quindi eseguire un failover pianificato verso l'area originale. Il failback richiede che l'infrastruttura di origine originale sia ancora integra; se è stata distrutta, potrebbe essere necessario ricreare la landing zone prima di eseguire il failback.

Dopo un test failover dovete eseguire Cleanup test failover nel portale per eliminare le VM di test e i dischi associati. Senza la pulizia, le VM di test continuano a essere eseguite e a generare costi di calcolo. Il passaggio di pulizia reimposta inoltre lo stato del test failover dell'elemento protetto, consentendo di eseguire un altro test in futuro. Automatizzare la pulizia (ad esempio, pianificandola un'ora dopo l'avvio del test tramite un runbook di Automation) evita che le VM di test dimenticate rimangano in esecuzione per giorni.

Ogni test di ripristino di emergenza dovrebbe produrre un DR drill report che registri: la data e lo scenario testato, i punti di ripristino utilizzati, l'RTO e l'RPO raggiunti, i problemi rilevati e le azioni correttive intraprese. Questa documentazione soddisfa i requisiti degli auditor per framework come ISO 27001 e SOC 2, che impongono test regolari di ripristino di emergenza. Conservate i report delle esercitazioni in una posizione sicura, accessibile sia ai team IT sia ai team responsabili della continuità aziendale.

Il prezzo di Azure Site Recovery si applica per istanza protetta al mese e comprende sia il servizio di replica sia l'orchestrazione. Vengono inoltre addebitati lo spazio di archiviazione utilizzato dai dischi gestiti replica nell'area di destinazione e l'account di archiviazione della cache durante la replica. Il trasferimento dati in uscita tra aree di Azure per il traffico di replica viene addebitato alle normali tariffe di uscita (a differenza di Azure Backup, per il quale l'uscita tra aree associate è gratuita). Per la replica da ambienti locali ad Azure, le licenze Windows Server per le VM di Azure possono usufruire di Azure Hybrid Benefit per ridurre i costi.

Verificate la vostra comprensione dei concetti di Microsoft Azure Fundamentals (AZ-900) trattati in questa lezione.

In questa lezione avete appreso che il test failover convalida il piano di ripristino di emergenza in una rete isolata senza influire sull'ambiente di produzione; i recovery plans organizzano il failover di più VM con controlli manuali e passaggi di automazione tramite runbook; infine, il failback restituisce i carichi di lavoro all'area originale invertendo la direzione della replica dopo un'emergenza. Nella prossima lezione vedremo Azure CDN per accelerare la distribuzione globale dei contenuti.