Zusätzliche Optimierungen für gestreckte FMW-Cluster konfigurieren

Die folgenden Optimierungen werden speziell für die Oracle Fusion Middleware-(FMW-)Topologie der gestreckten Cluster empfohlen.

Obwohl nicht alle für diese Topologie obligatorisch sind, verbessern sie die Performance und verbessern das Verhalten bestimmter Funktionen und Szenarien.

Timeouts in Oracle WebLogic Server (WLS) konfigurieren

Timeouts können in verschiedenen Schichten des Oracle Fusion Middleware-(FMW-)Stacks auftreten.

Für Transaktionen in der Datenbank, für Transaktionsverzweigungen, Aufrufe der Enterprise JavaBean-(EJB-)Methode, Webservices usw. sind Timeoutlimits angegeben. Die gestreckten Oracle Fusion Middleware-Cluster-Deployments reagieren besonders auf Timeouteinstellungen, da mehrere Vorgänge an einem anderen Speicherort auf die Datenbank zugreifen müssen. Konfigurieren Sie die Timeouts wie folgt:

  • Sie machen die Latenz im System aus.

    Möglicherweise müssen Sie die Timeouts in diesen Systemtypen aufgrund der damit verbundenen Latenzen erhöhen. Im gestreckten Clustermodell werden Domaineinstellungen für beide Sites freigegeben. Daher müssen Timeouts verwendet werden, die für das Worst-Case-Szenario verantwortlich sind.

  • Sie laufen in der Aufrufkette über verschiedene Ebenen hinweg ordnungsgemäß ab.

    Timeouts müssen in den verschiedenen Schichten des Systems so konfiguriert werden, dass sich die entsprechenden umschließenden Tiers ordnungsgemäß verhalten. Beispiel: Wenn der Datenbank-Timeout auf einen Wert gesetzt ist, der niedriger ist als der globale WLS-Timeout, kann eine Transaktions-ID aus der Datenbank "entfernt" werden, bevor die Arbeit an anderen Verzweigungen abgeschlossen ist.

Dies sind die wichtigsten Timeoutparameter in verschiedenen Layern:

  • Timeout bei globaler Transaktion

    Das Timeout für globale Oracle WebLogic Server-Transaktionen bestimmt die maximale Dauer (in Sekunden), die eine verteilte Transaktion (eine globale Transaktion) aktiv bleiben darf, bevor sie automatisch von Oracle WebLogic Server zurückgesetzt wird. Konfigurieren Sie den globalen Transaktionstimeout in der WebLogic Remotekonsole, indem Sie im Abschnitt Services des Bearbeitungsbaums die Option JTA (Java Transaction API) auswählen und Timeout in Sekunden angeben.

  • XA-Transaktionstimeouts

    Der XA-Transaktionstimeout in den XA-Datenquellen wird in Oracle WebLogic Server verwendet, um einen Transaktionsverzweigungstimeout für Datenquellen festzulegen. Standardmäßig ist dieser Wert auf 0 (Null) gesetzt. Daher wird das globale Transaktionstimeout WebLogic verwendet. Sie können diesen Wert jedoch einrichten, wenn Sie über lang laufende Transaktionen verfügen, die den Standard-Timout-Wert in der XA-Ressource überschreiten. Dieser Wert wird für jede XA-Datenquelle auf der Registerkarte Transaktion konfiguriert.

  • Verteiltes Sperr-Timeout

    Das verteilte Lock-Timeout in der Datenbank gibt an, wie lange verteilte Transaktionen auf gesperrte Ressourcen warten (in Sekunden). Sie können den Parameter (distributed_lock_timeout) mit den entsprechenden SQL ALTER-Anweisungen ändern.

Legen Sie das verteilte Sperr-Timeout der Datenbank so lange fest, dass die langsamste Transaktion unter Berücksichtigung von Netzwerkverzögerungen zwischen den Sites ausgeführt werden kann. Danach legen Sie die XA-Datenquelle und die globalen Transaktions-Timeouts mit der folgenden Regel auf niedrigere Werte fest:

distributed_lock_timeout >= XA DS Timeout >= Global Transaction Timeout

Anwendungen können zusätzliche Timeoutparameter verwenden. Beispiel: Oracle SOA und BPEL haben die folgenden zusätzlichen Timeoutparameter, die Sie berücksichtigen müssen:

  • syncMaxWaitTime

    syncMaxWaitTime ist die maximale Zeit, die ein synchroner Client auf eine Antwort wartet. Diese Einstellung legt fest, wie lange ein Anforderungs- und Antwortvorgang dauern kann, bevor ein Timeout auftritt. Wenn der BPEL-Prozess innerhalb dieser Zeit keine Antwort erhält, verläuft die Aktivität nicht erfolgreich. So ändern Sie diesen Wert in Oracle Enterprise Manager Fusion Middleware Control:

    1. Klicken Sie mit der rechten Maustaste auf SOA-infra, und wählen Sie SOA-Administration aus.
    2. Wählen Sie BPEL-Eigenschaften.
    3. Wählen Sie Weitere BPEL-Konfigurationseigenschaften aus.
    4. Aktualisieren Sie den Wert syncMaxWaitTime (in Sekunden).
  • Timeout für EJBs
    Wenn die BPEL-EJBs-Methoden beteiligt sind, gibt dies den Transaktionstimeout in Sekunden an (Standardwert ist 300 für alle BPEL-EJBs). Ändern Sie den Timeout wie folgt:
    1. Wählen Sie in der Monitoringstruktur der WebLogic Remotekonsole die Option Deployments und dann Application Management aus.
    2. Blenden Sie die Anwendung soa_infra ein, und blenden Sie Konfiguration und Sub-Deployment ein.
    3. Blenden Sie das Modul ein, und wählen Sie das spezifische BPEL-EJB.
    Um SOA-Ausnahmen zu vermeiden, weil Transaktionen vor Abschluss der Prozesse gelöscht werden, verwenden Sie die folgende Regel: 
    Global Transaction Timeout > BPEL EJB's transaction timeout > syncMaxWaitTime
  • Timeout für Webservices-Clients

    Der Webserviceclient muss mit einem Timeout konfiguriert werden, der mit der schlechtesten Latenz ausreichend zulässig ist. Beispiel: Wenn ein Anruf 3 Sekunden bis Site 1 dauert, aber 10 Sekunden bis Site 2 dauert, sollte der Timeout auf mindestens 10 Sekunden eingestellt werden, um die langsamere Site zu verarbeiten.

  • Timeout bei BPEL-Prozessen

    Wenn der BPEL-Prozess bestimmte Request-Reply-(synchrone) und In-Only-Empfang-(asynchrone) Timeouts verwendet, müssen Sie diese auf der Grundlage des Worst-Case-Szenarios definieren: Wenn der Aufruf an die Site mit der höchsten Datenbanklatenzzeit erfolgt. Diese Timeout-Einstellungen werden im BPEL-Prozess definiert und können nicht für jede Site unterschiedlich festgelegt werden. Weitere Informationen zum Konfigurieren von Ereignissen und Timeouts in BPEL-Prozessen finden Sie im Oracle Fusion Middleware Developer's Guide for Oracle SOA Suite. Siehe Abschnitt "Mehr entdecken".

Sessionreplikation konfigurieren

Einige Anwendungen (Webanwendungen, Konsolen wie Oracle SOA Composer, BPM Composer, BPM Workspace usw.) verwenden HTTP-Sessionobjekte intensiv.

Einer der Vorteile des gestreckten Cluster-Deployments von Oracle Fusion Middleware (FMW) ist die Möglichkeit eines nahtlosen Failovers zwischen Sites. Die regionsübergreifende Sessionreplikation kann jedoch zu einer Verschlechterung der Performance im System führen. Oracle empfiehlt, zwei verschiedene Replikationsgruppen (eine für jede Region) zu definieren, um die Replikation über die beiden Sites hinweg zu minimieren.

So konfigurieren Sie Sessionreplikationsgruppen:

  1. Wählen Sie in der WebLogic Remotekonsole "Baum bearbeiten" die Optionen Umgebung, Server aus.
  2. Wählen Sie Servername aus, und wählen Sie dann die Registerkarte Cluster aus.
  3. Geben Sie für jeden Server in Region 1 denselben Namen für die Replikationsgruppe ein (Beispiel: Region1RepGroup).
  4. Wiederholen Sie die Schritte für die Server in Region 2. Verwenden Sie für alle Server einen gemeinsamen Namen, der sich jedoch von dem in Region 1 verwendeten Namen unterscheidet (Beispiel: Region2RepGroup).

Beachten Sie, dass die Verwendung von Replikationsgruppen die beste Methode ist, um den Status nur auf Server auf derselben Site zu replizieren, aber keine deterministische Methode ist. Wenn ein einzelner Server auf einer Site verfügbar ist und andere auf der anderen verfügbar sind, erfolgt die Replikation über die Regionen hinweg und wird für diese Session fortgesetzt, auch wenn die Server auf derselben Site wieder online sind.

In-Place-Neustart für JMS konfigurieren

Konfigurieren Sie den In-Place-Neustart für die Java Message Service-(JMS-)Server und persistenten Speicher.

Die persistenten Speicher sind für die ordnungsgemäße Funktion der Oracle WebLogic Server-(WLS-)Server von entscheidender Bedeutung. Wenn beim In-Place-Neustart ein Fehler im persistenten Speicher auftritt, versucht der JMS-Service, auf demselben Server neu zu starten, bevor er versucht, auf einen anderen Server zu migrieren. Diese Methode ist schneller als die Migration des gesamten JMS-Service auf einen anderen Server und kann Probleme oft schnell lösen.

Um einen In-Place-Neustart für persistente JMS-Speicher zu konfigurieren, müssen der zugehörige JMS-Server und der persistente Speicher auf ein migrierbares Ziel ausgerichtet sein. Dieses migrierbare Ziel muss Bei Fehler neu starten verwenden, was standardmäßig nicht aktiviert ist. So konfigurieren Sie diese Eigenschaft:

  1. Verbindung zur WebLogic Remotekonsole herstellen
  2. Wählen Sie im Baum bearbeiten die Optionen Umgebung, Migrierbare Ziele aus.
  3. Wählen Sie ein migrierbares Ziel aus, und aktivieren Sie Bei Fehler neu starten.
  4. Wählen Sie Speichern aus, und speichern Sie die Änderungen.

Oracle FMW SOA Suite JMS-Adapter konfigurieren

Der JMS-(Java Message Service-)Adapter erfordert die Konfiguration bestimmter Connection Factory-Eigenschaften, die eine Liste der Server enthalten, die für den JNDI-Kontextabruf verfügbar sind.

Oracle empfiehlt die Verwendung der Clustersyntax (Beispiel: cluster:t3s://cluster_name), um die Konfiguration zu vereinfachen. Dieser Ansatz vereinfacht die Konfiguration, indem der Adapter die aktuelle Liste der aktiven Server im Cluster dynamisch abrufen kann, um einen effizienten JNDI-Kontextabruf sicherzustellen.

Wenn das System den JMS-Adapter intensiv und mit großen Payloads verwendet, wird empfohlen, die JNDI-URL so zu konfigurieren, dass nur die lokalen Server in jeder Region einbezogen werden. Das bedeutet, dass Server in Region 1 für Konfigurationen in Region 1 und Server in Region 2 für Konfigurationen in Region 2 angegeben werden. Dieses Setup stellt die Affinität zum Standortkontext sicher, optimiert die Performance und reduziert die Latenz.

  1. Aktualisieren Sie die Eigenschaften des ausgehenden Verbindungspools für die Instanz, die der Adapter verwendet, und geben Sie als java.naming.provider.url die Liste der Server in Region 1 an. Beispiel:
    java.naming.provider.url=t3s://region1_server1:7004,region1_server2:7004

    Weitere Informationen finden Sie unter Enabling High Availability for Oracle JMS Adapters im Oracle Fusion Middleware Enterprise Deployment Guide for Oracle SOA Suite.

  2. Nachdem die Änderung in der WebLogic Remotekonsole festgeschrieben wurde, kopieren Sie den generierten Deployment-Plan in das Spiegelverzeichnis in Region 2. Beispiel: von region1_server1:
    scp /u01/oracle/config/dp/example_domain/My_Cluster/JMSPlan.xml region2_server1:/u01/oracle/config/dp/example_domain/My_Cluster/
  3. Bearbeiten Sie den Deployment-Plan manuell in Region 2, und ersetzen Sie die Serverliste durch die Serverliste in Site2.

    Deployment-Planauszug für die Region 1:

    <name>ConfigProperty_FactoryProperties_Value_13243793917130
</name>
<value>java.naming.factory.initial=weblogic.jndi.WLInitialContextFactory;
java.naming.provider.url= t3s://region1_server1:7004,region1_server2:7004;
java.naming.security.principal=weblogic;
java.naming.security.credentials=<credentials>
</value>

    Deployment-Planauszug für die Region 2:

    <name>ConfigProperty_FactoryProperties_Value_13243793917130
</name>
<value>java.naming.factory.initial=weblogic.jndi.WLInitialContextFactory;
java.naming.provider.url= t3s://region2_server1:7004,region2_server2:7004;
java.naming.security.principal=weblogic;
java.naming.security.credentials=<credentials>
</value>
  4. Aktualisieren Sie das JMS-Adapter-Deployment mit dem geänderten Deployment-Plan (dieselbe Position in beiden Sites, aber effektiv eine andere Datei). Beim Update wird die Deployment-Plandatei in Region 1 für die Server in Region 1 und die Deployment-Plandatei in Region 2 für die Server in Region 2 verwendet.

Oracle FMW SOA Suite-Dateiadapter konfigurieren

Der Dateiadapter verwendet Datenbanktabellen, um Dateisperren und Dateimutexkoordination zu verwalten.

Dieser Mechanismus stellt sicher, dass dieselbe Datei nur von einem Server gleichzeitig verarbeitet wird und dass zwei Adapterinstanzen nicht gleichzeitig in dieselbe Datei schreiben.

In der gestreckten Clustertopologie von Oracle Fusion Middleware (FMW) arbeitet jede Site unabhängig und verarbeitet Dateien mit ihrem eigenen dedizierten Shared Storage. Standardmäßig verwenden beide Sites jedoch dieselbe Datenquelle, dasselbe Schema und dieselben Tabellen für Dateisperren und Mutex-Mechanismen.

Bei ausgehenden Vorgängen ist die Verwendung einer gemeinsamen Datenbanktabelle angemessen, da eine eindeutige Sequenz als Mutex verwendet wird, um zu verhindern, dass nebenläufige Schreibvorgänge Dateien überschreiben.

Für eingehende Vorgänge können jedoch Szenarios "unter Verarbeitung" auftreten. File Adapter-Instanzen in jeder Site können eine Datei als "blockiert" markieren. Wenn auf beiden Sites derselbe Dateiname vorhanden ist, kann dieser Mechanismus die Verarbeitung in beiden Speicherorten blockieren. Die Datei wird jedoch nur in einem dieser Speicherorte verwendet. Um diese Situationen zu vermeiden, gibt es mehrere Alternativen:

  1. Site-spezifische Dateibenennungskonventionen implementieren Verwenden Sie eindeutige IDs in Dateinamen basierend auf der Site, um die Wahrscheinlichkeit von Namenskollisionen und nachfolgendes Blockieren zu verringern.
  2. Konfigurieren Sie separate Schemas für jede Region für die File Adapter Lock- und Mutex-Tabellen, um sicherzustellen, dass Dateisperren und Mutex-Mechanismen unabhängig voneinander funktionieren, wodurch das Blockieren zwischen Standorten verhindert wird.
  3. Verwenden Sie eine separate Datenbank für die File Adapter Lock- und Mutex-Tabellen, um sicherzustellen, dass die Dateiverarbeitungsmetadaten separat verwaltet werden.

Um den Dateiadapter so zu konfigurieren, dass verschiedene Datenbanken oder separate Schemas in jeder Region verwendet werden, müssen Sie den entsprechenden Schemaeigentümer und die entsprechenden Tabellen erstellen und eine neue Datenquelle einrichten. Die Server in Region 1 verwenden weiterhin die ursprüngliche Datenquelle. Nur der Deployment-Plan in Region 2 wird zur Verwendung der neuen Datenquelle geändert.

  1. Erstellen Sie das Schema und die Tabellen:
    1. Erstellen Sie in der Datenbank ein neues Schema, das für die Vorgänge des Dateiadapters dediziert ist.
    2. Erstellen Sie in diesem Schema die erforderlichen Tabellen, die der Dateiadapter für Dateisperren und Mutex-Mechanismen benötigt.

      Skript für die Erstellung der Tabellen:

      CREATE TABLE FILEADAPTER_IN
                (
                FULL_PATH VARCHAR2(4000) NOT NULL,
                ROOT_DIRECTORY VARCHAR2(3000) NOT NULL,
                FILE_DIRECTORY VARCHAR2(3000) NOT NULL,
                FILE_NAME VARCHAR2(1000) NOT NULL,
                FILE_ENDPOINT_GUID VARCHAR2(2000) NOT NULL,
                FILE_LAST_MODIFIED NUMBER,
                FILE_READONLY CHAR(1),
                FILE_PROCESSED CHAR(1) DEFAULT '0',
                CREATED NUMBER NOT NULL,
                UPDATED NUMBER ,
                TENANT_ID NUMBER(18,0) DEFAULT -1
                );
                ALTER TABLE FILEADAPTER_IN ADD CONSTRAINT FILEADAPTER_IN_PK PRIMARY KEY (FULL_PATH);
                CREATE INDEX IDX_ROOT_DIRECTORY ON FILEADAPTER_IN (ROOT_DIRECTORY );
                CREATE INDEX IDX_FILE_DIRECTORY ON FILEADAPTER_IN (FILE_DIRECTORY );
                CREATE INDEX IDX_FILE_PROCESSED ON FILEADAPTER_IN (FILE_PROCESSED );
                CREATE INDEX IDX_FILE_READONLY ON FILEADAPTER_IN (FILE_READONLY );
                ----------------------------------------------------------------------- 
                -- FILEADAPTER_MUTEX 
                --------------------------------------------------------------------- 
                CREATE TABLE FILEADAPTER_MUTEX
                (
                MUTEX_ID VARCHAR2(4000) NOT NULL,
                MUTEX_CREATED TIMESTAMP,
                MUTEX_LAST_UPDATED TIMESTAMP,
                MUTEX_SEQUENCE NUMBER ,
                TENANT_ID NUMBER(18,0) DEFAULT -1
                );
                ALTER TABLE FILEADAPTER_MUTEX  ADD CONSTRAINT FILEADAPTER_MUTEX_PK PRIMARY KEY (MUTEX_ID);
  2. Neue Datenquelle konfigurieren:
    1. Zugriff auf die WebLogic Remotekonsole.
    2. Zu Datenquellen navigieren: Wählen Sie im Baum "Bearbeiten" die Optionen Services, Datenquellen aus.
    3. Erstellen Sie eine neue Datenquelle, die eine Verbindung zu dem in Schritt 1 erstellten Schema herstellt. Der Typ der Datenquelle muss ein Oracle-Treiber (Thin XA) für GridLink-Verbindungsversionen sein: Beliebig
    4. Ordnen Sie die Datenquelle dem entsprechenden Cluster zu, in dem der Dateiadapter verwendet wird.
  3. Erstellen Sie ein Backup des File Adapter-Deployment-Plans in der Region 1.
    cp /u01/oracle/config/dp/example_domain/FileAdapterPlan.xml /u01/oracle/config/dp/example_domain/FileAdapterPlan.xml.orig
  4. Dateiadapterkonfiguration der Datenquelle in der Dateiadapter-Deployment-Plane aktualisieren
    1. Stellen Sie eine Verbindung zur WebLogic Remotekonsole her, und öffnen Sie die Dateiadapterkonfiguration, wie unter High Availability für Oracle JMS Adapter aktivieren beschrieben.
    2. Geben Sie in der Eigenschaft InboundDataSource der Dateiadapterinstanz, die vom System verwendet wird, den JNDI-Namen der neuen Datenquelle an. Beispiel: jdbc/FileAdapter_Region2.
    3. Speichern Sie die Änderungen in der WebLogic Remotekonsole.
  5. Kopieren Sie den generierten Deployment-Plan in die Region 2.

    Beispiel:

    scp /u01/oracle/config/dp/example_domain/FileAdapterPlan.xml region2_server1:/u01/oracle/config/dp/example_domain/FileAdapterPlan.xml
  6. Setzen Sie den ursprünglichen Dateiadapterplan in Region 1 zurück.

    Beispiel:

    cp /u01/oracle/config/dp/example_domain/FileAdapterPlan.xml.orig /u01/oracle/config/dp/example_domain/FileAdapterPlan.xml
  7. Stellen Sie den Adapter mit der WebLogic Remotekonsole erneut bereit.

Die Server in Region 1 verwenden die ursprüngliche Datenquelle, während die Server in Region 2 die neue verwenden.

Oracle Fusion Middleware Oracle SOA Suite In-Memory SOA konfigurieren

In-Memory-SOA ist eine Funktion, die den Oracle Coherence-Cache nutzt, der mit Oracle WebLogic Server verknüpft ist, um die nicht-transaktionalen Geschäftsprozesse im Speicher auszuführen.

Dies verbessert die Performance und Skalierbarkeit dieser Geschäftsprozesse, da Lese- und Schreibvorgänge aus dem Cache ausgeführt werden.

Die BPEL-Statusinformationen werden in den Oracle Coherence-Cache gespeichert und daraus abgerufen. Der Prozessstatus wird nur dann in die Datenbank geschrieben, wenn ein Fehler auftritt, oder in regelmäßigen Abständen mit einem Write-Behind-Thread.

In-Memory-SOA wird in der gestreckten Clustertopologie von Oracle Fusion Middleware nicht unterstützt, wobei die Nutzung des Coherence-Caches minimal sein muss, da es sehr empfindlich auf Verzögerungen reagiert.

Tuning konfigurieren WebLogic Database Leasing

Oracle empfiehlt die Konfiguration von Automatic Service Migration für Enterprise Deployment-Topologien.

Das Datenbank-Leasing ist ein Kernmechanismus zur Unterstützung der automatischen Servicemigration, insbesondere für geclusterte Singleton-Services wie JMS-Server oder JTA Transaction Recovery Service. Sie dient zur Verwaltung und Koordination der Eigentümerschaft dieser Singleton-Services über mehrere Server in einem Cluster hinweg. Dieser Mechanismus verwendet eine Datenbank als zentralen Punkt, um zuverlässig zu verfolgen und zu steuern, welcher Server in einem Cluster zu einem bestimmten Zeitpunkt "besitzt" oder einen bestimmten Singleton-Service verwaltet. Dazu wird ein Releasedatensatz in der Datenbank gespeichert, der vom Eigentümerserver regelmäßig aktualisiert (erneut verlängert) wird. Siehe Leasing für migrierbare Services in Cluster für Oracle WebLogic Server verwalten.

Die Konfiguration für die zuvor in dieser Dokumentation bereitgestellten GridLink-Datenquellen garantiert automatische Neuverbindungen, wenn ein Datenbank-Failover oder ein Switchover stattfindet. Alle Server, die mit Datenbankleasing oder mit persistenten JDBC-Speichern konfiguriert sind, können jedoch bei einem Datenbankausfall, Switchover oder Failover heruntergefahren werden. Wenn ein kritisches Subsystem (wie der JTA-Service) ausfällt, wird der Server auf den Status FAILED gesetzt und vom Node Manager automatisch neu gestartet.

Die Zeit, die benötigt wird, um in den Status FAILED zu gelangen, ist variabel. Sie hängt davon ab, wann die relevanten Prüfungen ausgelöst werden, und kann aus verschiedenen Gründen auftreten:

  • Wenn der Server die Leasing-Tabelle nach der Gesamtanzahl der Wiederholungen nicht aktualisieren kann.
  • Wenn der Server nach verschiedenen Wiederholungen und In-Place-Neustarts nicht auf den persistenten JTA JDBC-Speicher zugreifen kann.

Ein Datenbank-Switchover kann einige Minuten dauern. Der automatische Neustart von WLS-Servern aufgrund des Zugriffsverlusts auf den persistenten JTA JDBC-Speicher dauert ca. 8-9 Minuten, sodass er bei einem typischen Switchover oder Failover der Datenbank nicht ausgelöst wird. Ein Server kann jedoch in den Status FAILED übergehen, da ein Leasing in weniger als 2 Minuten mit der Standard-Leasingkonfiguration verloren geht. Daher kann ein Neustart von Oracle WebLogic Server bei einem Oracle Data Guard-Switchover oder -Failover automatisch ausgelöst werden, wenn dieser WebLogic-Server Datenbankleasing verwendet.

Es gibt zwei Parameter, um die Resilienz von Datenbankausfällen für Server mit Datenbankleasing zu verbessern. Diese Parameter sind database-leasing-basis-connection-retry-count (standardmäßig 1 Wiederholung) und database-leasing-basis-connection-retry-delay (standardmäßig 1 Sekunde). Die Erhöhung dieser Parameter verlängert die Zeit, bevor ein Leasingfehler auftritt. Dadurch können die WebLogic-Server längere Datenbankausfälle tolerieren, ohne dass sie automatisch neu gestartet werden. Sie stellen einfach eine erneute Verbindung zur Datenbank her, sobald sie wieder verfügbar ist. Obwohl Verbindungsversuche nicht erfolgreich sind, während die Datenbank heruntergefahren ist, werden die WebLogic-Server nicht neu gestartet.

Daher wird in einem gestreckten Cluster empfohlen, die Werte für "Anzahl Wiederholungen der Datenbank-Leasing-Verbindung" und "Timeout" zu erhöhen, um den WebLogic-Server widerstandsfähiger gegen die Datenbankausfälle zu machen. Um diese Eigenschaften zu ändern, verwenden Sie WLST-Befehle. Beispiel:

$ORACLE_COMMON_HOME/common/bin/wlst.sh
        connect('weblogic','password','t3s://ADMINVHN:9002')
        edit()
        startEdit()
        cd('/Clusters/' + 'My_Cluster')
        cmo.setDatabaseLeasingBasisConnectionRetryCount(10)
        cmo.setDatabaseLeasingBasisConnectionRetryDelay(10000L)
        save()
        activate()
        disconnect()
        exit()
Wenn es sich um einen geplanten Switchover handelt, können Sie den WebLogic-Server vor dem Datenbank-Switchover-Vorgang ordnungsgemäß herunterfahren. Dadurch wird jedoch die gesamte Ausfallzeit für den Switchover erhöht. Sie können entweder einen Ansatz basierend auf der Systemlast oder den Geschäftsanforderungen verwenden.

Tipp:

Wenn ein Server den Status FAILED erreicht, versucht der Node Manager standardmäßig zwei Neustarts für den Server. Wenn der Server nicht ordnungsgemäß hochgefahren werden kann, wird er als FAILED_NOT_RESTARTABLE markiert. Sie können die Anzahl der Neustarts auf der Registerkarte Zustand des Servers optimieren. Mit dem Parameter Max. Neustarts innerhalb des Intervalls definieren Sie, wie oft der Node Manager den Server innerhalb des unter Neustartintervall angegebenen Intervalls neu starten kann.

Coherence konfigurieren

Coherence ist eine Komponente der Oracle Fusion Middleware, die von verschiedenen Produkten verwendet wird.

Beispiel: Oracle SOA Suite verwendet Oracle Coherence, um Composite-Deployments und Metadaten-(MDS-)Updates in einem Cluster zu propagieren.

Oracle Coherence unterstützt sowohl Multicast- als auch Unicast-Kommunikation für Cluster Member Discovery und Messaging. Unicast eignet sich besonders in Umgebungen, in denen Multicast nicht verfügbar ist oder nicht unterstützt wird, z. B. in mehreren Data Centern oder Cloud-Regionen. Mit dem Feature für bekannte Adressen (WKA) können Cluster-Member das Cluster erkennen und verknüpfen, ohne sich auf Multicast zu verlassen. Wenn WKA konfiguriert ist, ist die gesamte Multicast-Kommunikation deaktiviert. Standardmäßig verwenden Oracle Fusion Middleware-Produkte Unicast mit einer vordefinierten WKA-Liste für Coherence.

Oracle Coherence ist empfindlich auf Verzögerungen bei der Clusterbildung und bei der Reaktion auf Heartbeats von Cluster-Membern. Allerdings haben aktuelle Versionen eine verbesserte Toleranz gegenüber Kommunikationsverzögerungen durch Features wie allowable variance. Die allowable variance definiert die zulässigen Timingvariationen in der Netzwerkkommunikation in einem Coherence-Cluster. Dieser konfigurierbare Parameter (maximum-time-variance), der standardmäßig auf 16 ms gesetzt wird, legt die maximal zulässige Latenz für Roundtrip Time-(RTT-)UDP-Kommunikationen fest. Coherence passt diesen Wert dynamisch an, indem es auf beobachtete Netzwerklatenzen oder Inkonsistenzen reagiert und die Clusterstabilität und -performance aufrechterhält, indem größere Abweichungen beim erwarteten Timing berücksichtigt werden. Die Meldung Increasing allowable variance to XX gibt eine solche Anpassung an. Siehe Operational Configuration Elements in Developing Applications with Oracle Coherence.

Mit dieser Verbesserung von Oracle Coherence werden keine Fehler bei der Clusterbildung gemeldet, wenn die Latenz innerhalb der empfohlenen Limits für die FMW-gestreckte Clustertopologie (<10 ms RTT) bleibt. Dennoch können lange Verzögerungen bei Cluster-Heartbeats zu Konflikten bei Bereitstellungen und schlechten Reaktionszeiten auf Ausfälle führen.

Wenn Fehler in der Coherence-Clusterbildung oder bei Operationen auftreten, können Sie die folgenden Coherence-Netzwerktimeoutparameter anpassen:

  • <multicast-listener> <join-timeout-milliseconds>. Obwohl es ursprünglich für Multicast-Konfigurationen konzipiert wurde, wirkt sich Join-Timeout auch in Unicast aus. Es bestimmt, wie lange der anfängliche Knoten dauert, um ein Cluster zu bilden, und danach, wie lange jeder Knoten nach dem Cluster sucht, bevor er versucht, sich selbst zu bilden (wenn er sich auf der WKA-Liste befindet). Der Standardwert ist 3000. In einem unzuverlässigen Netzwerk müssen Sie diesen Wert möglicherweise erhöhen, um einen längeren Zeitraum zu versuchen, ein Cluster zu finden, bevor Sie ein neues starten.
  • <packet-publisher><packet-delivery><resend-milliseconds>. Das Intervall für das erneute Senden des Pakets gibt die minimale Zeit in Millisekunden an, die der Paketherausgeber auf ein entsprechendes ACK-Paket wartet, bevor ein Paket erneut gesendet wird. Dies sollte ein paar Vielfache der RTT sein, 10x sollte in Ordnung sein. Der Standardwert ist 200.
  • <packet-publisher><packet-delivery><timeout-milliseconds>. Bei Paketen, die eine Bestätigung erfordern, wird die maximale Zeit in Millisekunden angegeben, die ein Paket erneut gesendet wird. Nach Ablauf dieses Timeouts bestimmt Coherence, ob der Empfänger als beendet betrachtet wird. Der Standardwert von 5 Minuten sollte ausreichen. Sie können ihn jedoch erhöhen, um Timeouts beim Beitritt zum Cluster zu vermeiden.
  • <packet-publisher><packet-delivery><heartbeat-milliseconds> Dieser Parameter ist das Heartbeat-Intervall für die TCP-Ring-Todeserkennung. Der Standard-Heartbeat-Wert ist 1 Sekunde. Sie können den Wert erhöhen, um den Netzwerkverkehr zu lindern. Dies verlängert jedoch auch die Erkennung ausgefallener Member.
  • <tcp-ring-listener><ip-timeout> und <ip-attempts>. Dies ist der Zeitraum und die Versuche, bevor festgestellt wird, dass ein Computer, der Cluster-Mitglieder hostet, nicht erreichbar ist. IP-Timeout sollte im Bereich von 10x der RTT oder höher liegen, mit einem Minimum von 5s.
  • <cluster-config> <tcp-ring-listener><enabled>. Sie können sogar die TCP-Ring-Todeserkennung deaktivieren, um den Netzwerkverkehr zu lindern, aber auch die Erkennung von ausgefallenen Mitgliedern dauert länger. Um die Erkennung von Todesfällen zu deaktivieren, setzen Sie sie auf "false". Wenn diese Option deaktiviert ist, verwendet ein Cluster Member das Timeoutintervall für das erneute Senden des Paketherausgebers, um festzustellen, dass ein anderes Member nicht mehr auf UDP-Pakete reagiert (standardmäßig 5 Minuten).

Um die Standardkonfigurationseinstellungen zu ändern, verwenden Sie eine Coherence-Override-Datei. Erstellen Sie eine Datei mit dem Namen custom-coherence-override-<name>.xml, und stellen Sie sicher, dass sie konsistent und für alle Server im Cluster zugänglich ist. Geben Sie diese Datei in der java-Eigenschaft tangosol.coherence.override an. Sie können sie in der Eigenschaft EXTRA_JAVA_PROPERTIES java in der Datei setUserOverrides.sh festlegen. Beispiel: 

EXTRA_JAVA_PROPERTIES="${EXTRA_JAVA_PROPERTIES} -Dtangosol.coherence.override=/u01/oracle/config/coherence_custom/custom-coherence-override.xml"

Beispiel für eine Coherence-Override-Datei zur Optimierung von Parametern:

 <?xml version='1.0'?>
      <!--
      This is a custom operational configuration override 
      -->
      <coherence  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
      xmlns="http://xmlns.oracle.com/coherence/coherence-operational-config"
      xsi:schemaLocation="http://xmlns.oracle.com/coherence/coherence-operational-config coherence-operational-config.xsd"
      >
      <cluster-config>
      <multicast-listener>
      <join-timeout-milliseconds>5000</join-timeout-milliseconds>
      </multicast-listener>
      <tcp-ring-listener>
      <ip-timeout>20s</ip-timeout>
      <ip-attempts>3</ip-attempts>
      </tcp-ring-listener>
      <packet-publisher>
      <packet-delivery>
      <resend-milliseconds>200</resend-milliseconds>
      <timeout-milliseconds>650000</timeout-milliseconds>
      </packet-delivery>
      </packet-publisher>
      </cluster-config>
      </coherence>

Beispiel für eine Coherence-Override-Datei zur Optimierung des tcp-Ring-Intervalls:


      <?xml version='1.0'?>
      <coherence xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
      xmlns="http://xmlns.oracle.com/coherence/coherence-operational-config"
      xsi:schemaLocation="http://xmlns.oracle.com/coherence/coherence-operational-config coherence-operational-config.xsd">
      <cluster-config>
      <packet-publisher>
      <packet-delivery>
      <heartbeat-milliseconds>5000</heartbeat-milliseconds>    
      </packet-delivery>
      </packet-publisher>
      </cluster-config>
      </coherence>

Beispiel für eine Kohärenzüberschreibungsdatei zur Deaktivierung der TCP-Ring-Todeserkennung:

<?xml version='1.0'?>
      <coherence xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
      xmlns="http://xmlns.oracle.com/coherence/coherence-operational-config"
      xsi:schemaLocation="http://xmlns.oracle.com/coherence/coherence-operational-config coherence-operational-config.xsd">
      <cluster-config>
      <tcp-ring-listener>
      <enabled>false</enabled>
      </tcp-ring-listener>
      </cluster-config>
      </coherence>

Net Service Performance konfigurieren

Bei einem gestreckten Cluster-Deployment von Oracle Fusion Middleware (FMW) sind die Betriebssystem-Sockets und das Tuning von Oracle Net Services für eine effiziente regionsübergreifende Datenübertragung von entscheidender Bedeutung.

Einige Standardkonfigurationen des Betriebssystems sind möglicherweise nicht optimiert, und es wird sehr wichtig, einige Parameter anzupassen, um die Datenübertragung effizienter zu gestalten. Diese Anpassungen werden besonders wichtig, wenn eine hohe Latenz zwischen JDBC-Clients und -Servern besteht. Die Server mit der höchsten Latenz beim Datenbankzugriff sollten die Konfiguration von Netzwerkpuffern und Oracle Net Services-Einstellungen steuern, um die Performance zu optimieren.

Eine der Hauptmetriken bei der Bestimmung der optimalen Konfiguration ist das Bandwidth-Delay-Produkt (BDP). Es stellt die maximale Datenmenge dar, die zu einem bestimmten Zeitpunkt in einem Netzwerk übertragen werden kann. Er wird berechnet, indem die Kapazität (Bandbreite) eines Netzwerklinks mit der Roundtrip-Verzögerungszeit (Latenz) multipliziert wird:

BDP = Bandwidth × Round-Trip Time (RTT)
  • RTT: In OCI können Sie das durchschnittliche RTT zwischen Regionen von der Seite Regionsübergreifende Latenz in der OCI-Konsole abrufen. Alternativ können Sie die Roundtrip-Zeit (RTT) mit Befehlen wie Ping von einem Host auf einen anderen über einige Minuten bestimmen und die zurückgegebenen Antwortzeiten verwenden.
  • Bandbreite: Es gibt keine garantierte Bandbreite zwischen OCI-Regionen, und OCI bietet kein spezifisches OCI-Bandbreitenmessungstool. Für präzise Bandbreitenmessungen können Sie Tools wie iPerf verwenden, um Tests durchzuführen. Die getestete Bandbreite zwischen Frankfurt und Amsterdam beträgt etwa 2–2,5 Gbit/s.

Die TCP-Socket-Puffereinstellungen steuern, wie viele Pakete gleichzeitig über das Netzwerk gesendet werden. Um einen optimalen Durchsatz zu erzielen, wird empfohlen, die Socket-Puffergröße auf mindestens den BDP zu setzen. In vielen Fällen kann die Einstellung der Puffergröße auf das Doppelte des BDP die Performance weiter verbessern, insbesondere in Netzwerken mit hoher Latenz. Übermäßig große Puffer können jedoch zu einer erhöhten Speicherauslastung führen. Daher ist es ratsam, die Puffergröße im Bereich des BDP auf das Dreifache des BDP einzustellen:

BDP ≤ Socket Buffer Size ≤ 3 × BDP

I/O-Puffergrößen in der Datenbank konfigurieren

Der Datenbankserver schreibt hauptsächlich Daten in Clients. Daher reicht das Festlegen des Parameters SEND_BUF_SIZE auf Serverseite in der Regel aus.

Wenn der Datenbankserver große Anforderungen empfängt, legen Sie auch den Parameter RECV_BUF_SIZE fest. Es wird empfohlen, sie auf Oracle Net Services-Ebene in der Datenbank und nicht auf Betriebssystemebene zu optimieren, sodass normale TCP-Sessions wie SSH usw. keinen zusätzlichen Speicher verwenden.

Um diese Parameter für den Datenbankserver zu konfigurieren, legen Sie die Größe des Pufferspeichers in den Dateien listener.ora oder sqlnet.ora fest.

  • Geben Sie in der Datei listener.ora die Buffer Space-Parameter für eine bestimmte Protokolladresse oder für eine Beschreibung an. Im Folgenden finden Sie ein Beispiel für die Einstellungen für eine typische Oracle RAC-Listener-Konfiguration in einem Base Database-System in Oracle Cloud Infrastructure (OCI): 

    LISTENER_SCAN2=(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=IPC)(KEY=LISTENER_SCAN2))))
