Preparare per la riprotezione e il failback di macchine virtuali VMware

Dopo il failover di macchine virtuali VMware locali o server fisici in Azure, è necessario riproteggere le macchine virtuali di Azure create dopo il failover, in modo che vengano replicate nuovamente nel sito locale. Con la replica da Azure a locale, è quindi possibile eseguire il failback eseguendo un failover da Azure a locale quando si è pronti.

Componenti di failback o riprotezione

Sono necessari diversi componenti e impostazioni prima di poter riproteggere e eseguire il failback da Azure.

Componente	Dettagli
Server di configurazione locale	Il server di configurazione locale deve essere in esecuzione e connesso ad Azure. La macchina virtuale a cui si esegue il failback deve esistere nel database del server di configurazione. Se l'emergenza influisce sul server di configurazione, ripristinarlo con lo stesso indirizzo IP per garantire il funzionamento del failback. Se gli indirizzi IP dei computer replicati sono stati mantenuti in caso di failover, è necessario stabilire la connettività da sito a sito (o connettività ExpressRoute) tra le macchine virtuali di Azure e la scheda di interfaccia di rete di failback del server di configurazione. Per gli indirizzi IP manutenuti, il server di configurazione richiede due schede di interfaccia di rete, una per la connettività del computer di origine e una per la connettività di failback di Azure. In questo modo, si evita la sovrapposizione degli intervalli di indirizzi della subnet per l'origine e il failover delle macchine virtuali.
Server di elaborazione in Azure	È necessario un server di elaborazione in Azure prima di poter eseguire il failback del sito locale. Il server di elaborazione riceve i dati dalla macchina virtuale protetta di Azure e li invia al sito locale. È necessaria una rete a bassa latenza tra il server di elaborazione e la macchina virtuale protetta, quindi è consigliabile distribuire il server di elaborazione in Azure per ottenere prestazioni di replica più elevate. Per un modello di verifica, è possibile usare il server di elaborazione locale ed ExpressRoute con peering privato. Il server di elaborazione deve trovarsi nella rete di Azure in cui si trova la macchina virtuale di cui è stato eseguito il failover. Questo server di elaborazione deve anche poter comunicare con il server di configurazione locale e il server di destinazione master.
Server di destinazione master separato	Il server di destinazione master riceve i dati di failback e per impostazione predefinita viene eseguito un server di destinazione master Windows nel server di configurazione locale. Un server di destinazione master 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 server di destinazione master separato per il failback. Se i computer vengono raccolti in un gruppo di replica per la coerenza tra più macchine virtuali, le macchine virtuali devono essere tutte Windows o devono essere tutte Linux. Perché? Poiché tutte le macchine virtuali in un gruppo di replica devono usare lo stesso server di destinazione master e il server di destinazione master deve avere lo stesso sistema operativo (con la stessa o una versione successiva) rispetto a quelli dei computer replicati. Il server di destinazione master non deve avere snapshot nei dischi, altrimenti la riprotezione e il failback non funzioneranno. Il server di destinazione master non può avere un controller SCSI Paravirtual. Il controller può essere solo un controller LSI Logic. Senza un controller LSI Logic, la riprotezione non riuscirà.
Criterio di replica di failback	Per eseguire la replica nel sito locale, è necessario un criterio di failback, che viene creato automaticamente quando si crea un criterio di replica ad Azure. I criteri vengono automaticamente associati al server di configurazione. È impostato su una soglia RPO di 15 minuti, una la conservazione del punto di ripristino di 24 ore e la frequenza degli snapshot coerenti con l'app è di 60 minuti. Non è possibile modificare il criterio.
Peering privato ExpressRoute/VPN da sito a sito	La riprotezione e il failback devono avere una connessione VPN da sito a sito o un peering privato expressRoute per replicare i dati.

Porte per riprotezione/failback

Per la riprotezione/failback, è necessario aprire una serie di porte. Il grafico seguente illustra le porte e il flusso di riprotezione/failback.

Distribuire un server di elaborazione in Azure

1. Configurare un server di elaborazione in Azure per il failback
2. Assicurarsi che le macchine virtuali di Azure possano raggiungere il server di elaborazione.
3. Assicurarsi che la connessione VPN da sito a sito o la rete di peering privato ExpressRoute disponga di larghezza di banda sufficiente per inviare dati dal server di elaborazione al sito locale.

Distribuire un server di destinazione master distinto

1. Prendere nota dei requisiti e delle limitazioni del server di destinazione master.

2. Creare un server di destinazione master Windows o Linux in modo che corrisponda al sistema operativo delle macchine virtuali da riproteggere e su cui eseguire il failback.

