Preparare per la riprotezione e il failback di macchine virtuali VMware

Articolo
09/18/2023

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.

Riprotezione o componenti di failback

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 in 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 durante il failover, deve essere stabilita 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 conservati, 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 nel sito locale. Il server di elaborazione riceve i dati dalla macchina virtuale di Azure protetta 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 prestazioni di replica più elevate. Per il 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. Il server di elaborazione deve anche essere in grado di 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 il failback delle macchine virtuali ha più di un totale collettivo 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 versione o una versione successiva) rispetto a quelli dei computer replicati. Il server di destinazione master non deve avere snapshot nei relativi dischi. In caso contrario, 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à.
Criteri di replica di failback	Per eseguire la replica nel sito locale, è necessario un criterio di failback. Questo criterio viene creato automaticamente quando si creano criteri di replica in Azure. I criteri vengono automaticamente associati al server di configurazione. È impostato su una soglia RPO di 15 minuti, la conservazione dei punti di ripristino di 24 ore e la frequenza degli snapshot coerenti con l'app è di 60 minuti. Non è possibile modificare i criteri.
VPN da sito a sito/peering privato ExpressRoute	La riprotezione e il failback richiede una connessione VPN da sito a sito o un peering privato ExpressRoute per replicare i dati.

Porte per la riprotezione/failback

È necessario aprire diverse porte per la riprotezione/failback. L'immagine seguente illustra le porte e il flusso di riprotezione/failback.

Porte per il failover e il failback

Distribuire un server di elaborazione in Azure

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

Distribuire un server di destinazione master distinto

Si notino i requisiti e le limitazioni del server di destinazione master.
Creare un server di destinazione master Windows o Linux in modo che corrisponda al sistema operativo delle macchine virtuali di cui si vuole riproteggere e eseguire il failback.
Assicurarsi di non usare Storage vMotion per il server di destinazione master oppure il failback può avere esito negativo. Non è possibile avviare la macchina virtuale perché i dischi non sono disponibili.
- Per evitare questo problema, escludere il server di destinazione master dall'elenco vMotion.
- Se una destinazione master viene sottoposta a un'attività Storage vMotion dopo la riprotezione, i dischi delle macchine virtuali protetti collegati al server di destinazione master eseguino la migrazione alla destinazione dell'attività vMotion. Se si tenta di eseguire il failback dopo questo problema, lo scollegamento del disco ha esito negativo perché i dischi non vengono trovati. È quindi 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.
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 in cui la macchina virtuale viene replicata nel sito locale. Si notino questi criteri. Se non vengono soddisfatte, l'unità non è 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/.
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. È possibile aggiornare il server di configurazione se l'unità non viene visualizzata dopo 15 minuti.
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.
Impostare il disco. EnableUUID=true impostazione nei parametri di configurazione della macchina virtuale 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.
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. Assicurarsi che l'archivio dati della macchina virtuale locale sia montato nell'host 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. Questa macchina virtuale viene creata nell'host ESXi in cui si crea la macchina virtuale del server 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 un percorso alternativo, i dati vengono ripristinati nello stesso archivio dati e nello stesso host ESXi usato dal server di destinazione master locale.
Per il failback dei computer fisici alle macchine virtuali VMware, è necessario completare l'individuazione dell'host in cui è in esecuzione il server di destinazione master, prima di poter riproteggere il computer.
Verificare che l'host ESXi in cui la macchina virtuale di destinazione master abbia almeno un archivio dati VMFS (Virtual Machine File System) collegato. Se non sono collegati archivi dati VMFS, l'input dell'archivio dati nelle impostazioni di riprotezione è vuoto e non è possibile procedere.

Passaggi successivi

Informazioni su come riproteggere una macchina virtuale.