Lift & Shift-Migrationen im Unternehmensmaßstab

Es gibt viele Möglichkeiten (hier geht es zu Teil 1), 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 aber 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 bereits die Architektur von Azure Migrate erklärt und ein erstes Projekt angelegt. In diesem Teil stellen wir die Azure-Migrate-Appliance bereit und konfigurieren diese für deine Bewertungsquellen. Teil 3 widmet sich dann der Bewertung und Teil 4 der Replikation/Migration von Hyper-V-VMs. Das Know How ist wichtig für den AZ 305.

Wir haben im ersten Teil ein Azure-Migrate-Projekt erstellt. In Teil 3 werden wir mit Hilfe von Microsoft‘s eigenem Assessment-Werkzeug „Azure Migrate: Ermittlung und Bewertung“ eine Bewertung durchzuführen. Der erste Schritt besteht aber zunächst darin, deine zu bewertende Server zu ermitteln. Dazu müssen wir nun zunächst die Azure-Migrate-Appliance bereitstellen und konfigurieren. Ich gehe in diesem Beispiel davon aus, dass du lokal eine Reihe von Hyper-V-VMs betreibst, wahlweise auf einzelnen Hyper-V-Hosts oder einem Hyper-V-Cluster.

Wir starten mit dem Herunterladen und Bereitstellen der architektonisch in Teil 1 beschriebene Azure-Migrate-Appliance in einer Hyper-V-Umgebung. Klicke dazu unter „Migrationsziele / Server, Datenbanken und Web-Apps“ im Bewertungstool „Azure Migrate: Discovery and assessment“ auf „Ermitteln“ und dann im Klappmenü auf „Appliance verwenden“.

Nur mit „Appliance verwenden“ kannst du die Ermittlung deiner Server vollständig automatisieren Die Appliance gibt es für Hyper-V und VMware-Umgebungen

Die Appliance ermittelt kontinuierlich lokale Server und sendet Metadaten und Leistungsdaten der Server an Azure. Die Appliance wird als Vorlage für Server bereitgestellt, die in einer Hyper-V- (VHD-Vorlage) oder VMware- (OVA-Vorlage) laufen. Du kannst die Appliance aber auch mit Hilfe eines https://learn.microsoft.com/azure/migrate/deploy-appliance-script Powershell-Skriptes bereitstellen.

Der Assistent fragt dich bei „Virtualisierungstyp auswählen“, ob und auf welcher Plattform deine Server virtualisiert sind. Hier wählst du in unserem Beispiel „Ja, mit Hyper-V“. Im Dialog „Ermitteln“ des Assistenten gibst du im Schritt „1: Projektschlüssel generieren“ deiner Appliance einen Namen und klickst auf „Schlüssel generieren“. Bisher ist die Appliance erstmal nur ein logisches Objekt in Azure-Migrate.

Benennen des logischen Objektes „Azure Migrate Appliance“ und der Anschließende Download der VM

Danach kannst du im Schritt „2:Azure Migrate-Appliance herunterladen“ die Appliance wahlweise als 12GB große VHD-Datei oder als 500 MB kleines ZIP-Archiv herunterladen. Letzteres enthält selbstverständlich nur einen Installer, welche die eigentliche VHD dann erst bei der Bereitstellung holt. Von daher kannst du gleich mit der VHD starten.

Die Schritte 3 (Appliance einrichten) und 4 (Appliance konfigurieren und Ermittlung starten) führst du an der Appliance selbst durch. Du kannst den Ermitteln-Dialog jetzt geöffnet lassen und in deiner Hyper-V-Umgebung mit der Bereitstellung fortfahren.

Die Appliance stellt recht üppige Mindestanforderungen. Sie basiert, was das Gastbetriebssystem, betrifft auf Windows Server 2019 oder Windows Server 2022 mit 16 GB RAM, 8 vCPUs, benötigt ca. etwa 80 GB Speicherplatz und einem externen virtuellen Switch. Sie erfordert außerdem eine statische oder dynamische IP-Adresse sowie Zugriff auf das Internet. Das heruntergeladene Appliance-Template wird von Microsoft mit einer Windows Server 2022-Evaluierungslizenz ausgestattet, die 180 Tage lang gültig ist. Ist der Evaluierungszeitraum fast abgelaufen, solltest du besser eine neue Appliance herunterladen und bereitstellen oder die Betriebssystem-Lizenz des zugrundeliegenden Servers aktivieren, damit das Evaluierungssystem im Ernstfall nicht einfach herunterfährt. Es ist aber ohnehin nicht vorgesehen, die Appliance dauerhaft zu betreiben, da jedes Migrationsprojekt irgendwann abgeschlossen sein sollte.

