Überlegungen zur Migration

24 Minuten

Ein lokal ausgeführtes Geschäftssystem kann über eine Architektur verfügen, die mit anderen Diensten verbunden ist, die innerhalb derselben Umgebung ausgeführt werden. Sie müssen die Beziehungen zwischen einem System, das Sie migrieren möchten, und den anderen Anwendungen und Diensten, die Ihre Organisation zurzeit verwendet, verstehen.

In Ihrem Startup-Technologieunternehmen wird die Lieferantendatenbank verwendet, um sicherzustellen, dass Komponenten immer auf Lager sind und just-in-time für ihre Verwendung im Fertigungsprozess eintreffen. Stock Controller verwenden mobile Geräte, um diese Datenbank beim Eintreffen von Warensendungen zu aktualisieren, und Einkäufer verwenden eine Website, um Lagerbestände zu überwachen und die beste Zeit für die Bestellung zu ermitteln. Anhand eines Satzes unternehmenskritischer Berichte überwachen Manager den Prozess und verbessern die Effizienz. Sie möchten sicherstellen, dass keiner dieser Benutzer von der Migration zu Azure negativ beeinflusst wird.

Hier erfahren Sie, wie Sie eine reibungslose Datenbankmigration zur Cloud planen und ausführen.

Untersuchen von Abhängigkeiten

In einem komplexen System arbeitet eine Komponente selten ganz unabhängig. Stattdessen führt sie Aufrufe an andere Prozesse und Komponenten durch. Datenbanken können z. B. von Verzeichnisdiensten abhängig sein, die Benutzerkonten hosten. Wenn Sie eine Datenbank in die Cloud verschieben, können Sie dann auf diesen Verzeichnisdienst zugreifen? Wenn dies nicht der Fall ist, wie melden sich Benutzer an? Wenn Sie eine Abhängigkeit wie diese übersehen, kann dies zu einem Totalausfall der Datenbank führen.

Um Risiken zu mindern, überprüfen Sie, ob die Datenbank von Diensten wie den folgenden abhängig ist:

Verzeichnisdienste, z. B. Active Directory.
Andere Speicher von Sicherheitsprinzipalen.
Andere Datenbanken.
Web-APIs oder andere Netzwerkdienste.

Beachten Sie auch, dass andere Komponenten von Ihrer Datenbank abhängig sein könnten. Welche Konsequenzen treten auf, wenn Sie die Datenbank verschieben, ohne die abhängigen Komponenten neu zu konfigurieren? Wenn Sie z. B. eine Produktkatalogdatenbank verschieben und die öffentliche Website von ihr abhängig ist, wenn es darum geht, welche Produkte den Benutzern präsentiert werden, führt die Verschiebung dann zu einer Dienstunterbrechung?

Überprüfen Sie, ob Komponenten dieser Arten von Ihrer Datenbank abhängig sind:

Websites und Web-APIs.
Client-Apps, z. B. mobile Apps und Desktopsoftware.
Andere Datenbanken.
Berichte.
Data Warehouses.

Um diese Überprüfungen durchzuführen, sprechen Sie mit den Beteiligten, Administratoren und Entwicklern, die mit den einzelnen Datenbanken und Systemkomponenten zu tun haben. Wenn Sie nicht sicher sind, ob Sie das Verhalten der Systeme verstehen, konsultieren Sie die Dokumentation, und erwägen Sie, Tests wie z. B. Netzwerkerfassungen durchzuführen, um das Verhalten zu beobachten.

Vorbereiten auf einen Fallback

In jedem Migrationsprojekt sollten Sie immer auf einen Fehler vorbereitet sein. Das Schlimmste, was bei dem Projekt der Datenbankmigration zur Cloud passieren kann, ist, dass die neue Datenbank nicht mehr verfügbar ist und die Benutzer ihre Arbeit nicht erledigen können. Üblicherweise wird dieses Risiko, was eine große Auswirkung auf die Rentabilität Ihres Unternehmens haben könnte, durch Planung eines Rollbacks zur ursprünglichen, nicht geänderten lokalen Datenbank gemindert.

Berücksichtigen Sie Folgendes für den Fallbackplan:

Wie stellen Sie sicher, dass Sie einen Fallback auf eine Datenbank durchführen können, die von der nicht gelungenen Migration unberührt ist? Sie sollten z. B. unmittelbar vor dem Beginn der Migration unbedingt eine vollständige Datenbanksicherung durchführen.
Wie lange ist es akzeptabel, dass die Datenbank offline ist, wenn Sie einen Fallback ausführen müssen?
Wie hoch ist Ihr Budget für den Fallbackplan? Haben Sie beispielsweise die Möglichkeit, die Datenbank auf einen dedizierten Fallbackserver zu replizieren? Wenn dies der Fall ist, können Sie diesen Server direkt vor der Migration deaktivieren. Um einen Fallback durchzuführen, starten Sie diesen Server. Sie verfügen dann sofort über eine Datenbank, die von der Migration nicht betroffen ist, ohne sie aus der Sicherung wiederherstellen zu müssen.

Offline- oder Onlinemigration?

Zum Migrieren einer Datenbank haben Sie mindestens zwei Optionen:

Hinweis

Die Option online ist derzeit nicht für MySQL-Datenbanken im Datenmigrationsdienst verfügbar.

Halten Sie das System an, übertragen Sie die Datenbank, und konfigurieren und starten Sie das System neu, um die neue Datenbank zu verwenden. Dies ist eine Offlinemigration.
Halten Sie die Ausführung des Systems aufrecht, während Sie die Datenbank an den neuen Speicherort verschieben, führen Sie für Transaktionen, die in der ursprünglichen Datenbank ausgeführt werden, ein Rollforward zur neuen Datenbank aus, während die Migration fortgesetzt wird, und stellen Sie dann die Verbindung Ihre Anwendungen mit der neuen Datenbank her. Dies ist eine Onlinemigration.

Es ist einfacher, eine Offlinemigration durchzuführen, bei der die Benutzer die Daten während der Migration nicht ändern können. Wenn Ihre Datenbank jedoch ausgelastet ist oder der Erfolg Ihrer Organisation von ihr abhängt, ist dies unter Umständen nicht möglich.

Offlinemigrationen

Angenommen, Ihre Datenbank unterstützt ein Team von Analysten, die alle während der normalen Geschäftszeiten in einer einzigen Zeitzone arbeiten. Das Team arbeitet in der Regel nicht am Wochenende. Zwischen 18:00 Uhr am Freitag und 9:00 Uhr am Sonntag wird die Datenbank nicht oft verwendet.

In dieser Situation könnten Sie eine Offlinemigration über das Wochenende in folgenden Schritten durchführen:

Schalten Sie die Datenbank offline, nachdem alle Transaktionen am Freitagabend abgeschlossen wurden.
Erstellen Sie eine vollständige Sicherung oder einen Export der Datenbank.
Fahren Sie den lokalen Server herunter, und halten Sie ihn für einen eventuellen Fallback in Bereitschaft.
Stellen Sie die Datenbank auf dem Zielcloudsystem wieder her.
Schalten Sie das Zielsystem online.
Konfigurieren Sie Clients neu, um eine Verbindung mit der Clouddatenbank herzustellen.

In diesem Fall ist eine Offlinemigration möglich, da eine lange Dienstunterbrechung hier kaum Auswirkungen auf die Benutzer hat. Während dieser Zeit können Sie mit der Gewissheit, dass keine Änderungen auf der Strecke bleiben, eine komplette Sicherung und Wiederherstellung der Datenbank durchführen.

Onlinemigrationen

Jetzt stellen Sie sich eine andere Datenbank vor, die eine Verkaufs-App unterstützt. Die Vertriebsmitarbeiter sind weltweit verteilt und arbeiten auch an Wochenenden. Es gibt keine Phasen geringer Aktivität, die Datenbank ist immer ausgelastet, und wenn Sie die Datenbank für einen beträchtlichen Zeitraum offline schalten, wirkt sich dies auf die Benutzer aus. Die Verkaufsaktivität ist unternehmenskritisch, sodass sich eine Dienstunterbrechung direkt auf die Bilanz des Unternehmens auswirkt.

In solchen Fällen sollten Sie eine Onlinemigration durchführen. Bei einer Onlinemigration ist die Downtime auf die Zeit beschränkt, die für den Wechsel zur neuen Datenbank benötigt wird. Verwenden Sie ein Tool wie den Azure Data Migration Service, um eine Onlinemigration auszuführen. Onlinemigrationen unterscheiden sich folgendermaßen von Offlinemigrationen:

Sie verschieben die ursprüngliche Datenbank nicht offline, bevor Sie eine Sicherung oder einen Export durchführen.
Während der Migration werden Änderungen auf die alte Datenbank angewendet.
Das Migrationstool stellt sicher, dass diese Änderungen vor dem Wechsel in die neue Datenbank kopiert werden. Dies wird häufig durch Neukonfigurieren der alten Datenbank zum Replizieren von Änderungen in der neuen Datenbank erreicht.

Anwendungsmigration

Nachdem Sie eine Datenbank migriert haben, wie (und wann) sollten Sie zum neuen System wechseln und Anwendungen aktualisieren, um die neue Datenbank zu verwenden? Sie könnten:

Anwendungen nacheinander in die neue Datenbank verschieben.
Teilmengen von Benutzern verschieben.
Eine Kombination beider Ansätze übernehmen.

Dahinter steht die Absicht, dass Sie die Anwendungsmigration in kleinen Phasen durchführen, für die mühelos ein Rollback durchgeführt werden kann, wenn etwas schief geht. Unabhängig davon, ob Sie einen Offline- oder Onlineansatz bei der Datenbankmigration befolgt haben, sollten Sie immer noch über eine funktionierende Konfiguration verfügen, die sich an der ursprünglichen Quelle befindet. Theoretisch könnten Sie schnell wieder zurück zur ursprünglichen Quelle wechseln. Wenn sich die Daten jedoch ständig ändern, müssen Sie berücksichtigen, wo diese Änderungen vorgenommen wurden.

Bei einer Offlinemigration sind Quelle und Ziele voneinander unabhängig. Benutzer und Anwendungen sehen möglicherweise keine konsistente Ansicht der Daten mehr. In einem transaktionalen System ist diese Situation wahrscheinlich nicht akzeptabel. In diesem Fall müssten Sie eine Form der bidirektionalen Replikation zwischen Datenbanken aufrechterhalten, während beide Systeme live bleiben. Wenn der Zweck einer Anwendung andererseits darin besteht, monatliche oder wöchentliche Berichte zu generieren, Verkaufsprognosen zu generieren oder andere statistische Vorgänge auszuführen, ist dieser Mangel an Konsistenz möglicherweise nicht so beunruhigend. Diese Anwendungen werten Daten aus einem bestimmten Zeitraum aus, anstatt von aktuellen Daten abhängig zu sein. In diesem letzteren Fall verwenden transaktionale Anwendungen die neue Datenbank, während Berichterstellungsanwendungen langsamer verschoben werden.
Bei einer Onlinemigration wird die neue Datenbank mit der alten synchronisiert, normalerweise in Form der Replikation. Der Replikationsprozess ist möglicherweise asynchron, sodass es zu einer Verzögerung kommen kann. Änderungen, die an den Daten in der neuen Datenbank vorgenommen werden, werden jedoch nicht an die alte zurückgegeben, was zu möglichen Konflikten führt. Eine Anwendung, die auf der alten Datenbank ausgeführt wird, führt möglicherweise bei den Daten, die in der neuen Datenbank geändert wurden, eine Änderung durch, die einen Konflikt auslöst. Bei der Replikation wird die Änderung in der neuen Datenbank blind überschrieben, was zu einem „verlorenen Update“ führt.

Ansätze zum Testen

Wenn die Datenbank in Ihrem Unternehmen eine entscheidende Rolle spielt, können die Folgen eines Ausfalls sehr weitreichend sein. Um sicher zu gehen, dass dies nicht geschehen wird, sollten Sie Leistungstests der migrierten Datenbank durchführen, um sicherzustellen, dass sie die Workload, die Benutzer ihr auferlegen, bewältigen und schnell antworten kann. Beachten Sie, dass Phasen der Spitzenaktivität auftreten könnten, wenn die Nachfrage weitaus höher ist als normal. Sie müssen sicherstellen, dass Ihr migriertes System die erwartete Workload verarbeitet.

Führen Sie für die neue Datenbank immer Regressionstests durch, bevor Sie Benutzern darauf Zugriff gewähren. Mit diesen Tests wird überprüft, ob das Verhalten und die Funktionalität des Systems korrekt sind.

Außerdem sollten Sie die Ausführung eines „Soak-Tests“ erwägen. Ein Soak-Test ist ein Auslastungstest, der zeigen soll, wie das System als Ganzes unter Druck arbeitet. Ein Soak-Test belastet die neue Datenbank und ermittelt, ob sie bei starker Nachfrage stabil bleibt. Ein Soak-Test wird über einen längeren Zeitraum ausgeführt, um zu sehen, was geschieht, wenn die starke Nachfrage anhält.

Wenn Sie festgestellt haben, dass das neue System stabil ist, können Sie beginnen, Benutzer zu migrieren. Sie benötigen jedoch möglicherweise zusätzliche Sicherheit, dass Benutzer das neue System akzeptabel finden. An diesem Punkt könnten Sie die Ausführung eines „Canary-Tests“ erwägen. Bei einem Canary-Test wird eine kleine Teilmenge von Benutzern transparent zum neuen System umgeleitet, aber sie weiß nicht, dass sie darauf zugreift. Dabei handelt es sich um eine Art Blindtest, der Ihnen ermöglicht, Probleme mit dem neuen System zu erkennen. Überwachen Sie die Antworten dieser Benutzer, und nehmen Sie erforderliche Anpassungen vor.

Beibehalten paralleler Systeme

Es gibt mehrere Gründe, warum Sie sich entscheiden könnten, die alte lokale Datenbank parallel zur neuen Clouddatenbank auszuführen:

Testphasen. Wie Sie bereits im vorherigen Thema gesehen haben, empfiehlt es sich, Canary-Tests der migrierten Datenbank auszuführen, um ihre Funktionalität, Stabilität und Kapazität zu bewerten, bevor Sie sie zur Unterstützung von Personen verwenden. Wenn Sie das lokale System parallel beibehalten, können Sie die Benutzer schnell zum alten System zurückführen, wenn Probleme mit dem neuen System auftreten.
Migration in Phasen. Eine Möglichkeit, die Auswirkungen unerwarteter Ausfälle auf die Produktion zu mindern, besteht darin, zuerst eine kleine Anzahl von Benutzern in das neue System zu verschieben und die Ergebnisse zu überwachen. Wenn alles problemlos läuft, und Sie Vertrauen in die neue Datenbank gewonnen haben, könnten Sie andere Gruppen von Benutzern verschieben. Sie können Benutzer alphabetisch, nach Abteilung, nach Standort oder nach Rolle verschieben, bis alle mit der neuen Datenbank arbeiten.
Schrittweise Migration. Ein anderer Ansatz ist, die Migration nicht nach Benutzern, sondern nach Workload zu segmentieren. Beispielsweise könnten Sie die Datenbanktabellen, die die Personalabteilung unterstützen, vor denen migrieren, die den Verkauf unterstützen.

In all diesen Fällen gibt es einen Zeitraum, in dem die alte lokale Datenbank parallel zur neuen Clouddatenbank ausgeführt wird. Sie müssen sicherstellen, dass an der alten Datenbank vorgenommene Änderungen auch auf die neue Datenbank angewendet werden und umgekehrt. Sie könnten ein Skript für diese Synchronisierung erstellen oder ein Tool wie Azure Data Migration Service verwenden.

Wenn Sie sich dazu entschließen, parallele Datenbanken beizubehalten und Änderungen zu synchronisieren, stellen Sie sich folgende Fragen:

Konfliktlösung. Ist es wahrscheinlich, dass eine lokale Änderung an einer Zeile zum selben Zeitpunkt erfolgt wie eine andere Änderung derselben Zeile in der Cloud? Dies würde zu einem Konflikt führen, bei dem unklar ist, welche Änderung beibehalten werden soll. Wie würden Sie solche Konflikte lösen?
Netzwerkdatenverkehr. Wie viel Netzwerkdatenverkehr wird generiert, während Änderungen zwischen Datenbanken synchronisiert werden? Verfügen Sie über genügend Netzwerkkapazität für diesen Datenverkehr?
Wartezeit: Wenn eine der Datenbanken geändert wird, ist die (etwaige) Verzögerung, bevor diese Änderung die andere Datenbank erreicht, akzeptabel? Beispielsweise könnten Sie in einem Produktkatalog möglicherweise bis zu einem Tag warten, bis neue Produkte für alle Benutzer sichtbar sind. Wenn die Datenbank jedoch entscheidende Transaktionsinformationen wie Wechselkurse enthält, sollten diese Daten viel häufiger – wenn nicht gar sofort – synchronisiert werden.

Schrittweise Migration

Bei einer schrittweisen Migration teilen Sie ein ganzes System in Workloads auf und migrieren jeweils eine Workload.

Mehrere Datenbanken

Ein komplexes System kann mehrere Datenbanken enthalten, die mehrere Workloads unterstützen. Beispielsweise kann die Personalabteilung die StaffDb -Datenbank verwenden, während das Vertriebsteam über mobile Apps verfügen kann, die sowohl die ProductCatalogDB-Datenbank als auch die OrdersDB-Datenbank abfragen.

Natürlich können Sie das gesamte Datenbanksystem in einem einzigen Schritt zur Cloud migrieren. Dies ist möglicherweise einfacher, da Sie Datenbanken nicht lokal und in der Cloud ausführen müssen. Sie müssen nicht berücksichtigen, wie diese Datenbanken während der Migration kommunizieren. Die Risiken eines Ausfalls sind jedoch höher. Ein einzelnes Problem könnte sich sowohl auf das Personalabteilungsteam als auch auf das Vertriebsteam auswirken.

Sie sollten diese Risiken für mittelgroße und große Datenbanksysteme verringern, indem Sie eine schrittweise Migration durchführen, bei der Sie jeweils eine Workload verschieben. In diesem Beispiel sollten Sie erwägen, zuerst die StaffDB-Datenbank zu migrieren, da die Probleme im Zusammenhang mit einem Ausfall auf das Personalabteilungsteam beschränkt wären und Sie nicht daran hindern würden, Bestellungen anzunehmen. Bei der Behebung von Problemen, die bei der StaffDb-Migration auftreten, machen Sie Erfahrungen, die auch für andere Workloadmigrationen gelten.

Als Nächstes könnten Sie die Produktkatalog-Workload zur Cloud migrieren. Wenn Sie dies tun, sollten Sie folgende Fragen berücksichtigen:

Wie stellen Sie sicher, dass Produkte, die dem Katalog neu hinzugefügt wurden, für die Bestellung verfügbar sind?
Müssen Sie Daten mit der OrdersDB-Datenbank synchronisieren, die lokal verbleibt?
Welche Wartezeit, um die OrdersDB-Datenbank aus dem Produktkatalog zu erreichen, ist für neue Produkte akzeptabel?

Schrittweise Migrationen einzelner Datenbanken

Auch wenn Sie nur über eine einzelne Datenbank verfügen, die alle Workloads unterstützt, können Sie immer noch eine schrittweise Migration in Erwägung gezogen. Beispielsweise könnten Sie die Datenbank in Teile wie diese aufteilen:

Tabellen, die HR-Vorgänge unterstützen.
Tabellen, die den Vertrieb unterstützen.
Tabellen, die Analyse und Berichterstellung unterstützen.

Wenn Sie die Tabellen für HR-Vorgänge zuerst migrieren, wirken sich etwaige Probleme nur auf HR-Personal aus. Vertriebsmitarbeiter und Datenanalysten arbeiten weiterhin ohne Unterbrechung mit der alten Datenbank.

Bevor Sie eine schrittweise Migration durchführen, müssen Sie die Datenbanken und ihre Verwendung durch Anwendungen vollständig verstehen. Beispielsweise könnten einige Tabellen in der Datenbank sowohl den Vertrieb als auch die Berichterstellung unterstützen. Dies bedeutet, dass Sie Workloads nicht klar aufteilen können. Sie müssen diese Tabellen zwischen lokalen und Clouddatenbanken synchronisieren, bis alle Workloads migriert worden sind.

Sicherheitsaspekte

Ihre Datenbanken enthalten möglicherweise sensible Daten, wie z. B. Produktdetails, Personalinformationen und Zahlungsdetails – Sicherheit hat also immer eine hohe Priorität. Sie müssen entscheiden, wie diese Daten während der Migration und in der neuen Datenbank geschützt werden sollen.

Firewallschutz

In einer Anwendung mit Internetverbindung werden Datenbankserver in der Regel durch mindestens zwei Firewalls geschützt. Die erste Firewall trennt das Internet von den Front-End-Servern – wenn diese Server z. B. Websites oder Web-APIs hosten. Nur der TCP-Port 80 sollte in der äußeren Firewall geöffnet sein, aber dieser Port muss für alle Quell-IP-Adressen geöffnet sein, blockierte Adressen ausgenommen.

Die zweite Firewall trennt die Front-End-Server von den Datenbankservern. Der Datenbankdienst sollte über eine private Portnummer veröffentlicht werden, die der Außenwelt nicht bekannt ist. Öffnen Sie diese Portnummer bei der zweiten Firewall nur für die IP-Adressen der Front-End-Server. Dieses Arrangement verhindert jegliche direkte Kommunikation eines böswilligen Internetbenutzers mit den Datenbankservern.

Wenn Sie Datenbankserver zu virtuellen Azure-Computern migrieren möchten, verwenden Sie ein virtuelles Netzwerk mit Netzwerksicherheitsgruppen (NSGs), um Firewallregeln zu replizieren. Wenn Sie Azure Database for MySQL, Azure Database for MariaDB oder Azure Database for PostgreSQL verwenden, können Sie mit der Seite Verbindungssicherheit für den Server im Azure-Portal Firewallregeln erstellen, um die Datenbank zu schützen.

Authentifizierung und Autorisierung

In den meisten Datenbanken müssen Sie genau steuern, wer auf welche Daten zugreift und diese ändert. Diese Steuerung erfordert, dass Benutzer eindeutig identifiziert werden, wenn sie eine Verbindung mit der Datenbank herstellen. Dieser Vorgang wird als Authentifizierung bezeichnet und in der Regel mit einem Benutzernamen und einem Kennwort ausgeführt. Datenbanksysteme wie MySQL, MariaDB und PostgreSQL stellen ihre eigenen Authentifizierungsmechanismen bereit. Sie müssen sicherstellen, dass Sie die Benutzer weiterhin sicher authentifizieren, wenn Sie Ihre Systeme in die Cloud migrieren.

Hinweis

Die Azure Database for MySQL-, Azure Database for MariaDB- und Azure Database for PostgreSQL-Dienste emulieren herkömmliche MySQL-, MariaDB- und PostgreSQL-Authentifizierung.

Wenn Sie wissen, wer der Benutzer ist, müssen Sie ihm Berechtigungen zuweisen, damit er die Aufgaben ausführen kann, die zu seinem Job gehören. Dieser Prozess wird als Autorisierung bezeichnet.

Bei einem Datenbankmigrationsprojekt müssen Sie sicherstellen, dass Benutzer ordnungsgemäß in der Clouddatenbank autorisiert sind:

Finden Sie heraus, wo Benutzerkonten im lokalen System gespeichert werden. In MySQL werden Benutzerkonten normalerweise in der user-Tabelle der mysql-Datenbank gespeichert, aber es ist z. B. die Integration in Benutzerkonten möglich, die in Active Directory gespeichert sind.
Rufen Sie eine Liste aller Benutzerkonten ab. In MySQL könnten Sie z. B. folgenden Befehl verwenden:
```
SELECT host, user FROM mysql.user;
```
Finden Sie für jedes Benutzerkonto heraus, welchen Zugriff es auf die Datenbank hat. In MySQL könnten Sie z. B. diesen Befehl für das Benutzerkonto dbadmin@on-premises-host verwenden:
```
SHOW GRANTS FOR 'dbadmin'@'on-premises-host';
```
Erstellen Sie jedes Benutzerkonto in der Clouddatenbank neu. In MySQL könnten Sie z. B. diesen Befehl verwenden, um ein neues Konto zu erstellen:
```
CREATE USER 'dbadmin'@'cloud-host'
```
Autorisieren Sie jedes Benutzerkonto mit der richtigen Zugriffsebene in der Clouddatenbank. In MySQL könnten Sie z. B. diesen Befehl verwenden, um einem Benutzer den Zugriff auf die gesamte Datenbank zu gestatten:
```
GRANT USAGE ON *.* TO 'dbadmin'@'cloud-host'
```

Verschlüsselung

Wenn Daten über das Netzwerk gesendet werden, werden sie möglicherweise von einem so genannten „Man-in-the-Middle“-Angriff abgefangen. Um dies zu verhindern, unterstützen Azure Database for MySQL, Azure Database for MariaDB und Azure Database for PostgreSQL Secure Sockets Layer (SSL), um die Kommunikation zu verschlüsseln. SSL wird standardmäßig erzwungen, und Sie sollten diese Einstellung auf keinen Fall ändern.

Möglicherweise müssen Sie die Verbindungseinstellungen Ihrer Clientanwendungen so ändern, dass die SSL-Verschlüsselung verwendet wird. Besprechen Sie dieses Thema mit ihren Entwicklern, um ggf. erforderliche Änderungen zu bestimmen.

Überwachung und Verwaltung

Bei der Planung einer Datenbankmigration sollten Sie bedenken, wie Datenbankadministratoren ihre Aufgaben nach der Migration ausführen werden.

Überwachung

Lokale Datenbankadministratoren führen regelmäßige Überwachungen durch, um Probleme wie Hardwareengpässe oder Netzwerkzugriffskonflikte zu erkennen. Mit der Überwachung möchten sie sicherstellen, dass sie Probleme beheben können, bevor die Produktivität beeinträchtigt wird. Sie können davon ausgehen, dass jede Datenbank, die nicht regelmäßig überwacht wird, früher oder später Probleme verursacht.

Derselbe Ansatz sollte auch für Clouddatenbanken gelten. Die Problemlösung ist in einem Paas-System wie Azure leichter, weil Sie Ressourcen hinzufügen können, ohne Hardware kaufen, einrichten und konfigurieren zu müssen. Allerdings müssen Sie immer noch entstehende Probleme erkennen, sodass die Überwachung eine hohe Priorität unter Ihren täglichen Aufgaben hat.

Bevor Sie Datenbanken in die Cloud migrieren, finden Sie heraus, welche Überwachungstools Ihre Administratoren zurzeit verwenden. Wenn diese Tools mit der vorgeschlagenen cloudbasierten Lösung kompatibel sind, müssen Sie sie möglicherweise nur mit den migrierten Datenbanken neu verbinden. Andernfalls müssen Sie nach Alternativen suchen.

Beachten Sie, dass Azure eine Reihe von Tools für die Leistungsüberwachung umfasst und eine Vielzahl von Leistungsindikatoren und Protokolldaten sammelt. Sie können diese Daten mithilfe von Dashboards und Diagrammen im Azure-Portal anzeigen, wenn Sie Azure Monitor entsprechend konfigurieren. Sie erstellen benutzerdefinierte Diagramme, Tabellen und Berichte, die speziell für die Anforderungen Ihrer Administratoren entwickelt wurden.

Verwaltung

Die Datenbankadministratoren verwenden bevorzugte Tools, um das Schema und den Inhalt der lokalen Datenbank zu ändern. Wenn sie nach der Migration dieselben Tools verwenden, können Sie weiterhin von ihrem Fachwissen profitieren. Beginnen Sie, indem Sie bewerten, ob der vorhandene Satz von Tools mit der vorgeschlagenen in der Cloud gehosteten Datenbank kompatibel ist. Viele Tools sind kompatibel, weil sie auf weit verbreiteten Standards wie SQL basieren, aber es ist wichtig, dass Sie diese Kompatibilität überprüfen. Wenn die aktuellen Verwaltungstools nach der Migration nicht mehr funktionieren, versuchen Sie, mit Ihren Administratoren Alternativen zu finden.

Azure umfasst mehrere Tools, die Sie zum Verwalten von MySQL-, MariaDB- und PostgreSQL-Datenbanken verwenden können:

Das Azure-Portal. Diese Website bietet leistungsstarke Funktionen zum Konfigurieren, Überwachen und Verwalten von Datenbanken – und aller anderen Ressourcen, die Sie möglicherweise in der Azure-Cloud erstellen.
Azure PowerShell. Dabei handelt es sich um eine Ausführungsumgebung und Sprache mit großem Befehlsumfang für Skripts. PowerShell ist für Windows- und Linux-Umgebungen verfügbar. Automatisieren Sie damit komplexe Datenbankverwaltungsaufgaben.
Azure-Befehlszeilenschnittstelle. Dies ist eine Befehlszeilenschnittstelle für Azure. Verwenden Sie sie, um Dienste und Ressourcen in Azure zu verwalten. Sie können die CLI in den Windows- und Linux-Shellumgebungen und in Bash-Skripts verwenden.