Funzionamento della replica Hyper-V in Azure in Site Recovery

Questo articolo illustra i componenti e i processi interessati durante la replica di macchine virtuali Hyper-V locali in Azure usando il servizio Azure Site Recovery.

Site Recovery consente di replicare macchine virtuali Hyper-V in cluster Hyper-V e host autonomi gestiti con o senza System Center Virtual Machine Manager (VMM).

Per inviare commenti è possibile usare la parte inferiore di questo articolo oppure il forum sui Servizi di ripristino di Azure.

Componenti dell'architettura

Sono diversi i componenti interessati durante la replica di macchine virtuali Hyper-V in Azure.

Componente Posizione Dettagli
Azzurro In Azure sono necessari un account Microsoft Azure, un account di archiviazione di Azure e una rete di Azure. I dati replicati vengono salvati nell'account di archiviazione e,quando si verifica un failover dal sito locale, vengono create VM di Azure con i dati replicati.

Le VM di Azure si connettono alla rete virtuale di Azure quando vengono create.
Server VMM Gli host Hyper-V si trovano in cloud VMM. Se gli host Hyper-V sono gestiti in cloud VMM, il server VMM viene registrato nell'insieme di credenziali di Servizi di ripristino.

Nel server VMM è necessario installare il provider di Site Recovery per orchestrare la replica con Azure.

È necessaria la configurazione di reti logiche e VM per configurare il mapping di rete. È necessario che una rete VM sia collegata a una rete logica associata al cloud.
Host Hyper-V Gli host e i cluster Hyper-V possono essere distribuiti con o senza server VMM. In assenza di un server VMM, il provider di Site Recovery è installato nell'host per orchestrare la replica con Site Recovery tramite Internet. Se è presente un server VMM, il provider è installato in esso e non nell'host.

L'agente di Servizi di ripristino viene installato nell'host per gestire la replica dei dati.

Le comunicazioni dal provider e dall'agente sono protette e crittografate. I dati replicati nell'archiviazione di Azure vengono anche crittografati.
VM Hyper-V È necessaria una o più macchine virtuali in esecuzione nel server host Hyper-V. Non è necessario installare esplicitamente alcun componente nelle macchine virtuali.

Informazioni sui prerequisiti di distribuzione e i requisiti per ognuno di questi componenti sono disponibili nella matrice di supporto.

Figura 1: Replica dal sito Hyper-V ad Azure

Componenti

Figura 2: Replica da Hyper-V nei cloud VMM ad Azure

Componenti

Processo di replica

Figura 3: Processo di replica e ripristino per la replica Hyper-V in Azure

flusso di lavoro

Abilitare la protezione

  1. Dopo aver abilitato la protezione per una macchina virtuale Hyper-V, nel portale di Azure o in locale, viene avviato Abilita protezione.
  2. Il processo controlla se il computer è conforme ai prerequisiti, prima di richiamare CreateReplicationRelationship, per impostare la replica con le impostazioni configurate.
  3. Il processo avvia la replica iniziale richiamando il metodo StartReplication, per inizializzare una replica della macchina virtuale completa e inviare i dischi virtuali della VM ad Azure.
  4. Il processo può essere monitorato nella scheda Processi. Elenco dei processi Abilita protezione in dettaglio

Replicare i dati iniziali

  1. Quando viene attivata la replica iniziale, viene acquisito uno snapshot della VM Hyper-V.
  2. I dischi rigidi virtuali vengono replicati uno alla volta fino a quando non vengono copiati tutti in Azure. L'operazione potrebbe richiedere alcuni minuti, a seconda delle dimensioni della macchina virtuale e della larghezza di banda di rete. Per informazioni su come ottimizzare l'utilizzo della rete, vedere How to manage on-premises to Azure protection network bandwidth usage(Come gestire l'utilizzo della larghezza di banda di rete per la protezione da ambiente locale ad Azure).
  3. Se vengono apportate modifiche al disco mentre è in corso la replica iniziale, la gestione delle repliche di Hyper-V tiene traccia delle modifiche sotto forma di log di replica di Hyper-V (con estensione hrl). Questi file si trovano nella stessa cartella dei dischi. A ogni disco è associato un file con estensione hrl, che verrà inviato alla risorsa di archiviazione secondaria.
  4. Si noti che lo snapshot e i file di log usano risorse del disco durante l'esecuzione della replica iniziale.
  5. Al termine della replica iniziale, lo snapshot della macchina virtuale viene eliminato. Nel log le modifiche differenziali al disco vengono sincronizzate e unite al disco padre.

Finalizzare la protezione

  1. Al termine della replica iniziale, il processo Finalizza la protezione nella macchina virtuale configura la rete e altre impostazioni successive alla replica, in modo che la macchina virtuale sia protetta. Processo Finalizza la protezione
  2. Se si esegue la replica in Azure, potrebbe essere necessario modificare le impostazioni della macchina virtuale in modo che sia pronta per il failover. A questo punto è possibile eseguire un failover di test per controllare che tutto funzioni come previsto.

Replicare il differenziale

  1. Dopo la replica iniziale, viene avviata la sincronizzazione differenziale in base alle impostazioni della replica.
  2. La gestione delle repliche di Hyper-V tiene traccia delle modifiche in un disco rigido virtuale sotto forma di file con estensione hrl. A ogni disco configurato per la replica è associato un file con estensione hrl. I log vengono inviati all'account di archiviazione del cliente al termine della replica iniziale. Quando un log è in transito verso Azure, le modifiche nel disco primario vengono registrate in un altro file di log nella stessa directory.
  3. Durante la replica iniziale e differenziale, è possibile monitorare la macchina virtuale nella relativa visualizzazione. Altre informazioni.

Sincronizzare la replica

  1. Se la replica differenziale non riesce e una replica completa risulta costosa a livello di larghezza di banda o di tempo richiesto, la macchina virtuale verrà contrassegnata per la risincronizzazione. Ad esempio, se i file con estensione hrl raggiungono il 50% delle dimensioni del disco, la macchina virtuale verrà contrassegnata per la risincronizzazione.
  2. La risincronizzazione riduce al minimo la quantità di dati inviati calcolando i checksum delle macchine virtuali di origine e di destinazione e inviando solo i dati relativi al differenziale. La risincronizzazione usa un algoritmo di suddivisione in blocchi a blocchi fissi che suddivide appunto i file di origine e di destinazione in blocchi fissi. I checksum per ogni blocco vengono generati e messi a confronto per determinare quali blocchi dell'origine devono essere applicati alla destinazione.
  3. Al termine della risincronizzazione, dovrebbe riprendere la normale replica differenziale. Per impostazione predefinita, la risincronizzazione è pianificata per l'esecuzione automatica negli orari non lavorativi, ma è possibile risincronizzare manualmente una macchina virtuale. Ad esempio, se si verifica un'interruzione di rete o un'altra interruzione, è possibile riprendere la risincronizzazione. A tale scopo, selezionare la macchina virtuale nel portale > Risincronizza.

    Risincronizzazione manuale

Logica di retry

Se si verifica un errore di replica, per impostazione predefinita viene effettuato un nuovo tentativo. Tale logica può essere classificata nelle due categorie seguenti:

Categoria Dettagli
Errori irreversibili Non viene eseguito alcun nuovo tentativo. Lo stato della macchina virtuale sarà Critico e sarà necessario l'intervento di un amministratore. Esempi di questi errori includono: catena VHD interrotta, stato non valido per la macchina virtuale di replica, errori di autenticazione di rete: errori di autorizzazione, errori di macchina virtuale non trovata (per i server Hyper-V autonomi).
Errori reversibili Vengono eseguiti nuovi tentativi durante ogni intervallo di replica usando un backoff esponenziale che permette di aumentare l'intervallo tra i tentativi dall'inizio del primo tentativo di 1, 2, 4, 8 e 10 minuti. Se l'errore persiste, viene eseguito un nuovo tentativo ogni 30 minuti. Alcuni esempi: errori di rete, errori di spazio su disco insufficiente, condizioni di memoria insufficiente.

Processo di failover e failback

  1. È possibile eseguire un failover pianificato o non pianificato dalle VM Hyper-V locali ad Azure. Se si esegue un failover pianificato, le macchine virtuali di origine vengono arrestate per assicurare che non si verifichino perdite di dati.
  2. È possibile effettuare il failover di un solo computer o creare piani di ripristino per orchestrare il failover di più computer.
  3. Dopo avere eseguito il failover, le VM di replica create verranno visualizzate in Azure. È possibile assegnare un indirizzo IP pubblico alla VM, se necessario.
  4. Si esegue quindi il commit del failover per avviare l'accesso al carico di lavoro dalla VM di Azure di replica.
  5. Quando il sito locale primario è di nuovo disponibile, è possibile effettuare il failback. Si avvia un failover pianificato da Azure al sito primario. Per un failover pianificato è possibile scegliere di effettuare il failback nella stessa VM o in una posizione alternativa e di sincronizzare le modifiche tra Azure e l'ambiente locale, per evitare perdite di dati. Quando le VMs vengono create in locale, si esegue il commit del failover.

Passaggi successivi

Rivedere la matrice di supporto