Wie schon erwähnt, muss die Appliance dauerhaft mit dem Internet verbunden sein. Die Appliance führt bei der Bereitstellung eine Konnektivitätsprüfung für alle zwingend erreichbaren Public-URLs durch. Bedenke dies, falls du ggf. deine Firewall anpassen musst. Dies sind neben dem Azure-Portal *.portal.azure.com zahlreiche weitere URLs. Du findest sie ggf. in der https://learn.microsoft.com/en-us/azure/migrate/migrate-appliance#url-access Azure-Migrate-Dokumentation. Außerdem musst du wissen, dass die Appliance bei Hyper-V über den WinRM-Port 5985 (HTTP) mit den Hyper-V-Hosts kommuniziert (bei VMware über den TCP-Port 5443 mit dem vCenter-Server). Du solltest für den weiteren Verlauf wissen, wie du in Hyper-V eine neue VM auf Basis einer existierenden VHD bereitstellst, deswegen fasse ich mich hier kurz.

Ich habe mich für den klassischen „VM-Import“ entschieden. Wähle dazu im Kontextmenü deines Hyper-V-Hosts die Funktion „Virtuellen Computer importieren" und navigiere dann zum zuvor entpackten Ordner der zu importierenden virtuellen Maschine, wie in folgender Abbildung.

Screenshot eines Hyper-V-Manager-Fensters Hast du den Order mit den entpackten ZIP-Archiv angegeben, sollte die Appliance angezeigt werden

Beim Schritt „Importtyp auswählen“ nimmst du dann „Virtuellen Computer kopieren (neue eindeutige ID verwenden).“

Du musst den passenden Importtyp wählen

Bei „Ziel auswählen“ kannst du noch den gewünschten Ordner für deine neue VM auswählen, der (falls abweichend vom Default) bei „Speicherort auswählen“ noch einmal angezeigt wird.

Auswählen des Speicherortes, bei einem Single-Hyper-V-Host z. B. ein separates Laufwerk oder ein Cluster-Shared-Volume (CSV) bei einer Cluster-VM

Klickst du auf Zusammenfassung, wirst du vermutlich eine Fehlermeldung bekommen, weil dein virtueller Switch anders heißt als in der Vorlage. Hier wählst du dann einfach bei „Verbindung“ deinen vSwitch aus und navigierst mit „Weiter“ erneut zur Zusammenfassung. Das könnte z. B. so aussehen:

Import-Konfiguration in der Zusammenfassung

Klicke auf „Fertigstellen“. Der Import wird eine Weile dauern, weil die Disk 80 GB groß ist. Ich habe in meinem Fall anschließend die VM noch mit einem einprägsameren Namen unbenannt. Das kannst du im Hyper-V-Manager per Kontextmenü erledigen.

Du kannst die VM bei Bedarf im Inventar umbenennen. Möchtest du auch die zugehörigen Dateien umbenennen, musst du das manuell machen oder eine neue VM mit vorhandener VHD bereitstellen

Anschließend rufst du noch einmal die „Einstellungen“ der neuen VM auf und stellst sicher, dass die Mindestanforderungen der VM erfüllt sind, also 8 virtuelle Kerne und 16GB RAM.

Überprüfen/Anpassen der Hardwareanforderungen an die VM

Danach kannst du die VM per Doppelklick auf diese per VM Connect verbinden und mit einem Klick auf „Starten“ starten. Du musst wie bei jedem anderen neuen Windows-Server zunächst die Lizenzbedingungen akzeptieren und das Setup vervollständigen. Anschließend legst du ein administratives Benutzerkonto fest:

Das administrative Konto auf der Appliance legst du selbst an

Melde dich mit dem neuen Konto an und klicke auf dem Desktop auf „Azure Migrate Appliance Manager“. Der Shortcut öffnet einen Edge-Browser mit dem in Teil 1 erwähnten „Appliance-Konfigurations-Manager“ (geschieht beim Start der Appliance automatisch) mit der URL https://<vm-name>:44368.

Wir sind nun an dem Punkt angekommen, die Appliance zu konfigurieren, also auf der lokalen Seite mit deinen Ermittlungsquellen zu verbinden und auf der Azure-Seite mit deinem Azure-Account.

Wie schon oben erwähnt, überprüft der Setup-Prozess im Schritt „1. Set up prerequisites“ zunächst die Internetkonnektivität und auf die Zeitkonfiguration in Sync mit Azure ist.

Die Appliance überprüft zunächst die Konnektivität

