Hybrid-DR-Lösung für Oracle WebLogic Server konfigurieren

Um die Geschäftskontinuität bei Katastrophen sicherzustellen, sollten Sie eine Disaster-Recovery-(DR-)Strategie für Ihre On-Premise-Anwendungen implementieren, die Datenschutz bietet und Ihnen den schnellen Wechsel zum Standbysystem mit minimalem Daten- und Produktivitätsverlust ermöglicht. Sie können eine hybride DR-Strategie konfigurieren, bei der sich die Primärsysteme On Premise und die Standbysysteme auf Oracle Cloud Infrastructure (OCI) befinden. Mit Oracle Data Guard stellt diese Lösung eine hochverfügbare, sichere und skalierbare Infrastruktur bereit, mit der Sie das Recovery nach Katastrophen zuverlässig und sicher durchführen können.

Bevor Sie beginnen

Bevor Sie mit dem Deployment einer Hybrid Disaster Recovery-(DR-)Lösung für das Oracle WebLogic Server-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 WebLogic Server-Umgebung.

Das primäre System ist ein On-Premise-System von Oracle WebLogic Server. 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 durch Provisioning von Oracle WebLogic Server für OCI-Images und nicht des Oracle WebLogic Server für OCI-Stacks erstellt (es gibt Einschränkungen bei BS-Versionen, BS-Benutzern und Verzeichnisstruktur, die verhindern, dass Oracle WebLogic Server für OCI-Stacks ordnungsgemäß als Standby für ein On-Premise-System funktionieren).

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

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

maa-wls-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 lokale Netzwerk, das von Ihrer Organisation verwendet wird. Es ist einer der Speichen der Topologie.

• Load Balancer

  Stellt eine automatisierte Trafficverteilung von einem einzelnen Einstiegspunkt zu mehreren Servern im Backend bereit.

• Oracle WebLogic Server

  Die Oracle WebLogic Server-Domain ist eine High Availability-Umgebung, die gemäß den Best Practices des MAA-Standards für High Availability konfiguriert wurde.

• 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 beim Zugriff auf Shared Storage zu aktivieren. Benutzersessions, die sich bei Oracle RAC-Instanzen anmelden, können Failover durchführen und Änderungen bei Ausfällen ohne Änderungen an Endbenutzeranwendungen sicher wiedergeben, sodass die Auswirkungen der Ausfälle vor Endbenutzern verborgen bleiben.

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

• Region

  Eine Oracle Cloud Infrastructure-Region ist ein lokalisierter geografischer Bereich, der ein oder mehrere Data Center enthält, die als Availability-Domains bezeichnet werden. 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 Subnetz

  Ein VCN ist ein anpassbares, Software definiertes Netzwerk, das Sie in einer Oracle Cloud Infrastructure-Region einrichten. Wie bei Data Center-Netzwerken erhalten Sie mit VCNs eine vollständige Kontrolle über Ihre Netzwerkumgebung. Ein VCN kann mehrere sich nicht überschneidende CIDR-Blöcke enthalten, 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 erstrecken. 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 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 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.

• 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 Optionen mit höherer Bandbreite und ein zuverlässigeres Netzwerk als bei internetbasierten Verbindungen.

• Sicherheitsliste

  Für jedes Subnetz können Sie Sicherheitsregeln erstellen, die Quelle, Ziel und Typ des Traffics angeben, die in das Subnetz ein- und ausgehen dürfen.

• Routentabelle

  Virtuelle Routentabellen enthalten Regeln, mit denen Traffic von Subnetzen zu Zielen 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 einzigen Endpunkt auf mehrere Server 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 auf mehreren Servern 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 Failover durchführen und Änderungen bei Ausfällen ohne Änderungen an Endbenutzeranwendungen sicher wiedergeben, sodass die Auswirkungen der Ausfälle vor Endbenutzern verborgen bleiben. 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

  Mit Oracle Data Guard erhalten Sie zahlreiche Services, mit denen Sie eine oder mehrere Standbydatenbanken erstellen, verwalten und überwachen können, damit Oracle-Produktionsdatenbanken ohne Unterbrechung verfügbar bleiben. Oracle Data Guard verwaltet diese Standbydatenbanken als Kopien der Produktionsdatenbank. Wenn die Produktionsdatenbank dann aufgrund eines geplanten oder ungeplanten Ausfalls nicht verfügbar ist, kann Oracle Data Guard jede Standbydatenbank auf die Produktionsrolle umschalten, wodurch die Ausfallzeit für den Ausfall minimiert wird.

Beschreibung der Topologie

Die hybride DR-Topologie von Oracle WebLogic Server 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är- und die Sekundärdatenbank mit Oracle Data Guard konfiguriert. Mit Oracle Data Guard werden alle Änderungen, die auf die Primärdatenbank angewendet werden, in der sekundären (Standby-)Datenbank repliziert.

Die sekundäre Mid-Tier wird auf OCI Compute-Instanzen installiert. Dabei kann es sich um Oracle WebLogic Server for Oracle Cloud Infrastructure-Images handeln, um die WebLogic-Berechtigungslizenz zu nutzen, die in diesen Images enthalten ist. Die Oracle Fusion Middleware-Binärdateien und die Oracle WebLogic-Domain sind ein Replikat der Binärdateien und der Domain der Primärdatenbank, wobei Oracle Cloud Infrastructure File Storage-Services als Netzwerkdateisystemlösung und Oracle Cloud Infrastructure Block Volumes als Knotenlösung für das private Zugriffsdateisystem verwendet werden. Die Aliasnamen der Primärinstanz werden auch als Listener-Adressen der Oracle WebLogic Servers 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 Informationen zu Oracle Platform Security Services, 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 repliziert werden. Diese Replikation ist während des anfänglichen DR-Setups erforderlich und während des laufenden Lebenszyklus des Systems erforderlich. Wenn Konfigurationsänderungen in der primären Domain vorgenommen werden, müssen sie an dem sekundären Speicherort repliziert werden.

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

Überlegungen für Topologien

In diesem Setup werden die folgenden Topologieannahmen am relevantesten 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.

• 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).

• Das primäre und das sekundäre System 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 für das 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 die Middle Tier-Hosts während der Laufzeit nie eine Verbindung zur Remote-Datenbank herstellen. Die Latenz zwischen On Premise und OCI rät in der Regel von dieser Crossconnectivity ab. Um versehentliche Verbindungen und Workload-Probleme zu vermeiden, schließen Sie die Konnektivität von den Middle Tier-Hosts zur Remote-Datenbank aus.

• Virtuelle Hostnamen

  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-Adresse ist nur für die Listening-Adresse des Administrationsservers 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 wlsfrontend.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.

Überlegungen zum 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 für Betriebssysteme

Oracle WebLogic Server for Oracle Cloud Infrastructure-Images unterstützen Oracle Linux 7.9- und Oracle Linux 8.5-Betriebssysteme.

Die Middle-Tier- und Web-Tier-Compute-Instanzen müssen das BS-Image und die Compute-Ausprägung verwenden, die dem Image und der Ausprägung ähneln, die von den On-Premise-Hosts verwendet werden. Wenn Sie WebLogic Server für OCI-Images verwenden, ist die Lösung auf die von ihnen verwendete BS-Version beschränkt (Oracle Linux 7.X oder 8.X).

• Betriebssystemversionen für Mid-Tier-Hosts

  Ein Oracle WebLogic Server, der auf Oracle Cloud Infrastructure (OCI) ausgeführt wird, muss zusätzlich zu dem Lizenz- und Supportvertrag, der für die On-Premise-Ausführung von Oracle WebLogic Server verwendet wird, mit einem gültigen Lizenz- und Supportvertrag abgedeckt sein. In Oracle Cloud können die Compute-Instanzen mit den Oracle WebLogic Server for OCI-Images erstellt werden. Die mit diesen Images erstellten Compute-Instanzen umfassen die Berechtigung zur Ausführung von Oracle WebLogic Server. Sie werden pro OCPU/Stunde abgerechnet, wenn sie den Status "Wird ausgeführt" aufweisen. Diese Images sind für die Betriebssysteme Oracle Linux 7.9 und Oracle Linux 8.5 verfügbar.

• Betriebssystemversionen für Web-Tier-Hosts

  Ein Oracle HTTP Server, der in OCI ausgeführt wird, muss zusätzlich zu dem Lizenz- und Supportvertrag, der für die On-Premise-Ausführung von Oracle HTTP Server verwendet wird, mit einem gültigen Lizenz- und Supportvertrag abgedeckt sein. In Oracle Cloud können Compute-Instanzen mit den Oracle WebLogic Server for OCI-Images erstellt werden. Die mit diesen Images erstellten Compute-Instanzen umfassen die Berechtigung zur Ausführung von Oracle HTTP Server. Sie werden pro OCPU/Stunde für die Berechtigung zur Ausführung der WebLogic-Software abgerechnet, wenn diese ausgeführt wird. Diese Images sind für die Betriebssysteme Oracle Linux 7.9 und Oracle Linux 8.5 verfügbar.

Überlegungen zu Oracle WebLogic Server

