Migrationsarchitektur für Agents

In diesem Artikel werden die Replikationskonzepte beschrieben, wenn Sie virtuelle VMware-Computer (VMs) mithilfe der Migrationsmethode ohne Agent in Azure Migrate migrieren.

Replikationsprozess

Die Replikationsoption ohne Agent funktioniert mithilfe von VMware-Momentaufnahmen und der VMware CBT-Technologie (VMware Changed Block Tracking), um Daten von Datenträgern virtueller Computer zu replizieren. Das folgende Blockdiagramm zeigt Ihnen die Schritte, die beim Migrieren Ihrer virtuellen Computer mithilfe von Azure Migrate erforderlich sind.

Wenn Sie die Replikation für einen virtuellen Computer konfigurieren, durchläuft sie eine anfängliche Replikationsphase. Während dieser Phase erstellt Azure Migrate eine VM-Momentaufnahme. Der Dienst repliziert dann eine vollständige Kopie von Daten aus den Momentaufnahmendatenträgern auf verwaltete Datenträger in Ihrem Zielabonnement.

Nach Abschluss der ersten Replikation für die VM geht der Replikationsprozess in eine inkrementelle Replikationsphase (Deltareplikation) über. In dieser Phase werden Datenänderungen, die seit Beginn des letzten abgeschlossenen Replikationszyklus aufgetreten sind, repliziert und in die replikatverwalteten Datenträger geschrieben. Dieser Teil des Prozesses synchronisiert die Replikation mit Änderungen auf dem virtuellen Computer.

Azure Migrate verwendet die VMware CBT-Technologie, um Änderungen zwischen Replikationszyklen nachzuverfolgen. Zu Beginn eines Replikationszyklus übernimmt Azure Migrate eine VM-Momentaufnahme. Der Dienst verwendet CBT, um die Änderungen zwischen der aktuellen Momentaufnahme und der letzten erfolgreich replizierten Momentaufnahme abzurufen. Nur die Daten, die seit dem vorherigen abgeschlossenen Replikationszyklus geändert wurden, werden repliziert, um die Replikation für den virtuellen Computer synchron zu halten. Am Ende jedes Replikationszyklus wird die Momentaufnahme freigegeben und Azure Migrate führt eine Momentaufnahmekonsolidierung für den virtuellen Computer aus.

Wenn Sie den Migrationsvorgang auf einer replizierenden VM ausführen, repliziert ein Deltareplikationszyklus bei Bedarf die verbleibenden Änderungen seit dem letzten Replikationszyklus. Nach Abschluss des On-Demand-Zyklus erstellt Azure Migrate den virtuellen Computer in Azure mithilfe der replikatverwalteten Datenträger, die der VM entsprechen.

Bevor Sie die Migration auslösen, müssen Sie den lokalen virtuellen Computer herunterfahren. Durch das Herunterfahren des virtuellen Computers wird der Datenverlust während der Migration verhindert.

Nachdem die Migration erfolgreich war und der virtuelle Computer in Azure neu gestartet wird, stellen Sie sicher, dass Sie die Replikation des virtueller Computers beenden. Wenn Sie die Replikation beenden, werden die Zwischendatenträger (Seed-Datenträger) gelöscht, die während der Datenreplikation erstellt wurden. Sie vermeiden dann zusätzliche Gebühren im Zusammenhang mit den Speichertransaktionen auf diesen Datenträgern.

Replikationszyklen

Ein Replikationszyklus ist der regelmäßige Prozess der Übertragung von Daten aus einer lokalen Umgebung auf verwaltete Azure-Datenträger. Ein vollständiger Replikationszyklus besteht aus den folgenden Schritten:

1. Erstellen Sie eine VMware-Momentaufnahme für jeden Datenträger, der dem virtuellen Computer zugeordnet ist.
2. Laden Sie Daten in ein Protokollspeicherkonto in Azure hoch.
3. Geben Sie die Momentaufnahme frei.
4. Konsolidieren Sie VMware-Datenträger.

Ein Zyklus ist abgeschlossen, nachdem die Datenträger konsolidiert wurden.

