Geschäftskritische Anwendungen mit einer phasenweisen Strategie in Oracle Database@Azure migrieren

Migrieren Sie eine On-Premises-Datenbank und -Anwendung in die Cloud, um Ausfallzeiten mit schrittweisen oder hybriden Strategien zu minimieren und eine nahtlose Konnektivität für cloudbasierte Anwendungen zu On-Premises-Datenbanken sicherzustellen. Ein gut strukturierter Plan beschleunigt den Ausstieg aus dem Rechenzentrum, mindert Risiken und sorgt für Zuverlässigkeit. Ein hybrider, zweistufiger Ansatz ermöglicht einen reibungslosen Übergang bei gleichbleibender Stabilität.

Wenn Sie eine On-Premises-Datenbank und -Anwendung in die Cloud verschieben, müssen Sie verschiedene Herausforderungen bewältigen, um einen nahtlosen Übergang sicherzustellen. Wählen Sie eine Migrationsstrategie, die Ausfallzeiten minimiert, wie z. B. schrittweise Migration oder Hybrid-Cloud-Lösungen, um die Anwendungsverfügbarkeit aufrechtzuerhalten, insbesondere für kritische Geschäfts-Workloads. Stellen Sie sicher, dass Anwendungen, die sich bereits in der Cloud befinden und eine Verbindung zu On-Premise-Datenbanken herstellen, auch im Migrationsplan berücksichtigt werden, um Konnektivitätsprobleme zu vermeiden. Stellen Sie bei SaaS-Anwendungen, bei denen sich die App in der Cloud befindet, die Datenbank jedoch On Premise ist, eine umfassende Strategie sicher, die beide Komponenten umfasst. Bewältigen Sie diese Herausforderungen proaktiv, um einen reibungslosen Übergang sicherzustellen und die Zuverlässigkeit Ihrer kritischen Geschäftsanwendungen aufrechtzuerhalten. Eine gut strukturierte Strategie hilft Ihnen auch, den Austritt von Rechenzentren zu beschleunigen und Migrationsrisiken zu reduzieren, um die Zuverlässigkeit Ihrer kritischen Geschäftsanwendungen sicherzustellen.

Oracle Database@Azure beseitigt die Abhängigkeit von On-Premises-Exadata oder Oracle Real Application Clusters (Oracle RAC), indem die Datenbank den Anwendungs-Workloads in Microsoft Azure näher gebracht wird. Durch diese Integration können sowohl die Datenbank als auch die Anwendungen im selben Data Center gehostet werden. Dadurch wird die Latenz verringert und die Abhängigkeit von der physischen Infrastruktur minimiert.

Die Implementierung dieses Setups erfordert häufig eine sorgfältig konzipierte Lösung, um die Zielarchitektur einzurichten, ohne kritische Geschäftsabläufe zu unterbrechen. Viele geschäftskritische Workloads werden über mehrere Regionen hinweg bereitgestellt, um die Geschäftskontinuität durch Disaster Recovery oder Standbyumgebungen sicherzustellen. Dieser Ansatz unterstützt eine hybride, zweiphasige Migrationsstrategie, die nahtlose Übergänge bei gleichzeitiger Wahrung der Betriebsstabilität ermöglicht.

Bevor Sie beginnen

Bevor Sie beginnen, sollten Sie Folgendes berücksichtigen:

  • Deaktivieren Sie Fast-Start Failover in Oracle Data Guard, um einen reibungslosen und kontrollierten Übergang zwischen der Primär- und der Standbyregion während der Migration zu gewährleisten.
  • OCI Database Migration bietet validierte, versionsübergreifende, fehlertolerante und inkrementelle Oracle Database- und MySQL-Migrationen für Online- und Offline-Anwendungsfälle wie ZDM und OCI Migration.
  • Diese Referenzarchitektur folgt dem Oracle Gold Maximum Availability Architecture-(MAA-)Modell in einer Aktiv-Standby-Konfiguration mit regionsübergreifendem Deployment für verbesserte Resilienz. Diese Referenzarchitektur kann auf MAA Platin erweitert werden, wobei lokale High Availability durch synchrone Replikation mit Oracle Data Guard zwischen Verfügbarkeitszonen erreicht wird, während regionsübergreifendes Disaster Recovery mit asynchroner Replikation implementiert wird.

