1. On-Premise-Deployment von Oracle Database in ein Bare-Metal-DB-System migrieren
  2. On-Premise-Deployment von Oracle Database zu einem Bare-Metal-DB-System migrieren

On-Premise-Deployment von Oracle Database zu einem Bare-Metal-DB-System migrieren

Vereinfachen Sie Ihre Datenbankbereitstellungs-, Wartungs- und Verwaltungsvorgänge, indem Sie Ihre großen On-Premise-Deployments der Oracle Database Enterprise Edition in Oracle Cloud Infrastructure verschieben.

Architektur

Diese Architektur zeigt die Ressourcen und Topologie, die für die Migration eines On-Premise-Deployments von Oracle Database Enterprise Edition in ein Bare-Metal-DB-System mit einem Knoten in Oracle Cloud Infrastructure erforderlich sind.

Beschreibung von migration-bmdb.png folgt
Beschreibung der Abbildung migration-bmdb.png

migrieren-bmdb-oracle.zip

Die Architektur umfasst folgende Komponenten:

  • On-Premise-Bereitstellung

    Das On-Premise-Deployment umfasst einen Anwendungsserver, der auf einem 4-Core-Intel-Server und einer Oracle Database Enterprise Edition-Instanz auf einem 16-Core-Intel-Server ausgeführt wird. Der Datenbankserver ist mit einem Speichergerät verbunden. Das On-Premise-Netzwerk ist über Oracle Cloud Infrastructure FastConnect oder IPSec-VPN mit einer Oracle Cloud-Region verbunden. Bei der Architektur wird davon ausgegangen, dass auf den On-Premise-Servern Oracle Linux ausgeführt wird.

  • Region

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

  • Availability-Domains

    Availability-Domains sind eigenständige, unabhängige Data Center in einer Region. Die physischen Ressourcen in jeder Availability-Domain sind von den Ressourcen in den anderen Availability-Domains isoliert, was eine Fehlertoleranz bietet. Availability-Domains haben keine gemeinsame Infrastruktur wie Stromversorgung oder Kühlung oder das interne Availability-Domainnetzwerk. Daher ist es wahrscheinlich, dass sich ein Fehler in einer Availability-Domain auf die anderen Availability-Domains in der Region auswirkt.

  • Faultdomains

    Eine Fehlerdomain ist eine Gruppierung aus Hardware und Infrastruktur innerhalb einer Availability-Domain. Jede Availability-Domain hat drei Faultdomains mit unabhängiger Stromversorgung und Hardware. Wenn Sie Ressourcen auf mehrere Faultdomains verteilen, können Ihre Anwendungen physische Serverfehler, Systemwartung und Stromausfälle innerhalb einer Faultdomain tolerieren.

  • Virtuelles Cloud-Netzwerk (VCN) und Subnetze

    Ein VCN ist ein anpassbares, softwaredefiniertes Netzwerk, das Sie in einer Oracle Cloud Infrastructure-Region einrichten. Wie herkömmliche Data Center-Netzwerke erhalten VCNs vollständige Kontrolle über Ihre Netzwerkumgebung. Ein VCN kann mehrere nicht überlappende CIDR-Blöcke haben, die Sie nach dem Erstellen des VCN ändern können. Sie können ein VCN in Subnetze segmentieren, die für eine Region oder eine Availability-Domain gelten können. Jedes Subnetz besteht aus einem fortlaufenden Adressbereich, der sich nicht mit den anderen Subnetzen im VCN überschneidet. Sie können die Größe eines Subnetzes nach dem Erstellen ändern. Ein Subnetz kann öffentlich oder privat sein.

    In dieser Architektur verwenden die Datenbank- und Anwendungsebenen separate Subnetze.

  • Routentabellen

    Virtuelle Routentabellen enthalten Regeln, mit denen Traffic von Subnetzen zu Zielen außerhalb eines VCN weitergeleitet wird, im Allgemeinen über Gateways.

    Diese Architektur verwendet eine Routingregel, um Traffic vom Datenbanksubnetz über das Servicegateway an Oracle Cloud Infrastructure Object Storage zu senden.

  • Sicherheitslisten

    Für jedes Subnetz können Sie Sicherheitsregeln erstellen, die Quelle, Ziel und Typ des Traffics angeben, der im Subnetz und aus dem Subnetz zugelassen werden muss.

    Diese Architektur verwendet Ingress- und Egress-Regeln in den Sicherheitslisten, die an den Anwendungsserver und Datenbanksubnetzen angehängt sind. Diese Regeln ermöglichen die Konnektivität zwischen der Anwendung und der Datenbank. Ingress-Regeln werden während der Migration vorübergehend in den Sicherheitslisten hinzugefügt, die dem Anwendungsserver und den Datenbankserversubnetzen zugeordnet sind, um Anwendungsdateien, Shellskripte und Konfigurationsdaten zu übertragen.

  • 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 einem VCN in einer anderen Oracle Cloud Infrastructure-Region, einem On-Premise-Netzwerk oder einem Netzwerk in einem anderen Cloud-Provider.

  • Servicegateway

    Das Servicegateway bietet Zugriff von einem VCN auf andere Services, wie Oracle Cloud Infrastructure Object Storage. Der Traffic vom VCN zu dem Oracle-Service durchläuft das Oracle-Fabric und durchläuft nie das Internet.

  • Block-Volume

    Mit Block Storage-Volumes können Sie Speicher-Volumes erstellen, anhängen, verbinden und verschieben sowie die Volume-Performance entsprechend Ihren Speicher-, Performance- und Anwendungsanforderungen ändern. Nach dem Anhängen und Verbinden eines Volumes mit einer Instanz können Sie das Volume wie ein herkömmliches Festplattenlaufwerk verwenden. Sie können ein Volume auch trennen und an eine andere Instanz anhängen, ohne Daten zu verlieren.

  • Objektspeicher

    Mit Object Storage erhalten Sie schnellen Zugriff auf große Mengen an strukturierten und unstrukturierten Daten eines beliebigen Inhaltstyps, darunter Datenbankbackups, Analysedaten und umfangreiche Inhalte, wie Bilder 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 nahtlos skalieren, ohne dass die Performance oder Servicezuverlässigkeit beeinträchtigt wird. Verwenden Sie Standardspeicher für "Hotspeicher", auf den Sie brauchen, um schnell, sofort und häufig zuzugreifen. Verwenden Sie Archivspeicher für "Cold Storage", den Sie über lange Zeiträume beibehalten möchten und auf den Sie nur selten zugreifen.

  • Datenbanksystem

    Die On-Premise-Datenbank wird in ein Bare-Metal-DB-System migriert, wobei Oracle Database Enterprise Edition-Lizenzen für 16 Kerne aktiviert sind.

  • Anwendungsserver

    Der On-Premise-Anwendungsserver wird zu einer 4-Core-Compute-Instanz migriert.

