Configurer les clusters étendus FMW

Configurer des régions

Le modèle de cluster étendu Oracle Fusion Middleware (FMW) est configuré sur deux sites séparés.

Dans Oracle Cloud Infrastructure (OCI), vous pouvez l'implémenter dans les régions OCI qui présentent une faible latence entre elles. La latence inter-région maximale prise en charge est de 10 ms aller-retour (RTT). Vous pouvez vérifier la latence entre les régions dans la console OCI en sélectionnant Fonctions de réseau, Centre de commande réseau, puis Latence inter-région.

Compte tenu des valeurs de latence, vous pouvez déployer ce modèle entre des régions telles que Francfort et Amsterdam, qui ont 6-7 ms RTT. Toutefois, vous ne pouvez pas déployer ce modèle entre des emplacements tels qu'Ashburn et Phoenix, car la latence entre ces régions dépasse 50 ms RTT.

Exemple de paires de régions avec une latence inter-région inférieure à 10 ms RTT :

Amsterdam (AMS) - Paris (CDG)
Amsterdam (AMS) - Newport (CWL)
Amsterdam (AMS) - Francfort (FRA)
Amsterdam (AMS) - Londres (LHR)
Paris (CDG) - Francfort (FRA)
Paris (CDG) - Londres (LHR)
Paris (CDG) - Newport (CWL)
Marseille (MRS) - Milan (LIN)
Zurich (ZHR) - Francfort (FRA)
Zurich (ZHR) - Milan (LIN)
Osaka (KIX) - Tokyo (NRT)
Singapour (SIN) - Batan (HSG)
Sao Paulo (GRU) - Vinhedo (VCP)
Singapour (SIN) - Singapour 2 (XSP)
Batan (HSG) - Singapour 2 (XSP)
Séoul (ICN) - Chuncheon (YNY)
Toronto (YYZ) - Montréal (YUL)

En ce qui concerne la bande passante, il n'y a 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, utilisez des outils tels que iPerf. La bande passante testée entre Francfort et Amsterdam est d'environ 2 à 2,5 gigabits par seconde (Gbps).

Vous pouvez également implémenter ce modèle entre les domaines de disponibilité de la même région. Le déploiement des serveurs Oracle WebLogic Server sur les domaines de disponibilité est, en fait, le comportement standard des services Platform-as-a-Service (PaaS) tels qu'Oracle SOA Suite on Marketplace et les piles Oracle WebLogic Server for OCI. Toutefois, l'implémentation de ce modèle dans les domaines de disponibilité au lieu d'une région à l'autre n'est pas vraiment une solution de protection contre les catastrophes, car elle ne protège pas contre les événements qui affectent l'ensemble d'une région.

Conseil :

Pour créer les sous-réseaux, les règles, les instances de calcul, le stockage partagé et les équilibreurs de charge requis pour un déploiement FMW sur chaque site, vous pouvez utiliser la structure WLS-HYDR (reportez-vous à la procédure de création d'infrastructure).

Configuration du réseau

Les réseaux cloud virtuels dans les régions où vous déployez cette topologie doivent être interconnectés pour permettre le trafic entre tous les serveurs WebLogic du cluster et des serveurs WebLogic vers les bases de données.

Les fonctions réseau suivantes sont nécessaires à la configuration :

Un VCN et des sous-réseaux hiérarchisés dans chaque région.
Connexion d'appairage à distance entre les réseaux cloud virtuels, avec des passerelles de routage dynamique.
Les règles de routage appropriées pour acheminer le trafic entre les sites. Dans la région 1, les tables de routage doivent inclure un routage vers le CIDR VCN de la région 2 via la passerelle de routage dynamique. De même, les tables de routage de la région 2 doivent inclure un routage vers le CIDR du VCN de la région 1 via la passerelle de routage dynamique.
Règles de sécurité réseau permettant la communication suivante pour le cluster étendu :
- Ouvrez les ports du serveur WebLogic et du gestionnaire de noeuds entre les sous-réseaux de niveau intermédiaire de la région 1 et de la région 2. Si Coherence est utilisé, autorisez également le trafic TCP et UDP pour les ports Coherence.
- Autoriser le trafic vers le processus d'écoute de base de données et les ports Oracle Cloud Infrastructure Notifications (ONS) dans les deux régions à partir des sous-réseaux de niveau intermédiaire de la région 1 et de la région 2.
- Par défaut, la communication inter-région entre OHS et les serveurs WebLogic n'est pas nécessaire. Les ports du serveur WebLogic du sous-réseau de niveau intermédiaire ne doivent être accessibles qu'à partir des serveurs OHS de la même région. Cependant, une communication inter-région peut être requise dans des circonstances exceptionnelles, par exemple si tous les serveurs Web d'une région échouent. Des détails supplémentaires sont fournis dans la section Gérer les défaillances.
Tous les noms d'hôte utilisés par le système (adresses d'écoute WebLogic, adresse SCAN et adresse IP virtuelle de la base de données principale et de secours) doivent pouvoir être résolus à partir des deux sites. Par défaut, dans OCI, les noms d'hôte ne peuvent être résolus que dans chaque VCN. Pour permettre la résolution des noms de région 1 dans la région 2, créez une vue DNS privée dans la région 2 pour le domaine de région 1 et ajoutez les noms et adresses IP pertinents. Répétez ce processus dans la région 1 pour résoudre les noms de la région 2.
Sur chaque site, le nom front-end du système (tel que frontend.example.com) doit pointer vers l'adresse IP de l'équilibreur de charge local. Pour ce faire, ajoutez le nom front-end à une vue DNS privée dans chaque région ou au fichier /etc/hosts des hôtes de niveau intermédiaire. Cela garantit que tous les rappels d'un serveur WebLogic vers le front-end sont dirigés vers la région locale.

