Migration und Modernisierung: Häufige Fragen

Dieser Artikel beantwortet häufige Fragen zum Migrations- und Modernisierungstool. Wenn Sie weitere Fragen haben, sehen Sie sich die folgenden Ressourcen an:

• Erhalten Sie allgemeine Informationen zu Azure Migrate.
• Lesen Sie häufig gestellte Fragen zur Azure Migrate Appliance.
• Erfahren Sie mehr über Ermittlung, Bewertung und Abhängigkeitsvisualisierung.
• Stellen Sie Fragen im Azure Migrate-Forum.

Achtung

Dieser Artikel bezieht sich auf CentOS, eine Linux-Distribution, die sich einen End-of-Life-Status aufweist. Sie sollten Ihre Nutzung entsprechend planen. Weitere Informationen finden Sie im End-of-Life-Leitfaden für CentOS.

Allgemeine Fragen

Welche Migrationsmöglichkeiten gibt es bei Migration und Modernisierung?

Das Tool Migration und Modernisierung bietet agentenlose und Agent-basierte Migration, um Ihre Quellserver und virtuellen Computer (VMs) zu Azure zu migrieren.

Unabhängig davon, welche Migrationsoption Sie auswählen, besteht der erste Schritt zum Migrieren eines Servers mithilfe des Migration und Modernisierung Tools darin, die Replikation für den Server zu starten. Dieser Prozess führt eine anfängliche Replikation ihrer VM/Serverdaten in Azure durch. Nachdem die anfängliche Replikation abgeschlossen wurde, wird eine fortlaufende Replikation (Deltasynchronisierung) zum Migrieren von inkrementellen Daten zu Azure eingerichtet. Nachdem der Vorgang die Deltasynchronisierungsphase erreicht hat, können Sie jederzeit zu Azure migrieren.

Berücksichtigen Sie die folgenden Informationen, wenn Sie entscheiden, welche Migrationsoption verwendet werden soll.

Agentenlose Migrationen erfordern keine Bereitstellung von Software (Agents) auf den Quell-VMs/Servern, die Sie migrieren. Die Option ohne Agent orchestriert die Replikation durch Integration in die vom Virtualisierungsanbieter bereitgestellte Funktionalität.

Replikationsoptionen ohne Agent sind für VMware-VMs und Hyper-V-VMs verfügbar.

Agent-basierte Migrationen erfordern, dass Sie Azure Migrate-Software (Agents) auf den Quell-VMs installieren, die Sie migrieren. Die Agent-basierte Option ist nicht auf die Virtualisierungsplattform für die Replikationsfunktion angewiesen. Sie kann mit jedem Server verwendet werden, auf dem eine x86/x64-Architektur ausgeführt wird, und einer Version eines Betriebssystems, das von der Agent-basierten Replikationsmethode unterstützt wird.

Die Agent-basierte Migrationsoption kann für Folgendes verwendet werden:

• Virtuelle VMware-Computer
• Virtuelle Hyper-V-Computer
• Physische Server
• VMs, die auf AWSausgeführt werden.
• VMs, die auf GCP ausgeführt werden.
• VMs, die auf einem anderen Virtualisierungsanbieter ausgeführt werden.

Bei der Agent-basierten Migration werden Ihre Computer für die Migration als physische Server behandelt.

Die agentenlose Migration bietet mehr Komfort und Einfachheit als Agent-basierte Replikationsoptionen für VMware und Hyper-V-VMs. Möglicherweise sollten Sie jedoch die Verwendung des Agent-basierten Szenarios für die folgenden Anwendungsfälle in Betracht ziehen:

• Umgebungen, die durch Eingabe-/Ausgabevorgänge pro Sekunde (IOPS) eingeschränkt werden: Die agentenlose Replikation verwendet Momentaufnahmen und verbraucht Speicher-IOPS/Bandbreite. Wir empfehlen die Agent-basierte Migrationsmethode, wenn es in Ihrer Umgebung Einschränkungen bezüglich Speicher/IOPS gibt.

• Kein vCenter-Server: Wenn Sie über keinen vCenter-Server verfügen, können Sie Ihre VMware-VMs wie physische Server behandeln und den Agent-basierten Migrationsworkflow verwenden.

Weitere Informationen finden Sie unter Auswählen einer VMware-Migrationsoption.

Welche geografischen Regionen werden für die Migration mit Azure Migrate unterstützt?

Beachten Sie die unterstützten geografischen Regionen für öffentliche Clouds und Government Clouds.

Kann das gleiche Azure Migrate-Projekt verwendet werden, um zu mehreren Regionen zu migrieren?

Obwohl Sie in einem Azure Migrate-Projekt Bewertungen für mehrere Regionen erstellen können, kann ein einzelnes Azure Migrate-Projekt verwendet werden, um Server zu nur einer Azure-Region zu migrieren. Sie können weitere Azure Migrate-Projekte für andere Regionen erstellen.

