Lift & Shift-Migrationen im Unternehmensmaßstab

Es gibt zahlreiche Möglichkeiten, wie du deine Anwendungen nach Azure migrieren kannst. Der einfachste Ansatz - auch Lift & Shift-Migration genannt  - fußt auf der Idee, deine lokalen VMs 1: 1 auf Azure-VMs zu migrieren. Sobald du das im großen Stil für hunderte von Worksloads möglichst ohne Unterbrechung durchführen möchtest, führt kein Weg an einer Plattform vorbei, die nicht nur die erforderlichen Werkzeuge bereitstellt, sondern den Prozess auch umfassend orchestriert, wie Azure Migrate. Im Teil 1 dieses Vierteilers habe ich die Architektur von Azure Migrate erklärt und ein erstes Projekt angelegt. In Teil 2 haben wir die dazu erforderliche Azure Migrate Appliance bereitgestellt. Teil 3 widmete sich dann einer Bewertung von Hyper-V-Workloads. In diesen Teil migrieren wir exemplarisch eine Hyper-V-VM auf eine Azure-VM, einschließlich vorhergehender Replikation.

Da sämtliche erforderlichen Voraussetzungen in den vorangegangenen Teilen geklärt bzw. geschaffen wurden, können wir nun direkt loslegen. Wir starten wieder im Azure-Migrate-Projekt unter „Migrationsziele / Server, Datenbanken und Web-Apps“, beschäftigen uns aber diesmal mit den Migrationstools, namentlich dem von Microsoft favorisierten Werkzeug „Migration und Modernisierung“ und unteren Teil der Übersichtsseite. In folgendem Screenshoot habe ich durch Scrollen nur den relevanten Teil fokussiert, was du am Scrollbalken rechts erkennst.

Startpunkt für die Migration ist das Tool „Migration und Modernisierung

Falls du nicht mehr präsent hast, wie der Migrations-Workflow aussieht und welche Komponenten beteiligt sind, schau dir Teil 1 noch einmal an. Der unterscheidet sich z. B. erheblich zwischen Hyper-V und VMware. Die VMware-Migration habe ich schon vor längerer Zeit https://incas-training.de/blog/effizientes-bewerten-von-vmware-migrationen-in-die-cloud-mit-azure-migrate/ vorgestellt. Seitdem hat sich auch bei VMware einiges getan. In diesem Beitrag widmen wir uns allerdings der agentenlosen Hyper-V-Migration. Diese umfasst die Schritte „Replikation“, „Test-Migration“ und „finale Migration“.

Die von der agentenlosen Hyper-V-Migration verwendete Replikationstechnologie basiert auf Azure Site Recovery (ASR), welche wiederrum in Kern wesentliche Elemente von Hyper-V-Replika nutzt. Ich sage bewusst „basiert auf“ und nicht „ist gleich“. Azure Site Recovery ist primär ein Werkzeug für die Notfallwiederherstellung, d. h. die Azure Migrate Replikation und ASR verfügen über einige gemeinsame Technologiekomponenten, welche für die Datenreplikation genutzt werden, aber erfüllen für sich unterschiedliche Aufgaben. Ich erinnere an die Komponenten der Replikations-Architektur anhand dieser Abbildung von Microsoft:

Die Replikationsarchitektur bei Hyper-V (Quelle: Microsoft)

Der Microsoft Azure Site Recovery-Replikationsanbieter wird dabei auf deinen Hyper-V-Hosts installiert und beim Migrations- und Modernisierungstool registriert. Er orchestriert dann die Replikation für Hyper-V-VMs. Der Microsoft Azure Recovery Services-Agent selbst verarbeitet die Datenreplikation, wozu er mit dem Replikationsanbieter zusammenarbeitet, um die Daten von Hyper-V-VMs nach Azure zu replizieren. Wichtig: hierbei werden die replizierten Daten zunächst in ein Speicherkonto deines Azure-Abonnements hochgeladen, dem Replikationsspeicherkonto. Dieses muss du nicht selbst anlegen. Das Migrations- und Modernisierungstool verarbeitet kontinuierlich die replizierten Daten und wendet sie auf Replikatdatenträger im Replikationsspeicherkonto an. Die Replikatsdatenträger selbst werden erst bei der eigentlichen Migration zum Erstellen der Azure-Ziel-VMs verwendet und angehängt. Sämtliche beschriebene Komponenten werden mit Hilfe einer einzigen Setupdatei installiert, welche du in deinem Azure-Migrate-Projekt beim „Migrations- und Modernisierungstool“ herunterladen kannst. Der Replikationsprozess sieht dann etwa so aus:

• Sobald du die Replikation für eine Hyper-V-VM aktivierst, starte die erste (initiale) Replikation.

• Dazu erstellt das Tool einen Hyper-V-VM-Snapshot.

• Danach werden aller VHDs auf deiner VM nacheinander repliziert. Beim ersten Mal kann das durchaus länger dauern, da die vollständigen Datenträger repliziert werden müssen. Die Dauer der ersten Replikation hängt von der VM-Größe und der Netzwerkbandbreite ab, also auch davon, ob der Upload zu Azure über öffentliche Leistungen oder ein VPN, bzw. eine Express-Route erfolgt.

• Danach werden kontinuierlich sämtliche Änderungen auf den Datenträgern, welche in Verlauf der ersten Replikation dazu gekommen sind, mit Hilfe von Hyper-V-Replika nachverfolgt und in Protokolldateien (HRL-Dateien) gespeichert. Diese Protokolldateien befinden sich im gleichen Ordner, wie die Datenträger selbst, wobei jeder Datenträger eine ihm eindeutig zugeordnete HRL-Datei hat, die jeweils an das Replikationsspeicherkonto gesendet wird. Dabei belegen die Snapshots- und Protokolldateien im Verlauf der anfänglichen Replikation selbstverständlich Festplattenressourcen.

• Nach Beendigung der ersten Replikation wird der Snapshot des virtuellen Computers gelöscht und die kontinuierliche Deltareplikation in Gang gesetzt. Dabei werden die inkrementellen Datenträgeränderungen in den erwähnten HRL-Dateien verfolgt. Diese Replikationsprotokolle werden dann vom Recovery Services-Agent in regelmäßigen Abständen in dein Azure-Replikationsspeicherkonto hochgeladen.

Probieren wir es aus. Zunächst musst du im Tool „Migration und Modernisierung“ auf „Replizieren“ eine Server-Ermittlung durchführen, ähnlich wie wir es für das Assessment-Tool bereits getan haben. Wichtig ist hier Folgendes. Bei der Frage „Möchten Sie eine neue Replikationsappliance installieren oder ein vorhandenes Setup horizontal hochskalieren?“ wählst du „Replikationsappliance installieren“. Im nächsten Absatz bei „Bereiten Sie die Replikation vor, indem Sie die Replikationsanbietersoftware herunterladen und auf Ihren Hyper-V-Hosts installieren. Führen Sie die folgenden Schritte aus, um die Hyper-V-Hostserver einzurichten und zu konfigurieren“ kannst du dann bei „1. Bereiten Sie die Hyper-V-Hostserver vor“ auf „Laden Sie“ klicken, um die oben erwähnte Hyper-V-Replikationsanbietersoftware herunterzuladen.

Vor der ersten Replikation muss der Azure Site Recovery Provider heruntergeladen und auf deinem Hyper-V-Host installiert werden.

Diese hört auf den Namen „AzureSiteRecoveryProvider.exe“ und muss auf deinem Hyper-V-Host installiert werden. Achtung: Die Software erhältst du „nicht“ durch Klick auf den unübersehbaren blauen Button „Herunterladen“., sondern wie erwähnt auch Klicken des unscheinbaren Links „Laden Sie“. Dieser lädt nämlich die ASR-Tresoranmeldeinformationen für den Recovery-Services-Vault herunter, welche du für die folgende Registrierung des Servers brauchst. Beide Schritte führst du sinnvollerweise im Azure-Portal auf deinem Hyper-V-Host aus:

Im Zuge der Installation wird dein Hyper-V-Server dann bei Azure Migrate registriert. Ich erlaube mir hier, den Installationsassistenten nicht erneut Schritt für Schritt zu bebildern. Die Installation sollte dich nicht überfordern. Da die Software auf meinen Hyper-V-Host bereits installiert war, fragt der Installer lediglich, ob der Hyper-V-Server erneut registriert werden soll, was ich mit „Ja“ beantworte:

Registrieren eine Hyper-V-Hosts bei ASR

Dann musst du die die eben heruntergeladene Schlüsseldatei angeben. Das sieht so aus:

Azure-Site-Recovery benötigt die Tresoranmeldeinformationen

Den nächsten Schritt „Proxyeinstellungen“ kannst du übergehen, wenn du keinen Proxy verwendest. Im Schritt „Registrierung“ solltest du die erfolgreiche Registrierung deines Hyper-V-Hosts sehen können:

Erfolgreich registrierter Hyper-V-Host

Klicke auf „Fertig stellen“. Die erfolgreiche Registrierung sollte sich auch auf der Azure-Migrate-Projektseite bei der „Ermittlung“ im Tool „Migration und Modernisierung“ wiederspiegeln. Hier musst du lediglich noch auf „Registrierung abschließen“ klicken.

Abschließen der Registrierung des Hyper-V-Hosts im Azue-Portal

Das Ergebnis sollte so aussehen:

Erfolgreich abgeschlossene Registrierung

Der Vorgang dauert etwas länger, da er auch gleich die Ermittlung selbst umfasst. Vielleicht wunderst du dich, dass du erneut eine Ermittlung durchführen musst, aber das liegt schlicht daran, dass „Azure Migrate: Discovery and assessment“ und „Bewertung und Modernisierung“ zwei völlig unterschiedliche und voneinander unabhängige Werkzeuge sind. Das gilt insbesondere beim Hyper-V-Workflow.

Bei VMware könntest du die Azure-Migrate-Appliance auch zur Replikation und Migration nutzen und dann auf eine vorhandene Ermittlung zurückgreifen. Im Ergebnis finden wir in meinem Beispiel erneut „9“ ermittelte Server.

Erfolgreiche Ermittlung

Jetzt kannst du auf „Replizieren“ klicken. Im Dialog „Absicht angeben“ wählst du bei „Was möchten Sie migrieren“ den Eintrag „Server oder virtuelle Computer (VM)“.  Bei „Wohin möchten Sie migrieren“ wählst Du „Azure VM“ und bei „Sind ihre Computer virtualisiert" wählst du „Ja, mit  Hyper-V“.

Startpunkt für die Migration ist das Tool „Migration und Modernisierung"

Klicke nun auf „Fortfahren“. Die Replikationsassistent durchläuft jetzt einen weiteren Assistenten mit 6 Schritten. Im Schritt 1 „Virtueller Computer“ wählst du die zu replizierende Quell-VM. Hierbei hast du die Möglichkeit, mit „Migrationseinstellungen aus einer Bewertung importieren“ die Ziel-VM-Konfiguration (hier muss du dich leider schon bei der Replikation festlegen) nicht erneut vornehmen zu müssen, sondern aus einer vorhandenen Bewertung importieren kannst, was wir hier tun wollen. Du musst dann nur die Assessment-Gruppe und das gewünschte Assessment auswählen. Hiermit werden unten deine bewerteten Server aufgelistet und du kannst den gewünschten Server auswählen:

Auswählen der zu replizierenden VM

Achtung: ASR unterstützt bei der agentenlosen Hyper-V-Replikation evtl. nicht alle Betriebssysteme, insbesondere bei Generation-2-VMs mit UEFI. Auf der sicheren Seite bist du aber mit Windows Server 2022, 2019, 2016, 2012 R2, 2012, Windows 10/11 Pro, Windows 10/11 Enterprise sowie den gängigen Enterprise-Linux-Herstellern (SUSE Enterpriese Server 15,Ubuntu Server ab 16.04, RHEL ab 6, CentOS Stream und Oracle Linux ab 7.7). Bedenke außerdem: wenn du als Ermittlungsquelle einen Hyper-V-Cluster konfiguriert hast, dann kannst du auch nur hochverfügbare VMs replizieren!

Klicke dann auf „Weiter“, um zu den „Zieleinstellungen“ zu gelangen. Hier wählst du deine Zielumgebung für das Replikationsspeicherkonto (Cachespeicherkonto), also die gewünschte Azure-Subscription, die Ressourcengruppe, das virtuelle Netzwerk, das Subnetz und die Verfügbarkeitsoptionen für die Ziel-VM. Das Cachespeicherkonto kannst du automatisch erstellen lassen.

Bisher existiert nämlich in deiner Ressourcengruppe lediglich der Recovery-Services-Tresor und ggf. ein Azure-Key-Vault. Das virtuelle Ziel-Netzwerk samt Subnetz muss du selbstverständlich anlegen, bzw. angelegt haben. Etwas „unglücklich“ im Workflow ist, dass du z. B. das Netzwerk und die Adressbereiche bereits jetzt in der Replikationsphase planen musst. Die verwendeten Adressbereiche sollten sich dabei tunlichst nicht mit deinen lokal verwendeten Adressbereichen überschneiden, insbesondere wenn du später auf eine Online-Migration abzielst. Die Zieleinstellungen sollten etwa so aussehen:

Zieleinstellungen einer Replikation

Im nächsten Schritt „Compute“ kannst du die vorgeschlagene „Azure-VM-Größe“ übernehmen oder eine anderen wählen. Außerdem musst du den Betriebssystemtyp angegeben und den Betriebssystemdatenträger auswählen. Ich wähle im Beispiel trotz erfolgreicher Bewertung eine kleinerer Azure-Ziel-VM, um die Kosten zu reduzieren:

Größe der Ziel-VM kann von der Bewertung abweichen

Im nächsten Schritt „Datenträger“ wählst du die zu replizierenden Quell-Datenträger aus - bei einer VM mit mehreren Daten-Datenträgern oder Swap-Datenträgern brauchst du eventuell nicht alle - und ordnest Azure-seitig einen geeigneten Ziel-Datenträgertyp zu. Ich nehme aus Kostengründen hier „HDD-Standard“.

Auswahl der zu replizierenden Datenträger

Den Schritt Tags kannst du überspringen, bzw. Tags vergeben, wie bei jeder anderen Azure-Ressource auch. Wirf dann einen Blick auf „Replikation prüfen und starten“ und klicke bei Zufriedenheit auf „Replizieren“.

Anstoßen der Replikation

Du siehst in den Benachrichtigungen, bzw. im Aktivitätsprotokoll, dass die Replikation gestartet wurde.

Nachdem die Replikation erfolgreich angestoßen wurde, findest du auf der Projektseite im Tool „Migration und Modernisierung“ bei „Replikationen“ eine „1“ neben Azure-VM“.

Die Übersichtsseite zeigt die Anzahl vorhandener Replikationen an

Klickst du nun auf diese „1“, kannst du den Replikationsstatus überprüfen, der verschiedene Stufen durchläuft. Final sollte „Protected“ lauten und die „Replikationsintegrität“ „Fehlerfrei“ sein.

Erfolgreiche fehlerfreie Replikation

