Testare il DR senza impatto

Un piano di disaster recovery che non è mai stato testato è solo un'ipotesi. L'esperienza reale dimostra che i piani DR rivelano spesso lacune — deriva della configurazione, automazione mancante, runbook obsoleti o tempi di avvio più lunghi del previsto — che emergono solo in condizioni di test. I test DR regolari sono l'unico modo per avere la certezza che il piano funzionerà quando sarà più necessario.

Test Failover è una funzionalità integrata di Azure Site Recovery che consente di simulare un failover verso la regione secondaria senza interrompere l'ambiente di produzione. Durante un test di failover, ASR crea copie delle VM replicate in una rete virtuale isolata nella regione secondaria. Le VM di produzione continuano a funzionare normalmente nella regione primaria, quindi non vi è alcun rischio per gli utenti effettivi.

La VNet di test isolata non deve avere connettività con i sistemi di produzione. In questo modo si impedisce alle VM di test di scrivere accidentalmente nel database di produzione, inviare e-mail a clienti reali o avviare transazioni di pagamento. Crei una VNet dedicata per il test di failover, senza peering con le VNet di produzione e senza accesso a Internet, e la utilizzi esclusivamente per le esercitazioni DR.

Un test DR deve convalidare un insieme specifico di criteri:

• Tempo di avvio — tutte le VM si avviano entro l'intervallo previsto?
• Avvio dell'applicazione — l'applicazione viene inizializzata correttamente quando si connette al database ripristinato?
• Integrità dei dati — i dati presenti al punto di ripristino sono coerenti e completi?
• RTO effettivo — misuri il tempo totale trascorso dall'attivazione del failover fino a quando l'applicazione inizia a gestire le richieste
• Esecuzione del runbook — tutti gli script di automazione sono stati completati correttamente?

Durante il test, avvii un timer nel momento esatto in cui attiva il test di failover. Arresti il timer quando l'applicazione è confermata come funzionante (il probe di integrità del bilanciatore del carico restituisce 200 OK). Questo è il Suo RTO effettivo. Lo confronti con l'RTO obiettivo. Se il valore effettivo supera quello obiettivo, individui i colli di bottiglia — avvio lento delle VM, inizializzazione prolungata del database, ritardo nella propagazione DNS — e intervenga per risolverli.

Al termine del test di failover, si connetta al database ripristinato e verifichi i dati. Controlli che siano presenti le transazioni con commit eseguito prima del limite della replica e che le transazioni con commit parziale siano gestite correttamente (annullate o completate). Per i database con ripristino temporizzato (PITR), testi il ripristino a un timestamp specifico e verifichi lo stato previsto dei dati.

Al termine del test, è necessario eliminare le risorse del test di failover: le VM di test, i relativi dischi e le interfacce di rete nella regione secondaria. Azure Site Recovery offre nel portale l'azione 'Cleanup test failover', che rimuove automaticamente tutte le risorse di test. Dimenticare la pulizia comporta costi inutili e riempie la regione secondaria di risorse obsolete.

Dopo ogni test DR, rediga un report del test che includa: data e ambito del test, RTO e RPO effettivamente raggiunti, una checklist degli elementi di convalida con relativo stato superato/non superato, eventuali lacune o errori rilevati e le azioni correttive pianificate. Questo report è utile per gli audit di conformità (ISO 27001, SOC 2, HIPAA) e per monitorare nel tempo il miglioramento del livello di maturità DR.

Le procedure consigliate del settore e i framework di conformità richiedono generalmente test DR almeno ogni anno, ma molte organizzazioni eseguono test trimestrali o persino mensili per i carichi di lavoro di livello Tier 1. Test più frequenti rilevano prima la deriva della configurazione e accrescono la fiducia del team e la sua preparazione operativa. Automatizzi il più possibile la configurazione e la verifica del test, così da ridurre l'impegno richiesto dai test frequenti.

Azure Chaos Studio è un servizio gestito di chaos engineering che consente di introdurre guasti controllati nelle risorse Azure per testare la resilienza delle applicazioni. Può arrestare VM, simulare il guasto di zone, limitare la CPU o introdurre latenza di rete per osservare il comportamento dell'applicazione. A differenza di una normale esercitazione DR, il chaos engineering verifica se l'applicazione si degrada in modo regolare in condizioni di guasto parziale.

Il test DR è più utile quando fa parte di un ciclo di miglioramento continuo: Pianificare → Eseguire → Misurare → Correggere → Ripetere. Dopo ogni test, risolva le lacune individuate, aggiorni i runbook e la documentazione, quindi esegua nuovamente il test. Nel tempo, la differenza tra gli obiettivi RTO/RPO dichiarati e i valori effettivamente raggiunti dovrebbe ridursi, fino a superare costantemente ogni test entro i limiti di tolleranza.

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

In questa lezione ha appreso che il test di failover consente di simulare un evento DR senza interrompere la produzione, creando copie delle VM in una VNet isolata; durante il test è necessario misurare l'RTO effettivo e verificare l'integrità dei dati; dopo ogni esercitazione è inoltre opportuno eliminare le risorse di test e documentare i risultati. Nel prossimo argomento esamineremo il disaster recovery specifico per i servizi PaaS, come Azure SQL Database.