Configurer des optimisations supplémentaires pour les clusters étendus FMW

Configuration des délais d'expiration dans Oracle WebLogic Server (WLS)

Les délais d'attente peuvent se produire dans différentes couches de la pile Oracle Fusion Middleware (FMW).

Des limites d'expiration sont indiquées pour les transactions dans la base de données, pour les branchements de transaction, les appels de méthode Enterprise JavaBean (EJB), les services Web, etc. Les déploiements de cluster étendus Oracle Fusion Middleware sont particulièrement sensibles aux paramètres de délai d'expiration car plusieurs opérations doivent accéder à la base de données à un emplacement différent. Configurez les délais d'attente de manière à ce que :

Ils tiennent compte de la latence dans le système.
Vous devrez peut-être augmenter les délais d'attente dans ces types de systèmes en raison des latences impliquées. Dans le modèle de cluster étendu, les paramètres de domaine sont partagés pour les deux sites. Par conséquent, il est nécessaire d'utiliser des délais d'attente qui tiennent compte du pire scénario.
Ils expirent correctement dans la chaîne d'appels sur différentes couches.
Les délais d'attente doivent être configurés dans les différentes couches du système afin que les niveaux appropriés se comportent correctement. Par exemple, si le délai d'expiration de la base de données est défini sur une valeur inférieure au délai d'expiration WLS global, un ID de transaction peut être "supprimé" de la base de données avant la fin du travail sur d'autres branches.

Voici les principaux paramètres de délai d'expiration dans différentes couches :

Délai d'attente de transaction globale
Le délai d'expiration de transaction globale Oracle WebLogic Server détermine la durée maximale (en secondes) pendant laquelle une transaction distribuée (une transaction globale) est autorisée à rester active avant d'être automatiquement annulée par Oracle WebLogic Server. Configurez le délai d'expiration de transaction globale dans WebLogic Remote Console en sélectionnant JTA (API de transaction Java) dans la section Services de l'arborescence de modification et en indiquant Délai d'expiration en secondes.
Délai de transaction XA
Le délai d'expiration de transaction XA dans les sources de données XA est utilisé dans Oracle WebLogic Server pour définir un délai d'expiration de branchement de transaction pour les sources de données. Par défaut, cette valeur est définie sur 0 (zéro) , de sorte qu'elle utilise le délai d'expiration de transaction globale WebLogic. Toutefois, vous pouvez définir ce paramètre si vous disposez de transactions longues qui dépassent le délai d'attente par défaut de la ressource XA. Cette valeur est configurée pour chaque source de données XA, dans l'onglet Transaction.
Délai d'expiration du verrouillage distribué
Le délai d'expiration du verrou distribué dans la base de données indique la durée (en secondes) pendant laquelle les transactions distribuées attendent les ressources verrouillées. Vous pouvez modifier le paramètre (distributed_lock_timeout) avec les instructions SQL ALTER appropriées.

Définissez le délai d'expiration du verrouillage distribué de la base de données suffisamment long pour la transaction la plus lente, en tenant compte des retards réseau entre les sites. Ensuite, définissez la source de données XA et les délais d'attente globaux des transactions sur des valeurs inférieures à l'aide de la règle suivante :

distributed_lock_timeout >= XA DS Timeout >= Global Transaction Timeout

Les applications peuvent utiliser des paramètres d'expiration supplémentaires. Par exemple, Oracle SOA et BPEL ont les paramètres d'expiration supplémentaires suivants que vous devez prendre en compte :