LISTENER_SCAN1=(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=IPC)(KEY=LISTENER_SCAN1))))
LISTENER_SCAN3=(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=IPC)(KEY=LISTENER_SCAN3))))
(…)
LISTENER=(DESCRIPTION=(SDU=65535)(SEND_BUF_SIZE=10485760)(RECV_BUF_SIZE=10485760)(ADDRESS_LIST=(ADDRESS=(PROTOCOL=IPC)(KEY=LISTENER))))

  • Wenn die Parameter in sqlnet.ora festgelegt sind, werden sie global auf alle Listener angewendet. Im Folgenden finden Sie ein Beispiel für die Einstellungen in der Datei sqlnet.ora: 

    RECV_BUF_SIZE=10485760
SEND_BUF_SIZE=10485760

I/O-Puffergrößen in Middle Tier-Knoten konfigurieren

Die Oracle JDBC-Thin-Clients können keine Socket-Puffergrößen angeben. Daher müssen Sie diese Puffer im Betriebssystem der Middle Tier-Knoten anpassen.

Das Linux-Betriebssystem verwendet die automatische Optimierung sowohl für den Empfang als auch für den Absenderpuffer.

Für den Empfangspuffer wird die automatische Optimierung durch den Parameter /proc/sys/net/ipv4/tcp_moderate_rcvbuf bestimmt. Wenn der Parameter den Wert 1 hat, ist die automatische Optimierung aktiviert. Bei der automatischen Optimierung wird die Empfängerpuffergröße (und die TCP-Fenstergröße) für jede Verbindung dynamisch aktualisiert, wobei die maximale Puffergröße 4 MB beträgt.

