Piani di ripristino e failover automatizzato

Un Recovery Plan in Azure Site Recovery è una sequenza strutturata e ordinata di passaggi che orchestra il failover simultaneo di più VM. Anziché eseguire il failover di ogni VM singolarmente, un piano di ripristino le raggruppa in gruppi che eseguono il failover in sequenza, assicurando che l'infrastruttura (database, middleware, web) venga avviata nell'ordine corretto, proprio come durante la distribuzione iniziale.

Per creare un piano di ripristino, selezioni il sito di origine (area geografica primaria) e il sito di destinazione (area geografica secondaria), quindi aggiunga le VM da includere. La procedura guidata del piano crea automaticamente un gruppo predefinito, ma può aggiungere altri gruppi per controllare la sequenza di failover. Le VM dello stesso gruppo eseguono il failover simultaneamente; i gruppi vengono eseguiti nell'ordine numerico.

Per una tipica applicazione a tre livelli, il piano di ripristino dovrebbe includere tre gruppi:

• Gruppo 1 — VM del livello database (devono essere avviate per prime)
• Gruppo 2 — VM del livello applicativo/middleware
• Gruppo 3 — VM del frontend web (vengono avviate per ultime)

Ogni gruppo attende che il gruppo precedente completi correttamente il failover prima di avviarsi. In questo modo viene rispettato l'ordine corretto di avvio e si impedisce alle VM del livello web di avviarsi prima che il database sia pronto ad accettare le connessioni.

I piani di ripristino supportano azioni preliminari e azioni successive ai confini di ogni gruppo. Possono essere:

• Azioni manuali — mettono in pausa il failover e attendono la conferma di una persona (ad esempio «Verificare che il database sia pronto»)
• runbook di Azure Automation — eseguono automaticamente uno script (ad esempio aggiornare i record DNS o disabilitare la modalità di manutenzione)

L'uso dei runbook di Automation consente un failover completamente automatizzato, senza intervento umano, per i carichi di lavoro di livello 1.

Azure Site Recovery supporta due tipi di failover:

• Failover pianificato — avviato prima di un evento noto (ad esempio la manutenzione del data center). La VM primaria viene arrestata correttamente, i dati vengono sincronizzati e quindi viene avviata la VM secondaria. Non si verifica alcuna perdita di dati.
• Failover non pianificato — attivato durante un evento disastroso effettivo. La VM primaria potrebbe non essere disponibile, quindi ASR utilizza il checkpoint di replica più recente. È possibile che si verifichi una perdita di dati, a seconda dell'RPO.

Dopo un failover, le VM ripristinate nell'area geografica secondaria si trovano nello stato pending commit. Deve confermare il failover per indicare che il sito secondario è ora il sito attivo e che non desidera eseguire il rollback. Dopo la conferma, può configurare la replica inversa per proteggere il sito secondario ed eventualmente eseguire il failback verso l'area geografica primaria quando questa sarà stata ripristinata.

Dopo aver confermato un failover, gli elementi replicati nell'area geografica primaria originale non vengono più replicati attivamente. Per ripristinare la protezione, deve riproteggere gli elementi: in questo modo la direzione della replica viene invertita e la nuova area primaria (in precedenza secondaria) replica verso l'area primaria originale. La riprotezione richiede tempo e dovrebbe essere avviata non appena l'area geografica primaria originale torna disponibile.

Ogni passaggio di un piano di ripristino contribuisce all'RTO totale. Tra le attività che richiedono più tempo rientrano:

• tempo di avvio delle VM (2-5 minuti per VM)
• tempo di inizializzazione dell'applicazione (inizializzazione del pool di connessioni al database, riscaldamento della cache)
• propagazione del DNS dopo le modifiche agli indirizzi IP
• tempi di attesa per le approvazioni manuali

Misuri ogni passaggio durante i test di failover e li sommi per calcolare il Suo RTO effettivo rispetto all'obiettivo.

Dopo un failover, le VM nella regione secondaria hanno indirizzi IP diversi. Per le applicazioni che espongono un nome DNS pubblico, è necessario aggiornare il DNS affinché punti ai nuovi IP. Utilizzi un runbook di Azure Automation come azione post-failover per aggiornare Azure DNS o lo stato di integrità degli endpoint di Traffic Manager e reindirizzare automaticamente il traffico, evitando un passaggio manuale che potrebbe ritardare l'RTO.

Durante un failover, la visualizzazione Jobs del portale Azure nell'insieme di credenziali di Recovery Services mostra in tempo reale l'avanzamento di ogni passaggio del piano di ripristino. Può vedere quale gruppo è in esecuzione, quali VM sono state avviate correttamente e se sono in attesa script o azioni manuali. Il monitoraggio di questa visualizzazione consente al team di ripristino di intervenire rapidamente in caso di errore di un passaggio.

Principali procedure consigliate per i piani di ripristino:

• Mantenga i gruppi piccoli (5-10 VM) per limitare il raggio d'impatto in caso di errore di un gruppo
• Utilizzi runbook di Automation invece di azioni manuali quando possibile, per ridurre l'RTO
• Documenti il tempo di avvio previsto per ogni gruppo, così da poter calcolare l'RTO
• Esegua un test di failover almeno ogni trimestre per convalidare il piano
• Riveda e aggiorni il piano ogni volta che vengono aggiunte nuove VM o cambia l'architettura dell'applicazione

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

In questa lezione ha appreso che un piano di ripristino orchestra il failover ordinato di più VM, con azioni pre e post per ogni gruppo; il failover non pianificato utilizza l'ultimo checkpoint di replica, mentre il failover pianificato non comporta alcuna perdita di dati; dopo il failover è necessario eseguire commit e reprotect per ripristinare la protezione DR. Nel prossimo argomento vedremo come testare i piani DR senza influire sull'ambiente di produzione.