syncMaxWaitTime
syncMaxWaitTime est la durée maximale pendant laquelle un client synchrone attend une réponse. Ce paramètre définit la durée d'une opération de demande et de réponse avant son expiration. Si le processus BPEL n'obtient pas de réponse dans ce délai, l'activité échoue. Pour modifier cette valeur dans Oracle Enterprise Manager Fusion Middleware Control :
1. Cliquez avec le bouton droit de la souris sur SOA-infra, puis sélectionnez Administration SOA.
2. Sélectionnez Propriétés BPEL.
3. Sélectionnez Autres propriétés de configuration BPEL.
4. Mettez à jour la valeur syncMaxWaitTime (en secondes).
Délai d'expiration pour les EJB
Lorsque les méthodes EJB BPEL sont impliquées, cela indique le délai d'expiration de la transaction en secondes (la valeur par défaut est 300 pour tous les EJB BPEL). Modifiez le délai d'expiration comme suit :
1. Dans l'arborescence de surveillance de WebLogic Remote Console, sélectionnez Déploiements, puis Gestion des applications.
2. Développez l'application soa_infra, puis Configuration et Sous-déploiement.
3. Développez le module et sélectionnez l'EJB BPEL spécifique.
Pour éviter les exceptions SOA dues à la suppression de transactions avant la fin des processus, utilisez la règle suivante :
```
Global Transaction Timeout > BPEL EJB's transaction timeout > syncMaxWaitTime 
```
Délais d'attente des clients de services Web
Le client de services Web doit être configuré avec un délai d'expiration suffisamment permissif avec la latence la plus faible. Par exemple, si un appel prend 3 secondes sur le site 1 mais 10 secondes sur le site 2, le délai d'expiration doit être défini sur au moins 10 secondes pour gérer le site plus lent.
Délai d'expiration des processus BPEL
Si le processus BPEL utilise des délais d'attente spécifiques de réponse aux demandes (synchrones) et de réception (asynchrones) uniquement, vous devez les définir en fonction du scénario le plus défavorable : lorsque l'appel va vers le site avec la latence de base de données la plus élevée. Ces paramètres d'expiration sont définis dans le processus BPEL et ne peuvent pas être définis différemment pour chaque site. Pour plus d'informations sur la configuration des événements et des délais d'attente dans les processus BPEL, reportez-vous au manuel Oracle Fusion Middleware Developer's Guide for Oracle SOA Suite. Voir la section Explorer plus.

Configurer la réplication de session