Für den Absenderpuffer ist die automatische Optimierung ebenfalls standardmäßig aktiviert. Die automatische Optimierung des Empfangspuffers kann zwar über den Parameter tcp_moderate_rcvbuf gesteuert werden, die automatische Optimierung des Sendepuffers hat jedoch keinen direkten Umschalter. Wenn Sie nur feste Puffergrößen festlegen, wird die automatische Optimierung des Sendepuffers deaktiviert.

Diese automatischen Optimierungsprozesse werden von mehreren Kernel-Parametern gesteuert, die Speicherzuweisung für das Senden und Empfangen von Daten verwalten:

  • Pro Verbindungspuffergröße

    Die Speicherzuweisung für jede TCP-Verbindung wird durch zwei Parameter definiert:

    • /proc/sys/net/ipv4/tcp_rmem, das den für TCP-Empfangspuffer reservierten Speicher angibt.
    • /proc/sys/net/ipv4/tcp_wmem, das den für TCP-Sendepuffer reservierten Speicher angibt.

    Beide Parameter akzeptieren drei Werte:

    • Minimale Puffergröße: die kleinste Puffergröße, die einem TCP-Socket zugewiesen ist.
    • Standardpuffergröße: Die anfängliche Puffergröße, die einem TCP-Socket beim Erstellen zugewiesen wird.
    • Maximale Puffergröße: die größte Puffergröße, die automatisch einem TCP-Socket zugewiesen werden kann.

    Diese Einstellungen legen die Grenzen für Auto-Tuning-Mechanismen fest und helfen, die Speicherauslastung, insbesondere in Zeiten von Speicherstress, auszugleichen.

  • Puffergrößen pro Anwendung

    Anwendungen können bestimmte Puffergrößen anfordern. Diese Anforderungen unterliegen jedoch den durch die folgenden Parameter definierten Grenzwerten:

    • /proc/sys/net/core/rmem_max ist das maximale Empfangsfenster, in dem der obere Grenzwert für die Empfangspuffergröße festgelegt wird, die Anwendungen anfordern können.
    • /proc/sys/net/core/wmem_max ist das maximale Sendefenster, in dem der obere Grenzwert für die Sendepuffergröße festgelegt wird, die Anwendungen anfordern können.

So passen Sie I/O-Puffergrößen an:

  1. Stellen Sie sicher, dass die automatische Empfangsoptimierung aktiviert ist.
    /proc/sys/net/ipv4/tcp_moderate_rcvbuf:   1
  2. Optimieren Sie den maximalen TCP-Speicher für Verbindungen, die Puffer empfangen und senden (proc/sys/net/ipv4/tcp_rmem and tcp_wmem) auf einen Wert größer/gleich 2xBDP.
    /proc/sys/net/ipv4/tcp_rmem:     4096    131072  6291456
            /proc/sys/net/ipv4/tcp_wmem:    4096    16384   4194304
  3. Passen Sie die Socket-Fenstergrößen auf einen Wert größer/gleich 2xBDP an.

    Beispiel: Einstellung in /etc/sysctl,conf: 

    /proc/sys/net/core/rmem_max:     4194304
            /proc/sys/net/core/wmem_max:    4194304
  4. Stellen Sie sicher, dass die TCP-Leistungsfunktionen aktiviert sind, indem Sie alle der folgenden Werte auf 1 setzen.
    /proc/sys/net/ipv4/tcp_sack:                     1
            /proc/sys/net/ipv4/tcp_window_scaling: 1
            /proc/sys/net/ipv4/tcp_timestamps:        1

