Architettura di migrazione senza agente

Questo articolo descrive i concetti di replica durante la migrazione di macchine virtuali VMware usando il metodo di migrazione senza agente dello strumento di migrazione e modernizzazione.

Processo di replica

L'opzione di replica senza agente funziona usando snapshot VMware e la tecnologia CBT (Changed Block Tracking) di VMware per replicare i dati dai dischi delle macchine virtuali. Il diagramma a blocchi seguente illustra vari passaggi necessari quando si esegue la migrazione delle macchine virtuali usando lo strumento di migrazione e modernizzazione.

Quando la replica è configurata per una VM, viene prima eseguita una fase di replica iniziale. Durante la replica iniziale, viene creato uno snapshot della macchina virtuale e viene replicata una copia completa dei dati dai dischi snapshot nei dischi gestiti nella sottoscrizione di destinazione.

Al termine della replica iniziale per la VM, il processo di replica passa a una fase di replica incrementale (replica delta). Nella fase di replica incrementale, le modifiche ai dati apportate dall'inizio dell'ultimo ciclo di replica completato vengono replicate e scritte nei dischi gestiti di replica, mantenendo quindi la replica sincronizzata con le modifiche apportate nella macchina virtuale.

La tecnologia CBT (Changed Block Tracking) di VMware viene usata per tenere traccia delle modifiche tra i cicli di replica. All'inizio del ciclo di replica viene creato uno snapshot della VM e viene usato il rilevamento dei blocchi modificati per ottenere le modifiche tra lo snapshot corrente e l'ultimo snapshot replicato correttamente. Solo i dati modificati dopo il ciclo di replica completato precedente vengono replicati per mantenere sincronizzata la replica per la macchina virtuale. Alla fine di ogni ciclo di replica, viene rilasciato lo snapshot e viene eseguito il consolidamento degli snapshot per la macchina virtuale.

Quando si esegue l'operazione di migrazione in una macchina virtuale di replica, è presente un ciclo di replica differenziale su richiesta che replica le modifiche rimanenti dall'ultimo ciclo di replica. Al termine del ciclo su richiesta, i dischi gestiti di replica corrispondenti alla macchina virtuale vengono usati per creare la macchina virtuale in Azure. Prima di attivare la migrazione/failover, è necessario arrestare la macchina virtuale locale. L'arresto della macchina virtuale garantisce una perdita di dati pari a zero durante la migrazione.

Al termine della migrazione e l'avvio della macchina virtuale in Azure, assicurarsi di arrestare la replica della macchina virtuale. L'arresto della replica eliminerà i dischi intermedi (dischi di inizializzazione) creati durante la replica dei dati ed è anche possibile evitare di incorrere in costi aggiuntivi associati alle transazioni di archiviazione su questi dischi.

Cicli di replica

Nota

Assicurarsi di verificare la presenza di snapshot presenti da tentativi di replica precedenti o da altre app di terze parti. Non è possibile abilitare il rilevamento delle modifiche nella macchina virtuale se gli snapshot sono già presenti per la macchina virtuale. Eliminare gli snapshot esistenti o abilitare il rilevamento dei blocchi di modifiche nella macchina virtuale.

I cicli di replica fanno riferimento al processo periodico di trasferimento dei dati dall'ambiente locale ai dischi gestiti di Azure. Un ciclo di replica completo è costituito dai passaggi seguenti:

1. Creare uno snapshot VMware per ogni disco associato alla macchina virtuale
2. Caricare i dati nell'account di archiviazione di log in Azure
3. Snapshot della versione
4. Consolidare i dischi VMware

Si dice che un ciclo venga completato una volta consolidati i dischi.

Componenti coinvolti nella replica

Componenti locali: l'appliance Azure Migrate include i componenti seguenti responsabili della replica

• Agente dra
• Agente gateway

Componenti di Azure: la tabella seguente riepiloga i vari elementi di Azure creati durante l'uso del metodo senza agente della migrazione di macchine virtuali VMware.

