Freigeben über

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:

Vorsicht

Dieser Artikel bezieht sich auf CentOS, eine Linux-Distribution, die sich einen End-of-Life-Status aufweist. Überlegen Sie sich Ihre Nutzung und planen Sie entsprechend. 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 agentlose und agentbasierte 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 Vorgang führt eine anfängliche Replikation Ihrer VM-/Serverdaten nach Azure durch. Nach Abschluss der ersten Replikation wird eine fortlaufende Replikation (Delta-Synchronisierung) eingerichtet, die inkrementelle Daten zu Azure migriert. Nachdem der Vorgang die Delta-Synchronisierungsphase 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.

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

Agentbasierte 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:

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

Die agentlose Migration bietet mehr Komfort und Einfachheit als agentbasierte 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 Regionen werden für die Migration mit Azure Migrate unterstützt?

Überprüfen Sie die unterstützten Regionen für öffentliche und regierungsbasierte Clouds.

Kann ich dasselbe Azure Migrate Projekt verwenden, um zu mehreren Regionen zu migrieren?

Obwohl Sie Bewertungen für mehrere Regionen in einem Azure Migrate Projekt erstellen können, kann ein Azure Migrate Projekt zum Migrieren von Servern zu nur einer Azure Region verwendet werden. 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 agentlosen 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 ich dasselbe Azure Migrate Projekt verwenden, um zu mehreren Abonnements zu migrieren?

Ja, Sie können dasselbe Azure Migrate Projekt verwenden, um zu mehreren Abonnements mit demselben Azure Mandanten in derselben 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 Installation des Hyper-V Providers für agentlose Hyper-V Migrationen.

Unterstützt Azure Migrate Azure Resource Graph?

Derzeit ist Azure Migrate nicht in Azure Resource Graph integriert. Es unterstützt das Ausführen von Azure Resource Graph-bezogenen Abfragen.

Wie werden die Daten aus einer lokalen Umgebung an Azure übermittelt? Werden sie vor der Übertragung verschlüsselt?

Bei der agentlosen 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 von Azure Migrate erstellten Recovery Services-Tresor für Notfallwiederherstellungsszenarien verwenden?

Die Verwendung des von Azure Migrate erstellten Recovery Services-Tresors für Wiederherstellungsszenarien wird nicht empfohlen, da dies zu Fehlern beim Starten von Replikationen 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. Test Migration funktioniert, indem Sie eine Sandkastenumgebung in Azure verwenden können, um die virtuellen Computer 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.

Screenshot, der den Unterschied zwischen einem Test und einer tatsächlichen Migration zeigt.

Gibt es eine Rollbackoption für Azure Migrate?

Sie können die Option TestMigration verwenden, um Ihre Anwendungsfunktionalität und -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 (User Acceptance Testing, UAT) für die Testmigration Fehler auftreten, können Sie die endgültige Migration verschieben und die Quell-VM/den Server weiter betreiben und nach 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 wird, können Sie kein Rollback von Azure zu Ihrer lokalen Umgebung ausfü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 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, indem mithilfe replizierter Daten ein Test Azure VM erstellt wird. 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 virtuelle Testcomputer 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 virtuellen Computer/Server erfolgreich migriert haben, können Sie den virtuellen Computer anzeigen und verwalten, indem Sie zur Seite "Migrationen ausführen> " navigieren. Die Ausführungsphase wird als Abschluss angezeigt, und der Status wird abgeschlossen. 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 Azure VMs der Generation 1 auf Azure migrieren?

Das Tool Migration und Modernisierung migriert UEFI-basierte Maschinen zu Azure als Azure VMs der Generation 2. Wenn Sie sie als VMs der Azure Generation 1 migrieren möchten, konvertieren Sie den Starttyp vor dem Starten der Replikation in BIOS, und verwenden Sie dann das Tool Migration und Modernisierung, um zu Azure zu migrieren.

Konvertiert Azure Migrate UEFI-basierte Maschinen in BIOS-basierte Maschinen und migriert sie zu Azure als Azure-VMs der Generation 1?

Das Tool Migration und Modernisierung migriert alle UEFI-basierten Maschinen als Generation 2 Azure VMs nach Azure. Die Konvertierung von UEFI-basierten VMs in BIOS-basierte VMS wird nicht mehr unterstützt. Alle BIOS-basierten Computer werden auf Azure ausschließlich als Azure-Generation 1-VMs 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.

Vorsicht

