FMW-gestreckte Cluster einrichten

Regionen einrichten

Das gestreckte Oracle Fusion Middleware-(FMW-)Clustermodell wird über zwei getrennte Sites konfiguriert.

In Oracle Cloud Infrastructure (OCI) können Sie es über OCI-Regionen hinweg implementieren, die eine geringe Latenz zwischen ihnen aufweisen. Die maximal unterstützte regionsübergreifende Latenzzeit beträgt 10 ms Roundtrip Time (RTT). Sie können die Latenz zwischen Regionen in der OCI-Konsole prüfen, indem Sie Networking, Network Command Center, Regionsübergreifende Latenz auswählen.

In Anbetracht der Latenzwerte können Sie dieses Modell zwischen Regionen wie Frankfurt und Amsterdam bereitstellen, die 6-7 ms RTT haben. Sie können dieses Modell jedoch nicht zwischen Standorten wie Ashburn und Phoenix bereitstellen, da die Latenz zwischen diesen Regionen 50 ms RTT überschreitet.

Beispiel für Regionspaare mit regionsübergreifender Latenz kleiner als 10 ms RTT:

Amsterdam (AMS) - Paris (CDG)
Amsterdam (AMS) - Newport (CWL)
Amsterdam (AMS) - Frankfurt (FRA)
Amsterdam (AMS) - London (LHR)
Paris (CDG) - Frankfurt (FRA)
Paris (CDG) - London (LHR)
Paris (CDG) - Newport (CWL)
Marseille (MRS) - Mailand (LIN)
Zürich (ZHR) - Frankfurt (FRA)
Zürich (ZHR) - Mailand (LIN)
Osaka (KIX) - Tokio (NRT)
Singapur (SIN) - Batan (HSG)
Sao Paulo (GRU) - Vinhedo (VCP)
Singapur (SIN) - Singapur 2 (XSP)
Batan (HSG) - Singapur 2 (XSP)
Seoul (ICN) - Chuncheon (YNY)
Toronto (YYZ) - Montreal (YUL)

In Bezug auf die Bandbreite gibt es keine garantierte Bandbreite zwischen OCI-Regionen, und OCI bietet kein spezifisches OCI-Bandbreitenmessungstool. Für genaue Bandbreitenmessungen verwenden Sie Tools wie iPerf. Die getestete Bandbreite zwischen Frankfurt und Amsterdam beträgt etwa 2–2,5 Gigabit pro Sekunde (Gbit/s).

Sie können dieses Modell auch zwischen Availability-Domains (ADs) implementieren, die sich in derselben Region befinden. Die Bereitstellung der Oracle WebLogic Server-Server über ADs hinweg ist in der Tat das Standardverhalten in Platform-as-a-Service-(PaaS-)Services wie Oracle SOA Suite on Marketplace- und Oracle WebLogic Server for OCI-Stacks. Die Implementierung dieses Modells über ADs statt über Regionen hinweg ist jedoch keine Katastrophenschutzlösung, da es nicht vor Ereignissen schützt, die sich auf eine gesamte Region auswirken.

Tipp:

Um die Subnetze, Regeln, Compute-Instanzen, Shared Storage und Load Balancer zu erstellen, die für ein FMW-Deployment in jeder Site erforderlich sind, können Sie das WLS-HYDR-Framework verwenden (siehe die Prozedur "Infrastruktur erstellen").

Netzwerk einrichten

Die virtuellen Cloud-Netzwerke (VCNs) in den Regionen, in denen Sie diese Topologie bereitstellen, müssen miteinander verbunden sein, um Traffic zwischen allen WebLogic-Servern im Cluster und von den WebLogic-Servern zu den Datenbanken zuzulassen.

Die folgenden Netzwerkfunktionen sind für das Setup erforderlich:

Ein VCN und gestaffelte Subnetze in jeder Region.
Eine Remote-Peering-Verbindung zwischen den VCNs mit dynamischen Routinggateways (DRGs).
Die entsprechenden Routingregeln, um den Traffic zwischen den Sites weiterzuleiten. In Region 1 müssen die Routentabellen eine Route zum VCN-CIDR der Region 2 über das dynamische Routinggateway enthalten. Ebenso sollten Region 2-Routentabellen eine Route zum VCN-CIDR der Region 1 über das dynamische Routinggateway enthalten.
Die Netzwerksicherheitsregeln, um die folgende Kommunikation für das gestreckte Cluster zu ermöglichen:
- Öffnen Sie die WebLogic Server- und Node Manager-Ports zwischen den Mid-Tier-Subnetzen der Region 1 und Region 2. Wenn Coherence verwendet wird, erlauben Sie auch TCP- und UDP-Traffic für die Coherence-Ports.
- Traffic an den Datenbank-Listener und Oracle Cloud Infrastructure Notifications-(ONS-)Ports in beiden Regionen aus den Mid-Tier-Subnetzen der Region 1 und 2 zulassen.
- Standardmäßig ist keine regionsübergreifende Kommunikation zwischen OHS- und WebLogic-Servern erforderlich. WebLogic Server-Ports im Mid-Tier-Subnetz dürfen nur von OHS-Servern in derselben Region zugänglich sein. In Ausnahmefällen kann jedoch eine regionsübergreifende Kommunikation erforderlich sein, z. B. wenn alle Webserver in einer Region ausfallen. Weitere Details finden Sie im Abschnitt "Fehler verwalten".
Alle vom System verwendeten Hostnamen (WebLogic Listen-Adressen, SCAN- und VIP-Adressen der Primär- und Standbydatenbank) müssen von beiden Sites aufgelöst werden können. Standardmäßig können die Hostnamen in OCI nur innerhalb jedes VCN aufgelöst werden. Damit die Namen von Region 1 in Region 2 aufgelöst werden können, erstellen Sie eine private DNS-Ansicht in Region 2 für die Domain von Region 1, und fügen Sie die relevanten Namen und IP-Adressen hinzu. Wiederholen Sie diesen Vorgang in Region 1, um Namen aus Region 2 aufzulösen.
An jedem Standort muss der Frontend-Name des Systems (wie frontend.example.com) auf die IP-Adresse des lokalen Load Balancers verweisen. Um dies zu erreichen, fügen Sie den Frontend-Namen einer privaten DNS-Ansicht in jeder Region oder der Datei /etc/hosts der Mid-Tier-Hosts hinzu. Dadurch wird sichergestellt, dass alle Callbacks von einem WebLogic-Server zum Frontend an die lokale Region weitergeleitet werden.

Datenbank einrichten

Richten Sie ein Oracle Real Application Clusters-(Oracle RAC-)Datenbanksystem in Region 1 mit einem Standby-RAC-Datenbanksystem in Region 2 ein.

Es ist wichtig, RAC in jeder Region zu verwenden, da lokale High Availability eine wichtige Anforderung ist. Die Konfiguration einer Availability-Domain (AD) oder eines regionsübergreifenden Schutzes ist nur wirksam, wenn bereits ein zuverlässiger Schutz vor lokalen Ausfällen in einer einzelnen Region vorhanden ist. Wenn lokale High Availability, wie sie von RAC bereitgestellt wird, nicht implementiert wird, wird durch das Hinzufügen von Schutz über mehrere ADs oder Regionen hinweg das Risiko von Fehlern in der lokalen Umgebung nicht behoben.

Um die Verbindung der Anwendung aufrechtzuerhalten und Oracle Notification Service-Benachrichtigungen bei Fehlern des RAC-Datenbankknotens oder der Instanz zu erhalten, stellen Sie sicher, dass die Anwendung mit einem Cluster Ready Services-(CRS-)Datenbankservice eine Verbindung zur pluggable database (PDB) herstellt. Derselbe CRS-Service muss in Primär- und Standbydatenbank vorhanden sein. Beispielbefehle zum Erstellen eines Service für die Anmeldung bei der PDB:


srvctl add service -db $ORACLE_UNQNAME -service pdbservice.example.com -preferred ORCL1,ORCL2 -pdb pdb1 
srvctl modify service -db $ORACLE_UNQNAME -service pdbservice.example.com -rlbgoal SERVICE_TIME -clbgoal SHORT

Shared Storage einrichten

Oracle Cloud Infrastructure File Storage ist ein vollständig verwalteter, skalierbarer und sicherer Dateisystemservice, der von OCI bereitgestellt wird. Es wurde entwickelt, um leistungsstarken Dateispeicher für Unternehmensanwendungen bereitzustellen, die gemeinsam genutzte und persistente Dateisysteme erfordern.

Mehrere Compute-Instanzen können dasselbe Dateisystem gleichzeitig über das Network File System-(NFS-)Protokoll mounten und darauf zugreifen.

Das gestreckte Oracle Fusion Middleware-(FMW-)Clustermodell in OCI verwendet OCI File Storage-Systeme in jeder Region für die gemeinsamen Dateisysteme (z.B. für die gemeinsame Konfiguration oder für gemeinsame Laufzeitdaten). OCI File Storage bietet High Availability in der Region: Es verwendet intern redundanten Speicher über mehrere Faultdomains innerhalb einer Availability-Domain. Auf OCI File Storage kann jedoch nicht regionsübergreifend zugegriffen werden. Daher ist der Shared Storage lokal in der Region.

Verwenden Sie lokale Backups und Dateisystemreplikate zwischen Regionen, um eine wiederherstellbare Kopie der Artefakte bereitzustellen.

Middle Tier einrichten

Die Compute Nodes der mittleren Netzwerkebene sind über die beiden Regionen verteilt.

Die Rechenknoten der mittleren Netzwerkebene sind über die beiden Regionen verteilt, wobei sich die Hälfte der Knoten in Region 1 und die andere Hälfte in Region 2 befindet. Der Provisioning- und Installationsprozess ist mit dem beim Erstellen einer einzelnen WebLogic-Domain identisch. Um die High Availability-Features (wie Java Message Service (JMS) und Java Transaction API (JTA) Service-Migration, Administration Server Failover, automatische Crash-Erkennung mit Node Manager usw.) zu implementieren, verwenden Sie die Best Practices, die in den FMW Enterprise Deployment Guides empfohlen werden, die im Abschnitt "Weitere Informationen" referenziert werden.

Sie können die Domain von Anfang an erstellen und mit allen Managed Servern konfigurieren, oder Sie können eine vorhandene Domain, die in einer einzelnen Region ausgeführt wird, horizontal skalieren, indem Sie Knoten in der anderen Region hinzufügen.

Hinweis:

Das gestreckte Oracle Fusion Middleware-(FMW-)Clustermodell kann auf Domains angewendet werden, die mit Platform-as-a-Service-(PaaS-)Services wie Oracle WebLogic Server for OCI- und Oracle SOA Suite on Marketplace-Stacks erstellt wurden. Die Provisioning- und Scale-out-Features dieser PaaS-Services unterstützen standardmäßig nur eine einzelne Region. Daher müssen Sie das Cluster manuell horizontal skalieren, um Knoten in einer anderen Region hinzuzufügen. Die erforderlichen Schritte zur Ausführung dieses Vorgangs finden Sie in den Verfahren zum Skalieren eines WLS-Clusters. Beachten Sie, dass diese PaaS-Services keine Web-Tier enthalten und bestimmte Best Practices für High Availability, wie Administration Server-Failover, nicht implementieren. Daher gelten einige der Empfehlungen in diesem Dokument möglicherweise nicht für diese Umgebungen.

Dies sind die wichtigsten Aspekte, die bei der Verwendung des gestreckten FMW-Clustermodells in der Konfiguration WebLogic implementiert werden müssen:

Persistente Datenbankspeicher verwenden
Oracle unterstützt Stretch-Cluster, die persistente Datenbankspeicher für Oracle WebLogic Server-Transaktionslogs und JMS verwenden. Das Speichern der Transaktionslogs und persistenten Daten in der Datenbank nutzt die integrierten Replikations- und High-Availability-Features der Datenbank, wie Oracle Real Application Clusters (Oracle RAC) und Oracle Data Guard. Mit JMS, Transaktionsprotokollen (TLOGs) und Metadaten in einer geschützten Data Guard-Datenbank wird die Cross-Site-Synchronisierung vereinfacht und Konsistenz auf Anwendungsebene gewährleistet. Dies bedeutet auch, dass die Middle Tier keinen Shared Storage mehr für diese Artefakte benötigt (obwohl sie noch für Administration Server Failover, Deployment-Pläne und einige Adapter wie File Adapter erforderlich ist).

Die Verwendung von TLOGs und JMS in der Datenbank beeinträchtigt jedoch die Systemperformance. Diese Strafe wird erhöht, wenn eine der mittleren Ebenen mit der Datenbank auf der anderen Seite kommunizieren muss. Aus Performance-Sicht hätte ein Shared Storage, der sich lokal auf jeder Site befindet, eine bessere Performance. Dies führt jedoch zu Komplexität und Einschränkungen, um keinen Datenverlust zwischen Regionen und Anwendungskonsistenz zu gewährleisten.
Lokale Shared File System-Artefakte in jeder Region
Wie in den Oracle Fusion Middleware Enterprise Deployment Guides angegeben, muss sich das Domainverzeichnis des Administrationsservers (ASERVER_HOME) im Shared Storage befinden, getrennt vom Domainordner des Managed Servers (MSERVER_HOME). Dadurch kann der Administrationsserver zusammen mit einem virtuellen Hostnamen für die Listening-Adresse des Administrationsservers ein Failover auf einen anderen Host durchführen, entweder innerhalb desselben oder in einer anderen Region.

Andere Artefakte, die sich in gemeinsam genutzten Dateisystemen befinden, sind die Oracle Home-Installationen (binär), die Deployment-Pläne und die Dateiadapterverzeichnisse (Laufzeitordner).

In einer FMW-gestreckten Clustertopologie verwendet jede Region ihren eigenen lokalen Shared Storage. Folglich verwaltet die zweite Region ihre eigenen redundanten Binärdateien (für mindestens zwei Binärinstallationen pro Standort für High Availability) und ihre eigenen gemeinsamen Verzeichnisse für gemeinsame Konfiguration, Deployment-Pläne, Laufzeitdateien und mehr. Alle diese Artefakte müssen identische Pfade in beiden Regionen verwenden, um Konsistenz und nahtloses Failover sicherzustellen.
Einen affinitätsbasierten Algorithmus für das Cluster WebLogic verwenden
Um den Cross-Site-Datenverkehr zu minimieren, verwenden Sie die lokale Affinität für die Java Naming and Directory Interface-(JNDI-)Context Factory-Auflösung. So setzen Sie den Standardladealgorithmus des WebLogic-Clusters auf einen affinitätsbasierten Algorithmus:
1. Gehen Sie zu Baum bearbeiten in der WebLogic Remotekonsole.
2. Gehen Sie zu Umgebung, wählen Sie Cluster aus, und wählen Sie das Cluster aus.
3. Legen Sie in der Registerkarte Allgemein den Standardladealgorithmus des WebLogic-Clusters auf Round-Robin-Affinität (Standardwert ist Round-Robin) oder auf einen beliebigen "affinitätsbasierten" Algorithmus fest.
Die Clusteradresse muss nicht mit der expliziten Liste aller Server im Cluster festgelegt werden. Wenn dieser Wert leer ist, wird der Wert für die Clusteradresse automatisch generiert. Stellen Sie einfach sicher, dass die Eigenschaft Anzahl Server in Clusteradresse, mit der die Anzahl der Server begrenzt wird, die beim automatischen Generieren der Clusteradresse aufgelistet werden sollen, einen Wert hat, der hoch genug ist, um alle Server im Cluster einzuschließen.
Konfiguration der automatischen Servicemigration verwenden
Oracle empfiehlt, Automatic Service Migration zusammen mit persistenten Java Database Connectivity-(JDBC-)Speichern für Enterprise Deployment-Topologien zu konfigurieren. In einer FMW-gestreckten Clustertopologie ist die automatische Servicemigration innerhalb und auch regionsübergreifend möglich, solange JMS- und TLOG-Daten von beiden Sites aus zugänglich sind. Bei der Verwendung persistenter JDBC-Speicher sind keine besonderen Überlegungen für die Konfiguration von ASM in einem gestreckten Cluster erforderlich.

Die für einen Service-Migrationsvorgang von Region 1 in Region 2 benötigte Zeit kann zunehmen, wenn eine hohe Latenz zwischen Standorten besteht. Diese Erhöhung wird durch die Zeit verursacht, die für das Recovery der Nachrichten auf dem anderen Server aufgewendet wurde, da sie aus dem persistenten Speicher in der Datenbank in der anderen Region gelesen werden. Diese Latenz nimmt mit der Anzahl der ausstehenden Nachrichten in den persistenten Speichern zu. Die Strafe wird jedoch nur bei sehr hohen Latenzzeiten oder mit einer großen Anzahl ausstehender Nachrichten relevant. Weitere Informationen zu erwarteten Verhaltensweisen finden Sie im Abschnitt "Leistungsdaten prüfen".
Frontend-Hostname und -Auflösung
Geben Sie bei der Konfiguration des Frontend-Hosts für das WebLogic-Cluster den virtuellen Hostnamen an, den Clients für den Zugriff auf das System verwenden, wie bei jedem Standard-Deployment. Die Clients sollten diesen virtuellen Hostnamen in eine externe Adresse auflösen, die zwischen den OCI Load Balancer-Instanzen in Region 1 und Region 2 ausgeglichen ist. Siehe "Info zu Global Load Balancing".

Um sicherzustellen, dass WebLogic-Server in jeder Region interne Aufrufe nur an den jeweiligen lokalen OCI Load Balancer weiterleiten, konfigurieren Sie die Server so, dass der Frontend-Hostname in die IP-Adresse des OCI Load Balancers in ihrer Region aufgelöst wird. Dies kann erreicht werden, indem der Datei /etc/hosts auf jedem WebLogic-Serverhost ein Eintrag hinzugefügt oder einer privaten DNS-Ansicht in jeder Region hinzugefügt wird:

Für Server in Region 1:
```
[IP address of Region 1 OCI Load Balancer] [frontend hostname]
```
Für Server in Region 2:
```
[IP address of Region 2 OCI Load Balancer] [frontend hostname]
```
Diese Konfiguration stellt sicher, dass die interne Kommunikation von WebLogic-Servern an den entsprechenden regionalen Load Balancer geleitet wird, wodurch Routing und Performance optimiert werden.

WebLogic-Datenquellen einrichten

Verwenden Sie GridLink-Datenquellen mit einer doppelten Verbindungszeichenfolge in allen WebLogic-Datenquellen (für die Oracle Fusion Middleware-(FMW-)Metadaten, persistente Datenbankspeicher, Leasingtabellen, DB-Adapter usw.), um das Datenbank-Failover zu automatisieren. Sie müssen sich automatisch wieder verbinden, wenn ein Ausfall oder ein Herunterfahren auf einem der Knoten von Oracle Real Application Clusters (Oracle RAC) auftritt, aber auch, wenn ein vollständiges Switchover der Datenbank in die andere Region erfolgt. Um dies zu erreichen, wenden Sie folgende Empfehlungen an:

GridLink-Datenquellen verwenden
GridLink-Datenquellen nutzen den Oracle Notification Service (ONS), um Datenbankknotenausfälle oder Netzwerkunterbrechungen schnell zu erkennen und darauf zu reagieren und so die Verfügbarkeit und Resilienz von Anwendungen zu verbessern. Sie verteilen die Datenbankverbindungen automatisch basierend auf Workload-Informationen in Echtzeit und optimieren die Performance und Ressourcennutzung auf allen RAC-Knoten. Die Änderungen in der Datenbanktopologie (z. B. das Hinzufügen oder Entfernen von RAC-Knoten) werden automatisch erkannt und verarbeitet, wodurch der Verwaltungsaufwand reduziert und Ausfallzeiten minimiert werden.

Sie müssen den ONS-Host und -Port in der Datenquellenkonfiguration GridLink nicht manuell angeben. Die ONS-Liste wird automatisch von der Datenbank an den Treiber bereitgestellt, der die ONS-Informationen für Primär- und Standbydatenbanken abruft und Verbindungen zu beiden erleichtert.
TNS-Alias verwenden
Verwenden Sie in der Verbindungszeichenfolge der Datenquellen einen TNS-Alias, der auf einen Eintrag in der Datei tnsnames.ora verweist, der sowohl primäre als auch Standby-SCAN-Adressen enthält. Das empfohlene Format für Verbindungszeichenfolgen ist: Eine Beschreibung und zwei Adresslisten, eine pro RAC-Datenbank:
```
PDB =
(DESCRIPTION=   
(CONNECT_TIMEOUT=15)(RETRY_COUNT=5)(RETRY_DELAY=5)(TRANSPORT_CONNECT_TIMEOUT=3)   
(ADDRESS_LIST=
     (LOAD_BALANCE=on)
     (ADDRESS=(PROTOCOL=TCP)(HOST=primdb-scan.dbsubnet.region1vcn.oraclevcn.com)(PORT=1521))
 )
(ADDRESS_LIST=
     (LOAD_BALANCE=on)
    (ADDRESS=(PROTOCOL=TCP)(HOST=stbydb-scan.dbsubnet.region2vcn.oraclevcn.com)(PORT=1521))    
)
(CONNECT_DATA=(SERVICE_NAME=pdbservice.example.com))
)
```
Weitere Informationen zum Konfigurieren des TNS-Alias in den Datenquellen und FMW-Konfigurationsdateien finden Sie unter TNS-Alias in Connect-Strings verwenden im Enterprise Deployment Guide for Oracle SOA Suite.
Option Verbindungen beim Reservieren testen verwenden
Stellen Sie sicher, dass die Option Verbindungen bei Reserve testen für alle Datenquellen aktiviert ist. Dies ist besonders wichtig für Datenquellen, die für den Zugriff auf persistente Speicher verwendet werden, da persistente Speicher im Gesamtstatus der WebLogic-Server von entscheidender Bedeutung sind. Mit diesem Flag kann WebLogic Server eine Verbindung testen, bevor sie der Anwendung übergeben wird.

Verwenden Sie unter Testtabellenname den Standardwert SQL ISVALID. Dies ist ein schneller und effizienter Test, da er eine ressourcensparende Validierung durchführt, um festzustellen, ob die Datenbankverbindung noch aktiv ist, ohne Zugriff auf eine bestimmte physische Tabelle zu benötigen.
Anfängliche Kapazität optimieren
Wenn ein WebLogic-Server gestartet wird, wird viel Zeit für die Erstellung der anfänglichen Verbindungen für die Datenquellenpools verwendet. Je nach den anfänglichen Kapazitätseinstellungen in den Datenquellen werden unterschiedliche Verzögerungen erwartet. Standardmäßig verwenden die meisten FMW-Datenquellen eine anfängliche Kapazität von Null für ihren Verbindungspool. Um die Antwortzeit des Systems während des normalen Laufzeitbetriebs zu reduzieren, kann es jedoch vorteilhaft sein, die anfängliche Poolkapazität zu erhöhen.
Da die anfängliche Kapazität auf der Ebene der Datenquelle (Verbindungspool) konfiguriert wird, beeinflussen diese Einstellungen die Startzeit für alle Server im Cluster (die lokalen Server in der Datenbank und die entfernten Server in der Datenbank). In einem FMW-gestreckten Cluster zeigen die Server, die sich remote von der Datenbank befinden, beim Start eine erhöhte Latenz, da eine höhere anfängliche Poolkapazität verwendet wird (siehe "Startzeiten prüfen"). Daher ist eine ausgewogene Entscheidung zwischen der Optimierung der Reaktionszeiten während des normalen Betriebs und der Minimierung der Startzeit erforderlich, um die idealen anfänglichen Kapazitätseinstellungen zu bestimmen.
Maximale Kapazität optimieren
Die Anzahl der aktiven Datenquellenverbindungen nimmt mit einer höheren Latenz zur Datenbank zu. In den durchgeführten Tests zeigen die Server in der Remoteregion bis zu 2x aktive Verbindungen an, als der Server mit der Datenbank kolloziert hat (siehe "Stresstests prüfen"). Überwachen Sie die Verwendung in Ihrer Anwendung, und prüfen Sie diese für eine korrekte Größe der WebLogic-Datenquellen und Datenbanksessions.

Webserver einrichten

Wenn das System eine Web-Tier mit Oracle HTTP Server-Instanzen verwendet, muss jede Region über mindestens zwei Server verfügen, um High Availability in der Region bereitzustellen.

Um den Traffic regionsübergreifend zu reduzieren, verwenden Sie keine dynamische Serverlistenkonfiguration in den Oracle WebLogic Server-Routingabschnitten. Konfigurieren Sie stattdessen eine statische Liste der Server, und setzen Sie den Parameter DynamicServerList auf OFF. Dies hat die Einschränkung einer langsameren Ausfallerkennung: Wenn ein WebLogic-Server abstürzt, nimmt der HTTP-Server mehr Zeit in Anspruch, um den Fehler zu erkennen als bei einer dynamischen Liste. Außerdem sind Aktualisierungen in der Konfiguration erforderlich, wenn neue Server hinzugefügt werden. Es verbessert jedoch die Systemleistung.

Die folgenden Auszüge aus den mod_wl_ohs.conf-Dateien in Oracle HTTP Server enthalten ein Beispiel für die erforderliche Konfiguration für das Routing an die SOA-Infra-Webanwendung.

In Region 1:

<Location /soa-infra>
    WLSRequest ON
    WebLogicCluster region1_server1.example.com:7004,region1_server2.example.com:7004
    DynamicServerList OFF
</Location>

In Region 2:

<Location /soa-infra>
    WLSRequest ON
    WebLogicCluster region2_server1.example.com:7004,region2_server2.example.com:7004
    DynamicServerList OFF
</Location>

Load Balancer einrichten

Jede Region muss über einen eigenen Load Balancer verfügen, um Anforderungen auf die Server innerhalb dieser Site zu verteilen.

Konfigurieren Sie den Listener in beiden Regionen mit demselben SSL-Zertifikat auf jedem Load Balancer. Richten Sie die Backend-Server so ein, dass der Load Balancer in Region 1 die Oracle HTTP Server-(OHS-)Instanzen aus Region 1 enthält (wenn das System keine Webserver verwendet, sind die gesicherten Server die WebLogicServer aus Region 1), und der Load Balancer in Region 2 enthält die OHS-Server aus Region 2 (wenn das System keine Webserver verwendet, sind die Backend-Server die WebLogic-Server aus Region 2).

Konfigurieren Sie Health Checks, um die Verfügbarkeit der Backend-Server zu bestimmen. Verwenden Sie dazu eine URL, die den Status der Anwendung genau widerspiegelt. Dadurch wird verhindert, dass Traffic an einen Server weitergeleitet wird, auf dem Oracle WebLogic Server ausgeführt wird, aber die Anwendung selbst nicht verfügbar ist. Dies kann passieren, wenn der Health Check nur auf den Root-Kontext abzielt (/). Vermeiden Sie jedoch ressourcenintensive Health Checks, da häufige schwere Prüfungen die gesicherten Server überlasten könnten. Beispiel: Die empfohlene Health-Check-URL für Oracle SOA lautet /soa-infra/services/isSoaServerReady .

Globales Load Balancing

Das gestreckte Oracle Fusion Middleware-(FMW-)Clustermodell benötigt ein Element über dem Load Balancer jedes Data Centers, um die Anforderungen des Clients zwischen den beiden Regionen auszugleichen.

In On-Premise-Implementierungen wird dies traditionell mit einem globalen Load Balancer implementiert, der für das intelligente Routing verantwortlich ist, in der Regel basierend auf den IP-Adressen des Ursprungs. Dieser globale Load Balancer befindet sich normalerweise auf einer der Sites, wobei ein Backup auf der anderen Site für Failover vorhanden ist.

In Oracle Cloud Infrastructure (OCI) gibt es keinen dedizierten globalen Load-Balancer-Service. Sie können jedoch die globale Load Balancing-Funktionalität mithilfe von Trafficmanagement-Policys erreichen.

Lenkungs-Policys für OCI-Trafficmanagement als globaler Load Balancer verwenden

Verwenden Sie Steuerungs-Policys für Oracle Cloud Infrastructure-(OCI-)Trafficmanagement, um das Load Balancing des Clienttraffics zwischen den beiden Sites durchzuführen.

Die Steuerungs-Policys für Trafficmanagement dienen intelligenten Antworten auf Domain Name System-(DNS-)Abfragen, d.h. je nach der in der Policy definierten Logik können unterschiedliche Antworten für die Abfrage bereitgestellt werden. Es gibt verschiedene Policy-Typen:

Load Balancer Policy
Load Balancer Policys verteilen Traffic über viele Endpunkte hinweg. Endpunkte können gleichen Gewichtungen zugewiesen werden, um Traffic gleichmäßig auf die Endpunkte zu verteilen, oder benutzerdefinierte Gewichtungen können für Ratio Load Balancing zugewiesen werden. Oracle Cloud Infrastructure Health Checks-Monitore und On-Demand-Probes werden genutzt, um den Zustand des Endpunkts zu bewerten. Wenn ein Endpunkt fehlerhaft ist, wird der DNS-Traffic automatisch an die anderen Endpunkte verteilt.
Failover-Policy
Mit Failover Policys können Sie die Reihenfolge festlegen, in welcher Antworten in einer Policy bereitgestellt sein sollen (Beispiel: Primär und sekundär). OCI Health Checks-Monitore und On-Demand-Probes werden genutzt, um den Zustand der Antworten in der Policy zu bewerten. Wenn die primäre antwort fehlerhaft ist, wird DNS-traffic automatisch an die sekundäre antwort geleitet.
Geolokationssteuerungs-Policy
Bei Geolokationssteuerungs-Policys wird der DNS-Traffic basierend auf dem Standort des Endbenutzers an verschiedene Endpunkte verteilt. Kunden können geografische Regionen aus Ursprungskontinent, -ländern oder -bundesländern/-provinzen (Nordamerika) sowie einen separaten Endpunkt oder eine Set aus Endpunkten für jede Region definieren.
ASN-Steuerungs-Policy
Mit ASN-Steering-Policys können Sie DNS-Traffic basierend auf der Nummer des autonomen System (ASN) steuern. DNS-Abfragen von einer bestimmten ASN oder einem Set von ASNs können an einen bestimmten Endpunkt geleitet werden.
IP-Präfixsteuerungs-Policy
Bei IP-Präfixsteuerungs-Policys können Kunden den DNS-Traffic basierend auf dem IP-Präfix der Ursprungsabfrage steuern.

Wählen Sie die Politik, die am besten zu Ihren Bedürfnissen passt. Die am besten geeigneten Optionen für ein gestrecktes Cluster-Deployment sind die Geolokalisierungssteuerungs-Policy und die IP-Präfixsteuerungs-Policy. Die Failover-Policy eignet sich für Services, die nur auf einer der Sites ausgeführt werden, wie der WebLogic Remotekonsole.

Unabhängig vom Policy-Typ müssen Sie OCI-Health-Checks definieren, um die Verfügbarkeit der Site zu prüfen. Dadurch wird verhindert, dass der Datenverkehr zu einer Site gelangt, an der die Server gestoppt oder die Anwendung nicht verfügbar ist. Stellen Sie sicher, dass Sie eingehenden Traffic von den Standorten, die den Health Check ausführen, zu den OCI Load Balancer-Ports zulassen, die Sie prüfen.

Das folgende Diagramm zeigt das globale Load Balancing mit Steuerungs-Policys für OCI-Trafficmanagement.

Beschreibung von global-load-balancer-steering-policies.png folgt

Beschreibung der Abbildung global-load-balancer-steering-policies.png

global-load-balancer-steering-policies-oracle.zip

Wenn Sie Steuerungs-Policys für OCI-Trafficmanagement verwenden, um einen globalen Load Balancer zu emulieren:

Failover-Reaktionszeit
Die Antwortzeit auf einen Sitefehler hängt sowohl von den Health-Check-Intervallen (die bestimmen, wie schnell eine Site als nicht verfügbar markiert wird) als auch von der Gültigkeitsdauer des DNS-Datensatzes (TTL) ab. Selbst nachdem eine Site als nicht verfügbar gekennzeichnet wurde und Traffic an einen anderen Speicherort geleitet wird, erhalten Clients die aktualisierte IP-Adresse erst, wenn die vorherige DNS-TTL im lokalen Cache abläuft. Um Failover-Verzögerungen zu minimieren, wird empfohlen, einen TTL-Wert mit niedriger Policy festzulegen.
Einschränkung der Sessionpersistenz
Da das Load Balancing mit diesen Policys auf DNS-Antwortwerten basiert, gibt es keinen integrierten Mechanismus für Sessionpersistenz. Daher kann sich die DNS-Antwort, die Clients bereitgestellt wird, jederzeit ändern, wenn eine zufällige oder einfache Load Balancer Policy verwendet wird. Dies wirkt sich möglicherweise auf Anwendungssessions aus, die Persistenz erfordern. Wenn Ihre Anwendung persistente Sessions erfordert, stellen Sie sicher, dass alle möglichen Clientspeicherorte explizit in geolocation-basierten Regeln definiert sind, und vermeiden Sie die Verwendung zufälliger oder Load-Balancer-Steuerungsalgorithmen.

Im Folgenden finden Sie eine Beispielkonfiguration der OCI-Trafficmanagement-Steuerungs-Policys für ein Oracle Fusion Middleware-(FMW-)gestrecktes Clustersystem, das in den Regionen Frankfurt und Amsterdam bereitgestellt wird, mit drei Frontends: eine für Oracle SOA, eine für OSB und eine andere für die WebLogic Remotekonsole. Die IP des Load Balancers (LBR) in Frankfurt ist 111.111.111.111, und die IP des LBR in Amsterdam ist 222.222.222.222. In diesem Beispiel definieren die Steuerungs-Policys die folgenden Regeln:

Für SOA- und OSB-Frontends erhalten die Clients aus Deutschland, Europa, Asien und Südamerika von DNS die IP des Frankfurter Load Balancers als primäre Antwort.
Für die SOA- und OSB-Frontends erhalten die Kunden aus den Niederlanden, Afrika, Ozeanien und dem nordamerikanischen Standort von DNS die IP des Amsterdam Load Balancers als primäre Antwort.
Für alle anderen Clients (die nicht erwartet werden, da alle Regionen in den Geolokalisierungsregeln enthalten sind) gibt das DNS eine Standardantwort zurück, sodass sie nach Frankfurt umgeleitet werden.
OCI-Health Checks werden für jedes Frontend definiert. Wenn also die Primärdatenbank als nicht verfügbar markiert ist, wird der Traffic an den alternativen IP-Datensatz geleitet.
Das Frontend der WebLogic Remotekonsole verwendet ein Failover-Modell. Das DNS gibt die IP des Frankfurt-Load Balancers für alle Clients zurück. Wenn der Health Check in Frankfurt nicht erfolgreich verläuft, gibt das DNS die IP des Amsterdam-Load Balancers zurück.

Folgende OCI-Trafficmanagement-Steuerungs-Policys sind definiert:

Eine Geolocation-Steuerungs-Policy für den Zugriff auf das SOA-Frontend.

Konfigurationselement	Beispielwerte
Policy-Name	strecthed_cluster_steering_policy-SOA
Vorlage	Geolokationssteuerung
Policy-TTL	60s
Antwort Pool1 (Frankfurt_Pool)	Name: Frankfurt_LBR_IP Typ: A RDATA: 111.111.111.111
Antwortpool 2 (Amsterdam_Pool)	Name: Amsterdam_LBR_IP Typ: A RDATA: 222.222.222.222
Geolokationssteuerungsregel 1	Geolocation: Deutschland, Europa, Asien, Südamerika Poolpriorität 1: Frankfurt_Pool Poolpriorität 2: Amsterdam_Pool
Geolokationssteuerungsregel 2	Geolocation: Niederlande, Afrika, Ozeanien, Nordamerika Poolpriorität 1: Amsterdam_Pool Poolpriorität 2: Frankfurt_Pool
Globale Catch-All-Regel	Antwort Pool1 (Frankfurt_Pool)
Health Check zuordnen	Anforderungstyp: HTTP Health Check: `SOA_IS_ALIVE` (HTTPS)
Zugeordnete Domains	soafrontend.example.com

Eine Geolokalisierungssteuerungs-Policy für den Zugriff auf das OSB-Frontend.

Konfigurationselement	Beispielwerte
Policy-Name	strecthed_cluster_steering_policy-OSB
Vorlage	Geolokationssteuerung
Policy-TTL	60s
Antwortpool 1 (Frankfurt_Pool)	Name: Frankfurt_LBR_IP Typ: A RDATA: 111.111.111.111
Antwortpool 2 (Amsterdam_Pool)	Name: Amsterdam_LBR_IP Typ: A RDATA: 222.222.222.222
Geolokationssteuerungsregel 1	Geolocation: Deutschland, Europa, Asien, Südamerika Poolpriorität 1: Frankfurt_Pool Poolpriorität 2: Amsterdam_Pool
Geolokationssteuerungsregel 2	Geolocation: Niederlande, Afrika, Ozeanien, Nordamerika Poolpriorität 1: Amsterdam_Pool Poolpriorität 2: Frankfurt_Pool
Globale Catch-All-Regel	Antwort Pool1 (Frankfurt_Pool)
Health Check zuordnen	Anforderungstyp: HTTP Health Check: `OSB_IS_ALIVE` (HTTPS)
Zugeordnete Domains	osbfrontend.example.com

Für den Zugriff auf die WebLogic Remotekonsole wird eine Failover-Policy verwendet. Während des normalen Betriebs wird der Administrationsserver nur auf einer der Sites ausgeführt (in diesem Fall Frankfurt). Nur im Falle eines Sitefehlers wird er auf der anderen Site gestartet. Daher wird der Zugriff auf die WebLogic Remotekonsole und EM durch eine Failover-Policy gesteuert.

Konfigurationselement	Beispielwerte
Policy-Name	strecthed_cluster_steering_policy-ADMIN
Vorlage	Failover
Policy-TTL	60s
Antwort Pool1 (Frankfurt_Pool)	Name: Frankfurt_LBR_IP Typ: A RDATA: 111.111.111.111
Antwortpool 2 (Amsterdam_Pool)	Name: Amsterdam_LBR_IP Typ: A RDATA: 222.222.222.222
Poolpriorität 1	Frankfurt_Pool
Poolpriorität 2	Amsterdam_Pool
Health Check zuordnen	Anforderungstyp: HTTP Health Check: `EM_IS_ALIVE` (HTTPS)
Zugeordnete Domains	admin.example.com

Dies ist die Konfiguration von OCI-Health-Checks, die von jeder DNS-Steuerungs-Policy verwendet werden:

Health Check für das SOA-Frontend. SOA bietet eine einfache Seite, auf der Sie den SOA-Status im Pfad /soa-infra/services/isSoaServerReady prüfen können. Daher führt dieser Health Check eine HEAD-Anforderung mit HTTPS zu diesem Pfad aus, um zu prüfen, ob die SOA-Anwendung verfügbar ist. Der host-Header ist erforderlich, um den Frontend-Namen anzugeben, den Sie testen möchten (in diesem Beispiel soafrontend.example.com), wenn Sie benannte virtuelle Hosts auf den Webservern und Load Balancern verwenden.

Konfigurationselement	Beispielwerte
Health-Check-Name	SOA_IS_ALIVE
Ziele	111.111.111.111 (Frankfurt LBR IP) 222.222.222.222 (Amsterdam LBR IP)
Standorte	Microsoft Azure Nordeuropa Google Ost-US
Typ	HTTP
Protokoll	HTTPS
Port	443
Path	`/soa-infra/services/isSoaServerReady`
Header	Host: soafrontend.example.com:443
Methode	HEAD
Interval	30 Sekunden
Standorterfassung	10 Sekunden

Health Check für OSB-Frontend. OSB implementiert keine Integritäts-URL für seine Services. Einige der URLs, die normalerweise zur Prüfung des OSB-Status verwendet werden (wie /sbinspection.wsil), erfordern eine Authentifizierung, und OCI-Health-Checks unterstützen den authorization-Header nicht. Um den Status des OSB zu prüfen, stellen Sie daher einen einfachen benutzerdefinierten REST-Proxyservice bereit. Diese OCI-Health-Checks führen eine HEAD-Anforderung an einen solchen Endpunkt über HTTPS aus. Der host-Header ist erforderlich, um den Frontend-Namen anzugeben, den Sie testen möchten (in diesem Beispiel osbfrontend.example.com), wenn Sie benannte virtuelle Hosts auf den Webservern und Load Balancern verwenden.

Konfigurationselement	Beispielwerte
Health-Check-Name	OSB_IS_ALIVE
Ziele	111.111.111.111 (Frankfurt LBR IP) 222.222.222.222 (Amsterdam LBR IP)
Standorte	Microsoft Azure Nordeuropa Google Ost-US
Typ	HTTP
Protokoll	HTTPS
Port	443
Path	/`default/isOSBReadySample`
Header	Host: osbfrontend.example.com:443
Methode	HEAD
Interval	30 Sekunden
Standorterfassung	10 Sekunden

Health Check für WebLogic Remotekonsole-Frontend EM_IS_ALIVE.

OCI-Health-Checks führen eine HEAD-Anforderung mit HTTPS zum Pfad /em/faces/targetauth/emasLogin aus, um den Status der FMW-Kontrollkonsole zu prüfen.

Konfigurationselement	Beispielwerte
Health-Check-Name	SOA_IS_ALIVE
Ziele	111.111.111.111 (Frankfurt LBR IP) 222.222.222.222 (Amsterdam LBR IP)
Standorte	Microsoft Azure Nordeuropa Google Ost-US
Typ	HTTP
Protokoll	HTTPS
Port	443
Path	`/em/faces/targetauth/emasLogin`
Header	Host: admin.example.com:445
Methode	HEAD
Interval	30 Sekunden
Standorterfassung	10 Sekunden

Globalen Load Balancer eines Drittanbieters verwenden

Als Alternative zu den Steuerungs-Policys für das Oracle Cloud Infrastructure-(OCI-)Trafficmanagement können Sie einen Global Load Balancer (GLBR) eines Drittanbieters verwenden.

Er ist für das intelligente Routing der Anforderungen zwischen den lokalen Load Balancern verantwortlich.

Der GLBR ist ein Load Balancer, der für den Zugriff durch Benutzer aller Sites und externen Speicherorte als Adresse konfiguriert ist. Das Gerät stellt einen virtuellen Server bereit, der einem DNS-Namen (Domain Name System) zugeordnet ist, auf den jeder Client zugreifen kann, unabhängig von der Site, mit der er eine Verbindung herstellt.

Der GLBR leitet Traffic basierend auf konfigurierten Kriterien und Regeln an beide Standorte weiter. Diese Kriterien können beispielsweise auf der IP des Clients basieren. Dies sollte verwendet werden, um ein Persistenzprofil zu erstellen, mit dem GLBR Benutzer bei ersten und nachfolgenden Anforderungen derselben Site zuordnen kann. GLBR verwaltet einen Pool, der aus den Adressen aller lokalen Load Balancer besteht. Im Falle eines Ausfalls einer der Sites werden die Benutzer automatisch auf die verbleibende aktive Site umgeleitet.

In jeder Site empfängt ein lokaler Load Balancer die Anforderung von GLBR und leitet Anforderungen an den entsprechenden HTTP-Server weiter. Um unerwünschte Routings zu vermeiden, ist der GLBR auch mit bestimmten Regeln konfiguriert, die Callbacks nur an den LBR weiterleiten, der lokal zu den Servern ist, die sie generiert haben. Dies ist beispielsweise für interne Consumer von Oracle SOA-Services nützlich. Diese GLBR-Regeln können wie folgt zusammengefasst werden:

Wenn Anforderungen von site1 stammen (z.B. Anforderungen, die von den WebLogic-Servern in Site 1 stammen), leitet der GLBR an den LBR in site1 weiter.
Wenn Anforderungen von site2 stammen (z.B. Anforderungen, die von den WebLogic-Servern in Site 2 stammen), leitet der GLBR an den LBR in site2 weiter.
Wenn Anforderungen von einer anderen Adresse (Clientaufrufe) stammen, gleicht das GLBR die Verbindungen mit beiden LBRs aus.
Zusätzliche Routingregeln können im GLBR definiert werden, um bestimmte Clients an bestimmte Standorte weiterzuleiten (z.B. können die beiden Standorte je nach Hardwareressourcen unterschiedliche Reaktionszeiten bereitstellen).

Sonstige Ressourcen einrichten

Die beiden Regionen können externe Ressourcen wie LDAP, Identitätsspeicher, Policy-Speicher, JMS-(External Java Message Service-)Ziele, externe Webservices, Oracle Cloud Infrastructure Object Storage usw. verwenden.

Die Konfigurationsdetails für diese externen Ressourcen liegen außerhalb des Geltungsbereichs dieses Dokuments. Es ist jedoch erforderlich, dass diese Ressourcen in beiden Regionen konsistent sind, um ein einheitliches Verhalten zu gewährleisten.

Beispiel: In Oracle SOA können die asynchronen Callbacks Instanzen rehydrieren, die in einer anderen Region initiiert wurden. Ebenso kann jeder Oracle WebLogic Server im Falle eines automatischen Recoverys die Rolle des Cluster-Master übernehmen und Recovery-Vorgänge in beiden Regionen ausführen. Um sicherzustellen, dass diese Prozesse nahtlos funktionieren und ein konsistentes Verhalten bieten, müssen dieselben externen Ressourcen von beiden Regionen aus zugänglich sein.