Planen einer Datenmigration

Abgeschlossen

Ein Projekt zur Modernisierung einer Datenplattform weist fünf Phasen auf, die in der Regel nacheinander abgeschlossen werden.

In unserem Szenario mit dem globalen Einzelhandelsunternehmen hat der Vorstand das Modernisierungsprojekt genehmigt, und Sie beginnen damit, Personal und andere Ressourcen zu organisieren. Wenn Sie Aufgaben optimal einrichten und zuweisen möchten, müssen Sie die Projektphasen genau verstehen.

In dieser Lerneinheit werden Sie jede der fünf Phasen genauer erkunden.

Initiieren und Entdecken

Projekte zur Modernisierung der Datenplattform werden in der Regel initiiert, um geschäftliche oder rechtliche Anforderungen zu erfüllen. Daher ist es wichtig, diese Anforderungen zu berücksichtigen und sich die Unterstützung der Geschäftsleitung zu sichern. Der erste Schritt besteht darin, eine Ermittlungsübung durchzuführen, die folgende Punkte beinhaltet:

• Bewerten der aktuellen Umgebung

  Viele IT-Infrastrukturen werden typischerweise über viele Jahre, vielleicht sogar Jahrzehnte, weiterentwickelt. In dieser Zeit können sich das Geschäft und die Mitarbeiter so stark verändern, dass es möglicherweise keine Experten mehr für die Systeme gibt, die in einer Organisation verfügbar sind. In seltenen Fällen kann es sogar vorkommen, dass Organisationen vergessen, dass einige Systeme noch vorhanden sind.

• Überprüfen der Abhängigkeiten zwischen vorhandenen Anwendungen und Datenbanken

  Sie sollten sich Zeit nehmen, um zu verstehen, wie Ihre Anwendungen mit den in Ihrem Netzwerk vorhandenen Datenbanken interagieren. Darüber hinaus sollten Sie auch etwaige datenbankübergreifende Abhängigkeiten verstehen, damit Sie Datenbanken in logischen Gruppierungen zusammenfassen können. Durch die Durchführung dieser Übung werden Sie die logischen Gruppierungen der Datenbanken als Grundlage für die Migration zu Azure als einzelne Einheit verwenden.

• Auflisten der Workloadtypen Ihrer Systeme

  Das Auflisten von Workloadtypen für identifizierte Datenbankserver liefert Erkenntnisse zu deren Nutzung. Workloads können als analytisch (OLAP) oder als transaktional (OLTP) kategorisiert werden. Hierfür ist ausschlaggebend, ob die Workloads lese- oder schreibintensiv sind. Dies ist hilfreich bei der Entscheidung, zu welcher Datenplattformtechnologie migriert werden soll. Zur weiteren Kategorisierung können ggf. auch Batch- oder Entscheidungsunterstützungsworkloads verwendet werden.

Assessment

In der Bewertungsphase werden die identifizierten Workloads auf der Grundlage der Informationen aus der Ermittlungsphase umfassend ausgewertet, um Folgendes zu ermitteln:

• Mögliche Migrationsblockierungen
• Alle Breaking Changes, die nach der Migration erforderliche Korrekturen erfordern
• Azure-Features, die von den Workloads verwendet werden können

Zur Ermittlung dieser Informationen müssen Sie eine Bewertung der aktuellen Workload und eine Bewertung der Workloadkriterien durchführen.

• Bewertung der aktuellen Workload

  Die identifizierten Datenbankserver und Anwendungen werden kategorisiert und bestätigt, um Folgendes zu ermitteln: Datenvolumen und erwartete Wachstumsraten, durchschnittliche Ressourcennutzung und ihre Kritikalität für das Unternehmen. In dieser Phase können ggf. auch lokale Datenbanken miteinander kombiniert oder außer Betrieb genommen werden, um die Anzahl zu migrierender Datenbanken zu verringern und die Gesamtkosten zu senken.

• Bewertung der Workloadkriterien

  Bei der Bewertung der Workloadkriterien verwenden Sie die Erkenntnisse aus der Bewertung der aktuellen Workload und definieren die Kriterien nach der Migration für die Ausführung der identifizierten Workloads.

  Angenommen, Sie haben einen Transaktionsdatenbankserver identifiziert, der zu Spitzenzeiten stark ausgelastet ist, ansonsten aber nur wenig genutzt wird. Im Rahmen der Bewertung der Workloadkriterien definieren Sie ein Kriterium für die Zeit nach der Migration – beispielsweise die Migration zu einer Azure SQL-Datenbank-Instanz mit automatischer Skalierung, um Lastspitzen zu bewältigen.

Planung

Die Planungsphase eines Projekts zur Modernisierung der Datenplattform umfasst die Bestimmung der Zielplattform, des Migrationsansatzes und der vorbeugenden Maßnahmen für geplante oder ungeplante Unterbrechungen.