• Für agentenlose VMware-Migrationen ist die Zielregion gesperrt, wenn Sie die erste Replikation aktivieren.
• Bei Agent-basierten Migrationen (VMware, physische Server und Server aus anderen Clouds) wird die Zielregion gesperrt, wenn beim Einrichten der Replikationsappliance im Portal auf der Schaltfläche Ressourcen erstellen ausgewählt wird.
• Bei agentenlosen Hyper-V-Migrationen wird der Zielbereich gesperrt, wenn die Schaltfläche Ressourcen erstellen im Portal ausgewählt ist, wenn Sie den Hyper-V-Replikationsanbieter einrichten.

Kann das gleiche Azure Migrate-Projekt verwendet werden, um zu mehreren Abonnements zu migrieren?

Ja, Sie können das gleiche Azure Migrate-Projekt verwenden, um zu mehreren Abonnements mit demselben Azure-Mandanten in der gleichen Zielregion zu migrieren. Sie können das Zielabonnement auswählen, wenn Sie die Replikation für einen Computer oder eine Gruppe von Computern aktivieren.

Der Zielbereich ist gesperrt:

• Nach der ersten Replikation für agentenlose VMware-Migrationen.
• Während der Replikationsappliance für Agent-basierte Migrationen.
• Während der Hyper-V-Anbieterinstallation für agentenlose Hyper-V-Migrationen.

Unterstützt Azure Migrate Azure Resource Graph?

Derzeit ist Azure Migrate nicht mit Azure Resource Graph integriert. Es unterstützt aber die Durchführung von Azure Resource Graph-bezogenen Abfragen.

Wie werden die Daten von der lokalen Umgebung zu Azure übertragen? Werden sie vor der Übertragung verschlüsselt?

Bei der agentenlosen Replikation komprimiert und verschlüsselt die Azure Migrate-Appliance Daten, bevor sie hochgeladen werden. Daten werden über einen sicheren Kommunikationskanal über HTTPS übertragen und verwenden TLS 1.2 oder höher. Darüber hinaus verschlüsselt Azure Storage Ihre Daten automatisch, wenn sie die Daten in der Cloud speichert (Verschlüsselung im Ruhezustand).

Kann ich den Recovery Services-Tresor verwenden, der von Azure Migrate für Notfallwiederherstellungsszenarien erstellt wurde?

Wir empfehlen nicht, den von Azure Migrate erstellten Wiederherstellungsdienste-Tresor für Notfallwiederherstellungsszenarien zu verwenden, da dies zu Startreplikationsfehlern in Azure Migrate führen kann.

Worin besteht der Unterschied zwischen der Testmigration und den Migrationsvorgängen?

Mit der Option Migration testen können Sie Migrationen vor der tatsächlichen Migration testen und überprüfen. Migration testen funktioniert, indem Sie eine Sandkastenumgebung in Azure verwenden können, um die VMs vor der tatsächlichen Migration zu testen. Ein virtuelles Testnetzwerk, das Sie angeben,grenzt die Sandkastenumgebung ab. Der Migration testen Vorgang ist unterbrechungsfrei, solange das virtuelle Testnetzwerk ausreichend isoliert ist. Ein virtuelles Netzwerk ist ausreichend isoliert, wenn Sie die eingehenden und ausgehenden Verbindungsregeln entwerfen, um unerwünschte Verbindungen zu vermeiden. Zum Beispiel: Sie schränken die Verbindung auf lokale Computer ein.

Die Anwendungen können weiterhin auf dem Quellcomputer ausgeführt werden, während Sie Tests an einer geklonten Kopie in einer isolierten Sandboxumgebung durchführen können. Sie können nach Bedarf mehrere Tests durchführen, um die Migration zu überprüfen, App-Tests durchzuführen und alle Probleme vor der eigentlichen Migration zu beheben.

Gibt es eine Rollbackoption für Azure Migrate?

Sie können die Testmigrationsoption verwenden, um die Anwendungsfunktionalität und die Leistung in Azure zu überprüfen. Sie können eine beliebige Anzahl von Testmigrationen durchführen und die endgültige Migration durchführen, nachdem Sie eine Vertrauensstellung über den Migration testen Vorgang hergestellt haben.

Eine Testmigration wirkt sich nicht auf den lokalen Computer aus, der weiterhin betriebsbereit ist und die Replikation fortsetzt, bis Sie die tatsächliche Migration durchführen. Wenn während des Benutzerakzeptanztests (UAT) für die Testmigration Fehler auftreten, können Sie die endgültige Migration verschieben und ihre Quell-VM/Server ausführen und in Azure replizieren. Sie können die endgültige Migration erneut versuchen, nachdem Sie die Fehler behoben haben.

Hinweis

Nachdem Sie eine endgültige Migration zu Azure durchgeführt haben und der lokale Quellcomputer heruntergefahren wurde, können Sie kein Rollback aus Azure in Ihre lokale Umgebung durchführen.

Kann ich das virtuelle Netzwerk und Subnetz auswählen, das für Testmigrationen verwendet werden soll?