Dann musst du deine Appliance bei Azure registrieren, wozu du den oben generierten „Azure Migrate project key“ benötigst. Füge ihn im entsprechenden Feld „Register Hyper-V..“ ein und klicke auf „Verify“.

Registrieren der „physischen“ Appliance bei Azure-Migrate

Danach wird nach Updates gesucht, was eine ganze Weile dauern kann. Schließlich folgt noch der Login zu Azure mit einem geeigneten Azure-Account. Klicke dazu auf „Login“, notiere den angezeigten Device-Code und klicke dann auf „Copy code & Login“. Füge im nächsten Dialog den Device-Code ein und klicke auf „Next“. Dann kannst du dich wie gewohnt einem Azure-Konto anmelden. Das Konto, welches du hierzu verwendest, muss mindestens die RBAC-Rolle „Contributor“ für die Ressourcengruppe deines Azure-Migrate-Projektes aufweisen.

Allerdings passiert dabei im Hintergrund Folgendes: Bei der Registrierung werden die Resourceprovider „Microsoft.OffAzure“, „Microsoft.Migrate“ und „Microsoft.KeyVault“ in deinem Abonnement registriert (falls noch nicht geschehen).

Für die Registrierung der Ressourcenanbieter bedarf es jedoch Contributor- (Mitwirkender) oder Owner- (Besitzer)-Rechte auf das gesamte Abonnement. Azure Migrate erstellt eine Microsoft Entra-App. Die App kommuniziert mit den Appliance-Agents und dem Azure Migrate-Dienst. Die App selbst hat keine Berechtigungen zum Ausführen von Azure Resource Manager-Aufrufen und keinen RBAC-Zugriff auf Azure-Ressourcen.

Die Appliance verbindet sich im Verlauf der Konfiguration mit Azure

Das Ergebnis sollte so aussehen:

Der Login in Azure war erfolgreich

Nun geht es weiter mit dem zweiten Schritt des Assistenten „2. Manage credentials and discovery sources” also dem Anbinden deiner Ermittlungsquellen. In “Step 1: Provide Hyper-V host credentials for discovery of Hyper-V-VMs” kannst du nun Zugangsdaten für einzelne Hyper-V-Hosts oder Cluster mit „Add credentials” hinterlegen.

Hinzufügen von Anmeldedaten, die du für deine Ermittlungsquellen verwenden kannst

Achtung: Hierbei handelt es sich zunächst nur um einen Alias, bzw. „Friendly Name“. Der eigentliche FQDN, bzw. die IP-Adresse einzelner Hosts oder Cluster legst du erst unter „Step 2: Provide Hyper-V host/cluster details“ fest, indem du auf „Add discovery source“ klickst und dort die eben angelegten Credentials zuordnest. Um einen DNS-Hostnamen auflösen zu können, müsstest du evtl. in der Adapter-Konfiguration der Appliance deines DNS-Server konfigurieren. Gibst du  - egal ob via FQDN oder IP-Adresse  - einen Host an, der wie in meinem Fall Teil eines Clusters ist, wird automatisch der Cluster-Name aufgelöst. Das Konto, welches du bei „Credentials“ angegeben hast, muss entweder ein lokaler Administrator auf deinem Hyper-V-Host sein oder Mitglied der lokalen Gruppe „Remoteverwaltungsbenutzer“ des Hyper-V-Hosts. In dieser kannst du beliebige Domänenkonten, auch den Domain-Admin einfügen, was aus meiner Sicht aber nicht zu empfehlen ist. Das Ergebnis sieht z. B. so aus:

Erfolgreiche angebundene Ermittlungsquellen

Der dritte Schritt „Step 3: Provide server credentials to perform software inventory, agentless dependency analysis, discovery of SQL Server instances and databases and discovery of web apps in your HyperV environment” ist für dich nur relevant, wenn du VM-basierte Workloads mit SQL-Server-Instanzen oder Web-Apps hast, welche du ebenfalls bewerten möchtest. Hier müsstest du Credentials für deine SQL-Server oder Web-Apps hinterlegen. Außerdem kannst du Server-Credentials für deine einzelnen VMs hinterlegen, wenn die Bewertung auch eine Softwarebestandsaufnahme beinhalten soll. Andernfalls kannst du diese Funktion mit dem gleichnamigen Schiebeschalter auch deaktivieren. Ich habe in folgender Abbildung eines Satz Domain-Credentials hinterlegt.

Das Ergebnis könnte so aussehen:

Du kannst ebenfalls diverse Server-Anmeldedaten für deine verschiedenen VMs hinterlegen

