Lift & Shift-Migrationen im Unternehmensmaßstab

Migrieren von Hyper-V-VMs mit Azure Migrate  – Teil 1: Architektur und Szenarien

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. Auch dazu gibt es verschiedene Ansätze und Tools. 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 erkläre ich dir die Architektur von Azure Migrate und zeige, wie du ein Azure Migrate Projekt erstellst. In Teil 2 stellen wir die Azure Migrate Appliance bereit, um in Teil 3 eine Bewertung von Hyper-V-Workloads durchzuführen. Teil 4 widmet sich dann der Replikation und Migration von Hyper-V-VMs. Das Know How ist wichtig für den AZ 305.

Passende Schulungen

AZ-305 – Designing Microsoft Azure Infrastructure Solutions (AZ-305T00)

Microsoft selbst beschreibt Azure Migrate als einen Dienst, der dich nicht nur bei Planung einer Migration von VM-basierten Workloads zu Azure unterstützt, sondern auch bei der Ausführung einer Migration im großen Stil. Azure Migrate unterstützt dein Unternehmen dabei, den optimalen Migrationspfad zu finden, die Azure-Bereitschaft sowie die Kosten für das Hosten von Workloads in Azure zu bewerten und die Migration mit minimalen Ausfallzeiten und Risiken durchzuführen. Azure Migrate eignet sich zur Migration von Servern, Datenbanken, Web-Apps und virtuellen Desktops. Bei Bedarf unterstützt Azure Migrate auch Offline-Migration im großen Stil mithilfe der Azure Date Data Box.

Eine Migration einer großen Anzahl von Workloads zu Azure umfasst auch zahlreiche planerische Aspekte. Du brauchst dann einen umfassenden Cloud-Migrations-Plan, der nicht nur die technischen Aspekte, wie die zu verwenden Werkzeuge umfasst. Schließlich möchtest du auch vorab wissen, ob deine Workloads sich überhaupt für eine Migration zu Azure eigenen und was das Ganze vermutlich kosten wird. Zahlreiche Denkanregungen dazu gibt Microsoft übrigens in seinem https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ Cloud Adoption Framework, eine umfassende Sammlung von Beste Practises zum Thema Cloud-Einführung, einschließlich der Migration zu Azure mit Hilfe von Azure Migrate. 

Möchtest du hingegen nur eine Handvoll VMs oder sagen wir präziser VM-basierte Workloads nach Azure migrieren, ist Azure Migrate möglicherweise nicht das richtige Werkzeug. Letztendlich hängt vieles davon ab, ob du es dir erlauben kannst, deinen Workload für die Dauer der Migration offline zu nehmen. Rein technischen gesehen ist eine VM-Migration nicht schwierig. Im einfachsten Fall exportierst du die VHDs deiner VMs in einen Azure-Blob-Storage und baust daraus wahlweise in Azure Managed Disk, die du einer neuen VM anhängen kannst oder du machst daraus ein Image, um daraus eine neuen VM zu erzeugen.  Ich möchte dir aber trotzdem zeigen, wie du ein Azure-Migrate-Projekt aufsetzt, um damit Bewertung, Replikation und Migration zur orchestrieren.

Azure Migrate-Projekt anlegen

Suche im Azure-Portal nach „Azure Migrate“. Du landest dann auf der Seite „Erste Schritte”.

Dort klickst du auf „Migrationsziele / Server, Datenbanken und Web-Apps“ und erstellst mit dem Button „Projekt erstellen“ ein neues Migrationsprojekt. Dieses benötigt eine Ressourcengruppe, einen Namen und eine „Geografie“. Letztere ist konzeptionell „oberhalb“ eine Region. So umfasst die Geografie „Deutschland“ die Regionen „Deutschland Westen Mitte“ in Frankfurt, sowie „Deutschland Norden in Berlin.

Klickst du im Hauptmenü auf „Migrationsziele / Server, Datenbanken und Web-Apps“ ist der Projektfilter ganz oben bei „Projekt == <dein Projekt> automatisch auf den Namen deines Projekts gesetzt. Das wird leicht übersehen. Hast du später mehrere Projekte konfiguriert, musst du stets den Projektfilter passend setzen, um das passende Projekt zu sehen. Es gibt nämlich ansonsten keinen Azure-Ressource-Typ für das Projekt an sich, d. h. deine Ressourcengruppe ist zu diesem Zeitpunkt noch leer.