In diesem Artikel wird auf Windows Server Versionen verwiesen, die das Ende des Supports (EOS) erreicht haben.Microsoft hat den Support für die folgenden Betriebssysteme offiziell beendet:

  • Windows Server 2003
  • Windows Server 2008 (einschließlich SP2 und R2 SP1)
  • Windows Server 2012
  • Windows Server 2012 R2 als Ergebnis garantiert Azure Migrate keine konsistenten oder zuverlässigen Ergebnisse für diese Betriebssystemversionen. Kunden können Probleme haben und werden dringend empfohlen, vor beginn der Migration auf eine unterstützte Windows Server-Version zu aktualisieren.
Für UEFI-basierte Computer unterstützte Betriebssysteme Agentless VMware nach Azure Agentenloser Hyper-V zu Azure Agent-basierte VMware, physische und andere Clouds zu Azure
Windows Server 2025, 2022, 2019, 2016, 2012 R2, 2012 J J J
Windows 11 Pro, Windows 11 Enterprise J J J
Windows 10 Pro, Windows 10 Enterprise J J J
SUSE Linux Enterprise Server 15 SP1, SP2, SP3, SP4, SP5, SP6 J J J
SUSE Linux Enterprise Server 12 SP4 J J J
Ubuntu Server 24.04, 22.04 LTS, 20.04 LTS, 18.04 LTS, 16.04 LTS J J J
RHEL 9.x, 8.1, 8.0, 7.8, 7.7, 7.6, 7.5, 7.4, 7.0, 6.x J J J
CentOS Stream J J J
Oracle Linux 9, 8, 7.7-CI, 7.7, 6 J J J

Kann ich Active Directory Domänencontroller mithilfe 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.

Für Active Directory kann die Art 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 Active Directory Replikation einrichten. Sie können das Migrations- und Modernisierungs- Tool verwenden, wenn Sie:

  • Migrieren in eine isolierte Umgebung in Azure, die eigene Domänencontroller erfordert.
  • Anwendungen in einer Sandkastenumgebung testen.

Kann ich mein Betriebssystem während der Migration aktualisieren?

Das Tool Migration und Modernisierung unterstützt jetzt Windows Betriebssystemupgrades während der Migration. Diese Option ist derzeit nicht für CSV-Dateien verfügbar. Weitere Informationen zu 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 drei Jahre nach Ablauf des Supports ohne zusätzliche Kosten über den Kosten für die Ausführung des virtuellen Computers erhalten. Sie können das Tool Migration und Modernisierung verwenden, um Ihre Windows Server 2008- und 2008 R2-Workloads zu migrieren.

Wie kann ich Windows Server 2003 migrieren, der auf VMware/Hyper-V läuft, nach Azure?

Windows Server 2003 erweiterte Unterstützung endete am 14. Juli 2015. Das Azure-Support Team hilft weiterhin beim Beheben von Problemen, die Windows Server 2003 auf Azure betreffen. Diese Unterstützung ist jedoch auf Probleme beschränkt, die keine Problembehandlung oder Patches auf Betriebssystemebene erfordern.

Es wird empfohlen, Ihre Anwendungen zu Azure Instanzen zu 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 weiterhin Windows Server 2003 zu Azure migrieren möchten, können Sie das Tool Migration und Modernisierung verwenden, wenn Ihre Windows Server Bereitstellung eine VM ist, die auf VMware oder Hyper-V ausgeführt wird. Weitere Informationen finden Sie unter Bereiten Sie Ihre Windows Server 2003-Computer für die Migration.

VMware-Migration ohne Agent

Wie funktioniert eine Migration ohne Agent?

