OnPrem Datenbank Migration nach Azure

Einige unserer Kunden haben den Wunsch geäußert, ihre Server im Rahmen ihrer IT-Modernisierungsaktivitäten in die Cloud zu bringen, befürchten aber, dass dies, z.B. bei einem Datenbankserver mit hohem Datenbestand oder bei einer Multi-Tier / Multi-Server Architektur nicht ohne größere Ausfallzeit möglich ist.

In diesem Beitrag wird die Migration virtueller Maschinen nach Azure dargestellt. Ausgangspunkt sind hierbei zwei unter VMware betriebene virtuelle Server mit einer jeweiligen Gesamt-Plattenkapazität von 140 GB, die die zu migrierende Umgebung repräsentieren.

Vorbereitung

Zur Vorbereitung der Demonstration werden zwei virtuelle Maschinen (VM) eingerichtet, von denen die eine eine MSSQL Datenbank beherbergt (“MSServer2Azure” oder “DB-Server”). Die zweite VM (“AppServer2Azure” oder “App-Server”) stellt einen Server dar, auf dem eine Applikation betrieben wird, die auf die Datenbank zugreift. An beiden Servern sind drei Platten von 40 GB (Betriebssystem), 60 GB (DB Daten) und 40 GB (DB Logs) angeschlossen.

Zur Demonstration des Timings wird auf dem DB-Server ein Datenbankjob eingerichtet, der im zehn Sekunden Rhythmus den aktuellen Zeitstempel in die Tabelle local_time_table schreibt.

Auf dem App-Server wird - ebenfalls im zehn Sekunden Rhythmus - der aktuelle Zeitstempel in die Tabelle remote_time_table des DB-Servers geschrieben.

Damit benötigen wir zwei einfache Tabellen auf dem DB-Server, die durch folgendes Skript angelegt werden:

Das Befüllen der beiden Tabellen erfolgt mit den folgenden beiden simplen Statements:

Vorgehensweise

Auf der Azure-Home Seite wird das Icon “Azure Migrate” verwendet, um den Migrations-Wizard zu starten.

Im Migrations-Wizard stehen drei Optionen zur Verfügung:

1. Discover, assess and migrate
2. Assess and migrate databases
3. Explore more scenarios

In diesem Dokument wird die erste Möglichkeit behandelt, da sie das einfachste Allround-Verfahren für DB- und Application Server darstellt.

Nach Auswahl der Option “Discover, assess and migrate” gelangt man zu der Migrations-Seite, die i.W. aus zwei Bereichen besteht, nämlich dem ersten Bereich, in dem bestehende Kandidaten ermittelt und bewertet werden (“Azure Migrate: Discovery and assessment”) und dem zweiten Bereich, in dem nach der Bewertung die Migration durchgeführt wird (“Migration and modernization“). Doch zuvor muss ein Projekt über den Link “+ Create project” im oberen Bereich angelegt werden.

Zum Anlegen eines neuen Projektes werden lediglich vier Informationen benötigt:

1. Subscription (bereits vorbelegt, aber änderbar)
2. Name der Ressourcegruppe, der die benötigten Ressourcen zugeordnet werden sollen. Hier kann eine bestehende Gruppe gewählt oder über “Create new” eine neue Ressourcegruppe angelegt werden.
3. Name des Projektes, Informationen zu Namensanforderungen und -einschränkungen werden- wie in Azure üblich - durch Positionierung der Maus über dem Informations-Icon angezeigt.
4. Ziel-Location der zu migrierenden Objekte

Nach Eingabe der benötigten Informationen wird das Projekt über den “Create” Button angelegt und man gelangt wieder in den Wizard, in dem jetzt oben der Name des Projektes angezeigt wird. Dort wird jetzt über die Lupe der Discovery Prozess angestoßen. Dieser besteht, wie bereits in dem Wizard angegeben, aus den Phasen

• Ermitteln der Migrationskandidaten (Discover)
• Analyse der Abhängigkeiten der Kandidaten untereinander (Analyse dependencies)
• Bewertung (Assess)

Der Start des Discovery Prozesses öffnet eine Unterseite, auf der zunächst zwischen der Möglichkeit gewählt werden muss, eine Appliance zu verwenden oder die benötigten Daten über eine csv Datei zu spezifizieren. Der Hilfe-Link (“Help me choose”) beschreibt u.a. Inhalt und Struktur der benötigten csv-Datei. In diesem Beispiel wird jedoch die Appliance verwendet. Das Quellsystem besteht, wie bereits in der Einleitung erwähnt, aus zwei virtuellen VMware Maschinen.

Sobald auf der initialen Discovery-Seite der Virtualisierungstyp der Zielumgebung ausgewählt wurde, werden auf dieser Seite weitere Felder dargestellt. Als Virtualisierungstypen werden

• VMware vSphere Hypervisor
• Hyper-V
• Physikalisch oder andere (AWS, GCP, Xen, etc.) angeboten.

In unserem Fall wählen wir also VMware, sodass weitere Felder entsprechend nachfolgender Abbildung dargestellt werden. Hier muss zunächst ein Name für die herunterzuladende Migrations-Appliance vergeben und ein Schlüssel für die Einrichtung einer Migrations-Appliance generiert werden.

Die Generierung des Schlüssels benötigt ein paar Sekunden und anschließend erscheint ein weiteres Feld, in dem der Projektschlüssel dargestellt wird, der über ein Icon auf der rechten Seite dieses Feldes kopiert werden kann. Dieser Schlüssel wird beim ersten Start der Appliance erfragt, damit eine gesicherte Verbindung zwischen der Appliance und Azure eingerichtet werden kann und eine korrekte Zuordnung zu dem Projekt erfolgen kann.

Wir fahren fort mit dem Herunterladen der Appliance im OVA-Format, um diese dann in VMware entsprechend nachfolgender Abbildungen einzurichten. Dazu benötigen wir jetzt den Deployment Wizard des vSphere Clients, der entsprechend nachfolgender Abbildung und mit selektiertem vApps Feld über das Actions Menü und den Menüpunkt “Deploy OVF Template …” gestartet wird. Hinweis: Das selektierte vApps Feld wird hier von dem aufgeblendeten Actions-Menü überdeckt.

Der Deployment Wizard besteht aus sieben Seiten die in den folgenden Abbildungen dargestellt sind:

1. Auswahl des OVF / OVA Templates
2. Vergabe eines Namens für die Appliance (Default: MicrosoftAzureMigration) und Auswahl eines Zielordners
3. Auswahl einer Compute Ressource auf der die Appliance laufen soll
4. Überblickseite
5. Storage-Zuordnung
6. Netzwerk-Zuordnung
7. Abschluss

Entsprechend der Größe der OVA-Datei von 12 GB nimmt das Deployment bzw. der Upload der Datei einige Zeit in Anspruch. Anschließend sieht man im Baum der in VMware vorhandenen VM-Objekte die neue Appliance mit dem Namen “MicrosoftAzureMigration” und bei Selektion die zugehörigen Eigenschaften auf der rechten Seite.

Beim ersten Start der Appliance wird automatisch der Appliance Configuration Manager gestartet und als Verknüpfung auf dem Desktop abgelegt. Der Appliance Configuration Manager führt initial folgende Aktionen aus:

• Prüfen der Verbindung zu Azure
• Prüfen der Synchronizität zu Azure
• Prüfen der Version und ggf. Installation von Updates. Für diesen Schritt wird der Migrationsschlüssel benötigt, der zuvor in Azure im Verlauf der Einrichtung des Migrationsprojektes generiert wurde (vgl. folgende Abbildung)

Im weiteren Verlauf dieser Aktionen muss man sich bei Azure anmelden um eine PowerShell zu laden, über die die Appliance registriert wird. Hierzu wird ein entsprechender Device Code angezeigt, mit dem man sich neben Azure Login und zugehörigem Passwort authentifizieren muss.

Nach der Anmeldung bei Azure schlägt zunächst der folgende Schritt fehl, in dem das Vorhandensein des Virtual Disk Development Kit überprüft wird. Dies muss man als zip-File bei VMware herunterladen und - wie beschrieben - unter C:\Program Files\VMware\VMware Virtual Disk Development Kit entpacken. Der Download erfordert eine Registrierung bei VMware.

