Migrazione e la modernizzazione: domande comuni

Questo articolo risponde a domande comuni sullo strumento Migrazione e modernizzazione. In caso di altre domande, controllare queste risorse:

• Domande generali su Azure Migrate
• Domande sull'appliance di Azure Migrate
• Domande su individuazione, valutazione e visualizzazione delle dipendenze
• Risposte alle domande nel forum di Azure Migrate

Domande generali

Quali sono le opzioni di migrazione in Migrazione e modernizzazione?

Lo strumento Migrazione e modernizzazione offre due opzioni per la migrazione dei server di origine e delle macchine virtuali ad Azure: migrazione senza agente e migrazione basata su agente.

Indipendentemente dall'opzione di migrazione scelta, il primo passaggio per eseguire la migrazione di un server tramite lo strumento Migrazione e modernizzazione consiste nell'avviare la replica per il server. Viene eseguita una replica iniziale dei dati della VM o del server in Azure. Al termine della replica iniziale, viene stabilita una replica in corso (sincronizzazione delta in corso) per eseguire la migrazione dei dati incrementali in Azure. Quando l'operazione raggiunge la fase di sincronizzazione differenziale, è possibile scegliere di eseguire la migrazione ad Azure in qualsiasi momento.

Ecco alcune considerazioni da tenere presenti durante la scelta dell'opzione di migrazione.

Le migrazioni senza agente non richiedono la distribuzione di software (agenti) nelle VM/server di origine di cui viene eseguita la migrazione. L'opzione senza agente orchestra la replica integrando con la funzionalità fornita dal provider di virtualizzazione. Le opzioni di replica senza agente sono disponibili per VM VMware e le VM Hyper-V.

Le migrazioni basate su agente richiedono l'installazione di software (agenti) di Azure Migrate nelle VM/computer di origine di cui eseguire la migrazione. L'opzione basata su agente non si basa sulla piattaforma di virtualizzazione per la funzionalità di replica. Pertanto, può essere usata con qualsiasi server che esegue un'architettura x86/x64 e una versione di un sistema operativo supportato dal metodo di replica basato su agente.

L'opzione di migrazione basata su agente può essere usata per VM VMware, VM Hyper-V, server fisici, VM in esecuzione in AWS, VM in esecuzione in GCP o VM in esecuzione in un provider di virtualizzazione differente. La migrazione basata su agente considera i computer come server fisici per la migrazione.

Sebbene la migrazione senza agente offra un'altra praticità e semplicità rispetto alle opzioni di replica basate su agente per gli scenari supportati (VMware e Hyper-V), è consigliabile prendere in considerazione l'uso dello scenario basato su agente per i casi d'uso seguenti:

• Ambiente vincolato di IOPS: la replica senza agente usa snapshot e usa operazioni di I/O al secondo/o larghezza di banda di archiviazione. È consigliabile usare il metodo di migrazione basato su agente se sono presenti vincoli per l'archiviazione o le operazioni di I/O al secondo nell'ambiente.
• Se non si ha un server vCenter, è possibile considerare le VM VMware come server fisici e usare il flusso di lavoro di migrazione basato su agente.

Per altre informazioni, vedere questo articolo per confrontare le opzioni di migrazione per le migrazioni VMware.

Quali aree geografiche sono supportate per la migrazione con Azure Migrate?

Esaminare le aree geografiche supportate per i cloud pubblico e per enti pubblici.

È possibile usare lo stesso progetto di Azure Migrate per eseguire la migrazione a più aree?

Anche se è possibile creare valutazioni per più aree in un progetto di Azure Migrate, è possibile usare un progetto di Azure Migrate per eseguire la migrazione dei server solo in un'area di Azure. È possibile creare altri progetti di Azure Migrate per ogni area a cui è necessario eseguire la migrazione.

• Per le migrazioni VMware senza agente, l'area di destinazione viene bloccata dopo aver abilitato la prima replica.
• Per le migrazioni basate su agente (VMware, server fisici e server di altri cloud), l'area di destinazione viene bloccata dopo aver selezionato il "pulsante Crea risorse" nel portale durante la configurazione dell'appliance di replica.
• Per le migrazioni Hyper-V senza agente, l'area di destinazione viene bloccata dopo aver selezionato il "pulsante Crea risorse" nel portale durante la configurazione del provider di replica Hyper-V.

