Failover e failback
Azure Site Recovery offre la flessibilità necessaria per eseguire il failover in Azure in caso di emergenza e il failback nei computer locali dopo che l'evento è terminato.
Ora si vuole eseguire un failover completo per il resto dell'ambiente protetto in Azure. Si esegue un failover completo dopo aver eseguito correttamente un'analisi del failover in una singola macchina virtuale di test. Dopo aver completato il failover, si eseguirà quindi il failback.
In questa unità verranno analizzate le differenze tra failover e failback. Si apprenderà anche come creare automaticamente un criterio di failback dopo aver configurato un criterio di replica in Azure.
Failover e failback
Un failover è il processo che si verifica quando viene presa la decisione di attuare il piano BCDR per l'azienda. Il failover si verifica quando l'ambiente attivo corrente, protetto tramite Site Recovery, viene spostato nell'ambiente di replica. Questo ambiente di replica di destinazione prende il posto dell'ambiente attivo e diventa l'infrastruttura primaria.
Un failback è il contrario di un failover. L'ambiente attivo precedente (che ora è l'ambiente di replica perché è stato eseguito un failover) riprende il proprio ruolo originale e diventa di nuovo l'ambiente attivo. Dopo che è stato eseguito il failover nella prima istanza, è necessaria una fase di riprotezione. In questa fase si sincronizza l'ambiente originale con il nuovo ambiente attivo. Questo processo consente di eseguire il failover e il failback senza alcuna perdita di dati. La fase di riprotezione richiede probabilmente molto tempo perché è necessario verificare che l'ambiente attivo precedente funzioni correttamente dopo l'emergenza.
Le quattro fasi per le azioni di failover e failback sono le seguenti:
- Failover in Azure: se il sito primario locale smette di funzionare, viene presa la decisione di eseguire il failover in Azure (o nel sito secondario), creando macchine virtuali dai dati replicati del sito primario.
- Riprotezione delle macchine virtuali di Azure: dopo aver eseguito il failover, è necessario riproteggere le macchine virtuali di Azure in modo che sia possibile replicare nuovamente le modifiche nell'ambiente locale dopo che l'emergenza è stata superata. Le macchine virtuali vengono spente per garantire la coerenza dei dati.
- Failback nell'ambiente locale: quando il sito locale torna operativo, è possibile eseguire il failover in tale ambiente. L'ambiente torna a essere quello attivo. Non è possibile eseguire il failback in server fisici. Il failback di tutti i sistemi deve essere eseguito in macchine virtuali.
- Riprotezione delle macchine virtuali locali: la riprotezione delle macchine virtuali locali consente di iniziare la replica in Azure dopo la corretta esecuzione del failback.
Criteri di failback
Quando si creano criteri di replica locale per copiare i computer locali in Azure, vengono creati automaticamente i criteri di failback associati. I criteri hanno alcuni attributi fissi che non possono essere modificati. Gli attributi sono:
- È possibile eseguire di nuovo la replica solo nel server di configurazione locale.
- L'obiettivo del punto di ripristino è impostato su 15 minuti.
- La conservazione del punto di ripristino è impostata su 24 ore.
- Gli snapshot coerenti con l'app sono impostati per l'esecuzione ogni ora.
L'esecuzione del failback arresta le macchine virtuali di Azure. Al termine della replica è necessario avviare la macchina virtuale locale per spostare i carichi di lavoro. Il servizio verrà interrotto, quindi pianificare il failback in un momento in cui non avrà alcun impatto sull'attività aziendale.
Piani di continuità aziendale e ripristino di emergenza
I piani BCDR in Site Recovery consentono la personalizzazione e la sequenziazione del failover e del failback delle macchine virtuali e delle applicazioni in esse eseguite. I computer vengono raggruppati e le azioni di ripristino possono essere automatizzate con l'uso di script durante il failover o il failback. Se necessario, è anche possibile aggiungere ulteriori passaggi manuali per le azioni. Se si testa il piano BCDR prima di un'emergenza, sarà più probabile ottenere risultati positivi. È necessario ripristinare il funzionamento dell'infrastruttura nella posizione secondaria in modo rapido per soddisfare l'obiettivo del tempo di ripristino dell'azienda.
Failover flessibili
Grazie alla flessibilità dei failover, Site Recovery consente di eseguire failover su richiesta a scopo di test. L'isolamento di questi test significa che i servizi in tempo reale non vengono interrotti. Questa flessibilità consente inoltre di eseguire un failover durante un'interruzione pianificata del servizio attivo. L'interruzione non interrompe gli utenti del sistema perché passano automaticamente all'ambiente replicato. La flessibilità funziona anche in senso inverso. Il failback può essere eseguito su richiesta, come parte di un test pianificato o di uno scenario di ripristino di emergenza richiamato.