Empfehlungen

Ihre Anforderungen können sich von der hier beschriebenen Architektur unterscheiden. Verwenden Sie die folgenden Empfehlungen als Ausgangspunkt.

  • Compute-Ausprägungen

    Diese Architektur verwendet eine Oracle Linux-Compute-Instanz mit einer VM.Standard2.4-Ausprägung für den Anwendungsserver. Wenn die Anwendung mehr Verarbeitungsleistung, Speicher oder Netzwerkbandbreite benötigt, wählen Sie eine größere Ausprägung.

  • Block-Volumes

    Diese Architektur verwendet ein 100-GB-Block-Volume für den Anwendungsserver. Sie können das Volume zur Installation der Anwendung oder zum Speichern von Anwendungslogs und -daten verwenden.

  • DB-Systemausprägungen

    Diese Architektur verwendet die BM.DenseIO2.52-Ausprägung für das DB-System, wobei 16 Kerne aktiviert sind. Wenn Sie mehr Verarbeitungsleistung benötigen, können Sie zusätzliche Kerne aktivieren.

  • 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 standardmäßigen privaten IP-Adressbereich befinden.

    Wählen Sie einen Adressbereich aus, der sich nicht mit Ihrem On-Premise-Netzwerk überschneidet, damit Sie eine Verbindung zwischen dem VCN und Ihrem On-Premise-Netzwerk über FastConnect oder IPSec-VPN einrichten können.

    Nachdem Sie ein VCN erstellt haben, können Sie die zugehörigen CIDR-Blöcke ändern, hinzufügen und entfernen.

    Berücksichtigen Sie beim Entwerfen der Subnetze den Verkehrsfluss und die Sicherheitsanforderungen. Hängen Sie alle Ressourcen innerhalb einer bestimmten Ebene oder Rolle an dasselbe Subnetz an, das als Sicherheitsgrenze dienen kann.

    Regionale Subnetze verwenden

  • Datenbankmigrationsmethode
    In dieser Referenzarchitektur wird Oracle Zero Downtime Migration (ZDM) verwendet, um das On-Premise-Deployment von Oracle Database Enterprise Edition in Oracle Cloud Infrastructure ohne bis zu minimale Ausfallzeiten zu migrieren. Diese Methode reduziert die Auswirkungen der Datenbankmigration auf die Anwendungsverfügbarkeit erheblich, insbesondere wenn Backup- und Kopiervorgänge eine Verbindung mit begrenzter Bandbreite verwenden.

    Hinweis:

    Oracle bietet verschiedene andere Tools für die Migration von On-Premise-Deployments von Oracle Database in die Cloud. Im Abschnitt "Weitere Informationen" finden Sie Links zu weiteren Optionen.
    Überblick über den Migrationsprozess:
    1. Sie laden die ZDM-Software herunter, installieren sie auf einem Standalone-Server von Linux 7 (oder höher), um Migrationen zu koordinieren und den Datenbankmigrationsprozess mit dem Befehl zdmcli migrate database zu starten.
    2. ZDM stellt über die bereitgestellten SSH-Schlüssel eine Verbindung zum Quell- und Zieldatenbankserver her. Anschließend wird die Konnektivität zwischen der Quelldatenbank und einem Bucket in Oracle Cloud Infrastructure Object Storage hergestellt.
    3. ZDM orchestriert die Übertragung der Datenbankbackupdateien von der Quelldatenbank in den Objektspeicher-Bucket, startet eine Data Guard-Standbydatenbank in der Cloud mit den Backupdateien und synchronisiert die Quell- und Standbydatenbanken. ZDM verfügt über spezielle Funktionen für Verbindungen mit geringer Bandbreite und kann die Datenübertragung nach Netzwerkunterbrechungen fortsetzen.
    4. Diese Referenzarchitektur konzentriert sich auf den Teil der Datenbankmigration beim Verschieben des On-Premise-Anwendungsstacks in Oracle Cloud Infrastructure. Ihre Anwendungen verwenden möglicherweise Middleware- und Präsentationsschichtserver, die in der Regel von geringer Latenz mit den Datenbanken verbunden sind. Migrieren Sie also vor dem Wechsel zum Bare-Metal-DB-System in Oracle Cloud Infrastructure die Anwendungsserver.
    5. Wenn Sie zum Wechsel in die Cloud bereit sind, führen Sie mit ZDM ein Data Guard-Switchover aus und wechseln die Rolle der Datenbanken. Die On-Premise-Datenbank wird zum Standby, und das Bare-Metal-DB-System in Oracle Cloud Infrastructure wird zur primären Datenbank.
    6. Als letzten Schritt im Migrationsprozess beendet ZDM die Data Guard-Konnektivität zwischen der Quell- und Zieldatenbank und führt Bereinigungsvorgänge aus.

    Hinweis:

    Um die erforderliche Zeit für die Migration großer Datenbanken zu minimieren, verwenden Sie Oracle Cloud Infrastructure FastConnect.