Je nach dem, für welches Szenario du Azure Migrate einsetzt (Hyper-V oder VMware, agentenbasiert oder agentenlos) entstehen im Verlauf eines Projektes in den einzelnen Phasen (Bewertung, Replikation, Migration) unterschiedliche Ressourcentypen in deinen Ressourcengruppen. In der Ressourcengruppe des Projektes können z. B. ein Recovery-Services-Tresor (Link zum Artikel Azure Backup), eine Azure-Service-Bis-Warteschlange, ein Protokoll-Speicherkonto, ein Gateway-Speicherkonto und/oder ein Azure Key Vault (Schlüsseltresor) für die verschlüsselte agentenbasierte Migration entstehen. Im Ziel-Speicherkonto der migrierten VMs findest du die VM-Ressourcen einschließlich Datenträgern (Managed Disks), Netzwerkschnittstellen und/oder IP-Adressen. Übrigens speichert Azure Migrate bei einem Bewertungsprojekt die von der Azure Migrate-Appliance erfassten Daten an dem Azure-Speicherort, indem du das Projekt erstellt hast.

Die erfassten Daten werden dabei sicher in einer Azure Cosmos DB – Datenbank abgelegt und gelöscht, sobald du das Projekt löschst. Das geschieht automatisch durch Azure Migrate, d. h. du musst dafür kein spezielles Speicherkonto anlegen oder auswählen. Entscheidest du dich zusätzlich für die Funktion der Visualisierung von Abhängigkeiten, werden die erfassten Daten in einem Azure Log Analytics-Arbeitsbereich in deinem Azure-Abonnement gespeichert. Diese Daten werden erst gelöscht, wenn du den Log Analytics-Arbeitsbereich löschst. In einem einzelnen Projekt kannst du übrigens bis zu 35000 Server bewerten. Die Azure Migrate Appliance kann zudem bis zu 5000 Server ermitteln und Verbindungen zu maximal 300 Hyper-V-Hosts gleichzeitig herstellen.

Bewertung- und Migrationstools

Ferner findest du auf der Seite „Migrationsziele / Server, Datenbanken und Web-Apps“ zwei Bereiche für „Bewertungstools“ und darunter „Migrationstools“. Voreingestellt ist das jeweilige Azure-Werkzeug, also „Azure Migrate: Discovery and assessment“ für das Bewertungswerkzeug sowie „Migration und Modernisierung“ für das Migrationswerkzeug.

Etwas unscheinbar (aber sicher im Sinne von Microsoft) kommt die Möglichkeit daher, für beide Bereiche auch Drittanbieterwerkzeuge einsetzen zu können. Dazu müsstest du jeweils auf den Link unterhalb der beiden Bereiche klicken, also „Weitere Bewertungstools hinzufügen? Klicken Sie hier“ oder „Weitere Migrationstools hinzufügen? Klicken Sie hier“.

Prinzipiell sieht Microsoft im Rahmen eines Migrationsprojekts die Schrittfolge „Bewertung“, „Replikation“ und „Migration“ vor. Während eine erfolgreiche Online-Migration von on premise zu Azure zwingend einen vorangehenden mehr oder weniger langen Replikationszeitraum voraussetzt, kannst du auf eine Bewertung natürlich auch verzichten. Diese dient vor allem den Zweck, die Kostenverlagerung von lokalen Ressourcen zu Azure abschätzen, bzw. vorhersagen zu können. Bei großen Migrationsprojekte ist das Assessment in der Tat ein unverzichtbarer Teil einer jeden Migrationsstrategie.

