Migrazione e modernizzazione: domande comuni

Attenzione

Questo articolo fa riferimento a CentOS, una distribuzione Linux vicina allo stato end of life (EOL). Prendere in considerazione l'uso e la pianificazione di conseguenza. Per altre informazioni, vedere le linee guida per la fine della vita di CentOS.

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

• Domande generali su Azure Migrate
• Domande sull'appliance di Azure Migrate
• Domande sull'individuazione , la valutazione e la 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 di 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 macchina virtuale o del server in Azure. Al termine della replica iniziale, viene stabilita una replica in corso (sincronizzazione differenziale 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 macchine virtuali/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 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/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 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 macchine virtuali VMware, macchine virtuali Hyper-V, server fisici, macchine virtuali in esecuzione in AWS, macchine virtuali in esecuzione in GCP o macchine virtuali in esecuzione in un provider di virtualizzazione diverso. 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 macchine virtuali 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 agenti (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.

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. Inoltre, 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 di migrazione dei test e 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 più test, in base alle esigenze, 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 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 la replica fino a quando non si esegue la migrazione effettiva. Se si sono verificati errori durante l'autenticazione definita dall'utente di 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 è 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 un Rete virtuale per le migrazioni di test. La subnet viene selezionata automaticamente in base alla logica seguente:

• Se una subnet di destinazione (diversa da quella predefinita) è stata specificata come input durante l'abilitazione della replica, Azure Migrate assegna le priorità usando 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 in ordine alfabetico che non è una subnet Gateway/gateway applicazione/Firewall/Bastion.

Perché il pulsante Migrazione 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 finché non viene completata una replica iniziale per la macchina virtuale. Il pulsante di migrazione dei test verrà disabilitato fino al completamento del processo di integrazione. È possibile eseguire una migrazione di test dopo che la macchina virtuale è in una fase di sincronizzazione differenziale.
• Il pulsante può essere disabilitato se è già stata completata una migrazione di test, 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?

La migrazione di test simula la migrazione effettiva creando una macchina virtuale 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.

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

Dopo aver eseguito correttamente la migrazione della macchina virtuale o del server, è possibile visualizzare e gestire la macchina virtuale 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 di migrazione e modernizzazione pulisce i dischi gestiti nella sottoscrizione creata per la replica.

Cosa accade se non si completa la migrazione dopo la migrazione?

Al termine della 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 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 è possibile eseguire la migrazione di computer basati su UEFI in Azure come macchine virtuali 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 in macchine virtuali 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 macchine virtuali 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 macchine virtuali basate su UEFI in macchine virtuali 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?

Sistemi operativi supportati per i computer basati su UEFI	Da VMware senza agente ad Azure	Da Hyper-V senza agente ad Azure	VMware, fisico e altri cloud basati su agente in Azure
Windows Server 2019, 2016, 2012 R2, 2012	S	Y	S
Windows 10 Pro, Windows 10 Enterprise	S	Y	S
SUSE Linux Enterprise Server 15 SP1	S	Y	S
SUSE Linux Enterprise Server 12 SP4	S	Y	S
Ubuntu Server 16.04, 18.04, 19.04, 19.10	S	Y	S
RHEL 8.1, 8.0, 7.8, 7.7, 7.6, 7.5, 7.4, 7.0, 6.x	S	Y	S
Cent OS 8.1, 8.0, 7.7, 7.6, 7.5, 7.4, 6.x	S	Y	S
Oracle Linux 7.7, 7.7-CI	S	Y	S

È possibile eseguire la migrazione di controller di dominio 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, 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 migrazione e modernizzazione supporta attualmente solo le migrazioni like-for-like. Lo strumento non supporta l'aggiornamento della versione del sistema operativo durante la migrazione. Il computer migrato avrà lo stesso sistema operativo del computer di origine.

È necessario VMware vCenter per eseguire la migrazione di macchine virtuali VMware?

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

È possibile consolidare più macchine virtuali di origine in una macchina virtuale durante la migrazione?

Le funzionalità di migrazione e modernizzazione supportano attualmente migrazioni di tipo like. Non è supportato il consolidamento dei server o l'aggiornamento del sistema operativo 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 i Aggiornamenti di sicurezza estesa per tre anni dopo le date 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.

Ricerca per categorie eseguire la migrazione di Windows Server 2003 in esecuzione in VMware/Hyper-V in Azure?

Il supporto esteso di Windows Server 2003 è terminato il 14 luglio 2015. Il team supporto tecnico 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 macchina virtuale 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 di migrazione e modernizzazione offre opzioni di replica senza agente per la migrazione di macchine virtuali VMware e macchine virtuali Hyper-V che eseguono 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 snapshot VMware e la tecnologia di rilevamento dei blocchi modificati da 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 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, 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. Al termine della replica iniziale per la macchina virtuale, il processo di replica passa a una fase di replica incrementale (replica differenziale). Nella fase di replica incrementale, le modifiche ai dati che si sono verificate dopo l'ultimo ciclo di replica completato vengono replicate e applicate periodicamente ai dischi gestiti di replica, mantenendo quindi la replica sincronizzata con le modifiche apportate nella macchina virtuale. 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 macchina virtuale 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 macchina virtuale. 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 le esercitazioni sulla migrazione senza agente VMware e sulla migrazione senza agente hyper-V.

Ricerca per categorie 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 può leggere e replicare i dati in Azure. La replica ha due fasi: replica iniziale e replica differenziale.

All'avvio della replica per una macchina virtuale, si verifica 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 al volume di dati necessario per essere spostati nell'onda e nel tempo entro il quale si desidera completare la replica iniziale (idealmente si vuole 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 media di compressione del 30% - stima conservativa)}/larghezza di banda disponibile per la replica.

Ricerca per categorie la replica a limitazione nell'uso dell'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 si riduce nei dati, il modello di varianza è più importante della varianza. Quando un file viene scritto nuovamente e di nuovo, la frequenza non ha un impatto significativo. Tuttavia, un modello in cui ogni altro settore viene scritto causa una varianza 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 macchina virtuale 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 macchine virtuali nel server vCenter. Tuttavia, quando si tenta di eseguire la migrazione delle macchine virtuali, vengono visualizzate solo le macchine virtuali corrispondenti a una delle appliance.

Se sono configurate più appliance, non è necessaria alcuna sovrapposizione 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 sono presenti vincoli di archiviazione o I/O nell'ambiente.

È possibile usare Azure Migrate per eseguire la migrazione delle app Web al servizio app 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 di AWS EC2 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 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 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 con scalabilità orizzontale). 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 un computer di origine che si vuole replicare o nell'appliance di Azure Migrate (usata per l'individuazione e la valutazione) che potrebbe essere stata installata in precedenza. Per altri dettagli, seguire l'esercitazione.

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

Ricerca per categorie 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 può leggere e replicare i dati in Azure. La replica ha due fasi: replica iniziale e replica differenziale.

All'avvio della replica per una macchina virtuale, si verifica 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, 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 di 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 macchine virtuali Hyper-V che eseguono Windows o Linux. Lo strumento offre anche un'opzione di replica aggiuntiva basata su agente per i server Windows e Linux che possono essere usati per eseguire la migrazione di server fisici, nonché 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 dell'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 quindi maggiore praticità e semplicità sull'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 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, 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. Al termine della replica iniziale per la macchina virtuale, il processo di replica passa a una fase di replica incrementale (replica differenziale). Nella fase di replica incrementale, le modifiche ai dati che si sono verificate dopo l'ultimo ciclo di replica completato vengono replicate e applicate periodicamente ai dischi gestiti di replica, mantenendo quindi la replica sincronizzata con le modifiche apportate nella macchina virtuale. 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 macchina virtuale 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 macchina virtuale. 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.

Ricerca per categorie 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 può leggere e replicare i dati in Azure. La replica ha due fasi: replica iniziale e replica differenziale.

All'avvio della replica per una macchina virtuale, si verifica 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 al volume di dati necessario per essere spostati nell'onda e nel tempo entro il quale si desidera completare la replica iniziale (idealmente si vuole 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

Leggere la panoramica di Azure Migrate.