Überlegungen

  • Skalierbarkeit
    • Application Tier

      Sie können die Anwendungsserver vertikal skalieren, indem Sie die Ausprägung der Compute-Instanzen ändern. Eine Ausprägung mit einer höheren Core-Anzahl bietet auch mehr Speicher und Netzwerkbandbreite. Wenn mehr Speicher erforderlich ist, erhöhen Sie die Größe der Block-Volumes, die an den Anwendungsserver angeschlossen sind.

    • Database Tier

      Sie können die Datenbank vertikal skalieren, indem Sie zusätzliche Cores aktivieren. Die Datenbank ist während der Skalierung weiterhin verfügbar. Wenn Sie den verfügbaren Speicher vergrößern, können Sie zu einem Exadata-DB-System migrieren.

  • Verfügbarkeit

    Faultdomains bieten die beste Resilienz für Workloads, die in einer einzelnen Availability-Domain bereitgestellt werden. Diese Architektur zeigt keine redundanten Ressourcen an, da der Schwerpunkt auf dem Migrationsansatz liegt. Für High Availability in der Anwendungsebene stellen Sie die Anwendungsserver in verschiedenen Faultdomains bereit und verwenden einen Load Balancer, um den Clientdatenverkehr auf die Anwendungsserver zu verteilen.

    Um High Availability der Datenbankebene zu gewährleisten, sollten Sie zu einem Exadata-DB-System migrieren.

  • Kostenfaktor
    • Application Tier

      Wählen Sie die Compute-Ausprägung basierend auf den Cores, dem Arbeitsspeicher und der Netzwerkbandbreite aus, die Ihre Anwendung benötigt. Sie können mit einer 4-Core-Ausprägung für den Anwendungsserver beginnen. Wenn Sie mehr Performance, Speicher oder Netzwerkbandbreite benötigen, können Sie zu einer größeren Ausprägung wechseln.

    • Database Tier

      Wenn Sie ein Bare-Metal-DB-System bereitstellen, erhalten Sie den gesamten Speicher und den Raw-Speicher, der mit dem Bare-Metal-Server verknüpft ist, unabhängig von der Anzahl der aktivierten Cores. Die Kosten hängen von der Anzahl der aktivierten Cores sowie von den gewählten Optionen und Management Packs ab.