Architektur

Diese Architektur beschreibt einen schrittweisen Ansatz für die Migration von On-Premises-Oracle Database auf Oracle Exadata Database Service bei Oracle Database@Azure mit minimaler Ausfallzeit.

Um diese Strategie zu vereinfachen, unterteilen wir sie in drei Schlüsselaspekte: aktuelle Zustand, zukünftige Zustand und Migrationsphasen.

Diese Referenzarchitektur enthält vier Hauptkomponenten (im Diagramm mit blauen Zahlen markiert).
Nummer Komponente Beschreibung
1 Primäres On-Premises-Data-Center Hostet die Datenbank und die Anwendung vor der Migration als primäres System.
2 On-Premises-Standby-Rechenzentrum Verwaltet ein Standbysystem und repliziert die On-Premise-Primärdatenbank.
3 Primäre Azure-Region Führt die Anwendung und Datenbank auf Oracle Database@Azure aus und wird nach der Migration zum primären System.
4 Azure-Standbyregion Eine Disaster-Recovery-Site, die mit Oracle Data Guard die primäre Region repliziert.

Beschreibung von logical-architecture-diagram.png folgt
Beschreibung der Abbildung logical-architecture-diagram.png

logisch-Architektur-Diagramm-oracle.zip

Aktueller Status

Im vorhandenen Setup werden sowohl das primäre Data Center (1) als auch das Standby-Data Center (2) On Premise gehostet und unterstützen Anwendungs-Workloads und Datenbanken. Das primäre Data Center verarbeitet alle Anforderungen, während das Standby-Data Center die asynchrone Replikation mit Oracle Data Guard aufrechterhält. Dadurch wird High Availability sichergestellt, wobei das Standby-System bei unerwarteten Ausfällen für Failover bereit ist.

Zukünftiger Status

Die zukünftige Architektur spiegelt das aktuelle Setup wider, wird jedoch vollständig in der Cloud gehostet und umfasst zwei Azure-Regionen: die primäre Region (3) und die Standbyregion (4). Die Datenbank wird zu Oracle Database@Azure-Exadata-Services migriert. Dabei erfolgt eine asynchrone Replikation zwischen der Primär- und der Standbydatenbank, die über Oracle Data Guard über das Oracle Cloud Infrastructure-(OCI-)Netzwerk verwaltet wird.

Um eine sichere Verbindung zwischen dem On-Premise-Data Center und Azure zu gewährleisten, wird eine Azure-Firewall in einem sicheren virtuellen WAN-(vWAN-)Hub in Azure bereitgestellt.

Migrationsphasen

Die Migration folgt einem zweiphasigen Ansatz, um einen kontrollierten und zuverlässigen Übergang sicherzustellen.

Phase 1 – Übergang von On-Premise-Standbydatenbank zu Azure und Switchover

In dieser Phase wird das On-Premise-Standbysystem (2) zu Azure (3) migriert. Nach Abschluss werden die Rollen "Primär" (1) und "Standby" (3) ausgetauscht, sodass Azure zur neuen primären Region wird.

  1. Stellen Sie die Konnektivität zwischen On Premise und Azure mit Azure ExpressRoute her.
  2. Konfigurieren Sie den sicheren Azure-Hub, die Azure-Firewall und vWAN für die Sicherheit (sofern noch nicht geschehen).
  3. Stellen Sie Oracle Exadata Cloud Infrastructure in der primären Region von Azure bereit, und führen Sie dann folgende Schritte aus:
    1. Richten Sie ein Oracle Exadata-VM-Cluster ein, und erstellen Sie die Zieldatenbank.
    2. Aktivieren Sie Archive-Logs und erzwungenes Logging in der Primärdatenbank (sofern noch nicht aktiviert).
  4. Konfigurieren Sie Oracle Net für Listener und TNS-Namen für Discovery.
  5. Stellen Sie die Datenbank aus dem Service wieder her, um eine Standbydatenbank in der primären Region von Azure einzurichten (3).
  6. Führen Sie einen Switchover aus, und machen Sie die Azure-Datenbank (3) zur neuen Primärdatenbank.
  7. Migrieren Sie Anwendungen in die primäre Azure-Region (3), und aktualisieren Sie DNS-Routen.
  8. Prüfen Sie die Data Guard-Konfiguration, und überwachen Sie den Replikationsstatus.

Phase 2 – Standby in Azure einrichten und On Premise außer Betrieb nehmen

In dieser Phase wird ein Standby-System (4) in Azure eingerichtet, und On-Premise-Ressourcen (1 und 2) werden außer Betrieb genommen.

  1. Stellen Sie Oracle Exadata Cloud Infrastructure in der Standbyregion (4) mit Oracle Database@Azure bereit.
  2. Richten Sie ein Oracle Exadata-VM-Cluster ein, und erstellen Sie die Standbydatenbank.
  3. Aktivieren Sie Oracle Data Guard, um die Primärregionsdatenbank (3) mit der Standbydatenbank (4) zu verknüpfen.
  4. Verwenden Sie OCI-Networking für die Replikation mit hohem Durchsatz, indem Sie lokales und Remote-Peering innerhalb einer Hub-and-Spoke-Topologie zwischen der Primär- und der Standbydatenbank nutzen.
  5. Migrieren Sie Anwendungs-Workloads in die Azure-Standbydatenbankregion (4).
  6. Stoppen Sie die Synchronisierung mit den On-Premise-Ressourcen, und setzen Sie dann die On-Premise-Anwendungs- und Datenbankressourcen aus den primären (1) und Standby-(2-)Data Centern außer Betrieb.

Das folgende Diagramm veranschaulicht diese Referenzarchitektur.


Beschreibung von physical-architecture-diagram.png folgt
Beschreibung der Abbildung physical-architecture-diagram.png

Physikalische Architektur-Diagramm-oracle.zip

Microsoft Azure stellt die folgenden Komponenten bereit:

  • Azure-Region

    Eine Azure-Region ist ein geografisches Gebiet, in dem sich mindestens ein physisches Azure-Data Center, sogenannte Verfügbarkeitszonen, befindet. Regionen sind unabhängig von anderen Regionen, und große Entfernungen können sie trennen (über Länder oder sogar Kontinente).

    Azure- und OCI-Regionen sind lokalisierte geografische Bereiche. Bei Oracle Database@Azure ist eine Azure-Region mit einer OCI-Region verbunden, wobei Availability Zones (AZs) in Azure mit Availability-Domains (ADs) in OCI verbunden sind. Azure- und OCI-Regionspaare werden ausgewählt, um Entfernung und Latenz zu minimieren.

  • Azure-Verfügbarkeitszone

    Azure-Verfügbarkeitszonen sind physisch separate Standorte innerhalb einer Azure-Region, die durch unabhängige Stromversorgung, Kühlung und Vernetzung eine hohe Verfügbarkeit und Resilienz gewährleisten.

  • Azure VNet

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

  • Delegiertes Azure-Subnetz

    Die Subnetzdelegierung ist die Fähigkeit von Microsoft, einen verwalteten Service, insbesondere einen Platform-as-a-Service-(PaaS-)Service, direkt in Ihr virtuelles Netzwerk zu injizieren. Auf diese Weise können Sie ein Subnetz als Home für einen externen verwalteten Service in Ihrem virtuellen Netzwerk festlegen oder delegieren, sodass der externe Service als virtuelle Netzwerkressource fungiert, obwohl es sich um einen externen PaaS-Service handelt.

  • Azure-VNIC

    Die Dienste in Azure-Rechenzentren verfügen über physische Netzwerkkarten (NICs). Virtual-Machine-Instanzen kommunizieren über virtuelle NICs (VNICs), die mit den physischen NICs verknüpft sind. Jede Instanz verfügt über eine primäre VNIC, die beim Start automatisch erstellt und angehängt wird und während der Lebensdauer der Instanz verfügbar ist.

  • Azure Virtual Network Gateway

    Das Azure Virtual Network Gateway stellt eine sichere, standortübergreifende Konnektivität zwischen einem virtuellen Azure-Netzwerk und einem On-Premises-Netzwerk her. Es ermöglicht Ihnen, ein Hybridnetzwerk zu erstellen, das Ihr Rechenzentrum und Azure umfasst.

  • Azure Virtual WAN

    Microsoft Azure Virtual WAN (VWAN) ist ein Netzwerkservice, der viele Netzwerk-, Sicherheits- und Routingfunktionen zusammenführt, um eine einzige betriebliche Schnittstelle bereitzustellen.

  • Azure Secure Hub

    Ein sicherer Azure-Hub, auch als gesicherter virtueller Hub bezeichnet, ist ein Azure Virtual WAN-Hub, der durch Sicherheits- und Routingrichtlinien, die von Azure Firewall Manager verwaltet werden, erweitert wird. Es vereinfacht die Erstellung von Hub-and-Spoke- und transitiven Netzwerkarchitekturen, indem native Sicherheitsservices für Traffic Governance und Schutz integriert werden. Durch dieses Setup wird das Traffic-Routing automatisiert, sodass keine benutzerdefinierten Routen (UDRs) erforderlich sind. Unternehmen können einen sicheren Hub verwenden, um den Datenverkehr zwischen virtuellen Netzwerken, Niederlassungen und dem Internet zu filtern und zu sichern, um robuste Sicherheit und eine optimierte Netzwerkverwaltung zu gewährleisten.

  • Azure-Firewallmanager

    Azure Firewall Manager ist ein zentralisierter Sicherheitsmanagementservice, der die Bereitstellung und Konfiguration der Azure Firewall über mehrere Regionen und Abonnements hinweg vereinfacht. Sie ermöglicht ein hierarchisches Policy-Management, sodass globale und lokale Firewall-Policys konsistent angewendet werden können. Bei der Integration mit Azure Virtual WAN (vWAN) und einem sicheren Hub erhöht Azure Firewall Manager die Sicherheit, indem Traffic-Routing und -Filterung automatisiert werden, ohne dass benutzerdefinierte Routen (UDRs) erforderlich sind. Diese Integration stellt sicher, dass der Datenverkehr zwischen virtuellen Netzwerken, Zweigstellen und dem Internet sicher verwaltet und überwacht wird, und bietet eine robuste und optimierte Netzwerksicherheitslösung.

  • Azure ExpressRoute

    Azure ExpressRoute ist ein Service, der private Verbindungen zwischen On-Premise-Data Centern und Microsoft Azure ermöglicht und das öffentliche Internet umgeht. Dies führt zu höherer Sicherheit, Zuverlässigkeit und schnelleren Geschwindigkeiten mit konsistenten Latenzen. ExpressRoute-Verbindungen können über einen Konnektivitätsprovider mit verschiedenen Methoden wie Point-to-Point-Ethernet, Any-to-any (IP-VPN) oder virtuellen Crossconnections hergestellt werden. Bei der Integration in On-Premises-Data-Center ermöglicht ExpressRoute eine nahtlose Erweiterung Ihres Netzwerks in die Cloud und erleichtert Hybrid-Cloud-Szenarien, Disaster Recovery und Datenmigration mit verbesserter Performance und Sicherheit.

Oracle Cloud Infrastructure stellt die folgenden Komponenten bereit:

  • Region

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

  • Availability-Domain

    Availability-Domains sind eigenständige, unabhängige Data Center innerhalb einer Region. Die physischen Ressourcen in jeder Availability-Domain sind von den Ressourcen in den anderen Availability-Domains isoliert, was eine Fehlertoleranz sicherstellt. Availability-Domains haben keine gemeinsame Infrastruktur wie Stromversorgung oder Kühlung oder das interne Availability-Domainnetzwerk. Ein Fehler in einer Availability-Domain sollte sich also nicht auf die anderen Availability-Domains in der Region auswirken.

  • Virtuelles Cloud-Netzwerk (VCN) und Subnetz

    Ein VCN ist ein anpassbares, softwaredefiniertes Netzwerk, das Sie in einer Oracle Cloud Infrastructure-Region einrichten. Wie herkömmliche Data Center-Netzwerke erhalten Sie mit VCNs die 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.

  • Routentabelle

    Virtuelle Routentabellen enthalten Regeln zum Weiterleiten von Traffic von Subnetzen an Ziele außerhalb eines VCN, in der Regel über Gateways.

  • Sicherheitsliste

    Für jedes Subnetz können Sie Sicherheitsregeln erstellen, die Quelle, Ziel und Typ des Traffics angeben, der in und aus dem Subnetz zulässig ist.

  • Netzwerksicherheitsgruppe (NSG)

    NSGs fungieren als virtuelle Firewalls für Ihre Cloud-Ressourcen. Mit dem Zero-Trust-Sicherheitsmodell von Oracle Cloud Infrastructure steuern Sie den Netzwerktraffic in einem VCN. Eine NSG besteht aus einer Gruppe von Ingress- und Egress-Sicherheitsregeln, die nur für eine bestimmte Gruppe von VNICs in einem einzelnen VCN gelten.

  • Oracle Database Autonomous Recovery Service

    Oracle Database Autonomous Recovery Service ist ein Oracle Cloud-Service, der Oracle-Datenbanken schützt. Mit Backupautomatisierung und erweiterten Datenschutzfunktionen für OCI-Datenbanken können Sie alle Backupverarbeitungs- und Speicheranforderungen an Oracle Database Autonomous Recovery Service auslagern, was die Kosten der Backupinfrastruktur und den manuellen Administrationsaufwand reduziert.

  • Exadata Database Service

    ermöglicht es Ihnen, die Leistungsfähigkeit von Exadata in der Cloud zu nutzen. Oracle Exadata Database Service bietet bewährte Oracle Database-Funktionen auf einer speziell entwickelten, optimierten Oracle Exadata-Infrastruktur in der Public Cloud. Dank integrierter Cloud-Automatisierung, elastischer Ressourcenskalierung, Sicherheit und schneller Performance für alle Oracle Database-Workloads können Sie die Verwaltung vereinfachen und Kosten senken.

  • Oracle Database@Azure

    Oracle Database@Azure ist der auf Oracle Cloud Infrastructure (OCI) ausgeführte Oracle Database-Service (Oracle Exadata Database Service on Dedicated Infrastructure und Oracle Autonomous Database Serverless), der in Microsoft Azure-Data Centern bereitgestellt wird. Der Service bietet Features und Preisparität mit OCI. Erwerben Sie den Service im Azure Marketplace.

    Oracle Database@Azure integriert die Technologien Oracle Exadata Database Service, Oracle Real Application Clusters (Oracle RAC) und Oracle Data Guard in die Azure-Plattform. Benutzer verwalten den Service auf der Azure-Konsole und mit Azure-Automatisierungstools. Der Service wird im virtuellen Azure-Netzwerk (VNet) bereitgestellt und in das Identitäts- und Zugriffsverwaltungssystem von Azure integriert. Die generischen Metriken und Auditlogs von OCI und Oracle Database sind nativ in Azure verfügbar. Für den Service müssen Benutzer über ein Azure-Abonnement und einen OCI-Mandanten verfügen.

    Autonomous Database basiert auf der Oracle Exadata-Infrastruktur und ist selbstverwaltend, selbstsichernd und selbstreparierend, wodurch manuelle Datenbankverwaltung und menschliche Fehler vermieden werden. Autonomous Database ermöglicht die Entwicklung skalierbarer KI-gestützter Apps mit beliebigen Daten mithilfe integrierter KI-Funktionen unter Verwendung des LLM-Modells (Großsprache) und des Bereitstellungsorts Ihrer Wahl.

    Sowohl Oracle Exadata Database Service als auch Oracle Autonomous Database Serverless können einfach über das native Azure-Portal bereitgestellt werden, um den Zugriff auf das breitere Azure-Ökosystem zu ermöglichen.

  • Data Guard

    Oracle Data Guard und Oracle Active Data Guard stellen ein umfassendes Set von Services bereit, mit denen eine oder mehrere Standbydatenbanken erstellt, gewartet, verwaltet und überwacht werden und Oracle-Produktionsdatenbanken ohne Unterbrechung verfügbar bleiben können. Oracle Data Guard verwaltet diese Standbydatenbanken mit In-Memory-Replikation als Kopien der Produktionsdatenbank. Wenn die Produktionsdatenbank aufgrund eines geplanten oder ungeplanten Ausfalls nicht verfügbar ist, kann Oracle Data Guard jede Standbydatenbank in die Produktionsrolle umschalten, wodurch die Ausfallzeit im Zusammenhang mit dem Ausfall minimiert wird. Oracle Active Data Guard bietet die zusätzliche Möglichkeit, Workloads, die hauptsächlich gelesen werden, in Standbydatenbanken auszulagern, und bietet außerdem erweiterte Datenschutzfunktionen.

  • Lokales Peering

    Mit lokalem Peering können Sie ein VCN mit einem anderen VCN in derselben Region verknüpfen. Peering bedeutet, dass die VCNs über private IP-Adressen kommunizieren, ohne dass der Traffic über das Internet oder das On-Premise-Netzwerk geleitet wird.

  • Remote-Peering

    Mit Remote-Peering können Ressourcen in verschiedenen VCNs über private IP-Adressen kommunizieren. Mit Remote-Peering ist kein Internetgateway oder keine öffentlichen IP-Adressen für Instanzen erforderlich, die mit einem anderen VCN in einer anderen Region kommunizieren müssen.

  • Hub - virtuelles Cloud-Netzwerk

    Ein virtuelles Cloud-Hubnetzwerk (VCN) dient als zentraler Punkt für die Verwaltung und Weiterleitung des Traffics zwischen mehreren VCNs, sowohl innerhalb derselben Region als auch über verschiedene Regionen hinweg. Mit lokalen Peering-Gateways (LPGs) stellt das Hub-VCN eine Verbindung zu mehreren Spoke-VCNs in derselben Region her und erleichtert so eine effiziente Kommunikation und zentralisierte Verwaltung. Für regionsübergreifende Konnektivität werden Remote-Peering-Gruppen (RPGs) verwendet, bei denen jedes VCN an ein dynamisches Routinggateway (DRG) anhängt und Remote-Peering-Verbindungen (RPCs) herstellt. Dieses Setup eignet sich besonders für das Routing von Oracle Data Guard-Traffic. Dadurch wird sichergestellt, dass Redo-Logs und andere Synchronisierungsdaten effizient von der Primärdatenbank in einer Region an die Standbydatenbank in einer anderen Region übertragen werden. Dadurch wird die Datenkonsistenz und High Availability gewahrt.

Das On-Premise-System verfügt über die folgenden Komponenten:

  • Primäres Rechenzentrum

    Ein On-Premises-Data-Center, das Anwendungen hostet, und eine Oracle-Datenbank dienen als primärer Standort für Geschäftsvorgänge und stellen so hohe Performance und Datenverfügbarkeit sicher. Um die Disaster Recovery und die Geschäftskontinuität zu verbessern, ist dieses primäre Data Center mit einem Standby-Data Center verknüpft, das sich häufig in einer anderen geografischen Region befindet. Das Standby-Data Center verwaltet eine synchronisierte Kopie der Oracle-Datenbank mit Oracle Data Guard, die kontinuierlich Änderungen von der Primärdatenbank in die Standbydatenbank repliziert. Im Falle eines Ausfalls oder einer Katastrophe am primären Standort kann das Standby-Data Center schnell übernehmen, Ausfallzeiten und Datenverlust minimieren und so einen unterbrechungsfreien Geschäftsbetrieb sicherstellen.

  • Standby-Data Center

    Ein Standby-Rechenzentrum ist eine wichtige Komponente einer Disaster Recovery-Strategie, die darauf ausgelegt ist, die Geschäftskontinuität unter unvorhergesehenen Bedingungen sicherzustellen. Es hostet ein Replikat der Primäranwendungen und Oracle Database, das über Technologien wie Oracle Data Guard synchron gehalten wird. Im Falle eines Ausfalls oder einer Katastrophe im primären Rechenzentrum kann das Standby-Rechenzentrum den Betrieb nahtlos übernehmen und Ausfallzeiten und Datenverlust minimieren. Dieses Setup stellt sicher, dass die Geschäftsprozesse weiterhin reibungslos laufen, bietet Resilienz gegen Unterbrechungen und behält die Serviceverfügbarkeit für Benutzer und Kunden bei.

  • Datenbank

    Eine Oracle-Datenbank, die in einem On-Premises-Data-Center gehostet wird, spielt eine entscheidende Rolle bei der Speicherung und Verwaltung von Geschäftsdaten. Es bietet eine sichere, leistungsstarke Umgebung für den Umgang mit kritischen Geschäftsvorgängen und stellt die Datenintegrität und -verfügbarkeit sicher. Mit diesem Setup können Unternehmen die vollständige Kontrolle über ihre Dateninfrastruktur behalten, Konfigurationen an spezifische Anforderungen anpassen und gesetzliche Anforderungen erfüllen. Durch die Nutzung der robusten Datenbankfeatures von Oracle können Unternehmen Transaktionen effizient verarbeiten, Berichte generieren und Entscheidungsprozesse unterstützen.

  • Anwendungen

    Anwendungen, die in einem On-Premises-Data-Center auf einer Oracle Datenbank ausgeführt werden, sind für den Geschäftsbetrieb von wesentlicher Bedeutung. Diese Anwendungen nutzen die robuste und zuverlässige Oracle Datenbank, um Transaktionen zu verarbeiten, Kundendaten zu verwalten und wichtige Geschäftseinblicke zu generieren. Durch den Betrieb in einer sicheren und kontrollierten Umgebung gewährleisten sie hohe Leistung, Datenintegrität und die Einhaltung gesetzlicher Standards. Mit diesem Setup können Unternehmen ihre Infrastruktur an spezifische Anforderungen anpassen und so eine stabile Grundlage für den täglichen Betrieb und die strategische Entscheidungsfindung schaffen.

Empfehlungen

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

Performance

Für die Disaster Recovery-(DR-)Replikation wird dringend ein OCI-Netzwerk empfohlen. Die leistungsstarke Netzwerkinfrastruktur von OCI gewährleistet Konnektivität mit geringer Latenz und hoher Bandbreite, die für eine effiziente Datenreplikation und Synchronisierung zwischen der Primär- und der Standbydatenbank unerlässlich ist. Die Nutzung des OCI-Netzwerks für Oracle Data Guard mit Oracle Database@Azure bietet erhebliche Vorteile in Bezug auf Performance, Sicherheit und Zuverlässigkeit.

Dieses Setup stärkt die DR, indem es eine schnelle und sichere Übertragung von Redo-Logs und kritischen Daten ermöglicht und Datenverlust und Ausfallzeiten bei Failover-Szenarien minimiert. Darüber hinaus bieten die integrierten Sicherheitsfunktionen von OCI, einschließlich Netzwerkverschlüsselung und erweiterter Zugriffskontrollen, einen robusten Schutz für sensible Daten.

Durch die Integration von OCI-Netzwerken in Oracle Database@Azure können Unternehmen eine nahtlose, resiliente und hochverfügbare Datenbankarchitektur erreichen, die die Geschäftskontinuität und betriebliche Effizienz verbessert.

Hinweise

Beachten Sie beim Deployment dieser Referenzarchitektur die folgenden Punkte:

  • Geschäftskontinuität

    Durch die Integration von Oracle Database Autonomous Recovery Service in Oracle Data Guard wird eine umfassende und resiliente Datenschutzstrategie für die Einrichtung von Primär- und Standbydatenbanken erstellt. Oracle Data Guard stellt High Availability und Disaster Recovery sicher, indem eine synchronisierte Standbydatenbank verwaltet wird, die bei einem Ausfall der Primärdatenbank übernommen werden kann. Dadurch werden Ausfallzeiten und Datenverlust minimiert.

    Darüber hinaus bietet Oracle Database Autonomous Recovery Service eine vollständig verwaltete, zentralisierte Backuplösung ohne Datenschutz und Echtzeitwiederherstellungsfunktionen. Diese Kombination gewährleistet kontinuierlichen Datenschutz durch Echtzeitreplikation und robuste Backupmechanismen, wodurch die Datenintegrität und die Geschäftskontinuität verbessert werden.

  • Verfügbarkeit

    Durch das Deployment mehrerer Oracle Database-Instanzen in verschiedenen Verfügbarkeitszonen (AZs) in einer Region sowie Active Data Guard werden High Availability- und Disaster Recovery-Funktionen erheblich verbessert. AZs sind voneinander isoliert und stellen sicher, dass Fehler in einem nicht auf andere wirken. Durch die Verteilung von Datenbankinstanzen auf mehrere AZs können Unternehmen Risiken im Zusammenhang mit lokalisierten Ausfällen wie Stromausfällen oder Hardwareproblemen mindern.

    Active Data Guard stärkt dieses Setup weiter, indem ein synchronisiertes Echtzeitreplikat der Primärdatenbank verwaltet wird, sodass bei einem Ausfall der Primärinstanz ein nahtloser Failover möglich ist. Dieser Ansatz gewährleistet kontinuierlichen Datenschutz, minimale Ausfallzeiten und eine robuste Disaster Recovery-Strategie, die eine robuste Infrastruktur für geschäftskritische Anwendungen bereitstellt.

  • Durchsatz

    Bei der Migration von Datenbanken von On-Premises zu Azure ist es wichtig, die Bandbreite von Azure ExpressRoute zu berücksichtigen, um eine reibungslose und effiziente Übertragung sicherzustellen. Beispiel: Wenn Sie eine kleine Datenbank mit 100 GB migrieren, kann ein 200 Mbps-ExpressRoute-Circuit die Übertragung in etwa 1 Stunde und 10 Minuten verarbeiten, wobei optimale Bedingungen und kein Overhead vorausgesetzt werden. Bei einer größeren Datenbank mit 1 TB würde derselbe 200 Mbps-Circuit jedoch etwa 11 Stunden und 40 Minuten dauern. Ein Upgrade auf eine 1-Gbit/s-Schaltung würde diese Zeit erheblich auf etwa 2 Stunden und 20 Minuten reduzieren. Planen Sie entsprechend, damit die gesamte Bandbreite nicht verbraucht wird. Andernfalls können andere Anwendungen, die zwischen On Premise und Cloud kommunizieren, beeinträchtigt werden.

Mehr erfahren

Weitere Informationen zu Oracle Database und zugehörigen Tools finden Sie in den folgenden Ressourcen.

Prüfen Sie diese Deployment-Ressourcen, um diese Referenzarchitektur zu implementieren:

Prüfen Sie diese zusätzlichen Ressourcen:

Danksagungen

  • Autoren: Neeraj Tyagi, Thomas Van Buggenhout
  • Mitwirkende: Emiel Ramakers, John Sulyok