Ihr Weg in die Cloud

Als Teil der Transformation von Applikation und Daten in die Cloud ist meist die Migration von Daten und Datenbanken notwendig.

"Der Weg in die Cloud und nach Azure muss je nach Architektur von Infrastruktur und Software-Plattform gefunden und gestaltet werden."

Für diese Aufgabe haben wir ein paar Migrationsszenarien erarbeitet, die im Folgenden dargestellt werden. Diese Szenarien sind natürlich nicht "alternativlos", sondern eher als Beispiele für Migrationen anzusehen. Im Detail muss eine Migration je nach Plattform und Umfang geplant werden.

Put your data to the cloud

Migrieren einer SQL Server-Datenbank in eine Azure SQL-Datenbank

 Das Thema Cloud ist nicht nur – immer noch - ein Hype, sondern bietet auch zunehmend in immer mehr Bereichen viele Vorteile. Microsoft baut daher massiv sein Cloud-Angebot Azure auch im Datenbankbereich aus. Möchte man die „moderne“ Technik für seine bestehenden Datenbanken nutzen, muss man sie irgendwie in die Cloud bekommen. Dieser Artikel beschäftigt sich daher mit einigen Migrationsszenarien.

Wie bei jedem Hype entsteht schnell ein Begriffs-WirrWarr, daher sollte zunächst die Verwendung der Begrifflichkeiten geklärt werden. Für die klassische on-premise Datenbank wird der Begriff „SQL Server Datenbank“ verwendet. Da Azure verschiedene Möglichkeiten bietet, eine Datenbank in der Cloud zu halten, ist es wichtig die verschiedenen angebotenen Techniken klar auseinander zu halten. Somit soll „SQL Server on Azure VM“ für den Betrieb einer SQL-Server Datenbank in einer virtuellen Maschine, die in Azure läuft stehen (IaaS). Und „Azure SQL-Datenbank“ für den Betrieb einer SQL-Datenbank (eben ohne „Server“) in Azure (PaaS oder DBaaS). Es wird schnell ersichtlich, dass in diesem Fall eben kein vollständiger „SQL-Server“ und keine VM mit Betriebssystem zur Verfügung stehen.

Dieser Artikel beschreibt nun Vorgehensweisen für die Migration einer on-premise Benutzerdatenbank einer „SQL-Server Datenbank“ in eine Azure SQL-Datenbank.

Eine Migration einer „SQL-Server Datenbank“ in einen „SQL Server on Azure VM“, ist im Prinzip vergleichbar eines Updates von einer SQL-Server Datenbank und kann auch mit den gleichen Methoden wie zum Beispiel Backup/Restore, ETL bzw. SSIS, Copy/Clone, Replikation … und bis zur Verwendung von Always Availability Groups durchgeführt werden.

Steps

Die grundlegenden Steps einer Migration in eine Azure SQL-Datenbank unterscheiden sich im Vergleich zu anderen Migrationen nicht, und sind im Wesentlichen:

• Data Quality + Data Cleansing: Ja, dieser Step beschreibt sicherlich die „heile Welt“ und nicht die wirkliche und findet daher meist nicht statt. Im Sinne der Migration kann es aber nur Vorteile haben, nicht auch alle „Datenleichen“, technischen Schulden und Altlasten durch die Migration zu schleppen.
• Ermitteln der Kompatibilität bzw. der Kompatibilitätsprobleme
• Lösen der Kompatibilitätsprobleme;
  Dies ist der spannendste, kreativste und oft auch aufwendigste Step. Er entscheidet daher auch über die weiteren Szenarien der Migration.
  Außerdem führt dieser Step manchmal doch noch zu einer – zumindest teilweisen – Durchführung von Step 1 (Data Quality + Data Cleansing).
• Ermitteln und Übertragen der Metadaten wie Rollen, User, Rechte usw.
• „eigentliche“ Migration, bzw. das Übertragen von Schema und Daten
• Datenbank-Eigenschaften der Azure SQL-Datenbank einstellen

Tools

Da die Migration nach Azure zurzeit noch Microsoft-lastig ist, und Tools von anderen Anbietern erst langsam eine Anbindung an Azure bieten, sollen die Hauswerkzeuge von Microsoft hier genügen:

• SQL Server Management Studio (SSMS)
• SQL Server Data Tools für Visual Studio (SSDT)
• SQL Server Integration Service (SSIS)
• Data Migration Assistant (DMA)