Sie können ein virtuelles Netzwerk für Testmigrationen auswählen. Azure Migrate wählt automatisch ein Subnetz basierend auf der folgenden Logik aus:

• Wenn Sie ein Zielsubnetz (außer Standard) als Eingabe angeben, während die Replikation aktiviert wird, priorisiert Azure Migrate ein Subnetz mit demselben Namen im virtuellen Netzwerk, das für die Testmigration verwendet wird.
• Wenn ein Subnetz mit demselben Namen nicht gefunden wird, wählt Azure Migrate alphabetisch das erste verfügbare Subnetz aus, das kein Gateway, ein Anwendungsgateway, eine Firewall oder ein Azure Bastion-Subnetz ist.

Warum ist die Schaltfläche „Testmigration“ für meinen Server deaktiviert?

Die Schaltfläche „Testmigration“ könnte in den folgenden Szenarien deaktiviert sein:

• Sie können eine Testmigration erst starten, wenn eine anfängliche Replikation für die VM abgeschlossen ist. Die Schaltfläche „Testmigration“ bleibt deaktiviert, bis der anfängliche Replikationsprozess abgeschlossen ist. Sie können eine Testmigration durchführen, nachdem Ihre VM sich in einer Deltasynchronisierungsphase befindet.
• Die Schaltfläche kann deaktiviert sein, wenn eine Testmigration bereits abgeschlossen wurde, für diese VM jedoch noch keine Bereinigung der Testmigration durchgeführt wurde. Führen Sie eine Bereinigung der Testmigration durch, und wiederholen Sie den Vorgang.

Was geschieht, wenn ich meine Testmigration nicht bereinige?

Eine Testmigration simuliert die tatsächliche Migration durch Erstellen eines Test-Azure VMs mithilfe von replizierten Daten. Der Server wird mit einer Punkt-in-Time-Kopie der replizierten Daten in die Zielressourcengruppe (ausgewählt, wenn Sie die Replikation aktivieren) mit einem -test Suffix bereitgestellt. Testmigrationen sollen die Serverfunktionalität überprüfen, um Probleme nach der Migration zu minimieren.

Wenn die Testmigration nach dem Testen nicht bereinigt wird, wird der Test-VM weiterhin in Azure ausgeführt und verursacht Gebühren. Um nach einer Testmigration zu bereinigen, wechseln Sie zur Replizieren von Computern Ansicht im Migrations- and Modernisierungs- Tool, und verwenden Sie die Bereinigungstestmigrations- Aktion auf dem Computer.

Wie kann ich wissen, ob meine VM erfolgreich migriert wurde?

Nachdem Sie Ihren VM/Server erfolgreich migriert haben, können Sie den VM im Bereich virtuelle Computer anzeigen und verwalten. Stellen Sie eine Verbindung mit der migrierten VM her, um dies zu überprüfen.

Sie können auch den Auftragsstatus für den Vorgang überprüfen, um zu überprüfen, ob die Migration erfolgreich abgeschlossen wurde. Wenn Fehler angezeigt werden, beheben Sie diese, und wiederholen Sie dann den Migrationsvorgang.

Was geschieht, wenn ich die Replikation nach der Migration nicht beende?

Wenn Sie die Replikation beenden, bereinigt das Migrations- and Modernisierungs-Tool die verwalteten Datenträger im Abonnement, das für die Replikation erstellt wurden.

Was geschieht, wenn ich die Migration nach der Migration nicht auswähle?

Wenn Sie Migration abschließenauswählen, bereinigt das Migrations- und Modernisierungs- Tool die verwalteten Datenträger im Abonnement, das für die Replikation erstellt wurden. Wenn Sie nach einer Migration nicht Migration abschließen auswählen, fallen weiterhin Gebühren für diese Datenträger an. Abgeschlossene Migration wirkt sich nicht auf die Datenträger aus, die bereits migriert wurden.

Wie kann ich UEFI-basierte Computer als virtuelle Azure-Computer der Generation 1 zu Azure migrieren?

Das Migrations- und Modernisierungs- Tool migriert UEFI-basierte Computer als VMs der Azure Generation 2 zu Azure. Wenn Sie diese als Azure-VMs der Generation 1 migrieren möchten, konvertieren Sie den Starttyp vor dem Beginn der Replikation in BIOS, und verwenden Sie dann das Migrations- und Modernisierungs- Tool, um zu Azure zu migrieren.

Konvertiert Azure Migrate auf UEFI basierende Computer in BIOS-basierte Computer und migriert Sie als virtuelle Azure-Computer der Generation 1 zu Azure?

Das Migrations- und Modernisierungs- Tool migriert alle UEFI-basierten Computer als Azure-VM der Generation 2 zu Azure. Die Konvertierung von UEFI-basierten VMs in BIOS-basierte VMS wird nicht mehr unterstützt. Alle BIOS-basierten Computer werden nur als Azure-VMs der Generation 1 zu Azure migriert.

