Migrieren von VMware-VMs in die Microsoft-Cloud mit Azure Migrate

Migrieren von VMware-VMs in die Microsoft-Cloud mit Azure Migrate 1 – Architektur und Discovery

Nachdem wir uns im ersten Teil mit den prinzipiellen Fähigkeiten von Azure Migrate zum Migrieren von lokalen Hyper-V oder VMware VMs und SQL-Server-Datenbanken im Allgemeinen, sowie exemplarisch mit der Entdeckung und Bewertung von VMware-VMs befasst haben, soll es nun etwas konkreter um die Architektur von Azure Migrate und den Discover-Prozess unter VMware gehen:

Du benötigst mehr Know-how rund um MS Azure? Dann empfehlen wir dir unsere Microsoft Azure Schulungen!

Azure Migrate unterstützt im Zusammenhang mit VMware sowohl eine Agenten-lose, als auch eine Agenten-behafte Migration von ESXis-VMs. Die Replikationsoption ohne Agent nutzt unter anderem VMware-Snapshots und VMwares CBT-Technologie (VMware Changed Block Tracking), um Daten von Datenträgern virtueller Computer zu replizieren.

Viele weitere Tipps und Tricks rum um die Produktpalette von VMWare zeigen wir dir gerne in unseren VMWare Schulungen.

Die Agent-basierte Migration kann auch zur Migration anderer lokaler virtueller Server sowie virtueller Computer (VMs) in privaten und öffentlichen Clouds (einschließlich AWS-Instanzen und GCP-VMs) verwendet werden. Diese Methode stützt sich unter anderem auf eine Reihe von Back-End-Funktionen des Azure Dienste https://azure.microsoft.com/de-de/services/site-recovery/ Site Recovery.

Die Architektur der Agenten-basiertes Migration bei VMware zeigt folgende Abbildung:

Die drei wesentlichen Komponenten der Agenten-basierten Architektur sind die Azure-Replication-Appliance (nicht die Azure Migrate Appliance), welcher ihrerseits aus „Konfigurationsserver“ und „Prozessserver“ besteht und der Mobilitätsdienst, der eigentliche Agent. Die Repliation-Appliance besteht aus Konfigurationsserver und Prozessserver. Beide werden in Form einer Appliance auf einem lokalen Server (VM) bestrieben. Dieser fungiert als Brücke zwischen der lokalen Umgebung und der Servermigration. Die Appliance erkennt den lokalen Serverbestand, sodass die Servermigration die Replikation und Migration orchestrieren kann.

Dabei stellt der Konfigurationsserver eine Verbindung mit der Servermigration her und koordiniert die Replikation, während der Prozessserver die Datenreplikation durchführt. Er empfängt dazu die Serverdaten, komprimiert und verschlüsselt sie und sendet sie an Azure, wo die Servermigration die Daten dann auf verwaltete Datenträger schreibt. Auf den zu migrierenden VMs ist dann jeweils der eigentliche Agent (Mobilitätsdienst) zu installieren. Er sendet Replikationsdaten vom Server an den Prozessserver.

Agenten-lose Migration mit Azure Migrate und der Azure Migrate Appliance

Default bei VMware ist, wie auch bei der Migration von Hyper-V-VMs allerdings die Agenten-lose Migration, bei der die erwähnte Azure-Migrate-Appliance im Mittelpunt steht. Sie ist in VMware einfacher bereitzustellen, hat jedoch derzeit einige Einschränkungen, welche aber nur im Einzelfall ein Hindernis darstellen sollten. So ist z. B. die Anzahl gleichzeitiger Replikationen auf maximal 300 VMs beschränkt. Ferner gibt es derzeit noch Probleme mit Linux/UEFI-Boot, verschlüsselten Festplatten/Volumes sowie im Zusammenhang mit NFS-Volumes.

Auch unter Hyper-V unterstützt Azure Migrate eine Agenten-lose Migration. Sie stützt sich auf einen für Hyper-V optimierten Migrationsworkflows, bei dem man „lediglich“ auf den Hyper-V-„Hosts“ oder Cluster-Knoten einen Software-Agenten benötigt. Auf den Hyper-V-VMs selbst muss nichts installiert werden.

Alternativ lässt sich auch bei Hyper-V ähnlich wie bei VMware eine Methode nutzen, die sich auf Azure Site Recovery stützt, Azure‘s Tool für die Notfallwiederherstellung. Azure Site Recovery und Azure Migrate nämlich nutzen eine Reihe Technologiekomponenten gemeinsam, welche für die Datenreplikation verwendet werden können, aber ihrerseits eigentlich unterschiedlichen Zwecken dienen.