Componente	Paese	Abbonamento	Descrizione
Insieme di credenziali di Servizi di ripristino	Area del progetto di Azure Migrate	Sottoscrizione del progetto di Azure Migrate	Usato per orchestrare la replica dei dati
Bus di servizio	Area di destinazione	Sottoscrizione del progetto di Azure Migrate	Usato per la comunicazione tra il servizio cloud e l'appliance di Azure Migrate
Account di archiviazione log	Area di destinazione	Sottoscrizione del progetto di Azure Migrate	Usato per archiviare i dati di replica, letti dal servizio e applicati sul disco gestito del cliente
Account di archiviazione del gateway	Area di destinazione	Sottoscrizione del progetto di Azure Migrate	Usato per archiviare gli stati del computer durante la replica
Vault delle chiavi	Area di destinazione	Sottoscrizione del progetto di Azure Migrate	Gestisce stringa di connessione per il bus di servizio e le chiavi di accesso per l'account di archiviazione log
Macchina virtuale di Azure	Area di destinazione	Sottoscrizione di destinazione	Macchina virtuale creata in Azure durante la migrazione
Dischi gestiti di Azure	Area di destinazione	Sottoscrizione di destinazione	Dischi gestiti collegati alle macchine virtuali di Azure
Schede di interfaccia di rete	Area di destinazione	Sottoscrizione di destinazione	Schede di interfaccia di rete collegate alle macchine virtuali create in Azure

Autorizzazioni obbligatorie

Quando si avvia la replica per la prima volta, all'utente connesso devono essere assegnati i ruoli seguenti:

• Proprietario o Collaboratore e Amministratore accesso utenti nel gruppo di risorse del progetto Azure Migrate e nel gruppo di risorse di destinazione

Per le repliche successive, all'utente connesso devono essere assegnati i ruoli seguenti:

• Proprietario o Collaboratore nel gruppo di risorse del progetto di Azure Migrate e nel gruppo di risorse di destinazione

Oltre ai ruoli descritti in precedenza, l'utente connesso deve disporre dell'autorizzazione seguente a livello di sottoscrizione - Microsoft.Resources/subscriptions/resourceGroups/read

Integrità dei dati

Esistono due fasi in ogni ciclo di replica che garantisce l'integrità dei dati tra il disco locale (disco di origine) e il disco di replica in Azure (disco di destinazione).

1. Prima di tutto, viene verificato se ogni settore modificato nel disco di origine viene replicato nel disco di destinazione. La convalida viene eseguita usando bitmap. Il disco di origine è suddiviso in settori di 512 byte. Ogni settore nel disco di origine viene mappato a un bit nella bitmap. All'avvio della replica dei dati, la bitmap viene creata per tutti i blocchi modificati (in ciclo differenziale) nel disco di origine che deve essere replicato. Analogamente, quando i dati vengono trasferiti al disco di Azure di destinazione, viene creata una bitmap. Al termine del trasferimento dei dati, il servizio cloud confronta le due bitmap per assicurarsi che non venga perso alcun blocco modificato. In caso di mancata corrispondenza tra le bitmap, il ciclo viene considerato non riuscito. Poiché ogni ciclo viene risincronizzazione, la mancata corrispondenza verrà risolta nel ciclo successivo.

2. Assicurarsi quindi che i dati trasferiti ai dischi di Azure corrispondano ai dati replicati dai dischi di origine. Ogni blocco modificato caricato viene compresso e crittografato prima che venga scritto come BLOB nell'account di archiviazione log. Il checksum di questo blocco viene calcolato prima della compressione. Questo checksum viene archiviato come metadati insieme ai dati compressi. Al momento della decompressione, il checksum per i dati viene calcolato e confrontato con il checksum calcolato nell'ambiente di origine. In caso di mancata corrispondenza, i dati non sono scritti nei dischi di Azure e il ciclo viene considerato non riuscito. Poiché ogni ciclo viene risincronizzazione, la mancata corrispondenza verrà risolta nel ciclo successivo.

Sicurezza

L'appliance di Azure Migrate comprime i dati e crittografa prima del caricamento. I dati vengono trasmessi tramite un canale di comunicazione sicuro tramite https e usano TLS 1.2 o versione successiva. Archiviazione di Azure crittografa automaticamente i dati quando vengono salvati in modo permanente nel cloud (crittografia dei dati inattivi).

Stato della replica

Quando una macchina virtuale viene sottoposta a replica (copia dei dati), esistono alcuni stati possibili:

• Replica iniziale in coda: la macchina virtuale viene accodata per la replica (o la migrazione) perché potrebbero essere presenti altre macchine virtuali che usano le risorse locali (durante la replica o la migrazione). Una volta liberate le risorse, questa macchina virtuale verrà elaborata.
• Replica iniziale in corso: la macchina virtuale è in fase di pianificazione per la replica iniziale.
• Replica iniziale: la macchina virtuale è in fase di replica iniziale. Quando la macchina virtuale è in fase di replica iniziale, non è possibile procedere con la migrazione e la migrazione dei test. È possibile arrestare la replica solo in questa fase.
• Replica iniziale (x%): la replica iniziale è attiva e ha registrato un avanzamento di x%.
• Sincronizzazione differenziale: la macchina virtuale potrebbe essere sottoposta a un ciclo di replica differenziale che replica la varianza dei dati rimanenti dall'ultimo ciclo di replica.
• Sospensione in corso: la macchina virtuale è in fase di ciclo di replica differenziale attiva e verrà sospesa in un determinato periodo di tempo.
• Sospeso: i cicli di replica sono stati sospesi. I cicli di replica possono essere ripresi eseguendo un'operazione di replica di ripresa.
• Riprendi in coda: la macchina virtuale viene accodata per riprendere la replica perché sono presenti altre macchine virtuali che attualmente usano le risorse locali.
• Ripresa in corso (x%): il ciclo di replica viene ripreso per la macchina virtuale ed è stato registrato di x%.
• Arrestare la replica in corso: la pulizia della replica è in corso. Quando si arresta la replica, i dischi gestiti intermedi (dischi di inizializzazione) creati durante la replica verranno eliminati. Altre informazioni.
• Completare la migrazione in corso: la pulizia della migrazione è in corso. Al termine della migrazione, i dischi gestiti intermedi (dischi di inizializzazione) creati durante la replica verranno eliminati. Altre informazioni.
• – : quando la macchina virtuale è stata eseguita correttamente la migrazione e/o quando è stata arrestata la replica, lo stato diventa "-". Una volta interrotta la replica/completata la migrazione e l'operazione viene completata correttamente, la macchina virtuale verrà rimossa dall'elenco dei computer di replica. È possibile trovare la macchina virtuale nella scheda Macchine virtuali nella procedura guidata di replica.

Altri stati

• Replica iniziale non riuscita: non è stato possibile copiare i dati iniziali per la macchina virtuale. Seguire le indicazioni per la correzione per risolvere.
• Ripristino in sospeso: si è verificato un problema nel ciclo di replica. È possibile selezionare il collegamento per comprendere le possibili cause e le azioni da correggere (se applicabile). Se si è scelto di ripristinare automaticamente la replica selezionando Sì quando è stata attivata la replica della macchina virtuale, lo strumento tenterà di ripristinarlo automaticamente. In caso contrario, selezionare la macchina virtuale e selezionare Ripristina replica. Se non si è scelto di ripristinare automaticamente la replica o se il passaggio precedente non funziona, arrestare la replica per la macchina virtuale, reimpostare il rilevamento dei blocchi modificati nella macchina virtuale e quindi riconfigurare la replica.
• Ripristino della replica in coda: la macchina virtuale viene accodata per il ripristino della replica perché sono presenti altre macchine virtuali che usano le risorse locali. Una volta liberate le risorse, la macchina virtuale verrà elaborata per la replica di ripristino.
• Risincronizzazione (x%): la macchina virtuale è in fase di risincronizzazione dei dati. Ciò può verificarsi se si è verificato un problema o una mancata corrispondenza durante la replica dei dati.
• Arresto della replica/migrazione completata non riuscita: selezionare il collegamento per comprendere le possibili cause dell'errore e delle azioni da correggere (se applicabile).

Nota

Alcune macchine virtuali vengono inserite nello stato in coda per garantire un impatto minimo sull'ambiente di origine a causa del consumo di operazioni di I/O al secondo di archiviazione. Queste macchine virtuali vengono elaborate in base alla logica di pianificazione, come descritto nella sezione successiva.

Stato della migrazione/test della migrazione

• Migrazione di test in sospeso: la macchina virtuale è in fase di replica differenziale ed è ora possibile eseguire la migrazione di test (o migrazione).
• Pulizia della migrazione dei test in sospeso: al termine della migrazione dei test, eseguire una pulizia della migrazione di test per evitare addebiti in Azure.
• Pronto per la migrazione: la macchina virtuale è pronta per la migrazione ad Azure.
• Migrazione in coda: la macchina virtuale viene accodata per la migrazione perché sono presenti altre macchine virtuali che usano le risorse locali durante la replica (o la migrazione). Una volta liberate le risorse, la macchina virtuale verrà elaborata.
• Migrazione di test/migrazione in corso: la macchina virtuale è in fase di migrazione/migrazione di test. È possibile selezionare il collegamento per controllare il processo di migrazione in corso.
• Data, timestamp: data/test della migrazione e timestamp della migrazione.
• –: la replica iniziale è in corso. È possibile eseguire una migrazione o un test dopo la transizione del processo di replica a una fase di sincronizzazione differenziale (replica incrementale).

Altri stati

• Completato con informazioni: il processo di migrazione/test della migrazione completato con le informazioni. È possibile selezionare il collegamento per controllare l'ultimo processo di migrazione per individuare possibili cause e azioni da correggere (se applicabile).
• Non riuscito: il processo di migrazione/test della migrazione non è riuscito. È possibile selezionare il collegamento per controllare l'ultimo processo di migrazione per individuare possibili cause e azioni da correggere.

Logica di pianificazione

La replica iniziale viene pianificata quando la replica è configurata per una macchina virtuale. È seguita dalle repliche incrementali (repliche differenziali).

I cicli di replica differenziale sono pianificati come segue:

• Il primo ciclo di replica differenziale viene pianificato immediatamente dopo il completamento del ciclo di replica iniziale
• I cicli di replica differenziale successivi sono pianificati in base alla logica seguente: min[max[1 ora, (tempo precedente del ciclo di replica differenziale/2)], 12 ore]

Ovvero, la replica differenziale successiva verrà pianificata non prima di un'ora e non oltre 12 ore. Ad esempio, se una macchina virtuale richiede quattro ore per un ciclo di replica differenziale, il ciclo di replica differenziale successivo viene pianificato in due ore e non nell'ora successiva.

Nota

La logica di pianificazione è diversa dopo il completamento della replica iniziale. Il primo ciclo differenziale viene pianificato immediatamente dopo il completamento della replica iniziale e i cicli successivi seguono la logica di pianificazione descritta in precedenza.

• Quando si attiva la migrazione, viene eseguito un ciclo di replica differenziale su richiesta (ciclo di replica differenziale di pre-failover) per la macchina virtuale prima della migrazione.

Definizione delle priorità delle macchine virtuali per varie fasi della replica

• Le repliche di macchine virtuali in corso hanno la priorità rispetto alle repliche pianificate (nuove repliche)
• Il ciclo di pre-failover (replica differenziale su richiesta) ha la priorità più alta seguita dal ciclo di replica iniziale. Il ciclo di replica differenziale ha la priorità minima.

Ovvero, ogni volta che viene attivata un'operazione di migrazione, il ciclo di replica su richiesta per la macchina virtuale è pianificato e altre repliche in corso prendono posto se sono in competizione per le risorse.

Vincoli:

Vengono usati i vincoli seguenti per assicurarsi che non vengano superati i limiti di operazioni di I/O al secondo per le reti SAN.

• Ogni appliance di Azure Migrate supporta la replica di 52 dischi in parallelo
• Ogni host ESXi supporta 8 dischi. Ogni host ESXi ha un buffer NFC di 32 MB. È quindi possibile pianificare 8 dischi nell'host (ogni disco richiede fino a 4 MB di buffer per il runtime di integrazione, ripristino di emergenza).
• Ogni archivio dati può avere un massimo di 15 snapshot del disco. L'unica eccezione si verifica quando a una macchina virtuale sono collegati più di 15 dischi.

Replica con scalabilità orizzontale

Azure Migrate supporta la replica simultanea di 500 macchine virtuali. Quando si prevede di replicare più di 300 macchine virtuali, è necessario distribuire un'appliance con scalabilità orizzontale. L'appliance con scalabilità orizzontale è simile a un'appliance primaria di Azure Migrate, ma è costituita solo dall'agente gateway per facilitare il trasferimento dei dati in Azure. Il diagramma seguente illustra il modo consigliato per usare l'appliance con scalabilità orizzontale.

È possibile distribuire l'appliance con scalabilità orizzontale in qualsiasi momento dopo aver configurato l'appliance primaria, ma non è necessaria fino a quando non sono presenti 300 macchine virtuali che eseguono la replica simultanea. Quando sono presenti 300 macchine virtuali che eseguono la replica simultanea, è necessario distribuire l'appliance con scalabilità orizzontale per continuare.

Arrestare la replica/Completare la migrazione

Quando si arresta la replica, i dischi gestiti intermedi (dischi di inizializzazione) creati durante la replica verranno eliminati. È possibile arrestare la replica solo durante una replica attiva. È possibile selezionare Completa migrazione per arrestare la replica dopo la migrazione della macchina virtuale.

La macchina virtuale per cui viene arrestata la replica può essere replicata abilitando di nuovo la replica. Se è stata eseguita la migrazione della macchina virtuale, è possibile riprendere la replica e la migrazione.

Come procedura consigliata, è consigliabile completare sempre la migrazione dopo che la macchina virtuale è stata eseguita correttamente in Azure per assicurarsi che non vengano addebitati costi aggiuntivi per le transazioni di archiviazione nei dischi gestiti intermedi (dischi di inizializzazione). In alcuni casi, si noterà che l'arresto della replica richiede tempo. Perché ogni volta che si arresta la replica, il ciclo di replica in corso viene completato (solo quando la macchina virtuale è sincronizzata delta) prima di eliminare gli artefatti.

Impatto della varianza

Si tenta di ridurre al minimo la quantità di trasferimento dei dati in ogni ciclo di replica consentendo ai dati di ridursi il più possibile prima di pianificare il ciclo successivo. Poiché la replica senza agente incorpora dati, il criterio di abbandono è più importante rispetto alla frequenza di abbandono. Quando un file viene scritto nuovamente e di nuovo, la frequenza non ha un impatto significativo. Tuttavia, un criterio in cui ogni altro settore viene scritto causa un abbandono elevata nel ciclo successivo.

Gestione della replica

Limitazione

È possibile aumentare o ridurre la larghezza di banda della replica usando NetQosPolicy. AppNamePrefix da usare in NetQosPolicy è "GatewayWindowsService.exe".

È possibile creare criteri nell'appliance di Azure Migrate per limitare il traffico di replica dall'appliance creando criteri come questo:

New-NetQosPolicy -Name "ThrottleReplication" -AppPathNameMatchCondition "GatewayWindowsService.exe" -ThrottleRateActionBitsPerSecond 1MB

Nota

Questo è applicabile a tutte le macchine virtuali di replica dall'appliance di Azure Migrate contemporaneamente.

È anche possibile aumentare e ridurre la larghezza di banda della replica in base a una pianificazione usando lo script di esempio.

Finestra Di black-out

Azure Migrate offre un meccanismo basato sulla configurazione tramite il quale i clienti possono specificare l'intervallo di tempo durante il quale non desiderano che le repliche procedano. Questo intervallo di tempo viene chiamato finestra di black-out. La necessità di una finestra di black-out può verificarsi in più scenari, ad esempio quando l'ambiente di origine è vincolato dalle risorse o quando i clienti vogliono che la replica venga eseguita solo durante l'orario non lavorativo e così via.

Nota

• I cicli di replica esistenti all'inizio della finestra di black-out verranno completati prima che la replica venga sospesa.
• Per qualsiasi migrazione avviata durante la finestra di black-out, la replica finale non verrà eseguita, causando l'esito negativo della migrazione.

È possibile specificare una finestra di black-out per l'appliance creando/aggiornando il file GatewayDataWorker.json in C:\ProgramData\Microsoft Azure\Config. Un file tipico sarà nel formato seguente:

{
    
    "BlackoutWindows": "List of blackout windows"
    
}

L'elenco delle finestre di black-out è una stringa delimitata "|" del formato "DayOfWeek; StartTime; Durata". La durata può essere specificata in giorni, ore e minuti. Ad esempio, le finestre di black-out possono essere specificate come:

{
    
    "BlackoutWindows": "Monday;7:00;7h | Tuesday;8:00;1d7h | Wednesday;16:00;1d | Thursday;18:00;5h | Friday;13:00;8m"
    
}

Il primo valore nell'esempio precedente indica una finestra di black-out che inizia ogni lunedì alle 7:00 ora locale (ora dell'appliance) e dura 7 ore.

Dopo aver creato o aggiornato il GatewayDataWorker.json con questi contenuti, è necessario riavviare il servizio gateway nell'appliance per rendere effettive queste modifiche.

Nello scenario di scalabilità orizzontale, l'appliance primaria e l'appliance con scalabilità orizzontale rispettano le finestre di black-out in modo indipendente. Come procedura consigliata, è consigliabile mantenere le finestre coerenti tra le appliance.

Passaggi successivi

Eseguire la migrazione di macchine virtuali VMware con migrazione senza agente.