Die automatische TCP-Optimierung bleibt mit Begrenzungen aktiviert, die für das Bandbreitenverzögerungsprodukt Ihres Netzwerks skaliert sind. Dadurch wird der Durchsatz verbessert, ohne die Systemspeichernutzung zu stark zu dimensionieren.

Größe der Sessiondateneinheit konfigurieren

Oracle Net Services sendet Daten in Packages mit einer bestimmten Größe.

Oracle Net Services wartet, bis diese Einheiten gefüllt sind, bevor sie über das Netzwerk gesendet werden. Jeder dieser Puffer ist eine Session Data Unit (SDU). Durch die Anpassung der SDU-Größe an die Datenmenge, die Oracle Net Services bereitgestellt wird, können Performance, Netzwerkauslastung und Speicherverbrauch in einem gestreckten Oracle Fusion Middleware-Cluster mit höheren Latenzzeiten als 5 ms RTT verbessert werden.

Die SDU-Größe kann von 512 Byte auf 2 MB eingestellt werden. In Oracle Database 23ai beträgt die Standard-SDU-Größe 64 KB (65.536 Byte). Frühere Datenbankreleases setzen ihre Standard-SDU-Größe auf 8 KB.

Die tatsächlich verwendete SDU-Größe wird zur Verbindungszeit zwischen dem Client und dem Server ausgehandelt und ist der kleinere der beiden Werte. Um eine SDU-Größe zu konfigurieren, die sich von der Standardgröße unterscheidet, muss das SDU sowohl auf dem Client- als auch auf dem Servercomputer konfiguriert werden. Oracle empfiehlt, das SDU auf den maximal möglichen Wert (64k) zu setzen.

  1. Legen Sie das SDU auf den Middleware-Servern fest, indem Sie den TNS-Eintrag in der Datei tnsnames.ora aktualisieren, die von den WebLogic-Datenquellen verwendet wird.
    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)(SDU=65535))
 )
