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:
-- Timing des DB-Servers:
CREATE TABLE [migration].[local_time_table](
[ltt_id] [int] IDENTITY(1,1) NOT NULL,
[ltt_datetime] [datetime] NOT NULL,
CONSTRAINT [pk_ltt_Id] PRIMARY KEY CLUSTERED
(
[ltt_id] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
) ON [PRIMARY]
GO
-- Timing des App-Servers:
CREATE TABLE [migration].[remote_time_table](
[rtt_id] [int] IDENTITY(1,1) NOT NULL,
[rtt_datetime] [datetime] NOT NULL,
CONSTRAINT [pk_rtt_Id] PRIMARY KEY CLUSTERED
(
[rtt_id] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
) ON [PRIMARY]
GODas Befüllen der beiden Tabellen erfolgt mit den folgenden beiden simplen Statements:
-- lokal auf dem DB-Server:
insert into [migration].[local_time_table](ltt_datetime) values ( getdate());
-- Vom App-Server in die Tabelle des DB-Servers:
insert into [migration].[remote_time_table](rtt_datetime) values ( getdate());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:
- Discover, assess and migrate
- Assess and migrate databases
- 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:
- Subscription (bereits vorbelegt, aber änderbar)
- 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.
- Name des Projektes, Informationen zu Namensanforderungen und -einschränkungen werden- wie in Azure üblich - durch Positionierung der Maus über dem Informations-Icon angezeigt.
- 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:
- Auswahl des OVF / OVA Templates
- Vergabe eines Namens für die Appliance (Default: MicrosoftAzureMigration) und Auswahl eines Zielordners
- Auswahl einer Compute Ressource auf der die Appliance laufen soll
- Überblickseite
- Storage-Zuordnung
- Netzwerk-Zuordnung
- 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:
- Login und Passwort für den / die vCenter Server spezifizieren aus dem / denen VMs migriert werden sollen
- IP-Adresse bzw. FQDN und Port für den / die vCenter Server spezifizieren
- 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:
- Azure VM
- Azure SQL (Preview)
- Azure App Service (Preview)
- 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.
- Essentials: Bewertungskriterien, nur sichtbar durch Verwendung der Essentials Schaltfläche
- Azure Readiness: Eine Einschätzung zu den Erfolgsaussichten der Migration
- 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
- 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”