Ein anschließender Klick auf den Verify Button setzt hier den Fehlerstatus zurück und die Überprüfung der Voraussetzungen für die Migration ist beendet.

Damit kann der zweite Abschnitt der Appliance Konfiguration beginnen, der aus drei Schritten besteht und hier wegen der Größe des entsprechenden Fensters in zwei Teilen dargestellt ist:

1. Login und Passwort für den / die vCenter Server spezifizieren aus dem / denen VMs migriert werden sollen
2. IP-Adresse bzw. FQDN und Port für den / die vCenter Server spezifizieren
3. Zugangsdaten für die VMs spezifizieren, um die dort installierte Software zu ermitteln. Hier können für jeden Migrationskandidaten die zugehörigen Informationen hinterlegt werden. Im dargestellten Fall sind die Anmeldedaten für beide VMs gleich, sodass nur ein Eintrag benötigt wird.

Azure Arc, ein weiterer Teil dieses Fensters der sich unterhalb des “Start discovery” Buttons befindet, wird hier nicht behandelt.

Die Discovery-Phase kann je nach Umfang der VMware Umgebung längere Zeit in Anspruch nehmen.

Discovery, Abhängigkeitsanalyse, Bewertung und Überblick

Nachdem das Discovery durchgelaufen ist, können die Details in Azure über die Menüfolge “Home” > “Azure Migrate” > “Servers, databases and web apps” angesehen, Abhängigkeiten analysiert, bewertet und ein Überblick verschafft werden. Das entsprechende Fenster haben wir bereits zu Beginn dieses Artikels gesehen, jetzt liegen aber Informationen über gefundene Server und deren Betriebssysteme vor.

Zur Durchführung einer Bewertung wird der Menüpunkt “Assess” verwendet, hinter dem sich vier Links als potentielle Migrationsziele verbergen:

1. Azure VM
2. Azure SQL (Preview)
3. Azure App Service (Preview)
4. Azure VMware Solution (AVS)

Bei Auswahl des ersten Links “Azure VM” gelangt man auf eine Seite, auf der man Optionen für die Bewertung angeben kann. Etwas versteckt befindet sich der Link auf die gewünschten Einstellungen hinter dem “Edit”. Dort kann man die Kriterien spezifizieren, die die Bewertung beeinflussen.

Im folgenden Fenster werden die verschiedenen und teilweise geänderten Parameter dargestellt, die der Bewertung der Migration als Basis dienen. Insbesondere wurde hier die Auswahl der Ziel-VM-Typen - Default 0 - auf “Select all” gesetzt, was in 17 verschiedene VM Kandidaten resultiert. Nachdem alle Optionen gesetzt wurden, wird die Bewertung mit dem Button “Save” geschlossen und das Assessment mit dem Button “Next: Select servers to assess>” fortgesetzt.

Nach der Spezifikation der Faktoren für das Assessment muss ein Name hierfür vergeben und ggf. eine Ressourcegruppe angelegt oder ausgewählt werden. Über den Filter wurden als Migrationskandidaten nur diejenigen Server ausgewählt, deren Name den Text “Server2Azure” enthält.

Nach der spärlichen Überblickseite über die Einstellungen kann die Bewertung gestartet werden.

Die abgeschlossene Bewertung umfasst vier Bereiche, von denen einer per Default nicht angezeigt wird. Dieser Bereich besteht lediglich aus einem Überblick über die wichtigsten zuvor eingestellten Bewertungskriterien.

1. Essentials: Bewertungskriterien, nur sichtbar durch Verwendung der Essentials Schaltfläche
2. Azure Readiness: Eine Einschätzung zu den Erfolgsaussichten der Migration
3. Monthly Cost Estimate: Graphisch dargestellte Schätzung der monatlichen Kosten, unterteilt in Compute und Storage. Durch Selektion eines der beiden Graphik-Bereiche wird in der Mitte der Graphik der prozentuale Anteil angezeigt.
4. Storage - Monthly Cost Estimate: Graphisch dargestellte monatliche Storage-Kosten je nach ausgewählten Plattentypen (In dieser Demo wurden nur Standard HDD managed disks für die Ziele ausgewählt.)

