Informazioni sul failover/failback del ripristino di emergenza locale - Modernizzato
Questo articolo offre una panoramica del failover e del failback durante il ripristino di emergenza di computer locali in Azure con Azure Site Recovery - Modernizzato.
Per informazioni sul failover e il failback nelle versioni classiche di Azure Site Recovery, vedere questo articolo.
Fasi di ripristino
Il failover e failback in Site Recovery comprende quattro fasi:
- Fase 1: eseguire il failover da un ambiente locale: dopo aver configurato la replica in Azure per i computer locali, quando il sito locale diventa inattivo, si esegue il failover di tali computer in Azure. Dopo il failover, le macchine virtuali di Azure vengono create da dati replicati.
- Fase 2: riprotezione delle macchine virtuali di Azure: in Azure, si riproteggono le macchine virtuali di Azure in modo da avviarne la replica nel sito locale. La macchina virtuale locale (se disponibile) viene spenta durante la riprotezione per garantire la coerenza dei dati.
- Fase 3: eseguire il failover da Azure: quando il sito locale è di nuovo in esecuzione normalmente, viene eseguito un altro failover, questa volta per eseguire il failback delle macchine virtuali di Azure nel sito locale. È possibile eseguire il failback nella posizione originaria da cui è stato eseguito il failover oppure in una posizione alternativa. Questa attività viene definita failover pianificato.
- Fase 4: riproteggere i computer locali: dopo il failback, abilitare di nuovo la replica dei computer locali in Azure.
Failover
Il failover viene eseguito come parte della strategia di continuità aziendale e ripristino di emergenza (BCDR).
- Come primo passaggio della strategia BCDR, è possibile replicare i computer locali in Azure in modo continuativo. Gli utenti accedono ai carichi di lavoro e alle app in esecuzione nei computer di origine locali.
- Se si verifica la necessità, ad esempio in caso di interruzione locale, viene eseguito il failover dei computer di replica in Azure. Le macchine virtuali di Azure usando i dati replicati.
- Per la continuità aziendale, gli utenti possono continuare ad accedere alle app nelle macchine virtuali di Azure.
Il failover è un'attività in due fasi:
- Failover: failover che crea e riattiva una macchina virtuale di Azure usando il punto di ripristino selezionato.
- Commit: dopo il failover, si verifica la macchina virtuale in Azure:
- È quindi possibile eseguire il commit del failover nel punto di ripristino selezionato o selezionare un punto diverso per il commit.
- Dopo aver eseguito il commit del failover, il punto di ripristino non può essere modificato.
Nota
Usare un punto di ripristino coerente con l'arresto anomalo del sistema in Windows Server 2012 o versioni precedenti, perché il tempo di avvio delle macchine virtuali di cui è stato eseguito il failover potrebbe essere più lungo per queste versioni in caso di punto di ripristino coerente con l'applicazione.
Connettersi ad Azure dopo il failover
Per connettersi alle macchine virtuali di Azure create dopo il failover tramite RDP/SSH, esistono diversi requisiti.
| Failover | Location | Azioni |
|---|---|---|
| VM di Azure che esegue Windows | Nel computer locale prima del failover | Accedere tramite Internet: abilitare RDP. Assicurarsi che siano aggiunte regole TCP e UDP per Pubblico e che RDP sia consentito per tutti i profili in Windows Firewall>App consentite. Accedere tramite VNP da sito a sito: abilitare RDP nel computer. Verificare che RDP sia consentito in Windows Firewall ->App e funzionalità consentite per le reti di dominio e private. Verificare che il criterio SAN del sistema operativo sia impostato su OnlineAll. Altre informazioni. Quando si attiva un failover, verificare che nella macchina virtuale non siano in sospeso aggiornamenti di Windows. Windows Update potrebbe essere avviato durante il failover e non si potrà accedere alla macchina virtuale finché gli aggiornamenti non verranno completati. |
| VM di Azure che esegue Windows | Nella macchina virtuale di Azure dopo il failover | Aggiungere un indirizzo IP pubblico per la macchina virtuale. Le regole del gruppo di sicurezza di rete nella macchina virtuale sottoposta a failover e nella subnet di Azure a cui è connessa devono consentire connessioni in ingresso alla porta RDP. Selezionare Diagnostica di avvio per visualizzare uno screenshot della macchina virtuale. Se non è possibile connettersi, verificare che la macchina virtuale è in esecuzione e rivedere i suggerimenti per la risoluzione dei problemi. |
| VM di Azure che esegue Linux | Nel computer locale prima del failover | Assicurarsi che il servizio Secure Shell nella macchina virtuale sia impostato per l'avvio automatico all'avvio del sistema. Verificare che le regole firewall accettino la connessione SSH. |
| VM di Azure che esegue Linux | Nella macchina virtuale di Azure dopo il failover | Le regole del gruppo di sicurezza di rete nella macchina virtuale sottoposta a failover e nella subnet di Azure a cui è connessa devono consentire connessioni in ingresso alla porta SSH. Aggiungere un indirizzo IP pubblico per la macchina virtuale. Selezionare Diagnostica di avvio per visualizzare uno screenshot della macchina virtuale. |
Tipi di failover
Site Recovery offre diverse opzioni di failover.
| Failover | Dettagli | Ripristino | Flusso di lavoro |
|---|---|---|---|
| Failover di test | Si usa per eseguire un'esercitazione che convalida la strategia BCDR, senza perdita di dati o tempi di inattività. | Crea una copia della macchina virtuale in Azure, senza alcun impatto sulla replica in corso o sull'ambiente di produzione. | 1. Eseguire un failover di test su una sola macchina virtuale o su più macchine virtuali in un piano di ripristino. 2. Selezionare un punto di ripristino da usare per il failover di test: 3. Selezionare una rete di Azure in cui verrà collocata la macchina virtuale di Azure quando viene creata dopo il failover. La rete viene usata solo per il failover di test. 4. Verificare che l'esercitazione abbia funzionato come previsto. Site Recovery pulisce automaticamente le macchine virtuali create in Azure durante l'esercitazione. |
| Failover pianificato - Hyper-V | Si usa per un tempo di inattività pianificato. Le macchine virtuali di origine vengono arrestate. I dati più recenti vengono sincronizzati prima di avviare il failover. |
Nessuna perdita di dati per il flusso di lavoro pianificato. | 1. Pianificare una finestra di manutenzione con tempo di inattività e inviare una notifica agli utenti. 2. Portare offline le app rivolte agli utenti. 3. Avviare un failover pianificato con l'ultimo punto di ripristino. Il failover non viene eseguito se il computer non viene arrestato o se si verificano errori. 4. Dopo il failover, verificare che la macchina virtuale di Azure di replica sia attiva in Azure. 5. Eseguire il commit del failover per completare le operazioni. L'azione di commit elimina tutti i punti di ripristino. |
| Failover - Hyper-V | In genere viene eseguito se si verifica un'interruzione non pianificata o il sito primario non è disponibile. Facoltativamente, arrestare la macchina virtuale e sincronizzare le modifiche finali prima di avviare il failover. |
Perdita minima di dati per le app. | 1. Avviare il piano BCDR. 2. Avviare il failover. Specificare se Site Recovery deve arrestare la macchina virtuale e sincronizzare/replicare le ultime modifiche prima di attivare il failover. 3. È possibile eseguire il failover su molte opzioni del punto di ripristino, riepilogate qui. Se non si abilita l'opzione per arrestare la VM o se Site Recovery non è in grado di arrestarla, viene usato il punto di ripristino più recente. Il failover viene eseguito anche se non è possibile arrestare la VM. 4. Dopo il failover, verificare che la macchina virtuale di Azure di replica sia attiva in Azure. Se necessario, è possibile selezionare un punto di ripristino diverso dalla finestra di conservazione di 24 ore. 5. Eseguire il commit del failover per completare le operazioni. L'azione di commit elimina tutti i punti di ripristino disponibili. |
| Failover - VMware | In genere viene eseguito se si verifica un'interruzione non pianificata o il sito primario non è disponibile. Facoltativamente, specificare che Site Recovery deve tentare di attivare un arresto della macchina virtuale e di sincronizzare e replicare le modifiche finali prima di avviare il failover. |
Perdita minima di dati per le app. | 1. Avviare il piano BCDR. 2. Avviare un failover da Site Recovery. Specificare se Site Recovery deve provare ad attivare l'arresto e la sincronizzazione della VM prima di eseguire il failover. Il failover viene eseguito anche se i computer non possono essere arrestati. 3. Dopo il failover, verificare che la macchina virtuale di Azure di replica sia attiva in Azure. Se necessario, è possibile selezionare un punto di ripristino diverso dal periodo di conservazione di 72 ore. 5. Eseguire il commit del failover per completare le operazioni. L'azione di commit elimina tutti i punti di ripristino. Per le macchine virtuali Windows Site Recovery disabilita gli strumenti VMware durante il failover. |
| Failover pianificato - VMware | È possibile eseguire un failover pianificato da Azure a locale. | Poiché è un'attività di failover pianificato, il punto di ripristino viene generato dopo l'attivazione del processo di failover pianificato. | Quando viene attivato il failover pianificato, le modifiche in sospeso vengono copiate in locale, viene generato un punto di ripristino più recente della macchina virtuale e la macchina virtuale di Azure viene arrestata. Seguire il processo di failover come descritto qui. Dopo questa operazione, il computer locale è attivato. Dopo un failover pianificato, il computer sarà attivo nell'ambiente locale. |
Elaborazione del failover
In alcuni scenari il failover richiede un'altra elaborazione il cui completamento richiede da 8 a 10 minuti. Si possono notare tempi di failover di test più lunghi per:
- VM VMware che non hanno il servizio DHCP abilitato.
- VM VMware che non hanno i driver di avvio seguenti: storvsc, vmbus, storflt, intelide, atapi.
Opzioni del punto di ripristino
Durante il failover, è possibile selezionare molte opzioni del punto di ripristino.
| Opzione | Dettagli |
|---|---|
| Ultimo (RPO più basso) | Questa opzione assicura l'obiettivo del punto di ripristino (RPO) più basso. Prima vengono elaborati tutti i dati inviati al servizio Site Recovery per creare un punto di ripristino per ogni macchina virtuale e quindi viene eseguito il failover in tale punto di ripristino. Inizialmente vengono elaborati e applicati tutti i dati inviati al servizio Site Recovery nel posizione di destinazione, poi usando i dati elaborati viene creato un punto di ripristino. Tuttavia, se viene attivato il failover, non saranno presenti dati caricati nel servizio Site Recovery in attesa di essere elaborati; Azure Site Recovery non eseguirà alcuna elaborazione e, di conseguenza, non creerà un nuovo punto di ripristino. In questo scenario, invece, verrà eseguito il failover usando solo il punto di ripristino elaborato in precedenza. |
| Ultimo elaborato | Questa opzione consente di eseguire il failover delle macchine virtuali nell'ultimo punto di ripristino elaborato da Site Recovery. Per vedere il punto di ripristino più recente per una macchina virtuale specifica, selezionare Punti di ripristino più recenti nelle impostazioni della macchina virtuale. Offre un RTO (Recovery Time Objective) basso poiché non viene impiegato tempo per elaborare dati non elaborati. |
| Ultimo coerente con l'app | Questa opzione esegue il failover delle macchine virtuali all'ultimo punto di ripristino coerente con l'applicazione elaborato da Site Recovery se sono abilitati i punti di ripristino coerenti con l'app. Controllare l'ultimo punto di ripristino nelle impostazioni della macchina virtuale. |
| Ultimo elaborato tra più macchine virtuali | questa opzione è disponibile per i piani di ripristino con una o più macchine virtuali in cui è abilitata la coerenza tra più macchine virtuali. Le macchine virtuali con l'impostazione abilitata eseguono il failover nell'ultimo punto di ripristino coerente tra più macchine comune. Le altre macchine virtuali nel piano eseguono il failover nell'ultimo punto di ripristino elaborato. |
| Ultimo coerente con l'app tra più macchine virtuali | questa opzione è disponibile per i piani di ripristino con una o più macchine virtuali in cui è abilitata la coerenza tra più macchine virtuali. Le macchine virtuali che fanno parte di un gruppo di replica eseguono il failover nell'ultimo punto di ripristino comune coerente con l'applicazione tra più macchine virtuali. Le altre macchine virtuali eseguono il failover nel loro ultimo punto di ripristino coerente con l'applicazione. |
| Personalizzazione | Usare questa opzione per eseguire il failover di una macchina virtuale specifica in un punto di ripristino specifico nel tempo. Questa opzione non è disponibile per i piani di ripristino. |
Nota
Non è possibile eseguire la migrazione dei punti di ripristino a un altro insieme di credenziali di Servizi di ripristino.
Riprotezione/failover pianificato
Dopo il failover in Azure, le macchine virtuali di Azure replicate hanno uno stato non protetto.
- Come primo passaggio per eseguire il failback nel sito locale, è necessario avviare la replica delle macchine virtuali di Azure in locale. Il processo di riprotezione dipende dal tipo di computer di cui è stato eseguito il failover.
- Dopo la replica dei computer da Azure all'ambiente locale, è possibile eseguire un failover da Azure al sito locale.
- Dopo che i computer vengono eseguiti nuovamente in locale, è possibile abilitare la replica in modo che vengano replicati in Azure per il ripristino di emergenza.
- Solo i dischi replicati dall'ambiente locale ad Azure vengono replicati nuovamente da Azure durante l'operazione di riprotezione. I dischi appena aggiunti per il failover della macchina virtuale di Azure non verranno replicati nel computer locale.
- Un'appliance può avere fino a 60 dischi collegati. Se le macchine virtuali sottoposte a failback hanno più di un totale complessivo di 60 dischi o se si esegue il failback di grandi volumi di traffico, creare un'appliance separata per il failback.
Il failover pianificato funziona come indicato di seguito:
- Per eseguire il failback in un ambiente locale, una macchina virtuale richiede almeno un punto di ripristino per l'esecuzione del failback. In un piano di ripristino, tutte le macchine virtuali nel piano richiedono almeno un punto di ripristino.
- Poiché è un'attività di failover pianificato, è possibile selezionare il tipo di punto di ripristino a cui si vuole eseguire il failback. È consigliabile usare un punto coerente con l'arresto anomalo del sistema.
- È disponibile anche un'opzione del punto di ripristino coerente con l'app. In questo caso, una singola macchina virtuale viene ripristinata nell'ultimo punto di ripristino coerente con l'app disponibile. Per un piano di ripristino con un gruppo di replica, ogni gruppo di replica viene ripristinato nel punto di recupero comune disponibile.
- I punti di recupero coerenti con l'app possono essere indietro nel tempo e potrebbero verificarsi perdite di dati.
- Durante il failover da Azure nel sito locale, Site Recovery arresta le macchine virtuali di Azure. Quando si esegue il commit del failover, Site Recovery rimuove le macchine virtuali di Azure di cui è stato eseguito il failback in Azure.
Nota
L'avvio della macchina virtuale di failover potrebbe richiedere più tempo in Windows Server 2012 o versioni precedenti quando si usano punti di ripristino coerenti con l'arresto anomalo del sistema.
Riprotezione/Failback di computer VMware/fisici
Per riproteggere ed eseguire il failback di computer VMware e server fisici da Azure all'ambiente locale, assicurarsi di disporre di un'appliance integra.
Selezione dell'appliance
- È possibile selezionare una delle appliance di replica di Azure Site Recovery registrate in un insieme di credenziali per la riprotezione nell'ambiente locale. Non è necessario un server di elaborazione separato in Azure per l'operazione di riprotezione e un server di destinazione master con scalabilità orizzontale per le macchine virtuali Linux.
- L'appliance di replica non richiede un'altra connessione di rete o porte (rispetto alla protezione in avanti) durante il failback. La stessa appliance può essere usata per la protezione avanti e indietro se il suo stato è integro. Non dovrebbe influire sulle prestazioni delle repliche.
- Quando si seleziona l'appliance, assicurarsi che l'archivio dati di destinazione in cui si trova il computer di origine sia accessibile dall'appliance. L'archivio dati del computer di origine deve essere sempre accessibile dall'appliance. Anche se il computer e l'appliance si trovano in server ESX diversi, la riprotezione riesce purché l'archivio dati sia condiviso tra loro.
Nota
- L'archiviazione vMotion degli elementi replicati non è supportata. L'archiviazione vMotion dell'appliance di replica non è supportata dopo l'operazione di riprotezione.
- Quando si seleziona l'appliance, assicurarsi che l'archivio dati di destinazione in cui si trova il computer di origine sia accessibile dall'appliance.
Processo di riprotezione
- Se è una nuova operazione di riprotezione, per impostazione predefinita un nuovo account di archiviazione log viene creato automaticamente da Azure Site Recovery nell'area di destinazione. Il disco di conservazione non è obbligatorio.
- Nel ripristino in una posizione alternativa e nel ripristino nella posizione originaria, vengono recuperate le configurazioni originarie dei computer di origine.
Nota
- Non è possibile conservare l'indirizzo IP statico in caso di riprotezione in una posizione alternativa (ALR) o di riprotezione nella posizione originaria (OLR).
- fstab, LVMconf verrebbe modificato.
Errore
- Un processo di riprotezione non riuscito può essere tentato nuovamente. Durante i nuovi tentativi, è possibile scegliere qualsiasi appliance di replica integra.
Quando si riproteggono computer di Azure in un ambiente locale, si riceve una notifica indicante che il failback viene eseguito nella posizione originaria o in una posizione alternativa.
Ripristino nella posizione originaria: viene eseguito il failback da Azure nello stesso computer locale di origine, se esiste. In questo scenario, viene eseguita nuovamente la replica delle sole modifiche nell'ambiente locale.
- Selezione dell'archivio dati durante la riprotezione nella posizione originaria (OLR): l'archivio dati collegato al computer di origine viene selezionato automaticamente.
Ripristino in una posizione alternativa: se il computer locale non esiste, è possibile eseguire il failback da Azure in una posizione alternativa. Quando si riprotegge la macchina virtuale di Azure in un ambiente locale, viene creato il computer locale. La replica completa dei dati viene eseguita da Azure all'ambiente locale. Esaminare i requisiti e le limitazioni per il failback della posizione.
- Selezione dell'archivio dati durante la riprotezione in una posizione alternativa (ALR): è possibile scegliere qualsiasi archivio dati gestito da vCenter in cui si trova ed è accessibile l'appliance (autorizzazioni di lettura e scrittura) dall'appliance (originaria/nuova). È possibile scegliere l'account di archiviazione della cache usato per la riprotezione.
Una volta completato il failover, l'agente di mobilità nella macchina virtuale di Azure viene registrato automaticamente con Site Recovery Services. Se la registrazione non riesce, viene generato un problema di integrità critico nella macchina virtuale di cui è stato eseguito il failover. Dopo aver risolto il problema, la registrazione viene attivata automaticamente. È possibile completare manualmente la registrazione dopo aver risolto gli errori.
Annullare il failover
Se l'ambiente locale non è pronto o in caso di problemi, è possibile annullare il failover.
Dopo aver avviato e completato correttamente il failover pianificato, l'ambiente locale diventa disponibile per l'uso. Tuttavia, dopo il completamento dell'operazione, se si vuole eseguire il failover in un punto di ripristino diverso, è possibile annullare il failover.
È possibile annullare solo un failover pianificato.
È possibile annullare un failover pianificato dalla pagina Elementi replicati nell'insieme di credenziali di Servizi di ripristino.
Dopo l'annullamento del failover, i computer in Azure vengono riattivati e la replica viene avviata nuovamente da Azure all'ambiente locale.