Migration und Modernisierung: Häufige Fragen

  • Artikel

Achtung

Dieser Artikel bezieht sich auf CentOS, eine Linux-Distribution, die sich dem End-of-Life-Status (EOL) nähert. Sie sollten Ihre Nutzung entsprechend planen. Weitere Informationen finden Sie im CentOS End-of-Life-Leitfaden.

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

Allgemeine Fragen

Welche Migrationsmöglichkeiten gibt es bei Migration und Modernisierung?

Das Migrations- und Modernisierungstool bietet zwei Optionen für das Migrieren Ihrer Quellserver und VMs zu Azure: die Migration ohne Agent und die Agent-basierte Migration.

Unabhängig von der gewählten Migrationsoption besteht der erste Schritt zum Migrieren eines Servers mithilfe des Migrations- und Modernisierungstools darin, die Replikation für den Server zu starten. Dadurch wird eine anfängliche Replikation ihrer VM/Serverdaten in Azure durchgeführt. Nachdem die anfängliche Replikation abgeschlossen wurde, wird eine fortlaufende Replikation (fortlaufende Deltasynchronisierung) zum Migrieren von inkrementellen Daten zu Azure eingerichtet. Sobald der Vorgang die Deltasynchronisierungsphase erreicht hat, können Sie jederzeit zu Azure migrieren.

Im Folgenden finden Sie einige Überlegungen, die Sie berücksichtigen sollten, wenn Sie sich für eine Migrationsoption entscheiden.

Bei der Migration ohne Agent muss auf den zu migrierenden Quell-VMs/-Servern keine Software (Agents) bereitgestellt werden. Die Option ohne Agent orchestriert die Replikation durch Integration in die vom Virtualisierungsanbieter bereitgestellte Funktionalität. Die Replikationsoptionen ohne Agent sind für VMware-VMs und Hyper-V-VMs verfügbar.

Bei Agent-basierten Migrationen muss Azure Migrate-Software (Agents) auf den zu migrierenden Quell-VMs/-computern installiert werden. Die Agent-basierte Option ist nicht auf die Virtualisierungsplattform für die Replikationsfunktion angewiesen. Aus diesem Grund kann sie für jeden Server verwendet werden, auf dem eine x86-/x64-Architektur und eine Version eines Betriebssystems ausgeführt wird, das von der Agent-basierten Replikationsmethode unterstützt wird.

Die Agent-basierte Migrationsoption kann für VMware-VMs, Hyper-V-VMs, physische Server, VMs, die unter AWS, VMs, die unter GCP oder VMs, die unter einem anderen Virtualisierungsanbieter ausgeführt werden, verwendet werden. Bei der Agent-basierten Migration werden Ihre Computer für die Migration als physische Server behandelt.

Während die Migration ohne Agents zusätzliche Bequemlichkeit und Einfachheit gegenüber den Agent-basierten Replikationsoptionen für die unterstützten Szenarios (VMware und Hyper-V) bietet, sollten Sie die Verwendung des Agent-basierten Szenarios für die folgenden Anwendungsfälle in Betracht ziehen:

  • IOPS-begrenzte Umgebung: Die Replikation ohne Agent verwendet Momentaufnahmen und beansprucht Speicher-IOPS/Bandbreite. Wir empfehlen die Agent-basierte Migrationsmethode, wenn es in Ihrer Umgebung Einschränkungen bezüglich Speicher/IOPS gibt.
  • 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 in diesem Artikel, in dem Migrationsoptionen für VMware-Migrationen verglichen werden.

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 Azure 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 nur verwendet werden, um Server zu einer Azure-Region zu migrieren. Sie können zusätzliche Azure Migrate-Projekte für jede Region erstellen, zu der Sie migrieren müssen.

  • Für VMware-Migrationen ohne Agent ist die Zielregion gesperrt, sobald Sie die erste Replikation aktivieren.
  • Bei Agent-basierten Migrationen (VMware, physische Server und Server aus anderen Clouds) wird die Zielregion gesperrt, sobald beim Einrichten der Replikationsappliance im Portal auf Schaltfläche „Ressourcen erstellen“ ausgewählt wird.
  • Für Hyper-V-Migrationen ohne Agent wird die Zielregion gesperrt, sobald beim Einrichten des Hyper-V-Replikationsanbieters im Portal die Schaltfläche „Ressourcen erstellen“ ausgewählt wird.

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