Bereitstellen

Um diese Referenzarchitektur bereitzustellen, erstellen Sie die erforderlichen Ressourcen in Oracle Cloud Infrastructure und migrieren Sie die On-Premise-Datenbank dann mit Oracle Zero Downtime Migration.

  1. Erstellen Sie die erforderlichen Ressourcen in Oracle Cloud Infrastructure.

    Der Terraform-Code zur Bereitstellung der Ressourcen in der Cloud ist auf GitHub verfügbar. Mit dem Code können Sie die Netzwerkressourcen, eine Compute-Instanz, die Sie als Bastion oder für den Anwendungsserver verwenden können, und ein Bare-Metal-DB-System bereitstellen.

    Sie können den Code mit nur einem Klick in Oracle Cloud Infrastructure Resource Manager abrufen, den Stack erstellen und bereitstellen. Alternativ können Sie den Code von GitHub auf Ihren Computer herunterladen, den Code anpassen und die Architektur mit der Terraform-CLI bereitstellen.

    • Stellen Sie die Cloud-Ressourcen mit Oracle Cloud Infrastructure Resource Manager bereit:
      1. Klicken Sie auf In Oracle Cloud bereitstellen

        Wenn Sie noch nicht angemeldet sind, geben Sie den Mandanten und die Benutzerzugangsdaten ein.

      2. Prüfen und akzeptieren Sie die Vertragsbedingungen.
      3. Wählen Sie die Region aus, in der Sie den Stack bereitstellen möchten.
      4. Befolgen Sie die Prompts und Anweisungen zum Erstellen des Stacks auf dem Bildschirm.
      5. Nachdem Sie den Stack erstellt haben, klicken Sie auf Terraform-Aktionen, und wählen Sie Planen aus.
      6. Warten Sie, bis der Job abgeschlossen ist, und prüfen Sie den Plan.

        Um Änderungen vorzunehmen, kehren Sie zur Seite "Stackdetails" zurück, klicken Sie auf Stack bearbeiten, und nehmen Sie die erforderlichen Änderungen vor. Führen Sie anschließend die Aktion Planen erneut aus.

      7. Wenn keine weiteren Änderungen erforderlich sind, kehren Sie zur Seite "Stackdetails" zurück, klicken Sie auf Terraform-Aktionen, und wählen Sie Anwenden.
    • Stellen Sie die Cloud-Ressourcen mit der Terraform-CLI bereit:
      1. Gehen Sie zu GitHub.
      2. Laden Sie den Code auf Ihren lokalen Rechner herunter.
      3. Führen Sie die in der README beschriebenen erforderlichen Schritte durch.
      4. Wenden Sie die Konfiguration mit der Terraform-CLI an.
  2. Migrieren Sie die On-Premise-Datenbank mit Oracle Zero Downtime Migration.

Mehr anzeigen

Weitere Informationen zum Migrieren von On-Premise-Datenbanken in die Cloud.

Änderungslog

In diesem Log werden nur die wesentlichen Änderungen aufgeführt: