Lift & Shift-Migrationen im Unternehmensmaßstab
Migrieren von Hyper-V-VMs mit Azure Migrate – Teil 4: Migrieren von Hyper-V-Workloads
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.
Passende Schulungen
AZ-305 – Designing Microsoft Azure Infrastructure Solutions (AZ-305T00)
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.
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“.
Phase 1- die Replikation
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:
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.
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:
Dann musst du die die eben heruntergeladene Schlüsseldatei angeben. Das sieht so aus:
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.
Das Ergebnis sollte so aussehen:
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.
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“.
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:
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:
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:
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“.
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“.
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“.
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.
Phase 2 – die Test-Migration
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:
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:
Klicke auf den Button „Testmigration“. Du siehst im Verlauf, dass die Testmigration gestartet wurde:
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.
Außerdem siehst du jetzt die testmigrierte VM im Azure-Portal in deiner Ressourcengruppe.
Phase 3 – die Migration
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.
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“.
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“.
Nach einer letzten im Idealfall erfolgreichen Überprüfung, wird die Migration gestartet, was du wieder in den Benachrichtigungen verfolgen kannst.
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.
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:
Zur Kontrolle überprüfe nun noch, dass deine Quell-VM aus ist:
