Migrieren von Oracle-Workloads zu Azure
Im Rahmen Ihrer Journey der Cloudeinführung müssen Sie Ihre bestehenden Workloads in die Cloud migrieren. Oracle-Workloads erfordern ähnlich wie andere Workloads einen methodischen Ansatz, um eine erfolgreiche Migration sicherzustellen. Weitere Informationen zur Migrationsmethodik finden Sie unter Cloudmigration im Cloud Adoption Framework. In diesem Artikel werden die für Oracle-Workloads spezifischen Einschränkungen und Überlegungen beschrieben.
Der Oracle-Migrationsprozess
Sie sollten Ihre Infrastrukturanforderungen ständig neu bewerten, um die Leistung zu verbessern und Kosten zu senken, indem Sie den entsprechenden Diensttyp für Ihre Workload wählen. Wenn Sie beispielsweise die Verlagerung Ihrer Workload zu Oracle Database@Azure planen, sollten Sie sicherstellen, dass die von Ihnen ausgewählte SKU Ihre Anforderungen erfüllt. Ebenso müssen Sie bei der Verlagerung Ihrer Workload auf virtuelle Oracle in Azure-Computer sicherstellen, dass die Größe des virtuellen Computers (VM) Ihre Anforderungen erfüllt. Weitere Informationen finden Sie unter Kapazitätsplanung für die Migration von Oracle-Workloads zu Azure-Zielzonen.
Überprüfen Sie die Migrationsressourcen, um den Prozess der Migration von Oracle zu Azure zu definieren. Sie können außerdem:
Überprüfen der Kontingentgrenzen von Azure-Abonnements: Stellen Sie sicher, dass die Ziel-VM-Größen, die Sie bei der Migration von virtuellen Oracle in Azure-Computern auswählen, die Kontingentgrenzen in Ihrem Azure-Abonnement unterstützen.
Bestimmen eines Bereitstellungsmodells: Automatisieren Sie die Bereitstellung von Lösungskomponenten so weit wie möglich durch Einsatz von Infrastructure-as-Code (IaaS), CI/CD-Pipelines (Continuous Integration und Continuous Delivery) und anderen DevOps-Methoden.
Ermitteln von Anwendungsabhängigkeiten: Stellen Sie sicher, dass Migrationsaktivitäten nur minimal störend wirken.
Bestimmen der Datenkapazität: Bestimmen Sie die zu migrierende Datenmenge und bewerten Sie die aktuelle verfügbare Netzwerkkonnektivitätskapazität von lokalen Umgebungen zu Azure. Anhand dieser Informationen können Sie feststellen, ob Sie die Daten direkt aus lokalen Umgebungen in Azure kopieren können. Sie brauchen eventuell eine physische Datenübertragungsanwendung wie Azure Data Box für das anfängliche Laden von Daten.
Ermitteln von Verfügbarkeitsanforderungen: Ermitteln Sie die Anforderungen an die Verfügbarkeit der Workload, denn sie können sich auf die einsetzbaren Migrationstools auswirken.
Für Oracle Database@Azure ist Folgendes erforderlich:
Stellen Sie sicher, dass die Oracle Database@Azure-Lösung in der Region verfügbar ist, in der Sie die Lösung bereitstellen möchten. Weitere Informationen finden Sie unter Verfügbare Regionen.
Ziehen Sie den Einsatz der Oracle-Migration ohne Downtime (ZDM) für den Migrationsprozess in Erwägung. Evaluieren Sie die Migrationsstrategien, um den am besten geeigneten Ansatz für Ihre spezifischen Migrationsanforderungen zu ermitteln. Weitere Informationen finden Sie unter Migration ohne Downtime.
Workloadspezifische Oracle-Migrationsaktivitäten
Im folgenden Abschnitt wird der Migrationsprozess ausführlicher beschrieben. Die Schritte müssen nicht unbedingt aufeinander folgen. Manche Schritte können parallel ausgeführt werden.
Bewerten der Quell- und Zielsystemversionen: Evaluieren Sie, ob die lokalen Betriebssystemversionen (BS), Anwendungs- und Datenbankversionen mit den Versionen übereinstimmen, die sie in Azure verwenden möchten.
Wenn Sie eine oder mehrere Ressourcen aktualisieren müssen, sollten Sie sie vor der Migration aktualisieren, damit der Migrationsprozess nicht kompliziert wird.
Wenn Ihre lokale Datenbank auf einem Big-Endian-Betriebssystem ausgeführt wird, z. B. Oracle Solaris, IBM Advanced Interactive eXecutive oder Hewlett Packard Unix, umfasst der Prozess der Datenbankmigration eine Endian-Konvertierung. Azure unterstützt nur Little-Endian-Betriebssysteme. Diese Einschränkung reduziert die Anzahl der verfügbaren Tools für die Migration. Insbesondere können Sie weder Oracle Data Guard noch eine andere Methode zum Kopieren von Dateien verwenden. Zu den mit der Endian-Konvertierung kompatiblen Migrationsmethoden gehören Oracle Data Pump Export oder Import, Oracle Cross Platform Transportable Tablespaces (XTTS) oder Hilfsprogramme zur Datenreplikation wie Oracle GoldenGate, Quest SharePlex und Striim.
Lokale Anwendungsserver können je nach Anforderungen und Kompatibilität modernisiert oder migriert werden. Weitere Informationen finden Sie unter Cloudeinführungsszenarien.
Bewerten der Anforderungen an die Verfügbarkeit der Workload während des Migrationsprozesses: Wenn Sie die Ausfallzeiten Ihrer Workload minimieren müssen, sind Migrationsmethoden wie Data Pump Export oder Import möglicherweise nicht für Ihre Workload geeignet. In diesem Fall können Sie diesen vierstufigen Prozess befolgen:
Verwenden Sie den Oracle Recovery Manager (RMAN), um die gesamte Datenbank zu sichern und dann in Azure wiederherzustellen. Nehmen Sie bei Bedarf eine Endian-Konvertierung über XTTS vor. Dadurch ergibt sich eine Datenbank, die eine Kopie der lokalen Quelldatenbank zu einem bestimmten Zeitpunkt ist. Weitere Informationen finden Sie unter Transport von Daten über Plattformen hinweg.
Verwenden Sie Oracle Data Guard, um die neu wiederhergestellte Datenbank in Azure mit der Quelldatenbank zu synchronisieren, wenn beide Quellen das Little-Endian-Format haben. Wenn die Migration eine Konvertierung von Big-Endian nach Little-Endian erfordert, können Sie Data Guard nicht verwenden. Verwenden Sie stattdessen ein SQL-basiertes Hilfsprogramm zur Datenreplikation wie Oracle GoldenGate, Quest SharePlex oder Striim, um die neu wiederhergestellte Datenbank in Azure mit der Quelldatenbank zu synchronisieren.
Wenn Sie die Zieldatenbank in Azure mit der lokalen Quelldatenbank synchronisiert haben, können Sie ein Cutover planen. Ein Cutover schaltet die lokale Quelldatenbank ab und überträgt die letzten Transaktionen in die Zieldatenbank in Azure. Anschließend können Sie die Zieldatenbank in Azure als neue Quelldatenbank öffnen. Ein Cutover dauert je nach verwendeter Synchronisierungsmethode nur wenige Minuten.
Je nach der für Anwendungsdienste gewählten Migrationsmethode müssen Sie gegebenenfalls mehrere Aufgaben im Anwendungsdienst ausführen, bevor Sie die Anwendung vollständig zu Azure migrieren.
Prüfen der erforderlichen Lizenzen: Je nach Migrationstool erfordert Ihre Datenbank möglicherweise verschiedene Lizenzen. Beispiel:
Oracle Data Guard erfordert die Oracle Database Enterprise Edition.
Oracle GoldenGate erfordert Oracle GoldenGate-Lizenzen.
Weitere Informationen zur Oracle-Lizenzierung in Azure finden Sie unter Lizenzieren von Oracle-Software in der Cloud Computing-Umgebung.