Hybride DR-Lösung für Oracle SOA Suite konfigurieren

Um die Geschäftskontinuität bei Katastrophen sicherzustellen, möchten Sie eine Disaster-Recovery-(DR-)Strategie für Ihre On-Premise-Oracle SOA Suite implementieren, die Datenschutz bietet und Ihnen den schnellen Wechsel zum Standbysystem mit minimalem Datenverlust und minimaler Produktivität ermöglicht. In dieser Lösung wird gezeigt, wie Sie eine Hybrid-DR-Strategie für ein vorhandenes SOA-System konfigurieren, das On Premise ist und auf Oracle Cloud Infrastructure (OCI) das Standbysystem ist. Mit Oracle Data Guard bietet diese DR-Lösung eine hochverfügbare, sichere und skalierbare Infrastruktur und Services , mit denen Sie von Katastrophen zuverlässig und sicher wiederherstellen können.

Bevor Sie beginnen

Bevor Sie mit dem Deployment einer Hybrid Disaster Recovery-(DR-)Lösung für das Oracle SOA Suite-System beginnen, stellen Sie sicher, dass Sie mit den High Availability-Best Practices für Netzwerk, Speicher und Host vertraut sind, die für On-Premise-Oracle WebLogic Server-Systeme eingerichtet sind.

Das in diesem Dokument verwendete Oracle WebLogic Server-System ist eine High Availability-Umgebung, die gemäß den Best Practices für MAA-Standards konfiguriert wurde, die im Enterprise Deployment Guide for Oracle SOA Suite (EDG) for Fusion Middleware Systems beschrieben sind. Obwohl nicht alle Szenarios genau dieser Topologie folgen, werden viele verschiedene Komponenten und Kombinationen behandelt, häufig in großen Deployments verwendet und High Availability-Empfehlungen implementiert, die vor dem Deployment eines Disaster Recovery-(DR-)Systems angewendet werden sollten. Daher wird es als das beste Referenzbeispiel für ein Primärsystem für eine hybride DR-Lösung für Oracle WebLogic Server betrachtet. Davon ausgehend wird dringend empfohlen, sich mit den Best Practices für High Availability und Enterprise-Deployment von Oracle WebLogic Server für Netzwerk-, Speicher- und Hostsetup vertraut zu machen, bevor Sie ein Hybridsystem bereitstellen.

Weitere Informationen finden Sie unter:

• Oracle Fusion Middleware High Availability Guide
• Oracle Fusion Middleware Enterprise Deployment Guide für Oracle SOA Suite
• Oracle Fusion Middleware Enterprise Deployment-Anleitungen in MAA Best Practices - Oracle Fusion Middleware

Stellen Sie sicher, dass Sie auch mit den Konzepten und der Administration von Oracle Cloud Infrastructure vertraut sind.

Architektur

Diese Architektur zeigt die primäre On-Premise-Data-Center-Umgebung mit einem Standbysystem auf Oracle Cloud Infrastructure (OCI). Verwenden Sie diese Architektur für eine Hybrid Disaster Recovery-(DR-)Lösung für Ihre On-Premise-Oracle SOA Suite-Umgebung.

Das primäre System ist ein Oracle SOA Suite-System, das sich On Premise befindet. Das Standbysystem wird in einem OCI-Mandanten neu erstellt, der Oracle Cloud Infrastructure FastConnect (oder Site-to-Site-VPN) für die Verbindung mit der On-Premise-Umgebung verwendet.

Die Middle Tier auf OCI wird erstellt, indem SOA auf OCI Virtual Machines (VMs) und keine Oracle SOA Cloud Service- oder Oracle SOA Suite on Marketplace-Instanz installiert wird (es gibt Einschränkungen bei BS-Versionen, BS-Benutzern und Verzeichnisstruktur, die verhindern, dass die Oracle SOA Cloud Service- oder Oracle SOA Suite on Marketplace-Instanz ordnungsgemäß als Standby für ein On-Premise-System funktioniert).

Die Datenbankebene auf der OCI-Site ist ein Oracle Real Application Clusters-(Oracle RAC-)DB-System.

Beschreibung der Abbildung maa-soa-hybrid-dr.png

maa-soa-hybrid-dr-oracle.zip

Diese Architektur unterstützt die folgenden Komponenten im primären On-Premise-Data Center:

• On-Premise-Netzwerk

  Dieses Netzwerk ist das von Ihrer Organisation verwendete lokale Netzwerk. Es ist einer der Speichen der Topologie.

• Load Balancer

  Bietet automatisierte Trafficverteilung von einem einzigen Einstiegspunkt auf mehrere Server im Backend.

• Oracle SOA Suite

  Die SOA-Umgebung wird gemäß dem Standard-Enterprise Deployment Guide for Oracle SOA Suite (EDG) konfiguriert. Diese Topologie deckt viele verschiedene Komponenten ab, die häufig in großen Deployments verwendet werden, und implementiert High Availability-Empfehlungen, die vor dem Deployment eines DR-Systems angewendet werden sollten.

• Oracle Real Application Clusters (Oracle RAC)

  Mit Oracle RAC können Sie eine einzelne Oracle Database auf mehreren Servern ausführen, um die Verfügbarkeit zu maximieren und die horizontale Skalierbarkeit zu aktivieren und gleichzeitig auf Shared Storage zuzugreifen. Benutzersessions, die sich bei Oracle RAC-Instanzen anmelden, können bei Ausfällen Failover ausführen und Änderungen sicher wiedergeben, ohne dass Änderungen an Endbenutzeranwendungen vorgenommen werden und die Auswirkungen der Ausfälle von Endbenutzern verborgen werden.

Diese Architektur unterstützt die folgenden Komponenten in der sekundären Standbyumgebung auf OCI:

• Region

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

• Virtuelles Cloud-Netzwerk (VCN) und Subnetz

  Ein VCN ist ein anpassbares, softwaredefiniertes Netzwerk, das Sie in einer Oracle Cloud Infrastructure-Region einrichten. Wie bei traditionellen Data Center-Netzwerken erhalten Sie mit VCNs die vollständige 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 einer Region oder einer Availability-Domain zugeordnet werden können. Jedes Subnetz besteht aus einem fortlaufenden Adressbereich, der sich mit den anderen Subnetzen im VCN nicht überschneidet. Sie können die Größe eines Subnetzes nach der Erstellung ändern. Ein Subnetz kann öffentlich oder privat sein.

  Private Subnetze werden aus Sicherheitsgründen allgemein empfohlen, es sei denn, die Ressource muss über das öffentliche Internet zugänglich sein (wenn über das öffentliche Internet auf einen Load Balancer zugegriffen wird, muss er sich in einem öffentlichen Subnetz befinden).

• Dynamisches Routinggateway (DRG)

  Das DRG ist ein virtueller Router, der einen Pfad für privaten Netzwerkverkehr 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, ein On-Premise-Netzwerk oder ein Netzwerk in einem anderen Cloud-Provider.

• FastConnect

  Mit Oracle Cloud Infrastructure FastConnect können Sie ganz einfach eine dedizierte, private Verbindung zwischen Ihrem Data Center und Oracle Cloud Infrastructure erstellen. FastConnect bietet im Vergleich zu Internet-basierten Verbindungen Optionen mit höherer Bandbreite und eine zuverlässigere Netzwerkerfahrung.

• Sicherheitsliste

  Für jedes Subnetz können Sie Sicherheitsregeln erstellen, die Quelle, Ziel und Traffictyp angeben, der in das und aus dem Subnetz zugelassen werden muss.

• Routentabelle

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

• Load Balancer

  Der Oracle Cloud Infrastructure Load Balancing-Service ermöglicht automatisierte Trafficverteilung von einem einzelnen Entry Point zu mehreren Servern im Backend.

• Cloud Guard

  Mit Oracle Cloud Guard können Sie die Sicherheit Ihrer Ressourcen in Oracle Cloud Infrastructure überwachen und verwalten. Cloud Guard verwendet Detektorrezepte, die Sie definieren können, um Ihre Ressourcen auf Sicherheitslücken zu untersuchen und Operatoren und Benutzer auf bestimmte riskante Aktivitäten zu überwachen. Wenn eine Fehlkonfiguration oder unsichere Aktivität erkannt wird, empfiehlt Cloud Guard Korrekturmaßnahmen und unterstützt Sie bei der Ausführung dieser Aktionen basierend auf den Responder-Rezepten, die Sie definieren können.

• DB-System

  Oracle Database System ist ein Oracle Cloud Infrastructure-(OCI-)Datenbankservice, mit dem Sie Oracle-Datenbanken mit vollem Funktionsumfang erstellen, skalieren und verwalten können. Das DB-System verwendet OCI Block Volumes-Speicher anstelle von lokalem Speicher und kann Oracle Real Application Clusters (Oracle RAC) ausführen, um die Verfügbarkeit zu verbessern.

• Oracle Cloud Infrastructure File Storage-Service

  Oracle Cloud Infrastructure File Storage Service stellt ein dauerhaftes, skalierbares und sicheres Netzwerkdateisystem der Unternehmensklasse bereit. Sie können über jede Bare-Metal-, VM- oder Containerinstanz in Ihrem virtuellen Cloud-Netzwerk (VCN) eine Verbindung mit einem File Storage Service-Dateisystem herstellen. File Storage Service unterstützt das Network File System Version 3.0-(NFSv3-)Protokoll. Der Service unterstützt das Network Lock Manager-(NLM-)Protokoll zur Dateisperrung.

  Oracle Cloud Infrastructure File Storage verwendet 5-fach replizierten Speicher, der in verschiedenen Faultdomains gespeichert ist, um Redundanz für resilienten Datenschutz bereitzustellen. Daten werden durch die Löschungscodierung geschützt. File Storage Service erfüllt die Anforderungen von Anwendungen und Benutzern, die ein Unternehmensdateisystem für verschiedenste Anwendungsfälle benötigen.

• Oracle Cloud Infrastructure Block Volumes

  Mit dem Service Oracle Cloud Infrastructure Block Volumes können Sie Blockspeicher-Volumes dynamisch bereitstellen und verwalten. Sie können Volumes erstellen, anhängen, verbinden und verschieben sowie die Volume-Performance gegebenenfalls ändern, um Ihre Speicher-, Performance- und Anwendungsanforderungen zu erfüllen. Nachdem Sie ein Volume an eine Instanz angehängt und damit verbunden haben, können Sie es wie eine herkömmliche Festplatte verwenden.

• Oracle RAC-DB-System

  Mit Oracle Real Application Clusters (Oracle RAC) können Kunden eine einzelne Oracle Database über mehrere Server hinweg ausführen, um die Verfügbarkeit zu maximieren und die horizontale Skalierbarkeit beim Zugriff auf Shared Storage zu ermöglichen. Benutzersessions, die sich bei Oracle RAC-Instanzen anmelden, können bei Ausfällen Failover ausführen und Änderungen sicher wiedergeben, ohne dass Änderungen an Endbenutzeranwendungen vorgenommen werden und die Auswirkungen der Ausfälle von Endbenutzern verborgen werden. Das Oracle RAC High Availability Framework hält die Service-Verfügbarkeit aufrecht, indem es die Konfigurationsinformationen für die einzelnen Services in Oracle Cluster Registry (OCR) speichert.

  Das Oracle RAC-DB-System befindet sich auf der Datenbankebene.

• Data Guard

  Oracle Data Guard umfasst ein umfangreiches Set von Services, mit denen Sie eine oder mehrere Standby-Datenbanken erstellen, verwalten und überwachen können, damit Oracle-Produktionsdatenbanken ohne Unterbrechung verfügbar bleiben können. Diese Standbydatenbanken werden von Oracle Data Guard als Kopien der Produktionsdatenbank verwaltet. Wenn die Produktionsdatenbank aufgrund eines geplanten oder ungeplanten Ausfalls nicht verfügbar ist, kann Oracle Data Guard jede Standbydatenbank auf die Produktionsrolle umschalten und so die mit dem Ausfall verbundene Ausfallzeit minimieren.

Topologiebeschreibung

Die Oracle SOA Suite Hybrid-DR-Topologie verwendet ein Active/Passive-Modell. Das primäre System befindet sich in einem On-Premise-Data Center, und das sekundäre System befindet sich auf Oracle Cloud Infrastructure (OCI). Die On-Premise- und OCI-Netzwerke sind mit Oracle Cloud Infrastructure FastConnect (bevorzugt) oder Site-to-Site-VPN verbunden.

In der db-Tier werden die primären und sekundären Datenbanken mit Oracle Data Guard konfiguriert. Mit Oracle Data Guard werden alle Änderungen, die auf die primäre Datenbank angewendet werden, in der sekundären (Standby-)Datenbank repliziert.

Die sekundäre Mid-Tier ist auf OCI Virtual Machines (VMs) installiert. Die Oracle Fusion Middleware-Binärdateien und die SOA-Domain sind ein Replikat der Binärdateien und der SOA-Domain der Primärdatenbank, wobei Oracle Cloud Infrastructure File Storage als Netzwerkdateisystemlösung verwendet wird, und Oracle Cloud Infrastructure Block Volumes als Knotenlösung für das private Zugriffsdateisystem. Die Hostnamen-Aliasnamen der Primärdatenbank werden auch als Listener-Adressen der WebLogic-Server in der sekundären Umgebung verwendet. Im sekundären Verzeichnis werden die Hostnamen-Aliasnamen durch die IP-Adressen der sekundären Hosts aufgelöst.

Die Web-Tier im primären Data Center folgt dem Enterprise Deployment Guide (EDG)-Modell mit zwei Oracle HTTP Server-Hosts und einem Load Balancer (LBR). Dieselbe Topologie wird im Sekundärsystem mit einem OCI Load Balancer und auf OCI-Compute-Instanzen installierten Oracle HTTP Server-Hosts bereitgestellt. Im sekundären System können Sie die Webschicht alternativ nur mit einem OCI Load Balancer implementieren, der die meisten Features bereitstellt, die für die Unternehmens-Deployment-Topologie erforderlich sind. In diesem Dokument sind beide Optionen enthalten, nur OCI Load Balancer- oder OCI Load Balancer- und Oracle HTTP Server-Hosts.

Eine eindeutige Frontend-Adresse wird für den Zugriff auf die im System ausgeführten Anwendungen konfiguriert. Der virtuelle Frontend-Name verweist auf die IP des Load Balancers auf der primären Site. Bei einem Switchover wird der Frontend-Name in DNS aktualisiert, sodass er auf die IP des OCI Load Balancers auf der sekundären Site verweist. Er muss immer auf die Load Balancer-IP der Site mit der primären Rolle verweisen.

Während des normalen Geschäftsbetriebs ist die Standbydatenbank eine physikalische Standbydatenbank. Ist entweder im Mount-Status oder wird im schreibgeschützten Modus geöffnet, wenn Active Data Guard verwendet wird. Die Standbydatenbank empfängt und wendet redo von der Primärdatenbank an, kann jedoch nicht im Lese-/Schreibmodus geöffnet werden. Oracle Data Guard repliziert die Informationen in der Datenbank automatisch auf der sekundären Site, einschließlich Server Oriented Architecture-(SOA-)Schemas, Oracle Platform Security Services-Informationen, benutzerdefinierten Schemas, Transaktionslogs (TLOGs), persistenten Java Database Connectivity-(JDBC-)Speichern und mehr.

Während des in diesem Dokument beschriebenen DR-Setups und der Lebenszyklusvalidierung können Sie die Standbydatenbank von einer physischen Standbydatenbank in eine Snapshot-Standbydatenbank konvertieren, um die sekundäre Site zu validieren, ohne einen vollständigen Switchover auszuführen. Eine Datenbank im Snapshot Standby-Modus ist eine vollständig aktualisierbare Datenbank. Eine Snapshot-Standbydatenbank empfängt und archiviert die redo-Daten, die von einer Primärdatenbank empfangen wurden, jedoch nicht. Alle auf eine Snapshot Standby-Datenbank angewendeten Änderungen werden verworfen, wenn sie in eine physische Standby-Datenbank konvertiert wird.

Die Domainkonfiguration WebLogic muss von der primären Site zur sekundären Site repliziert werden. Diese Replikation ist beim ersten DR-Setup erforderlich und wird während des laufenden Lebenszyklus des Systems durchgeführt. Wenn Konfigurationsänderungen in der primären Domain vorgenommen werden, müssen sie am sekundären Speicherort repliziert werden.

Wenn eine Standbydatenbank während des normalen Geschäftsvorgangs heruntergefahren wird, erhält sie keine Aktualisierungen von der Primärdatenbank, und sie ist möglicherweise nicht mehr synchron. Da dies zu einem Datenverlust in einem Switchover-Szenario führen kann, wird nicht empfohlen, die Standby-Datenbank während des normalen Geschäftsbetriebs zu stoppen. Die Middle-Tier-Hosts der Standby-Datenbank können gestoppt werden. Wenn Standbyhosts jedoch gestoppt werden, werden die Konfigurationsänderungen, die von der primären Site repliziert werden, nicht an die sekundäre Domain übertragen. In diesem Fall wird bei einem Switchover das Recovery Time Object (RTO) erhöht, da die Middle-Tier-Hosts der Standby-Datenbank gestartet und die Domain mit primären Änderungen synchronisiert werden muss.

Überlegungen für Topologien

Bei diesem Setup werden die relevantesten Topologieannahmen berücksichtigt:

• Das primäre System ist eine vorhandene On-Premise-Umgebung

  Die Umgebung umfasst eine Oracle Real Application Clusters (Oracle RAC)-Datenbank, Middle Tier-Hosts und einen Load Balancer. Das Setup des On-Premise-Systems liegt außerhalb des Geltungsbereichs dieses Dokuments.

• Das sekundäre System befindet sich auf Oracle Cloud Infrastructure (OCI)

  Das sekundäre System wird auf OCI komplett neu erstellt und stellt eine Oracle Cloud-Version Ihres On-Premise-Systems bereit. Es handelt sich um ein vollständig standardmäßiges Oracle Cloud-System mit der Möglichkeit, das primäre System zu werden.

• Oracle SOA Suite und Komponenten

  Dieses Dokument konzentriert sich auf das Oracle SOA Suite-System, einschließlich der zugehörigen Komponenten. Beispiel: Oracle Service Bus, Oracle Business Process Management, Oracle Enterprise Scheduler Service usw. Obwohl die Prozeduren und Empfehlungen in diesem Dokument für andere Oracle Fusion Middleware-Komponenten gelten können, die nicht Bestandteil von Oracle SOA Suite sind (wie Web Center und Business Intelligence), sind die Einzelheiten und die Unterstützbarkeit dieser Komponenten aus dieser Übung ausgeschlossen.

• Das Primär- und Sekundärsystem sind symmetrisch

  Das sekundäre System verfügt über die gleiche Anzahl an Knoten in der Middle Tier, Web-Tier und DB-Tier. Es können Unterschiede in der Web-Tier-Schicht auftreten, wenn OCI Load Balancer allein in OCI verwendet wird (ohne Oracle HTTP Server).

• Primäre und sekundäre Systeme verwenden ähnliche Ressourcen

  Obwohl die verfügbaren OCI-Ausprägungen möglicherweise nicht denselben genauen Werten in CPU und Arbeitsspeicher der vorhandenen Primärkonfiguration entsprechen, müssen Sie die ähnlichsten Ausprägungen verwenden. Oracle empfiehlt die Verwendung von symmetrischen Standbydatenbanken, die dem Primärsystem eine ähnliche Verarbeitungsleistung bieten. Andernfalls könnten Performanceprobleme und Kaskadierungsfehler auftreten, wenn die Workload auf das OCI-System umgeschaltet wird.

Überlegungen zum Netzwerk

Beachten Sie beim Konfigurieren des Netzwerks Folgendes:

• Konnektivität zwischen On-Premise-Netzwerk und Oracle Cloud Infrastructure (OCI)

  Die On-Premise- und OCI-Datenbanken müssen über Oracle SQL*Net Listener (Port 1521) für den Oracle Data Guard redo-Transport miteinander kommunizieren. Die On-Premise- und OCI-Middle Tier-Hosts müssen über den SSH-Port miteinander kommunizieren (für rsync-Kopien). Oracle empfiehlt die Verwendung der Oracle Cloud Infrastructure FastConnect-Kommunikation zwischen dem On-Premise-Data Center und der OCI-Region. Oracle Cloud Infrastructure FastConnect bietet dedizierte, sichere Konnektivität und Bandbreite mit vorhersagbarer Latenz, Jitter und Kosten. Alternativ können Sie Site-to-Site-VPN verwenden, das auch eine sichere Konnektivität zwischen On Premise und OCI bietet. Dies sorgt aber für geringere Bandbreite und variable Latenz, Jitter und Kosten.

• Konnektivität zwischen Mid-Tier-Hosts und der Remote-Datenbank deaktivieren

  Es wird erwartet, dass sich die Mid-Tier-Hosts während der Laufzeit nie bei der Remote-Datenbank anmelden. Diese Crossconnectktivität wird durch die Latenzzeit zwischen On Premise und OCI vermieden. Um zufällige Verbindungen und Workload-Probleme zu vermeiden, schließen Sie die Konnektivität von den Mid-Tier-Hosts zur Remote-Datenbank aus.

• Namen von virtuellen Hosts

  Als Best Practice wird angenommen, dass das primäre On-Premise-System anstelle des physischen Knotenhostnamens virtuelle Hostnamen als Listenadressen für die Oracle WebLogic Servers verwendet. Virtuelle Hostnamen sind normalerweise Aliasnamen des physischen Knotenhostnamens. Virtuelle Hostnamen erleichtern das Verschieben von Konfigurationen auf andere Hosts. Dies ist jedoch nicht erforderlich. Die Konfiguration in diesem Dokument funktioniert, solange die sekundären Server in OCI die Hostnamen verwenden können, die als Listening-Adressen in der Primärdatenbank verwendet werden, als Alias in jedem Knoten (wie in DNS oder lokal /etc/hosts aufgelöst).

• Eine virtuelle IP ist nur für die Listen-Adresse des Administration Servers erforderlich

  Die automatische Servicemigration wird für High Availability (HA) unterstützt und empfohlen. Das bedeutet, dass die Managed Server keine virtuellen IP-Adressen verwenden müssen. Nur der Administrationsserver benötigt eine VIP für lokales Failover. Als Best Practice wird davon ausgegangen, dass der Administrationsserver im primären On-Premise-System eine VIP-Adresse überwacht. Dieses Dokument enthält Anweisungen zum Konfigurieren einer VIP für den Administrationsserver in OCI. Diese VIP-Adresse ist jedoch nicht unbedingt erforderlich, um Disaster Recovery auf OCI mit diesem Dokument zu konfigurieren. Wenn der primäre Administrationsserver nicht in einer VIP horcht, können Sie diesen Punkt überspringen.

• Load Balancer

  Ein Frontend Load Balancer (LBR) wird in der primären On-Premise-Umgebung und ein OCI Load Balancer in der Standbyumgebung verwendet.

• Virtuelle Frontend-Adresse

  Das primäre System muss einen virtuellen Frontend-Namen (eine Vanity-URL, wie mysoa.example.com) als Einstiegspunkt für die Clients verwenden. Dieser Frontend-Name wird in DNS mit der IP-Adresse des primären Load Balancers aufgelöst. In einer DR-Topologie ist das sekundäre System so konfiguriert, dass es den gleichen virtuellen Frontend-Namen verwendet. Wenn ein Switchover oder Failover zum sekundären System stattfindet, wird der virtuelle Frontend-Name im DNS so geändert, dass er auf die IP-Adresse des sekundären Load Balancers verweist. So ist der Zugriff von den Clients auf das System unabhängig von dem Standort, der als primärer Standort verwendet wird. Dasselbe gilt für jeden im System verwendeten virtuellen Frontend-Namen. Beispiel: Sie können einen zusätzlichen Frontend-Namen wie admin.example.com verwenden, um auf Admin-Funktionen für die Oracle WebLogic Server-Administrationskonsole oder die Fusion Middleware Control-Konsole zuzugreifen.

  Sie können einen separaten Frontend-Namen verwenden, wie osb.example.com, um auf Oracle Service Bus-Services zuzugreifen. In diesem Dokument wird ein Frontend-Hostname zur Vereinfachung verwendet.

Überlegungen zu Speicher

Beachten Sie beim Konfigurieren des Speichers Folgendes:

• EDG-basierte Verzeichnisstruktur

  Dieses Dokument verwendet eine Enterprise Deployment Guide-(EDG-)Verzeichnisstruktur für die Oracle WebLogic Server-Domainkonfiguration des primären Systems. Das EDG-Modell verwendet separate Domainverzeichnisse für die Administration von Oracle WebLogic Server und für jedes verwaltete Oracle WebLogic Server, wie unter Dateisystem für ein Enterprise Deployment vorbereiten beschrieben. Die EDG-Verzeichnisstruktur wird in den Beispielen als Referenz verwendet. Es verwendet eine Kombination aus freigegebenen und privaten Ordnern, die weitere Anwendungsfälle abdeckt. Wenn Ihr System die EDG-Verzeichnisstruktur nicht verwendet, passen Sie die Beispiele an Ihre Umgebungsmerkmale an.

• Überlegungen zur Speicherung in der Primärdatenbank (On Premise)
  Es empfiehlt sich, nicht nur die freigegebenen Ordner (Oracle WebLogic Server Admin Server-Domainverzeichnis, Deployment-Pläne Home, Shared Runtime usw.) sondern auch die Oracle Fusion Middleware Home-Binärdateien und die lokalen Konfigurationen (Managed Server-Domainverzeichnisse, Node Manager-Ordner) im NFS-Speicher im primären Speicherort zu speichern. Dies erleichtert das Kopieren von der Primärdatenbank in die Standbydatenbank. Obwohl jeder Host seine eigenen Binärdateien und seine eigene lokale Konfiguration privat verwendet (getrennte NFS-Volumes für jeden Server), ist die Kopie der Konfiguration zwischen Standorten einfacher, wenn diese in Shared Storage gespeichert sind. Mit dieser Lösung können Sie alle von einem eindeutigen Knoten mounten und die rsync-Kopie in einem einzigen Vorgang auf den Remoteknoten ausführen. Ohne diesen Ansatz muss die Kopie einzeln von jedem Primärknoten ausgeführt werden, der Daten privat speichert.

  Hinweis:

  Die für diese rsync-Kopie bereitgestellten Skripte sind so flexibel, dass sie an jeden Fall angepasst werden können.
• Überlegungen zu gemeinsamen Ordnern im sekundären Ordner (OCI)

  Die Ordner, die von den Middle Tier-Hosts gemeinsam verwendet werden müssen (z.B. das Domainverzeichnis des Oracle WebLogic Server-Admin-Servers, das Home der Deployment-Pläne, die gemeinsame Laufzeit usw.) müssen im Shared Storage gespeichert werden. OCI stellt Oracle Cloud Infrastructure File Storage als Netzwerkdateisystemlösung bereit.

  Verschiedene Artefakte sind gemeinsame Ordner und haben unterschiedliche Nutzung und unterschiedlichen Lebenszyklus. Sie müssen entsprechend ihrer Verwendung in einem getrennten Shared Storage platziert werden. Beispiel:

  • Die gemeinsam verwendete Konfiguration (z.B. Admin-Server-Domainverzeichnis WebLogic Server, Deployment-Pläne-Home) wird hauptsächlich vom Administrationsserverhost aufgerufen. Der Restzugriff erfolgt über die übrigen Hosts (für Deployment-Pläne, gemeinsame Keystores usw.). Diese muss in einem Oracle Cloud Infrastructure File Storage-Dateisystem abgelegt werden.
  • Wenn das System einen gemeinsam verwendeten Ordner für Laufzeitartefakte verwendet (z.B. Dateien, die von der Anwendung erstellt und gelesen wurden), wird er normalerweise gleichzeitig von allen Middle Tier-Hosts verwendet. Sie müssen Laufzeitartefakte in einem anderen Oracle Cloud Infrastructure File Storage-Dateisystem oder in einem Datenbankdateisystem-(DBFS-)Mount platzieren.
• Überlegungen zur Speicherung privater Ordner im sekundären Ordner (OCI)

  Die FMW-Binärdateien und lokalen Konfigurationen werden von jedem Host einzeln verwendet. Es wird empfohlen, diese im externen Speicher anstatt im Standard-Boot-Volume der Hosts zu speichern.

  • In OCI können Sie die FMW-Binärdateien in Oracle Cloud Infrastructure Block Volumes für jeden Host speichern. Wenn mehr als zwei Mid-Tier-Hosts vorhanden sind, empfiehlt es sich, redundante gemeinsame Binär-Homes zu verwenden (siehe High Availability Guide). Verwenden Sie dazu Oracle Cloud Infrastructure File Storage, um die FMW-Binärdateien zu speichern.
  • Sie können die lokale Konfiguration (z.B. verwaltete Serverdomainverzeichnisse WebLogic und Node Manager-Ordner) in Oracle Cloud Infrastructure Block Volumes speichern, weil davon ausgegangen wird, dass sie von jedem Host privat verwendet werden. Alternativ können Sie Oracle Cloud Infrastructure File Storage-Dateisysteme verwenden, die von jedem Knoten privat gemountet werden.
  Um das Kopieren von der Primär- auf die Remotesite zu vereinfachen, können Sie die Speicherdateien von einem eindeutigen Knoten mounten und die Kopie rsync in einem einzigen Vorgang ausführen (bei Block Volumes kann ein anderer Host die Dateien im schreibgeschützten Modus mounten). Alternativ kann die Kopie einzeln von jedem Knoten aus durchgeführt werden, der die Daten privat speichert.

  Hinweis:

  Die für diese rsync-Kopie bereitgestellten Skripte sind so flexibel, dass sie an jeden Fall angepasst werden können.
• Speicherreplikation

  Auf Speicherebene gibt es keine direkte Replikation zwischen On Premise und OCI. Die Kopie der Binärdateien und Konfiguration von Primär- zu Standbydatenbank wird mit rsync über Secure Shell (SSH) über eine private Verbindung in Oracle Cloud Infrastructure FastConnect oder Site-to-Site-VPN ausgeführt (niemals das öffentliche Internet verwenden). Die Kopie der Konfigurations- und Laufzeitartefakte kann je nach Kundenanforderungen auch auf DBFS basieren. Weitere Informationen hierzu erhalten Sie später.

• WebLogic persistente Speicher

  Es wird davon ausgegangen, dass die persistenten WebLogic-Speicher, die für TLOGS- und JMS-Nachrichten verwendet werden, persistente JDBC-Speicher sind und in Datenbanktabellen gespeichert werden. Auf diese Weise können die persistenten Speicher von jedem Member des Clusters aus aufgerufen werden (um lokale HA mit Servicemigration bereitzustellen). Dadurch wird auch der zugrunde liegende Oracle Data Guard genutzt, der TLOGS und JMS automatisch auf der sekundären Site repliziert.

Überlegungen zu Datenbanken

Beachten Sie beim Konfigurieren der Datenbanken Folgendes:

• Mehrmandantenfähigkeit

  Die primäre Datenbank muss eine mehrmandantenfähige Datenbank (CDB/PDB) sein. Dies ist erforderlich, um eine hybride Oracle Data Guard in Oracle Cloud Infrastructure zu konfigurieren.