Ja, Sie können zu mehreren Abonnements (desselben Azure-Mandanten) in der gleichen Zielregion für ein Azure Migrate-Projekt migrieren. Sie können das Zielabonnement auswählen, während Sie die Replikation für einen Computer oder eine Gruppe von Computern aktivieren. Die Zielregion wird nach der ersten Replikation für VMware-Migrationen ohne Agent und während der Replikationsappliance- und Hyper-V-Anbieterinstallation für Agent-basierte Migrationen bzw. für Hyper-V-Migrationen ohne Agent gesperrt.

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

Die Azure Migrate-Appliance komprimiert Daten bei der Replikation ohne Agent und verschlüsselt sie vor dem Hochladen. Daten werden über einen sicheren Kommunikationskanal über HTTPS übertragen und verwenden TLS 1.2 oder höher. Zudem werden Ihre Daten von Azure Storage beim Speichern in der Cloud automatisch verschlüsselt (Verschlüsselung ruhender Daten).

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

Die Verwendung des Recovery Services-Tresors, der von Azure Migrate für Notfallwiederherstellungsszenarien erstellt wurde, wird nicht empfohlen. Dies kann zu Fehlern beim Starten der Replikation in Azure Migrate führen.

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

Die Test Migration bietet eine Möglichkeit zum Testen und Überprüfen von Migrationen vor der eigentlichen Migration. Bei der Testmigration können Sie eine Sandboxumgebung in Azure verwenden, um die virtuellen Computer vor der eigentlichen Migration zu testen. Die Sandboxumgebung wird von einem virtuellen Testnetzwerk abgegrenzt, das Sie angeben. Der Testmigrationsvorgang ist unterbrechungsfrei, vorausgesetzt, das Test-VNET ist ausreichend isoliert. Isoliertes VNET bedeutet hier, dass die Regeln für eingehende und ausgehende Verbindungen so konzipiert sind, dass unerwünschte Verbindungen vermieden werden. Beispiel: Die Verbindung mit lokalen Computern ist eingeschränkt.

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.

Screenshot: Unterschied zwischen der Testmigration und der tatsächlichen Migration

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 und dann die endgültige Migration ausführen, nachdem Sie durch den Testmigrationsvorgang Vertrauen gewonnen 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 der Testmigration-UAT Fehler aufgetreten sind, können Sie die endgültige Migration verschieben und den virtuellen Quellcomputer/Server weiterhin ausführen und in Azure replizieren. Nachdem Sie die Fehler behoben haben, können Sie die endgültige Migration erneut versuchen. Hinweis: Wenn 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. Das Subnetz wird automatisch basierend auf der folgenden Logik ausgewählt:

  • Wenn bei der Aktivierung der Replikation ein Zielsubnetz (ein anderes Subnetz als das Standardsubnetz) als Eingabe angegeben wurde, dann priorisiert Azure Migrate die Verwendung eines gleichnamigen Subnetzes in dem für die Testmigration ausgewählten virtuellen Netzwerk.
  • Wenn das gleichnamige Subnetz nicht gefunden wird, wählt Azure Migrate alphabetisch das erste verfügbare Subnetz aus, das kein Subnetz vom Typ Gateway/Anwendungsgateway/Firewall/Bastion ist.

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