Certaines applications (applications Web, consoles telles qu'Oracle SOA Composer, BPM Composer, espace de travail BPM, etc.) utilisent intensivement des objets de session HTTP.

L'un des avantages du déploiement de cluster étendu d'Oracle Fusion Middleware (FMW) est la possibilité de fournir un basculement transparent entre les sites. Toutefois, la réplication de session entre les régions peut entraîner une dégradation des performances du système. Oracle recommande de définir deux groupes de réplication différents (un pour chaque région) afin de réduire la réplication sur les deux sites.

Pour configurer des groupes de réplication de session, procédez comme suit :

Dans l'arborescence de modification de la console distante WebLogic, sélectionnez Environnement, puis Serveurs.
Sélectionnez Nom du serveur, puis l'onglet Cluster.
Pour chaque serveur de la région 1, entrez le même nom de groupe de réplication (par exemple, Region1RepGroup).
Répétez les étapes pour les serveurs de la région 2, en utilisant un nom commun pour tous, mais différent de celui utilisé dans la région 1 (par exemple, Region2RepGroup).

Notez que l'utilisation de groupes de réplication est un meilleur effort pour répliquer l'état uniquement sur les serveurs du même site, mais n'est pas une méthode déterministe. Si un seul serveur est disponible sur un site et que d'autres sont disponibles sur l'autre, la réplication se produira dans les régions et se poursuivra pour cette session même si les serveurs sont de nouveau en ligne sur le même site.

Configurer le redémarrage sans réutilisation de la mémoire pour JMS

Configurez le redémarrage sur place pour les serveurs JMS (Java Message Service) et les espaces de stockage persistants.

Les espaces de stockage persistants sont essentiels au bon fonctionnement des serveurs Oracle WebLogic Server (WLS). Avec le redémarrage sur place, si l'espace de stockage persistant rencontre une erreur, le service JMS tente de redémarrer sur le même serveur avant de tenter de migrer vers un autre serveur. Cette méthode est plus rapide que la migration de l'ensemble du service JMS vers un autre serveur et peut souvent résoudre les problèmes rapidement.

Pour configurer le redémarrage sur place pour les espaces de stockage persistants JMS, le serveur JMS et l'espace de stockage persistant associés doivent être ciblés sur une cible migrable. Cette cible migrable doit utiliser Redémarrer en cas d'échec, qui n'est pas activé par défaut. Pour configurer cette propriété, procédez comme suit :

Connexion à la console distante WebLogic
Dans l'arborescence de modification, sélectionnez Environnement, puis Cibles migrables.
Sélectionnez une cible migrable et activez Redémarrer en cas d'échec.
Sélectionnez Enregistrer et validez les modifications.

Configurer l'adaptateur JMS Oracle FMW SOA Suite

L'adaptateur JMS (Java Message Service) requiert la configuration de propriétés d'instanciateur de connexions spécifiques qui incluent la liste des serveurs disponibles pour l'extraction de contexte JNDI.

Oracle recommande d'utiliser la syntaxe de cluster (par exemple, cluster:t3s://cluster_name) pour simplifier la configuration. Cette approche simplifie la configuration en permettant à l'adaptateur d'extraire dynamiquement la liste actuelle des serveurs actifs dans le cluster, ce qui garantit une extraction efficace du contexte JNDI.

Si le système utilise l'adaptateur JMS de manière intensive et avec des charges utiles volumineuses, il est recommandé de configurer l'URL JNDI de manière à inclure uniquement les serveurs locaux dans chaque région. Cela signifie spécifier des serveurs dans la région 1 pour les configurations dans la région 1, et des serveurs dans la région 2 pour les configurations dans la région 2. Cette configuration garantit l'affinité du contexte du site, optimisant les performances et réduisant la latence.

Mettez à jour les propriétés du pool de connexions sortantes pour l'instance que l'adaptateur utilise, en indiquant comme java.naming.provider.url la liste des serveurs de la région 1. Par exemple :
```
java.naming.provider.url=t3s://region1_server1:7004,region1_server2:7004
```
Pour plus d'informations, reportez-vous à Activation de la haute disponibilité pour les adaptateurs Oracle JMS dans le Guide de déploiement Oracle Fusion Middleware Enterprise pour Oracle SOA Suite.
Une fois la modification validée dans WebLogic Remote Console, copiez le plan de déploiement généré dans l'emplacement miroir de la région 2. Par exemple, dans region1_server1 :
```
scp /u01/oracle/config/dp/example_domain/My_Cluster/JMSPlan.xml region2_server1:/u01/oracle/config/dp/example_domain/My_Cluster/
```

Modifiez manuellement le plan de déploiement dans la région 2 et remplacez la liste des serveurs par la liste des serveurs dans Site2.

Extrait du plan de déploiement pour la région 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>

Extrait du plan de déploiement pour la région 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>

Mettez à jour le déploiement de l'adaptateur JMS à l'aide du plan de déploiement modifié (le même emplacement sur les deux sites, mais en réalité un fichier différent). La mise à jour utilisera le fichier de plan de déploiement de la région 1 pour les serveurs de la région 1 et le fichier de plan de déploiement de la région 2 pour les serveurs de la région 2.

Configurer l'adaptateur de fichiers Oracle FMW SOA Suite

L'adaptateur de fichiers utilise des tables de base de données pour gérer le verrouillage et la coordination des fichiers mutex.

Ce mécanisme garantit que le même fichier est traité par un seul serveur à la fois et que deux instances d'adaptateur n'écrivent pas simultanément dans le même fichier.

Dans la topologie de cluster étendue Oracle Fusion Middleware (FMW), chaque site fonctionne indépendamment et traite les fichiers à l'aide de son propre stockage partagé dédié. Cependant, par défaut, les deux sites utilisent la même source de données, le même schéma et les mêmes tables pour le verrouillage de fichiers et les mécanismes mutex.

Dans les opérations sortantes, l'utilisation d'une table de base de données partagée est appropriée car une séquence unique est utilisée en tant que mutex pour empêcher les opérations d'écriture simultanées d'écraser les fichiers.

Toutefois, des scénarios de "sous-traitement" peuvent survenir pour les opérations entrantes. Les instances d'adaptateur de fichiers de chaque site peuvent marquer un fichier comme "bloqué". Si le même nom de fichier existe dans les deux sites, ce mécanisme peut bloquer son traitement dans les deux emplacements, mais le fichier sera utilisé dans un seul d'entre eux. Pour éviter ces situations, il existe plusieurs alternatives :

Implémentez les conventions de dénomination des fichiers propres au site. Utilisez des identificateurs uniques dans les noms de fichier en fonction du site, ce qui réduit le risque de collisions de noms et de blocage ultérieur.
Configurez des schémas distincts pour chaque région pour les tables de verrouillage et de mutex de l'adaptateur de fichiers afin de garantir que le verrouillage des fichiers et les mécanismes mutex fonctionnent indépendamment, ce qui empêche le blocage intersite.
Utilisez une base de données distincte pour les tables de verrouillage et de mutex de l'adaptateur de fichiers afin de vous assurer que les métadonnées de traitement des fichiers sont gérées séparément.

Pour configurer l'adaptateur de fichiers afin qu'il utilise des bases de données ou des schémas distincts dans chaque région, vous devez créer le propriétaire et les tables de schéma appropriés, puis établir une nouvelle source de données. Les serveurs de la région 1 continueront d'utiliser la source de données d'origine. Seul le plan de déploiement de la région 2 sera modifié pour utiliser la nouvelle source de données.

Créez le schéma et les tables :

Dans la base de données, créez un schéma dédié aux opérations de l'adaptateur de fichiers.

Dans ce schéma, créez les tables requises par l'adaptateur de fichiers pour le verrouillage de fichiers et les mécanismes mutex.

Script permettant de créer les tables :

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

Configurez une nouvelle source de données :
1. Accès à WebLogic Remote Console.
2. Accédez aux sources de données : dans l'arborescence de modification, sélectionnez Services, puis Sources de données.
3. Créez une source de données qui se connecte au schéma créé à l'étape 1. Le type de la source de données doit être un pilote Oracle (XA fin) pour les versions de connexions GridLink : toutes
4. Ciblez la source de données vers le cluster approprié dans lequel l'adaptateur de fichiers est utilisé.

Effectuez une sauvegarde du plan de déploiement de l'adaptateur de fichiers dans la région 1.

cp /u01/oracle/config/dp/example_domain/FileAdapterPlan.xml /u01/oracle/config/dp/example_domain/FileAdapterPlan.xml.orig

Mettre à jour la configuration de l'adaptateur de fichiers de la source de données dans le plan de déploiement de l'adaptateur de fichiers
1. Connectez-vous à la console distante WebLogic et ouvrez la configuration de l'adaptateur de fichiers comme décrit dans Activation de la haute disponibilité pour les adaptateurs Oracle JMS.
2. Dans la propriété InboundDataSource de l'instance d'adaptateur de fichiers utilisée par le système, indiquez le nom JNDI de la nouvelle source de données. Par exemple : jdbc/FileAdapter_Region2.
3. Enregistrez les modifications dans la console distante WebLogic.

Copiez le plan de déploiement généré dans la région 2.

Exemple :

scp /u01/oracle/config/dp/example_domain/FileAdapterPlan.xml region2_server1:/u01/oracle/config/dp/example_domain/FileAdapterPlan.xml

Rétablissez le plan d'adaptateur de fichiers d'origine dans la région 1.

Exemple :

cp /u01/oracle/config/dp/example_domain/FileAdapterPlan.xml.orig /u01/oracle/config/dp/example_domain/FileAdapterPlan.xml

Redéployez l'adaptateur à l'aide de la console distante WebLogic.

Les serveurs de la région 1 utiliseront la source de données d'origine tandis que les serveurs de la région 2 utiliseront la nouvelle.

Configurer SOA en mémoire Oracle Fusion Middleware Oracle SOA Suite

L'architecture SOA en mémoire est une fonctionnalité qui exploite le cache Oracle Coherence associé à Oracle WebLogic Server pour exécuter les processus métier non transactionnels en mémoire.

Les performances et l'évolutivité de ces processus métier sont ainsi améliorées à mesure que les opérations de lecture et d'écriture sont effectuées hors du cache.

Les informations d'état BPEL sont stockées dans le cache Oracle Coherence et extraites de celui-ci. L'état du processus est écrit dans la base de données uniquement en cas de panne ou à intervalles réguliers à l'aide d'un thread d'écriture différée.

L'architecture SOA en mémoire n'est pas prise en charge dans la topologie de cluster étendue Oracle Fusion Middleware, où l'utilisation du cache Coherence doit être minimale, car elle est très sensible aux retards.

Configurer le réglage de la location de base de données WebLogic

Oracle recommande de configurer la migration automatique des services pour les topologies de déploiement d'entreprise.

La location de base de données est un mécanisme de base utilisé pour prendre en charge la migration automatique des services, en particulier pour les services singleton clusterisés tels que les serveurs JMS ou le service de récupération des transactions JTA. Il permet de gérer et de coordonner la propriété de ces services singleton sur plusieurs serveurs d'un cluster. Ce mécanisme utilise une base de données comme point central pour suivre et contrôler de manière fiable le serveur d'un cluster "propriété" ou gère un service singleton spécifique à un moment donné. Pour ce faire, vous stockez un enregistrement de version dans la base de données, qui est régulièrement mis à jour (renouvelé) par le serveur propriétaire. Reportez-vous à Leasing for Migratable Services dans Administration de clusters pour Oracle WebLogic Server.

La configuration des sources de données GridLink fournie précédemment dans ce guide garantit la reconnexion automatique lorsqu'un basculement de base de données ou une permutation a lieu. Toutefois, tous les serveurs configurés avec le leasing de base de données ou avec des espaces de stockage persistants JDBC peuvent s'arrêter pendant une panne, une permutation ou un basculement de base de données. Lorsqu'un sous-système critique (comme le service JTA) tombe en panne, le serveur est défini sur l'état FAILED et il est automatiquement redémarré par le gestionnaire de noeuds.

Le temps nécessaire pour passer à l'état FAILED est variable ; il dépend du moment où les vérifications pertinentes sont déclenchées et peut se produire pour diverses raisons :

Si le serveur ne parvient pas à mettre à jour la table de location après le nombre total de nouvelles tentatives.
Si le serveur ne peut pas accéder à l'espace de stockage persistant JDBC JTA après plusieurs tentatives et redémarrages sur place.

Une permutation de base de données peut prendre quelques minutes. Le redémarrage automatique des serveurs WLS en raison de la perte d'accès à l'espace de stockage persistant JDBC JTA prend plus de temps, soit environ 8 à 9 minutes, de sorte qu'il n'est pas déclenché lors d'une permutation ou d'un basculement standard de la base de données. Mais un serveur peut passer à l'état FAILED en raison de la perte d'un bail en moins de 2 minutes avec la configuration de crédit-bail par défaut. Par conséquent, un redémarrage d'Oracle WebLogic Server peut être déclenché automatiquement lors d'une permutation ou d'un basculement Oracle Data Guard si ce serveur WebLogic utilise l'association de bases de données.

Il existe deux paramètres pour améliorer la résilience aux pannes de base de données pour les serveurs utilisant la location de base de données. Ces paramètres sont database-leasing-basis-connection-retry-count (1 nouvelle tentative par défaut) et database-leasing-basis-connection-retry-delay (1 seconde par défaut). L'augmentation de ces paramètres prolonge la durée avant qu'une erreur de location perdue ne se produise. Cela permet aux serveurs WebLogic de tolérer des pannes de base de données plus longues sans redémarrer automatiquement. Ils se reconnectent simplement à la base de données une fois qu'elle est à nouveau disponible. Bien que les tentatives de connexion échouent lorsque la base de données est arrêtée, les serveurs WebLogic ne sont pas redémarrés.

Par conséquent, dans un cluster étendu, il est recommandé d'incrémenter les valeurs Nombre de nouvelles tentatives de connexion Database Leasing et Délai d'expiration pour rendre le serveur WebLogic plus résilient aux pannes de base de données. Pour modifier ces propriétés, utilisez les commandes WLST. Exemple :

$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()

Sinon, s'il s'agit d'une permutation planifiée, vous pouvez arrêter progressivement le serveur WebLogic avant l'opération de permutation de base de données, mais cela augmente le temps d'inactivité total de la permutation. Vous pouvez utiliser l'une ou l'autre approche en fonction de la charge système ou des besoins métier.

Conseil :

Lorsqu'un serveur passe à l'état FAILED, le gestionnaire de noeuds tente deux redémarrages pour le serveur par défaut. Si le serveur ne peut pas démarrer correctement, il est marqué comme FAILED_NOT_RESTARTABLE. Vous pouvez régler le nombre de redémarrages dans l'onglet Etat du serveur. Utilisez le paramètre Nombre maximal de redémarrages dans l'intervalle pour définir le nombre de redémarrages du serveur que le gestionnaire de noeuds peut effectuer dans l'intervalle défini dans Intervalle de redémarrage.

Configurer Coherence

Coherence est un composant d'Oracle Fusion Middleware utilisé par différents produits.

Par exemple, Oracle SOA Suite utilise Oracle Coherence pour propager les déploiements de composite et les mises à jour de métadonnées (MDS) dans un cluster.

Oracle Coherence prend en charge la communication en multidiffusion et en monodiffusion pour le repérage et la messagerie des membres du cluster. La monodiffusion est particulièrement adaptée aux environnements où la multidiffusion n'est pas disponible ou n'est pas prise en charge, par exemple dans plusieurs centres de données ou régions cloud. Grâce à la fonctionnalité d'adresses connues (WKA), les membres du cluster peuvent repérer et rejoindre le cluster sans recourir à la multidiffusion. Lorsque WKA est configuré, toutes les communications multicast sont désactivées. Par défaut, les produits Oracle Fusion Middleware utilisent la monodiffusion avec une liste WKA prédéfinie pour Coherence.

Oracle Coherence est sensible aux retards lors de la formation du cluster et de la réponse aux signaux d'activité des membres du cluster. Cependant, les versions récentes ont amélioré la tolérance aux retards de communication grâce à des fonctionnalités telles que allowable variance. allowable variance définit les variations de temps autorisées dans les communications réseau au sein d'un cluster Coherence. Ce paramètre configurable (maximum-time-variance), dont la valeur par défaut est 16 ms, définit la latence maximale autorisée pour les communications UDP avec temps d'aller-retour (RTT). Coherence ajuste cette valeur de manière dynamique en fonction des latences ou des incohérences de réseau observées, en maintenant la stabilité et les performances du cluster en tenant compte des écarts plus importants au moment prévu. Le message Increasing allowable variance to XX indique un tel ajustement. Reportez-vous à Eléments de configuration opérationnelle dans le manuel Développement d'applications avec Oracle Coherence.

Grâce à cette amélioration dans Oracle Coherence, aucune erreur n'est signalée lors de la formation du cluster si la latence reste dans les limites recommandées pour la topologie de cluster étendue FMW (RTT < 10 ms). Toutefois, de longs retards sur les signaux d'activité de cluster peuvent entraîner des conflits dans les déploiements et des temps de réaction incorrects aux pannes.

Si vous rencontrez des erreurs dans la formation ou les opérations du cluster Coherence, vous pouvez ajuster les paramètres de délai d'expiration du réseau Coherence suivants :

<multicast-listener> <join-timeout-milliseconds>. Bien que conçu à l'origine pour les configurations de multidiffusion, le délai d'attente de jointure a également un impact sur la monodiffusion. Il détermine combien de temps le noeud initial prendra pour former un cluster, et ensuite combien de temps chaque noeud passera à rechercher le cluster avant d'essayer de former le sien (s'ils figurent sur la liste WKA). La valeur par défaut est 3000. Sur un réseau peu fiable, vous devrez peut-être augmenter cette valeur, afin de rechercher un cluster plus longtemps avant d'en démarrer un nouveau.
<packet-publisher><packet-delivery><resend-milliseconds>. L'intervalle de renvoi de paquet spécifie la durée minimale, en millisecondes, pendant laquelle l'éditeur de paquet attend un paquet ACK correspondant, avant de renvoyer un paquet. Il doit s'agir de quelques multiples du RTT, 10x doit être correct. La valeur par défaut est 200.
<packet-publisher><packet-delivery><timeout-milliseconds>. Pour les paquets nécessitant une confirmation, spécifie la durée maximale, en millisecondes, pendant laquelle un paquet est renvoyé. Une fois ce délai expiré, Coherence détermine si le destinataire doit être considéré comme ayant pris fin. La valeur par défaut de 5 minutes doit être suffisante, mais vous pouvez l'augmenter pour éviter les délais d'attente lors de l'adhésion au cluster.
<packet-publisher><packet-delivery><heartbeat-milliseconds> Ce paramètre est l'intervalle de signal d'activité pour la détection de la mort de l'anneau TCP. La valeur par défaut du signal d'activité est de 1 seconde. Vous pouvez augmenter la valeur pour réduire le trafic réseau, mais cela prolonge également la détection des membres défaillants.
<tcp-ring-listener><ip-timeout> et <ip-attempts>. Il s'agit de la durée et des tentatives avant de déterminer qu'un ordinateur hébergeant des membres de cluster est devenu inaccessible. Le délai d'expiration IP doit être situé dans la zone de 10x, avec un minimum de 5s.
<cluster-config> <tcp-ring-listener><enabled>. Vous pouvez même désactiver la détection de la mort par anneau TCP pour réduire le trafic réseau, mais cela rend également la détection des membres défaillants plus longue. Pour désactiver la détection de décès, définissez-la sur False. Si cette option est désactivée, un membre du cluster utilise l'intervalle de délai d'expiration du renvoi de l'éditeur de paquets pour déterminer qu'un autre membre a cessé de répondre aux paquets UDP (par défaut défini sur 5 minutes).

Pour modifier les paramètres de configuration par défaut, utilisez un fichier de remplacement Coherence. Créez un fichier nommé custom-coherence-override-<name>.xml et assurez-vous qu'il est cohérent et accessible pour tous les serveurs du cluster. Indiquez ce fichier dans la propriété java tangosol.coherence.override. Vous pouvez la définir dans la propriété java EXTRA_JAVA_PROPERTIES du fichier setUserOverrides.sh. Exemple :

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

Exemple de fichier de remplacement Coherence pour régler les paramètres :

 <?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>

Exemple de fichier de remplacement Coherence pour régler l'intervalle tcp-ring :


      <?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>

Exemple de fichier de remplacement de cohérence pour désactiver la détection de décès par anneau TCP :

<?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>

Configurer les performances de service réseau

Dans un déploiement de cluster étendu Oracle Fusion Middleware (FMW), les sockets de système d'exploitation et le réglage Oracle Net Services sont essentiels pour une transmission efficace des données entre les régions.

Certaines configurations par défaut du système d'exploitation peuvent ne pas être optimisées et il devient très important d'ajuster certains paramètres pour rendre le transfert de données plus efficace. Ces ajustements deviennent particulièrement importants lorsque la latence entre les clients JDBC et les serveurs est élevée. Les serveurs présentant la latence la plus élevée en matière d'accès à la base de données doivent guider la configuration des tampons réseau et des paramètres Oracle Net Services afin d'optimiser les performances.