In der Planungsphase des Projekts zur Modernisierung der Datenplattform gibt es sieben Begriffe, die beschreiben, wie Sie den Übergang von Anwendungen und Daten aus einer bestehenden lokalen Umgebung in eine neue cloudbasierte Umgebung (entweder öffentlich oder privat) handhaben können.

#	Phase	Aktion	BESCHREIBUNG
1.	Remain (Verharren)	Keine Maßnahmen	Kontinuierliche Modernisierung unter Berücksichtigung langfristiger Optionen für verbleibende lokale Dienste
2.	Zuweisen eines neuen Hosts	Migrieren zu IaaS	Bei diesem Ansatz entfällt die Verwaltung eines Rechenzentrums, und er bietet eine höhere Rendite (Return On Investment, ROI) dank geringerer Gesamtkosten (Total Cost of Ownership, TCO).
3.	Refactor	Migration zu IaaS oder PaaS mit minimalen Anwendungsänderungen	Bei diesem Ansatz entfällt die Verwaltung eines Rechenzentrums, und er bietet eine höhere Rendite (Return On Investment, ROI) dank geringerer Gesamtkosten (Total Cost of Ownership, TCO). Außerdem verringert sich ggf. der Verwaltungsaufwand durch die Konsolidierung von Datenbanken.
4.	Überarbeiten	Umschreiben zentraler Aspekte der Anwendung, um Cloudtechnologien zu nutzen	Dies ermöglicht die Verwendung moderner Komponenten, verringert die Codebereitstellung und erleichtert die DevOps-Bereitstellung von Infrastruktur und Diensten.
5.	Neuerstellen	Neuerstellen der Anwendung, um PaaS oder serverlose Technologien zu nutzen	Die Neuerstellung von Datenplattformen und Anwendungen mit neueren Technologien ermöglicht die Verwendung der integrierten Hochverfügbarkeit von Azure, erhöht die Portabilität und Skalierbarkeit von Anwendungen und minimiert potenzielle Qualifikationslücken zwischen der verwendeten Technologie und dem Personal, das Support für die Anwendung bereitstellt bzw. die Anwendung entwickelt.
6.	Replace	Ersetzen der Anwendung durch eine neuere Anwendung oder SaaS-Lösung	Ein Austausch ist möglicherweise sinnvoll, wenn eine Anwendung von physischen Geräten abhängig ist, die an den Server angeschlossen sind, oder wenn sie tief in die lokale Infrastruktur integriert ist.
7.	Außerkraftsetzen	Außerbetriebnahme von nicht mehr benötigten Anwendungen	Der Ansatz für die Außerbetriebnahme sollte in Betracht gezogen werden, wenn Legacyanwendungen und Datenbanken nicht mehr verwendet werden, da es keine geschäftlichen oder gesetzlichen Anforderungen gibt, sie zu behalten.

Der folgende Graph zeigt den Aufwand, den jeder Begriff erfordert, im Vergleich zum Wert, den das Unternehmen durch die Migration gewinnt.

• Optionen für das Plattformziel

  Bei der Auswahl der Zielplattform gibt es zwei allgemeine Optionen.

  • Infrastructure-as-a-Service (IaaS): Bei diesem Ansatz werden Sie Ihre Daten auf einen virtuellen Computer migrieren, auf dem SQL Server installiert ist.

  • Platform-as-a-Service (PaaS): Bei diesem Ansatz migrieren Sie Ihre Daten auf einen Datenplattformdienst, der zu Ihrer Workload passt. Bei transaktionalen Workloads wird dafür Azure SQL-Datenbank oder Azure SQL Managed Instance verwendet. Bei OLAP-Workloads (Online Analytical Processing) wäre hierzu Azure Synapse Analytics erforderlich.