configurer la base de données,

Configurez un système de base de données Oracle Real Application Clusters (Oracle RAC) dans la région 1 avec un système de base de données RAC de secours dans la région 2.

Il est important d'utiliser RAC dans chaque région car la haute disponibilité locale est une exigence essentielle. La configuration de la protection inter-domaines de disponibilité ou inter-région n'est efficace que si la protection contre les pannes locales au sein d'une même région est déjà fiable. Si la haute disponibilité locale, telle que celle fournie par RAC, n'est pas implémentée, l'ajout d'une protection sur plusieurs domaines de disponibilité ou régions ne résout pas le risque de pannes dans l'environnement local.

Pour que l'application reste connectée et reçoive des notifications Oracle Notification Service en cas d'échec d'instance ou de noeud de base de données RAC, assurez-vous que l'application se connecte à la base de données pluggable à l'aide d'un service de base de données CRS (Cluster Ready Services). Le même service CRS doit exister dans la base principale et dans la base de données de secours. Exemples de commandes permettant de créer un service pour la connexion à la base de données pluggable :


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

Configurer le stockage partagé

Oracle Cloud Infrastructure File Storage est un service de système de fichiers entièrement géré, évolutif et sécurisé fourni par OCI. Il est conçu pour fournir un stockage de fichiers hautes performances aux applications d'entreprise qui nécessitent des systèmes de fichiers partagés et persistants.

Plusieurs instances de calcul peuvent monter le même système de fichiers et y accéder simultanément via le protocole NFS (Network File System).

Le modèle de cluster étendu Oracle Fusion Middleware (FMW) dans OCI utilise les systèmes OCI File Storage de chaque région pour les systèmes de fichiers partagés (par exemple, pour la configuration partagée ou pour les données d'exécution partagées). OCI File Storage offre une haute disponibilité au sein de la région : il utilise en interne un stockage redondant sur plusieurs domaines de pannes au sein d'un domaine de disponibilité. Cependant, OCI File Storage n'est pas accessible entre les régions. Par conséquent, le stockage partagé est local dans la région.

Utilisez des sauvegardes locales et des répliques de système de fichiers entre les régions pour fournir une copie récupérable des artefacts.

Configurer le niveau intermédiaire

Les noeuds de calcul de niveau intermédiaire sont répartis dans les deux régions.

Les noeuds de calcul de niveau intermédiaire sont répartis entre les deux régions, la moitié des noeuds étant situés dans la région 1 et l'autre moitié dans la région 2. Le processus de provisionnement et d'installation est identique à celui de la création d'un seul domaine WebLogic. Pour implémenter les fonctionnalités de haute disponibilité (telles que la migration des services JMS (Java Message Service) et JTA (Java Transaction API), le basculement du serveur d'administration, la détection automatique des pannes avec le gestionnaire de noeuds, etc.), utilisez les meilleures pratiques recommandées dans les guides de déploiement FMW Enterprise référencés dans la section En savoir plus.

Vous pouvez soit créer le domaine et le configurer avec tous les serveurs gérés dès le début, soit redimensionner un domaine existant qui s'exécute dans une seule région en ajoutant des noeuds dans l'autre région.

Remarques :

Le modèle de cluster étendu Oracle Fusion Middleware (FMW) peut s'appliquer aux domaines créés à l'aide de services de plate-forme en tant que service (PaaS), tels qu'Oracle WebLogic Server for OCI et les piles Oracle SOA Suite on Marketplace. Par défaut, les fonctionnalités de provisionnement et d'augmentation de ces services PaaS ne prennent en charge qu'une seule région. Vous devez donc augmenter manuellement le cluster pour ajouter des noeuds dans une autre région. Reportez-vous aux procédures de mise à l'échelle d'un cluster WLS pour connaître les étapes requises pour effectuer cette opération. Notez que ces services PaaS n'incluent pas de niveau Web et n'implémentent pas certaines bonnes pratiques de haute disponibilité, telles que le basculement du serveur d'administration. Par conséquent, certaines des recommandations de ce document peuvent ne pas s'appliquer à ces environnements.

Voici les aspects les plus pertinents à implémenter dans la configuration WebLogic lors de l'utilisation du modèle de cluster étendu FMW :