Voraussetzungen

Um die im Folgenden für VMware geschilderten Möglichkeiten nachvollziehen zu können benötigst du eine vSphere-Umgebung mit vCenter ab 5.5, ESXi ab 5.5 und geöffnetem Port 443 in der ESXi-Firewall. Die Azure-Migrate Appliance benötigt mindestens 8 vCPUs, 32 GB RAM sowie 80 GB freiem Speicherplatz auf dem Datenträger. Was die reine Ermittlung von Konfigurations- und Leistungsmetadaten von virtuellen Servern betrifft unterstützt Azure Migrate, bzw. die Azure Migrate Appliance alle Windows- und Linux-Betriebssystemversionen.

Voraussetzung für die Ermittlung installierter Anwendungen und für die Abhängigkeitsanalyse bei der Agenten-freien Methode ist, dass die VMware Tools (ab 10.2.1) auf den Servern installiert sind und ausgeführt werden. Auf Windows-Servern muss zudem PowerShell ab Version 2.0 installiert sein. Ferner muss das SSO-Konto, dass man auf vSphere-Seite nutzt selbstverständlich für das in Teil 1 kurz skizzierte Bereitstellen der Azure Migrate Appliance, bzw. VMs über eine OVA-Datei im Allgemeinen berechtigt sein.

Azure Migrate selbst benötigt einen vCenter Server-Account mit Lesezugriff für das Ermitteln (Discover) und Bewerten (Assessment), die in der VMware-Umgebung laufen. Möchte man zusätzlich auch installierte Anwendungen ermitteln oder die Abhängigkeitsanalyse ohne Agent ausführen, braucht das Konto in VMware aktivierte Berechtigungen für VM-Gastvorgänge. Hat man ein Migrations-Projekt in Azure angelegt, kann man im Abschnitt „Migration Tools“ das gewünschte Werkzeug hinzufügen wie z. B. „Azure Migrate: Server Migration“, aber auch für die Migration stehen verschiedene ISVs, wie z. B. Zerto zur Verfügung.

Hat man sich für „Azure Migrate: Server Migration“ entscheiden, kann man mit einem Klick auf „Ermitteln“ ähnlich wie beim Assessment die gewünschte Quellumgebung konfigurieren. So steht etwa bei der Frage „Sind Ihre Computer Virtualisiert“ der Eintrag „Hyper-V oder Andere (AWS, CGP)“ zur Verfügung. Ferner lässt sich hier bestimmen, ob die Migration Agenten-basiert oder ohne Agenten-los durchgeführt werden soll. Zudem wählt man hier die zu verwendende Appliance aus (Vorhandene Appliance aufskalieren), bzw. erstellt eine Neue, und generiert einen Projektschlüssel.

Mit diesem lässt sich die Appliance selbst dann VMware-seitig im „Appliance-Gastsystem“ authentifizieren und konfigurieren. Den „Appliance Configuration Manager“ findet man, indem man im Gastsystem im Browser die URL https://<vm-hostname>:44368 aufruft.

Im Abschnitt „2. Register with Azure Migrate“ ist dann der Projektschlüssel zu hinterlegen, gefolgt von einem Klick auf „Login“. Hierbei muss man sich den „Device code“ kopieren und dann noch einmal auf „Copy code & Login“ klicken.

Danach kann man sich im Browser mit dem gewünschten Microsoft-Organisationskonto bei Azure anmelden. Das Ergebnis sollte etwa so aussehen:

Die Arbeiten an der Appliance sind damit erledigt und man kann sich wieder dem Dienst Azure-Migrate im Azure-Portal zuwenden: Hier sollte jetzt im Abschnitt „Migrationstools“ bei „Azure Migrate: Server Migration“ die Meldung „Ermittlung wird ausgeführt“ erscheinen.

Das Ergebnis könnte z. B. so aussehen:

Jetzt hat der User entweder die Möglichkeit, direkt in die Liste ermittelte Server zu wechseln, in dem er dem Link mit der Anzahl folgt, um dann gezielt einzelne Server für die Replikation auszuwählen oder man klickt direkt auf „Replizieren“, wählen dann wieder bei „Sind Ihre Computer virtualisiert“ den Eintrag „Ja, mit VMware vSphere“ und erneut die zu verwendende Appliance aus:

Schauen wir uns im dritten Teil an, wie Replikation und Migration ablaufen.