• Auswählen der Zielplattform nach Features

  • Azure SQL-Datenbank: Verwenden Sie diese Option, wenn die Anwendungsoberfläche datenbankbezogen ist. SQL-Datenbank bietet eine Lösung mit geringem Wartungsaufwand, die eine hervorragende Option für bestimmte Workloads sein kann.

  • Pools für elastische Datenbanken in Azure SQL-Datenbank: Mit Pools für elastische Datenbanken können Sie Speicher- und Computeressourcen einer Gruppe von Datenbanken zuordnen, anstatt Ressourcen für jede Datenbank einzeln verwalten zu müssen. Darüber hinaus sind Pools für elastische Datenbanken einfacher zu skalieren als Einzeldatenbanken, weil die Skalierung einzelner Datenbanken aufgrund von Änderungen am Pool für elastische Datenbanken nicht mehr erforderlich ist.

  • Azure SQL-Datenbank (serverlos): Diese Option ermöglicht die Senkung der Kosten in Entwicklungs- und Testumgebungen. Mit dem Feature „Verzögerung für automatisches Anhalten“ können Sie den Inaktivitätszeitraum festlegen, nach dem die Datenbank automatisch angehalten werden soll. Sie können zwischen einer Stunde und sieben Tagen wählen oder das Feature deaktivieren. Wenn erneut auf die Datenbank zugegriffen wird, wird sie fortgesetzt, und während der Pause fallen nur Speichergebühren an.

  • Azure SQL Managed Instance: Wäre geeignet, wenn die Anwendungsoberfläche instanzenspezifisch ist und Features erfordert, die in Azure SQL-Datenbank nicht verfügbar sind – beispielsweise:

    • SQL-Agent
    • MSDTC
    • DQS
    • MDS
    • Datenbank-E-Mail
    • PolyBase
    • Unterstützung von Verbindungsservern
    • Unterstützt neue Azure Cloud Services wie die Bedrohungserkennung

  • SQL Server auf virtuellem Azure-Computer: Verwenden Sie diese Option, wenn die Anwendungsoberfläche instanzenspezifisch ist und Features erfordert, die in Azure SQL Managed Instance nicht verfügbar sind – beispielsweise SQL Server Reporting Services (SSRS), SQL Server Analysis Services (SSAS) und SQL Server Integration Services (SSIS).

  • Azure Synapse Analytics: Verwenden Sie diese Option, wenn Sie über Anwendungen verfügen, die komplexe Abfragen für große Datenmengen ausführen, für die Massively Parallel Processing (MPP) genutzt werden kann, um die Abfrageverarbeitung zu beschleunigen.

Eine Liste der Features, die in den einzelnen PaaS-Angeboten für SQL unterstützt werden, finden Sie unter Featurevergleich: Azure SQL-Datenbank und Azure SQL Managed Instance.

• Auswählen der Zielplattform nach Kosten

  • Azure SQL-Datenbank: Der Platform-as-a-Service-Charakter von Azure SQL-Datenbank reduziert die Administrations- und Verwaltungskosten im Vergleich zur traditionelleren Topologie „SQL Server in Azure IaaS“ erheblich, da die meisten der erforderlichen Aufgaben von Microsoft im Hintergrund für Sie erledigt werden. Bei Verwendung im großen Stil können Sie so erheblich Zeit und Aufwand sparen.

  • Pools für elastische Datenbanken in Azure SQL-Datenbank: Pools für elastische Datenbanken in Azure SQL-Datenbank ermöglichen erhebliche Einsparungen für mehrere Datenbanken mit unvorhersehbaren Nutzungsanforderungen. Computeressourcen werden gemeinsam genutzt, um eine Überbereitstellung zu vermeiden und die Kosten für Serverwartung und -verwaltung zu reduzieren.

  • Azure SQL Managed Instance: SQL Managed Instance wird für Kund*innen angeboten, die einen vollständig verwalteten Dienst benötigen, bei dem sie für ihre lokale Umgebung mit minimalen Konfigurationsänderungen ganz einfach eine Lift & Shift-Migration durchführen können. Die Umgebung bietet mindestens 8 Kerne und bis zu 8 TB Speicherplatz und befindet sich in einem isolierten virtuellen Netzwerk. Dieses Angebot eignet sich hervorragend für Kund*innen, die schnell zur Cloud migrieren und den Mehraufwand der Verwaltung von virtuellen Computern vermeiden möchten.

  • SQL Server auf virtuellen Azure-Computern: Im Vergleich zu PaaS-Angeboten fallen bei SQL Server auf virtuellen Azure-Computern höhere Compute-, Speicher- und Verwaltungskosten an. Dafür haben Sie allerdings mehr Kontrolle über SQL Server und über die Infrastruktur.

  • Azure Synapse Analytics: Azure Synapse Analytics kann Ihre Kosten reduzieren, indem es die MPP-Architektur nutzt, um komplexe Abfragen in Minuten statt in Stunden zu verarbeiten.

• Offline- oder Onlinemigration

  In der Planungsphase sollten Sie überlegen, ob Sie eine Offline- oder eine Onlinemigration durchführen. Bei Migrationen des Typs Offline beginnt die Ausfallzeit der Anwendung mit dem Start der Migration. Führen Sie eine Migration des Typs Online durch, um die Ausfallzeit auf die Zeit zu begrenzen, die bei Abschluss der Migration für die Umstellung auf die neue Umgebung erforderlich ist. Es empfiehlt sich, eine Offlinemigration zu testen, um zu ermitteln, ob die Ausfallzeit akzeptabel ist. Wenn dies nicht der Fall ist, sollten Sie eine Onlinemigration durchführen. Außerdem sind je nach gewählter Azure-Plattform möglicherweise keine Online- oder Offlineoptionen verfügbar.

Transformieren und Optimieren

Ihre Bewertung und Planung hätten Aspekte Ihrer Anwendungen und Ihrer Datenbank identifiziert, die Aufgaben nach der Migration erfordern würden, die entweder ein Feature transformieren oder optimieren, um eine erfolgreiche Migration zu gewährleisten. Bei einer Transformation handelt es sich in der Regel um Aufgaben, bei denen Sie einen Aspekt einer Datenbank korrigieren oder ändern müssen.

Bei der Optimierung wird typischerweise eine Änderung an der migrierten Datenbank vorgenommen, um die Vorteile eines Features zu nutzen, oder die Nutzung innerhalb von Azure optimiert.

Eine Transformation kann beispielsweise das Ändern einer gespeicherten Prozedur oder SQL-Abfrage mit Syntax umfassen, die in der Zieldatenbank nicht unterstützt wird. In diesem Fall müsste die Syntax angepasst werden, um die Kompatibilität mit der neuen Datenbankplattform zu gewährleisten und sicherzustellen, dass die gespeicherte Prozedur oder die Abfrage reibungslos und ohne Probleme in der Zielumgebung ausgeführt wird.

• Transformieren

  Um sicherzustellen, dass nach der Migration alles funktioniert, muss möglicherweise mindestens eine der folgenden Änderungen vorgenommen werden:

  • Installieren Sie Versionsupgrades vor der Migration.

  • Beheben Sie sämtliche Fehler, die von den Migrationsbewertungstools identifiziert werden.

  • Implementieren Sie Datenbankschemaänderungen.

  • Migrieren Sie vorhandene integrierte Datenbankdienste in Azure.

  • Behandeln Sie SSIS-Workloads in der Cloud.

• Optimieren

  Möglicherweise gibt es eine oder mehrere der folgenden Optimierungsrichtlinien, die Sie während der Migration befolgen sollten, um sicherzustellen, dass Ihre Organisation ihre Investition in Azure optimal nutzt.

  • Bewerten, welche neuen Features auf der Zielplattform verfügbar sein könnten

  • Neustrukturieren von Workloads in kostengünstigere oder leistungsfähigere Sätze

  • Auswählen der höchsten Dienstebene und Leistungsstufe während der Migration und Herunterskalieren nach Abschluss der Migration

  • Sicherstellen der richtigen Größe von Workloads

  • Minimieren der Entfernung zwischen Ihrer BACPAC-Datei und dem Zielrechenzentrum

  • Deaktivieren Sie die automatische Statistik während der Migration.

  • Partitionierte Tabellen und Indizes

  • Verwerfen Sie indizierte Sichten, und erstellen Sie sie nach Abschluss des Vorgangs neu.

Migrieren, Validieren und Korrigieren

Diese Phase umfasst die Migration selbst und vor allem die Validierungs- und Korrekturschritte, die zur Bestätigung einer erfolgreichen Migration erforderlich sind. Die vorangegangenen Planungs-, Bewertungs- und Transformationsphasen haben sichergestellt, dass alles für die Migration bereit ist und nach dem Wechsel zu Azure ordnungsgemäß funktioniert. Nun bleiben nur noch die Vorbereitung der erforderlichen Migrationstools, der Abschluss der Migration und die Durchführung von Funktions- und Leistungsvalidierungen nach der Migration, um die Datenkonsistenz mit der Quelldatenbank sicherzustellen.

Überlegungen zur Migration, Validierung und Korrektur

Es gibt eine Vielzahl von Tools, mit denen die Migration auf die gewählte Zielplattform durchgeführt werden kann. Diese Tools werden in anderen Modulen behandelt. Beachten Sie beim Abschluss der Migration Folgendes:

• Verstehen Sie Ihre Workloadanforderungen als Ausgangspunkt.
• Wählen Sie zunächst nicht kritische Workloads oder Datenbanken mit niedriger Priorität für die Migration aus.
• Ausführen einer Testmigration
• Testen der Datenbank auf Probleme
• Testen Sie den Plan, um das Risiko von Downtimes und Kompatibilitätsproblemen zu minimieren.
• Bewerten Sie die Migrationstools auf Basis von Unterbrechungen, um das Risiko von Downtimes für Datenbanken zu verringern.
• Durchlaufen Sie Ihren Migrationsprozess kontinuierlich.
• Berücksichtigen Sie die Wartungsfenster, die für die zu migrierende Anwendung und Datenbank verfügbar sind.
• Nehmen Sie alte Datenbanken und Anwendungen offline.
• Testen Sie Anwendungen von Drittanbietern.
• Erstellen Sie neue Pläne für die Notfallwiederherstellung und Wartung.