Das Tool Migration und Modernisierung bietet agentlose Replikationsoptionen für die Migration von VMware und Hyper-V VMs, die Windows oder Linux ausführen. Das Tool bietet eine weitere agentbasierte Replikationsoption für Windows- und Linux-Server. Diese andere Option kann verwendet werden, um physische Server und x86/x64-VMs auf Anbietern wie VMware, Hyper-V, AWS und GCP zu migrieren.

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 Agentless-Replikationsoption verwendet Mechanismen, die vom Virtualisierungsanbieter (VMware oder 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 Agentlose 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 nach.

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 ausgeführt wird, werden die replikatverwalteten Datenträger, die der VM entsprechen, verwendet, um den virtuellen Computer in Azure zu erstellen.

Informationen zu den ersten Schritten finden Sie in den Lernprogrammen VMware agentless migration und Hyper-V agentless 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 drossele ich die Replikation bei Verwendung der Azure Migrate Appliance für die agentlose VMware-Replikation?

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

Beispielsweise ist der in AppNamePrefix zu verwendende NetQosPolicy Wert GatewayWindowsService.exe. Sie können eine Richtlinie für die Azure Migrate Appliance erstellen, um den Replikationsdatenverkehr von der Appliance zu drosseln, indem Sie eine Richtlinie wie diese 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 Windows geplanten Aufgaben verwenden, 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 umfangreiche agentlose Migration von ASP.NET Web-Apps ausführen, die auf IIS-Webservern ausgeführt werden, 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?

Überblicken Sie Entdecken, bewerten und migrieren Sie VMs von Amazon Web Services (AWS) zu Azure.

Wie funktioniert eine Agent-basierte Migration?

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

Die agentbasierte Migrationsmethode verwendet Agentsoftware, 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 Replikations-Appliance unterscheidet sich von der Azure Migrate Discovery Appliance 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 im Artikel Migration von Maschinen als physische Server nach 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 drehen. 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 agentbasierten Replikationsmethode kann Azure Site Recovery Bereitstellungsplaner dabei helfen, die Umgebung für die Datenabwanderung zu profilieren und die erforderliche Bandbreitenanforderung vorherzusagen. Um mehr zu erfahren, lesen Sie Planen der VMware-Bereitstellung.

Agentlose Hyper-V Migration

Wie funktioniert eine Migration ohne Agent?

Das Tool Migration und Modernisierung bietet agentlose Replikationsoptionen für die Migration von VMware und Hyper-V VMs, die Windows oder Linux ausführen. Das Tool bietet eine weitere agentbasierte 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 Agentless-Replikationsoption funktioniert mithilfe von Mechanismen, die vom Virtualisierungsanbieter (VMware oder Hyper-V) bereitgestellt werden. Bei Hyper-V VMs repliziert der agentlose 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 für Hyper-V VMs das Hyper-V Replikatänderungsnachverfolgungsmodul 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 Lernprogramm Hyper-V agentless 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.

Wie kann ich einen Rollback durchführen, wenn während des Migrationsprozesses ein Fehler auftritt?

Azure Migrate unterstützt derzeit kein Rollback, was bedeutet, dass Benutzer nach der Migration nicht zur lokalen Umgebung zurückkehren können.

Welche Strategien verwende ich, um ausfallzeiten während der Migration zu reduzieren?

Übung Wie es hilft Nutzen
Verwenden Sie die Agent-Based Replikation für die kontinuierliche Synchronisierung Es repliziert fortlaufend lokale VMs auf Azure Dies hilft Ihnen, mit minimalem Datenverlust (RPO von ein paar Sekunden) überzugehen und Ausfallzeiten (RTO von ein paar Minuten) zu reduzieren.
Durchführen von Testmigrationen mit Azure Migrate können Sie Testmigrationen ausführen, ohne dass sich dies auf die Produktions-VM auswirkt. Sie überprüfen den Erfolg des Startvorgangs, die Netzwerkkonnektivität und die Anwendungsfunktionalität in Azure vor dem endgültigen Cutover-Vorgang.
Verwenden Sie Replikationsgruppen für die Dependency-Aware-Migration Sie gruppieren virtuelle Computer basierend auf Anwendungs- oder Dienstabhängigkeiten und migrieren sie zusammen. Dadurch wird das Risiko unterbrochener Abhängigkeiten während der Migration verringert und hilft, die Dienste reibungslos zu halten.
Planen Sie Umstellungen während der Wartungszeitfenster **: Sie planen den endgültigen Übernahmevorgang (Wechseln von Benutzern zur Azure gehosteten App) während eines bekannten Zeitraums mit geringem Datenverkehr. Dies minimiert die Auswirkungen des Benutzers und gibt bei Bedarf Zeit für das Rollback.
Durchführen einer phasenweisen Migration Sie migrieren und modernisieren Workloads in Phasen statt alle gleichzeitig. Kleinere Änderungen minimieren das Risiko und tragen dazu bei, dienste während des gesamten Prozesses verfügbar zu halten.

Wie kann ich den Erfolg meiner Cloudmigrationsausführung messen?

Maßeinheit BESCHREIBUNG
Übernahmeerfolgsrate Prozentsatz der Workloads, die ohne Rollback oder Probleme erfolgreich migriert wurden.
Ausfallzeitsdauer Die gesamte ungeplante Ausfallzeit tritt während der Übernahme auf; das Ziel ist minimal oder null.
Datenintegrität Überprüfung nach der Migration der Vollständigkeit und Genauigkeit von Daten.
Anwendungsfunktionalität Nach der Migration funktionieren Apps genau wie erwartet (Funktionstests und UAT-Pass).
Zeitrahmen für den Abschluss der Migration Ist im Vergleich zur geplanten Einhaltung des Migrationszeitplans.

Verwandte Inhalte

  • Last updated on