Komponenten für die Replikation

Eine Azure Migrate Appliance verfügt über die folgenden lokalen Komponenten, die für die Replikation verantwortlich sind:

• Datenreplikations-Agent
• Gateway-Agent

In der folgenden Tabelle sind die Azure-Komponenten zusammengefasst, die erstellt werden, wenn Sie Methode ohne Agent der VMware VM-Migration verwenden.

Erforderliche Berechtigungen

Wenn Sie die Replikation zum ersten Mal starten, muss der angemeldete Benutzer über die folgenden Rollen verfügen:

• Besitzer oder Mitwirkender und Benutzerzugriffsadmin für die Ressourcengruppe und Zielressourcengruppe des Azure Migrate Projekts

Für die nachfolgenden Replikationen muss der angemeldete Benutzer über die folgenden Rollen verfügen:

• Besitzer oder Mitwirkender in der Ressourcengruppe des Azure Migrate-Projekts und der Zielressourcengruppe

Zusätzlich zu den vorherigen Rollen benötigt der angemeldete Benutzer die folgende Berechtigung auf Abonnementebene: Microsoft.Resources/subscriptions/resourceGroups/read

Datenintegrität

Es gibt zwei Phasen in jedem Replikationszyklus, um die Datenintegrität zwischen dem lokalen Datenträger (Quelldatenträger) und dem Replikatdatenträger in Azure (Zieldatenträger) sicherzustellen.

Überprüfen der Replikation

Die erste Stufe überprüft, ob jeder Sektor, der sich auf dem Quelldatenträger geändert hat, auf den Zieldatenträger repliziert wird. Sie führen die Überprüfung mithilfe von Bitmaps durch.

Der Quelldatenträger ist in Sektoren von 512 Bytes unterteilt. Jeder Sektor auf dem Quelldatenträger wird einem Bit in der Bitmap zugeordnet. Wenn die Datenreplikation gestartet wird, erstellt Azure Migrate eine Bitmap für alle geänderten Blöcke (im Delta-Zyklus) auf dem Quelldatenträger, der repliziert werden muss. Ebenso erstellt Azure Migrate, wenn die Daten an den Azure-Zieldatenträger übertragen werden, eine Bitmap.

Nachdem die Datenübertragung erfolgreich abgeschlossen wurde, vergleicht der Clouddienst die beiden Bitmaps, um sicherzustellen, dass kein geänderter Block vergessen wurde. Wenn zwischen den Bitmaps ein Konflikt besteht, wird der Zyklus als fehlgeschlagen betrachtet. Da jeder Zyklus neu synchronisiert wird, wird der Konflikt im nächsten Zyklus behoben.

Überprüfen replizierter Daten

Die zweite Stufe stellt sicher, dass die Daten, die auf die Azure-Datenträger übertragen werden, mit den Daten identisch sind, die von den Quelldatenträgern repliziert wurden.

Jeder geänderte Block, der hochgeladen wird, wird komprimiert und verschlüsselt, bevor er als Blob in das Protokollspeicherkonto geschrieben wird. Azure Migrate berechnet die Prüfsumme dieses Blocks vor der Komprimierung. Diese Prüfsumme wird zusammen mit den komprimierten Daten als Metadaten gespeichert.

Bei der Dekomprimierung berechnet Azure Migrate die Prüfsumme für die Daten und vergleicht sie mit der in der Quellumgebung berechneten Prüfsumme. Wenn ein Konflikt vorliegt, werden die Daten nicht auf die Azure-Datenträger geschrieben, und der Zyklus wird als fehlgeschlagen betrachtet. Da jeder Zyklus neu synchronisiert wird, wird der Konflikt im nächsten Zyklus behoben.

Sicherheit

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

Replikationsstatus

Wenn für einen virtuellen Computer eine Replikation (Datenkopie) durchgeführt wird, gibt es mehrere mögliche Zustände:

• Erste Replikation (in Warteschlange): Der virtuelle Computer wird für die Replikation oder Migration in die Warteschlange gestellt, da andere virtuelle Computer möglicherweise die lokalen Ressourcen während der Replikation oder Migration nutzen. Nachdem die Ressourcen frei sind, wird dieser virtuelle Computer verarbeitet.
• Erste Replikation wird ausgeführt: Der virtuelle Computer wird für die erste Replikation geplant.
• Erste Replikation: Für die VM wird eine erste Replikation ausgeführt. Wenn der virtuelle Computer der ersten Replikation unterzogen wird, können Sie nicht mit der Testmigration und der Produktionsmigration fortfahren. Sie können die Replikation nur in dieser Phase beenden.
• Erste Replikation (x %): Die erste Replikation ist aktiv und hat den Fortschritt um den angezeigten Prozentsatz erreicht.
• Deltasynchronisierung: Die VM durchläuft möglicherweise einen Deltareplikationszyklus, der die verbleibenden Daten seit dem letzten Replikationszyklus repliziert.
• Anhalten in Bearbeitung: Der virtuelle Computer durchläuft einen aktiven Deltareplikationszyklus und wird angehalten.
• Angehalten: Die Replikationszyklen werden angehalten. Sie können die Replikationszyklen fortsetzen, indem Sie den Vorgang ausführen, um die Replikation fortzusetzen.
• Fortsetzen in der Warteschlange: Der virtuelle Computer wird für das Fortsetzen der Replikation in die Warteschlange eingereiht, da andere VMs derzeit die lokalen Ressourcen nutzen.
• Fortsetzen in Bearbeitung (x %): Der Replikationszyklus wird für den virtuellen Computer fortgesetzt, der Fortschritt beträgt den angezeigten Prozentsatz.
• Beenden der Replikation in Bearbeitung: Replikationsbereinigung wird ausgeführt. Wenn Sie die Replikation beenden, werden die verwalteten Zwischendatenträger (Seed-Datenträger), die während der Replikation erstellt wurden, gelöscht. Weitere Informationen zum Beenden der Replikation finden Sie weiter unten in diesem Artikel.
• Abschließen der Migration in Bearbeitung: Migrationsbereinigung wird ausgeführt. Wenn Sie die Migration abschließen, werden die verwalteten Zwischendatenträger (Seed-Datenträger) gelöscht, die während der Replikation erstellt wurden. Weitere Informationen zum Abschließen der Replikation finden Sie weiter unten in diesem Artikel.
• – : Wenn der virtuelle Computer erfolgreich migriert oder die Replikation beendet wird, ändert sich der Status in einen Gedankenstrich. Nachdem Sie die Migration abgeschlossen oder die Replikation beendet haben und der Vorgang erfolgreich abgeschlossen wurde, wird der virtuelle Computer aus der Liste der replizierenden Computer entfernt. Sie finden den virtuellen Computer auf der Registerkarte für virtuelle Computer im Replikations-Assistenten.

Alle anderen Status

• Fehler bei der ersten Replikation: Die anfänglichen Daten konnten nicht für die VM kopiert werden. Folgen Sie den Anleitungen zur Behebung des Problems.

• Reparatur ausstehend: Es gab ein Problem im Replikationszyklus. Sie können den Link auswählen, um mögliche Ursachen und Aktionen zu verstehen, die zur Behebung verwendet werden können (sofern zutreffend). Wenn Sie sich dafür entschieden haben, die Replikation automatisch reparieren zu lassen, indem Sie Ja ausgewählt haben, als Sie die Replikation des virtuellen Computers initiiert haben, startet das Tool einen Reparaturversuch. Wählen Sie andernfalls den virtuellen Computer aus, und wählen Sie dann Replikation reparieren aus.

  Wenn Sie sich nicht für die automatische Reparaturreplikation entscheiden oder der Reparaturschritt für Sie nicht funktioniert hat, beenden Sie die Replikation für den virtuellen Computer. Setzen Sie das CBT auf dem virtuellen Computer zurück, und konfigurieren Sie dann die Replikation neu.

• Replikation reparieren (in Warteschlange): Der virtuelle Computer wird für die Reparatur der Replikation in die Warteschlange eingereiht da andere virtuelle Computer die lokalen Ressourcen nutzen. Nachdem die Ressourcen frei sind, wird der virtuelle Computer für die Reparaturreplikation verarbeitet.

• Erneut synchronisieren ( x%): Für die VM erfolgt erneute Synchronisierung der Daten. Diese erneute Synchronisierung kann auftreten, wenn während der Datenreplikation ein Problem aufgetreten ist oder ein Konflikt auftritt.

• Fehler beim Beenden der Replikation/Abschließen der Migration: Wählen Sie den Link aus, um die möglichen Ursachen für Fehler und Aktionen zur Behebung (wenn zutreffend) zu verstehen.

Status der Testmigration oder Produktionsmigration

• Testmigration steht aus: Der virtuelle Computer befindet sich in der Delta-Replikationsphase. Sie können jetzt eine Testmigration (oder Produktionsmigration) durchführen.
• Bereinigung der Testmigration ausstehend: Führen Sie nach Abschluss der Testmigration eine Bereinigung aus, um Gebühren in Azure zu vermeiden.
• Bereit für die Migration: Der virtuelle Computer ist bereit für die Migration zu Azure.
• Migration in Bearbeitung (in Warteschlange): Der virtuelle Computer wird für die Migration in die Warteschlange eingereiht, da andere virtuelle Computer die lokalen Ressourcen während der Replikation (oder Migration) nutzen. Nachdem die Ressourcen frei sind, wird der virtuelle Computer verarbeitet.
• Migration/Testmigration in Bearbeitung: Der virtuelle Computer wird einer Testmigration oder einer Produktionsmigration unterzogen. Sie können den Link auswählen, um den laufenden Migrationsauftrag zu überprüfen.
• Datum, Zeitstempel: Die Testmigration oder Produktionsmigration ist zu diesem Datum und zu dieser Uhrzeit durchgeführt worden.
• –: Die erste Replikation ist in Bearbeitung. Sie können eine Testmigration oder eine Produktionsmigration durchführen, nachdem der Replikationsprozess zu einer Deltasynchronisierungsphase (inkrementelle Replikation) wechselt.

Alle anderen Status

• Abgeschlossen mit Informationen: Der Testmigrations- oder Produktionsmigrationsauftrag wurde mit Informationen abgeschlossen. Sie können den Link auswählen, um den letzten Migrationsauftrag auf mögliche Ursachen und Aktionen zu überprüfen, die zur Reparatur ausgeführt werden sollen (sofern zutreffend).
• Fehler: Fehler beim Testmigrations- oder Produktionsmigrationsauftrag. Sie können den Link auswählen, um den letzten Migrationsauftrag auf mögliche Ursachen und Aktionen zu überprüfen, die zur Reparatur ausgeführt werden sollen.

Planungslogik

Die anfängliche Replikation wird geplant, wenn Sie die Replikation für einen virtuellen Computer konfigurieren. Darauf folgen inkrementelle Replikationen (Deltareplikation).

Deltareplikationszyklen werden wie folgt geplant:

• Der erste Deltareplikationszyklus wird unmittelbar nach Abschluss des ersten Replikationszyklus geplant.

• Die nächsten Deltareplikationszyklen werden gemäß der folgenden Logik geplant: min[max[1 hour, (<Previous delta replication cycle time>/2)], 12 hours].

  Das heißt, die nächste Deltareplikation wird für nicht vor 1 Stunde und nicht später als 12 Stunden geplant. Beispiel: Wenn ein Deltareplikationszyklus für eine VM 4 Stunden dauert, wird der nächste Deltareplikationszyklus in 2 Stunden geplant, nicht in der nächsten Stunde.

  Hinweis

  Die Planungslogik ist nach Abschluss der ersten Replikation anders. Der erste Deltazyklus wird unmittelbar nach Abschluss der ersten Replikation geplant. Nachfolgende Zyklen folgen der Planungslogik.

• Wenn Sie die Migration auslösen, tritt vor der Migration ein Deltadeplikationszyklus bei Bedarf (Pre-Failover) für den virtuellen Computer auf.

Priorisierung

Hier sehen Sie die Priorisierung von VMs für verschiedene Phasen der Replikation:

• Laufende VM-Replikationen werden gegenüber geplanten Replikationen (neue Replikationen) priorisiert.
• Der bedarfsbasierte Deltadeplikationszyklus (Pre-Failover) hat die höchste Priorität, gefolgt vom ersten Replikationszyklus. Der Deltareplikationszyklus hat die niedrigste Priorität.

Immer wenn Sie einen Migrationsvorgang auslösen, wird der Replikationszyklus bei Bedarf für den virtuellen Computer geplant. Andere laufende Replikationen müssen warten, wenn sie mit Ressourcen konkurrieren.

Zwänge

Die folgenden Einschränkungen tragen dazu bei, dass Sie die IOPS-Grenzwerte für die Speicherbereichsnetzwerke nicht überschreiten:

• Jede Azure Migrate Appliance unterstützt die parallele Replikation von 52 Datenträgern.
• Jeder ESXi-Host unterstützt acht Datenträger. Jeder ESXi-Host verfügt über einen NFC-Puffer von 32 MB. Sie können also 8 Datenträger auf dem Host planen. (Jeder Datenträger benötigt 4 MB Puffer für die Reaktion auf Vorfälle und Notfallwiederherstellung.)
• Jeder Datenspeicher kann maximal 15 Datenträgermomentaufnahmen enthalten. Die einzige Ausnahme ist, wenn einem virtuellen Computer mehr als 15 Datenträger angefügt sind.

Replikation für horizontale Skalierung

Azure Migrate unterstützt die gleichzeitige Replikation von 500 virtuellen Computern. Wenn Sie beabsichtigen, mehr als 300 virtuelle Computer zu replizieren, müssen Sie eine Appliance für die horizontale Skalierung bereitstellen. Die Appliance für die horizontale Skalierung ähnelt einer primären Azure Migrate Appliance, besteht aber nur aus einem Gateway-Agent, um die Datenübertragung zu Azure zu vereinfachen.

Das folgende Diagramm zeigt die empfohlene Methode zur Verwendung der Appliance für die horizontale Skalierung.

Sie können die Appliance für die horizontale Skalierung jederzeit bereitstellen, nachdem Sie die primäre Appliance konfiguriert haben, sie ist jedoch erst erforderlich, wenn 300 VMs gleichzeitig repliziert werden. Wenn 300 VMs gleichzeitig repliziert werden, müssen Sie die Appliance für die horizontale Skalierung bereitstellen, um den Vorgang fortzusetzen.

Beenden der Replikation oder Abschließen einer Migration

Wenn Sie die Replikation beenden, werden die verwalteten Zwischendatenträger (Seed-Datenträger), die während der Replikation erstellt wurden, gelöscht. Sie können die Replikation nur während einer aktiven Replikation beenden. Sie können Migration abschließen auswählen, um die Replikation zu beenden, nachdem die VM migriert wurde.

Sie können den virtuellen Computer replizieren, für den die Replikation beendet wird, indem Sie die Replikation erneut aktivieren. Wenn die VM migriert wurde, können Sie die Replikation und Migration erneut fortsetzen.

Als bewährte Methode sollten Sie die Migration immer abschließen, nachdem der virtuelle Computer erfolgreich zu Azure migriert wurde. Diese Vorgehensweise stellt sicher, dass für Speichertransaktionen auf den zwischenverwalteten Datenträgern (Seed-Datenträger) keine zusätzlichen Gebühren anfallen.

In einigen Fällen dauert das Beenden der Replikation etwas. Der Grund: Wenn Sie die Replikation beenden, wird der fortlaufende Replikationszyklus abgeschlossen (nur wenn sich der virtuelle Computer in der Delta-Synchronisierung befindet), bevor die Artefakte gelöscht werden.

Auswirkung des Churn

Sie können die Menge der Datenübertragung in jedem Replikationszyklus minimieren, indem Sie dass sich die Daten so weit wie möglich falten, bevor Sie den nächsten Zyklus planen. 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.

Wenn der aktuelle Deltadeplikationszyklus aufgrund eines hohen Datenabflusses verzögert wird, kann die Initiierung des nachfolgenden Zyklus verzögert werden. Ein höheres Datenvolumen, das für einen bestimmten Datenträger repliziert werden soll, erweitert die zum Erstellen eines Wiederherstellungspunkts erforderliche Dauer. Daher dauert der letzte Migrationszyklus länger. Diese Situation führt zu einem erweiterten Fenster zum Herunterfahren der Quell-VM.

Wenn die Momentaufnahmegröße (aufgrund des Änderungsmusters) so stark zunimmt, dass die verfügbare Kapazität des Datenspeichers überschreitet, besteht die Gefahr, dass der Speicherplatz des Datenspeichers knapp wird. Diese Situation kann sich negativ auf Produktions-Workloads auswirken und dazu führen, dass die Quell-VM nicht mehr reagiert.

Um dieses Risiko zu minimieren, empfehlen wir, die Größe des Datenspeichers proaktiv zu erhöhen. Wenn mehrere VMs, die Sie replizieren, gleichzeitig über Datenträger in einem Datenspeicher mit geringer verfügbarer Kapazität verfügen, empfehlen wir, Migrationen jeweils für einen virtuellen Computer durchzuführen, um einen Ressourcenkonflikt zu vermeiden.

Verwaltung der Replikation

Drosselung

Sie können die Replikationsbandbreite mithilfe von NetQosPolicy erhöhen oder verringern. Der in AppNamePrefix zu verwendende NetQosPolicy-Wert ist GatewayWindowsService.exe.

Um den Replikationsdatenverkehr von der Azure Migrate-Appliance zu drosseln, können Sie eine Richtlinie wie das folgende Beispiel für die Appliance erstellen. Diese Richtlinie gilt für alle replizierenden VMs von der Azure Migrate Appliance gleichzeitig.

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

Sie können die Replikationsbandbreite auch nach einem Zeitplan erhöhen und verringern, indem Sie das Beispielskript verwenden.

Blackout-Fenster

Azure Migrate bietet einen konfigurationsbasierten Mechanismus, mit dem Sie das Zeitintervall angeben können, in dem keine Replikationen fortgesetzt werden sollen. Dieses Intervall wird als Blackout-Fenster bezeichnet. Ein Blackout-Fenster kann in mehreren Szenarien notwendig sein, z. B. wenn die Quellumgebung ressourcenbeschränkt ist oder wenn Sie möchten, dass die Replikation nur außerhalb der Geschäftszeiten erfolgt.

Sie können ein Blackout-Fenster für die Appliance angeben, indem Sie die GatewayDataWorker.json-Datei in C:\ProgramData\Microsoft Azure\Config erstellen oder aktualisieren. Eine typische Datei hat folgendes Format:

{
    
    "BlackoutWindows": "List of blackout windows"
    
}

Die Liste der Blackout-Fenster ist eine durch Pipe getrennte (|) Zeichenfolge im Format <DayOfWeek>;<StartTime>;<Duration>. Sie können die Dauer in Tagen, Stunden und Minuten angeben. Beispielsweise können Sie die Blackout-Fenster wie folgt angeben:

{
    
    "BlackoutWindows": "Monday;7:00;7h | Tuesday;8:00;1d7h | Wednesday;16:00;1d | Thursday;18:00;5h | Friday;13:00;8m"
    
}

Der erste Wert im vorherigen Beispiel zeigt ein Blackout-Fenster an, das jeden Montag um 7:00 Uhr Ortszeit (Uhrzeit für die Appliance) beginnt und 7 Stunden dauert.

Nachdem Sie diese Inhalte erstellt oder aktualisiert GatewayDataWorker.json haben, müssen Sie den Gatewaydienst auf der Appliance neu starten, damit diese Änderungen wirksam werden.

Im Szenario mit horizontaler Skalierung werden die Blackout-Fenster von der primären Appliance und der Appliance für die horizontale Skalierung unabhängig voneinander unterstützt. Als bewährte Methode empfiehlt es sich, die Fenster applianceübergreifend konsistent zu halten.

Verwandte Inhalte

• Migrieren von VMware-VMs zu Azure (ohne Agent)