Utiliser des espaces de stockage persistants de base de données
Oracle prend en charge les clusters extensibles qui utilisent des espaces de stockage persistants de base de données pour les journaux de transactions Oracle WebLogic Server et JMS. Le stockage des journaux de transactions et des données persistantes dans la base de données tire parti des fonctionnalités de réplication et de haute disponibilité intégrées de la base de données, telles qu'Oracle Real Application Clusters (Oracle RAC) et Oracle Data Guard. Avec JMS, les journaux de transactions (TLOG) et les métadonnées d'une base de données protégée par Data Guard, la synchronisation intersite est simplifiée et la cohérence au niveau de l'application est garantie. Cela signifie également que le niveau intermédiaire n'a plus besoin de stockage partagé pour ces artefacts (bien qu'il en ait toujours besoin pour le basculement du serveur d'administration, les plans de déploiement et certains adaptateurs tels que l'adaptateur de fichiers).

Toutefois, l'utilisation de TLOG et de JMS dans la base de données entraîne une pénalité sur les performances du système. Cette pénalité est augmentée lorsque l'un des niveaux intermédiaires doit communiquer avec la base de données de l'autre site. Du point de vue des performances, un stockage partagé local sur chaque site aurait de meilleures performances, mais cela introduit de la complexité et des limites pour garantir une perte de données nulle entre les régions et la cohérence des applications.
Artefacts de système de fichiers partagés locaux pour chaque région
Comme indiqué dans les guides de déploiement Oracle Fusion Middleware Enterprise, le répertoire de domaine du serveur d'administration (ASERVER_HOME) doit résider sur le stockage partagé, séparé du dossier de domaine du serveur géré (MSERVER_HOME). En plus d'utiliser un nom d'hôte virtuel pour l'adresse d'écoute du serveur d'administration, ce dernier peut basculer vers un autre hôte, dans la même région ou dans une autre.

Les autres artefacts résidant dans des systèmes de fichiers partagés sont les installations du répertoire de base Oracle (binaires), les plans de déploiement et les répertoires d'adaptateur de fichiers (dossier d'exécution).

Dans une topologie de cluster étendue FMW, chaque région utilise son propre stockage local partagé. Par conséquent, la deuxième région conserve ses propres fichiers binaires redondants (garantissant au moins deux installations binaires par site pour la haute disponibilité) et ses propres répertoires partagés pour la configuration partagée, les plans de déploiement, les fichiers d'exécution, etc. Tous ces artefacts doivent utiliser des chemins identiques dans les deux régions pour garantir la cohérence et un basculement transparent.
Utiliser un algorithme basé sur l'affinité pour le cluster WebLogic
Pour réduire le trafic intersite, utilisez l'affinité locale pour la résolution de l'instanciateur de contexte JNDI (Java Naming and Directory Interface). Pour définir l'algorithme de chargement par défaut du cluster WebLogic sur un algorithme basé sur l'affinité, procédez comme suit :
1. Accédez à l'arborescence de modification dans la console distante WebLogic.
2. Accédez à Environnement, sélectionnez Clusters et sélectionnez le cluster.
3. Dans l'onglet Général, définissez l'algorithme de charge par défaut du cluster WebLogic sur l'affinité de tourniquet (la valeur par défaut est round-robin) ou sur tout algorithme "basé sur l'affinité".
Il n'est pas nécessaire de définir l'adresse de cluster avec la liste explicite de tous les serveurs du cluster. Lorsqu'elle est vide, la valeur Adresse du cluster est générée automatiquement. Assurez-vous simplement que la propriété Number of Servers In Cluster Address, qui limite le nombre de serveurs à répertorier lors de la génération automatique de l'adresse de cluster, a une valeur suffisamment élevée pour inclure tous les serveurs du cluster.
Utiliser la configuration de la migration automatique des services
Oracle recommande de configurer la migration automatique des services avec les espaces de stockage persistants JDBC (Java Database Connectivity) pour les topologies de déploiement d'entreprise. Dans une topologie de cluster étendue FMW, la migration automatique des services est possible à l'intérieur et entre les régions, à condition que les données JMS et TLOG soient accessibles à partir des deux sites. Lorsque vous utilisez des espaces de stockage persistants JDBC, aucune considération particulière n'est requise pour configurer ASM dans un cluster étendu.

Le temps nécessaire à une opération de migration de service de la région 1 vers la région 2 peut augmenter en cas de latence élevée entre les sites. Cette augmentation est due au temps passé à récupérer les messages sur l'autre serveur, car ils sont lus à partir de l'espace de stockage persistant dans la base de données de l'autre région. Cette latence augmente avec le nombre de messages en attente dans les espaces de stockage persistants. Cependant, la pénalité ne devient pertinente qu'avec des latences très élevées ou un grand nombre de messages en attente. Pour plus d'informations sur les comportements attendus, reportez-vous à la section "Vérifier les données de performance".
Nom d'hôte et résolution frontaux
Lors de la configuration de l'hôte frontal pour votre cluster WebLogic, spécifiez le nom d'hôte virtuel que les clients utilisent pour accéder au système, comme dans tout déploiement standard. Les clients doivent résoudre ce nom d'hôte virtuel en une adresse externe équilibrée entre les instances OCI Load Balancer des régions 1 et 2. Reportez-vous à la section "A propos de l'équilibrage de charge global".