(ADDRESS_LIST=
     (LOAD_BALANCE=on)
    (ADDRESS=(PROTOCOL=TCP)(HOST=stbydb-scan.dbsubnet.region2vcn.oraclevcn.com)(PORT=1521)(SDU=65535))    
)
(CONNECT_DATA=(SERVICE_NAME=pdbservice.example.com))
  2. Legen Sie das SDU auf den Datenbankservern fest, indem Sie die Listener-Konfiguration oder serverweite SQLNET-Einstellungen ändern.

    Sie können die Listener-Konfigurationsdatei listener.ora (pro Listener) ändern oder DEFAULT_SDU_SIZE in sqlnet.ora festlegen, um die SDU-Größe für alle Oracle Net Services-Verbindungen auf dem Server zu definieren. Der Standardwert in 23ai ist bereits auf 64k gesetzt. 

    (…)
LISTENER=(DESCRIPTION)(SDU=65535)(SEND_BUF_SIZE=10485760)(RECV_BUF_SIZE=10485760)(ADDRESS_LIST=(ADDRESS=(PROTOCOL=IPC)(KEY=LISTENER))))

Clients und Server verhandeln das SDU zur Verbindungszeit. Durch die Konfiguration beider Seiten wird sichergestellt, dass das beabsichtigte SDU verwendet wird.