Welche Betriebssysteme werden für die Migration von UEFI-basierten Computern zu Azure unterstützt?

Hinweis

Wenn eine Hauptversion eines Betriebssystems bei der agentlosen Migration unterstützt wird, werden alle Nebenversionen und Kernel automatisch unterstützt.

Für UEFI-basierte Computer unterstützte Betriebssysteme	VMware ohne Agent zu Azure	Hyper-V ohne Agent zu Azure	Agent-basierte VMware, physische und andere Clouds zu Azure
Windows Server 2025, 2022, 2019, 2016, 2012 R2, 2012	Y	J	J
Windows 11 Pro, Windows 11 Enterprise	Y	J	J
Windows 10 Pro, Windows 10 Enterprise	Y	J	J
SUSE Linux Enterprise Server 15 SP1, SP2, SP3, SP4, SP5, SP6	Y	J	J
SUSE Linux Enterprise Server 12 SP4	Y	J	J
Ubuntu Server 22.04 LTS, 20.04 LTS, 18.04 LTS, 16.04 LTS	Y	J	Y
RHEL 9.x, 8.1, 8.0, 7.8, 7.7, 7.6, 7.5, 7.4, 7.0, 6.x	Y	J	Y
CentOS Stream	Y	J	J
Oracle Linux 9, 8, 7.7-CI, 7.7, 6	Y	J	J

Kann ich Active Directory-Domänencontroller durch Verwendung von Azure Migrate migrieren?

Das Migrations- und Modernisierungs- Tool ist anwendungsagnostisch und funktioniert für die meisten Anwendungen. Wenn Sie einen Server mit Verwendung des Migrations- und Modernisierungs- Tools migrieren, werden alle auf dem Server installierten Anwendungen zusammen mit dem Server migriert. Alternative Migrationsmethoden sind jedoch möglicherweise besser geeignet, um einige Anwendungen zu migrieren.

Bei Active Directory kann der Typ der Umgebung ein Faktor sein. In einer Hybridumgebung mit einem lokalen Standort, der mit Ihrer Azure-Umgebung verbunden ist, können Sie Ihr Verzeichnis in Azure erweitern, indem Sie zusätzliche Domänencontroller hinzufügen und die Active Directory-Replikation einrichten. Sie können das Migrations- und Modernisierungs- Tool verwenden, wenn Sie:

• Zu einer isolierten Umgebung in Azure migrieren, die eigene Domänencontroller erfordert.
• Anwendungen in einer Sandkastenumgebung testen.

Kann ich mein Betriebssystem während der Migration aktualisieren?

Das Migrations- und Modernisierungs- Tool unterstützt jetzt das Windows-Betriebssystemupgrade während der Migration. Diese Option ist derzeit nicht für CSV-Dateien verfügbar. Erhalten Sie weitere Details zum Windows Betriebssystemupgrade.

Benötige ich VMware vCenter, um VMware-VMs zu migrieren?

Damit Sie VMware-VMs mithilfe der Agent-basierten oder agentenlosen Migration von VMware migrieren können, muss vCenter Server die ESXi-Hosts verwalten, auf denen sich die VMs befinden. Wenn Sie nicht über vCenter Server verfügen, können Sie VMware-VMs als physische Server migrieren. Weitere Informationen

Kann ich bei der Migration mehrere Quell-VMs in einer VM konsolidieren?

Das Migrations- und Modernisierungs- Tool unterstützt derzeit nur Migrationen für identische Betriebssysteme. Wir unterstützen die Konsolidierung von Servern während der Migration nicht.

Werden Windows Server 2008 und 2008 R2 nach der Migration in Azure unterstützt?

Sie können Ihre lokalen Windows Server 2008- und 2008 R2-Server zu Azure VMs migrieren und erweiterte Sicherheitsupdates für einen Zeitraum von drei Jahren nach dem Ende des Supportvertrags ohne zusätzliche Kosten zu den Kosten für den Betrieb des VMs erhalten. Sie können das Migrations- und Modernisierungs- Tool zum Migrieren Ihrer Windows Server 2008- und 2008 R2-Workloads verwenden.

Wie migriere ich Windows Server 2003 unter VMware/Hyper-V zu Azure?

Der erweiterte Support für Windows Server 2003 wurde am 14. Juli 2015 beendet. Das Azure-Supportteam hilft weiterhin bei der Behebung von Problemen, die sich auf die Ausführung von Windows Server 2003 in Azure beziehen. Diese Unterstützung ist jedoch auf Probleme beschränkt, die keine Problembehandlung oder Patches auf Betriebssystemebene erfordern.

Wir empfehlen, dass Sie Ihre Anwendungen zu Azure-Instanzen migrieren, die eine neuere Version von Windows Server ausführen, um sicherzustellen, dass Sie die Flexibilität und Zuverlässigkeit der Azure-Cloud effektiv nutzen.