Klickt man in die Mitte der Graphiken oder auf einen der beiden Links auf der linken Seite im Bereich “Assessment details”, so öffnet sich ein Detail-Fenster zu dem jeweiligen Thema, nämlich Details zur “Azure readiness” oder zu den Kostendetails (vgl. folgende Abbildungen).

Bewertungsergebnisse: Detail “Azure readiness”

Migration

Nachdem nun die Vorarbeiten abgeschlossen und die Bewertung durchgeführt wurden, kann mit der eigentlichen Migration begonnen werden. Hierzu navigieren wir zu dem bekannten Migrations-Wizard. Jetzt wird allerdings der untere Bereich “Migration tools” verwendet. Die Discovery-Lupe brauchen wir an dieser Stelle nicht. Hierüber werden lediglich die Migrationskandidaten festgelegt, sofern man nicht zuvor über den oberen Teil des Fensters ein Assessment durchgeführt hat.

Zum Start der Replikation wird also der Replicate Link verwendet. Dieser führt uns auf eine Seite, auf der Quell- und Zielumgebung spezifiziert werden. Im hier beschriebenen Fall bilden zwei virtuelle Maschinen die Quelle und diese sollen nach Azure migriert werden.

Migrationsquell- und -zielumgebung

Mit dem “Continue” Button gelangt man in einen weiteren siebenseitigen Dialog zur Spezifikation weiterer Details, in dem man mit dem “Previous” bzw. “Next” Button navigieren kann.

Auf der zweiten Seite werden

• Assessment-Gruppe
• Assessment
• der / die zu migrierende(n) Server erfragt. Hierbei kann, wie dargestellt, ein Filter (“Server2Azure”) auf die Servernamen angewandt werden.

Auf Seite 3 geht es um die Parameter für die Zielserver. Im oberen Bereich werden wesentliche Parameter für die Region, die Abrechnung, die Zuordnung zu einer Resourcegruppe und dem zu verwendenden virtuellen Netz abgefragt. Der untere Bereich dient zur Angabe der Lizenzsituation und zur Auswahl von Informationen zu dem zu verwendenden virtuellen Netz für die Testmigration. Hier empfiehlt Microsoft die Verwendung eines separaten Netzwerks für die Testmigration.

Auf Seite 4 können für die Migrationskandidaten passende Zielserver ausgewählt werden. Die voreingestellte Größe resultiert hier aus dem zuvor durchgeführten Assessment, kann aber hier noch individuell angepasst werden.

Auf Seite 5 folgen die Platten. Die Quellmaschinen haben jeweils drei Platten, sodass auch hier drei Platten pro Server erfragt werden. Auch hier wurde eine Minimalauswahl getroffen, weil hier mit einem Test-Konto gearbeitet wurde.

Auf Seite 6 können, wie auch für andere Azure Objekte, Tags vergeben werden. Hierauf wurde in diesem Fall verzichtet.

Seite 7 stellt schließlich einen Überblick über die Einstellungen bereit und bietet die Möglichkeit über den “Replicate” Button die Replikation zu starten. Zu beachten ist, dass man nach Betätigung des Replicate-Buttons wieder zurück auf die erste Wizard-Seite mit den “Basics” gelangt, d.h. hier wurde vom Microsoft Team eine Endlosschleife programmiert.

In dem Überblick sieht man den Replikationsprozess im Status “Healthy” für beide VMs und am unteren Bildrand wird dargestellt, dass die Replikation “in progress” ist. Im mittleren Rahmen wird eine Testmigration und im rechten die tatsächliche Migration angeboten. Entsprechend dem rot umrahmten Hinweisfeld wurde noch keine Testmigration durchgeführt und diese erfolgt nun über den unteren Button.