L'une des mesures clés pour déterminer la configuration optimale est le produit de retard de bande passante (BDP). Il représente la quantité maximale de données qui peuvent être en transit dans un réseau à un moment donné. Il est calculé en multipliant la capacité d'une liaison réseau (bande passante) par son temps de retard aller-retour (latence) :

BDP = Bandwidth × Round-Trip Time (RTT)

RTT : dans OCI, vous pouvez obtenir le RTT moyen entre les régions à partir de la page Latence inter-région de la console OCI. Vous pouvez également déterminer le temps d'aller-retour (RTT) à l'aide de commandes telles que la commande ping d'un hôte à un autre en quelques minutes et utiliser les temps de réponse renvoyés.
Bande passante : il n'existe pas de bande passante garantie entre les régions OCI, et OCI ne propose pas d'outil de mesure de bande passante OCI spécifique. Pour des mesures de bande passante précises, vous pouvez utiliser des outils tels que iPerf pour effectuer des tests. La bande passante testée entre Francfort et Amsterdam est d'environ 2 à 2,5 Gbps.

Les paramètres du tampon de socket TCP contrôlent le nombre de paquets envoyés simultanément sur le réseau. Pour atteindre un débit optimal, il est recommandé de définir la taille du tampon de socket sur au moins le BDP. Dans de nombreux cas, le fait de définir la taille de la mémoire tampon sur deux fois le BDP peut encore améliorer les performances, en particulier dans les réseaux à latence élevée. Cependant, des tampons trop volumineux peuvent entraîner une utilisation accrue de la mémoire. Par conséquent, il est conseillé de définir la taille du tampon dans la plage du BDP sur trois fois le BDP :