Wenn Sie sich weiterhin für die Migration von Windows Server 2003 zu Azure entscheiden, können Sie das Migrations- und Modernisierungs- Tool verwenden, wenn Ihre Windows Server-Bereitstellung ein VM ist, der auf VMware oder Hyper-V ausgeführt wird. Weitere Informationen finden Sie unter Vorbereiten Ihres Windows Server 2003 Computer für die Migration.

VMware-Migration ohne Agent

Wie funktioniert eine Migration ohne Agent?

Das Migrations- und Modernisierungs- Tool bietet agentenlose Replikationsoptionen für die Migration von VMware- und Hyper-V-VMs unter Windows oder Linux. Das Tool bietet eine weitere Agent-basierte Replikationsoption für Windows- und Linux-Server. Diese andere Option kann zum Migrieren physischer Server und x86/x64-VMs auf Anbietern wie VMware, Hyper-V, AWS und GCP verwendet werden.

Die Agent-basierte Replikation erfordert, dass Sie Agent-Software auf dem virtuellen Computer/Server installieren, den Sie migrieren. Die agentenlose Option erfordert nicht, dass Sie Software auf den VMs installieren, was Komfort und Einfachheit bieten kann.

Die agentenlose Replikationsoption verwendet Mechanismen, die vom Virtualisierungsanbieter (VMware, Hyper-V) bereitgestellt werden. Für VMware VMs verwendet der agentenlose Replikationsmechanismus ohne Agent VMware-Momentaufnahmen und die VMware-Nachverfolgungstechnologie für geänderte Blöcke, um Daten von Datenträgern von VMs zu replizieren. Viele Backup-Produkte verwenden einen ähnlichen Mechanismus. Für Hyper-V VMs verwendet der agentenlose Replikationsmechanismus VM-Momentaufnahmen und die Änderungsnachverfolgungsfunktion des Hyper-V-Replikats, um Daten von VM-Datenträgern zu replizieren.

Wenn Replikation für einen VM konfiguriert ist, wird der VM zuerst eine anfängliche Replikationsphase durchlaufen. Während der ersten Replikation wird eine VM-Momentaufnahme erstellt, und eine vollständige Kopie der Daten von den Momentaufnahmedatenträgern wird auf verwaltete Datenträger in Ihrem Abonnement repliziert. Wenn die anfängliche Replikation für den VM beendet ist, geht der Replikationsprozess in eine inkrementelle Replikationsphase (Deltareplikation) über.

In der inkrementellen Replikationsphase werden alle Datenänderungen behandelt, die seit dem letzten abgeschlossenen Replikationszyklus aufgetreten sind. Diese Änderungen werden regelmäßig repliziert und auf die vom Replikat verwalteten Datenträger angewendet. Dieser Prozess synchronisiert die Replikation mit Änderungen auf dem VM.

Die VMware-Technologie zur Verfolgung geänderter Blöcke verfolgt Änderungen zwischen Replikationszyklen für VMware-VMs. Zu Beginn des Replikationszyklus wird eine VM-Momentaufnahme erstellt, und die Nachverfolgung geänderter Blöcke wird verwendet, um die Änderungen zwischen der aktuellen Momentaufnahme und der zuletzt erfolgreich replizierten Momentaufnahme zusammenzustellen. Um die Replikation für den VM synchron zu halten, müssen nur Daten repliziert werden, die seit dem letzten abgeschlossenen Replikationszyklus geändert wurden.

Am Ende jedes Replikationszyklus wird die Momentaufnahme freigegeben und eine Momentaufnahmekonsolidierung für den VM ausgeführt. Ebenso verfolgt das Hyper-V-Replikatänderungsnachverfolgungsmodul für Hyper-V VMs Änderungen zwischen aufeinander folgenden Replikationszyklen.

Wenn Sie den Migrate Vorgang auf einem replizierenden VM durchführen, können Sie die lokale VM herunterfahren und eine abschließende inkrementelle Replikation durchführen, um zu gewährleisten, dass kein Datenverlust auftritt. Wenn die Replikation durchgeführt wird, dann werden die replikatverwalteten Datenträger, die der VM entsprechen, verwendet, um den VM in Azure zu erstellen.

Informationen zu den ersten Schritten finden Sie in den Tutorials agentenlose VMware-Migration und agentenlose Hyper-V-Migration.

Wie schätze ich den Bandbreitenbedarf für meine Migrationen ein?

Eine Reihe von Faktoren kann sich auf die Bandbreite auswirken, die Sie zum Replizieren von Daten in Azure benötigen. Die Bandbreitenanforderung hängt davon ab, wie schnell die lokale Azure Migrate-Appliance die Daten in Azure lesen und replizieren kann. Die Replikation besteht aus zwei Phasen: anfängliche Replikation und Deltareplikation.

Wenn die Replikation für einen virtuellen Computer gestartet wird, werden in einem ersten Replikationszyklus vollständige Kopien der Datenträger repliziert. Nachdem die erste Replikation abgeschlossen wurde, werden in regelmäßigen Abständen inkrementelle Replikationszyklen (Deltazyklen) geplant, um Änderungen zu übertragen, die seit dem vorherigen Replikationszyklus aufgetreten sind.