• Patchebenen

  Oracle Home für die On-Premise-Datenbank muss sich auf derselben Patch-Ebene wie die Standbydatenbank befinden.

• Transparente Datenverschlüsselung

  Verwenden Sie Transparente Datenverschlüsselung (TDE) für die Primär- und die Standbydatenbank, um sicherzustellen, dass alle Daten verschlüsselt sind. Wenn die On-Premise-Datenbank noch nicht mit TDE aktiviert ist, wird dringend empfohlen, vor der Konfiguration von Oracle Data Guard eine Konvertierung in TDE vorzunehmen, um die sicherste Umgebung bereitzustellen.

• Hochverfügbarkeit

  Um lokale High Availability auf Datenbankebene abzurufen und die EDG-Topologie zu befolgen, verwenden Sie Oracle Real Application Clusters (Oracle RAC) für die Primär- und die Standbydatenbank. Obwohl der Schwerpunkt auf Oracle RAC liegt, gilt dieses Verfahren für eine einzelne Datenbank. Es wird jedoch empfohlen, Oracle RAC zu verwenden, um lokale High Availability in der DB-Ebene zu erhalten.

• Datenbankservice

  Die primäre On-Premise-Middle Tier sollte einen Anwendungsdatenbankservice verwenden, um eine Verbindung zur primären Datenbank herzustellen.

• Oracle Cloud Infrastructure-(OCI-)Datenbanksystem

  Verwenden Sie ein OCI-DB-System (Bare Metal, Virtual Machine oder Oracle Exadata Database Service) als Standbydatenbank. Eine gemeinsam genutzte oder dedizierte Oracle Autonomous Database liegt außerhalb des Geltungsbereichs dieses Dokuments. Es stellt keine Reihe von Features bereit, die für das Setup des hybriden Disaster Recovery erforderlich sind, wie die Möglichkeit, Oracle Data Guard mit einer On-Premise-Datenbank zu konfigurieren, und die Snapshot Standbykonvertierung.

• TNS-Alias in WebLogic-Datenbankverbindungszeichenfolgen

  In diesem Dokument wird ein TNS-Alias verwendet, um die Datenbankverbindungszeichenfolge in der Oracle WebLogic-Konfiguration zu definieren. Der TNS-Alias wird mit einer tnsnames.ora-Datei aufgelöst, die in jeder Site unterschiedlich ist und auf die lokale Datenbank verweist. Da derselbe Aliasname in der Primär- und Sekundärkonfiguration verwendet wird, müssen Sie die WebLogic-Konfiguration nicht ändern, nachdem sie von der Primär- zur Sekundärkonfiguration repliziert wurde.

  Wenn die primäre Instanz diesen Ansatz noch nicht verwendet, ist ein anfängliches einmaliges Setup erforderlich. Einzelheiten dazu werden später in diesem Dokument beschrieben.

Überlegungen zum Identity Management

Beachten Sie beim Konfigurieren von Identity Management Folgendes:

• Lightweight Directory Access Protocol (LDAP)

  Das System kann ein externes LDAP zur Authentifizierung verwenden (z.B. Oracle Unified Directory), solange das externe LDAP sowohl vom Primär- als auch vom Standbysystem aus erreichbar ist.

• Disaster Recovery-Lösung für LDAP

  Die Disaster Recovery-Lösung für einen externen LDAP-Service liegt außerhalb des Geltungsbereichs dieses Dokuments und sollte vom jeweiligen LDAP-Produkt bereitgestellt werden. Die DR-Lösung für LDAP sollte eine einzigartige Möglichkeit bieten, auf sie zuzugreifen (normalerweise ein virtueller Hostname), der sich bei einem Switchover im LDAP-System nicht ändert.

Überlegungen - Übersicht

Im Folgenden finden Sie eine Zusammenfassung der Aspekte, die Sie bei der Planung einer Disaster-Recovery-Lösung berücksichtigen sollten.