Beachten Sie bei der Implementierung dieser Lösung Folgendes:

• Produkte auf Oracle WebLogic Server

  Umgebungen mit zusätzlichen Produkten, die zusätzlich zu Oracle WebLogic Server installiert sind, können von den in diesem Playbook beschriebenen Verfahren profitieren. Die Besonderheiten anderer Produkte liegen jedoch außerhalb des Geltungsbereichs dieses Dokuments.

• Oracle WebLogic Server-Edition

  Dieses Dokument kann für Oracle WebLogic Suite Edition und Oracle WebLogic Server Enterprise Edition gelten. Wenn es sich bei der Datenbank jedoch um eine Oracle Real Application Clusters (Oracle RAC)-Datenbank handelt (die zum Abrufen lokaler High Availability empfohlen wird), wird in diesem Dokument davon ausgegangen, dass Oracle WebLogic Suite Edition verwendet wird, da Oracle WebLogic Server Enterprise Edition keine Berechtigung zur Verwendung von Active GridLink-Datenquellen enthält.

• JRF-fähige WebLogic-Domains

  Dieses Dokument gilt für Domains mit aktivierten Java Required Files-(JRF-)Komponenten und Basisdomains.

  JRF-fähige Domains haben mehr Abhängigkeiten in der Datenbank als Basisdomains. Daher hat ein Disaster Recovery-(DR-)Modell, das für JRF-fähige Domains entwickelt wurde, mehr Constraints. Basisdomains haben mehr Flexibilität für DR, aber ein für eine Basisdomain gültiges DR-Modell gilt möglicherweise nicht für eine JRF-fähige Domain, da WebLogic JRF-Datenbankabhängigkeiten nicht berücksichtigt werden. Ein DR-Modell, das für eine JRF-fähige Domain gültig ist, gilt auch für eine Basisdomain. Das in diesem Dokument beschriebene Modell basiert auf JRF-fähigen Domains. Es gilt daher für beide Oracle WebLogic-Domaintypen.

Aspekte von Datenbanken

Beachten Sie beim Konfigurieren der Datenbanken Folgendes:

• Mehrmandantenfähigkeit

  Die Primärdatenbank muss eine mehrmandantenfähige Datenbank (CDB/PDB) sein. Dies ist erforderlich, um ein hybrides Oracle Data Guard in Oracle Cloud Infrastructure zu konfigurieren.

• Patchebenen

  Das Oracle Home für die On-Premise-Datenbank muss sich auf derselben Patchebene 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.

• High Availability

  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.

• Database-Service

  Die primäre On-Premise-Middle Tier muss einen Anwendungsdatenbankservice verwenden, um eine Verbindung zur Primärdatenbank 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 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.

Ü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)

In der folgenden Tabelle werden Betriebssystem- und Oracle WebLogic-Überlegungen sowie die in der vorherigen Tabelle beschriebenen Überlegungen zusammengefasst.

Hinweise zu	Übersicht	Obligatorisch oder sehr empfohlen
Betriebssystem	On Premise Mid-Tier OS-Versionen Oracle Linux 7 oder 8	Sehr empfohlen (um Oracle WebLogic Server für OCI-Images zu nutzen)
Betriebssystem	On-Premise-BS-Versionen der Web-Tier Oracle Linux 7 oder 8	Sehr empfohlen (um Oracle WebLogic Server für OCI-Images zu nutzen)
Oracle WebLogic Server	Nur WebLogic-Software. Andere Produkte außerhalb des Geltungsbereichs des Dokuments	n.v.
Oracle WebLogic Server	Oracle WebLogic Suite Edition bei Verwendung von Oracle RAC zur Verwendung von GridLink-Datenquellen	Obligatorisch
Oracle WebLogic Server	WebLogic JRF-fähige und Nicht-JRF-fähige Domains	n/a (beide sind gültig)

Erforderliche Services und Rollen

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

Dies sind die für jeden Service erforderlichen Rollen.

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 On Premise als auch 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	Verwalten Sie die Datenbanken.
Oracle WebLogic Server: root, oracle	Konfigurieren Sie die Mid-Tier-Hosts nach Bedarf: Führen Sie die Konfiguration auf BS-Ebene durch, fügen Sie Hostaliasnamen hinzu, verwalten Sie virtuelle IP-Adressen und mounten Sie Dateisysteme.
Oracle WebLogic Server: Weblogic Administrator	Oracle WebLogic Server verwalten: WebLogic-Konfigurationsänderungen stoppen, starten und anwenden.

Siehe Informationen zum Abrufen von Oracle Cloud-Services für Oracle-Lösungen, um die erforderlichen Cloud-Services zu erhalten.