Sie können die Bandbreitenanforderung auf der Grundlage folgender Faktoren berechnen:

• Das Datenvolumen, das Sie in der Welle verschieben müssen.
• Die Zeit, die Sie für den anfänglichen Replikationsprozess zugeben möchten.

Im Idealfall sollten Sie die erste Replikation mindestens 3 bis 4 Tage vor dem tatsächlichen Migrationsfenster abschließen. Diese Zeitleiste bietet Ihnen ausreichend Zeit, um eine Testmigration vor dem tatsächlichen Fenster durchzuführen und Ausfallzeiten während des Fensters auf ein Minimum zu halten.

Mithilfe der folgenden Formel können Sie die Bandbreite oder die benötigte Zeit für eine Migration von VMware-VMs ohne Agent schätzen:

• Zeit bis zum Abschluss der anfänglichen Replikation = {Größe der Datenträger (oder verwendete Größe, falls verfügbar) · 0,7 (unter der Annahme einer durchschnittlichen Komprimierung von 30 Prozent – konservative Schätzung)}/Bandbreite, die für die Replikation zur Verfügung steht.

Wie kann ich die Replikation drosseln, wenn die Azure Migrate-Appliance für die agentenlose VMware-Replikation verwendet wird?

Mithilfe von NetQosPolicykönnen Sie die Drosselung ausführen. Diese Drosselungsmethode gilt nur für ausgehende Verbindungen aus der Azure Migrate Appliance.

Beispielsweise ist der in NetQosPolicy zu verwendende AppNamePrefix Wert GatewayWindowsService.exe. Sie können eine Richtlinie auf der Azure Migrate-Appliance erstellen, um den Replikationsdatenverkehr von der Appliance zu drosseln, indem Sie eine Richtlinie wie die folgende erstellen:

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

Um die Replikationsbandbreite basierend auf einem Zeitplan zu erhöhen und zu verringern, können Sie eine geplante Windows-Aufgabe nutzen, um die Bandbreite nach Bedarf zu skalieren. Eine Aufgabe verringert die Bandbreite, und eine andere Aufgabe erhöht die Bandbreite.

Hinweis

Sie müssen die zuvor erwähnten NetQosPolicy erstellen, bevor Sie die folgenden Befehle ausführen.

#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

Wie wirkt sich die Änderungsrate auf die Replikation ohne Agent aus?

Da bei der Replikation ohne Agent Daten zusammengelegt werden, ist das Änderungsmuster wichtiger als die Änderungsrate. Wenn eine Datei immer wieder geschrieben wird, hat die Rate keine große Auswirkung. Dagegen verursacht ein Muster, bei dem in jeden zweiten Sektor geschrieben wird, im nächsten Zyklus viele Änderungen. Da die zu übertragende Datenmenge minimiert werden soll, sollen die Daten so weit wie möglich zusammengelegt werden, bevor der nächste Zyklus geplant wird.

Wie häufig wird ein Replikationszyklus geplant?

Die Formel zur Planung des nächsten Replikationszyklus ist (Vorherige Zyklusdauer / 2) oder eine Stunde, je nachdem, welcher Wert höher ist.

Beispiel: Wenn ein Deltazyklus für eine VM vier Stunden dauert, wird der nächste Zyklus in zwei Stunden geplant, nicht in der nächsten Stunde. Das Verfahren unterscheidet sich unmittelbar nach der ersten Replikation, wenn sofort der erste Deltazyklus geplant wird.

Ich habe zwei (oder mehr) Appliances zum Entdecken von VMs auf meiner vCenter Server-Instanz bereitgestellt. Wenn ich aber versuche, die VMs zu migrieren, werden mir nur VMs angezeigt, die einer der Appliances entsprechen.

Wenn Sie mehrere Appliances einrichten, kann es keine Überlappung zwischen den VMs auf den bereitgestellten vCenter-Konten geben. Eine Entdeckung mit einer solchen Überlappung ist ein nicht unterstütztes Szenario.

Welche Auswirkungen hat die Replikation ohne Agent auf VMware-Server?

Die Replikation ohne Agent hat einige Auswirkungen auf die Leistung von VMware vCenter Server- und VMware ESXi-Hosts. Da die Replikation ohne Agent Momentaufnahmen verwendet, verbraucht sie IOPS im Speicher, sodass eine gewisse IOPS-Speicherbandbreite erforderlich ist. Wir raten davon ab, die Replikation ohne Agent zu verwenden, wenn es in Ihrer Umgebung Einschränkungen hinsichtlich Speicher oder IOPS gibt.

Können ausgeschaltete VMs repliziert werden?

Die Replikation von VMware-VMs, während sie ausgeschaltet werden, wird unterstützt, aber nur im agentenlosen Ansatz.

Wichtig

