Wir stoßen immer wieder an die Grenzen des Portals, wenn es darum geht Subscription-übergreifend Ressourcen umzuziehen. Das hat uns dazu bewegt einmal aufzuzeigen, wie wir eine Migration angehen. Die folgenden Schritte leiten Sie durch diesen Prozess.
Um welche Migrationsszenarien geht es hier?
In Azure gibt es prinzipiell zwei Bereitstellungsmethoden:
- Classic – Azure Service Manager bzw. ASM
- Azure Resource Manager bzw. ARM
Neue Entwicklungen finden in Zukunft nur noch im ARM Modell statt, weshalb eine Migration zu ARM – hierfür gibt es eine weitere Möglichkeit innerhalb einer Subscription auf die hier nicht eingegangen wird – ohnehin zu empfehlen ist, es sei denn es kommen Dienste aus Azure Service Manager zum Einsatz, die noch nicht in Azure Resource Manager bereitstehen.
In CSP besteht keine Möglichkeit ASM Ressourcen zu betreiben, weshalb das Ziel immer ARM ist. Die Quelle kann aber beide Typen beinhalten, weshalb wir zwei Migrationswege benötigen. Des weiteren kann eine bestehende Open Subscription nicht in eine CSP Sub umgewandelt werden. Deshalb schauen wir uns zwei Wege an, die uns den Weg in CSP ebnen.
- ASM2ARM – von ASM Quellen in die moderne ARM Umgebung (direkt zu ASM2ARM)
- ARM2ARM – Migration von ARM Quellen in eine andere Subscription (direkt zu ARM2ARM)
Warum machen wir das gerade verstärkt?
Wir als Microsoft Gold Partner stehen momentan vor der Aufgabe bestehende Azure Subscriptions umzuziehen. Viele unserer Kunden betreiben ihre Azure Infrastruktur im Open Lizenzprogramm von Microsoft. Das Cloud Solution Provider Programm (CSP) bietet mittlerweile fast alle Dienste an, weshalb einem Umzug von technischer Seite meistens nichts mehr im Wege steht. Aber wie bekommen wir die virtuellen Maschinen von einer Subscription in die andere?
Microsoft bietet Stand heute keinen Weg an, wie IaaS Ressourcen von einer Subscription in eine andere umgezogen werden können. Wenn ein Kunde aber zu CSP migrieren möchte, dann benötigen wir ein Migrationsweg, der genau das abdeckt. Schließlich wollen wir nicht parallel virtuelle Maschinen aufbauen und Daten von Hand kopieren. Das ganze soll möglichst automatisiert von Statten gehen.
Warum migrieren Azure Nutzer zu CSP?
Vielleicht fragen Sie sich, weshalb man überhaupt umziehen möchte. In CSP hat man einige Vorteile, die z.B. im Open Lizenzprogramm nicht zur Verfügung stehen. Der wichtigste Punkt ist meiner Meinung nach, dass man sich nicht mehr um das Guthaben kümmern muss und folglich auch das Guthaben nicht ausgehen kann, was den Stillstand der Umgebung zur Folge hätte. Die Zahlung bei CSP findet auch nicht mehr Prepaid, sondern nach Bedarf und Postpaid statt. Auf der WPC 2016 hat Microsoft angekündigt, dass CSP der neue Königsweg wird. Wir gehen da selbstverständlich mit und helfen Ihnen dabei Ihre Umgebung umzuziehen.
Wie funktioniert die Migration von ASM zu ARM?
Ein Mitarbeiter von Microsoft hat ein Tool namens migAZ geschrieben, dass viele Schritte automatisiert. Dennoch sind händische Anpassungen und ein bisschen PowerShell notwendig um die Ressourcen umzuziehen.
Ablauf ASM2ARM
In der Ausgangssituation gibt es zwei klassische Virtuelle Maschinen (ASM)
Mit Hilfe des Tools migAZ (Downloadlink) kann man sich in die “alte” Subscription einloggen, die betroffenen Ressourcen auswählen und schließlich ein Resourcemanager Template generieren, dass wir später in der neuen Umgebung bereitstellen.
Das Template muss ggf. noch angepasst werden. z.B. wenn statische, externe IP Adressen verwendet werden sollen, oder bestimmte Ressourcen nicht benötigt werden.
Ich habe für dieses Deployment ein paar Ressourcen herausgenommen, die nicht in Benutzung waren.
Mit Hilfe von PowerShell wird ein erstes Deployment durchgeführt. Dazu melden wir uns am Ziel an.
Im nächsten Schritt lassen wir die Resource Group erstellen und führen das Deployment durch.
Diese folgenden Fehlermeldungen beziehen sich auf die virtuellen Maschinen, die nicht erstellt werden konnten. Das ist korrekt. Noch haben wir die Festplatten nicht migriert auf die die Parameter im Template verweisen.
Durch eine Anpassung des Skriptes ließe sich diese unschöne Fehlermeldung vermeiden, z.B. dadurch, dass man im ersten Schritt die VMs noch nicht deployed. Der Standard gibt das leider nicht her.
Jetzt beginnen wir die Festplatten zu kopieren. Dieser Kopiervorgang kann je nach Nettogröße der Festplatten eine Weile dauern.
Nachdem alle Festplatten erfolgreich kopiert wurden, kann das Template noch einmal eingespielt werden.
Im Resultat sehen wir, dass alle Ressourcen aus dem Template erstellt wurden. Die virtuellen Maschinen sind nach dem Start wieder erreichbar. Die externe IP kann aber leider nicht mitgenommen werden. Zudem muss ggf. ein VPN neu aufgebaut werden.
Nachdem die Zugriffe und die Inhalte erfolgreich getestet wurden, können die neuen ARM Server in den Livebetrieb gehen.
Wie funktioniert die Migration von ARM VMs in eine andere Subscription?
Leider gibt es für diesen Migrationspfad noch kein Tool. Aber wir haben den Vorteil, dass hier die Ressourcen bereits in ARM bestehen und folglich ein ARM Template aus dem Bestand erstellt werden kann. Auch hier benötigen wir für die meisten Schritte die PowerShell.
Ablauf ARM2ARM
In der Zielsubscription erstellen wir zunächst die benötigten Speicherkonten.
Anders als bei ASM2ARM werden hier die Festplatten zunächst kopiert. Die Grundlage für das Skript zum Kopieren der vhds habe ich von Opsgility (Link). Je nach Umgebung sind hier Anpassungen nötig.
Nachdem der Kopiervorgang abgeschlossen ist, muss man sich am Quellkonto anmelden.
Dann kann man das ARM Template exportieren. Eigentlich kann man die Templates auch über das Portal herunterladen. Dann fehlen allerdings einige Parameter, die man erst wieder nachtragen muss. Auf diese Art haben wir alles in einer Datei.
Auch bei der Migration zwischen ARM Subscriptions müssen ein paar Anpassungen am Template durchgeführt werden.
Im nächsten Schritt meldet man sich am Ziel an.
Und spielt das Template ein.
Nach dem Abschluss sind wieder alle Ressourcen erstellt worden und man kann sich um die Prüfung der Migration kümmern.
Achtung: Diese Pfade liefern einen Ansatzpunkt, sind aber nicht zwingend vollständig. Wir übernehmen keine Haftung für die Richtigkeit, oder Vollständigkeit. Wir haben alle Migrationen Offline durchgeführt. Das heißt die virtuellen Maschinen waren die ganze Zeit über ausgeschaltet. Manche Teile der Konfiguration können nicht mit umgezogen werden. So ändert sich beispielsweise der DNS Namen, sowie die externe IP Adresse der Ressourcen.
Fazit
Wir wünschen uns eigentlich immer noch ein Tool, mit dem wir den Umzug ähnlich wie bei der Migration von ASM zu ARM innerhalb einer Subscription durchführen können. Bis das soweit ist, behelfen wir uns mit dieser Methode.
Wenn Sie Fragen zu einer Migration haben, oder Unterstützung benötigen, dann kommen Sie auf uns zu. Wir helfen Ihnen gerne weiter. Natürlich bringen wir auch ihre lokale Umgebung in die Cloud, wenn Sie das möchten.