1. Mit Oracle Zero Downtime Migration zu Oracle Database@Azure wechseln
  2. Mit Oracle Zero Downtime Migration zu Oracle Database@Azure wechseln

Mit Oracle Zero Downtime Migration zu Oracle Database@Azure wechseln

Mit Oracle Database@Azure können Sie Ihre geschäftskritischen Oracle-Datenbanken auf Oracle Exadata Database Service on Dedicated Infrastructure im Microsoft Azure-Data Center ausführen.

Profitieren Sie von der integrierten High Availability, Performance und Skalierbarkeit von Oracle Exadata Database Service und Oracle Real Application Clusters (Oracle RAC), und profitieren Sie gleichzeitig von geringer Latenz für Ihre Azure-Anwendungen.

Die Datenbankmigration in die Cloud ist in der Regel ein manueller Prozess, der mit Ausfallzeiten für Ihr Unternehmen verbunden ist. Oracle Zero Downtime Migration vereinfacht und automatisiert Oracle-Datenbankmigrationen ohne bis zu minimale Ausfallzeiten, umfasst standardmäßig die Best Practices von Oracle Maximum Availability Architecture (Oracle MAA), unterstützt Flottenmigrationen und ist unter anderem kostenlos.

Seit seiner Veröffentlichung im Jahr 2019 ist Oracle Zero Downtime Migration das vertrauenswürdige Migrationstool für Kunden weltweit für Oracle-Datenbankmigrationen zu On-Premises-Oracle Exadata-Maschinen, Oracle Exadata Database Service on Cloud@Customer und Oracle Cloud Infrastructure (OCI). Weitere Informationen zur Oracle Zero Downtime Migration finden Sie unter "Weitere Informationen".

Architektur

Diese Referenzarchitektur beschreibt Oracle Database-Migrationen von On Premise zu Oracle Exadata Database Service on Dedicated Infrastructure auf Oracle Database@Azure mit dem physischen Online-Migrationsworkflow basierend auf Oracle Data Guard und direkter Datenübertragung. Dies bietet Einfachheit, Automatisierung und Geschäftskontinuität während Ihrer Datenbankmigrationen zu Oracle Database@Azure.

Der Host des Oracle Zero Downtime Migration-Service wird auf einer separaten On-Premise-VM neben der Quelldatenbank installiert. Das Ziel Oracle Exadata Database Service on Dedicated Infrastructure wird im Azure-Data Center im virtuellen Azure-Netzwerk (VNet) in einem delegierten Subnetz an Oracle Database@Azure bereitgestellt. Das On-Premise-Data Center ist über Azure ExpressRoute oder Site-to-Site-VPN mit dem Data Center von Azure verbunden. Der physische Onlineworkflow von Oracle Zero Downtime Migration basierend auf der direkten Datenübertragung erstellt die Zieldatenbank mit dem Restore aus einer Servicemethode und vermeidet das Backup der Quelldatenbank in einem Zwischenspeicherort. Oracle Zero Downtime Migration nutzt Oracle Data Guard automatisch, um die Daten aus der On-Premise-Datenbank in die Zieldatenbank zu replizieren. Oracle Zero Downtime Migration richtet Oracle Data Guard automatisch ein, verwaltet es und bereinigt die Konfiguration nach Abschluss der Migration. Daher sind keine Kenntnisse zum Einrichten und Verwalten von Oracle Data Guard erforderlich. Nach Abschluss der Migration kann die Zieldatenbank mit dem Feature "Automatisches Backup" ein Backup der Datenbank in Oracle Database Autonomous Recovery Service erstellen.

Das folgende Diagramm veranschaulicht diese Referenzarchitektur.


Beschreibung von oracle-db-azure-zdm-diagram.png:
Beschreibung der Abbildung oracle-db-azure-zdm-diagram.png

oracle-db-azure-zdm-oracle.zip