Die Schaltfläche „Testmigration“ kann in den folgenden Szenarien einen deaktivierten Zustand aufweisen:

  • Sie können eine Testmigration erst starten, wenn für die VM eine anfängliche Replikation (Initial Replication, IR) abgeschlossen wurde. Die Schaltfläche „Testmigration“ bleibt deaktiviert, bis der IR-Prozess abgeschlossen wurde. Sie können eine Testmigration durchführen, wenn sich Ihre VM 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 virtuellen Azure-Testcomputers mithilfe von replizierten Daten. Der Server wird mit einer Zeitpunktkopie der replizierten Daten mit dem Suffix „-test“ in der (bei der Aktivierung der Replikation ausgewählten) Zielressourcengruppe bereitgestellt. Testmigrationen sind zum Überprüfen der Server Funktionalität vorgesehen, sodass Probleme nach der Migration minimiert werden. Wenn die Testmigration nach dem Testen nicht bereinigt wird, wird die Test-VM weiterhin in Azure ausgeführt, und es fallen Gebühren an. Wechseln Sie im Migrations- und Modernisierungstool zur Ansicht der replizierenden Computer und verwenden Sie die Aktion „Testmigration bereinigen“ auf dem Computer, um die Bereinigung nach einer Testmigration durchführen zu können.

Woran erkenne ich, ob meine VM erfolgreich migriert wurde?

Nachdem Sie Ihre VM bzw. Ihren Server erfolgreich migriert haben, können Sie die VM über die Seite „Virtual Machines“ anzeigen und verwalten. Stellen Sie eine Verbindung mit der migrierten VM her, um dies zu überprüfen. Alternativ können Sie den „Auftragsstatus“ für den Vorgang überprüfen, um zu ermitteln, ob die Migration erfolgreich abgeschlossen wurde. Wenn Fehler angezeigt werden, beheben Sie diese, und wiederholen Sie den Migrationsvorgang.

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

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

Was geschieht, wenn ich die Migration nach der Migration nicht abschließe?

Wenn Sie die Migration abschließen, bereinigt das Migrations- und Modernisierungstool die verwalteten Datenträger im Abonnement, die 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. Das Abschließen der 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 Modernisierungstool migriert UEFI-basierte Computer als Azure-VM der Generation 2 zu Azure. Wenn Sie diese zu 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 Modernisierungstool, 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 Modernisierungstool 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?

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 2019, 2016, 2012 R2, 2012 Y Y J
Windows 10 Pro, Windows 10 Enterprise Y Y J
SUSE Linux Enterprise Server 15 SP1 Y Y J
SUSE Linux Enterprise Server 12 SP4 Y Y J
Ubuntu Server 16.04, 18.04, 19.04, 19.10 Y Y J
RHEL 8.1, 8.0, 7.8, 7.7, 7.6, 7.5, 7.4, 7.0, 6.x Y Y J
Cent OS 8.1, 8.0, 7.7, 7.6, 7.5, 7.4, 6.x Y Y J
Oracle Linux 7.7, 7.7-CI Y Y J

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

Das Migrations- und Modernisierungstool ist anwendungsagnostisch und funktioniert für die meisten Anwendungen. Wenn Sie einen Server mit dem Migrations- und Modernisierungstool migrieren, werden alle auf dem Server installierten Anwendungen zusammen mit dem Server migriert. Für einige Anwendungen sind jedoch andere Migrationsmethoden als die Migration und Modernisierung möglicherweise besser für die Migration geeignet. Für Active Directory können Sie im Fall von Hybridumgebungen, in denen der lokale Standort mit Ihrer Azure-Umgebung verbunden ist, Ihr Verzeichnis in Azure erweitern, indem Sie zusätzliche Domänencontroller in Azure hinzufügen und die Active Directory-Replikation einrichten. Wenn Sie zu einer isolierten Umgebung in Azure migrieren, die eigene Domänencontroller erfordert (oder Anwendungen in einer Sandboxumgebung testen), können Sie Server mit dem Migrations- und Modernisierungstool migrieren.

Kann ich mein Betriebssystem während der Migration aktualisieren?

Das Migrations- und Modernisierungstool unterstützt derzeit nur Migrationen für identische Betriebssysteme. Das Tool unterstützt kein Upgrade der Betriebssystemversion während der Migration. Der migrierte Computer weist das gleiche Betriebssystem wie der Quellcomputer auf.

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

Zum Migrieren von VMware-VMs mithilfe der VMware-Migration mit oder ohne Agent müssen ESXi-Hosts, auf denen sich VMs befinden, von vCenter Server verwaltet werden. Wenn Sie nicht über vCenter Server verfügen, können Sie VMware-VMs migrieren, indem Sie sie als physische Server migrieren. Weitere Informationen

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