3. Assicurarsi di non usare Storage vMotion per il server di destinazione master, altrimenti il failback può avere esito negativo. La macchina virtuale non viene avviata perché i dischi non risultano disponibili.

   • Per impedire questo problema, escludere i server di destinazione master dall'elenco vMotion.
   • Se una destinazione master viene sottoposta a un'attività di Storage vMotion dopo la riprotezione, per i dischi delle macchine virtuali protette collegati alla destinazione master viene eseguita la migrazione alla destinazione dell'attività di vMotion. Se si tenta di eseguire il failback dopo questa operazione, la rimozione del disco ha esito negativo perché i dischi non vengono trovati. Diventa quindi molto difficile trovare i dischi negli account di archiviazione. In questo caso, trovarli manualmente e collegarli alla macchina virtuale. Successivamente, è possibile avviare la macchina virtuale locale.

4. Aggiungere un'unità di conservazione al server di destinazione master Windows esistente. Aggiungere un nuovo disco e formattare l'unità. L'unità di conservazione viene usata per arrestare i punti nel tempo quando la macchina virtuale esegue di nuovo la replica nel sito locale. Si notino questi criteri. Se non vengono soddisfatti, l'unità non viene elencata per il server di destinazione master:

   • Il volume non viene usato per altri scopi, ad esempio una destinazione di replica, e non è in modalità di blocco.
   • Il volume non è un volume della cache. Il volume di installazione personalizzata per il server di elaborazione e il server di destinazione master non è idoneo per un volume di conservazione. Quando il server di elaborazione e il server di destinazione master vengono installati in un volume, si tratta di un volume della cache del server di destinazione master.
   • Il file system del volume non è di tipo FAT o FAT32.
   • La capacità del volume è diversa da zero.
   • Il volume di conservazione predefinito per Windows è il volume R.
   • Il volume di conservazione predefinito per Linux è /mnt/retention/.

5. Aggiungere un'unità se si usa un server di elaborazione esistente. La nuova unità deve soddisfare i requisiti nell'ultimo passaggio. Se l'unità di conservazione non è presente, non verrà inclusa nell'elenco a discesa di selezione nel portale. Dopo aver aggiunto un'unità alla destinazione master locale, sono necessari fino a 15 minuti perché l'unità appaia nell'elenco di selezione nel portale. È anche possibile aggiornare il server di configurazione se l'unità non appare dopo 15 minuti.

6. Installare gli strumenti VMware oppure open-vm-tools nel server master di destinazione. Senza gli strumenti, non è possibile rilevare gli archivi dati nell'host ESXi del server di destinazione master.

7. Assicurarsi di configurare l'impostazione disk.enableUUID=true nei parametri di configurazione della VM di destinazione master in VMware. Se questa riga non esiste, aggiungerla. Questa impostazione è necessaria per fornire un valore UUID coerente al file VMDK in modo che venga montato correttamente.

8. Controllare i requisiti di accesso al server vCenter:

   • Se la macchina virtuale a cui si esegue il failback si trova in un host ESXi gestito dal server VMware vCenter, il server di destinazione master deve accedere al file VM Virtual Machine Disk (VMDK) locale, per scrivere i dati replicati nei dischi della macchina virtuale. Verificare che l'archivio dati della macchina virtuale in locale sia montato nell'host del server di destinazione master con accesso in lettura/scrittura.
   • Se la macchina virtuale non si trova in un host ESXi gestito da un server VMware vCenter, Site Recovery crea una nuova macchina virtuale durante la riprotezione. La VM viene creata nell'host ESXi in cui si crea la VM di destinazione master. Scegliere attentamente l'host ESXi per creare la macchina virtuale nell'host desiderato. Il disco rigido della macchina virtuale deve trovarsi in un archivio dati accessibile dall'host in cui è in esecuzione il server di destinazione master.
   • Un'altra opzione, in presenza della VM locale per il failback, consiste nell'eliminarla prima di eseguire un failback. Il failback crea quindi una nuova macchina virtuale nello stesso host dell'host ESXi di destinazione master. Quando si esegue il failback in una posizione alternativa, i dati vengono ripristinati nello stesso archivio dati e nello stesso host ESXi usati dal server di destinazione master locale.

9. Per le macchine fisiche di cui si esegue il failback su macchine virtuali VMware, è necessario completare l'individuazione dell'host in cui viene eseguito il server di destinazione master prima di riproteggere la macchina.

10. Verificare che l'host ESXi in cui viene creata la destinazione master abbia almeno un archivio dati VMFS (Virtual Machine File System) collegato a esso. In assenza di archivi dati VMFS collegati, l'input dell'archivio dati nella pagina di riprotezione è vuoto e non è possibile procedere.

Passaggi successivi

Informazioni su come riproteggere una macchina virtuale.