Durch Start der Testmigration gelangt man in das folgende Fenster, in dem der Status der Replikation, der Testmigration und der Migration dargestellt sind. Die Menüführung bedarf hier einer detaillierteren Beschreibung: Hinter dem Button “Test migration” verbirgt sich ein Fenster, das auf den ersten Blick keinen Test anbietet, sondern lediglich ein “Migrate” und genau das macht dieser Link.

In dem Testfenster sind die Kandidaten der Migration mit ihren jeweiligen Statuswerten aufgelistet. Hinter jedem dieser Kandidaten befindet sich auf der rechten Seite ein Kontextmenü (rechte Maustaste auf den drei Punkten), über das man je nach aktueller Situation folgende Möglichkeiten angeboten bekommt:

• Pause replication
• Resume replication
• Test migration
• Clean up test migration
• Repair replication
• Complete replication
• Stop replication

Hier befindet sich also die Möglichkeit, die Migration für jede einzelne Maschine zu testen. Die folgende Abbildung zeigt das Kontextmenü und den Migrationsstatus der beiden VMs, nachdem für eine der beiden VMs (AppServer2Azure) eine Testmigration durchgeführt wurde.

Geht man an dieser Stelle zurück in das übergeordnete Fenster, so erhält man hier in dem mittleren Bereich einen Überblick über die Testmigrationen.

Nachdem auch für die zweite VM eine Testmigration erfolgt ist, werden die Ressourcen der Testmigrationen gelöscht und die Migration durchgeführt. Dies kann sowohl über den “Migrate” Button im rechten Kästchen der Überblickseite als auch über den Migrate-Link auf der Statusseite der Testmigration initiiert werden. Auf der Startseite der Migration kann ausgewählt werden, ob die Quell-VMs vor der Migration heruntergefahren werden sollen oder nicht. Außerdem besteht die Möglichkeit, die zu migrierenden VMs auszuwählen, wie in der folgenden Abbildung dargestellt. Hier wurde die Option gewählt, die Quell-VMs nicht herunterzufahren. In einem realen Migrationsszenario könnte dies natürlich zur Verwirrung führen, weil möglicherweise nicht geklärt werden kann, zu welchem Zeitpunkt eventuelle Benutzer von der Quell- auf die Zielumgebung zugreifen.

Migrationsüberblick nach erfolgter Migration

Wurden die zu Beginn erstellten Tabellen [migration].[local_time_table] und [migration].[local_time_table] in der Zielumgebung, also auf dem neuen nach Azure migrierten Server, bezüglich der dort eingetragenen Zeitstempel mit dem folgenden Ergebnis überprüft:

• Die Zeitstempel der Tabelle local_timetable auf dem Zielserver stammten bis um 15:59:40 aus der alten Umgebung. Die Zeitstempel in der Zielumgebung begannen um 16:14:00. Es existierte also eine Lücke zwischen der letzten Replikation und dem Start des Servers “MSServer2Azure” in Azure von ungefähr 15 Minuten.
• Die Zeitstempel der Tabelle remote_timetable auf dem Zielserver endeten ebenfalls um 15:49:40. Hier gab es aber erwartungsgemäß keine weiteren Einträge von dem migrierten Server. Hier konnte der simulierte Server “AppServer2Azure” wegen der geänderten Netzwerkadresse in der Zielumgebung nicht mehr auf “MSServer2Azure” zugreifen.

Fazit

Die “Online” Migration von VMs nach Azure erfordert eine kurze Downtime. Lokale Zugriffe auf die Datenbank erfolgen mit einer Verzögerung, die mit der Bereitstellung der virtuellen Maschine in der Azure Umgebung zusammenhängt: Die Platten werden repliziert, anschließend werden die Azure VMs eingerichtet und die replizierten Platten den neuen VMs verfügbar gemacht.

Remote Zugriffe erfordern einen manuellen Eingriff, um die Verbindungsdaten zu der Zieldatenbank umzukonfigurieren. Anschließend sind auch sie wieder uneingeschränkt verfügbar.

Sie benötigen professionelle Unterstützung oder haben offene Fragen? Unsere Expert:innen helfen Ihnen gerne weiter! Kontaktieren Sie uns gerne einfach über das Kontaktformular