Pour vous assurer que les serveurs WebLogic de chaque région acheminent les appels internes uniquement vers leur équilibreur de charge OCI local respectif, configurez les serveurs afin de résoudre le nom d'hôte frontal à l'adresse IP de l'équilibreur de charge OCI dans leur région. Pour ce faire, vous pouvez ajouter une entrée au fichier /etc/hosts sur chaque hôte de serveur WebLogic ou les ajouter à une vue privée DNS dans chaque région :

Pour les serveurs de la région 1 :
```
[IP address of Region 1 OCI Load Balancer] [frontend hostname]
```
Pour les serveurs de la région 2 :
```
[IP address of Region 2 OCI Load Balancer] [frontend hostname]
```
Cette configuration garantit que les communications internes des serveurs WebLogic sont dirigées vers l'équilibreur de charge régional approprié, ce qui optimise le routage et les performances.

Configurer les sources de données WebLogic

Utilisez des sources de données GridLink avec une chaîne de connexion double dans toutes les sources de données WebLogic (pour les métadonnées Oracle Fusion Middleware (FMW), les espaces de stockage persistants de base de données, les tables de location, l'adaptateur de base de données, etc.) pour automatiser le basculement de base de données. Ils doivent se reconnecter automatiquement en cas de panne ou d'arrêt dans l'un des noeuds d'Oracle Real Application Clusters (Oracle RAC), mais également en cas de permutation complète de la base de données vers l'autre région. Pour ce faire, appliquez les recommandations suivantes :

Utiliser des sources de données GridLink
Les sources de données GridLink tirent parti d'Oracle Notification Service (ONS) pour détecter et réagir rapidement aux pannes de noeud de base de données ou aux interruptions de réseau, améliorant ainsi la disponibilité et la résilience des applications. Ils répartissent automatiquement les connexions de base de données en fonction des informations de charge globale en temps réel, ce qui optimise les performances et l'utilisation des ressources sur tous les noeuds RAC. Les modifications de la topologie de base de données (par exemple, l'ajout ou la suppression de noeuds RAC) sont automatiquement reconnues et gérées, ce qui réduit la surcharge administrative et réduit les temps d'arrêt.

Vous n'avez pas besoin d'indiquer manuellement l'hôte et le port ONS dans la configuration de source de données GridLink. La liste ONS est automatiquement fournie par la base de données au pilote, qui extrait les informations ONS pour les bases de données principale et de secours, ce qui facilite les connexions aux deux.
Utiliser un alias TNS
Dans la chaîne de connexion des sources de données, utilisez un alias TNS qui pointe vers une entrée du fichier tnsnames.ora, qui inclut les adresses SCAN principale et de secours. Le format de chaîne de connexion recommandé est le suivant : une description et deux listes d'adresses, une par base de données RAC :
```
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))
)
```
Pour plus d'informations sur la configuration de l'alias TNS dans les sources de données et les fichiers de configuration FMW, reportez-vous à Utilisation de l'alias TNS dans les chaînes Connect dans le Guide de déploiement Enterprise pour Oracle SOA Suite.
Utiliser l'option Tester les connexions lors de leur réservation
Assurez-vous que l'option Tester les connexions en réserve est activée pour toutes les sources de données. Ceci est particulièrement important pour les sources de données utilisées pour accéder aux espaces de stockage persistants, car ces derniers sont essentiels dans l'état global des serveurs WebLogic. Cet indicateur permet au serveur WebLogic de tester une connexion avant de l'accorder à l'application.

Pour Nom de table de test, utilisez la valeur par défaut SQL ISVALID. Il s'agit d'un test rapide et efficace, car il effectue une validation légère pour déterminer si la connexion à la base de données est toujours active, sans avoir besoin d'accéder à une table physique spécifique.
Régler la capacité initiale
Lorsqu'un serveur WebLogic démarre, un temps considérable est consacré à la création des connexions initiales pour les pools de sources de données. Différents retards sont attendus en fonction des paramètres de capacité initiaux dans les sources de données. Par défaut, la plupart des sources de données FMW utilisent une capacité initiale nulle pour leur pool de connexions. Toutefois, pour réduire le temps de réponse du système lors d'un fonctionnement normal, il peut être avantageux d'augmenter la capacité initiale du pool.
Etant donné que la capacité initiale est configurée au niveau de la source de données (pool de connexions), ces paramètres influent sur le temps de démarrage de tous les serveurs du cluster (ceux qui sont locaux à la base de données et ceux qui y sont distants). Dans un cluster étendu FMW, les serveurs résidant à distance à partir de la base de données afficheront une latence accrue au démarrage, car une capacité de pool initiale plus élevée est utilisée (reportez-vous à "Heures de début de la révision"). Par conséquent, une décision équilibrée est nécessaire entre l'optimisation des temps de réponse pendant le fonctionnement normal et la minimisation de l'heure de début pour déterminer les paramètres de capacité initiale idéaux.
Régler la capacité maximale
Le nombre de connexions de source de données actives augmente avec une latence plus élevée pour la base de données. Dans les tests effectués, les serveurs de la région distante affichent jusqu'à 2x connexions actives que le serveur colocalisé avec la base de données (voir "Vérifier les tests de stress"). Surveillez l'utilisation dans votre application et tenez compte de cela pour un dimensionnement correct des sources de données et des sessions de base de données WebLogic.

Configurer des serveurs Web

Si le système utilise un niveau Web avec des instances Oracle HTTP Server, chaque région doit disposer d'au moins deux serveurs pour fournir une haute disponibilité au sein de la région.

Pour réduire le trafic entre les régions, n'utilisez pas de configuration de liste de serveurs dynamique dans les sections de routage Oracle WebLogic Server. Configurez plutôt une liste statique des serveurs, en définissant le paramètre DynamicServerList sur OFF. La détection de défaillance est ainsi plus lente : lorsqu'un serveur WebLogic tombe en panne, le serveur HTTP prend plus de temps pour détecter la défaillance qu'avec une liste dynamique. En outre, il nécessite des mises à jour dans la configuration si de nouveaux serveurs sont ajoutés. Cependant, il améliore les performances du système.

Les extraits suivants des fichiers mod_wl_ohs.conf dans Oracle HTTP Server fournissent un exemple de la configuration requise pour le routage vers l'application Web soa-infra.

Dans la région 1 :

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

Dans la région 2 :

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

Configurer les équilibreurs de charge

Chaque région doit disposer de son propre équilibreur de charge pour répartir les demandes entre les serveurs de ce site.

Configurez le processus d'écoute dans les deux régions avec le même certificat SSL sur chaque équilibreur de charge. Configurez les serveurs back-end de sorte que l'équilibreur de charge de la région 1 comprenne les instances Oracle HTTP Server (OHS) de la région 1 (si le système n'utilise pas de serveurs Web, les serveurs soutenus sont les WebLogicles serveurs de la région 1), et l'équilibreur de charge de la région 2 inclut les serveurs OHS de la région 2 (si le système n'utilise pas de serveurs Web, les serveurs back-end sont les serveurs WebLogic de la région 2).

Configurez les vérifications de l'état pour déterminer la disponibilité des serveurs back-end, à l'aide d'une URL qui reflète précisément le statut de l'application. Cela empêche le trafic d'être acheminé vers un serveur où Oracle WebLogic Server est en cours d'exécution mais où l'application elle-même n'est pas disponible, ce qui peut se produire si la vérification de l'état cible uniquement le contexte racine (/). Cependant, évitez d'utiliser des vérifications de l'état gourmandes en ressources, car de fréquentes vérifications lourdes peuvent surcharger les serveurs soutenus. Par exemple, pour Oracle SOA, l'URL de vérification de l'état recommandée est /soa-infra/services/isSoaServerReady .

A propos de l'équilibrage de charge global

Le modèle de cluster étendu Oracle Fusion Middleware (FMW) a besoin d'un élément sur l'équilibreur de charge de chaque centre de données pour équilibrer les demandes du client entre les deux régions.

Dans les implémentations sur site, cela est traditionnellement implémenté avec un équilibreur de charge global, qui est responsable du routage intelligent, généralement basé sur les adresses IP de l'origine. Cet équilibreur de charge global est généralement situé sur l'un des sites, avec une sauvegarde sur l'autre site pour le basculement.

Dans Oracle Cloud Infrastructure (OCI), il n'existe pas de service d'équilibreur de charge global dédié. Toutefois, vous pouvez bénéficier d'une fonctionnalité globale d'équilibrage de charge à l'aide de stratégies de gestion du trafic.

Utilisation des stratégies de pilotage OCI Traffic Management en tant qu'équilibreur de charge global

Utilisez les stratégies de pilotage de la gestion du trafic Oracle Cloud Infrastructure (OCI) pour équilibrer la charge du trafic du client entre les deux sites.

Les stratégies de pilotage de la gestion du trafic fournissent des réponses intelligentes aux requêtes DNS (Domain Name System), ce qui signifie que différentes réponses peuvent être fournies pour la requête en fonction de la logique définie dans la stratégie. Il existe différents types de stratégie :

Stratégie d'équilibreur de charge
Les stratégies d'équilibreur de charge répartissent le trafic entre plusieurs adresses. Des pondérations égales peuvent être affectées à des adresses afin de répartir le trafic uniformément entre les adresses ou les pondérations personnalisées doivent être affectées à des fins d'équilibrage de charge de ratio. Les moniteurs et les tests à la demande Oracle Cloud Infrastructure Health Checks sont utilisés pour évaluer l'état de l'adresse. Si une adresse est en mauvais état, le trafic DNS est automatiquement distribué aux autres adresses.
Stratégie de basculement
Les stratégies de basculement vous permet de définir l'ordre de priorité des réponses que vous souhaitez utiliser dans une stratégie (par exemple, primaire et secondaire). Les moniteurs OCI Health Checks et les sondes à la demande sont utilisés pour évaluer l'état des réponses dans la stratégie. Si la réponse est en mauvais état, le trafic DNS est automatiquement piloté vers la réponse secondaire
Politique de pilotage de la géolocalisation
Les stratégies de pilotage de géolocalisation distribuent le trafic DNS à différentes adresses en fonction de l'emplacement de l'utilisateur final. Les clients peuvent définir les régions géographiques composées de continent, de pays ou d'Etats/provinces d'origine (Amérique du Nord), et définir une adresse ou ensemble d'adresses distincts pour chaque région.
Stratégie de pilotage ASN
Les stratégies du pilotage ASN vous permettent de piloter un trafic DNS en fonction des numéros de système autonomes (ASN). Les requêtes DNS provenant d'un numéro ASN ou d'un ensemble de numéros ASN spécifique peuvent être pilotées vers une adresse indiquée.
Stratégie de pilotage de préfixe IP
Les stratégies de pilotage de préfixe IP permettent aux clients de piloter le trafic DNS en fonction du préfixe IP de la requête d'origine.

Choisissez la politique qui correspond le mieux à vos besoins. Les options les plus appropriées pour un déploiement de cluster étendu sont la stratégie de pilotage de la géolocalisation et la stratégie de pilotage du préfixe IP. La stratégie de basculement convient aux services qui s'exécutent uniquement sur l'un des sites, tels que WebLogic Remote Console.

Quel que soit le type de stratégie, vous devez définir des vérifications de l'état OCI pour vérifier la disponibilité du site. Cela évite que le trafic n'atteigne un site où les serveurs sont arrêtés ou où l'application n'est pas disponible. Veillez à autoriser le trafic entrant à partir des points d'observation qui effectuent la vérification de l'état vers les ports d'équilibreur de charge OCI que vous vérifiez.

Le diagramme suivant présente l'équilibrage de charge global avec les stratégies de pilotage de la gestion du trafic OCI.

Description de l'image global-load-balancer-steering-policies.png

Description de l'illustration global-load-balancer-steering-policies.png

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

Lors de l'utilisation des stratégies de pilotage de la gestion du trafic OCI pour émuler un équilibreur de charge global :

Temps de réaction de basculement
Le temps de réponse à une panne de site dépend à la fois des intervalles de vérification de l'état (qui déterminent la vitesse à laquelle un site est marqué comme indisponible) et de la valeur de durée de vie de l'enregistrement DNS (TTL). Même après qu'un site est marqué comme indisponible et que le trafic est dirigé vers un autre emplacement, les clients ne recevront pas l'adresse IP mise à jour tant que la durée de vie DNS précédente n'aura pas expiré dans leur cache local. Pour minimiser les délais de basculement, il est recommandé de définir une valeur de durée de vie de stratégie faible.
Limite de persistance de session
Etant donné que l'équilibrage de charge avec ces stratégies repose sur les valeurs de réponse DNS, il n'existe aucun mécanisme intégré pour la persistance de session. Par conséquent, lorsque vous utilisez une stratégie d'équilibreur de charge simple ou aléatoire, la réponse DNS fournie aux clients peut changer à tout moment, ce qui peut avoir un impact sur les sessions d'application nécessitant une persistance. Si votre application requiert des sessions persistantes, assurez-vous que tous les emplacements client possibles sont explicitement définis dans des règles basées sur la géolocalisation et évitez d'utiliser des algorithmes de pilotage aléatoires ou d'équilibreur de charge.

Voici un exemple de configuration des stratégies de pilotage de la gestion du trafic OCI pour un système de cluster étendu Oracle Fusion Middleware (FMW) déployé dans les régions de Francfort et d'Amsterdam, avec trois frontaux : l'un pour Oracle SOA, l'autre pour OSB et l'autre pour WebLogic Remote Console. L'adresse IP de l'équilibreur de charge (LBR) à Francfort est 111.111.111.111 et l'adresse IP de l'équilibreur de charge à Amsterdam est 222.222.222.222. Dans cet exemple, les stratégies de pilotage définissent les règles suivantes :

Pour les systèmes frontaux SOA et OSB, les clients d'Allemagne, d'Europe, d'Asie et d'Amérique du Sud obtiennent de DNS l'adresse IP de l'équilibreur de charge de Francfort en tant que réponse principale.
Pour les systèmes frontaux SOA et OSB, les clients des Pays-Bas, d'Afrique, d'Océanie et d'Amérique du Nord obtiennent de DNS l'adresse IP de l'équilibreur de charge d'Amsterdam en tant que réponse principale.
Pour tous les autres clients (ce qui n'est pas attendu, puisque toutes les régions sont incluses dans les règles de géolocalisation), le DNS renvoie une réponse par défaut afin qu'ils soient redirigés vers Francfort.
Les vérifications de l'état OCI sont définies pour chaque front-end. Par conséquent, si la base principale est marquée comme indisponible, le trafic est dirigé vers l'autre enregistrement IP.
Le système frontal WebLogic Remote Console utilise un modèle de basculement. Le DNS renvoie l'adresse IP de l'équilibreur de charge de Francfort pour tous les clients. Lorsque la vérification de l'état échoue à Francfort, le DNS renvoie l'adresse IP de l'équilibreur de charge d'Amsterdam.

Les stratégies de pilotage de la gestion du trafic OCI sont les suivantes :

Stratégie de pilotage de la géolocalisation permettant d'accéder au système frontal SOA.

Elément de configuration	Exemples de valeurs
Nom de stratégie	strecthed_cluster_steering_policy-SOA
Modèle	Pilotage de géolocalisation
Durée de vie de la stratégie	60s
Réponse Pool1 (Frankfurt_Pool)	Nom : Frankfurt_LBR_IP Type : A RDATA : 111.111.111.111
Pool de réponses 2 (Amsterdam_Pool)	Nom : Amsterdam_LBR_IP Type : A RDATA : 222.222.222.222
Règle de pilotage de géolocalisation 1	Géolocalisation : Allemagne, Europe, Asie, Amérique du Sud Priorité du pool 1 : Frankfurt_Pool Priorité du pool 2 : Amsterdam_Pool
Règle de pilotage de géolocalisation 2	Géolocalisation : Pays-Bas, Afrique, Océanie, Amérique du Nord Priorité du pool 1 : Amsterdam_Pool Priorité du pool 2 : Frankfurt_Pool
Détection générique globale	Réponse Pool1 (Frankfurt_Pool)
Attacher une vérification d'état	Type de demande : HTTP Vérification de l'état : `SOA_IS_ALIVE` (HTTPS)
Domaines attachés	soafrontend.example.com

Stratégie de pilotage de géolocalisation permettant d'accéder au front-end OSB.

Elément de configuration	Exemples de valeurs
Nom de stratégie	strecthed_cluster_steering_policy-OSB
Modèle	Pilotage de géolocalisation
Durée de vie de la stratégie	60s
Pool de réponses 1(Frankfurt_Pool)	Nom : Frankfurt_LBR_IP Type : A RDATA : 111.111.111.111
Pool de réponses 2 (Amsterdam_Pool)	Nom : Amsterdam_LBR_IP Type : A RDATA : 222.222.222.222
Règle de pilotage de géolocalisation 1	Géolocalisation : Allemagne, Europe, Asie, Amérique du Sud Priorité du pool 1 : Frankfurt_Pool Priorité du pool 2 : Amsterdam_Pool
Règle de pilotage de géolocalisation 2	Géolocalisation : Pays-Bas, Afrique, Océanie, Amérique du Nord Priorité du pool 1 : Amsterdam_Pool Priorité du pool 2 : Frankfurt_Pool
Détection générique globale	Réponse Pool1 (Frankfurt_Pool)
Attacher une vérification d'état	Type de demande : HTTP Vérification de l'état : `OSB_IS_ALIVE` (HTTPS)
Domaines attachés	osbfrontend.example.com

Une stratégie de basculement est utilisée pour accéder à WebLogic Remote Console. En fonctionnement normal, le serveur d'administration s'exécute uniquement sur l'un des sites (dans ce cas, à Francfort). Seulement en cas d'échec du site, il est démarré sur l'autre site. Par conséquent, l'accès à la console distante WebLogic et à EM est contrôlé par une stratégie de basculement.

Elément de configuration	Exemples de valeurs
Nom de stratégie	strecthed_cluster_steering_policy-ADMINISTRATION
Modèle	Panne du serveur
Durée de vie de la stratégie	60s
Réponse Pool1 (Frankfurt_Pool)	Nom : Frankfurt_LBR_IP Type : A RDATA : 111.111.111.111
Pool de réponses 2 (Amsterdam_Pool)	Nom : Amsterdam_LBR_IP Type : A RDATA : 222.222.222.222
Priorité 1 du pool	Frankfurt_Pool
Priorité 2 du pool	Amsterdam_Pool
Attacher une vérification d'état	Type de demande : HTTP Vérification de l'état : `EM_IS_ALIVE` (HTTPS)
Domaines attachés	admin.example.com

Voici la configuration des vérifications de l'état OCI utilisées par chaque stratégie de pilotage DNS :

Vérification de l'état du front-end SOA. SOA fournit une page simple permettant de vérifier le statut SOA, dans le chemin /soa-infra/services/isSoaServerReady. Par conséquent, cette vérification de l'état effectue une demande HEAD avec HTTPS vers ce chemin pour vérifier si l'application SOA est disponible. L'en-tête host est nécessaire pour indiquer le nom du front-end à tester (dans cet exemple, soafrontend.example.com) lors de l'utilisation d'hôtes virtuels nommés sur les serveurs Web et les équilibreurs de charge.

Elément de configuration	Exemples de valeurs
Nom de la vérification d'état	SOA_IS_ALIVE
Cibles	111.111.111.111 (adresse IP LBR de Francfort) 222.222.222.222 (adresse IP LBR d'Amsterdam)
Points d'observation	Microsoft Azure Europe du Nord Google Est des Etats-Unis
Type	HTTP
Protocole	HTTPS
Port	443
Chemin	`/soa-infra/services/isSoaServerReady`
En-têtes	Hôte : soafrontend.example.com :443
Méthode	HEAD
d'agrégation	30 secondes
Délai d'expiration	10 secondes

Vérification de l'état du front-end OSB. OSB n'implémente pas d'URL d'état pour ses services. Certaines des URL normalement utilisées pour vérifier le statut d'OSB (par exemple, /sbinspection.wsil) nécessitent une authentification, et OCI Health Checks ne prend pas en charge l'en-tête authorization. Par conséquent, pour vérifier le statut d'OSB, déployez un service proxy REST personnalisé simple. Cette vérifications de l'état OCI effectue une demande HEAD vers une telle adresse via HTTPS. L'en-tête host est nécessaire pour indiquer le nom du front-end à tester (dans cet exemple, osbfrontend.example.com) lors de l'utilisation d'hôtes virtuels nommés sur les serveurs Web et les équilibreurs de charge.

Elément de configuration	Exemples de valeurs
Nom de la vérification d'état	OSB_IS_ALIVE
Cibles	111.111.111.111 (adresse IP LBR de Francfort) 222.222.222.222 (adresse IP LBR d'Amsterdam)
Points d'observation	Microsoft Azure Europe du Nord Google Est des Etats-Unis
Type	HTTP
Protocole	HTTPS
Port	443
Chemin	/`default/isOSBReadySample`
En-têtes	Hôte : osbfrontend.example.com :443
Méthode	HEAD
d'agrégation	30 secondes
Délai d'expiration	10 secondes

Vérification de l'état du système frontal WebLogic Remote Console EM_IS_ALIVE.

OCI Health Checks effectue une demande HEAD avec HTTPS vers le chemin /em/faces/targetauth/emasLogin afin de vérifier le statut de la console de FMW Control.

Elément de configuration	Exemples de valeurs
Nom de la vérification d'état	SOA_IS_ALIVE
Cibles	111.111.111.111 (adresse IP LBR de Francfort) 222.222.222.222 (adresse IP LBR d'Amsterdam)
Points d'observation	Microsoft Azure Europe du Nord Google Est des Etats-Unis
Type	HTTP
Protocole	HTTPS
Port	443
Chemin	`/em/faces/targetauth/emasLogin`
En-têtes	Hôte : admin.example.com :445
Méthode	HEAD
d'agrégation	30 secondes
Délai d'expiration	10 secondes

Utiliser un équilibreur de charge global tiers

Au lieu des stratégies de pilotage de la gestion du trafic Oracle Cloud Infrastructure (OCI), vous pouvez utiliser un équilibreur de charge global tiers.

Il est chargé d'effectuer le routage intelligent des demandes entre les équilibreurs de charge locaux.

Le GLBR est un équilibreur de charge configuré pour être accessible en tant qu'adresse par les utilisateurs de tous les sites et emplacements externes. Le périphérique fournit un serveur virtuel qui est mappé avec un nom de système de noms de domaine (DNS) accessible à tout client, quel que soit le site auquel il se connectera.

Le GLBR dirige le trafic vers l'un ou l'autre site en fonction de critères et de règles configurés. Ces critères peuvent être basés sur l'adresse IP du client, par exemple. Cela doit être utilisé pour créer un profil de persistance qui permet à GLBR de mapper les utilisateurs sur le même site lors des demandes initiales et ultérieures. Le GLBR gère un pool qui se compose des adresses de tous les équilibreurs de charge locaux. En cas d'échec de l'un des sites, les utilisateurs sont automatiquement redirigés vers le site actif survivant.

Sur chaque site, un équilibreur de charge local reçoit la demande de GLBR et dirige les demandes vers le serveur HTTP approprié. Pour éliminer les routages indésirables, le GLBR est également configuré avec des règles spécifiques qui acheminent les rappels uniquement vers le LBR qui est local aux serveurs qui les ont générés. Par exemple, cela est utile pour les consommateurs internes des services Oracle SOA. Ces règles GLBR peuvent être résumées comme suit :

Si les demandes proviennent de site1 (par exemple, les demandes proviennent des serveurs WebLogic du site 1), le GLBR achemine vers le LBR dans site1.
Si les demandes proviennent de site2 (par exemple, les demandes proviennent des serveurs WebLogic du site 2), GLBR achemine vers le LBR dans site2.
Si les demandes proviennent d'une autre adresse (appels client), la charge GLBR équilibre les connexions aux deux LBR.
Des règles de routage supplémentaires peuvent être définies dans le GLBR pour router des clients spécifiques vers des sites spécifiques (par exemple, les deux sites peuvent fournir des temps de réponse différents en fonction des ressources matérielles dans chaque cas).

Configurer d'autres ressources

Les deux régions peuvent utiliser des ressources externes, telles que LDAP, les banques d'identités, les banques de stratégies, les destinations JMS (Java Message Service) externes, les services Web externes, Oracle Cloud Infrastructure Object Storage, etc.

Les détails de configuration de ces ressources externes ne sont pas inclus dans ce document. Toutefois, il est nécessaire que ces ressources soient cohérentes dans les deux régions pour fournir un comportement uniforme.

Par exemple, dans Oracle SOA, les callbacks asynchrones peuvent réhydrater les instances qui ont été lancées dans une autre région. De même, dans le cas d'une récupération automatique, tout Oracle WebLogic Server peut prendre le rôle de maître de cluster et effectuer des opérations de récupération dans l'une ou l'autre région. Pour que ces processus fonctionnent de manière transparente et offrent un comportement cohérent, les mêmes ressources externes doivent être accessibles à partir des deux régions.