Mid-Tier-Replikation in einer OCI Disaster Recovery-Architektur implementieren

Implementieren Sie die fortlaufende Replikation für Ihre Middleware-Ebene in einem symmetrischen Disaster Recovery-(DR-)System in Oracle Cloud Infrastructure (OCI), indem Sie die Anwendungsserver und ihre Konfigurationen zwischen primären und sekundären Regionen replizieren, um minimale Ausfallzeiten und Datenverluste während eines Failovers oder Switchovers sicherzustellen.

Dieses Lösungs-Playbook bietet einen Überblick über die Mid-Tier-Replikation während des gesamten Lebenszyklus des Systems. Es stellt verschiedene Replikationstechnologien vor und bietet Details, um sie in einem realen Szenario zu implementieren. Es wendet active-passive Mid-Tier-Disaster Recovery-Szenarios an, in denen sich sowohl Primär- als auch Standbysysteme in OCI befinden.

Der Inhalt richtet sich an Mid-Tier-Administratoren, die mit Disaster Recovery-(DR-)Topologien für Middleware und OCI vertraut sind. Die Beispiele und die Terminologie beziehen sich auf Oracle WebLogic Server- und PaaS-Services, die WebLogic verwenden. Die beschriebenen Replikationstechnologien und Implementierungen gelten jedoch für jedes Mid-Tier-System.

Hinweis:

In diesem Dokument wird das Disaster Recovery-Setup nicht beschrieben.

Architektur

Diese Architektur zeigt einen allgemeinen Überblick über die Active/Passive Disaster Recovery-Topologie der Middleware. Bei diesem Playbook wird davon ausgegangen, dass das primäre und das sekundäre System bereits erstellt wurden.

Jede Active/Passive-Disaster Recovery-Lösung für ein Mid-Tier-System muss die folgenden wesentlichen Funktionen implementieren:

• Geografische Trennung

  Primäre und sekundäre Systeme sind geografisch getrennt, weit genug, damit sie nicht von demselben Katastrophenereignis betroffen sein können.

• Symmetrie

  Primär- und Sekundärsysteme sind symmetrisch. Das sekundäre System verfügt über die gleiche Anzahl von Knoten in der Mid-Tier und der DB-Tier mit ähnlicher CPU- und Speicherkapazität.

• Eindeutiger Frontend-Name

  Eindeutige Frontend-Namen für Primär- und Sekundärnamen. Der Zugriff von Clients auf das System muss agnostisch auf die Site sein, die als primäre Site verwendet wird. Dazu müssen die Frontend-Adressnamen eindeutig sein und immer der IP des Systems zugeordnet sein, das in diesem Moment die primäre Adresse ist. Dieser Name wird normalerweise als virtuelles Frontend oder Vanity-URL bezeichnet.

• Listening- Adressen

  Die Listening-Adressen der Mid-Tier-Prozesse müssen Hostnamen sein, die in beiden Systemen aufgelöst und den IPs der Hosts der lokalen Site zugeordnet werden können.

• Datenbankreplikation

  Die Daten der Primärdatenbank müssen mit Oracle Data Guard in die Standbydatenbank repliziert werden.

• Midtier-Replikation

  Primäre und sekundäre Mid-Tiers müssen synchron sein. Sie müssen dieselbe Konfiguration, dieselbe Produktversion und dieselbe Patchebene aufweisen. Dafür gibt es verschiedene Ansätze. Sie können das primäre und das sekundäre System separat verwalten: Wenn eine Änderung im primären System durchgeführt wird, wird dieselbe Änderung im sekundären System wiederholt, wenn ein Patch im primären System installiert wird, wird derselbe Patch im Standby installiert. Dies dupliziert jedoch die Arbeit und ist anfällig für Fehler. Oracle Maximum Availability Architecture (Oracle MAA) empfiehlt die Implementierung einer automatischen Replikation, um die Mid-Tier-Dateisystemartefakte zu kopieren. Dadurch wird sichergestellt, dass Primär- und Standby-Systeme immer synchron sind.

• Verwaltung der für jeden Standort spezifischen Informationen

  Die Konfiguration der sekundären Instanz ist eine exakte Kopie der primären Instanz. Es können jedoch Dateiartefakte vorhanden sein, die spezifische Informationen zu jeder Site enthalten, die sich in der primären und sekundären Instanz unterscheiden müssen. Die DR-Topologie muss dies unterstützen und die Anpassung standortspezifischer Informationen ermöglichen.

  Tipp:

  Oracle WebLogic Server – Beispiel

  In einem Oracle WebLogic-System stellt die primäre Mid-Tier eine Verbindung zur Datenbank der primären Region her, und die sekundäre Mid-Tier stellt eine Verbindung zur Datenbank der sekundären Region her. Das primäre und das sekundäre Mid-Tier-System haben dieselbe Konfiguration. Daher muss ein Mechanismus vorhanden sein, mit dem sichergestellt werden kann, dass jedes System die entsprechende Verbindungszeichenfolge verwendet, die auf seine lokale Datenbank verweist. Oracle Maximum Availability Architecture (Oracle MAA) empfiehlt die Verwendung von TNS-Aliasnamen für die Datenquellen mit unterschiedlichen tnsnames.ora-Dateien in jeder Site. Die Mid-Tier-Replikationsmethoden müssen dies berücksichtigen, indem sie entweder die Datei mit der Datenbank-Connect String (tnsnames.ora) überspringen oder die Datenbank-Connect String in den Dateien ersetzen, um auf die lokale Datenbank zu verweisen.

Das folgende Bild ist ein Beispiel für eine Active/Passive Disaster Recovery-Lösung für ein Mid-Tier-System.

Beschreibung der Abbildung active-passive-dr-mid-tier.png

active-passive-dr-mid-tier-oracle.zip

Terminologie

Sie sollten mit den folgenden Konzepten und Begriffen vertraut sein:

• Mid-Tier (auch Middle Tier oder Middleware)

  Die Middle Tier bezieht sich auf die Schicht innerhalb einer Multi-Tier-Anwendungsarchitektur, die zwischen der Benutzeroberfläche (Front-End) und dem Datenspeicher (Back-End) liegt. Es verarbeitet Geschäftslogik, Datenverarbeitung und Sicherheit und fungiert als Brücke zwischen dem Benutzer und der Datenbank.

• Katastrophe

  Ein plötzliches, ungeplantes Katastrophenereignis, das inakzeptable Schäden oder Verluste an einem Standort oder einem geografischen Gebiet verursacht. Eine Katastrophe ist ein Ereignis, das die Fähigkeit eines Unternehmens beeinträchtigt, kritische Funktionen, Prozesse oder Services für einen inakzeptablen Zeitraum bereitzustellen, und das Unternehmen veranlasst, seine Wiederherstellungspläne aufzurufen.

• Disaster Recovery (DR)

  Fähigkeit zum Schutz vor natürlichen oder ungeplanten Ausfällen an einer Produktionssite durch eine Wiederherstellungsstrategie für Anwendungen und Daten in einer geografisch getrennten sekundären Site.

• Disaster-Recovery-Topologie

  Die Produktions-Site sowie die Hardware- und Softwarekomponenten des sekundären Standorts, aus denen eine Oracle Fusion Middleware Disaster Recovery-Lösung besteht.

• Oracle Maximum Availability Architecture

  Oracle Maximum Availability Architecture (Oracle MAA) ist der Best-Practice-Blueprint für Datenschutz und Verfügbarkeit von Oracle-Produkten (Database, Fusion Middleware, Applications). Die Implementierung von Best Practices für Oracle MAA ist eine der wichtigsten Anforderungen für jede Bereitstellung von Oracle. Es enthält Empfehlungen zum Einrichten und Verwalten eines Oracle-Systems. Oracle MAA enthält die Oracle Fusion Middleware Enterprise Deployment Guide-Empfehlungen und fügt Best Practices zum Katastrophenschutz hinzu, um geplante und ungeplante Ausfallzeiten für Ausfälle zu minimieren, die sich auf ein gesamtes Data Center oder eine gesamte Region auswirken.

• System

  Ein System besteht aus einer Gruppe von Zielen (Hosts, Datenbanken, Anwendungsserver usw.), die zusammenarbeiten, um Ihre Anwendungen zu hosten. Beispiel: Um eine Anwendung in Oracle Enterprise Manager zu überwachen, erstellen Sie zunächst ein System, das aus den Datenbank-, Listener-, Anwendungsserver- und Hostzielen besteht, auf denen die Anwendung ausgeführt wird.

• Site

  Ein Standort besteht aus verschiedenen Komponenten in einem Data Center, die zum Ausführen einer Anwendungsgruppe benötigt werden. Beispiel: Eine Site kann aus Oracle Fusion Middleware-Instanzen, Datenbanken, Speicher usw. bestehen.

• Produktions- oder Primärstandort

  Der Standort, der die Arbeitslast des Systems zu einem genauen Zeitpunkt trägt. Es handelt sich um eine Gruppe von Hardware-, Netzwerk- und Speicherressourcen und -prozessen, die aktiv zur Übertragung von Geschäftslogik und Prozessanforderungen zu einem bestimmten Zeitpunkt verwendet wird.

• Sekundäre Site (oder Standby Site oder DR)

  Ein sekundärer Standort ist ein Backup-Speicherort, der die Geschäftslogik übernehmen und Anforderungen stellen kann, die von einem primären Standort verarbeitet wurden. Normalerweise werden sekundäre Sites auch als "Standby" bezeichnet, da sie im "Standby- oder Inaktivmodus" bleiben. Dies bedeutet, dass sie die Produktions-Workload während des normalen Betriebs nicht verarbeiten. Dies bedeutet jedoch nicht, dass die sekundäre Website nicht für andere Zwecke verwendet werden kann. Dies gilt insbesondere für modernere Modelle, bei denen der sekundäre Standort für Reportingvorgänge und vor allem für die Validierung von Änderungen verwendet wird, bevor sie auf dem primären Standort angewendet werden.

• Recovery Point Objective (RPO)

  Das Recovery Point Objective ist die Menge an Datenverlust, die ein System aus geschäftlicher Sicht tolerieren kann. Beispiel: Die Menge an Datenverlust, die bei einem Ausfall akzeptabel ist.

• Recovery Time Objective (RTO)

  Das Recovery Time Objective ist die Ausfallzeit, die ein System tolerieren kann, oder die akzeptable Zeit, die eine Anwendung oder ein Service aus geschäftlicher Sicht nicht verfügbar bleiben kann, wenn ein Ausfall stattfindet.

• Oracle Cloud Infrastructure (OCI)

  OCI ist eine Reihe sich ergänzender Cloud-Services, mit denen Sie eine Vielzahl von Anwendungen und Services in einer hochverfügbaren gehosteten Umgebung erstellen oder ausführen kann. OCI bietet Funktionen für High Performance Computing (als physische Hardwareinstanzen) und Speicherkapazität in einem flexiblen virtuellen Overlay-Netzwerk, auf das über Ihr On-Premise-Netzwerk sicher zugegriffen werden kann.

• OCI-region

  Eine OCI-Region ist ein lokalisierter geografischer Bereich, der aus einer oder mehreren Availability-Domains besteht. Regionen sind unabhängig von anderen Regionen. Sie können extrem weit auseinanderliegen und durch Länder oder sogar Kontinente getrennt sein. Eine Region ist eine Site in Bezug auf Disaster Recovery.

• OCI-Block-Volumes

  OCI Block Volumes bieten zuverlässigen, leistungsstarken und kostengünstigen Blockspeicher, der über die Lebensdauer einer virtuellen Maschine hinaus erhalten bleibt, mit integrierter Redundanz und Skalierbarkeit.

• OCI File Storage

  OCI File Storage ist ein vollständig verwalteter, elastischer Speicherservice der Unternehmensklasse, mit dem Server und Anwendungen über gemeinsame Dateisysteme auf Daten zugreifen können.

• DBFS

  Ein Datenbankdateisystem (DBFS) ist eine Standarddateisystemschnittstelle in Oracle Database. DBFS ähnelt NFS darin, dass es ein gemeinsam verwendetes Netzwerkdateisystem bereitstellt, das wie ein lokales Dateisystem aussieht und sowohl eine Serverkomponente als auch eine Clientkomponente aufweist.

• WLS-HYDR-Framework

  Das "WLS-HYDR-Framework" bezeichnet ein Framework zum Erstellen und Konfigurieren eines symmetrischen Disaster Recovery-(DR-)Systems für Oracle WebLogic Server-(WLS-)Umgebungen, insbesondere in Oracle Cloud Infrastructure. Dieses Framework automatisiert die manuellen Prozesse, die beim Einrichten einer DR-Umgebung für WLS- oder Fusion Middleware-(FMW-)Domains erforderlich sind.

• Oracle WebLogic Server for Oracle Cloud Infrastructure-Stack

  Oracle WebLogic Server for OCI-Stack bezieht sich auf eine vorkonfigurierte Umgebung, die mit Oracle Resource Manager im OCI Marketplace erstellt wurde und Oracle WebLogic Server-Deployments auf OCI bereitstellt und verwaltet. Es automatisiert die Erstellung und Konfiguration verschiedener OCI-Ressourcen wie Compute-Instanzen, Networking, Load Balancer sowie eine WebLogic-Domain.

• Oracle SOA Suite on Marketplace-Stack

  Der Oracle SOA Suite on Marketplace-Stack ist eine vorkonfigurierte Umgebung, die mit Oracle Resource Manager im OCI Marketplace erstellt wurde, um Oracle SOA Suite-Anwendungen auf OCI bereitzustellen und zu verwalten. Es automatisiert die Erstellung und Konfiguration verschiedener OCI-Ressourcen wie Compute-Instanzen, Networking, Load Balancer sowie eine SOA-WebLogic-Domain.

• TNS-Alias

  In Oracle ist ein TNS-Alias, auch Net Service Name genannt, eine benutzerfreundliche ID, die Datenbankverbindungen vereinfacht. Sie fungiert als Shortcut und ordnet einen menschenlesbaren Namen den komplexeren Verbindungsdetails zu, die erforderlich sind, um eine bestimmte Oracle-Datenbankinstanz zu erreichen. Diese Details, einschließlich Protokoll, Host, Port und Servicename, werden in einer Konfigurationsdatei gespeichert, die normalerweise tnsnames.ora heißt.

• TNS-Admin-Ordner

  Der Oracle TNS-Admin-Ordner, der von der Umgebungsvariablen TNS_ADMIN angegeben wird, ist das Verzeichnis, in dem sich Oracle Net Services-Konfigurationsdateien wie tnsnames.ora befinden. Ein Mid-Tier-System kann einen TNS-Admin-Ordner mit dem tnsnames.ora und anderen Artefakten verwenden, die für die Anmeldung bei der Datenbank erforderlich sind.

Informationen zu Active/Passive DR-Setupprozeduren für Middleware in OCI

Bei einer Active/Passive Disaster Recovery-Topologie für Middleware ist das sekundäre System ein Spiegel des primären Systems. Wenn sich das primäre und das sekundäre System in OCI befinden, gibt es verschiedene Möglichkeiten, das sekundäre System einzurichten:

• Manuell

  Erstellen Sie jede Ressource einzeln über die OCI-Konsole oder CLI als Spiegel des primären Systems.

• WLS-HYDR-Framework

  Verwenden Sie das WLS-HYDR-Framework für Ihre Mid-Tier-Systeme basierend auf Oracle WebLogic. Dieses Framework verwendet das OCI-SDK für Python, um alle Ressourcen im sekundären System als Spiegel des primären Systems zu erstellen. Im Abschnitt "Weitere Informationen" in diesem Playbook finden Sie einen Link zum wls-hydr-Framework in GitHub.

• Bereitstellung mit demselben Marketplace-Stack

  Wenn es sich bei dem primären System um einen Marketplace-Stack wie Oracle WebLogic Server for OCI oder SOA Marketplace handelt, können Sie das Provisioning mit demselben Marketplace-Stack durchführen, der in der Primärdatenbank verwendet wird, wobei sich die Standbydatenbank im Snapshot-Standbymodus befindet.

Dieses Lösungs-Playbook gilt für alle diese Fälle, solange es die Funktionen einer Aktiv-Passiv-Disaster Recovery-Topologie erfüllt, die im vorherigen Abschnitt beschrieben wurde. Es wird davon ausgegangen, dass das primäre und das sekundäre System bereits erstellt wurden.

Hinweis:

In diesem Dokument wird das Disaster Recovery-Setup nicht beschrieben.