Azure Migrate kann virtuelle Maschinen von ESXi-Hosts nach Azure übertragen, wahlweise mit einem lokalen Agenten oder einer Methode, die sich auf Azure Site Recovery stützt. Die Option ohne Agent nutzt unter anderem Hypervisor-Snapshots und VMwares Changed Block Tracking.
Die agentenbasierte Migration eignet sich auch für andere virtuelle Server in privaten und öffentlichen Clouds (einschließlich AWS-Instanzen und GCP-VMs). Diese Methode stützt sich unter anderem auf eine Reihe von Back-End-Funktionen des Azure Dienstes Site Recovery.
Die drei wesentlichen Komponenten der agentenbasierten Architektur sind der Konfigurations- und Prozess-Server. Beide sind in der Azure Replication Appliance (nicht Azure Migrate Appliance) enthalten. Hinzu kommt der Mobilitätsdienst.
Die Replication-VM läuft auf einem lokalen Server, der als Brücke zwischen der lokalen Umgebung und dem Cloud-Service dient. Die Appliance erkennt den lokalen Server-Bestand, so dass sie die Replikation und Migration orchestrieren kann.
Dabei stellt der Konfigurations-Server eine Verbindung mit Azure Migrate her und koordiniert die Replikation, während der Prozess-Server die Daten repliziert. Dabei verschlüsselt und komprimiert er diese und sendet sie an Azure, wo die Server-Migration sie 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 Prozess-Server.
Agentenlose Migration
Standard bei VMware ist, wie auch bei Hyper-V-VMs, die agentenlose 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 zum Beispiel die Anzahl gleichzeitiger Replikationen auf maximal 300 VMs beschränkt. Ferner gibt es aktuell noch Probleme mit Linux/UEFI-Boot, verschlüsselten Festplatten bzw. Volumes sowie im Zusammenhang mit NFS-Volumes.
Unter Hyper-V stützt sich die Migration auf einen dafür optimierten Workflow, bei dem man lediglich auf den Hosts oder Cluster-Knoten einen Software-Agenten benötigt. In den 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, ein Tool für die Notfallwiederherstellung. Es teilt sich nämlich einige Komponenten mit Azure Migrate, welche der Datenreplikation dienen, wenn auch für unterschiedliche Zwecke.
Voraussetzungen
Um die im Folgenden für VMware geschilderten Möglichkeiten nachvollziehen zu können benötigt man 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 erfordert mindestens 8 vCPUs, 32 GB RAM sowie 80 GB freien Speicherplatz auf dem Datenträger. Was die reine Ermittlung von Konfigurations- und Leistungsdaten der virtuellen Server betrifft, unterstützt Azure Migrate alle Windows- und Linux-Versionen.
Ferner muss das SSO-Konto, das man auf vSphere-Seite nutzt, für das Bereitstellen der Azure-Migrate-Appliance berechtigt sein.
Azure Migrate selbst benötigt einen vCenter-Account mit Lesezugriff für das Ermitteln (Discover) und Bewerten (Assessment) der VMware-Umgebung. Möchte man zusätzlich auch installierte Anwendungen entdecken oder die Abhängigkeitsanalyse ohne Agent ausführen, dann braucht das Konto in VMware die Berechtigungen für VM-Gastvorgänge.
Hat man ein Migrations-Projekt in Azure angelegt, dann kann man im Abschnitt Migration Tools das gewünschte Werkzeug hinzufügen, zum Beispiel Azure Migrate: Server Migration. Alternativ stehen für die Migration auch verschiedene ISVs wie etwa Zerto zur Verfügung.
VMs ermitteln
Hat man sich für Azure Migrate: Server Migration entscheiden, dann 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 Auswahl.
Ferner lässt sich hier bestimmen, ob die Migration agentenbasiert oder agentenlos erfolgen soll. Zudem wählt man die zu verwendende Appliance aus (etwa jene aus dem Bewertungsvorgang) bzw. erstellt eine neue, und generiert einen Projektschlüssel.
Mit diesem lässt sich die Appliance selbst VMware-seitig in ihrem Gastsystem authentifizieren und konfigurieren. Den Appliance Configuration Manager findet man, indem man im Browser des Gastsystems die URL https://<vm-hostname>:44368 öffnet.
Im Abschnitt 2. Register with Azure Migrate ist dann der Projektschlüssel zu hinterlegen, gefolgt von einem Klick auf Login. Hierbei muss man 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:
Das Ergebnis könnte so aussehen:
Jetzt hat der User entweder die Möglichkeit, direkt in die Liste der ermittelten Server zu wechseln, indem er dem Link mit der Anzahl folgt, um dann gezielt einzelne Maschinen für die Replikation auszuwählen.
Alternativ klickt man direkt auf Replizieren, wählt dann bei Sind Ihre Computer virtualisiert den Eintrag Ja, mit VMware vSphere und erneut die zu verwendende Appliance aus.