Condividi tramite

Migrazione e la modernizzazione: domande comuni

  • Articolo

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

Attenzione

Questo articolo fa riferimento a CentOS, una distribuzione Linux con stato di fine vita. Prendere in considerazione l'uso e la pianificazione di conseguenza. Per altre informazioni, vedere le linee guida per la fine della vita di CentOS.

Domande generali

Quali sono le opzioni di migrazione con lo strumento di migrazione e modernizzazione?

Lo strumento di migrazione e modernizzazione offre la migrazione senza agente e basata su agente per eseguire la migrazione dei server di origine e delle macchine virtuali (VM) ad Azure.

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. Questo processo esegue una replica iniziale dei dati della macchina virtuale o del server in Azure. Al termine della replica iniziale, viene stabilita una replica in corso (sincronizzazione delta) che esegue la migrazione dei dati incrementali in Azure. Dopo che l'operazione raggiunge la fase di sincronizzazione differenziale, è possibile scegliere di eseguire la migrazione ad Azure in qualsiasi momento.

Prendere in considerazione le informazioni seguenti quando si decide quale opzione di migrazione usare.

Le migrazioni senza agente non richiedono la distribuzione di software (agenti) nelle macchine virtuali/server di origine di cui si sta eseguendo 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 macchine virtuali VMware e macchine virtuali Hyper-V.

Le migrazioni basate su agente richiedono l'installazione del software (agenti) di Azure Migrate nelle macchine virtuali di origine di cui si esegue la migrazione. L'opzione basata su agente non si basa sulla piattaforma di virtualizzazione per la funzionalità di replica. Può essere usato 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:

La migrazione basata su agente considera i computer come server fisici per la migrazione.

La migrazione senza agente offre maggiore praticità e semplicità rispetto alle opzioni di replica basate su agente per le macchine virtuali VMware e Hyper-V. Tuttavia, è possibile prendere in considerazione l'uso dello scenario basato su agente per i casi d'uso seguenti:

  • Ambienti vincolati dalle operazioni di input/output al secondo (IOPS): la replica senza agente usa snapshot e usa operazioni di I/O al secondo di archiviazione/larghezza di banda. È 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.

  • Nessun server vCenter: se non si dispone di un server vCenter, è possibile considerare le macchine virtuali VMware come server fisici e usare il flusso di lavoro di migrazione basato su agente.

Per altre informazioni, vedere Selezionare un'opzione di migrazione VMware.

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

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

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

Sebbene sia 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 a una sola area di Azure. È possibile creare altri progetti di Azure Migrate per altre aree.

  • Per le migrazioni VMware senza agente, l'area di destinazione viene bloccata quando si abilita la prima replica.
  • Per le migrazioni basate su agente (VMware, server fisici e server di altri cloud), l'area di destinazione viene bloccata quando si seleziona il pulsante Crea risorse nel portale quando si configura l'appliance di replica.
  • Per le migrazioni Hyper-V senza agente, l'area di destinazione viene bloccata quando si seleziona il pulsante Crea risorse nel portale quando si configura il provider di replica Hyper-V.

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

Sì, è possibile usare lo stesso progetto di Azure Migrate per eseguire la migrazione a più sottoscrizioni con lo stesso tenant di Azure nella stessa area di destinazione. È possibile selezionare la sottoscrizione di destinazione quando si abilita la replica per un computer o un set di computer.

L'area di destinazione è bloccata:

  • Dopo la prima replica per le migrazioni VMware senza agente.
  • Durante l'installazione dell'appliance di replica per le migrazioni basate su agente.
  • Durante l'installazione del provider Hyper-V per le migrazioni Hyper-V senza agente.

Azure Migrate supporta Azure Resource Graph?

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

Come vengono trasmessi i dati da un ambiente locale ad Azure? È crittografato prima della trasmissione?

Con la replica senza agente, l'appliance di Azure Migrate comprime e crittografa i dati prima di caricarli. I dati vengono trasmessi tramite un canale di comunicazione sicuro tramite https e usano TLS 1.2 o versione successiva. Inoltre, Archiviazione di Azure crittografa automaticamente i dati quando rende persistenti i dati 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, perché ciò può causare errori di replica di avvio in Azure Migrate.

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

