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 ähneln anderen Workloads und erfordern einen methodischen Ansatz, um eine erfolgreiche Migration sicherzustellen. Weitere Informationen zur Migrationsmethodik finden Sie unter Cloud-Migration im Cloud Adoption Framework für Azure. In diesem Artikel werden Einschränkungen und Überlegungen beschrieben, die für Oracle-Workloads spezifisch sind.
Oracle-Migrationsszenarien
Wenn Sie Oracle-Workloads migrieren, müssen Sie Datenbanken und Anwendungen übertragen. In diesem Artikel wird der Ansatz "Lift-and-Shift" für Anwendungs- und Datenbankmigrationen erläutert. Der Ansatz "Lift-and-Shift" umfasst die Bereitstellung von Oracle-Anwendungen auf virtuellen Azure-Computern. Für die Datenbankmigration stehen mehrere Optionen zur Verfügung. Dieser Artikel enthält Anleitungen, die für Oracle Database@Azuregelten.
Anwendungen auf virtuellen Computern: Führen Sie Oracle-Unternehmensanwendungen aus, z. B. Siebel, PeopleSoft, JD Edwards, E-Business Suite oder angepasste WebLogic Server-Anwendungen auf der Azure-Infrastruktur.
Oracle Standard Edition- oder Enterprise Edition-Datenbanken auf virtuellen Computern: In diesem Szenario stellen Sie Ihre Oracle-Datenbank auf einem virtuellen Computer bereit. Es stehen mehrere Optionen zur Verfügung, von selbstverwalteten bis hin zu verwalteten Datenbanken. Wenn Sie eine verwaltete Datenbanklösung bevorzugen, überprüfen Sie Tessell.
Oracle Database@Azure: Oracle Database@Azure ist ein Oracle-Datenbankdienst, der auf Oracle Cloud Infrastructure (OCI) ausgeführt wird und in Microsoft-Rechenzentren verortet ist.
Anmerkung
Um die unterstützten Betriebssysteme für Ihre spezifische Datenbankversion zu ermitteln, siehe unterstützte Datenbanken und Betriebssysteme.
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. Stellen Sie beispielsweise für alle zuvor erwähnten Szenarien sicher, dass ausreichende Bandbreite für Ihre Migration verfügbar ist. Wir empfehlen Ihnen dringend, die erforderliche Bandbreite zu überprüfen, wenn Sie einen Machbarkeitsnachweis (PoC) durchführen.
Wenn Sie Ihre Workload auf virtuellen Computern auf Oracle verschieben, stellen Sie sicher, dass die Größe des virtuellen Computers (VM) Ihren Anforderungen entspricht. 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 Sie die Grenzwerte für azure-Abonnementkontingente: Stellen Sie sicher, dass die Kontingentbeschränkungen in Ihrem Azure-Abonnement die von Ihnen ausgewählten Ziel-VM-Größen berücksichtigen können, wenn Sie auf virtuellen Computern zu Oracle migrieren.
Anmerkung
Wenn Sie Ihre Workload auf Oracle Database@Azure hosten und eine Kontingenterhöhung benötigen, wenden Sie sich an Ihren Oracle-Kontakt.
Identifizieren eines Bereitstellungsmodells: Automatisieren Sie die Bereitstellung von Lösungskomponenten so weit wie möglich, indem Sie Infrastruktur als Code, kontinuierliche Integration und fortlaufende Bereitstellungspipelinen und andere DevOps-Methoden verwenden.
Ermitteln von Anwendungsabhängigkeiten: Sicherstellen, dass Migrationsaktivitäten so störungsfrei wie möglich sind.
Identifizieren der Datenkapazität: Identifizieren Sie die Datenmenge, die migriert werden soll, 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 Workloadverfügbarkeit, da diese sich u. U. auf die Migrationstools auswirken, die Sie verwenden können. Definieren Sie Ihre maximale akzeptable Ausfallzeit. Diese Metrik hilft Ihnen, Ihre Migrationstools und -ansätze zu definieren.
Diese Überlegung gilt gleichermaßen für Ihre Anwendung. Wenn Sie in Ihren täglichen Vorgängen keine Unterbrechungen akzeptieren können, müssen Sie eine Onlinemigration durchführen.
- Bestimmen Sie Ihre Tools für die Migration Ihrer Workload zu Oracle auf virtuellen Azure-Computern: Die beiden primären Migrationspfade sind offline und online.
| Offlinemigration | Onlinemigration |
|---|---|
| Einmalige direkte Kopie der Datenbank. | Anfängliche Kopie der Datenbank gefolgt von änderungsdatenerfassung während der Migration. |
| Erfordert, dass die betroffene Anwendung während der Migration offline ist. | Die Anwendung kann während der Migration online bleiben. |
| Verwendete Tools: Data Box, DataPump, Oracle Recovery Manager (RMAN) | Verwendeten Tools: DataGuard, Oracle Recovery Manager (RMAN), GoldenGate |
Anmerkung
Wenn Sie sich für eine Onlinemigration entscheiden, stellen Sie sicher, dass Sie Firewallregeln so konfigurieren, dass die Datenübertragung zulässig ist.
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: Bewerten, ob die lokalen Betriebssystemversionen, Anwendungsversionen und Datenbankversionen lokal und in Azure identisch sind.
Wenn Sie eine oder mehrere Ressourcen aktualisieren müssen, aktualisieren Sie sie vor der Migration, um den Migrationsprozess zu vereinfachen.
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. Migrationsmethoden, die mit der Endian-Konvertierung kompatibel sind, umfassen Oracle DataPump Export oder Oracle Data Pump Import, Oracle Cross Platform Transportable Tablespaces (XTTS) oder Hilfsprogramme zur Datenreplikation wie Oracle GoldenGate, Quest SharePlex und Striim.
Je nach Anforderungen und Kompatibilität können Sie lokale Anwendungsserver modernisieren oder migrieren. Weitere Informationen finden Sie unter Cloudeinführungsszenarien.
Bewerten der Workloadverfügbarkeitsanforderungen während des Migrationsprozesses: Wenn Sie die Downtime von Workloads minimieren müssen, sind Migrationsmethoden wie DataPump Export oder Data Pump Import für Ihre Workload möglicherweise nicht geeignet. Führen Sie in diesem Fall diesen vierstufigen Prozess aus:
Verwenden Sie RMAN, um die gesamte Datenbank in Azure zu sichern und dann 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.
Wenn beide Quellen im Little-Endian-Format vorliegen, verwenden Sie Oracle Data Guard, um die neuhergestellte Datenbank in Azure mit der Quelldatenbank zu synchronisieren. Sie können Data Guard nicht verwenden, wenn die Migration eine Konvertierung von „big-endian“ in „little-endian“ umfasst. 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. Je nach verwendeter Synchronisierungsmethode kann ein Cutover nur wenige Minuten dauern.
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.
Erforderliche Lizenzen bewerten: Ihre Datenbank könnte, abhängig vom Migrationstooling, verschiedene Lizenzen benötigen. 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.
Oracle Database@Azure Migrationsleitfaden
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 (Zero Downtime Migration, ZDM). ZDM bietet die Möglichkeit, logische oder physische Migrationsszenarien auszuwählen. Weitere Informationen finden Sie unter ZDM-Migration.
Anmerkung
Wenn Sie den autonomen Datenbankdienst (ADB-S) auswählen, denken Sie daran, dass nur logische Migrationsszenarien unterstützt werden.
Weitere Anleitungen
Im folgenden Abschnitt können Sie die richtige Migrationsoption für Ihre Anforderungen und Datengrößen auswählen.
Referenz zur ExpressRoute-basierten Migrationsdauer
Die folgende Tabelle dient nur als Basisplan. Andere Produktionsworkloads, die über dieselbe Azure ExpressRoute-Verbindung ausgeführt werden, werden nicht berücksichtigt.
VMware benötigt möglicherweise mehr Bandbreite als angegeben. Bewerten Sie Ihre Bandbreitenanforderungen während der PoC-Phase. Wenn Sie Support benötigen, wenden Sie sich an Ihren lokalen Kontakt.
| Datengröße | Bandbreite von 1 Gpbs | Bandbreite von 10 GBit/s |
|---|---|---|
| 1 TB | 3 Stunden | 15 Min. |
| 10 TB | 1 Tag | 3 Stunden |
| 35 TB | 4 Tage | 9 Stunden |
| 80 TB | 8 Tage | 20 Stunden |
| 100 TB | 11 Tage | 1 Tag |
| 200 TB | 21 Tage | 2 Tage |
| 500 TB | 53 Tage | 5 Tage |
Wenn Sie beabsichtigen, ExpressRoute für die Migration zu verwenden, stellen Sie sicher, dass die Resilienz Ihre Anforderungen erfüllt.