Die Architektur umfasst die folgenden Komponenten:

  • Region

    Eine Oracle Cloud Infrastructure-Region ist ein lokalisierter geografischer Bereich, der mindestens ein Data Center enthält, das als Availability-Domain bezeichnet wird. Regionen sind unabhängig von anderen Regionen, und große Entfernungen können sie trennen (über Länder oder sogar Kontinente).

  • Virtuelles Cloud-Netzwerk (VCN) und Subnetze

    Ein VCN ist ein anpassbares, benutzerdefiniertes Netzwerk, das Sie in einer Oracle Cloud Infrastructure-Region einrichten können. Wie traditionelle Data Center-Netzwerke erhalten Sie mit VCNs Kontrolle über Ihre Netzwerkumgebung. Ein VCN kann mehrere sich nicht überschneidende CIDR-Blöcke aufweisen, die Sie nach dem Erstellen des VCN ändern können. Sie können ein VCN in Subnetze segmentieren, die sich auf eine Region oder eine Availability-Domain beschränken. Jedes Subnetz besteht aus einem Bereich zusammenhängender Adressen, die sich nicht mit anderen Subnetzen im VCN überschneiden. Sie können die Größe eines Subnetzes nach der Erstellung ändern. Ein Subnetz kann öffentlich oder privat sein.

  • Dynamisches Routinggateway (DRG)

    Das DRG ist ein virtueller Router, der einen Pfad für privaten Netzwerktraffic zwischen VCNs in derselben Region zwischen einem VCN und einem Netzwerk außerhalb der Region bereitstellt, wie ein VCN in einer anderen Oracle Cloud Infrastructure-Region, einem On-Premise-Netzwerk oder einem Netzwerk in einem anderen Cloud-Provider.

  • On-Premise-Netzwerk

    Dieses Netzwerk ist das lokale Netzwerk, das von Ihrer Organisation verwendet wird. Es ist eine der Speichen der Topologie.

  • Servicegateway

    Das Servicegateway ermöglicht den Zugriff von einem VCN auf andere Services, wie Oracle Cloud Infrastructure Object Storage. Der Traffic vom VCN zum Oracle-Service durchläuft die Oracle-Netzwerkstruktur und nicht das Internet.

  • Site-to-Site-VPN

    Site-to-Site-VPN bietet IPSec-VPN-Konnektivität zwischen Ihrem On-Premise-Netzwerk und VCNs in Oracle Cloud Infrastructure. Die IPSec-Protokollfamilie verschlüsselt den IP-Traffic, bevor die Pakete von der Quelle an das Ziel übertragen werden, und entschlüsselt den Traffic, wenn er ankommt.

  • VNIC

    Mit einer virtuellen Netzwerkkarte (VNIC) kann eine Instanz eine Verbindung zu einem VCN herstellen. Sie legt fest, wie die Instanz mit Endpunkten innerhalb und außerhalb des VCN verbunden wird. Jede VNIC befindet sich in einem Subnetz in einem VCN und umfasst die folgenden Elemente:

    • Eine primäre private IPv4-Adresse des Subnetzes, in dem sich die VNIC befindet, die Sie oder von Oracle ausgewählt haben.
    • Optionale sekundäre private IPv4-Adressen aus demselben Subnetz, in dem sich die VNIC befindet, die Sie oder von Oracle ausgewählt haben.
    • Eine optionale öffentliche IPv4-Adresse für jede private IP, die von Oracle gewählt, aber von Ihnen nach Belieben zugewiesen wird.
    • Ein optionaler DNS-Hostname für jede private IP-Adresse.
    • Eine MAC-Adresse.
    • Ein von Oracle zugewiesenes VLAN-Tag, das verfügbar ist, wenn der Anhang der VNIC zu der Instanz abgeschlossen ist (nur für Bare-Metal-Instanzen relevant).
    • Ein Flag zum Aktivieren oder Deaktivieren der Quell-/Zielprüfung im Netzwerktraffic der VNIC.
    • Optionale Mitgliedschaft in einer oder mehreren Netzwerksicherheitsgruppen Ihrer Wahl. NSGs enthalten Sicherheitsregeln, die nur für VNICs in dieser NSG gelten.
    • Optionale IPv6-Adressen. Die Adressierung der IPv6 wird für alle kommerziellen und Regierungsregionen unterstützt.
  • Data Guard

    Oracle Data Guard umfasst zahlreiche Services, mit denen Sie mindestens eine Standbydatenbank erstellen, verwalten und überwachen können, damit Oracle-Produktionsdatenbanken ohne Unterbrechung verfügbar bleiben können. Oracle Data Guard verwaltet diese Standby-Datenbanken als Kopien der Produktionsdatenbank. Wenn die Produktionsdatenbank aufgrund eines geplanten oder ungeplanten Ausfalls nicht mehr verfügbar ist, kann Oracle Data Guard jede Standbydatenbank auf die Produktionsrolle umstellen und so die mit dem Ausfall verbundene Ausfallzeit minimieren.

  • Exadata Database Service

    Mit Oracle Exadata Database Service können Sie die Vorteile von Exadata in der Cloud nutzen. Sie können flexible Exadata X9M-Systeme bereitstellen, mit denen Sie dem System Datenbank-Compute-Server und Storage Server je nach Bedarf hinzufügen können. Exadata X9M-Systeme bieten RDMA-über-Converged-Ethernet-(RoCE-)Networking für Module mit hoher Bandbreite und geringer Latenz, persistente Arbeitsspeicher (PMEM) und intelligente Exadata-Software. Sie können Exadata X9M-Systeme mit einer Ausprägung bereitstellen, die einem X9M-System mit Quarter-Rack entspricht. Anschließend können Sie Datenbank- und Speicherserver nach dem Provisioning jederzeit hinzufügen.

    Oracle Exadata Database Service on Dedicated Infrastructure bietet Oracle Exadata Database Machine als Service in einem Oracle Cloud Infrastructure-(OCI-)Data-Center. Die Oracle Exadata Database Service on Dedicated Infrastructure-Instanz ist ein Virtual-Machine-(VM-)Cluster, das sich auf Exadata-Racks in einer OCI-Region befindet.

    Oracle Exadata Database Service on Cloud@Customer stellt Oracle Exadata Database Service bereit, das in Ihrem Data Center gehostet wird.

  • Object Storage

    Der Objektspeicher bietet schnellen Zugriff auf große Mengen an strukturierten und unstrukturierten Daten eines beliebigen Inhaltstyps, einschließlich Datenbankbackups, Analysedaten und umfangreichen Inhalten, wie Bildern und Videos. Sie können Daten sicher und geschützt speichern und dann direkt aus dem Internet oder aus der Cloud-Plattform abrufen. Sie können den Speicher skalieren, ohne dass die Performance oder Servicezuverlässigkeit beeinträchtigt wird. Verwenden Sie Standardspeicher für "Hot Storage", auf den Sie schnell, sofort und häufig zugreifen müssen. Verwenden Sie Archivspeicher für "Cold Storage", den Sie über lange Zeiträume beibehalten möchten und auf den Sie nur selten zugreifen.

  • Azure-VNIC

    Die Services in Azure-Data Centern weisen physische Netzwerkkarten (NICs) auf. Instanzen virtueller Maschinen kommunizieren über virtuelle NICs (VNICs), die mit den physischen NICs verknüpft sind. Jede Instanz verfügt über eine primäre VNIC, die während des Starts automatisch erstellt und angehängt wird und während der Lebensdauer der Instanz verfügbar ist.

  • Virtuelles Azure-Netzwerkgateway

    Azure Virtual Network Gateway ist ein Service, der eine sichere, standortübergreifende Konnektivität zwischen einem virtuellen Azure-Netzwerk und einem On-Premise-Netzwerk herstellt. Sie können damit ein hybrides Netzwerk erstellen, das Ihr Data Center und Azure umfasst.

  • Delegiertes Azure-Subnetz

    Subnetzdelegierung ist die Fähigkeit von Microsoft, einen verwalteten Dienst, insbesondere einen Platform-as-a-Service, direkt in Ihr virtuelles Netzwerk einzuspeisen. Das bedeutet, dass Sie ein Subnetz als Home für einen externen verwalteten Service in Ihrem virtuellen Netzwerk festlegen oder delegieren können. Mit anderen Worten, dieser externe Service wird als virtuelle Netzwerkressource fungieren, obwohl es sich technisch um einen externen Platform-as-a-Service-Service handelt.

  • Virtuelles Azure-Netzwerk

    Das virtuelle Azure-Netzwerk (VNet) ist der grundlegende Baustein für Ihr privates Netzwerk in Azure. Mit VNet können viele Azure-Ressourcen, wie virtuelle Azure-Maschinen, sicher miteinander, mit dem Internet und On-Premise-Netzwerken kommunizieren.

  • Host des Migrationsservice ohne Ausfallzeit

    Der Host des Oracle Zero Downtime Migration-Service muss ein dediziertes System sein, kann aber für andere Zwecke gemeinsam verwendet werden.

    Die Oracle Zero Downtime Migration-Software erfordert einen eigenständigen Oracle Linux-Host, der auf einer der folgenden Plattformen ausgeführt wird: Oracle Linux 7, Oracle Linux 8 oder Red Hat Enterprise Linux 8.

    Der Host des Oracle Zero Downtime Migration-Service muss eine Verbindung zu den Quell- und Zieldatenbankservern herstellen können. Solange die Konnektivität gewährleistet ist, kann sich der Servicehost überall befinden.

Empfehlungen

Verwenden Sie die folgenden Empfehlungen als Ausgangspunkt. Ihre Anforderungen können von der hier beschriebenen Architektur abweichen.
  • Laden Sie die neueste Oracle Zero Downtime Migration-Softwareversion von My Oracle Support (MOS) herunter, indem Sie auf der Registerkarte Patches und Updates nach Patch-Nummer 33509650 suchen.
  • Installieren Sie den Host des Oracle Zero Downtime Migration-Service On Premise neben der Quelldatenbank.
  • Stellen Sie sicher, dass der Host des Oracle Zero Downtime Migration-Service über mindestens 100 GB freien Speicher verfügt.
  • Stellen Sie über ein Site-to-Site-VPN oder Azure ExpressRoute eine sichere und private Netzwerkkonnektivität zwischen On Premise und Azure sicher.
  • Stellen Sie je nach Datenbankgröße einen ausreichenden Netzwerkdurchsatz von Ihrem On-Premise-Netzwerk zu Azure sicher.

Hinweise

Beachten Sie beim Deployment dieser Referenzarchitektur die folgenden Punkte.

  • Die Zieldatenbank muss:
    • Bereitstellung mit Oracle Cloud-Tools, ohne automatische Backups zu aktivieren.
    • Sie verfügen über eine Zeitzonendateiversion, die mit der Quelldatenbank identisch oder höher ist.
  • Die Quell- und Zieldatenbank müssen:
    • Haben denselben Datenbanknamen (DB_NAME).
    • Verwenden Sie unterschiedliche eindeutige Datenbanknamen (DB_UNIQUE_NAME).
    • Verwenden Sie ein Server Parameter File (SPFILE).
    • Verwenden Sie denselben Zeichensatz.
    • Sie müssen denselben Verschlüsselungsalgorithmus in der Datei sqlnet.ora definieren.
    • Verwenden Sie dieselbe Hauptversion (z. B. 19c). Die Zieldatenbank kann jedoch eine höhere Patchebene aufweisen (Beispiel: Quelle bei 19.21 und Ziel bei 19.22). Wenn sich die Zieldatenbank auf einer höheren Patchebene als die Quelldatenbank befindet, führt Oracle Zero Downtime Migration Datapatch automatisch im Rahmen der Migration aus.
  • Das Kennwort des SYS-Benutzeraccounts muss in der Quell- und Zieldatenbank identisch sein.
  • Der Initialisierungsparameter der COMPATIBLE-Datenbank muss in der Quell- und Zieldatenbank identisch sein.
  • Für Oracle Database 12c Release 2 und höher muss das TDE-Wallet in der Quelle vorhanden sein, und der Wallet-Status muss den Status OPEN aufweisen. Die Quelldatenbank muss nicht unbedingt verschlüsselt werden, aber ein TDE-Wallet muss konfiguriert werden.
  • Für Oracle Zero Downtime Migration muss der SSH-Schlüssel auf dem Host des Oracle Zero Downtime Migration-Service im RSA-Format vorliegen (in Oracle Linux 8 ist der Standardwert OPENSSH).

Mehr erfahren

Erfahren Sie mehr über die Services in dieser Architektur.

Prüfen Sie diese zusätzlichen Ressourcen:

Danksagungen

  • Autoren: Sinan Petrus Toma, Ricardo Gonzalez, Thomas Van Buggenhout
  • Beitragende: Emiel Ramakers, Wei Han, John Sulyok