L'opzione Migrazione 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. Una rete virtuale di test specificata demarca l'ambiente sandbox. L'operazione di migrazione dei test non è indipendente, purché la rete virtuale di test sia sufficientemente isolata. Una rete virtuale è sufficientemente isolata quando si progettano le regole di connessione in ingresso e in uscita per evitare connessioni indesiderate. Ad esempio: si limita la connessione ai computer locali.

Le applicazioni possono continuare a essere eseguite nell'origine mentre si eseguono 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.

Screenshot che mostra la differenza tra un test e una migrazione effettiva.

È disponibile un'opzione di rollback per Azure Migrate?

È possibile usare l'opzione Migrazione 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 dei test.

Una migrazione di test non influisce sul computer locale, che rimane operativo e continua la replica fino a quando non si esegue la migrazione effettiva. Se si verificano errori durante il test di accettazione dell'utente (UAT) per la migrazione di test, è possibile scegliere di posticipare la migrazione finale e mantenere in esecuzione la macchina virtuale o il server di origine e la replica in 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 viene 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. Azure Migrate seleziona automaticamente una subnet in base alla logica seguente:

  • Se si specifica una subnet di destinazione (diversa da quella predefinita) come input durante l'abilitazione della replica, Azure Migrate assegna la priorità a una subnet con lo stesso nome nella rete virtuale usata per la migrazione di test.
  • Se non viene trovata una subnet con lo stesso nome, Azure Migrate seleziona in ordine alfabetico la prima subnet disponibile che non è un gateway, un gateway applicazione, un firewall o una subnet di Azure Bastion.

Perché il pulsante Test Migration è disabilitato per il server?

Il pulsante Test Migration (Migrazione test) può essere disabilitato negli scenari seguenti:

  • Non è possibile avviare una migrazione di test finché non viene completata una replica iniziale per la macchina virtuale. Il pulsante Migrazione test è disabilitato fino al completamento del processo di replica iniziale. È possibile eseguire una migrazione di test dopo che la macchina virtuale è in una fase di sincronizzazione differenziale.
  • Il pulsante può essere disabilitato se una migrazione di test è già stata completata, ma non è stata eseguita una pulizia della migrazione di test per tale macchina virtuale. Eseguire una pulizia della migrazione di test e ripetere l'operazione.

Cosa accade se non si pulisce la migrazione di test?

Una migrazione di test simula la migrazione effettiva creando una macchina virtuale di Azure di test usando i dati replicati. Il server viene distribuito con una copia temporizzato dei dati replicati nel gruppo di risorse di destinazione (selezionato quando si abilita la replica) con un -test suffisso. Le migrazioni di test sono destinate a convalidare la funzionalità del server per ridurre al minimo i problemi post-migrazione.

Se la migrazione di test non viene pulita dopo il test, la macchina virtuale di test continua a essere eseguita in Azure e comporta addebiti. Per eseguire la pulizia dopo una migrazione di test, passare alla visualizzazione Replica di computer nello strumento Migrazione e modernizzazione e usare l'azione pulizia della migrazione dei test nel computer.

Ricerca per categorie sapere se è stata eseguita la migrazione della macchina virtuale?

Dopo aver eseguito correttamente la migrazione della macchina virtuale o del server, è possibile visualizzare e gestire la macchina virtuale dal riquadro Macchine virtuali. Connettersi alla VM di cui è stata eseguita la migrazione per verificare.

È anche possibile esaminare lo stato del processo per verificare se la migrazione è stata completata correttamente. Se vengono visualizzati errori, risolverli e quindi ripetere l'operazione di migrazione.

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

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

Cosa accade se non si seleziona Completa migrazione dopo una migrazione?

Quando si seleziona Completa migrazione, lo strumento di migrazione e modernizzazione pulisce i dischi gestiti nella sottoscrizione creata per la replica. Se non si seleziona Completa migrazione dopo una migrazione , si continuano a incorrere in addebiti per questi dischi. La migrazione completa non influisce 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 di migrazione e modernizzazione esegue la migrazione di computer basati su UEFI in Azure come macchine virtuali di seconda generazione di Azure. Se si vuole eseguirne la migrazione come macchine virtuali di prima generazione di Azure, convertire il tipo di avvio in BIOS prima di avviare la replica e quindi usare lo strumento di 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 di migrazione e modernizzazione esegue la migrazione di tutti i computer basati su UEFI in Azure come macchine virtuali 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 macchine virtuali di prima generazione di Azure.

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

Nota

Se è supportata una versione principale di un sistema operativo nella migrazione senza agente, tutte le versioni secondarie e i kernel sono supportati automaticamente.

Sistemi operativi supportati per i computer basati su UEFI VMware senza agente a Azure Hyper-V senza agente a Azure VMware, fisico e altri cloud basati su agente in Azure
Windows Server 2025, 2022, 2019, 2016, 2012 R2, 2012 S Y S
Windows 11 Pro, Windows 11 Enterprise S Y S
Windows 10 Pro, Windows 10 Enterprise S Y S
SUSE Linux Enterprise Server 15 SP1, SP2, SP3, SP4, SP5, SP6 S Y S
SUSE Linux Enterprise Server 12 SP4 S Y S
Ubuntu Server 22.04 LTS, 20.04 LTS, 18.04 LTS, 16.04 LTS S Y S
RHEL 9.x, 8.1, 8.0, 7.8, 7.7, 7.6, 7.5, 7.4, 7.0, 6.x S Y S
Flusso CentOS S Y S
Oracle Linux 9, 8, 7.7-CI, 7.7, 6 S Y S

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

Lo strumento di 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 di migrazione e modernizzazione , viene eseguita la migrazione di tutte le applicazioni installate nel server. Tuttavia, metodi di migrazione alternativi potrebbero essere più adatti per eseguire la migrazione di alcune applicazioni.

Per Active Directory, il tipo di ambiente può essere un fattore. In un ambiente ibrido con un sito locale connesso all'ambiente Azure, è possibile estendere la directory in Azure aggiungendo controller di dominio aggiuntivi e configurando la replica di Active Directory. È possibile usare lo strumento di migrazione e modernizzazione se si è:

  • Migrazione in un ambiente isolato in Azure che richiede controller di dominio specifici.
  • Test delle applicazioni in un ambiente sandbox.

È possibile aggiornare il sistema operativo durante la migrazione?

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

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

Per eseguire la migrazione di macchine virtuali VMware usando la migrazione basata su agente VMware o senza agente, il server vCenter deve gestire gli host ESXi in cui si trovano le macchine virtuali. Se il server vCenter non è disponibile, è possibile eseguire la migrazione di macchine virtuali VMware come server fisici. Altre informazioni.

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

Lo strumento di migrazione e modernizzazione supporta attualmente migrazioni simili. Non è supportato il consolidamento dei server durante la 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 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 supporto tecnico di Azure continua a risolvere i 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.

È consigliabile eseguire la migrazione delle applicazioni alle istanze di Azure che eseguono una versione più recente di Windows Server per assicurarsi di usare in modo efficace la flessibilità e l'affidabilità del cloud di Azure.

Se si sceglie ancora di eseguire la migrazione di Windows Server 2003 ad Azure, è possibile usare lo strumento di migrazione e modernizzazione se la distribuzione di Windows Server è una macchina virtuale in esecuzione in VMware o Hyper-V. Per altre informazioni, vedere Preparare i computer Windows Server 2003 per la migrazione.

Migrazione VMware senza agente

Come funziona la migrazione senza agente?

Lo strumento di migrazione e modernizzazione offre opzioni di replica senza agente per la migrazione di macchine virtuali VMware e Hyper-V che eseguono Windows o Linux. Lo strumento offre un'altra opzione di replica basata su agente per i server Windows e Linux. Questa altra opzione può essere usata per eseguire la migrazione di server fisici e macchine virtuali x86/x64 in provider come VMware, Hyper-V, AWS e GCP.

Per la replica basata su agente è necessario installare il software agente nella macchina virtuale o nel server di cui si sta eseguendo la migrazione. L'opzione senza agente non richiede l'installazione del software nelle macchine virtuali, che può offrire praticità e semplicità.

L'opzione di replica senza agente usa meccanismi forniti dal provider di virtualizzazione (VMware o Hyper-V). Per le macchine virtuali VMware, il meccanismo di replica senza agente usa snapshot VMware e la tecnologia di rilevamento dei blocchi modificati VMware per replicare i dati dai dischi delle macchine virtuali. Molti prodotti di backup usano un meccanismo simile. Per le macchine virtuali Hyper-V, il meccanismo di replica senza agente usa snapshot di macchine virtuali 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 macchina virtuale, la macchina virtuale passa prima attraverso 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. Al termine della replica iniziale per la macchina virtuale, il processo di replica passa a una fase di replica incrementale (replica differenziale).

La fase di replica incrementale risolve tutte le modifiche ai dati apportate dopo l'ultimo ciclo di replica completato. Tali modifiche vengono replicate periodicamente e applicate ai dischi gestiti dalla replica. Questo processo mantiene la replica sincronizzata con le modifiche nella macchina virtuale.

La tecnologia di rilevamento dei blocchi modificati VMware tiene traccia delle modifiche tra i cicli di replica per le macchine virtuali VMware. All'inizio del ciclo di replica, viene creato uno snapshot della macchina virtuale e viene usato il rilevamento dei blocchi modificati per compilare le modifiche tra lo snapshot corrente e l'ultimo snapshot replicato correttamente. Per mantenere sincronizzata la replica per la macchina virtuale, è necessario replicare solo i dati modificati dopo l'ultimo ciclo di replica completato.

Alla fine di ogni ciclo di replica, lo snapshot viene rilasciato e il consolidamento degli snapshot viene eseguito per la macchina virtuale. Analogamente, per le macchine virtuali Hyper-V, il motore di rilevamento delle modifiche della replica Hyper-V tiene traccia delle modifiche tra cicli di replica consecutivi.

Quando si esegue l'operazione Migrate 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. Quando viene eseguita la replica, i dischi gestiti dalla replica che corrispondono alla macchina virtuale vengono usati per creare la macchina virtuale in Azure.

Per iniziare, vedere le esercitazioni sulla migrazione senza agente VMware e sulle migrazioni senza agente Hyper-V.

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

Una serie di fattori può influire sulla quantità di larghezza di banda che è necessario replicare i dati in Azure. Il requisito di larghezza di banda dipende dalla velocità con cui l'appliance di Azure Migrate locale può 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, i cicli di replica incrementali (cicli differenziali) vengono pianificati periodicamente per trasferire tutte le modifiche apportate dopo il ciclo di replica precedente.

È possibile risolvere il requisito di larghezza di banda in base a:

  • Volume di dati che è necessario spostare nell'onda.
  • Ora di allocazione per il processo di replica iniziale.

Idealmente, è consigliabile completare la replica iniziale almeno 3-4 giorni prima della finestra di migrazione effettiva. Questa sequenza temporale offre tempo sufficiente per eseguire una migrazione di test prima della finestra effettiva e mantenere il tempo di inattività durante la finestra fino a un minimo.

È 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.

Ricerca per categorie la replica di limitazione quando si usa l'appliance Azure Migrate per la replica VMware senza agente?

È possibile limitare la limitazione usando NetQosPolicy. Questo metodo di limitazione si applica solo alle connessioni in uscita dall'appliance di Azure Migrate.

Ad esempio, il AppNamePrefix valore 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 usare le attività pianificate di Windows per ridimensionare la larghezza di banda in base alle esigenze. Un'attività riduce la larghezza di banda e un'altra attività aumenta la larghezza di banda.

Nota

È necessario creare l'oggetto indicato NetQosPolicy in precedenza prima di eseguire i comandi seguenti.

#Replace with an account that's 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) is 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 è: (tempo 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. Ma quando si tenta di eseguire la migrazione delle macchine virtuali, vengono visualizzate solo le macchine virtuali che corrispondono a una delle appliance.

Se si configurano più appliance, non è possibile sovrapporsi tra le macchine virtuali 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 si hanno vincoli di archiviazione o operazioni di I/O al secondo nell'ambiente.

Le macchine virtuali spente possono essere replicate?

La replica di macchine virtuali VMware mentre sono spente è supportata, ma solo nell'approccio senza agente.

Importante

Non è possibile garantire che una macchina virtuale spenta venga avviata correttamente, perché non è possibile verificarne lo stato operativo prima della replica.

È consigliabile eseguire una migrazione di test per assicurarsi che tutto proceda senza problemi durante la migrazione effettiva. Questo metodo può essere utile quando il processo di replica iniziale è lungo o per macchine virtuali a varianza elevata, ad esempio i server di database o altri carichi di lavoro a elevato utilizzo di disco.

È 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 in 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 Individuare, valutare ed eseguire la migrazione di macchine virtuali Amazon Web Services (AWS) ad Azure.

Come funziona la migrazione basata su agente?

Lo strumento di 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 come macchine virtuali x86/x64 su provider come VMware, Hyper-V, AWS e GCP.

Il metodo di migrazione basato su agente usa il software agente per replicare i dati del server in Azure. Installare il software nel server di cui si sta eseguendo la migrazione. 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 con scalabilità orizzontale). Per altre informazioni, vedere Architettura della 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?

È necessario installare l'appliance di replica in un computer dedicato. Non è consigliabile installare l'appliance di replica in un computer di origine da replicare o nell'appliance di Azure Migrate usata per l'individuazione e la valutazione. Per altre informazioni, vedere Eseguire la migrazione di computer come server fisici in Azure .

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

Le macchine virtuali che eseguono Amazon Linux non possono essere migrate 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. È quindi possibile eseguire la migrazione del carico di lavoro eseguito nel computer AWS Linux usando un approccio di migrazione del carico di lavoro pertinente. A seconda del carico di lavoro, ad esempio, potrebbero essere disponibili strumenti specifici del carico di lavoro per facilitare la migrazione, ad esempio strumenti per i database o gli strumenti di distribuzione per i server Web.

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

Una serie di fattori può influire sulla quantità di larghezza di banda che è necessario replicare i dati in Azure. Il requisito di larghezza di banda dipende dalla velocità con cui l'appliance di Azure Migrate locale può 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, i cicli di replica incrementali (cicli differenziali) vengono pianificati periodicamente per trasferire tutte le modifiche apportate dopo il ciclo di replica precedente.

Per un metodo di replica basato su agente, Azure Site Recovery 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 Pianificare la distribuzione VMware.

Migrazione Hyper-V senza agente

Come funziona la migrazione senza agente?

Lo strumento di migrazione e modernizzazione offre opzioni di replica senza agente per la migrazione di macchine virtuali VMware e Hyper-V che eseguono Windows o Linux. Lo strumento offre un'altra opzione di replica basata su agente per i server Windows e Linux. Questa altra opzione può essere usata per eseguire la migrazione di server fisici e macchine virtuali x86/x64 in provider come VMware, Hyper-V, AWS e GCP.

L'opzione di replica basata su agente richiede l'installazione del software agente nella macchina virtuale o nel server di cui si sta eseguendo la migrazione. L'opzione senza agente non richiede l'installazione del software nelle macchine virtuali, che può offrire praticità e semplicità.

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

Quando la replica è configurata per una macchina virtuale, la macchina virtuale passa prima attraverso 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. Al termine della replica iniziale per la macchina virtuale, il processo di replica passa a una fase di replica incrementale (replica differenziale).

La fase di replica incrementale risolve tutte le modifiche ai dati apportate dopo l'ultimo ciclo di replica completato. Tali modifiche vengono replicate periodicamente e applicate ai dischi gestiti dalla replica. Questo processo mantiene la replica sincronizzata con le modifiche nella macchina virtuale.

La tecnologia di rilevamento dei blocchi modificati VMware viene usata per tenere traccia delle modifiche tra i cicli di replica per le macchine virtuali VMware. All'inizio del ciclo di replica, viene creato uno snapshot della macchina virtuale e viene usato il rilevamento dei blocchi modificati per ottenere le modifiche tra lo snapshot corrente e l'ultimo snapshot replicato correttamente. Per mantenere sincronizzata la replica per la macchina virtuale, è necessario replicare solo i dati modificati dopo l'ultimo ciclo di replica completato.

Alla fine di ogni ciclo di replica, lo snapshot viene rilasciato e il consolidamento degli snapshot viene eseguito per la macchina virtuale. Analogamente, per le 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 Migrate 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. I dischi gestiti da replica che corrispondono alla macchina virtuale vengono usati per creare la macchina virtuale in Azure.

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

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

Una serie di fattori può influire sulla quantità di larghezza di banda che è necessario replicare i dati in Azure. Il requisito di larghezza di banda dipende dalla velocità con cui l'appliance di Azure Migrate locale può 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, i cicli di replica incrementali (cicli differenziali) vengono pianificati periodicamente per trasferire tutte le modifiche apportate dopo il ciclo di replica precedente.

È possibile risolvere il requisito di larghezza di banda in base a:

  • Volume di dati che è necessario spostare nell'onda.
  • Ora di allocazione per il processo di replica iniziale.

Idealmente, è consigliabile completare la replica iniziale almeno 3-4 giorni prima della finestra di migrazione effettiva. Questa sequenza temporale offre tempo sufficiente per eseguire una migrazione di test prima della finestra effettiva e mantenere il tempo di inattività durante la finestra fino a un minimo.

Contenuto correlato