BDP ≤ Socket Buffer Size ≤ 3 × BDP

Configurer les tailles de tampon d'E/S dans la base de données

Le serveur de base de données écrit principalement des données sur les clients. Par conséquent, il suffit généralement de définir le paramètre SEND_BUF_SIZE côté serveur.

Si le serveur de base de données reçoit des demandes volumineuses, définissez également le paramètre RECV_BUF_SIZE. Il est recommandé de les régler au niveau Oracle Net Services dans la base de données plutôt qu'au niveau du système d'exploitation, de sorte que les sessions TCP normales telles que SSH, etc. n'utilisent pas de mémoire supplémentaire.

Pour configurer ces paramètres pour le serveur de base de données, définissez la taille de l'espace tampon dans les fichiers listener.ora ou sqlnet.ora.

Dans le fichier listener.ora, indiquez les paramètres d'espace tampon pour une adresse de protocole particulière ou pour une description. Voici un exemple des paramètres d'une configuration de processus d'écoute Oracle RAC standard dans un système Base Database dans 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))))

Si les paramètres sont définis dans sqlnet.ora, ils s'appliquent globalement à tous les processus d'écoute. Voici un exemple des paramètres du fichier sqlnet.ora :
```
RECV_BUF_SIZE=10485760
SEND_BUF_SIZE=10485760
```