È possibile usare lo stesso progetto di Azure Migrate per eseguire la migrazione a più sottoscrizioni?

Sì, è possibile eseguire la migrazione a più sottoscrizioni (stesso tenant di Azure) nella stessa area di destinazione per un progetto di Azure Migrate. È possibile selezionare la sottoscrizione di destinazione durante l'abilitazione della replica per un computer o un set di computer. L'area di destinazione è bloccata dopo la prima replica per le migrazioni VMware senza agente e durante l'installazione dell'appliance di replica e del provider Hyper-V per le migrazioni basate su agenti e le migrazioni Hyper-V senza agente rispettivamente.

Azure Migrate supporta Azure Resource Graph?

Attualmente Azure Migrate non è integrato con Azure Resource Graph. Supporta l'esecuzione di query correlate a ARG.

Come vengono trasmessi i dati dall'ambiente locale ad Azure? È crittografato prima della trasmissione?

L'appliance Azure Migrate nel caso di replica senza agente 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).

È possibile usare l'insieme di credenziali dei servizi di ripristino creato da Azure Migrate per gli scenari di ripristino di emergenza?

Non è consigliabile usare l'insieme di credenziali dei servizi di ripristino creato da Azure Migrate per gli scenari di ripristino di emergenza. In questo modo possono verificarsi errori di replica di avvio in Azure Migrate.

Qual è la differenza tra le operazioni Migrazione di test e Esegui migrazione?

La migrazione di test consente di testare e convalidare le migrazioni prima della migrazione effettiva. La migrazione dei test funziona consentendo di usare un ambiente sandbox in Azure per testare le macchine virtuali prima della migrazione effettiva. L'ambiente sandbox è delimitato da una rete virtuale di test specificata. L'operazione di migrazione dei test non causa interruzioni, a condizione che la rete virtuale di test sia sufficientemente isolata. La rete virtuale isolata significa che le regole di connessione in ingresso e in uscita sono progettate per evitare connessioni indesiderate. Ad esempio – la connessione ai computer locali è limitata.

Le applicazioni possono continuare a essere eseguite nell'origine, consentendo di eseguire test su una copia clonata in un ambiente sandbox isolato. È possibile eseguire diversi test, come necessario, per convalidare la migrazione, eseguire test delle app e risolvere eventuali problemi prima della migrazione effettiva.

È disponibile un'opzione di rollback per Azure Migrate?

È possibile usare l'opzione Migrazione di test per convalidare le funzionalità e le prestazioni dell'applicazione in Azure. È possibile eseguire un numero qualsiasi di migrazioni di test ed eseguire la migrazione finale dopo aver stabilito la confidenza tramite l'operazione di migrazione di test. Una migrazione di test non influisce sul computer locale, che rimane operativo e continua a effettuare repliche fino a quando non si esegue la migrazione effettiva. Se durante la il test di accettazione utente della migrazione di prova fossero presenti errori, è possibile scegliere di rinviare la migrazione finale e mantenere la VM/il server di origine in esecuzione e che effettua la replica a Azure. È possibile ripetere la migrazione finale dopo aver risolto gli errori. Nota: dopo aver eseguito una migrazione finale ad Azure e il computer di origine locale è stato arrestato, non è possibile eseguire un rollback da Azure all'ambiente locale.

È possibile selezionare la rete virtuale e la subnet da usare per le migrazioni di test?

È possibile selezionare una rete virtuale per le migrazioni di test. La subnet viene selezionata automaticamente in base alla logica seguente:

• Se una subnet di destinazione (diversa dall'impostazione predefinita) è stata specificata come input durante l'abilitazione della replica, Azure Migrate assegna priorità all'uso di una subnet con lo stesso nome nella rete virtuale selezionata per la migrazione di test.
• Se la subnet con lo stesso nome non viene trovata, Azure Migrate seleziona la prima subnet disponibile alfabeticamente che non è un gateway/gateway applicazione/firewall/subnet Bastion.

Perché il pulsante Migrazione di test è disabilitato per il server?

Il pulsante di migrazione di test potrebbe trovarsi in uno stato disabilitato negli scenari seguenti:

• Non è possibile avviare una migrazione di test fino al completamento di una replica iniziale per la VM. Il pulsante di migrazione dei test verrà disabilitato fino al completamento del processo di integrazione. È possibile eseguire una migrazione di test dopo che la VM è in una fase di sincronizzazione differenziale.
• È possibile disabilitare il pulsante se è già stata completata una migrazione di test, ma non è stata eseguita una pulizia della migrazione di test per tale VM. Eseguire una pulizia della migrazione di test e ripetere l'operazione.

Cosa accade se non si pulisce la migrazione di test?

La migrazione di test simula la migrazione effettiva creando una VM di Azure di test usando i dati replicati. Il server verrà distribuito con una copia temporizzato dei dati replicati nel gruppo di risorse di destinazione (selezionato durante l'abilitazione della replica) con un suffisso "-test" . Le migrazioni di test sono destinate alla convalida delle funzionalità del server in modo che i problemi post-migrazione vengano ridotti al minimo. Se la migrazione di test non viene pulita dopo il test, la macchina virtuale di test continuerà a essere eseguita in Azure e comporta addebiti. Per eseguire la pulizia dopo una migrazione di test, passare alla visualizzazione Computer di replica nello strumento Migrazione e modernizzazione e usare l'azione "pulizia della migrazione dei test" nel computer.

Come si stabilisce se la migrazione della VM è riuscita?

Dopo aver eseguito correttamente la migrazione della VM o del server, è possibile visualizzare e gestire la VM dalla pagina Macchine virtuali. Connettersi alla VM di cui è stata eseguita la migrazione per verificare. In alternativa, è possibile esaminare lo ‘stato' del processo per verificare se la migrazione è stata completata correttamente. Se vengono visualizzati errori, risolverli e ripetere l'operazione di migrazione.

Cosa accade se non si arresta la replica dopo la migrazione?

Quando si arresta la replica, lo strumento Migrazione e modernizzazione pulisce i dischi gestiti nella sottoscrizione creata per la replica.

Cosa accade se la migrazione non viene completata dopo la migrazione?

Al termine della migrazione, lo strumento Migrazione e modernizzazione pulisce i dischi gestiti nella sottoscrizione creata per la replica. Se non si seleziona Completare la migrazione dopo una migrazione, si continuerà a incorrere in addebiti per questi dischi. La migrazione completa non influirà sui dischi collegati ai computer di cui è già stata eseguita la migrazione.

Come si effettua la migrazione dei computer basati su UEFI a Azure come VM di prima generazione di Azure?

Lo strumento Migrazione e modernizzazione esegue la migrazione di computer basati su UEFI in Azure come VM di seconda generazione di Azure. Se si desidera eseguirne la migrazione in VM di prima generazione di Azure, convertire il tipo di avvio in BIOS prima di avviare la replica e quindi usare lo strumento Migrazione e modernizzazione per eseguire la migrazione ad Azure.

Azure Migrate converte i computer basati su UEFI in computer basati su BIOS ed esegue la migrazione ad Azure come VM di prima generazione di Azure?

Lo strumento Migrazione e modernizzazione esegue la migrazione di tutti i computer basati su UEFI in Azure come VM di seconda generazione di Azure. Non è più supportata la conversione di VM basate su UEFI in VM basate su BIOS. Tutti i computer basati su BIOS vengono migrati in Azure solo come VM di prima generazione di Azure.

Quali sistemi operativi sono supportati per la migrazione di computer basati su UEFI ad Azure?

È possibile eseguire la migrazione di controller di dominio Active Directory usando Azure Migrate?

Lo strumento Migrazione e modernizzazione è indipendente dall'applicazione e funziona per la maggior parte delle applicazioni. Quando si esegue la migrazione di un server usando lo strumento Migrazione e modernizzazione, viene eseguita la migrazione di tutte le applicazioni installate nel server. Tuttavia, per alcune applicazioni, metodi di migrazione alternativi diversi da Migrazione e modernizzazione possono essere più adatti per la migrazione. Per Active Directory, se gli ambienti ibridi in cui il sito locale è connesso all'ambiente Azure, è possibile estendere directory in Azure aggiungendo controller di dominio aggiuntivi in Azure e configurando la replica di Active Directory. Se si esegue la migrazione in un ambiente isolato in Azure che richiede controller di dominio propri (o test di applicazioni in un ambiente sandbox), è possibile eseguire la migrazione dei server usando lo strumento Migrazione e modernizzazione.

È possibile aggiornare il sistema operativo durante la migrazione?

Lo strumento di migrazione e modernizzazione supporta ora l'aggiornamento del sistema operativo Windows durante la migrazione. Per Linux questa opzione non è attualmente disponibile. Altre informazioni sull'aggiornamento del sistema operativo Windows.

È necessario VMware vCenter per eseguire la migrazione di VM VMware?

Per eseguire la migrazione di VM VMware usando la migrazione basata sull'agente VMware o senza agente, gli host ESXi in cui si trovano le VM devono essere gestiti dal server vCenter. Se il server vCenter non è disponibile, è possibile eseguire la migrazione di VM VMware eseguendo la migrazione come server fisici. Altre informazioni.

È possibile consolidare più VM di origine in una VM durante la migrazione?

Le funzionalità di migrazione e modernizzazione supportano attualmente solo le migrazioni like-for-like. Non è supportato il consolidamento dei server come parte della migrazione.

Windows Server 2008 e 2008 R2 saranno supportati in Azure dopo la migrazione?

È possibile eseguire la migrazione dei server Windows Server 2008 e 2008 R2 locali alle macchine virtuali di Azure e ottenere gli aggiornamenti della sicurezza estesi per tre anni dopo la data di fine del supporto senza costi aggiuntivi oltre il costo di esecuzione della macchina virtuale. È possibile usare lo strumento Migrazione e modernizzazione per eseguire la migrazione dei carichi di lavoro di Windows Server 2008 e 2008 R2.

Come si esegue la migrazione di Windows Server 2003 in esecuzione in VMware/Hyper-V in Azure?

Supporto esteso di Windows Server 2003 terminato il 14 luglio 2015. Il team di supporto di Azure continua a contribuire alla risoluzione dei problemi relativi all'esecuzione di Windows Server 2003 in Azure. Tuttavia, questo supporto è limitato a problemi che non richiedono la risoluzione dei problemi a livello di sistema operativo o patch. La migrazione delle applicazioni alle istanze di Azure che eseguono una versione più recente di Windows Server è l'approccio consigliato per assicurarsi di usare in modo efficace la flessibilità e l'affidabilità del cloud di Azure.

Tuttavia, se si sceglie di eseguire la migrazione di Windows Server 2003 ad Azure, è possibile usare lo strumento Migrazione e modernizzazione se Windows Server è una VM in esecuzione in VMware o Hyper-V Esaminare questo articolo per preparare i computer Windows Server 2003 per la migrazione.

Migrazione VMware senza agente

Come funziona la migrazione senza agente?

Lo strumento Migrazione e modernizzazione offre opzioni di replica senza agente per la migrazione di macchine virtuali VMware e macchine virtuali Hyper-V con installato Windows o Linux. Lo strumento offre anche un'altra opzione di replica basata su agente per i server Windows e Linux che possono essere usati per eseguire la migrazione di server fisici e macchine virtuali x86/x64 in VMware, Hyper-V, AWS, GCP e così via. L'opzione di replica basata su agente richiede l'installazione del software agente nel server o nella macchina virtuale di cui viene eseguita la migrazione, mentre nell'opzione senza agente non è necessario installare software nelle macchine virtuali stesse, offrendo così maggiore praticità e semplicità rispetto all'opzione di replica basata su agente.

L'opzione di replica senza agente funziona usando meccanismi forniti dal provider di virtualizzazione (VMware, Hyper-V). Nel caso di macchine virtuali VMware, il meccanismo di replica senza agente usa gli snapshot delle VMware e la tecnologia di rilevamento dei blocchi modificati VMware per replicare i dati dai dischi delle macchine virtuali. Questo meccanismo è simile a quello usato da molti prodotti di backup. Nel caso di macchine virtuali Hyper-V, il meccanismo di replica senza agente usa gli snapshot delle VM e la funzionalità di rilevamento delle modifiche della replica Hyper-V per replicare i dati dai dischi delle macchine virtuali.

Quando la replica è configurata per una VM, viene prima eseguita una fase di replica iniziale. Durante la replica iniziale, viene creato uno snapshot della VM e viene replicata una copia completa dei dati dai dischi snapshot nei dischi gestiti nella sottoscrizione. 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 che hanno avuto luogo dopo l'ultimo ciclo di replica completato vengono replicate e applicate periodicamente ai dischi gestiti di replica, mantenendo così la replica sincronizzata con le modifiche apportate nella VM. Nel caso di macchine virtuali VMware, viene usata la tecnologia di rilevamento dei blocchi modificati di VMware 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. In questo modo è necessario replicare solo i dati modificati dopo l'ultimo ciclo di replica completato per mantenere sincronizzata la replica per la VM. Alla fine di ogni ciclo di replica, viene rilasciato lo snapshot e viene eseguito il consolidamento degli snapshot per la macchina virtuale. Analogamente, nel caso di macchine virtuali Hyper-V, il motore di rilevamento delle modifiche della replica Hyper-V viene usato per tenere traccia delle modifiche tra cicli di replica consecutivi.

Quando si esegue l'operazione di migrazione in una macchina virtuale di replica, è possibile arrestare la macchina virtuale locale ed eseguire una replica incrementale finale per garantire una perdita di dati pari a zero. Durante l'esecuzione della migrazione, i dischi gestiti di replica corrispondenti alla macchina virtuale vengono usati per creare la macchina virtuale in Azure.

Per iniziare, vedere l'esercitazione su migrazione senza agente VMware e migrazione senza agente Hyper-V.

Come è possibile misurare il requisito di larghezza di banda per le migrazioni?

La larghezza di banda per la replica dei dati in Azure dipende da una serie di fattori ed è una funzione della velocità con cui l'appliance di Azure Migrate locale è in grado di leggere e replicare i dati in Azure. La replica ha due fasi: replica iniziale e replica differenziale.

All'avvio della replica per una VM, viene eseguito un ciclo di replica iniziale, in cui vengono replicate copie complete dei dischi. Al termine della replica iniziale, vengono pianificati cicli di replica incrementali (cicli delta) periodicamente per trasferire le modifiche che sono state introdotte dopo il ciclo di replica precedente.

È possibile risolvere il requisito di larghezza di banda in base al volume di dati necessario per essere spostati nell'onda e nel tempo entro i quali si desidera completare la replica iniziale (idealmente si desidera che la replica iniziale sia stata completata almeno 3-4 giorni prima della finestra di migrazione effettiva per offrire tempo sufficiente per eseguire una migrazione di test prima della finestra effettiva e mantenere il tempo di inattività minimo durante la finestra).

È possibile stimare la larghezza di banda o il tempo necessario per la migrazione di macchine virtuali VMware senza agente usando la formula seguente:

Tempo necessario per completare la replica iniziale = {dimensioni dei dischi (o dimensioni usate, se disponibili) * 0,7 (presupponendo una stima conservativa media della compressione – del 30%)}/larghezza di banda disponibile per la replica.

Come si limita la replica usando l'appliance Azure Migrate per la replica VMware senza agente?

È possibile limitare l'uso di NetQosPolicy. Si noti che questa limitazione è applicabile solo alle connessioni in uscita dall'appliance di Azure Migrate. Ad esempio:

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

Per aumentare e ridurre la larghezza di banda della replica in base a una pianificazione, è possibile sfruttare le attività pianificate di Windows per ridimensionare la larghezza di banda in base alle esigenze. Un'attività verrà usata per ridurre la larghezza di banda e un'altra attività verrà usata per aumentare la larghezza di banda. Nota: è necessario creare NetQosPolicy, descritto in precedenza, prima di eseguire i comandi seguenti.

#Replace with an account part of the local Administrators group
$User = "localVmName\userName"

#Set the task names
$ThrottleBandwidthTask = "ThrottleBandwidth"
$IncreaseBandwidthTask = "IncreaseBandwidth"

#Create a directory to host PowerShell scaling scripts
if (!(Test-Path "C:\ReplicationBandwidthScripts"))
{
 New-Item -Path "C:\" -Name "ReplicationBandwidthScripts" -Type Directory
}

#Set your minimum bandwidth to be used during replication by changing the ThrottleRateActionBitsPerSecond parameter
#Currently set to 10 MBps
New-Item C:\ReplicationBandwidthScripts\ThrottleBandwidth.ps1
Set-Content C:\ReplicationBandwidthScripts\ThrottleBandwidth.ps1 'Set-NetQosPolicy -Name "ThrottleReplication" -ThrottleRateActionBitsPerSecond 10MB'
$ThrottleBandwidthScript = "C:\ReplicationBandwidthScripts\ThrottleBandwidth.ps1"

#Set your maximum bandwidth to be used during replication by changing the ThrottleRateActionBitsPerSecond parameter
#Currently set to 1000 MBps
New-Item C:\ReplicationBandwidthScripts\IncreaseBandwidth.ps1
Set-Content C:\ReplicationBandwidthScripts\IncreaseBandwidth.ps1 'Set-NetQosPolicy -Name "ThrottleReplication" -ThrottleRateActionBitsPerSecond 1000MB'
$IncreaseBandwidthScript = "C:\ReplicationBandwidthScripts\IncreaseBandwidth.ps1"

#Timezone set on the Azure Migrate Appliance (VM) will be used; change the frequency to meet your needs
#In this example, the bandwidth is being throttled every weekday at 8:00 AM local time
#The bandwidth is being increased every weekday at 6:00 PM local time
$ThrottleBandwidthTrigger = New-ScheduledTaskTrigger -Weekly -DaysOfWeek Monday,Tuesday,Wednesday,Thursday,Friday -At 8:00am
$IncreaseBandwidthTrigger = New-ScheduledTaskTrigger -Weekly -DaysOfWeek Monday,Tuesday,Wednesday,Thursday,Friday -At 6:00pm

#Setting the task action to execute the scripts
$ThrottleBandwidthAction = New-ScheduledTaskAction -Execute "PowerShell.exe" -Argument "-executionpolicy bypass -noprofile -file $ThrottleBandwidthScript"
$IncreaseBandwidthAction = New-ScheduledTaskAction -Execute "PowerShell.exe" -Argument "-executionpolicy bypass -noprofile -file $IncreaseBandwidthScript"

#Creating the Scheduled tasks
Register-ScheduledTask -TaskName $ThrottleBandwidthTask -Trigger $ThrottleBandwidthTrigger -User $User -Action $ThrottleBandwidthAction -RunLevel Highest -Force
Register-ScheduledTask -TaskName $IncreaseBandwidthTask -Trigger $IncreaseBandwidthTrigger -User $User -Action $IncreaseBandwidthAction -RunLevel Highest -Force

In che modo la frequenza di varianza influisce sulla replica senza agente?

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. Poiché si riduce al minimo la quantità di dati trasferiti, è possibile ridurre il più possibile i dati prima di pianificare il ciclo successivo.

Con quale frequenza viene pianificato un ciclo di replica?

La formula per pianificare il ciclo di replica successivo è (ora del ciclo precedente / 2) o un'ora, a qualsiasi livello superiore.

Ad esempio, se una VM richiede quattro ore per un ciclo differenziale, il ciclo successivo viene pianificato in due ore e non nell'ora successiva. Il processo è diverso immediatamente dopo la replica iniziale, quando il primo ciclo differenziale viene pianificato immediatamente.

Sono stati distribuiti due (o più) appliance per individuare le VM nel server vCenter. Tuttavia, quando si tenta di eseguire la migrazione delle VM, vengono visualizzate solo le VM che corrispondono a una delle appliance.

Se sono configurate più appliance, non devono esistere sovrapposizioni tra le VM negli account vCenter forniti. Un'individuazione con una sovrapposizione di questo tipo è uno scenario non supportato.

In che modo la replica senza agente influisce sui server VMware?

La replica senza agente comporta un impatto sulle prestazioni sugli host VMware vCenter Server e VMware ESXi. Poiché la replica senza agente usa snapshot, usa operazioni di I/O al secondo nell'archiviazione, quindi è necessaria una larghezza di banda di archiviazione di I/O al secondo. Non è consigliabile usare la replica senza agente se sono presenti vincoli di archiviazione o I/O nell'ambiente.

È possibile usare Azure Migrate per eseguire la migrazione delle app Web al servizio app di Azure?

È possibile eseguire la migrazione senza agente su larga scala di ASP.NET app Web in esecuzione su server Web IIS ospitati in un sistema operativo Windows in un ambiente VMware. Altre informazioni.

Migrazione basata su agente

Come è possibile eseguire la migrazione delle istanze di AWS EC2 ad Azure?

Vedere l'articolo per individuare, valutare ed eseguire la migrazione delle istanze EC2 di AWS in Azure.

Come funziona la migrazione basata su agente?

Oltre alle opzioni di migrazione senza agente per macchine virtuali VMware e macchine virtuali Hyper-V, lo strumento Migrazione e modernizzazione offre un'opzione di migrazione basata su agente per eseguire la migrazione di server Windows e Linux in esecuzione su server fisici o in esecuzione come macchine virtuali x86/x64 in VMware, Hyper-V, AWS, Google Cloud Platform e così via.

Il metodo di migrazione basato su agente usa il software agente installato nel server di cui viene eseguita la migrazione per replicare i dati del server in Azure. Il processo di replica usa un'architettura di offload in cui l'agente inoltra i dati di replica a un server di replica dedicato denominato appliance di replica o server di configurazione (o a un server di elaborazione di scale-out). Altre informazioni sul funzionamento dell'opzione di migrazione basata su agente.

Nota: l'appliance di replica è diversa dall'appliance di individuazione di Azure Migrate e deve essere installata in un computer separato/dedicato.

Dove è necessario installare l'appliance di replica per le migrazioni basate su agente?

L'appliance di replica deve essere installata in un computer dedicato. L'appliance di replica non deve essere installata in una macchina virtuale di origine che si desidera replicare o nell'appliance di Azure Migrate eventualmente (usata per l’individuazione e la valutazione) installata in precedenza. Vedere l'esercitazione per altri dettagli.

È possibile eseguire la migrazione di VM AWS che eseguono il sistema operativo Amazon Linux?

Non è possibile eseguire la migrazione di VM che eseguono Amazon Linux così come sono, perché il sistema operativo Amazon Linux è supportato solo in AWS. Per eseguire la migrazione dei carichi di lavoro in esecuzione in Amazon Linux, è possibile creare una macchina virtuale CentOS/RHEL in Azure ed eseguire la migrazione del carico di lavoro in esecuzione nel computer Linux AWS usando un approccio pertinente per la migrazione del carico di lavoro. A seconda del carico di lavoro, ad esempio, è possibile che siano disponibili strumenti specifici per il carico di lavoro per facilitare la migrazione, ad esempio per i database o gli strumenti di distribuzione nel caso di server Web.

Come è possibile misurare il requisito di larghezza di banda per le migrazioni?

La larghezza di banda per la replica dei dati in Azure dipende da una serie di fattori ed è una funzione della velocità con cui l'appliance di Azure Migrate locale è in grado di leggere e replicare i dati in Azure. La replica ha due fasi: replica iniziale e replica differenziale.

All'avvio della replica per una VM, viene eseguito un ciclo di replica iniziale, in cui vengono replicate copie complete dei dischi. Al termine della replica iniziale, vengono pianificati cicli di replica incrementali (cicli delta) periodicamente per trasferire le modifiche che sono state introdotte dopo il ciclo di replica precedente.

Per un metodo di replica basato su agente, Deployment Planner consente di profilarne l'ambiente per la varianza dei dati e di prevedere il requisito di larghezza di banda necessario. Per altre informazioni, vedere questo articolo

Migrazione Hyper-V senza agente

Come funziona la migrazione senza agente?

Lo strumento Migrazione e modernizzazione offre opzioni di replica senza agente per la migrazione di macchine virtuali VMware e macchine virtuali Hyper-V con installato Windows o Linux. Lo strumento offre anche un'altra opzione di replica basata su agente per i server Windows e Linux che possono essere usati per eseguire la migrazione di server fisici e macchine virtuali x86/x64 in VMware, Hyper-V, AWS, GCP e così via. L'opzione di replica basata su agente richiede l'installazione del software agente nel server o nella macchina virtuale di cui viene eseguita la migrazione, mentre nell'opzione senza agente non è necessario installare software nelle macchine virtuali stesse, offrendo così maggiore praticità e semplicità rispetto all'opzione di replica basata su agente.

L'opzione di replica senza agente funziona usando meccanismi forniti dal provider di virtualizzazione (VMware, Hyper-V). Nel caso di macchine virtuali Hyper-V, il meccanismo di replica senza agente usa gli snapshot delle VM e la funzionalità di rilevamento delle modifiche della replica Hyper-V per replicare i dati dai dischi delle macchine virtuali.

Quando la replica è configurata per una VM, viene prima eseguita una fase di replica iniziale. Durante la replica iniziale, viene creato uno snapshot della VM e viene replicata una copia completa dei dati dai dischi snapshot nei dischi gestiti nella sottoscrizione. 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 che hanno avuto luogo dopo l'ultimo ciclo di replica completato vengono replicate e applicate periodicamente ai dischi gestiti di replica, mantenendo così la replica sincronizzata con le modifiche apportate nella VM. Nel caso di macchine virtuali VMware, viene usata la tecnologia di rilevamento dei blocchi modificati di VMware 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. In questo modo è necessario replicare solo i dati modificati dopo l'ultimo ciclo di replica completato per mantenere sincronizzata la replica per la VM. Alla fine di ogni ciclo di replica, viene rilasciato lo snapshot e viene eseguito il consolidamento degli snapshot per la macchina virtuale. Analogamente, nel caso di macchine virtuali Hyper-V, il motore di rilevamento delle modifiche della replica Hyper-V viene usato per tenere traccia delle modifiche tra cicli di replica consecutivi.

Quando si esegue l'operazione di migrazione in una macchina virtuale di replica, è possibile arrestare la macchina virtuale locale ed eseguire una replica incrementale finale per garantire una perdita di dati pari a zero. Durante l'esecuzione della migrazione, i dischi gestiti di replica corrispondenti alla macchina virtuale vengono usati per creare la macchina virtuale in Azure.

Per iniziare, vedere l'esercitazione sulla migrazione senza agente Hyper-V.

Come è possibile misurare il requisito di larghezza di banda per le migrazioni?

La larghezza di banda per la replica dei dati in Azure dipende da una serie di fattori ed è una funzione della velocità con cui l'appliance di Azure Migrate locale è in grado di leggere e replicare i dati in Azure. La replica ha due fasi: replica iniziale e replica differenziale.

All'avvio della replica per una VM, viene eseguito un ciclo di replica iniziale, in cui vengono replicate copie complete dei dischi. Al termine della replica iniziale, vengono pianificati cicli di replica incrementali (cicli delta) periodicamente per trasferire le modifiche che sono state introdotte dopo il ciclo di replica precedente.

È possibile risolvere il requisito di larghezza di banda in base al volume di dati necessario per essere spostati nell'onda e nel tempo entro i quali si desidera completare la replica iniziale (idealmente si desidera che la replica iniziale sia stata completata almeno 3-4 giorni prima della finestra di migrazione effettiva per offrire tempo sufficiente per eseguire una migrazione di test prima della finestra effettiva e mantenere il tempo di inattività minimo durante la finestra).

Passaggi successivi

Altre informazioni sulla migrazione delle VM VMware, delle VM Hyper-V e dei server fisici.