Wir können nicht garantieren, dass eine ausgeschaltete VM erfolgreich gestartet wird, da wir den Betriebsstatus vor der Replikation nicht überprüfen können.

Wir empfehlen dringend, dass Sie eine Testmigration durchführen, um sicherzustellen, dass während der tatsächlichen Migration alles reibungslos abläuft. Diese Methode kann nützlich sein, in denen der anfängliche Replikationsprozess langwierig ist, oder für VMs mit hoher Abwanderung, wie Datenbankserver oder andere datenträgerintensive Workloads.

Kann ich Azure Migrate verwenden, um meine Web-Apps zu Azure App Service zu migrieren?

Sie können eine skalierte agentenlose Migration von ASP.NET-Web-Apps durchführen, die auf IIS-Webservern laufen, die auf einem Windows-Betriebssystem in einer VMware-Umgebung gehostet werden. Weitere Informationen

Agent-basierte Migration

Wie kann ich meine AWS EC2-Instanzen zu Azure migrieren?

Überprüfen Sie Entdecken, Bewerten und Migrieren von Amazon Web Services (AWS)-VMs zu Azure.

Wie funktioniert eine Agent-basierte Migration?

Das Migration und Modernisierung Tool bietet eine Agent-basierte Migrationsoption zum Migrieren von Windows- und Linux-Servern auf physischen Servern oder als x86/x64-VMs auf Anbietern wie VMware, Hyper-V, AWS und GCP.

Die Agent-basierten Migrationsmethode verwendet Agent-Software, um Serverdaten in Azure zu replizieren. Sie installieren die Software auf dem Server, den Sie migrieren. Der Replikationsprozess verwendet eine Auslagerungsarchitektur, bei der der Agent Replikationsdaten an einen dedizierten Replikationsserver weiterleitet, der als Replikationsappliance oder Konfigurationsserver bezeichnet wird (oder an einen Prozessserver für horizontale Skalierung). Weitere Informationen finden Sie unter Agent-basierte Migrationsarchitektur.

Hinweis

Die Replikationsappliance unterscheidet sich von der Azure Migrate-Erkennungsappliance und muss auf einem separaten/dedizierten Computer installiert werden.

Wo sollte ich die Replikationsappliance für Agent-basierte Migrationen installieren?

Sie sollten die Replikations-Appliance auf einem dedizierten Computer installieren. Sie sollten die Replikations-Appliance nicht auf einem Quellcomputer installieren, den Sie replizieren möchten, oder auf der Azure Migrate-Appliance, die Sie für die Ermittlung und Bewertung verwendet haben. Weitere Informationen finden Sie unter Migrieren von Computern als physische Server zu Azure.

Kann ich AWS-VMs migrieren, die das Betriebssystem Amazon Linux ausführen?

VMs, auf denen Amazon Linux ausgeführt wird, können nicht unverändert migriert werden, da das Betriebssystem Amazon Linux nur in AWS unterstützt wird.

Um Workloads zu migrieren, die unter Amazon Linux ausgeführt werden, können Sie eine CentOS/RHEL-VM in Azure einrichten. Anschließend können Sie die Workload, die auf dem AWS Linux-Computer ausgeführt wird, mithilfe eines entsprechenden Workload-Migrationsansatzes migrieren. Abhängig von der Workload gibt es zum Beispiel möglicherweise workloadspezifische Tools zur Unterstützung der Migration, wie Tools für Datenbanken oder Bereitstellungstools für Webserver.

Wie schätze ich den Bandbreitenbedarf für meine Migrationen ein?

Eine Reihe von Faktoren kann sich auf die Bandbreite auswirken, die Sie zum Replizieren von Daten in Azure benötigen. Die Bandbreitenanforderung hängt davon ab, wie schnell die lokale Azure Migrate-Appliance die Daten in Azure lesen und replizieren kann. Die Replikation besteht aus zwei Phasen: anfängliche Replikation und Deltareplikation.

Wenn die Replikation für einen virtuellen Computer gestartet wird, werden in einem ersten Replikationszyklus vollständige Kopien der Datenträger repliziert. Nachdem die erste Replikation abgeschlossen wurde, werden in regelmäßigen Abständen inkrementelle Replikationszyklen (Deltazyklen) geplant, um Änderungen zu übertragen, die seit dem vorherigen Replikationszyklus aufgetreten sind.

Bei einer Agent-basierten Replikationsmethode kann der Azure Site Recovery-Bereitstellungsplaner die Ermittlung der Umgebung für die Datenänderung unterstützen und die erforderliche Bandbreitenanforderung vorhersagen. Um mehr zu erfahren, lesen Sie Planen der VMware-Bereitstellung.

Hyper-V-Migration ohne Agent

Wie funktioniert eine Migration ohne Agent?

Das Migrations- und Modernisierungs- Tool bietet agentenlose Replikationsoptionen für die Migration von VMware- und Hyper-V-VMs unter Windows oder Linux. Das Tool bietet eine weitere Agent-basierte Replikationsoption für Windows- und Linux-Server. Diese andere Option kann zum Migrieren physischer Server und x86/x64-VMs auf Anbietern wie VMware, Hyper-V, AWS und GCP verwendet werden.