Die Migrations- und Modernisierungsfunktionen unterstützen derzeit nur Migrationen in identische VMs. Das Konsolidieren von Servern oder ein Upgrade des Betriebssystems im Rahmen der Migration wird nicht unterstützt.

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 virtuellen Azure-Computern 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 virtuellen Computers erhalten. Sie können das Migrations- und Modernisierungstool 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. Die Migration Ihrer Anwendungen zu Azure-Instanzen, die eine neuere Version von Windows Server ausführen, ist die empfohlene Vorgehensweise, um sicherzustellen, dass Sie die Flexibilität und Zuverlässigkeit der Azure-Cloud effektiv nutzen.

Wenn Sie sich dennoch für die Migration von Windows Server 2003 zu Azure entscheiden, können Sie das Migrations- und Modernisierungstool verwenden, wenn es sich bei Ihrem Windows-Server um eine VM unter VMware oder Hyper-V handelt. Lesen Sie diesen Artikel, um die Windows Server 2003-Computer auf die Migration vorzubereiten.

VMware-Migration ohne Agent

Wie funktioniert eine Migration ohne Agent?

Das Migrations- und Modernisierungstool bietet Replikationsoptionen ohne Agent für die Migration von VMware-VMs und Hyper-V-VMs unter Windows oder Linux. Das Tool bietet auch eine weitere Agent-basierte Replikationsoption für Windows- und Linux-Server, die zum Migrieren physischer Server sowie von x86-/x64-VMs für VMware, Hyper-V, AWS, GCP usw. verwendet werden kann. Die Agent-basierte Replikationsoption erfordert die Installation von Agent-Software auf dem zu migrierenden Server bzw. virtuellen Computer, während bei der Option ohne Agent keine Software auf den virtuellen Computern selbst installiert werden muss, was gegenüber der Agent-basierten Replikationsoption zusätzlichen Komfort und Einfachheit bietet.

Die Replikationsoption ohne Agent funktioniert mithilfe von Mechanismen, die vom Virtualisierungsanbieter (VMware, Hyper-V) bereitgestellt werden. Im Fall von virtuellen VMware-Computern verwendet der Replikationsmechanismus ohne Agent VMware-Momentaufnahmen und die VMware-Nachverfolgungstechnologie für geänderte Blöcke, um Daten von Datenträgern virtueller Computer zu replizieren. Dieser Mechanismus ähnelt dem Mechanismus, der von vielen Sicherungsprodukten verwendet wird. Bei virtuellen Hyper-V-Computern verwendet der Replikationsmechanismus ohne Agent VM-Momentaufnahmen und die Änderungsnachverfolgungsfunktion des Hyper-V-Replikats, um Daten von Datenträgern virtueller Computer zu replizieren.

Wenn Replikation für einen virtuellen Computer konfiguriert ist, wird 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. Nach Abschluss der ersten Replikation für die VM geht der Replikationsprozess in eine inkrementelle Replikationsphase (Deltareplikation) über. In der inkrementellen Replikationsphase werden Datenänderungen, die seit dem letzten abgeschlossenen Replikationszyklus eingetreten sind, periodisch repliziert und auf die verwalteten Datenträger des Replikats angewendet, wodurch die Replikation mit den Änderungen auf der VM synchron gehalten wird. Im Fall von virtuellen VMware-Computern werden Änderungen zwischen Replikationszyklen mithilfe der VMware-Nachverfolgungstechnologie für geänderte Blöcke nachverfolgt. 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. Auf diese Weise müssen nur Daten repliziert werden, die seit dem letzten abgeschlossenen Replikationszyklen geändert wurden, um die Replikation für die VM synchron zu halten. Am Ende jedes Replikationszyklus wird die Momentaufnahme freigegeben und eine Momentaufnahmekonsolidierung für den virtuellen Computer ausgeführt. Analog dazu wird im Fall von virtuellen Hyper-V-Computern die Hyper-V-Replikatänderungsnachverfolgungs-Engine verwendet, um Änderungen zwischen aufeinanderfolgenden Replikationszyklen nachzuverfolgen.