Die Bewertung ist vor allem dann interessant, wenn sie automatisiert erfolgen kann, d. h. eine Software wie „Migrate: Discovery and assessment“ in der Lage ist, deine vorhandenen Workloads zu ermitteln. Praktisch erfolgt das dadurch, dass du eine von Microsoft gelieferte virtuelle Appliance als VM in deiner Virtualisierungsumgebung bereitstellst (Diese gibt es für Hyper-V und VMware) und mit dem erforderlichen Zugriffsberechtigungen ausstattest, welche die ermittelten Daten dann über eine ausgehenden HTTPS-Verbindung an Azure Migrate reportet. „Migrate: Discovery and assessment“ bietet alternativ auch die Möglichkeit, dass du das Ermitteln deiner lokalen Ressource mit Hilfe eines Spreedsheet-Dokuments manuell erledigst.

Die Azure Migrate Appliance

Im Kontext von Azure Migrate stellt Microsoft mit der Azure Migrate Appliance und der Replication Appliance zwei verschiedene Software-Appliances zur Verfügung, die je nach Migrationsszenario eine unterschiedliche Rolle im Azure Migrate-Prozess spielen und unterschiedliche Funktionen bereitstellen. Du kannst dich hierbei eigentlich nicht vertun, da dich Azure Migrate sauber durch die Projekt-Konfiguration führt. Trotzdem halte ich es für richtig, dass du die Unterschiede kennst.   

Die Azure Migrate Appliance dient in erster Linie der Ermittlung und Bewertung physischer oder virtueller Server an lokalen Standorten oder anderen Clouds. Sie ermittelt also lokale Server und sendet kontinuierlich Server-Metadaten und Leistungsdaten an Azure Migrate. Sie arbeitet vollständig agentenlos, d. h. auf den zu bewertenden physischen oder virtuellen Servern müssen keine Agenten installiert werden. In Summe stellt die Appliance folgende Dienste zur Verfügung:

• Der Appliance-Konfigurations-Manager ist eine Webanwendung. Diese kannst du im Verlauf der Bereitstellung mit Details zu deinen zu untersuchen Quellen (Hyper-V-Sever, VMware vCenter-Systeme) konfigurieren, um die Ermittlung und Bewertung von Servern (z. B. VMs, die auf den konfigurierten Quellen laufen) zu starten.
• Der Ermittlungs-Agent sammelt dann die Konfigurationsmetadaten deiner Server, um diese zum Erstellen von lokalen Bewertungen zu verwenden.
• Der Bewertungs-Agent kommt zum Sammeln von Leistungsmetadaten deiner Server zum Einsatz, wenn du auch leistungsbasierten Bewertungen verwenden möchtest.
• Schließlich gibt es auch einen SQL-Ermittlungs- und -Bewertungs-Agent. Dieser sendet die Konfigurations- und Leistungsmetadaten von SQL-Server-Instanzen und -Datenbanken an Azure, wenn du solche Workloads auf deinen VMs betreibst.
• Gleiches gilt für den Ermittlungs- und Bewertungs-Agent für Web-Apps. Er sendet die Konfigurationsdaten deiner Web-Apps an Azure
• Natürlich wird auf der Appliance auch ein Dienst für automatische Aktualisierungen ausgeführt. Er kann damit sämtliche Agents, die auf der Appliance ausgeführt werden, auf dem neuesten Stand halten.

Bis hierher handelt es sich ausnahmslos um Dienste, die erforderlich sind, wenn du die Azure Migrate Appliance ausschließlich als Assessment-Lösung für Hyper-V- oder VMware-basierte Workloads einsetzenten möchtest. Während du bei der späteren Replikation und Migration im Falle von Hyper-V lediglich einen Azure Site Recovery-Provider auf deinen Hyper-V-Hosts, sowie den Microsoft Azure Recovery Services-Agent auf den beteiligten VMs installieren musst (wir kommen im Teil 2 auf diesen Aspekt zurück) hast du bei VMware zwei Möglichkeiten.

Die agentenlose Migration verwendet die Azure Migrate Appliance ebenfalls für die Replikation und Migration und macht sich dabei VMware-Techniken, wie VMware-Snapshots und das Changed-Block.Tracking-Protokoll (CBT) zu nutze. Ich habe in https://incas-training.de/blog/effizientes-bewerten-von-vmware-migrationen-in-die-cloud-mit-azure-migrate/ das VMware-Szenario beschrieben. In diesem Fall kommen auf der Azure Migrate Appliance zwei weitere Dienste zum Einsatz:

• Der DRA-Agent orchestriert die Server-Replikation und koordiniert die Kommunikation zwischen replizierten Servern und Azure.
• Der Gateway-Dienst sendet dann replizierte Daten an Azure

Wenn wir in Teil 2 die Ermittlung und Bewertung von unter Hyper-V ausgeführten Servern einrichten, verwenden wir in unserem gerade erstellten Projekt das Werkzeug „Azure Migrate: Ermittlung und Bewertung“ und stellen die Azure Migrate-Appliance bereit. Die Appliance ermittelt kontinuierlich lokale Server und sendet Servermetadaten und Leistungsdaten an Azure. Die Appliance wird einfach als Vorlage für Server bereitgestellt, die in einer Hyper-V- (VHD-Vorlage) oder VMware- (OVA-Vorlage) laufen. Man kann die Appliance aber auch mit Hilfe eines Powersshell-Skriptes bereitstellen (mehr dazu in Teil 2).

Die Replication Appliance kommt also nur bei der agentenbasierten Replikation von VMware-Workloads, VMs in anderen Clouds oder physischen Servern zum Einsatz. Sie koordiniert dann die Kommunikation und verwaltet die Datenreplikation für lokale VMware-VMs und physische Server. Außerdem fungiert sie als Replikationsgateway, optimiert die Replikationsdaten mittels Caching, Komprimierung und Verschlüsselung und sendet sie an Azure. Außerdem triggert sie die Push-Installation des Mobility Service auf den zu replizierenden Computern.

Zusammenfassend lässt sich also für den Einsatz von Azure Migrate in Bezug auf VMware- und Hyper-V Szenarien folgenden sagen: Bei Hyper-V wird die Azure Migrate Appliance nur für die Bewertung benötigt. Die spätere Replikation und Migration erfolgt unter Zuhilfenahme des Dienstes Azure Site Recovery (ASR). Die dafür erforderlichen Komponenten sind der Azure Site Recovery-Provider auf dem Hyper-V-Host, sowie der Microsoft Azure Recovery Services-Agent auf den zu migrierenden VMs. ASR ist eine mit Hyper-V-Replika vergleichbare Technologie, die agentenlos ist.

Bei VMware hast du die Wahl zwischen einer agentenlosen und agentenbehafteten Technologie. Bei ersterer kommt die Azure Migrate Appliance sowohl für das Assessment, als auch für die Replikation und Migration zum Einsatz. Microsoft nutzt dann VMware-Technologien wie Snapshots und Changed Block Tracking (CBT). Die agentenbasierte Replikation/Migration kannst du ebenfalls für VMware-Workloads, sowie physische Server und VMs in anderen Clouds einsetzen. In diesem Fall benötigst du zusätzlich die Replication Appliance. Sie führt die eigentliche Replikation durch und installiert den Mobility Service auf den zu replizierenden VMs.

Wenn aber die VMware-Replikation auch agentenlos funktioniert und du bei der agentenbasierten Replikation sogar zwei Appliances benötigst (sofern du das Assessment mitberücksichtigst) stellt sich dir sicher die Frage, worin der Vorteil der agentenbasierten Methode liegt? Diese möchte ich die abschließend gerne beantworten:

Du hast z. B. eine granularere Kontrolle, denn die agentenbasierte Methode ermöglicht eine detailliertere Steuerung und Überwachung der Replikation und Migration. Dies kann besonders nützlich sein, wenn du spezifische Anpassungen oder Optimierungen vornehmen möchtest. Ferner bietet die agentenbasierte Methode Unterstützung für eine breitere Palette von Szenarien, denn sie unterstützt nicht nur VMware-VMs, sondern auch physische Server und VMs in anderen Clouds wie AWS und GCP. Außerdem stellt die agentenbasierte Methode viele erweiterte Funktionen zur Verfügung, wie z.B. die Unterstützung von Pass-Through-Datenträgern und UEFI-Start. Ferner optimiert die bei der agentenbasierten Methode zum Einsatz kommenden Replication Appliance die Datenübertragung, indem sie die Replikationsdaten komprimiert und verschlüsselt, bevor sie sie an Azure sendet.