Hinweise zu	Übersicht	Obligatorisch oder sehr empfohlen
Topologie	Das primäre System ist eine vorhandene On-Premise-Umgebung.	Sehr empfehlenswert
Topologie	Das sekundäre System auf Oracle Cloud Infrastructure (OCI) wird auf OCI von Grund auf neu erstellt.	Obligatorisch
Topologie	Das primäre und das sekundäre System sind symmetrisch und haben dieselbe Anzahl von Knoten in db-tier, mid-tier und web-tier.	Obligatorisch
Topologie	Die primäre Web-Tier besteht aus einem Load Balancer vor Oracle HTTP Server.	Sehr empfehlenswert
Topologie	Das primäre und das sekundäre System verwenden ähnliche Ressourcen (CPU, Arbeitsspeicher usw.).	Obligatorisch
Netzwerk	Verwenden Sie OCI FastConnect für die Konnektivität zwischen On Premise und OCI, alternativ Site-to-Site-VPN. Nie öffentliches Internet.	Obligatorisch
Netzwerk	Deaktivieren Sie die Konnektivität zwischen Mid-Tier-Hosts und der Remote-Datenbank. Nur erforderlich, wenn Oracle Database File System (DBFS) zur Replikation der Konfiguration verwendet wird.	Sehr empfehlenswert
Netzwerk	Verwenden Sie virtuelle Hostnamen für WebLogic-Server-Listening-Adressen.	Sehr empfehlenswert
Netzwerk	Virtuelle IP für Administrationsserver.	Sehr empfehlenswert
Netzwerk	Virtuelle Frontend-Adresse.	Obligatorisch
Speicher	EDG-basierte Verzeichnisstruktur.	Sehr empfehlenswert
Speicher	Private und gemeinsam genutzte On-Premise-Ordner im externen Speicher, damit sie von einem eindeutigen Knoten für zentralisierte rsync-Vorgänge gemountet werden können.	Sehr empfehlenswert
Speicher	Gemeinsame OCI-Konfiguration in Oracle Cloud Infrastructure File Storage.	Obligatorisch
Speicher	OCI Shared Runtime in OCI File Storage oder Oracle Database File System (DBFS).	Obligatorisch
Speicher	OCI FMW-Binärdateien in OCI File Storage werden privat gemountet.	Sehr empfehlenswert
Speicher	Lokale OCI-Konfigurationen in Oracle Cloud Infrastructure Block Volumes (alternativ OCI File Storage privat gemountet).	Sehr empfehlenswert
Speicher	Staging-DBFS-Mount (nur wenn DBFS-basiertes Replikat für die Konfiguration verwendet wird).	Sehr empfehlenswert
Speicher	Speicherreplikation basierend auf rsync (oder DBFS für bestimmte Artefakte wie Konfiguration).	Sehr empfehlenswert
Speicher	WebLogic Persistente Speicher (TLOGS, JMS) in persistenten JDBC-Speichern.	Erforderlich (*wenn JMS-Info relevant ist)
Datenbank	On-Premise-Datenbank-Patchebene mit der Standbydatenbank.	Obligatorisch
Datenbank	Transparente Datenverschlüsselung (TDE) für die Primär- und die Standbydatenbank. Wenn die On-Premise-Datenbank noch nicht mit TDE aktiviert ist, sollten Sie die Konvertierung in TDE unbedingt empfehlen, bevor Sie Oracle Data Guard konfigurieren.	Obligatorisch
Datenbank	Oracle RAC Database für lokale High Availability.	Sehr empfehlenswert
Datenbank	Primäre Mehrmandantendatenbank.	Obligatorisch
Datenbank	Verwenden Sie einen Anwendungsdatenbank-Service, nicht den Standardadministrations-Service, um eine Verbindung zur Datenbank herzustellen.	Obligatorisch
Datenbank	Verwenden Sie in OCI das DB-System (BM, VM oder Oracle Exadata Database Service), nicht Oracle Autonomous Database.	Obligatorisch
Datenbank	TNS-Alias in WebLogic-Datenbankverbindungszeichenfolgen.	Sehr empfehlenswert
Identity Management	Das System kann ein externes LDAP zur Authentifizierung verwenden (z.B. Oracle Unified Directory), solange das externe LDAP sowohl vom Primär- als auch vom Standbysystem aus erreichbar ist.	Obligatorisch (die Verwendung von externem LDAP ist NICHT obligatorisch, muss jedoch bei Verwendung von beiden Sites aus erreichbar sein)
Identity Management	Die Disaster Recovery-Lösung für externe LDAP-Services liegt außerhalb des Geltungsbereichs dieses Dokuments und sollte vom jeweiligen LDAP-Produkt bereitgestellt werden. Die DR-Lösung für LDAP muss eine eindeutige Zugriffsmöglichkeit bieten (in der Regel ein virtueller Hostname), die sich bei einem Switchover im LDAP-System nicht ändert.	Obligatorisch (die Verwendung von externem LDAP ist NICHT obligatorisch, muss aber bei Verwendung und DR-geschützt eine virtuelle Zugriffsadresse angeben, die bei einem Switchover/Failover für die LDAP-Zugriffsmöglichkeit identisch bleibt)

Informationen zu erforderlichen Services und Rollen

Für diese Lösung sind die folgenden Services und Rollen erforderlich:

Diese Rollen sind für jeden Service erforderlich.

Servicename: Rolle	Erforderlich für...
Oracle Cloud Infrastructure: administrator	Erstellen Sie die erforderlichen Ressourcen im OCI-Mandanten: Compartment, DB-System, Compute-Instanzen, FSS-Ressourcen und Load Balancer.
Netzwerk: administrator	Konfigurieren Sie die erforderlichen Netzwerkressourcen sowohl in On Premise als auch in OCI: Fast Connect, VCNs und Subnetze in OCI, Netzwerksicherheitsregeln und Routingregeln.
Oracle Data Guard: root, oracle und sysdba	Konfigurieren Sie Oracle Data Guard zwischen primärer On-Premise- und Standby-OCI, und führen Sie Rollenkonvertierungen durch.
Oracle Database: sysdba	Datenbanken verwalten
Oracle WebLogic Server: root, oracle	Konfigurieren Sie die Mid-Tier-Hosts nach Bedarf: Führen Sie die Konfiguration auf BS-Ebene aus, fügen Sie Hostaliasnamen hinzu, verwalten Sie virtuelle IP-Adressen und mounten Sie Dateisysteme.
Oracle WebLogic Server: Weblogic Administrator	Oracle WebLogic Server verwalten: Konfigurationsänderungen WebLogic stoppen, starten und anwenden.

Informationen zum Abrufen der benötigten Cloud-Services finden Sie unter https://docs.oracle.com/pls/topic/lookup?ctx=en/solutions/soa-dr-on-cloud&id=GCSSL.