Migration planen
Die Architektur unterstützt mehrere Migrationsszenarios.
Migrationsoptionen berücksichtigen
Mit Oracle Exadata Database Service oder Oracle Database Exadata Cloud at Customer sind vier gängige Deployment-Modelle zu berücksichtigen:
- Verschieben Sie Ihre große On-Premise-Datenbank in Oracle Database Exadata Cloud at Customer unverändert, und stellen Sie außerdem eine OCI-Disaster-Recovery-(DR-)Instanz bereit, die über Oracle Data Guard verbunden ist.
Komponente On Premise Exadata (Halb Rack) Datenbankgröße 47 TB 47 TB Kerne 24 16 Globaler Systembereich und globaler Programmbereich 4 TB 1,5 TB - Konsolidieren Sie mehrere On-Premise-Datenbanken in mehreren integrierbaren Datenbanken (PDBs) in Oracle Exadata Database Service oder Oracle Database Exadata Cloud at Customer, und stellen Sie gleichzeitig eine mit Oracle Data Guard verbundene OCI DR-Instanz bereit.
Komponente On Premise Exadata (10 Full Rack) Datenbanken 1000 1000 DB-Konfiguration 2-16 TB pro DB CDB = 29 PDB = 1000 unterschiedlicher Größe
- Führen Sie Produktions-Workloads On Premise mit Oracle Database Exadata Cloud at Customer aus, und stellen Sie DR oder Oracle Exadata Database Service auf OCI mit den Datenbankinstanzen bereit, die über Oracle Data Guard verbunden sind.
Komponente On Premise Exadata (Halb Rack) Datenbankgröße 19.5 TB 19.5 TB Kerne 24 12 Globaler Systembereich und globaler Programmbereich 2.5 TB 1,5 TB - Führen Sie Produktions-Workloads in Oracle Exadata Database Service auf OCI und DR mit On-Premise-Hardware mit den Datenbankinstanzen aus, die über Oracle Data Guard verbunden sind.
Komponente On Premise Exadata (Halb Rack) Datenbankgröße 19.5 TB 19.5 TB Kerne 24 12 Globaler Systembereich und globaler Programmbereich 2.5 TB 1,5 TB
Migrationsservices ohne Ausfallzeiten verwenden
Um Ihre großen On-Premise-Datenbanken zu Oracle Cloud Infrastructure (OCI) zu migrieren, sollten Sie Zero Downtime Migration-(ZDM-)Services verwenden.
Unabhängig davon, ob Sie Oracle Exadata Database Service oder Oracle Database Exadata Cloud at Customer verwenden, müssen Sie beide ein Backup der Quelldatenbank erstellen und in der Zieldatenbank wiederherstellen. Anschließend müssen Sie RMAN ausführen, eine Oracle Active Data Guard-Synchronisierung ausführen und die primäre Rolle von der Quelldatenbank in die Zieldatenbank umschalten. Zero Downtime Migration unterstützt außerdem verschiedene Migrationsmethoden basierend auf dem gewählten Backupmedium. Das Backupmedium kann Oracle Cloud Infrastructure Object Storage-, Zero Data Loss Recovery Appliance- oder NFS-Speicher (Network File System) sein.
Die folgende Tabelle zeigt die Anforderungen und Bedingungen für mehrere Zero Downtime Migration-(ZDM-)Szenarios.
| Migrationsmethode | Migrationszeit | Ausfallzeitanforderung* | Verwendete Oracle-Tools | Wann verwendet |
|---|---|---|---|---|
| ZDM - Physisch online | 8 Stunden |
2-5 Minuten (unabhängig von der Datenbankgröße) |
|
|
| ZDM - Physisch offline | 8 Stunden | ~8 Stunden pro TB |
|
|
| ZDM - Logisch online | 12 Stunden |
2-5 Minuten (unabhängig von der Datenbankgröße) |
|
|
| ZDM - Logisch offline | 16 Stunden | ~16 Stunden pro TB |
|
|
* Diese Ausfallzeiten stammen von unserer Erfahrung und sollten als Gesamtleitfaden und nicht als genaue Zahlen verwendet werden. Die Ausfallzeitanforderungen können stark variieren. Daher ist eine gründliche Analyse und Prüfung erforderlich, bevor eine Produktionsumstellung geplant wird.
Empfehlungen
Ihre Anforderungen können sich von der hier beschriebenen Architektur unterscheiden. Verwenden Sie die folgenden Empfehlungen als Ausgangspunkt.
- VCN
Wenn Sie ein VCN erstellen, bestimmen Sie die Anzahl der erforderlichen CIDR-Blöcke und die Größe jedes Blocks basierend auf der Anzahl der Ressourcen, die Sie an Subnetze im VCN anhängen möchten. Verwenden Sie CIDR-Blöcke, die sich im privaten Standardadressbereich befinden.
Wählen Sie CIDR-Blöcke aus, die sich nicht mit einem anderen Netzwerk (in Oracle Cloud Infrastructure, Ihrem On-Premise-Data Center oder einem anderen Cloud-Provider) überschneiden, für das Sie private Verbindungen einrichten möchten.
Nachdem Sie ein VCN erstellt haben, können Sie die zugehörigen CIDR-Blöcke ändern, hinzufügen und entfernen.
Berücksichtigen Sie bei der Entwicklung der Subnetze Ihren Trafficfluss und Ihre Sicherheitsanforderungen. Hängen Sie alle Ressourcen innerhalb einer bestimmten Tier oder Rolle an dasselbe Subnetz an, das als Sicherheitsgrenze dienen kann.
Verwenden Sie regionale Subnetze.
- Cloud Guard
Klonen und passen Sie die von Oracle bereitgestellten Standardrezepte an, um benutzerdefinierte Detektor- und Responder-Rezepte zu erstellen. Mit diesen Rezepten können Sie angeben, welche Art von Sicherheitsverletzungen eine Warnung generieren und welche Aktionen für sie ausgeführt werden dürfen. Beispiel: Sie möchten Object Storage-Buckets ermitteln, deren Sichtbarkeit auf "Öffentlich" gesetzt ist.
Wenden Sie Cloud Guard auf Mandantenebene an, um den weitesten Geltungsbereich abzudecken und den administrativen Aufwand bei der Verwaltung mehrerer Konfigurationen zu reduzieren.
Sie können auch das Feature "Verwaltete Liste" verwenden, um bestimmte Konfigurationen auf Detektoren anzuwenden.
- Sicherheitszonen
Für Ressourcen, die maximale Sicherheit erfordern, empfiehlt Oracle, Sicherheitszonen zu verwenden. Eine Sicherheitszone ist ein Compartment, das mit einem von Oracle definierten Rezept der Sicherheits-Policys verknüpft ist, die auf Best Practices basieren. Beispiel: Die Ressourcen in einer Sicherheitszone dürfen nicht über das öffentliche Internet zugänglich sein und müssen mit vom Kunden verwalteten Schlüsseln verschlüsselt werden. Wenn Sie Ressourcen in einer Sicherheitszone erstellen und aktualisieren, validiert Oracle Cloud Infrastructure die Vorgänge anhand der Policys im Sicherheitszonenrezept und lehnt Vorgänge ab, die eine der Policys verletzen.
Überlegungen
Wenn Sie On-Premise-Datenbanken in Oracle Cloud mit Oracle Exadata Database Service bereitstellen, beachten Sie Folgendes:
- Migration ohne Ausfallzeiten (ZDM)
ZDM kann sowohl On Premise als auch in der Cloud ausgeführt werden. ZDM unterstützt On-Premise-Datenbanken, die in eine Vielzahl von Zielen migriert werden:
- Oracle Base Database Service
- Oracle Exadata Database Service auf dedizierter Infrastruktur
- Oracle Exadata Database Service Cloud at Customer
- Oracle Exadata On Premise
- Oracle Autonomous Database
- Oracle Autonomous Transaction Processing (dediziert und gemeinsam verwendet)
- Oracle Autonomous Data Warehouse (dediziert und gemeinsam verwendet)
- ZDM- und Oracle Cloud Infrastructure-Datenbankmigrationsservice (DMS)
Die Hauptunterschiede zwischen ZDM und DMS sind:
-
ZDM arbeitet als Haupt-Engine zur Unterstützung der meisten Methoden/Quellen/Ziele und basiert auf einer Befehlszeilenschnittstelle (CLI).
-
DMS verwendet ZDM unter den Abdeckungen und ermöglicht die logische Offline-/Onlinemigration mit einer Benutzeroberfläche zu OCI-nativen Datenbankservices.
-
Database Migration ist ein komplett verwalteter Service, mit dem Sie leistungsstarke Selfservice-Funktionen für die Migration von Datenbanken in Oracle Cloud Infrastructure (OCI) erhalten.
-
Die OCI-Datenbankmigration wird als verwalteter Cloud-Service ausgeführt, der von Ihrem Mandanten und Ihren Ressourcen getrennt ist. Der Service wird als Mehrmandantenservice in einem Datenbankmigrationsservice-Mandanten ausgeführt und kommuniziert mit Ihren Ressourcen über private Endpunkte (PEs). PEs werden von der Datenbankmigration verwaltet.
-
- Datenbankgröße
Es gibt keine Größenbeschränkungen für ZDM oder DMS. Die theoretische Einschränkung ist die maximale Größe der Oracle Database, die Ihr Betriebssystem haben kann. Die maximale Anzahl an Datendateien und die maximale Größe einer Datendatei hängen von Ihrem Betriebssystem ab.
Bei einer kleinen (<1) Terabyte-Datenbankmigration zu einer Autonomous Database können Sie je nach Ausfallzeitanforderungen logische ZDM-Offline- oder Onlinemethode verwenden. Die logische Onlineoption erfordert nur wenige Minuten Ausfallzeit, während die logische Offlineoption je nach Datenbankgröße einige Stunden Ausfallzeit in Anspruch nimmt.
Bei einer On-Premise-Datenbankgröße von mindestens 400 TB erfolgt die Migration von On Premise zu Oracle Exadata Database Service Cloud at Customer (das auch im Data Center des Kunden enthalten ist). Mit der physischen ZDM-Onlinemigration können Sie Ihre Ausfallzeit gering halten und mit Data Guard das Risiko während der Migration reduzieren. Die Quell- und Zieldatenbank müssen jedoch dieselbe Version aufweisen. Wenn Sie ein sofortiges Upgrade von einer niedrigeren Version auf eine höhere Version durchführen möchten, verwenden Sie die logische ZDM-Onlinemethode. Jede Offline-Methode verursacht große Ausfallzeiten, die für Ihr Unternehmen möglicherweise nicht akzeptabel sind.
- Data Guard und Active Data Guard
Sowohl Data Guard (DG) als auch Active Data Guard (ADG) bieten ein umfassendes Set von Services, mit denen eine oder mehrere Standbydatenbanken erstellt, verwaltet und überwacht werden, damit primäre Oracle-Datenbanken Katastrophen und Datenbeschädigungen überleben können. Standby-Datenbanken werden als Kopien der Produktionsdatenbank verwaltet. Mit ADG können Sie die Standbydatenbank jedoch schreibgeschützt öffnen (z.B. für Berichtszwecke), während sie mit der Primärdatenbank synchron gehalten wird. Bei DG müssen Sie den Synchronisierungsprozess unterbrechen, um die Standbydatenbank im schreibgeschützten Modus zu öffnen.
- Exadata-Virtualisierung
Sie können Exadata auf einer virtuellen Maschine virtualisieren oder eine Bare-Metal-Installation ausführen. Die Architektur der Optionen kann sich erheblich unterscheiden. Bei einer Bare-Metal-Installation ist ein Oracle-Cluster für einen gesamten Exadata-Rechner vorhanden, es sei denn, Sie partitionieren den Exadata-Rechner physisch. Bei einem virtualisierten Exadata-Rechner verfügen Sie über eine Managementdomain (dom0) und mindestens eine Benutzerdomain (domU), je nachdem, wie viele VM-Cluster bereitgestellt werden.
- Real Application Testing (RAT)
Siehe den Link im Abschnitt "Weitere Informationen anzeigen".