Erste Schritte

Oracle WebLogic Server kann über mehrere On-Premise-Sites oder über mehrere Oracle Cloud Infrastructure-(OCI-)Regionen hinweg bereitgestellt werden.

Die Konfiguration in diesem Playbook verwendet eine einzelne Oracle WebLogic Server-Domain, in der Server in zwei Sites an demselben Cluster (einem gestreckten Cluster) teilnehmen und sich auf Data Guard verlassen, um den Schutz der Datenbank zu gewährleisten.

In OCI bieten Features wie Trafficmanagement, Health Checks, Load Balancer, private DNS-Ansichten und dynamische Routinggateways erweiterte Funktionen zur Unterstützung dieses Setups. Bei On-Premises-Umgebungen sollten entsprechende Netzwerk- und Infrastrukturkomponenten verwendet werden, um diese Anforderungen zu erfüllen.

Die Netzwerklatenz zwischen den Sites oder Regionen muss ausreichend niedrig sein, um die durch die Verzögerung der Aufrufe verursachte Performanceeinschränkung zu minimieren und Inkonsistenzen während der Bereitstellung und Laufzeit zu vermeiden. Oracle unterstützt diese Topologie nur, wenn die Latenz zwischen den WebLogic-Servern und der Datenbank unter 10 ms Roundtrip Time (RTT) liegt.

Um eine optimale Performance und ein optimales Failover-Verhalten zu erzielen, empfiehlt Oracle, dass Sie jede Anwendung analysieren, die in einem WebLogic-Stretch-Cluster ausgeführt wird, und die verschiedenen in diesem Playbook beschriebenen Parameter (Timeouts, Sessionreplikationskonfiguration, Service-Migrationsleasing, Java Transaction API (JTA) usw.) entsprechend anpassen.

Informationen zu gestreckten Oracle Fusion Middleware-Clustern

Die Bereitstellung der Maximum Availability Architecture (MAA) von Oracle ist eine der Hauptanforderungen für jedes Oracle Fusion Middleware-Unternehmens-Deployment.

Oracle Fusion Middleware umfasst ein umfangreiches Set an High-Availability-Features, wie Erkennung und Neustart von Prozessen, Server-Clustering, Servicemigration, GridLink, Load Balancing, Failover, Backup und Recovery, Rolling-Upgrades und Rolling-Konfigurationsänderungen, die ein Unternehmens-Deployment vor ungeplanten Ausfallzeiten schützen und geplante Ausfallzeiten minimieren. Diese Funktionen bieten eine lokale High Availability-Lösung in einem einzigen Data Center.

Darüber hinaus benötigen Anwendungen Schutz vor unvorhergesehenen Katastrophen, Naturkatastrophen und Ausfallzeiten, die sich auf ein gesamtes Data Center auswirken können. Die meisten herkömmlichen Katastrophenschutzsysteme verwenden das Aktiv-Passiv-Modell, bei dem ein Standby-Standort an einem geografisch anderen Ort als der Produktionsstandort eingerichtet wird. Dieses Modell wird normalerweise angewendet, wenn die Latenz zwischen den Sites hoch ist und kein Clustering über die beiden Sites hinweg zulässig ist. Dieser Ansatz bietet einen vollständigen Maximum Availability Architecture-(MAA-)Schutz. Dies führt jedoch zu zusätzlichen Betriebs- und Verwaltungskosten, da das Standby-Middleware-System das primäre System widerspiegelt und eine kontinuierliche Replikation erfordert. Dieses Modell wird im Oracle Fusion Middleware Disaster Recovery Guide beschrieben.

In diesem Playbook wird ein weiteres Modell beschrieben: das Active/Active-Modell, das auf gestreckten Oracle Fusion Middleware-Clustern basiert. Dieses Modell kann verwendet werden, um ein Oracle Fusion Middleware-System gegen Ausfallzeiten an mehreren Standorten zu schützen. Dieses Modell verwendet eine Aktiv/Aktiv-Konfiguration für die Middle Tier, während die Datenbankebene eine Aktiv/Passiv-Konfiguration mit Data Guard verwendet. Es wurde entwickelt, um die Kapazität zu optimieren und Workloads auf die Standorte zu verteilen. Sie nutzt die Ressourcen effektiver als das Active/Passive-Modell, indem sie alle verfügbaren Ressourcen nutzt, anstatt Standby-Rechner im Leerlauf zu lassen. Dieses Modell wird als Deployment gestreckter FMW-Cluster bezeichnet.

In diesem Playbook wird insbesondere beschrieben, wie dieses Modell in Oracle Cloud Infrastructure-(OCI-)Regionen implementiert wird. Sie enthält die Konfigurationsschritte zum Einrichten der empfohlenen Topologie sowie Anleitungen zur Performance und zu den Failover-Auswirkungen dieses Setups.

Die Ergebnisse und Beispiele in diesem Handbuch basieren auf einem Oracle SOA Suite 14.1.2-System, das der Enterprise Deployment Guide-Architektur folgt. Dies ist ein wichtiges Beispiel, da es viele Features wie standardmäßige Jakarta-Komponenten, HTTP-Sessionreplikation, Datenbankmetadatenpersistenz, ein Coherence-Cluster und persistente Speicher von Java Message Service (JMS) und Java Transaction API (JTA) umfasst, unter anderem relevante Überlegungen für gestreckte Cluster. Daher können die beschriebene Topologie und Empfehlungen auch auf andere Oracle Fusion Middleware-Umgebungen angewendet werden.

Terminologie

Hier sind die Definitionen einiger Begriffe, die in diesem Playbook verwendet werden:

  • 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 (Frontend) und dem Datenspeicher (Backend) liegt. Es verarbeitet Geschäftslogik, Datenverarbeitung und Sicherheit und fungiert als Brücke zwischen dem Benutzer und der Datenbank.

  • Oracle Fusion Middleware

    Oracle Fusion Middleware ist eine umfassende Familie von Middleware-Produkten für Unternehmen von Oracle, die es Unternehmen ermöglicht, Anwendungen effizient und sicher zu erstellen, bereitzustellen und zu verwalten. Es umfasst Lösungen für Anwendungsserver, Integration, Geschäftsprozessmanagement, Business Intelligence, Sicherheit, Identitätsmanagement, Webserver und mehr.

  • 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

    Fähigkeit zum Schutz vor natürlichen oder ungeplanten Ausfällen einer Produktionssite durch eine Wiederherstellungsstrategie für Anwendungen und Daten in einer geografisch getrennten Standy-Umgebung.

  • Oracle Maximum Availability-Architektur

    Die Maximum Availability-Architektur von Oracle (Oracle MAA) ist der Best Practice-Blueprint für den Datenschutz und die Verfügbarkeit von Oracle-Produkten (Oracle Database, Oracle 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 Empfehlungen des Oracle Fusion Middleware Enterprise Deployment Guide und fügt Best Practices für den 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. Im Abschnitt "Weitere Informationen durchsuchen" finden Sie Links zur zugehörigen Dokumentation und zu anderen Ressourcen.

  • Standort (oder Data Center)

    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.

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

  • Gestreckter Cluster

    Ein gestrecktes Cluster bezieht sich auf eine Clusterarchitektur, bei der die Knoten in einem einzelnen logischen Cluster über geografisch getrennte Data Center oder Standorte verteilt sind.

  • Switchover

    Bei einem Switchover werden die Rollen der Produktions-Site und der Standby Site umgekehrt. Switchover sind geplante Vorgänge, die zur regelmäßigen Validierung oder zur Durchführung einer geplanten Wartung am aktuellen Produktionsstandort durchgeführt werden. Bei einem Switchover wird die aktuelle Standby Site zur neuen Produktions-Site, und die aktuelle Produktions-Site wird zur neuen Standby Site. Dieses Playbook verwendet auch den Begriff Switchover, um sich auf einen Site Switchover zu beziehen.

  • Zurückwechseln

    Bei einem Switchback wird die aktuelle Produktions-Site und die aktuelle Standby Site auf ihre ursprünglichen Rollen zurückgesetzt. Switchbacks sind geplante Vorgänge, die nach Abschluss des Switchover-Vorgangs ausgeführt werden. Bei einem Switchback werden die ursprünglichen Rollen jeder Site wiederhergestellt: Die aktuelle Standby Site wird zur Production Site, und die aktuelle Production Site wird zur Standby Site. Dieses Playbook verwendet auch den Begriff "Switchback", um auf ein Site-Switchback zu verweisen.

  • Failover

    Failover ist der Prozess, bei dem die aktuelle Standby Site zur neuen Produktions-Site wird, nachdem die Produktions-Site unerwartet nicht mehr verfügbar ist, z.B. aufgrund eines Ausfalls an der Produktions-Site. Dieses Playbook verwendet auch den Begriff Failover, um sich auf ein Site Failover zu beziehen.

  • Recovery Point Objective (RPO)

    Recovery Point Objective ist die Menge an Datenverlust, die ein System aus geschäftlicher Sicht tolerieren kann, z. B. 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

    Oracle Cloud Infrastructure (OCI) besteht nicht nur aus einer 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. 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 mindestens ein Data Centre enthält, das Availability-Domains hostet. Regionen sind unabhängig von anderen Regionen, und große Entfernungen können über Länder oder Kontinente voneinander getrennt werden.

    Eine Region ist eine Site in Bezug auf Disaster Recovery.

  • Availability-Domain

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

  • Virtuelles OCI-Cloud-Netzwerk und Subnetz

    Ein virtuelles Cloud-Netzwerk (VCN) ist ein anpassbares, softwaredefiniertes Netzwerk, das Sie in einer OCI-Region einrichten. Wie herkömmliche Data Center-Netzwerke erhalten Sie über VCNs die Kontrolle über Ihre Netzwerkumgebung. Ein VCN kann mehrere nicht überschneidende CIDR-Blöcke aufweisen, die Sie nach dem Erstellen des VCN ändern können. Sie können ein VCN in Subnetze segmentieren, die sich auf eine Region oder eine Availability-Domain beschränken. Jedes Subnetz besteht aus einem Bereich zusammenhängender Adressen, die sich nicht mit anderen Subnetzen im VCN überschneiden. Sie können die Größe eines Subnetzes nach der Erstellung ändern. Ein Subnetz kann öffentlich oder privat sein.

  • Dynamisches Routinggateway (DRG)

    Das DRG ist ein virtueller Router, der einen Pfad für den privaten Netzwerktraffic zwischen VCNs in derselben Region zwischen einem VCN und einem Netzwerk außerhalb der Region bereitstellt, z.B. ein VCN in einer anderen OCI-Region, ein On-Premise-Netzwerk oder ein Netzwerk in einem anderen Cloud-Provider.

  • OCI-DNS

    Der Oracle Cloud Infrastructure Domain Name System-(DNS-)Service ist ein hoch skalierbares, globales Anycast-Domain Name System-(DNS-)Netzwerk, das verbesserte DNS-Performance, Resilienz und Skalierbarkeit bietet, sodass Endbenutzer von überall aus schnell eine Verbindung zu Internetanwendungen herstellen können.

  • Private OCI DNS-Ansicht

    Eine private OCI-DNS-Ansicht ist eine Sammlung aus einer oder mehreren privaten OCI-DNS-Zonen, mit denen DNS-Zonen logisch gruppiert und gesteuert werden, wie sie aufgelöst werden. Eine Ansicht ist an einen privaten DNS-Resolver angehängt, der der Standardresolver für ein virtuelles Cloud-Netzwerk (VCN) oder ein benutzerdefiniertes sein kann. Auf diese Weise können Sie separate DNS-Konfigurationen für verschiedene Umgebungen oder Anwendungen in Ihrem VCN verwalten.

  • Virtuelles IP

    Eine virtuelle IP-Adresse (VIP) bezieht sich auf eine IP-Adresse, die nicht an eine bestimmte physische Netzwerkschnittstelle oder ein bestimmtes physisches Gerät gebunden ist. Stattdessen ist es abstrahiert und kann zwischen Geräten wechseln oder für verschiedene Netzwerkfunktionen verwendet werden.

  • OCI-Trafficmanagement

    OCI Traffic Management leitet den Benutzertraffic mithilfe erweiterter DNS-basierter Policys (OCI-Trafficsteuerungs-Policys) intelligent an optimale Endpunkte weiter. Dadurch können Unternehmen kontrollieren, wie DNS-Abfragen aufgelöst werden, und das Routing von Clientanforderungen optimieren, um die Verfügbarkeit, Performance und Resilienz von Anwendungen oder Services zu verbessern, die auf OCI oder anderswo bereitgestellt werden.

  • Load Balancer

    Ein Load Balancer ist ein System oder ein Service, der eingehenden Netzwerktraffic auf mehrere Server verteilt, um High Availability, Zuverlässigkeit und optimale Performance von Anwendungen sicherzustellen.

  • OCI Load Balancer

    OCI Load Balancer ist ein vollständig verwalteter Oracle Cloud Infrastructure-Service, der eingehenden Traffic automatisch auf mehrere Backend-Server oder -Ressourcen verteilt, um High Availability, bessere Performance und Skalierbarkeit für Anwendungen sicherzustellen.

  • Block Storage

    Block Storage ist eine Art von Datenspeicher, bei dem Informationen in Blöcken fester Größe gespeichert werden und direkt von Servern oder Anwendungen über Speicherprotokolle wie iSCSI oder Fibre Channel aufgerufen werden können.

  • OCI-Block-Volumes

    Mit Oracle Cloud Infrastructure Block Volumes können Sie Speicher-Volumes erstellen, anhängen, verbinden und verschieben sowie die Volume-Performance ä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. Sie können ein Volume auch trennen und an eine andere Instanz anhängen, ohne Daten zu verlieren.

  • Gemeinsamer Speicher

    Shared Storage bezeichnet ein Speichersystem oder eine Ressource, auf die gleichzeitig mehrere Server, Computer oder Anwendungen innerhalb einer IT-Umgebung zugreifen können. Mit diesem Setup können alle teilnehmenden Systeme aus demselben Daten-Repository lesen und in dieses schreiben. Dies ist ideal für Szenarien, die Datenkonsistenz, Zusammenarbeit, High Availability und Skalierbarkeit erfordern.

  • OCI File Storage

    Oracle Cloud Infrastructure File Storage stellt ein dauerhaftes, skalierbares und sicheres Netzwerkdateisystem der Unternehmensklasse dar. Sie können von jeder Bare-Metal-, Virtual-Machine- oder Containerinstanz in einem VCN eine Verbindung zu OCI File Storage herstellen. Sie können auch von außerhalb des VCN auf OCI File Storage zugreifen, indem Sie Oracle Cloud Infrastructure FastConnect und IPSec VPN verwenden.

  • OCI-Datenbankdienste

    OCI-Datenbankservices beziehen sich auf das Portfolio von verwalteten Datenbanklösungen, die von Oracle Cloud Infrastructure (OCI) bereitgestellt werden. Diese Services bieten eine Vielzahl von Datenbankbereitstellungs- und -verwaltungsoptionen in der Oracle Cloud und unterstützen verschiedene Workloads, Performanceanforderungen und Datenmodelle, wie Oracle Base Database Service und Oracle Exadata Database Service.

  • Oracle Data Guard

    Oracle Data Guard und Active Data Guard bieten ein umfassendes Set an Services, mit denen eine oder mehrere Standbydatenbanken erstellt, gewartet, verwaltet und überwacht werden können und die es Oracle-Produktionsdatenbanken ermöglichen, ohne Unterbrechung verfügbar zu bleiben. Oracle Data Guard verwaltet diese Standbydatenbanken mit In-Memory-Replikation als Kopien der Produktionsdatenbank. Wenn die Produktionsdatenbank aufgrund eines geplanten oder ungeplanten Ausfalls nicht verfügbar ist, kann Oracle Data Guard jede Standbydatenbank auf die Produktionsrolle umstellen und so die Ausfallzeit minimieren, die mit dem Ausfall verbunden ist. Oracle Active Data Guard bietet die zusätzliche Möglichkeit, Workloads mit Lesezugriffen in Standbydatenbanken auszulagern, und bietet außerdem erweiterte Datenschutzfunktionen.

In diesem Playbook wird OCI als Beispielinfrastruktur für das Deployment von gestreckten Oracle Fusion Middleware-Clustern verwendet. Dies sind die Äquivalenzen zwischen On-Premises und OCI für die Hauptkomponenten, die für das Oracle Fusion Middleware-Clustersetup erforderlich sind:

On-Premises (oder allgemein) OCI-Äquivalent
Standort (oder Data Center) OCI-Region
Shared Storage (z.B. NFS) OCI File Storage
Block Storage OCI-Block-Volumes
Globaler Load Balancer OCI Traffic Management und Steuerungs-Policys
Lokaler Load Balancer OCI Load Balancer
Netzwerk Virtuelles OCI-Cloud-Netzwerk
Firewall-/Firewallregeln OCI-Netzwerksicherheitsregeln
Internes DNS Private OCI DNS-Ansicht
Physischer Server/virtuelle Maschine OCI Compute-Instanz
On-Premise-Datenbank OCI-Datenbankservice
On-Premise-Konnektivität zwischen Standorten OCI-Remote-Peering mit dynamischem Routinggateway

Architektur

In diesem Abschnitt werden die Topologie und Überlegungen für die gestreckte Clusterarchitektur von Oracle Fusion Middleware (FMW) beschrieben.

Folgende Überlegungen gelten für die gestreckte FMW-Clusterarchitektur:

  • Bereiche

    Diese Topologie enthält zwei Regionen oder Standorte. Die Latenzzeit zwischen ihnen sollte nicht höher als 10 ms Roundtrip Time (RTT) sein. Die Anforderungen an die Bandbreite hängen von den Payloads ab, die von jedem System verarbeitet werden. Es wird jedoch empfohlen, mindestens 1 oder 2 Gigabit pro Sekunde (Gbit/s) zu verwenden.

  • Mittlere Stufe

    Die Middle Tier wird in einem Active/Active-Modell mit einer einzelnen Domain ausgeführt. Die Hälfte der Managed Server wird an einem Standort bereitgestellt, der Rest an dem anderen Standort. Der Administration Server wird auf einer Site ausgeführt, kann jedoch bei Bedarf ein Failover auf die andere Site ausführen. Dieses Setup wird im Allgemeinen als gestrecktes Cluster bezeichnet.

  • Datenbankebene

    Die Datenbankebene verwendet eine Active/Passive-Architektur, die von Oracle Data Guard unterstützt wird. Die Primärdatenbank befindet sich an einer Site, während sich die Standbydatenbank an der anderen Site befindet. Alle Middle Tier-Server sind so konfiguriert, dass sie sich unabhängig von ihrem Speicherort bei der Datenbank anmelden, die derzeit als primäre Datenbank dient. Die in jeder Site konfigurierte Oracle Database ist eine Oracle Real Application Clusters (Oracle RAC). Oracle RAC ermöglicht es einer Oracle-Datenbank, auf einem Servercluster im selben Data Center ausgeführt zu werden. Dadurch werden Fehlertoleranz, Performance und Skalierbarkeit ohne Anwendungsänderungen bereitgestellt.

  • Speicherung

    Der Shared Storage ist lokal für jeden Standort. Aus Gründen von Zugriffskonflikten und Sicherheit wird die Verwendung von Shared Storage über Standorte hinweg nicht empfohlen. Datenträgerspiegelung oder -replikation von site1 bis site2 und umgekehrt wird empfohlen, um eine wiederherstellbare Kopie der Artefakte in jeder Site bereitzustellen.

  • Persistente Speicher

    Die persistenten Speicher (Java Message Service (JMS) und die Java Transaction API (JTA)) von WebLogic werden als JDBC-(Java Database Connectivity-)Speicher in der Datenbank konfiguriert. Auf diese Weise sind sie von beiden Seiten erreichbar. Dadurch kann das Feature "Automatische Servicemigration" zwischen beiden Sites funktionieren.

  • Anforderungsweiterleitung

    Die Webserver an jeder Site leiten Anforderungen nur an die Oracle WebLogic Server-Instanzen weiter, die sich in derselben Site befinden. Es erfolgt keine regionsübergreifende Kommunikation zwischen den Webservern (Oracle HTTP Server-Instanzen) und den WebLogic-Servern auf der anderen Site, um Latenz und regionsübergreifenden Traffic zu minimieren.

  • Load Balancer

    Jede Site verfügt über einen eigenen dedizierten Load Balancer, der Anforderungen ausschließlich an die Webserver innerhalb dieser lokalen Site weiterleitet. Es gibt keine regionsübergreifende Kommunikation zwischen den Load Balancern und den Webservern, die sich auf der anderen Site befinden.

  • Frontend-Zugang

    Vor dem System bietet die Lösung einen einzigen Front-End-Zugang zum System. Clients verbinden sich mit einer einzigen Adresse, die unabhängig von der Site, an die sie weitergeleitet werden, gleich bleibt. Dieser Mechanismus bietet einen Domain Name System (DNS), der für alle Clients zugänglich ist und Anforderungen basierend auf vordefinierten Kriterien und Regeln, wie dem geografischen Standort des Clients, an jede Site weiterleitet.

Das folgende Diagramm veranschaulicht die gedehnte Clustertopologie von Oracle Fusion Middleware


Beschreibung von stretched-cluster-topology.png folgt
Beschreibung der Abbildung stretched-cluster-topology.png

gestreckt-Cluster-Topologie-oracle.zip

Das folgende Diagramm veranschaulicht die Domain WebLogic und die Cluster in der gestreckten Clustertopologie von Oracle Fusion Middleware:


Beschreibung von stretched-cluster-topology-wls-domain.png folgt
Beschreibung der Abbildung stretched-cluster-topology-wls-domain.png

gestreckt-Cluster-Topologie-WLS-Domain-oracle.zip

Vorteile

Die Vorteile der Verwendung des gestreckten Oracle Fusion Middleware-(FMW-)Clustermodells gegenüber dem herkömmlichen Active/Passive-Modell umfassen Folgendes:
  • Einfachere Administration

    Für Active/Passive-Deployments entsteht ein zusätzlicher Administrations-Overhead, damit die Konfiguration zwischen der primären und der Standby Site synchronisiert bleibt. Obwohl die meisten Laufzeitinformationen und Metadaten in der Datenbank gespeichert sind, befindet sich die Oracle WebLogic Server-Konfiguration im Dateisystem. Zusätzlich zur Oracle Data Guard-Replikation für die Datenbank erfordert das Active/Passive-Modell eine kontinuierliche Dateisystemreplikation, die auf verschiedene Weise implementiert werden kann (rsync, Replikation auf Speicherebene usw.).

    Die Oracle WebLogic Server-Infrastruktur sorgt jedoch dafür, dass die Konfiguration im gestreckten FMW-Clustermodell über mehrere Knoten in derselben Domain synchronisiert bleibt. Der Großteil dieser Konfiguration befindet sich in der Regel im Domänenverzeichnis des Administration Servers. Diese Konfiguration wird automatisch an die anderen Knoten in derselben Domain propagiert, wenn die Managed Server gestartet werden oder wenn eine Änderung implementiert wird. Aus diesem Grund ist der Administrations-Overhead des Deployments im Vergleich zu jedem Active-Passive-Ansatz sehr gering, bei dem eine konstante Replikation von Konfigurationsänderungen erforderlich ist.

  • Verbesserte Verfügbarkeit und geringeres RTO und RPO für einige Failover-Szenarien

    Das gestreckte FMW-Clustermodell bietet in diesen Szenarien ein besseres Recovery Point Objective (RPO) und Recovery Time Objective (RTO) als das aktiv-passive Modell:

    • Vollständiger Middle Tier-Fehler in einem Site-Ereignis

      Wenn alle Middle Tier-Server an einem Speicherort ausfallen, kann das System die Anforderungen sofort mit den Middle Tier-Servern auf der Peer Site erfüllen. RTO und RPO sind in diesem Szenario Null.

      Um dies zu erreichen, müssen die Middle Tier-Server am alternativen Standort in der Lage sein, die kombinierte Workload der beiden Standorte aufrechtzuerhalten. Es muss eine angemessene Kapazitätsplanung durchgeführt werden, um solche Szenarien zu berücksichtigen. Je nach Design müssen Anforderungen von Endclients möglicherweise gedrosselt werden, wenn nur eine Site aktiv ist. Andernfalls müssen Standorte mit hoher Kapazität ausgelegt werden, was zum Teil den Zweck einer konstanten und effizienten Kapazitätsauslastung verfehlt.

    • Fehler in Datenbank-Tier-Ereignissen

      Bei einem Switchover der Datenbank werden dieselben RTO- und RPO-Werte in einem Active-Passive- und im FMW-gedehnten Clustermodell verwendet. Das gesamte RTO des Systems ist jedoch im gestreckten Clustermodell niedriger, da die Mid-Tier-Server bereits am sekundären Standort aktiv sind. Ein Neustart der Middle Tiers ist nicht erforderlich. Eine geeignete Datenquellenkonfiguration, die eine duale Verbindungszeichenfolge mit GridLink- und Fast Application Notification-(FAN-)Benachrichtigungen verwendet, automatisiert das Failover der Datenbankverbindungen von den Middle Tiers und reduziert so das RTO des Systems.

Hinweise

Beim Implementieren des gestreckten Oracle Fusion Middleware-(FMW-)Clustermodells sollten Sie Folgendes beachten:
  • Kapazitätsplanung

    Für dieses Modell ist eine Kapazitätsplanung erforderlich, um Failover-Szenarios zwischen den beiden Sites zu berücksichtigen. Wenn eine gesamte Site die Middle Tiers verliert, muss die andere in der Lage sein, die gesamte Workload aufrechtzuerhalten. Andernfalls kann die verfügbare Site aufgrund des Overheads möglicherweise nicht mehr reagieren. Dies bedeutet, dass die Middle Tier-Knoten während des normalen Betriebs zu wenig ausgelastet sein müssen, um ausreichend Kapazität für Failover-Szenarios zu ermöglichen. Dieselbe Regel gilt für die Web Tier. Wenn eine Site alle ihre Webserver verliert, müssen die Webserver auf der anderen Site in der Lage sein, alle Systemanforderungen zu verarbeiten.

  • Netzwerkdurchsatz standortübergreifend

    Der Netzwerkdurchsatz hängt hauptsächlich von zwei Dingen ab: Wie weit die Standorte sind und wie gut das Netzwerk mit Zuverlässigkeit und Überlastung umgeht. Unabhängig davon, wie schnell die Server oder Software sind, gibt es eine Grenze dafür, wie schnell Daten zwischen den Standorten verschoben werden können. Zwei wichtige Faktoren, die dies beeinflussen, sind Latenz und Jitter:

    • Latenz ist die Zeit, die benötigt wird, um Daten von einer Site zur anderen über das Netzwerk zu übertragen. Es kann einseitig (von Quelle zu Ziel) oder Hin- und Rückfahrt (dort und zurück) gemessen werden. Die Roundtrip-Zeit (RTT) ist häufiger und kann mit dem Befehl ping geprüft werden.

    • Jitter ist die Variation der Zeit, die für das Eintreffen von Datenpaketen benötigt wird.

    Für das aktuelle Modell ist es besonders wichtig, die Latenz niedrig zu halten, da Jitter in der Regel nur dann wichtig ist, wenn die Latenz bereits sehr gering ist. Daher ist die Kontrolle der Latenz die Hauptpriorität für eine gute Leistung bei dieser Art von Setup. Der Abstand ist in der Regel die relevanteste Ursache für Latenz.

    Die durchgeführten Tests haben gezeigt, dass sich die Performance in diesem Modell (wo sich einige Oracle WebLogic Server-Instanzen im Cluster an einer anderen Site als die Datenbank befinden) erheblich verschlechtert, wenn die Latenz (RTT) 10 Millisekunden überschreitet.

    Oracle hat mehrere Tests mit verschiedenen Konfigurationen durchgeführt, die von verschiedenen Latenzzeiten betroffen sind. Die in diesem Playbook gezeigten Referenzlatenzen unterscheiden zwischen Clustern mit:
    • Alle Mitglieder in derselben Availability-Domain
    • Mitglieder in verschiedenen Availability-Domains
    • Mitglieder in zwei nahe gelegenen, aber unterschiedlichen OCI-Regionen

    Die folgende Abbildung zeigt den Durchsatz (Transaktionen pro Sekunde) für ein Oracle Fusion Middleware SOA-System, auf dem die Fusion Order Demo (FOD) für verschiedene Latenzzeiten zwischen dem WebLogic-Server und der Datenbank ausgeführt wird:


    Beschreibung von wls-server-throughput.png folgt
    Beschreibung der Abbildung wls-server-throughput.png

    Die folgende Abbildung zeigt die aktive Zeit der Java Transaction API (JTA) für ein Oracle Fusion Middleware-SOA-System, auf dem die Fusion Order Demo (FOD) ausgeführt wird, die eine Datenbank auf einer anderen Site mit unterschiedlichen Latenzzeiten zwischen Sites verwendet:


    Beschreibung von wls-average-jta-active-time.png folgt
    Beschreibung der Abbildung wls-average-jta-active-time.png

    Die folgende Abbildung zeigt die Verschlechterung des gesamten Systemdurchsatzes bei Transaktionen pro Sekunde für verschiedene Latenzzeiten zwischen den Sites (beide Sites arbeiten zusammen mit der Datenbank an einem der Sites).


    Beschreibung von system-throughput.png folgt
    Beschreibung der Abbildung system-throughput.png

    Hinweis:

    Angesichts all der oben genannten Aspekte und der in vielen Tests beobachteten Leistungsstrafen unterstützt Oracle keine gestreckten Oracle Fusion Middleware-Cluster, die eine Latenzzeit von mehr als 10 Millisekunden (RTT) zwischen den Sites überschreiten. Systeme können ohne Probleme funktionieren, aber die Transaktionszeiten werden erheblich steigen. Latenzzeiten über 10 Millisekunden (RTT) führen auch zu Problemen im Oracle Coherence-Cluster, das für Deployment und JTA, Webservices oder Anwendungstimeouts verwendet wird. Dadurch eignen sich die in diesem Playbook vorgestellten Lösungen vor allem für Sites oder Regionen mit geringer Latenz dazwischen.

  • Regionsübergreifender Datenverkehr

    Im aktuellen Modell müssen Sie den Datenverkehr über Standorte hinweg minimieren, um die Auswirkungen der Latenz auf den Systemdurchsatz zu reduzieren. In einem typischen FMW-System sind die Kommunikation zwischen den verschiedenen Ebenen oder Elementen:

    • Zugriff auf die Datenbank von den Oracle WebLogic Server-Instanzen für Metadatenzugriff und andere Lese-/Schreibvorgänge der Datenbank.

    • Eingehende HTTP-Aufrufe von Load Balancern (LBR) oder Oracle HTTP Server-Instanzen und HTTP-Callbacks.

    • Java Naming and Directory Interface-(JNDI-)/Remote Method Invocation-(RMI-) und Java Message Service-(JMS-)Aufrufe zwischen Oracle WebLogic Server-Instanzen.

    • Oracle Coherence-Benachrichtigungen zwischen allen Servern im System. Beispiel: SOA verwendet Coherence, um ein konsistentes Composite- und Metadatenimage bereitzustellen.

    • HTTP-Sessionreplikationen zwischen den Oracle WebLogic Server-Instanzen. Einige Komponenten verwenden zustandsbehaftete Webanwendungen, die möglicherweise auf der Sessionreplikation basieren, um ein transparentes Failover von Sessions über Server hinweg zu ermöglichen. Abhängig von den Nutzungsmustern und der Anzahl der Benutzer kann dies eine beträchtliche Menge an Replikationsdaten generieren.

    • Der Lightweight Directory Access Protocol-(LDAP-)/policy/identity-Speicherzugriff wird von der Oracle WebLogic Server-Infrastruktur zu Autorisierungs- und Authentifizierungszwecken ausgeführt. Idealerweise sollte jede Site über einen unabhängigen Identity- und Policy-Speicher verfügen, der regelmäßig synchronisiert wird, um Aufrufe von einer Site zur anderen zu minimieren. Alternativ können beide Sites denselben Store teilen. Die Auswirkungen der gemeinsamen Nutzung der Filiale hängen vom Typ der Filiale und dem Nutzungsmuster des Systems ab.

    Wenn möglich, sollten alle oben genannten Elemente in der Website enthalten sein, um die Leistung zu verbessern. Beispiel:

    • Die Server in einer Site dürfen nur Aufrufe von Oracle HTTP Server-Instanzen in derselben Site empfangen.

    • Die Server in einer Site sollten JMS-, RMI- und JNDI-Aufrufe nur für Server in derselben Site vornehmen und Callbacks abrufen, die von Servern nur auf derselben Site generiert werden.

    • Die HTTP-Sessionreplikation sollte nur auf die anderen Server auf derselben Site beschränkt werden. Replikations- und Failover-Anforderungen müssen für jeden Business Case analysiert werden. Im Idealfall sollte jedoch der Traffic der Sessionreplikation über Standorte hinweg so weit wie möglich reduziert werden.

  • Gemeinsamer Speicher

    Die Latenz für Schreibvorgänge in Netzwerkdateisystemen (NFS) über Standorte hinweg kann zu einer starken Performanceverschlechterung führen. Die Server sollten lokale Speichergeräte für ihren Standort verwenden, um Konflikte bei Lese-/Schreibanforderungen an Dateisysteme zu vermeiden. Shared Storage sollte auf die einzelnen Sites beschränkt sein.

  • Andere Ressourcen

    Die beiden Sites können andere externe Ressourcen wie LDAP, externe JMS-Ziele, externe Webservices usw. gemeinsam verwenden. Es ist erforderlich, dass diese Ressourcen in beiden Standorten konsistent verfügbar sind. Die Konfigurationsdetails für diese externen Ressourcen liegen außerhalb des Geltungsbereichs dieses Playbooks.