Migrering och modernisering: Vanliga frågor
Varning
Den här artikeln refererar till CentOS, en Linux-distribution som har statusen End Of Life (EOL). Överväg att använda och planera i enlighet med detta. Mer information finns i CentOS End Of Life-vägledningen.
Den här artikeln besvarar vanliga frågor om migrerings- och moderniseringsverktyget. Om du har andra frågor kontrollerar du dessa resurser:
- Allmänna frågor om Azure Migrate
- Frågor om Azure Migrate-installationen
- Frågor om identifiering, utvärdering och beroendevisualisering
- Få svar på frågor i Azure Migrate-forumet
Allmänna frågor
Vilka är migreringsalternativen i Migrering och modernisering?
Migrerings- och moderniseringsverktyget erbjuder två alternativ för att migrera källservrar och virtuella datorer till Azure: agentlös migrering och agentbaserad migrering.
Oavsett vilket migreringsalternativ som valts är det första steget att migrera en server med hjälp av migrerings- och moderniseringsverktyget att starta replikeringen för servern. Detta utför en inledande replikering av dina vm-/serverdata till Azure. När den inledande replikeringen har slutförts upprättas en pågående replikering (pågående deltasynkronisering) för att migrera inkrementella data till Azure. När åtgärden når deltasynkroniseringssteget kan du välja att migrera till Azure när som helst.
Här följer några saker att tänka på när du bestämmer migreringsalternativet.
Agentlösa migreringar kräver inte att någon programvara (agenter) distribueras på de virtuella källdatorer/servrar som migreras. Det agentlösa alternativet orkestrerar replikeringen genom att integrera med de funktioner som tillhandahålls av virtualiseringsprovidern. Alternativen för agentlös replikering är tillgängliga för virtuella VMware-datorer och virtuella Hyper-V-datorer.
Agentbaserade migreringar kräver att Azure Migrate-programvara (agenter) installeras på de virtuella källdatorerna/datorerna som ska migreras. Det agentbaserade alternativet förlitar sig inte på virtualiseringsplattformen för replikeringsfunktionen. Därför kan den användas med valfri server som kör en x86/x64-arkitektur och en version av ett operativsystem som stöds av den agentbaserade replikeringsmetoden.
Agentbaserat migreringsalternativ kan användas för virtuella VMware-datorer, virtuella Hyper-V-datorer, fysiska servrar, virtuella datorer som körs på AWS, virtuella datorer som körs på GCP eller virtuella datorer som körs på en annan virtualiseringsprovider. Den agentbaserade migreringen behandlar dina datorer som fysiska servrar för migrering.
Även om den agentlösa migreringen ger en annan bekvämlighet och enkelhet jämfört med agentbaserade replikeringsalternativ för de scenarier som stöds (VMware och Hyper-V), kanske du vill överväga att använda det agentbaserade scenariot för följande användningsfall:
- IOPS-begränsad miljö: Agentlös replikering använder ögonblicksbilder och förbrukar lagrings-IOPS/bandbredd. Vi rekommenderar den agentbaserade migreringsmetoden om det finns begränsningar för lagring/IOPS i din miljö.
- Om du inte har en vCenter-server kan du behandla dina virtuella VMware-datorer som fysiska servrar och använda det agentbaserade migreringsarbetsflödet.
Mer information finns i den här artikeln om du vill jämföra migreringsalternativ för VMware-migreringar.
Vilka geografiska områden stöds för migrering med Azure Migrate?
Granska de geografiska områden som stöds för offentliga moln och myndighetsmoln.
Kan jag använda samma Azure Migrate-projekt för att migrera till flera regioner?
Du kan skapa utvärderingar för flera regioner i ett Azure Migrate-projekt, men ett Azure Migrate-projekt kan endast användas för att migrera servrar till en Azure-region. Du kan skapa ytterligare Azure Migrate-projekt för varje region som du behöver migrera till.
- För agentlösa VMware-migreringar låses målregionen när du aktiverar den första replikeringen.
- För agentbaserade migreringar (VMware, fysiska servrar och servrar från andra moln) låses målregionen när knappen "Skapa resurser" har valts på portalen när replikeringsinstallationen konfigureras.
- För agentlösa Hyper-V-migreringar låses målregionen när knappen "Skapa resurser" har valts på portalen när du konfigurerar Hyper-V-replikeringsprovidern.
Kan jag använda samma Azure Migrate-projekt för att migrera till flera prenumerationer?
Ja, du kan migrera till flera prenumerationer (samma Azure-klientorganisation) i samma målregion för ett Azure Migrate-projekt. Du kan välja målprenumerationen när du aktiverar replikering för en dator eller en uppsättning datorer. Målregionen är låst efter den första replikeringen för agentlösa VMware-migreringar och under replikeringsinstallationen och Installationen av Hyper-V-providern för agentbaserade migreringar respektive agentlösa Hyper-V-migreringar.
Hur överförs data från en lokal miljö till Azure? Krypteras den före överföring?
Azure Migrate-installationen i det agentlösa replikeringsfallet komprimerar data och krypterar innan den laddas upp. Data överförs via en säker kommunikationskanal via https och använder TLS 1.2 eller senare. Dessutom krypterar Azure Storage dina data automatiskt när de sparas i molnet (kryptering i vila).
Kan jag använda Recovery Services-valvet som skapats av Azure Migrate för haveriberedskapsscenarier?
Vi rekommenderar inte att du använder Recovery Services-valvet som skapats av Azure Migrate för haveriberedskapsscenarier. Detta kan leda till startreplikeringsfel i Azure Migrate.
Vad är skillnaden mellan testmigrering och migreringsåtgärder?
Testmigrering är ett sätt att testa och validera migreringar före den faktiska migreringen. Testmigrering fungerar genom att du kan använda en sandbox-miljö i Azure för att testa de virtuella datorerna före den faktiska migreringen. Sandbox-miljön avgränsas av ett virtuellt testnätverk som du anger. Testmigreringsåtgärden är icke-störande, förutsatt att det virtuella testnätverket är tillräckligt isolerat. Isolerat virtuellt nätverk innebär att reglerna för inkommande och utgående anslutning är utformade för att undvika oönskade anslutningar. Till exempel är anslutningen till lokala datorer begränsad.
Programmen kan fortsätta att köras vid källan samtidigt som du kan utföra tester på en klonad kopia i en isolerad sandbox-miljö. Du kan utföra flera tester efter behov för att verifiera migreringen, utföra apptestning och åtgärda eventuella problem före den faktiska migreringen.
Finns det ett återställningsalternativ för Azure Migrate?
Du kan använda alternativet Testmigrering för att verifiera programmets funktioner och prestanda i Azure. Du kan utföra valfritt antal testmigreringar och köra den slutliga migreringen efter att ha etablerat förtroende genom testmigreringsåtgärden. En testmigrering påverkar inte den lokala datorn, som förblir i drift och fortsätter att replikera tills du utför den faktiska migreringen. Om det uppstod några fel under testmigreringen av UAT kan du välja att skjuta upp den slutliga migreringen och hålla den virtuella källdatorn/servern igång och replikera till Azure. Du kan försöka utföra den slutliga migreringen igen när du har löst felen. Obs! När du har utfört en slutlig migrering till Azure och den lokala källdatorn stängdes av kan du inte utföra en återställning från Azure till din lokala miljö.
Kan jag välja det virtuella nätverk och undernät som ska användas för testmigreringar?
Du kan välja ett virtuellt nätverk för testmigreringar. Undernätet väljs automatiskt baserat på följande logik:
- Om ett målundernät (annat än standard) angavs som indata vid aktivering av replikering prioriterar Azure Migrate användningen av ett undernät med samma namn i det virtuella nätverk som valts för testmigreringen.
- Om undernätet med samma namn inte hittas väljer Azure Migrate det första undernätet som är tillgängligt alfabetiskt och som inte är ett gateway-/Application Gateway-/brandväggs-/Bastion-undernät.
Varför är knappen Testmigrering inaktiverad för min server?
Testmigreringsknappen kan vara i ett inaktiverat tillstånd i följande scenarier:
- Du kan inte påbörja en testmigrering förrän en inledande replikering (IR) har slutförts för den virtuella datorn. Knappen för testmigrering inaktiveras tills IR-processen har slutförts. Du kan utföra en testmigrering när den virtuella datorn är i en deltasynkroniseringsfas.
- Knappen kan inaktiveras om en testmigrering redan har slutförts, men en rensning av testmigreringen utfördes inte för den virtuella datorn. Utför en testmigreringsrensning och försök utföra åtgärden igen.
Vad händer om jag inte rensar min testmigrering?
Testmigrering simulerar den faktiska migreringen genom att skapa en virtuell Azure-testdator med replikerade data. Servern distribueras med en tidpunktskopia av replikerade data till målresursgruppen (markerad när replikering aktiveras) med suffixet "-test". Testmigreringar är avsedda för validering av serverfunktioner så att problem efter migreringen minimeras. Om testmigreringen inte rensas efter testningen fortsätter den virtuella testdatorn att köras i Azure och debiteras. Om du vill rensa efter en testmigrering går du till vyn replikeringsdatorer i migrerings- och moderniseringsverktyget och använder åtgärden "rensningstestmigrering" på datorn.
Hur vet jag om min virtuella dator har migrerats?
När du har migrerat den virtuella datorn/servern kan du visa och hantera den virtuella datorn från sidan Virtuella datorer. Anslut till den migrerade virtuella datorn för att verifiera. Du kan också granska jobbstatusen för åtgärden för att kontrollera om migreringen har slutförts. Om du ser några fel löser du dem och försöker utföra migreringsåtgärden igen.
Vad händer om jag inte stoppar replikeringen efter migreringen?
När du stoppar replikeringen rensar migrerings- och moderniseringsverktyget de hanterade diskarna i prenumerationen som skapades för replikering.
Vad händer om jag inte slutför migreringen efter migreringen?
När du slutför migreringen rensar migrerings- och moderniseringsverktyget de hanterade diskarna i prenumerationen som skapades för replikering. Om du inte väljer Slutför migrering efter en migrering fortsätter du att debiteras för dessa diskar. Fullständig migrering påverkar inte de diskar som är anslutna till datorer som redan har migrerats.
Hur kan jag migrera UEFI-baserade datorer till Azure som virtuella Azure-datorer i generation 1?
Migrerings- och moderniseringsverktyget migrerar UEFI-baserade datorer till Azure som virtuella Azure-datorer i generation 2. Om du vill migrera dem till virtuella Azure generation 1-datorer konverterar du starttypen till BIOS innan du startar replikeringen och använder sedan verktyget Migrering och modernisering för att migrera till Azure.
Konverterar Azure Migrate UEFI-baserade datorer till BIOS-baserade datorer och migrerar dem till Azure som virtuella Azure-datorer i generation 1?
Migrerings- och moderniseringsverktyget migrerar alla UEFI-baserade datorer till Azure som virtuella Azure-datorer i generation 2. Vi stöder inte längre konvertering av UEFI-baserade virtuella datorer till BIOS-baserade virtuella datorer. Alla BIOS-baserade datorer migreras endast till Azure som virtuella Azure-datorer i generation 1.
Vilka operativsystem stöds för migrering av UEFI-baserade datorer till Azure?
| Operativsystem som stöds för UEFI-baserade datorer | Agentlös VMware till Azure | Agentlös Hyper-V till Azure | Agentbaserad VMware, fysiska moln och andra moln till Azure |
|---|---|---|---|
| Windows Server 2019, 2016, 2012 R2, 2012 | Y | Y | Y |
| Windows 10 Pro, Windows 10 Enterprise | Y | Y | Y |
| SUSE Linux Enterprise Server 15 SP1 | Y | Y | Y |
| SUSE Linux Enterprise Server 12 SP4 | Y | Y | Y |
| Ubuntu Server 16.04, 18.04, 19.04, 19.10 | Y | Y | Y |
| RHEL 8.1, 8.0, 7.8, 7.7, 7.6, 7.5, 7.4, 7.0, 6.x | Y | Y | Y |
| Cent OS 8.1, 8.0, 7.7, 7.6, 7.5, 7.4, 6.x | Y | Y | Y |
| Oracle Linux 7.7, 7.7-CI | Y | Y | Y |
Kan jag migrera Active Directory-domänkontrollanter med Hjälp av Azure Migrate?
Migrerings- och moderniseringsverktyget är programberoende och fungerar för de flesta program. När du migrerar en server med migrerings- och moderniseringsverktyget migreras alla program som är installerade på servern tillsammans med den. För vissa program kan dock alternativa migreringsmetoder som inte är migrering och modernisering vara bättre lämpade för migreringen. Om hybridmiljöer där den lokala platsen är ansluten till din Azure-miljö för Active Directory kan du utöka din katalog till Azure genom att lägga till extra domänkontrollanter i Azure och konfigurera Active Directory-replikering. Om du migrerar till en isolerad miljö i Azure som kräver egna domänkontrollanter (eller testar program i en sandbox-miljö) kan du migrera servrar med hjälp av migrerings- och moderniseringsverktyget.
Kan jag uppgradera mitt operativsystem när jag migrerar?
Migrerings- och moderniseringsverktyget stöder för närvarande bara liknande migreringar. Verktyget stöder inte uppgradering av os-versionen under migreringen. Den migrerade datorn har samma operativsystem som källdatorn.
Behöver jag VMware vCenter för att migrera virtuella VMware-datorer?
Om du vill migrera virtuella VMware-datorer med VMware-agentbaserad eller agentlös migrering måste ESXi-värdar där virtuella datorer finns hanteras av vCenter Server. Om du inte har vCenter Server kan du migrera virtuella VMware-datorer genom att migrera dem som fysiska servrar. Läs mer.
Kan jag konsolidera flera virtuella källdatorer till en virtuell dator när jag migrerar?
Migrerings- och moderniseringsfunktioner stöder för närvarande liknande migreringar. Vi stöder inte konsolidering av servrar eller uppgradering av operativsystemet som en del av migreringen.
Kommer Windows Server 2008 och 2008 R2 att stödjas i Azure efter migreringen?
Du kan migrera dina lokala Windows Server 2008- och 2008 R2-servrar till virtuella Azure-datorer och få utökade säkerhetsuppdateringar i tre år efter att supporten upphör utan extra kostnad utöver kostnaden för att köra den virtuella datorn. Du kan använda migrerings- och moderniseringsverktyget för att migrera dina Windows Server 2008- och 2008 R2-arbetsbelastningar.
Hur migrerar jag Windows Server 2003 som körs på VMware/Hyper-V till Azure?
Utökad support för Windows Server 2003 upphörde den 14 juli 2015. Azure-supportteamet fortsätter att hjälpa till med felsökningsproblem som rör körning av Windows Server 2003 på Azure. Det här stödet är dock begränsat till problem som inte kräver felsökning eller korrigeringar på os-nivå. Att migrera dina program till Azure-instanser som kör en nyare version av Windows Server är den rekommenderade metoden för att säkerställa att du effektivt använder flexibiliteten och tillförlitligheten i Azure-molnet.
Men om du fortfarande väljer att migrera Windows Server 2003 till Azure kan du använda migrerings- och moderniseringsverktyget om Windows Server är en virtuell dator som körs på VMware eller Hyper-V Granska den här artikeln för att förbereda dina Windows Server 2003-datorer för migrering.
Agentlös VMware-migrering
Hur fungerar agentlös migrering?
Migrerings- och moderniseringsverktyget tillhandahåller agentlösa replikeringsalternativ för migrering av virtuella VMware-datorer och virtuella Hyper-V-datorer som kör Windows eller Linux. Verktyget innehåller också ett annat agentbaserat replikeringsalternativ för Windows- och Linux-servrar som kan användas för att migrera fysiska servrar och virtuella x86/x64-datorer på VMware, Hyper-V, AWS, GCP osv. Det agentbaserade replikeringsalternativet kräver installation av agentprogramvara på den server/virtuella dator som migreras, medan ingen programvara behöver installeras på själva de virtuella datorerna i det agentlösa alternativet, vilket ger mer bekvämlighet och enkelhet jämfört med det agentbaserade replikeringsalternativet.
Det agentlösa replikeringsalternativet fungerar med hjälp av mekanismer som tillhandahålls av virtualiseringsprovidern (VMware, Hyper-V). När det gäller virtuella VMware-datorer använder den agentlösa replikeringsmekanismen VMware-ögonblicksbilder och VMware ändrade blockspårningstekniken för att replikera data från virtuella datordiskar. Den här mekanismen liknar den som används av många säkerhetskopieringsprodukter. När det gäller virtuella Hyper-V-datorer använder den agentlösa replikeringsmekanismen vm-ögonblicksbilder och funktionen för ändringsspårning för Hyper-V-repliken för att replikera data från virtuella datordiskar.
När replikeringen har konfigurerats för en virtuell dator genomgår den först en inledande replikeringsfas. Under den inledande replikeringen tas en ögonblicksbild av den virtuella datorn och en fullständig kopia av data från ögonblicksbilddiskarna replikeras till hanterade diskar i din prenumeration. När den inledande replikeringen för den virtuella datorn är klar övergår replikeringsprocessen till en inkrementell replikeringsfas (deltareplikering). I den inkrementella replikeringsfasen replikeras regelbundet dataändringar som har inträffat sedan den senaste slutförda replikeringscykeln och tillämpas på replikhanterade diskar, vilket håller replikeringen synkroniserad med ändringar som sker på den virtuella datorn. När det gäller virtuella VMware-datorer används VMware-teknik för ändring av blockspårning för att hålla reda på ändringar mellan replikeringscykler. I början av replikeringscykeln tas en ögonblicksbild av den virtuella datorn och ändringsblockspårning används för att hämta ändringarna mellan den aktuella ögonblicksbilden och den senast replikerade ögonblicksbilden. På så sätt behöver endast data som har ändrats sedan den senaste slutförda replikeringscykeln replikeras för att hålla replikeringen för den virtuella datorn synkroniserad. I slutet av varje replikeringscykel släpps ögonblicksbilden och ögonblicksbildskonsolideringen utförs för den virtuella datorn. När det gäller virtuella Hyper-V-datorer används på samma sätt hyper-V-replikändringsspårningsmotorn för att hålla reda på ändringar mellan efterföljande replikeringscykler.
När du utför migreringsåtgärden på en replikerande virtuell dator har du möjlighet att stänga av den lokala virtuella datorn och utföra en sista inkrementell replikering för att säkerställa noll dataförlust. Vid migreringen används replikhanterade diskar som motsvarar den virtuella datorn för att skapa den virtuella datorn i Azure.
Kom igång genom att läsa självstudierna för migrering utan VMware-agent och Hyper-V-agentlös migrering .
Hur mäter jag bandbreddskravet för mina migreringar?
Bandbredden för replikering av data till Azure beror på en mängd olika faktorer och är en funktion av hur snabbt den lokala Azure Migrate-installationen kan läsa och replikera data till Azure. Replikeringen har två faser: inledande replikering och deltareplikering.
När replikeringen startar för en virtuell dator inträffar en inledande replikeringscykel där fullständiga kopior av diskarna replikeras. När den inledande replikeringen har slutförts schemaläggs inkrementella replikeringscykler (deltacykler) regelbundet för att överföra eventuella ändringar som har inträffat sedan föregående replikeringscykel.
Du kan räkna ut bandbreddskravet baserat på mängden data som behövs för att flyttas i våg och tid inom vilken du vill att den inledande replikeringen ska slutföras (helst vill du att den inledande replikeringen ska ha slutförts minst 3–4 dagar före det faktiska migreringsfönstret för att ge dig tillräckligt med tid för att utföra en testmigrering före det faktiska fönstret och hålla stilleståndstiden till ett minimum under fönstret).
Du kan beräkna den bandbredd eller tid som krävs för migrering av virtuella VMware-datorer utan agent med hjälp av följande formel:
Tid att slutföra den inledande replikeringen = {storleken på diskar (eller använd storlek om det är tillgängligt) * 0,7 (förutsatt ett 30-procentigt komprimeringsmedelvärde – konservativ uppskattning)}/tillgänglig bandbredd för replikering.
Hur begränsar jag replikeringen med hjälp av Azure Migrate-installationen för agentlös VMware-replikering?
Du kan begränsa med NetQosPolicy. Observera att den här begränsningen endast gäller för utgående anslutningar från Azure Migrate-installationen. Till exempel:
AppNamePrefix som ska användas i NetQosPolicy är "GatewayWindowsService.exe". Du kan skapa en princip på Azure Migrate-installationen för att begränsa replikeringstrafiken från installationen genom att skapa en princip som den här:
New-NetQosPolicy -Name "ThrottleReplication" -AppPathNameMatchCondition "GatewayWindowsService.exe" -ThrottleRateActionBitsPerSecond 1MB
För att öka och minska replikeringsbandbredden baserat på ett schema kan du använda schemalagd Windows-aktivitet för att skala bandbredden efter behov. En uppgift används för att minska bandbredden och en annan uppgift används för att öka bandbredden. Obs! Du måste skapa NetQosPolicy, som beskrivs ovan, innan du kör kommandona nedan.
#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
Hur påverkar omsättningshastigheten agentlös replikering?
Eftersom agentlös replikering viks i data är churn-mönstret viktigare än omsättningshastigheten. När en fil skrivs om och om igen har hastigheten inte någon större inverkan. Ett mönster där alla andra sektorer skrivs orsakar dock hög omsättning i nästa cykel. Eftersom vi minimerar mängden data som vi överför tillåter vi att data viks så mycket som möjligt innan vi schemalägger nästa cykel.
Hur ofta schemaläggs en replikeringscykel?
Formeln för att schemalägga nästa replikeringscykel är (tidigare cykeltid/2) eller en timme, beroende på vilket som är högst.
Om en virtuell dator till exempel tar fyra timmar för en deltacykel schemaläggs nästa cykel om två timmar och inte under nästa timme. Processen skiljer sig omedelbart efter den inledande replikeringen, när den första deltacykeln schemaläggs omedelbart.
Jag har distribuerat två (eller flera) enheter för att identifiera virtuella datorer i min vCenter Server. Men när jag försöker migrera de virtuella datorerna ser jag bara virtuella datorer som motsvarar en av enheterna.
Om det finns flera installationer måste det inte finnas någon överlappning mellan de virtuella datorerna på de vCenter-konton som tillhandahålls. En identifiering med sådan överlappning är ett scenario som inte stöds.
Hur påverkar agentlös replikering VMware-servrar?
Agentlös replikering ger viss prestandapåverkan på VMware vCenter Server- och VMware ESXi-värdar. Eftersom agentlös replikering använder ögonblicksbilder förbrukar den IOPS på lagring, så viss IOPS-lagringsbandbredd krävs. Vi rekommenderar inte att du använder agentlös replikering om du har begränsningar för lagring eller IOPs i din miljö.
Kan jag använda Azure Migrate för att migrera mina webbappar till Azure App Service?
Du kan utföra en agentlös migrering i stor skala av ASP.NET webbappar som körs på IIS-webbservrar som finns i ett Windows-operativsystem i en VMware-miljö. Läs mer.
Agentbaserad migrering
Hur kan jag migrera mina AWS EC2-instanser till Azure?
Läs artikeln för att identifiera, utvärdera och migrera dina AWS EC2-instanser till Azure.
Hur fungerar agentbaserad migrering?
Förutom alternativ för agentlös migrering för virtuella VMware-datorer och virtuella Hyper-V-datorer tillhandahåller migrerings- och moderniseringsverktyget ett agentbaserat migreringsalternativ för att migrera Windows- och Linux-servrar som körs på fysiska servrar, eller som körs som virtuella x86/x64-datorer på VMware, Hyper-V, AWS, Google Cloud Platform osv.
Den agentbaserade migreringsmetoden använder agentprogramvara som är installerad på den server som migreras för att replikera serverdata till Azure. Replikeringsprocessen använder en avlastningsarkitektur där agenten vidarebefordrar replikeringsdata till en dedikerad replikeringsserver som kallas replikeringsinstallationen eller konfigurationsservern (eller till en skalbar processserver). Läs mer om hur det agentbaserade migreringsalternativet fungerar.
Obs! Replikeringsinstallationen skiljer sig från Azure Migrate-identifieringsinstallationen och måste installeras på en separat/dedikerad dator.
Var ska jag installera replikeringsinstallationen för agentbaserade migreringar?
Replikeringsinstallationen bör installeras på en dedikerad dator. Replikeringsinstallationen bör inte installeras på en källdator som du vill replikera eller på Azure Migrate-installationen (används för identifiering och utvärdering) som du kanske har installerat tidigare. Följ självstudien för mer information.
Kan jag migrera virtuella AWS-datorer som kör Amazon Linux-operativsystem?
Virtuella datorer som kör Amazon Linux kan inte migreras som de är eftersom Amazon Linux OS endast stöds på AWS. Om du vill migrera arbetsbelastningar som körs på Amazon Linux kan du starta en virtuell CentOS/RHEL-dator i Azure och migrera arbetsbelastningen som körs på AWS Linux-datorn med hjälp av en relevant migreringsmetod för arbetsbelastningar. Beroende på arbetsbelastningen kan det till exempel finnas arbetsbelastningsspecifika verktyg som underlättar migreringen, till exempel för databaser eller distributionsverktyg för webbservrar.
Hur mäter jag bandbreddskravet för mina migreringar?
Bandbredden för replikering av data till Azure beror på en mängd olika faktorer och är en funktion av hur snabbt den lokala Azure Migrate-installationen kan läsa och replikera data till Azure. Replikeringen har två faser: inledande replikering och deltareplikering.
När replikeringen startar för en virtuell dator inträffar en inledande replikeringscykel där fullständiga kopior av diskarna replikeras. När den inledande replikeringen har slutförts schemaläggs inkrementella replikeringscykler (deltacykler) regelbundet för att överföra eventuella ändringar som har inträffat sedan föregående replikeringscykel.
För en agentbaserad replikeringsmetod kan distributionshanteraren hjälpa till att profilera miljön för dataomsättningen och hjälpa till att förutsäga det nödvändiga bandbreddskravet. Mer information finns i den här artikeln
Agentlös Hyper-V-migrering
Hur fungerar agentlös migrering?
Migrerings- och moderniseringsverktyget tillhandahåller agentlösa replikeringsalternativ för migrering av virtuella VMware-datorer och virtuella Hyper-V-datorer som kör Windows eller Linux. Verktyget innehåller också ytterligare ett agentbaserat replikeringsalternativ för Windows- och Linux-servrar som kan användas för att migrera fysiska servrar, samt virtuella x86/x64-datorer på VMware, Hyper-V, AWS, GCP osv. Det agentbaserade replikeringsalternativet kräver installation av agentprogramvara på den server/virtuella dator som migreras, medan ingen programvara behöver installeras på själva de virtuella datorerna i det agentlösa alternativet, vilket ger ytterligare bekvämlighet och enkelhet jämfört med det agentbaserade replikeringsalternativet.
Det agentlösa replikeringsalternativet fungerar med hjälp av mekanismer som tillhandahålls av virtualiseringsprovidern (VMware, Hyper-V). När det gäller virtuella Hyper-V-datorer använder den agentlösa replikeringsmekanismen vm-ögonblicksbilder och funktionen för ändringsspårning för Hyper-V-repliken för att replikera data från virtuella datordiskar.
När replikeringen har konfigurerats för en virtuell dator genomgår den först en inledande replikeringsfas. Under den inledande replikeringen tas en ögonblicksbild av den virtuella datorn och en fullständig kopia av data från ögonblicksbilddiskarna replikeras till hanterade diskar i din prenumeration. När den inledande replikeringen för den virtuella datorn är klar övergår replikeringsprocessen till en inkrementell replikeringsfas (deltareplikering). I den inkrementella replikeringsfasen replikeras regelbundet dataändringar som har inträffat sedan den senaste slutförda replikeringscykeln och tillämpas på replikhanterade diskar, vilket håller replikeringen synkroniserad med ändringar som sker på den virtuella datorn. När det gäller virtuella VMware-datorer används VMware-teknik för ändring av blockspårning för att hålla reda på ändringar mellan replikeringscykler. I början av replikeringscykeln tas en ögonblicksbild av den virtuella datorn och ändringsblockspårning används för att hämta ändringarna mellan den aktuella ögonblicksbilden och den senast replikerade ögonblicksbilden. På så sätt behöver endast data som har ändrats sedan den senaste slutförda replikeringscykeln replikeras för att hålla replikeringen för den virtuella datorn synkroniserad. I slutet av varje replikeringscykel släpps ögonblicksbilden och ögonblicksbildskonsolideringen utförs för den virtuella datorn. När det gäller virtuella Hyper-V-datorer används på samma sätt hyper-V-replikändringsspårningsmotorn för att hålla reda på ändringar mellan efterföljande replikeringscykler.
När du utför migreringsåtgärden på en replikerande virtuell dator har du möjlighet att stänga av den lokala virtuella datorn och utföra en sista inkrementell replikering för att säkerställa noll dataförlust. Vid migreringen används replikhanterade diskar som motsvarar den virtuella datorn för att skapa den virtuella datorn i Azure.
Kom igång genom att läsa självstudien om agentlös Hyper-V-migrering .
Hur mäter jag bandbreddskravet för mina migreringar?
Bandbredden för replikering av data till Azure beror på en mängd olika faktorer och är en funktion av hur snabbt den lokala Azure Migrate-installationen kan läsa och replikera data till Azure. Replikeringen har två faser: inledande replikering och deltareplikering.
När replikeringen startar för en virtuell dator inträffar en inledande replikeringscykel där fullständiga kopior av diskarna replikeras. När den inledande replikeringen har slutförts schemaläggs inkrementella replikeringscykler (deltacykler) regelbundet för att överföra eventuella ändringar som har inträffat sedan föregående replikeringscykel.
Du kan räkna ut bandbreddskravet baserat på mängden data som behövs för att flyttas i våg och tid inom vilken du vill att den inledande replikeringen ska slutföras (helst vill du att den inledande replikeringen ska ha slutförts minst 3–4 dagar före det faktiska migreringsfönstret för att ge dig tillräckligt med tid för att utföra en testmigrering före det faktiska fönstret och hålla stilleståndstiden till ett minimum under fönstret).
Nästa steg
Feedback
Kommer snart: Under hela 2024 kommer vi att fasa ut GitHub-problem som feedbackmekanism för innehåll och ersätta det med ett nytt feedbacksystem. Mer information finns i: https://aka.ms/ContentUserFeedback.
Skicka och visa feedback för