Da von Seiten Microsofts die Entwicklung rund um Azure kontinuierlich ist, sollten immer die neuesten und aktuellsten Versionen der Tools verwendet werden.

Szenarien für zwei Beispiele

Prinzipiell kommen zur Migration von kompletten SQL-Server Datenbanken nach Azure das Migrieren der Datenbank in einen SQL-Server, der in einer virtuellen Maschine auf Azure läuft und das Migrieren in eine Azure SQL-Datenbank in Betracht.

Da die Migration im ersten Fall wie eine Migration von einem SQL-Server zu einem anderen SQL-Server zu sehen ist, kann dies auch mit den gleichen Techniken durchgeführt werden (Stichworte siehe oben). Interessanter wird’s bei der Migration in eine Azure SQL-Datenbank, also die Nutzung als Dienst bzw. Service in der Cloud (PaaS bzw. DBaaS).

Zur Ermittlung der Kompatibilität wird zunächst mit dem Data Migration Assistant (DMA) ein Assessment durchgeführt. Ergebnis des Assessments ist eine Liste mit Erläuterungen und Lösungsmöglichkeiten zur „SQL Server feature parity“ (Feature Übereinstimmung) und der „Compatibility issues“ (Kompatibilitätsproblemen). Dieses Ergebnis und die Komplexität der Lösungsmöglichkeiten entscheiden dann über das konkrete weitere Vorgehen.

Im Detail wird versucht eine transaktionsgesicherte Kopie der Quelldatenbank solange zu „tunen“, bis die Migrationsblocker beseitigt sind. Je nach Umfang und Aufwand sind zwei grundlegende Vorgehensweisen denkbar:

• Szenario 1: Bearbeiten der Kopie der Quelldatenbank mit skriptbaren T-SQL Befehlen und anschließendem Export von Schema und Daten aus der bearbeiteten Kopie der Datenbank und Import in die Azure SQL Datenbank
• Szenario 2: Oder bei umfangreicheren Änderungen: Laden der DB mit Hilfe der SQL Server Data Tools (SSDT) in ein Visual Studio Datenbank-Projekt und Bearbeitung der Issues innerhalb des Projektes

Natürlich sind eine Reihe andere Vorgehensweisen ebenso denkbar, wie z.B. eine Kombination der beiden genannten Vorgehensweisen oder die Nutzung der Integration Services (SSIS) oder anderer ETL-Prozesse. Auch hier könnten die einzelnen Skripte und entwickelten Routinen des Visual Studio Datenbank-Projektes wieder verwendet werden.

In einem weiteren Artikel werden wir noch auf Migrations-Szenarien unter Verwendung der Azure Data Factory (ADF) eingehen. Dies kann als ein Integration-Service für die Cloud angesehen werden, und ist daher gerade für eine hybride Datenwelt sowie den Aufbau von Data Warehouse und BI/BA Anwendungen interessant.

Modell für das 1. Szenario

Wenns noch überschaubar ist ...

Sind die Kompatibilitätsprobleme „überschaubar“ und kann die zu erreichende Kompatibilität mit ebenso „überschaubaren“ T-SQL-Skripten erreicht werden, lässt sich wie folgt vorgehen:

1. Erstellen einer transaktionsgesicherten Kopie der zu migrierenden Quelldatenbank
2. Erstellen von T-SQL-Skripten zur Erlangung der notwendigen oder benötigten Kompatibilität
3. Erneutes Überprüfen der Kompatibilität und Funktionsübereinstimmung mit dem Data Migration Assistant
4. Schleife über die Punkte 2. und 3., bis die zu erreichende notwendige Kompatibilität und Funktionsübereinstimmung hergestellt ist
5. Export von Schema und Daten in eine BACPAC-Datei. Eine BACPAC-Datei ist eine ZIP-Datei mit der Erweiterung BACPAC. Sie enthält die Metadaten und Daten aus einer SQL Server-Datenbank. Eine BACPAC-Datei kann im Azure Blob Storage oder im lokalen Speicher an einem lokalen Standort gespeichert werden und dann in die Azure SQL-Datenbank importiert werden. Die BACPAC-Datei kann mit dem Management Studio (SSMS) oder dem Befehlszeilen-Werkzeug „SqlPackage.exe“ erstellt werden. Die Verwendung des Tools „SqlPackage“ bietet meist eine bessere Skalierbarkeit und Leistung beim Im-und Export der BACPAC-Dateien.
6. Import der BACPAC-Datei in die Azure SQL-Datenbank. Dies kann über das Azure Dashboard oder wieder über das Befehlszeilen-Werkzeug „SqlPackage.exe“ durchgeführt werden. Neben den o.g. Vorteilen bei Verwendung von „SqlPakage“ kommt beim Import ein weiterer Vorteil hinzu: die BACPAC-Datei kann direkt von einem lokalen Speicherplatz aus importiert werden. Bei Verwendung des Azure Dashboards muss – zumindest derzeit noch – die BACPAC-Datei über einen Azure Blob Storage bereitgestellt werden.
7. Einstellen des Kompatibilitätslevels der Azure SQL-Datenbank mit den T-SQL Befehlen „ALTER DATABASE Compatibility Level“ und/oder „ALTER DATABASE SCOPED CONFIGURATION“.
8. Ein- und Erstellen der Metadaten wie User, Rechte, Eigenschaften und dergleichen
9. Test, test, test ….

Test, test, test … steht natürlich für eine ausreichende Validierung der Migration und soll darauf hinweisen, möglichst bald das Testteam mit einzubeziehen.

Und das 2. Szenario

Wenns nicht mehr ganz so schnell überschaubar ist ...

Sind die Kompatibilitätsprobleme etwas komplexer und beinhalten auch Schemaänderungen und/oder Änderungen in den Funktionalitäten (einzelne Datenbankserver oder Betriebssystem Funktionen, die in Azure nicht zur Verfügung stehen, müssen anderweitig abgebildet werden) sollte aus Gründen der besseren Projektierung ein Visual Studio Datenbankprojekt aufgebaut werden. In diesem Fall lässt sich wie folgt vorgehen:

1. Erstellen eines neuen Datenbank-Projektes in Visual Studio mit den SQL-Server Data Tools. In Visual Studio lässt sich über den SQL Server Objekt Explorer ein neues Datenbank Projekt erstellen.
2. Im „Import Database“ Dialog die notwendigen Einstellungen treffen (in den „Import Settings“ sollte die Option „Import application-scoped objects only“ ausgewählt sein und der Import von „referenced logins“, „permissions“ und database settings“ nicht) und die Datenbankstrukturen und Objekte in das Projekt importieren.
3. Die Zielplattform in den Projekt-Einstellungen setzen (Microsoft Azure SQL Database V12, oder die gewünschte Plattform).
4. Ein Snapshot des Projektes erstellen. Dies hilft später in jeder Phase des Projektes mit der Möglichkeit die Änderungen zu analysieren (Schema Compare).
5. Über einen Build-Prozess des Projektes oder die Ergebnisse aus dem Data Migration Assistant die entsprechenden Änderungen an Schema, Struktur und Funktionen identifizieren.
6. Die entsprechenden Änderungen innerhalb des Projektes entwickeln.
7. Über einen Publish des Projektes eine neue angepasste Kopie der Quelldatenbank (Target Plattform für den Publish hierfür anpassen) erstellen. Es sollte mindestens einmal eine Datenbankkopie der Struktur erstellt werden, in der dann die eventuell notwendigen Änderungen in den Daten durchgeführt werden.
8. Über eine Schleife der Punkte 3. bis 7. die zu erreichende und notwendige Kompatibilität entwickeln und Funktionalität bereitstellen.
9. Die im Ziel erstellte und kompatible Datenbankkopie nach Azure übertragen. Dies kann wie oben beschrieben über den Export und Import mit BACPAC-Dateien erfolgen oder über das Management Studio (SSMS)
10. Auch hier folgt dann das Einstellen des Kompatibilitätslevels der Azure SQL-Datenbank mit den T-SQL Befehlen „ALTER DATABASE Compatibility Level“ und/oder „ALTER DATABASE SCOPED CONFIGURATION“.
11. Ebenso das Ein- und Erstellen der Metadaten wie User, Rechte, Eigenschaften und dergleichen
12. Und natürlich: Test, test, test …

Test, test, test … steht natürlich auch hier für eine ausreichende Validierung der Migration und soll darauf hinweisen, möglichst bald das Testteam mit einzubeziehen.