Wurde Phase 1 (mindestens eine erfolgreiche Replikation) für die ausgewählte virtuelle Maschine(n) abgeschlossen, kannst du dich im Rahmen einer Test-Migration vergewissern, ob die Ziel-VM einwandfrei hochfährt, ohne die Quell-VM herunterzufahren. Du kannst dir bei der nachfolgenden echten Migration in puncto Netzwerk sicher vorstellen, dass dabei in der Praxis eine ganze Reihe von Voraussetzungen passen müssen, etwa im Hinblick auf etwaige IP-Adresse-Konflikte oder das Übernehmen bestehende Verbindungszeichenfolgen (z. B. bei Datenbanken), deren Erläuterungen jedoch den Rahmen des Beitrages sprengen und außerdem nicht mit Azure Migrate selbst im Zusammenhang stehen. Solchen Fragen geht die Test-Migration  - denn dafür ist sie gedacht - zunächst aus dem Weg.

Du kannst nun z. B. in oben angezeigte Liste der erfolgreich replizierten VM(s) direkt auf den Link der VM klicken, um mehr Details zum Replikationsstatus zu sehen. Das könnte dann z. B. so aussehen:

Starten der Testmigration erfolgt aus der Seite mit den Replikationsdetails

Du erkennst hier schnell, dass bei „Status der Testmigration“ „Niemals ausgeführt“ steht. Klicke jetzt links oben auf „Testmigration“. Dort wählst du zunächst dein vorbereitetes (sich möglichst nicht mit lokalen Adressbereichen überschneidendes) virtuelles Netzwerk aus:

Virtuelles Netzwerk für die Testmigration

Klicke auf den Button „Testmigration“. Du siehst im Verlauf, dass die Testmigration gestartet wurde:

Erfolgreich gestartete Testmigration

Navigierst du nach Abschluss des Startes der Testmigration wieder zurück zur Replikationsseite, sollte der Status so aussehen, wie in folgender Abbildung, d. h. der Button „Testmigration“ ist nun ausgegraut, dafür aber der Button „Testmigration bereinigen“ klickbar.

Nach erfolgreicher Testmigration musst du diese wieder bereinigen

Außerdem siehst du jetzt die testmigrierte VM im Azure-Portal in deiner Ressourcengruppe.

Testmigrierte VM in Azure

Um nun die finale Migration zu starten - behalte immer im Hinterkopf: in freier Wildbahn könntest du dies bei passender Konfiguration und guter Planung durchaus für hunderte von VMs gleichzeitig tun  - musst du die Testmigration nun zuerst mit dem gleichnamigen Button „bereinigen“. Die Quell-VM läuft noch problemlos weiter.

Bereinigen einer Testmigration ist zwingend für eine finale Migration

Klicke dann auf „Test bereinigen“. Navigierst du nun zurück zur Seite mit dem Replikationsstatus deiner VM, gibt es nun nur noch den Knopf „Migrieren“.

Erst nach erfolgreich bereinigter Testmigration kannst du eine Migration starten

Klickst du darauf, musst du beantworten, ob die Quell-VM nach erfolgreicher Migration beendet werden soll, in meinen Fall „Ja“. Klicken dann auf den Button „Migrieren“.

Beim Migrieren soll die Quell-VM beendet werden

Nach einer letzten im Idealfall erfolgreichen Überprüfung, wird die Migration gestartet, was du wieder in den Benachrichtigungen verfolgen kannst.

Migration wurde gestartet

Ja nach Art und Größe der VM, sowie ihren Datenträgern solltest du dann nach einer gewissen Zeit die Ziel-VM im Ziel-Netzwerk wiederfinden und die Hyper-V-VM sollte „aus“, aber nicht gelöscht sein. Das hält dir die Hintertür für einen etwaigen Rückweg offen.

Erfolgreich migrierte Azure-VM

Wurde die VM erfolgreich migriert, kannst natürlich nachträglich jederzeit alles mit dieser VM tun, was du auch mit jeder anderen Azure-VM tun kannst, z. B. deren Größe wieder an den Leistungsbedarf oder dein Budget anpassen:

Nach der Migration kannst du die Größe der VM auch wieder ändern

Zur Kontrolle überprüfe nun noch, dass deine Quell-VM aus ist:

Die Quell VM ist erwartungsgemäß aus