Configuration des tailles de tampon d'E/S dans les noeuds de niveau intermédiaire

Les clients légers JDBC Oracle ne peuvent pas indiquer de tailles de tampon de socket ; vous devez donc ajuster ces tampons dans le système d'exploitation des noeuds de niveau intermédiaire.

Le système d'exploitation Linux utilise le réglage automatique pour la réception et le tampon de l'expéditeur.

Pour le tampon de réception, le réglage automatique est déterminé par le paramètre /proc/sys/net/ipv4/tcp_moderate_rcvbuf. Si le paramètre a la valeur 1, le réglage automatique est activé. Avec le réglage automatique, la taille du tampon du récepteur (et la taille de la fenêtre TCP) est mise à jour dynamiquement pour chaque connexion, avec une taille de tampon maximale de 4 Mo.

Pour le tampon d'expéditeur, le réglage automatique est également activé par défaut. Bien que le réglage automatique du tampon de réception puisse être contrôlé via le paramètre tcp_moderate_rcvbuf, le réglage automatique du tampon d'envoi n'a pas de basculement direct. La définition de tailles de tampon fixes désactive le réglage automatique du tampon d'envoi.

Ces processus de réglage automatique sont régis par plusieurs paramètres de noyau qui gèrent l'allocation de mémoire pour l'envoi et la réception de données :

Par taille de tampon de connexion
L'allocation de mémoire pour chaque connexion TCP est définie par deux paramètres :
- /proc/sys/net/ipv4/tcp_rmem, qui indique la mémoire réservée aux tampons de réception TCP.
- /proc/sys/net/ipv4/tcp_wmem, qui indique la mémoire réservée aux tampons d'envoi TCP.
Les deux paramètres acceptent trois valeurs :
- Taille de tampon minimale : plus petite taille de tampon allouée à un socket TCP.
- Taille de tampon par défaut : taille de tampon initiale affectée à un socket TCP lors de sa création.
- Taille maximale du tampon : taille maximale du tampon qui peut être allouée automatiquement pour un socket TCP.
Ces paramètres établissent les limites des mécanismes de réglage automatique et aident à équilibrer l'utilisation de la mémoire, en particulier pendant les périodes de contrainte de mémoire.
Tailles de tampon par application
Les applications peuvent demander des tailles de tampon spécifiques, mais ces demandes sont soumises à des limites définies par les paramètres suivants :
- /proc/sys/net/core/rmem_max est la fenêtre de réception maximale, qui définit la limite supérieure de la taille du tampon de réception que les applications peuvent demander.
- /proc/sys/net/core/wmem_max est la fenêtre d'envoi maximale, qui définit la limite supérieure de la taille du tampon d'envoi que les applications peuvent demander.

Pour ajuster la taille des tampons d'E/S :

Assurez-vous que le réglage automatique de la réception est activé.
```
/proc/sys/net/ipv4/tcp_moderate_rcvbuf:   1
```
Réglez la mémoire TCP maximale pour les connexions qui reçoivent et envoient des tampons (proc/sys/net/ipv4/tcp_rmem and tcp_wmem) à une valeur supérieure ou égale à 2xBDP.
```
/proc/sys/net/ipv4/tcp_rmem:     4096    131072  6291456
            /proc/sys/net/ipv4/tcp_wmem:    4096    16384   4194304
```
Réglez les tailles des fenêtres de socket sur une valeur supérieure ou égale à 2xBDP.

Par exemple, la définition dans /etc/sysctl,conf :
```
/proc/sys/net/core/rmem_max:     4194304
            /proc/sys/net/core/wmem_max:    4194304
```

Assurez-vous que les fonctions de performances TCP sont activées en définissant tous les éléments suivants sur 1.

/proc/sys/net/ipv4/tcp_sack:                     1
            /proc/sys/net/ipv4/tcp_window_scaling: 1
            /proc/sys/net/ipv4/tcp_timestamps:        1

Le réglage automatique TCP reste activé avec des limites dimensionnées pour le produit de retard de bande passante de votre réseau, ce qui améliore le débit sans surdimensionnement de l'utilisation de la mémoire système.

Configuration de la taille des unités de données de session

Oracle Net Services envoie des données dans des packages dont la taille est spécifique.

Oracle Net Services attend que ces unités soient remplies avant de les envoyer sur le réseau. Chacun de ces tampons est une unité de données de session (SDU). L'ajustement de la taille de la SDU à la quantité de données fournies à Oracle Net Services peut améliorer les performances, l'utilisation du réseau et la consommation de mémoire dans un cluster étendu Oracle Fusion Middleware avec des latences supérieures à 5 ms RTT.

La taille de la SDU peut être définie de 512 octets à 2 Mo. Dans Oracle Database 23ai, la taille SDU par défaut est de 64 ko (65 536 octets). Les versions antérieures de la base de données définissent leur taille SDU par défaut sur 8 ko.

La taille réelle de la SDU utilisée est négociée entre le client et le serveur au moment de la connexion et est la plus petite des deux valeurs. La configuration d'une taille SDU différente de la taille par défaut nécessite la configuration de la SDU sur les ordinateurs client et serveur. Oracle recommande de définir la SDU sur la valeur maximale possible (64k).

Définissez la SDU sur les serveurs middleware en mettant à jour l'entrée TNS dans le fichier tnsnames.ora utilisé par les sources de données WebLogic.

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

Définissez la SDU sur les serveurs de base de données en modifiant la configuration du processus d'écoute ou les paramètres SQLNET à l'échelle du serveur.

Vous pouvez modifier le fichier de configuration du processus d'écoute listener.ora (par processus d'écoute) ou définir DEFAULT_SDU_SIZE dans sqlnet.ora pour définir la taille de la SDU pour toutes les connexions Oracle Net Services sur le serveur. La valeur par défaut dans 23ai est déjà définie sur 64k.
```
(…)
LISTENER=(DESCRIPTION)(SDU=65535)(SEND_BUF_SIZE=10485760)(RECV_BUF_SIZE=10485760)(ADDRESS_LIST=(ADDRESS=(PROTOCOL=IPC)(KEY=LISTENER))))
```

Les clients et les serveurs négocient la SDU au moment de la connexion ; la configuration des deux côtés garantit que la SDU prévue est utilisée.