Für die Agent-basierte Replikationsoption müssen Sie Agent-Software auf dem virtuellen Computer/Server installieren, den Sie migrieren. Die agentenlose Option erfordert nicht, dass Sie Software auf den VMs installieren, was Komfort und Einfachheit bieten kann.

Die agentenlose Replikationsoption funktioniert mithilfe von Mechanismen, die vom Virtualisierungsanbieter (VMware oder Hyper-V) bereitgestellt werden. Bei Hyper-V VMs repliziert der agentenlose Replikationsmechanismus Daten von VM-Datenträgern mithilfe von VM-Momentaufnahmen und der Änderungsnachverfolgungsfunktion des Hyper-V-Replikats.

Wenn Replikation für einen VM konfiguriert ist, wird der VM zuerst eine anfängliche Replikationsphase durchlaufen. Während der ersten Replikation wird eine VM-Momentaufnahme erstellt, und eine vollständige Kopie der Daten von den Momentaufnahmedatenträgern wird auf verwaltete Datenträger in Ihrem Abonnement repliziert. Wenn die anfängliche Replikation für den VM beendet ist, geht der Replikationsprozess in eine inkrementelle Replikationsphase (Deltareplikation) über.

In der inkrementellen Replikationsphase werden alle Datenänderungen behandelt, die seit dem letzten abgeschlossenen Replikationszyklus aufgetreten sind. Diese Änderungen werden regelmäßig repliziert und auf die vom Replikat verwalteten Datenträger angewendet. Dieser Prozess synchronisiert die Replikation mit Änderungen auf dem VM.

Die VMware-Technologie zur Verfolgung geänderter Blöcke wird verwendet, um Änderungen zwischen Replikationszyklen für VMware-VMs zu verfolgen. Zu Beginn des Replikationszyklus wird eine VM-Momentaufnahme erstellt, und die Nachverfolgung geänderter Blöcke wird verwendet, um die Änderungen zwischen der aktuellen Momentaufnahme und der zuletzt erfolgreich replizierten Momentaufnahme abzurufen. Um die Replikation für den VM synchron zu halten, müssen nur Daten repliziert werden, die seit dem letzten abgeschlossenen Replikationszyklus geändert wurden.

Am Ende jedes Replikationszyklus wird die Momentaufnahme freigegeben und eine Momentaufnahmekonsolidierung für den VM ausgeführt. Ebenso wird das Hyper-V-Replikatänderungsnachverfolgungsmodul für Hyper-V-Computer verwendet, um Änderungen zwischen aufeinander folgenden Replikationszyklen nachzuverfolgen.

Wenn Sie den Migrate Vorgang auf einem replizierenden VM durchführen, können Sie die lokale VM herunterfahren und eine abschließende inkrementelle Replikation durchführen, um zu gewährleisten, dass kein Datenverlust auftritt. Die replikatverwalteten Datenträger, die der VM entsprechen, werden verwendet, um den virtuellen Computer in Azure zu erstellen.

Informationen zu den ersten Schritten finden Sie im Tutorial Migrieren von virtuellen Hyper-V-Computern zu Azure.

Wie schätze ich den Bandbreitenbedarf für meine Migrationen ein?

Eine Reihe von Faktoren kann sich auf die Bandbreite auswirken, die Sie zum Replizieren von Daten in Azure benötigen. Die Bandbreitenanforderung hängt davon ab, wie schnell die lokale Azure Migrate-Appliance die Daten in Azure lesen und replizieren kann. Die Replikation besteht aus zwei Phasen: anfängliche Replikation und Deltareplikation.

Wenn die Replikation für einen virtuellen Computer gestartet wird, werden in einem ersten Replikationszyklus vollständige Kopien der Datenträger repliziert. Nachdem die erste Replikation abgeschlossen wurde, werden in regelmäßigen Abständen inkrementelle Replikationszyklen (Deltazyklen) geplant, um Änderungen zu übertragen, die seit dem vorherigen Replikationszyklus aufgetreten sind.

Sie können die Bandbreitenanforderung auf der Grundlage folgender Faktoren berechnen:

• Das Datenvolumen, das Sie in der Welle verschieben müssen.
• Die Zeit, die Sie für den anfänglichen Replikationsprozess zugeben möchten.

Im Idealfall sollten Sie die erste Replikation mindestens 3 bis 4 Tage vor dem tatsächlichen Migrationsfenster abschließen. Diese Zeitleiste bietet Ihnen ausreichend Zeit, um eine Testmigration vor dem tatsächlichen Fenster durchzuführen und Ausfallzeiten während des Fensters auf ein Minimum zu halten.

Zugehöriger Inhalt

• Erfahren Sie mehr über die Migration von VMware-VMs, Hyper-V-VMs und physischen Servern.