Die Cloud bietet viele neue Möglichkeiten und steht auf Knopfdruck zur Verfügung. Und genau das birgt diverse Gefahren. Du startest in dein Cloud-Abenteuer, startest die ersten Services und merkst dann schon bald, dass du einen Fehler begangen hast, beispielsweise die Wahl des falschen Subscription – Types. Üblicherweise hast du zudem deine Services über verschiedene Resourcegroups verteilt. Ich wurde daher schon öfters mit der Frage «Wie kann ich eine Migration der bestehenden Azure Services verteilt in Multi – Resourcegroups in eine neue Azure Subscription durchführen?» konfrontiert. Mit diesem Beitrag versuche ich diese Frage möglichst umfassend zu beantworten.
Machbarkeit der Migration in neue Azure Subscription
Als erstes ist die Frage zu beantworten, ob eine Migration von Azure Services in eine neue Azure Subscription überhaupt möglich ist. Hierzu gibt es keine klare Antwort. Während die meisten Services inzwischen problemlos migriert werden können, gibt es noch gewisse Ressourcen-Typen die Limitierungen aufweisen oder die Migration schlichtweg nicht möglich ist. Verschaffe dir entsprechend zuerst ein Bild, welche Ressourcen-Typen du gerne migrieren möchtest. Am einfachsten gelingt dir dies mit dem folgenden PowerShell Script.
$DesktopPath = [Environment]::GetFolderPath("Desktop")
Set-ExecutionPolicy Unrestricted
Import-Module -Name Az
Connect-AzAccount
Get-AzResource | Select-Object -Property Name,ResourceType,Sku | Export-Csv -Path $DesktopPath\azure-resource-export.csvDieser Script verbindet sich mit deiner Subscription und exportiert alle deine Azure-Services in ein übersichtliches CSV und speichert es mit dem Namen «azure-resource-export.csv» auf deinem Desktop. Dieses CSV verwendest du zur Beurteilung der Migrationsfähigkeit. Denn gewisse Services weisen Limitierungen auf.
Services mit Limitierungen
Die Anzahl der Services welche Limitierungen aufweisen hat sich laufend verkleinert, so dass es sich heute nur noch um wenige handelt. Die Folgende Tabelle zeigt die mir am wichtigsten erscheinenden Limitierungen.
| Service | Beschreibung | Migration möglich |
|---|---|---|
| App Services | Können migriert werden, jedoch nur aus der ursprünglichen Resourcegroup, in welcher der Service erstellt wurde. Stell sicher, dass du die Migration aller abhängigen Services aus dieser Resourcegroup durchführst. | Mit Einschränkung |
| Azure Active Directory Domain Services (AAD DS) | Eine Migration auf eine neue Azure Subscription wird nicht unterstütz. | Nicht möglich |
| Recovery Services | Regional bedingt. Paar wenige Regionen sind nicht unterstützt. Zudem sollte eine geschützte VM gemeinsam mit dem Vault migriert werden. Restorepointcollections können nicht migriert werden und müssen vor der Migration gelöscht werden (in der Regel unkritisch). | Mit Einschränkung |
| Marketplace – Services | Services die aus dem Azure Marketplace erstellt wurden, können NICHT migriert werden. Selbst wenn es sich bspw. nur um eine Azure VM handelt. | Nicht möglich |
Da Microsoft bestrebt ist die Limitierungen weiter zu minimieren, ist diese Liste keinesfalls als komplett zu betrachten. Eine komplette und aktuelle Liste der Limitierungen findest du unter folgendem Link. https://docs.microsoft.com/en-us/azure/azure-resource-manager/management/move-support-resources
Vergleiche deine CSV-Liste mit der Liste von Microsoft und halte fest, ob sich deine Services alle problemlos migrieren lassen, ob ein Workaround notwendig ist, oder ob die Migration gar verhindert ist (beispielsweise durch AAD DS).
Systemauswirkungen der Migration
Bevor du mit der Planung der Migration weiterfährst, solltest du dir die Frage stellen, welchen Einfluss die Durchführung auf die bestehenden Azure Services, während und nach der Migration hat. Die Antwort auf diese Frage ist durchaus positiv. Denn die Migration von Ressourcen in eine neue Azure Subscription hat keinen direkten Einfluss auf den Service selbst. Während Azure die Ressourcen beim Migrationsprozess einfriert und so vor veränderungen schützt, läuft der eigentliche Service unterbruchsfrei weiter. Eine Migration an sich hat dadurch keinen Einfluss auf das Tagesgeschäft. Trotzdem ist ein angekündigtes Wartungsfenster in der Regel nötig. Eine Azure Ressource hat nämlich eine spezifische Ressource-ID, welche sich teils aus der Azure Subscription ID zusammensetzt. Migrierst du also deinen Service auf eine andere Subscription, so erhält die Ressource eine neue Ressource-ID. Beispiel: https://portal.azure.com/#@graber.cloud/resource/subscriptions/500axxxx-xx00-00xx-x0x0-xx000xxxx0xx/resourceGroups/RG-name/providers/Microsoft.Network/dnszones/graber.cloud/overview
(Der markierte Teil verändert sich = Subscription-ID)
Du sollst also prüfen, ob diese ID in Verwendung ist. Das ist leider nur über deine hoffentlich vorhandene Dokumentation herauszufinden. Andernfalls gilt «Trial And Error».
- Falls du mit einer deiner Applikationen oder Custom-Scripts auf diese ID zeigst, so musst du lediglich den Subscription ID Teil des Ressource-ID Strings anpassen, nachdem die Migration abgeschlossen ist.
- Ist die Ressource-ID nicht in Verwendung, so brauchst du diesbezüglich nichts weiter zu beachten.
Hinweis: Hast du nicht bemerkt, dass die Ressource-ID in Verwendung ist, so kannst du die Ressource nach der Migration einfach wieder zurück auf die «alte» Subscription Migrieren, um die ID-Veränderung rückgängig zu machen.
Durchführung der Azure Subscription Migration
Hast du die zuvor genannten Punkte der Machbarkeit geprüft und du und deine Ressourcen sind bereit für die Migration, so kannst mit den folgenden Schritten weiterfahren. Beachte, dass in diesem beschriebenen Szenario die Ressourcen auf Multi – Resourcegroups verteilt sind. Hast du in deiner Ausgangslage alle zu migrierenden Ressourcen bereits in einer einzigen Resourcegroups, so kannst du das folgende Unterkapitel «Konsolidierung von Multi – Resourcegroups» überspringen.
Konsolidieren von Multi – Resourcegroups
Wenn deine Ressourcen in verschiedenen Resourcegroups verteilt sind, so musst du diese zuerst in eine einzige Resourcegroup konsolidieren. Das ist so, weil Ressourcen Abhängigkeiten aufweisen, aber nur eine Resourcegroup und deren Azure Ressourcen für den Migrationsauftrag gewählt werden kann. Zum besseren Verständnis gehe ich hier davon aus, dass zum Beispiel die VM01 in der Resourcegroup «RG01» und das Azure Backup «Bckp02» von «VM01» in der Resourcegroup «RG02» platziert ist.
Bevor du weiterfährst, notiere dir in irgendeiner Form, wie deine Ressourcen und Resourcegroups aufgeteilt sind, damit du diese Ordnung auf der neuen Subscription am Schluss wieder herstellen kannst. Hast du dies notiert, dann verschiebe alle deine Ressourcen in die gleiche Resourcegroup. In diesem Beispiel «Bckp02» von «RG02» in «RG01». Wähle dazu die zu verschiebende Resourcegroup «RG02» aus und klicke unter «Overview» auf «Move» und «Move to another resource group».
Nun erscheint dir eine Liste aller Ressourcen der Resourcegroup. Stelle sicher, dass du alle Ressourcen selektierst, welche du migrieren möchtest (meist sind das alle). Wähle zudem die Ziel – Resourcegroup aus (hier «RG01»).
Bestätige anschliessend mit «OK». Azure verifiziert nun die Migration auf die Durchführbarkeit. Dies dauert je nach Anzahl und Art der Services ein paar Minuten. Wenn alles okay ist, so startet die Migration automatisch. Wenn die Resourcegroups zu Resourcegroups Migration erfolgreich durchgelaufen ist, hast du nun alle deine zu migrierenden Ressourcen in eine einzige Resourcegroup («RG01»). Dies ist die Grundlage, damit du mit dem nächsten Schritt weiterfahren kannst.
Hinweis: Wenn du App Services verwendest, denke daran, dass du die Resourcegroup des App Services zur Migration verwenden musst. Das ist somit die Resourcegroup, in welcher du alle anderen Services vor der Subscription – Migration sammelst.
Azure Subscription Migration
Bevor du mit der eigentlichen Migration beginnst, prüfe nochmals, ob du alle Vorbereitungen befolgt hast.
- Du hast das PowerShell-Script für den Export der Ressourcen durchgeführt und das CSV-File gespeichert.
- Die Services im CSV-File hast du mit der Liste von Microsoft auf deren Migrationstauglichkeit geprüft.
- Ob und welche Applikationen und Scripts auf eine Ressource-ID zugreifen, um diese nach der Migration anzupassen, hast du validiert.
- Du hast ein Wartungsfenster für die Migration einberufen und kommuniziert (nicht nötig, aber empfohlen).
- Die Ausgangssituation deiner Ressourcen und Resourcegroups hast du notiert, so dass du sie wiederherstellen kannst.
- Du hast alle zu migrierende Ressourcen in eine einzige Resourcegroup konsolidiert.
Die Vorbereitung selbst ist die wesentliche Arbeit. Die Durchführung der Migration an sich ist bei sauberer Vorbereitung einfach. Hast du alle Vorbereitungen gewissenhaft getroffen, dann bist du bereit für die Migration. Navigiere dafür zu deiner Resourcegroup, deren Ressourcen du migrieren möchtest (in Beispiel wäre das «RG01») und klicke wieder auf «Move». Wähle nun «Move to another subscription».
Gleich wie bei der Konsolidierung der Resourcegroups kannst du nun alle Ressourcen auswählen, die du gerne migrieren möchtest. Wähle zudem die neue Azure Subscription aus, auf welche du die Ressourcen migrieren möchtest und erstelle direkt eine neue Resourcegroup mit demselben Namen der bestehenden (Beispiel: «RG01»).
Auch hier verifiziert Azure wieder automatisch die Durchführbarkeit der Migration, was ein paar Minuten in Anspruch nehmen kann. Die Migration auf die neue Azure Subscription wird dann automatisch in Angriff genommen. Beachte, dass dies bei einer neuen Subscription etwas länger dauern kann, da Azurezuerst alle nötigen Resource-Provider auf der Azure Subscription registrieren muss. Du wirst informiert, sobald die Migration erfolgreich durchgeführt werden konnte.
Herzlichen Glückwunsch. Hat Azure keine Fehler ausgegeben, so hast du die Migration deiner Ressourcen auf eine neue Azure Subscription erfolgreich durchgeführt.
Post – Migration Check
Nach der erfolgreichen Migration deiner Azure Ressourcen in eine neue Azure Subscription ist noch nicht ganz Schluss. Du hast noch ein paar wenige, aber dennoch wichtige Arbeiten vor dir.
Split in Resourcegroups
Verschiebe deine Ressourcen nun wieder in die gewünschten Resourcegroups. Erstelle daher zuerst auf der neuen Subscription alle Resourcegroups, welche du benötigst. Verwende dazu deine Notizen der Vorbereitung, dass du wieder die gleiche Struktur herstellen kannst. Erstelle also eine Resourcegroup nach der anderen und verschiebe dann die Ressourcen wie wie zuvor mit «Move» in die gewünschte Resourcegroup. Wiederhole diesen Prozess für jede Resourcegroup, bis du die Struktur wiedererlangt hast (im Beispiel «RG01» mit «VM01» und «RG02» mit «Bckp02»).
Azure Ressource-ID Anpassung
Hast du die gewünschte Resourcegroups – Struktur erlangt, so verändert sich auch die ID der Azure Ressourcen nicht mehr. Ergänze nun alle deine Scripts und Applikationen mit der neuen Ressource-ID. Diese hast du bereits in der Vorbereitung deiner Dokumentation entnommen. Hast du die Anpassungen gemacht, prüfe die Funktionalität der Scripts und Applikationen.
Kommunikation und Abschluss
Hast du die Vorbereitungen sauber getätigt, solltest du auch keine Probleme bei der Migration selbst gehabt haben. Hast du im Anschluss den kompletten Post – Migration Check erfolgreich durchgeführt, so ist die Migration nun komplett und erfolgreich durchgeführt. Kommuniziere den Erfolg der Azure Subscription Migration den entsprechenden Stellen und beende somit auch das Wartungsfenster offiziell.
Herzlichen Glückwunsch zur erfolgreichen Migration.
German 
English