Hast du bis hierher alles erfolgreich erledigt, klickst du auf „Start discovery“, um die Ermittlung zu starten. Hier kann es sein, dass du dich wie oben beschrieben erneut mit einem Device-Code bei Azure anmelden musst, je nachdem, wie lange der Anmeldevorgang oben zurück liegt. Der Prozess kann in Abhängigkeit der Größe deiner Hyper-V-Umgebung einen Moment dauern.

Du kannst in der Zwischenzeit in den Dialog „Ermitteln“ einer der Projekt-Ressource im Azure-Portal zurückkehren und abwarten, bis der Schritt „Warten Sie, bis die Appliance verbunden, die Ermittlung abgeschlossen und die Leistungsdaten erfasst wurden.“ abgeschlossen ist. Danach kannst du die Seite schließen.

Ermittlung ist im Gange

Wechselt du wieder in dein Azure-Migrate-Projekt zu „Migrationsziele / Server, Datenbanken und Web-Apps“ solltest du bei „Bewertungstools“ unter „Azure Migrate: Discovery and assessment“ bei „Ermittelte Server nun die Anzahl der von der Appliance ermittelten Server angezeigt bekommen, hier sind es 9.

Die Übersichtsseite des Bewertungstools zeigt nun 9 ermittelte Server. Es könnten auch Hunderte sein

Achte auch auf den Bereich rechts bei „Appliances“. Bei mir gibt es derzeit zwei Appliances, von denen nur eine registriert ist. Das bedeutet nicht, dass ich zwei VMs gleichzeitig betreibe. Vielmehr hatte ich das Bereitstellen der ersten Appliance für diesen Beitrag aus organisatorischen Gründen einen Tag unterbrochen. Solange die zugehörige VM nicht bereitgestellt und registriert wurde, ist die Appliance nur ein logisches Objekt in Azure Migrate. Ich hätte auch einfach nach einem Tag mit dem Registrieren der ersten Aplliance fortfahren können. Klickst du nämlich bei „Appliances“ auf die „2“, siehst du im Detail, dass es zwei Appliances gibt, von denen eine registriert ist.

Du kannst auch mehrere Appliances haben

Hier hätte ich nun einfach auf den Link „Nicht registriert“ klicken können, um die virtuelle Maschine bei der Konfiguration mit DIESEM Projektschlüssel registrieren zu können. Stattdessen hatte ich eine neue Appliance im Azure-Migrate-Portal angelegt und sie mit der realen VM registriert. Das ist nicht weiter schlimm. Allerdings wird nun, klicke ich nun auf die „9“ bei „Ermittelte Server“ stets zunächst vermeintlich kein Ergebnis angezeigt, weil der Projektfilter im Tab „Azure Migrate-Appliance“ auf die „Alte“ Appliance eingestellt ist.

Hast du mehrere Appliances, musst du im Projektfilter die richtige auswählen

Setze ich den Projektfilter auf die „Neue“, bekomme ich auch das Ergebnis dieses Workshops zu sehen, nämlich 9 ermittelte Server.

Ergebnis einer erfolgreichen Ermittlung

Du erkennst auf den ersten Blick den Namen der VM, die zugehörige IP-Adresse und die Ermittlungsquelle. Lass dich nicht von den vermeintlichen Fehlermeldungen in den übrigen Spalten („Daten nicht verfügbar“, bzw. „Fehler bei der Überprüfung“) verunsichern. Was die Fehlermeldung „Daten nicht verfügbar“ betrifft bezieht sich das auf die Spalten „Softwareinventur“, „Datenbanken“ „Web-Apps“ und „Dateiserver“, weil es bei mir schlicht keine Datenbanken, Web-Apps gibt oder Dateiserver gibt. Für die Softwareinventur hätte ich die notwendigen Credentials hinterlegen müssen. Der „Fehler“ „Fehler bei der „Überprüfen“ hingegen bezieht sich auf die Abhängigkeitsanalyse.

Dazu musst du wissen: bei der Abhängigkeitsanalyse „ohne Agent“ werden TCP-Verbindungsdaten von den Servern erfasst, für die diese aktiviert wurden, was in meinem Szenario nicht der Fall ist. Bei der Abhängigkeitsanalyse ohne Agents werden übrigens Verbindungen vom gleichen Quellserver- und Prozess sowie Zielserver-, Prozess und/oder Port logisch in einer Abhängigkeit gruppiert.

Bei der Agenten-basierten Abhängigkeitsanalyse musst du auf den beteiligten lokalen VMs zuerst den Azure Monitor Agent (AMA) installieren.

Wir haben nun die Appliance erfolgreich bereitgestellt, konfiguriert und eine erste Ermittlung durchgeführt. Im dritten Teil dieses Workshops werden wir uns dem Thema Assessment (Bewertung) widmen.