Wenn Sie den Migrationsvorgang auf eine replizierende VM durchführen, können Sie die lokale VM herunterfahren und eine abschließende inkrementelle Replikation ausführen, um zu gewährleisten, dass kein Datenverlust auftritt. Beim Ausführen der Migration werden die dem virtuellen Computer entsprechenden verwalteten Datenträger des Replikats verwendet, um den virtuellen Computer in Azure zu erstellen.

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

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

Die Bandbreite für die Replikation von Daten in Azure hängt von einer Reihe von Faktoren ab und richtet sich danach, wie schnell die lokale Azure Migrate-Appliance die Daten lesen und in Azure 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 Grundlage des Datenvolumens berechnen, das im Vorgang verschoben werden muss, und des Zeitrahmens, in dem die anfängliche Replikation abgeschlossen werden soll (idealerweise sollte die anfängliche Replikation mindestens 3 bis 4 Tage vor dem eigentlichen Migrationsfenster abgeschlossen sein, damit Sie genügend Zeit haben, vor dem eigentlichen Zeitfenster eine Testmigration durchzuführen und die Ausfallzeit während des Zeitfensters auf ein Minimum zu beschränken).

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 mithilfe der Azure Migrate-Appliance für die VMware-Replikation ohne Agent drosseln?

Sie können die Replikation mithilfe von NetQosPolicy drosseln. Beachten Sie, dass diese Drosselung nur für die ausgehenden Verbindungen aus der Azure Migrate Appliance gilt. Beispiel:

Das in der NetQosPolicy zu verwendende AppNamePrefix ist „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 wird zum Verringern der Bandbreite und eine andere Aufgabe zum Erhöhen der Bandbreite verwendet. Hinweis: Vor dem Ausführen der folgenden Befehle müssen Sie die oben beschriebene NetQosPolicy erstellen.

#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

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 versuche, die VMs zu migrieren, werden mir nur VMs angezeigt, die einer der Appliances entsprechen.

Wenn mehrere Appliances eingerichtet sind, ist es erforderlich, dass es keine Überlappungen zwischen den VMs in den bereitgestellten vCenter-Konten gibt. 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.

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?

Lesen Sie diesen Artikel, um Ihre AWS EC2-Instanzen zu ermitteln, zu bewerten und zu Azure zu migrieren.

Wie funktioniert eine Agent-basierte Migration?

Zusätzlich zu den Agent-losen Migrationsoptionen für VMware-VMs und Hyper-V-VMs bietet das Migrations- und Modernisierungstool eine Agent-basierte Migrationsoption für die Migration von Windows- und Linux-Servern, die auf physischen Servern oder als x86-/x64-VMs unter VMware, Hyper-V, AWS, Google Cloud Platform usw. ausgeführt werden.

Bei der Agent-basierten Migrationsmethode wird auf dem zu migrierenden Server installierte Agent-Software verwendet, um Serverdaten in Azure zu replizieren. 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). Erfahren Sie mehr darüber, wie die Agent-basierte Migrationsoption funktioniert.

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?

Die Replikationsappliance sollte auf einem dedizierten Computer installiert werden. Die Replikationsappliance sollte nicht auf einem zu replizierenden Quellcomputer oder auf der Azure Migrate-Appliance (wird für die Ermittlung und Bewertung verwendet) installiert werden, die Sie unter Umständen bereits installiert haben. Weitere Einzelheiten finden Sie im Tutorial.

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 unter AWS unterstützt wird. Zum Migrieren von Workloads, die unter Amazon Linux ausgeführt werden, können Sie eine CentOS/RHEL-VM in Azure einrichten und die Workload, die auf dem AWS Linux-Computer ausgeführt wird, mithilfe eines relevanten Migrationsansatzes migrieren. Abhängig von der Workload gibt es z. B. möglicherweise workloadspezifische Tools zur Unterstützung der Migration – etwa für Datenbanken oder Bereitstellungstools im Fall von Webservern.

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

Die Bandbreite für die Replikation von Daten in Azure hängt von einer Reihe von Faktoren ab und richtet sich danach, wie schnell die lokale Azure Migrate-Appliance die Daten lesen und in Azure 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 Bereitstellungsplaner die Ermittlung der Umgebung für die Datenänderung unterstützen und die erforderliche Bandbreitenanforderung vorhersagen. Weitere Informationen finden Sie in diesem Artikel.

Hyper-V-Migration ohne Agent

Wie funktioniert eine Migration ohne Agent?

Das Migrations- und Modernisierungstool bietet Replikationsoptionen ohne Agent für die Migration von VMware-VMs und Hyper-V-VMs unter Windows oder Linux. Das Tool bietet auch eine zusätzliche Agent-basierte Replikationsoption für Windows- und Linux-Server, die zum Migrieren physischer Server sowie von x86-/x64-VMs für VMware, Hyper-V, AWS, GCP usw. verwendet werden kann. Die Agent-basierte Replikationsoption erfordert die Installation von Agent-Software auf dem Server/virtuellen Computer, der migriert werden soll, während bei der Option ohne Agent keine Software auf den virtuellen Computern selbst installiert werden muss, was gegenüber der Agent-basierten Replikationsoption zusätzlichen Komfort und Einfachheit bietet.

Die Replikationsoption ohne Agent funktioniert mithilfe von Mechanismen, die vom Virtualisierungsanbieter (VMware, Hyper-V) bereitgestellt werden. Bei virtuellen Hyper-V-Computern verwendet der Replikationsmechanismus ohne Agent VM-Momentaufnahmen und die Änderungsnachverfolgungsfunktion des Hyper-V-Replikats, um Daten von Datenträgern virtueller Computer zu replizieren.

Wenn Replikation für einen virtuellen Computer konfiguriert ist, wird 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. Nach Abschluss der ersten Replikation für die VM geht der Replikationsprozess in eine inkrementelle Replikationsphase (Deltareplikation) über. In der inkrementellen Replikationsphase werden Datenänderungen, die seit dem letzten abgeschlossenen Replikationszyklus eingetreten sind, periodisch repliziert und auf die verwalteten Datenträger des Replikats angewendet, wodurch die Replikation mit den Änderungen auf der VM synchron gehalten wird. Im Fall von virtuellen VMware-Computern werden Änderungen zwischen Replikationszyklen mithilfe der VMware-Nachverfolgungstechnologie für geänderte Blöcke nachverfolgt. 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. Auf diese Weise müssen nur Daten repliziert werden, die seit dem letzten abgeschlossenen Replikationszyklen geändert wurden, um die Replikation für die VM synchron zu halten. Am Ende jedes Replikationszyklus wird die Momentaufnahme freigegeben und eine Momentaufnahmekonsolidierung für den virtuellen Computer ausgeführt. Analog dazu wird im Fall von virtuellen Hyper-V-Computern die Hyper-V-Replikatänderungsnachverfolgungs-Engine verwendet, um Änderungen zwischen aufeinanderfolgenden Replikationszyklen nachzuverfolgen.

Wenn Sie den Migrationsvorgang auf eine replizierende VM durchführen, können Sie die lokale VM herunterfahren und eine abschließende inkrementelle Replikation ausführen, um zu gewährleisten, dass kein Datenverlust auftritt. Beim Ausführen der Migration werden die dem virtuellen Computer entsprechenden verwalteten Datenträger des Replikats 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?

Die Bandbreite für die Replikation von Daten in Azure hängt von einer Reihe von Faktoren ab und richtet sich danach, wie schnell die lokale Azure Migrate-Appliance die Daten lesen und in Azure 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 Grundlage des Datenvolumens berechnen, das im Vorgang verschoben werden muss, und des Zeitrahmens, in dem die anfängliche Replikation abgeschlossen werden soll (idealerweise sollte die anfängliche Replikation mindestens 3 bis 4 Tage vor dem eigentlichen Migrationsfenster abgeschlossen sein, damit Sie genügend Zeit haben, vor dem eigentlichen Zeitfenster eine Testmigration durchzuführen und die Ausfallzeit während des Zeitfensters auf ein Minimum zu beschränken).

Nächste Schritte

Sehen Sie sich die Übersicht zu Azure Migrate an.