Configurer des grappes étirées FMW

Configurer les régions

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

Dans Oracle Cloud Infrastructure (OCI), vous pouvez la mettre en oeuvre dans toutes les régions OCI qui ont une faible latence entre elles. La latence inter-région maximale prise en charge est de 10 ms de temps aller-retour (RTT). Vous pouvez vérifier la latence entre les régions de la console OCI en sélectionnant Réseau, Centre de contrôle de réseau, puis L 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 un RTT de 6 à 7 ms. Toutefois, vous ne pouvez pas déployer ce modèle entre des emplacements tels que 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 n'offre pas d'outil de mesure de bande passante OCI spécifique. Pour des mesures précises de la bande passante, utilisez des outils tels que iPerf. La bande passante testée entre Francfort et Amsterdam est d'environ 2 à 2,5 gigabits par seconde (Gbit/s).

Vous pouvez également mettre en oeuvre ce modèle entre des domaines de disponibilité qui se trouvent dans la même région. Le déploiement des serveurs Oracle WebLogic Server dans les domaines de disponibilité est, en fait, le comportement standard des services de plate-forme-service (PaaS) tels que les piles Oracle SOA Suite on Marketplace et Oracle WebLogic Server pour OCI. Toutefois, la mise en oeuvre de ce modèle dans les domaines de disponibilité au lieu de dans toutes les régions n'est pas vraiment une solution de protection en cas de sinistre, car elle ne protège pas contre les événements ayant une incidence sur 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 dans chaque site, vous pouvez utiliser le cadre WLS-HYDR (voir la procédure "Créer une infrastructure").

Configurer le réseau

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

Les fonctions de 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 distante entre les réseaux en nuage virtuels, avec passerelles de routage dynamique (DRG).
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 une route vers le bloc CIDR du VCN de la région 2 au moyen de la passerelle de routage dynamique. De même, les tables de routage de la région 2 doivent inclure une route vers le CIDR du VCN de la région 1 au moyen de la passerelle de routage dynamique.
Règles de sécurité de réseau permettant la communication suivante pour le cluster étendu :
- Ouvrez le serveur WebLogic et les ports 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 de Coherence.
- Autoriser le trafic vers le module d'écoute de base de données et les ports ONS d'Oracle Cloud Infrastructure Notifications dans les deux régions à partir des sous-réseaux de niveau intermédiaire des régions 1 et 2.
- Par défaut, aucune communication inter-région n'est nécessaire entre les serveurs OHS et WebLogic. Les ports du serveur WebLogic du sous-réseau de niveau intermédiaire (middle tier) ne doivent être accessibles qu'à partir des serveurs OHS de la même région. Toutefois, une communication inter-région peut être nécessaire dans des circonstances exceptionnelles, par exemple si tous les serveurs Web d'une région échouent. Vous trouverez plus de détails dans la section Managing Failures.
Tous les noms d'hôte utilisés par le système (adresses d'écoute WebLogic, adresses SCAN et VIP 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 frontal du système (par exemple, frontend.example.com) doit pointer vers l'adresse IP de l'équilibreur de charge local. Pour ce faire, ajoutez le nom frontal à une vue DNS privée dans chaque région ou au fichier /etc/hosts des hôtes de niveau intermédiaire (middle tier). Cela garantit que tous les rappels d'un serveur WebLogic vers le serveur frontal 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 clé. La configuration d'une protection inter-région ou d'un domaine de disponibilité n'est efficace que s'il existe déjà une protection fiable contre les défaillances locales au sein d'une même région. Si la haute disponibilité locale, telle que celle fournie par RAC, n'est pas mise en oeuvre, l'ajout d'une protection sur plusieurs domaines de disponibilité ou régions ne résout pas le risque de défaillance dans l'environnement local.

Pour garder l'application connectée et recevoir des avis du service d'avis Oracle en cas d'échec d'un noeud de base de données RAC ou d'une instance, assurez-vous que votre application se connecte à la base de données enfichable à 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 la base de secours. Exemples de commandes pour créer un service de connexion à la base de données enfichable :


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é

Le service de stockage de fichiers d'Oracle Cloud Infrastructure est un service de système de fichiers entièrement géré, évolutif et sécurisé fourni par OCI. Il est conçu pour offrir un stockage de fichiers haute performance pour les applications d'entreprise qui nécessitent des systèmes de fichiers partagés et persistants.

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

Le modèle de grappe étendu Oracle Fusion Middleware (FMW) dans OCI utilise les systèmes de stockage de fichiers OCI 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). Le service Stockage de fichiers pour OCI offre une haute disponibilité dans la région : il utilise en interne un stockage redondant dans plusieurs domaines d'erreur au sein d'un domaine de disponibilité. Toutefois, le service Stockage de fichiers OCI n'est pas accessible entre les régions. Par conséquent, le stockage partagé est local pour 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 entre 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 le même que lors de la création d'un seul domaine WebLogic. Pour implémenter les fonctionnalités de haute disponibilité (telles que la migration de service 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 d'entreprise FMW référencés dans la section Explorer davantage.

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

Note :

Le modèle de grappe étendu Oracle Fusion Middleware (FMW) peut s'appliquer aux domaines créés à l'aide de services de plate-forme-service (PaaS), tels que les piles Oracle WebLogic Server pour OCI et Oracle SOA Suite on Marketplace. Les fonctions de provisionnement et de redimensionnement de ces services PaaS ne prennent en charge qu'une seule région par défaut. Vous devez donc redimensionner manuellement la grappe pour ajouter des noeuds dans une autre région. Reportez-vous aux procédures de redimensionnement 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 ne mettent pas en oeuvre certaines meilleures pratiques de haute disponibilité, telles que le basculement du serveur d'administration. Par conséquent, certaines des recommandations du présent document peuvent ne pas s'appliquer à ces environnements.

Voici les aspects les plus pertinents à mettre en oeuvre dans la configuration WebLogic lors de l'utilisation du modèle de grappe étendu FMW :

Utiliser des espaces de stockage persistants de base de données
Oracle prend en charge les grappes extensibles qui utilisent des espaces de stockage persistants de base de données pour les journaux de transactions et JMS d'Oracle WebLogic Server. Le stockage des journaux de transactions et des données persistantes dans la base de données tire parti des fonctions intégrées de réplication et de haute disponibilité de la base de données, telles que 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 entre les sites 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 encore besoin pour le basculement du serveur d'administration, les plans de déploiement et certains adaptateurs tels que l'adaptateur de fichiers).

L'utilisation de TLOG et de JMS dans la base de données a toutefois une incidence sur les performances du système. Cette pénalité est augmentée lorsque l'un des niveaux intermédiaires doit communiquer en commun avec la base de données de l'autre site. Du point de vue des performances, un stockage partagé local pour 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 de l'application.
Artefacts de système de fichiers partagés locaux pour chaque région
Comme indiqué dans les guides de déploiement d'Oracle Fusion Middleware Enterprise, le répertoire de domaine du serveur d'administration (ASERVER_HOME) doit résider dans un stockage partagé, séparé du dossier de domaine du serveur géré (MSERVER_HOME). Cette opération, associée à l'utilisation d'un nom d'hôte virtuel pour l'adresse d'écoute du serveur d'administration, permet au serveur d'administration de basculer vers un autre hôte, dans la même région ou dans une autre.

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

Dans une topologie de cluster étendue FMW, chaque région utilise son propre stockage partagé local. Par conséquent, la deuxième région conserve ses propres binaires redondants (garantissant la haute disponibilité d'au moins deux installations binaires par site) 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 assurer la cohérence et un basculement en toute transparence.
Utiliser un algorithme basé sur l'affinité pour la grappe WebLogic
Pour réduire le trafic inter-site, utilisez l'affinité locale pour la résolution d'usine de contextes JNDI (Java Naming and Directory Interface). Pour régler l'algorithme de chargement par défaut de la grappe WebLogic à un algorithme basé sur l'affinité :
1. Allez à Modifier l'arbre dans la console distante WebLogic.
2. Allez à Environnement, sélectionnez Grappes et sélectionnez la grappe.
3. Dans l'onglet Général, réglez l'algorithme de chargement par défaut de la grappe WebLogic à affinité de tourniquet (la valeur par défaut est round-robin) ou à tout algorithme "basé sur l'affinité".
Il n'est pas nécessaire de définir l'adresse de la grappe avec la liste explicite de tous les serveurs de la grappe. Lorsqu'elle est vide, la valeur d'adresse de grappe est générée automatiquement. Assurez-vous simplement que la propriété Number of Servers In Cluster Address (Nombre de serveurs dans l'adresse de grappe), qui limite le nombre de serveurs à répertorier lors de la génération automatique de l'adresse de grappe, a une valeur suffisamment élevée pour inclure tous les serveurs de la grappe.
Utiliser la configuration de la migration automatique de service
Oracle recommande de configurer la migration automatique de services avec les magasins 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 depuis les deux sites. Lors de l'utilisation 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 pour 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. Reportez-vous à la section "Review Performance Data" pour plus de détails sur les comportements attendus.
Nom d'hôte et résolution frontaux
Lors de la configuration de l'hôte frontal pour votre grappe 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 de l'équilibreur de charge OCI dans la région 1 et la région 2. Voir "À 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 pour 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 en les ajoutant à 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 l'acheminement et la performance.

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 magasins 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 en cas de panne. Ils doivent se reconnecter automatiquement en cas de défaillance 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 les sources de données GridLink
Les sources de données GridLink exploitent le service d'avis Oracle (ONS) pour détecter rapidement les défaillances de noeud de base de données ou les interruptions de réseau et y réagir, améliorant ainsi la disponibilité et la résilience des applications. Ils répartissent automatiquement les connexions à la base de données en fonction des informations de charge de travail en temps réel, optimisant ainsi les performances et l'utilisation des ressources sur tous les noeuds RAC. Les modifications apportées à la topologie de la base de données (par exemple, l'ajout ou la suppression de noeuds RAC) sont automatiquement reconnues et traitées, ce qui réduit les frais d'administration et les temps d'arrêt.

Vous n'avez pas besoin de spécifier manuellement l'hôte et le port ONS dans la configuration de la 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 dans le fichier tnsnames.ora, qui inclut à la fois les adresses SCAN principale et de secours. Le format de chaîne de connexion recommandé est le suivant, avec 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 de détails sur la configuration de l'alias TNS dans les sources de données et les fichiers de configuration FMW, voir Utilisation de l'alias TNS dans les chaînes de connexion dans le Guide de déploiement d'entreprise pour Oracle SOA Suite.
Utilisez l'option Tester les connexions lors de la réservation
Assurez-vous que l'option Tester les connexions lors de la réservation est activée pour toutes les sources de données. Cela est particulièrement important pour les sources de données utilisées pour accéder aux magasins persistants, car les magasins persistants sont essentiels dans l'état général des serveurs WebLogic. Cet indicateur permet au serveur WebLogic de tester une connexion avant de l'attribuer à l'application.

Pour Nom de la 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 nécessiter l'accès à 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 groupes 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 réserve de connexions. Toutefois, pour réduire le temps de réponse du système pendant l'exécution normale, il peut être avantageux d'augmenter la capacité initiale du pool.
Étant donné que la capacité initiale est configurée au niveau de la source de données (groupe de connexions), ces paramètres influencent le temps de démarrage de tous les serveurs du cluster (ceux qui sont locaux à la base de données et ceux qui sont distants). Dans un cluster étendu FMW, les serveurs qui résident à distance de la base de données affichent une latence accrue au démarrage, car une capacité de pool initiale plus élevée est utilisée (voir "Review Start Times"). 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 actives à une source de données 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 "Review Stress Tests"). Surveillez l'utilisation dans votre application et considérez 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 avoir au moins deux serveurs pour assurer 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 d'Oracle WebLogic Server. Configurez plutôt une liste statique des serveurs, en réglant le paramètre DynamicServerList à OFF. Cela met en garde contre une détection de défaillance 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, cela améliore les performances du système.

Les extraits suivants des fichiers mod_wl_ohs.conf d'Oracle HTTP Server fournissent un exemple de 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 avoir son propre équilibreur de charge pour répartir les demandes entre les serveurs de ce site.

Configurez le module d'écoute dans les deux régions avec le même certificat SSL dans chaque équilibreur de charge. Configurez les serveurs dorsaux de sorte que l'équilibreur de charge de la région 1 inclut les instances Oracle HTTP Server (OHS) de la région 1 (si le système n'utilise pas de serveurs Web, les serveurs sauvegardés sont WebLogic) les serveurs de la région 1) et l'équilibreur de charge de la région 2 comprend les serveurs OHS de la région 2 (si le système n'utilise pas de serveurs Web, les serveurs dorsaux sont les serveurs WebLogic de la région 2).

Configurer les vérifications d'état pour déterminer la disponibilité des serveurs dorsaux, à l'aide d'une URL qui reflète fidèlement 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 d'état gourmandes en ressources, car des vérifications fréquentes pourraient surcharger les serveurs sauvegardés. Par exemple, pour Oracle SOA, l'URL recommandée pour la vérification de l'état est /soa-infra/services/isSoaServerReady .

À propos de l'équilibrage de charge global

Le modèle de grappe étendu à Oracle Fusion Middleware (FMW) nécessite un élément au-dessus de l'équilibreur de charge de chaque centre de données pour équilibrer les demandes du client entre les deux régions.

Dans les mises en oeuvre sur place, celle-ci est traditionnellement mise en oeuvre avec un équilibreur de charge global, 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é dans 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é. Vous pouvez toutefois bénéficier d'une fonctionnalité globale d'équilibrage de charge à l'aide de politiques de gestion du trafic.

Utiliser les politiques de pilotage pour la gestion du trafic OCI en tant qu'équilibreur de charge global

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

Les politiques de pilotage pour la gestion du trafic fournissent des réponses intelligentes aux interrogations de système de noms de domaine (DNS), ce qui signifie que différentes réponses peuvent être fournies pour l'interrogation en fonction de la logique définie dans la politique. Il existe différents types de politique :

Politique d'équilibreur de charge
Les politiques d'équilibreur de charge répartissent le trafic entre de nombreux points d'extrémité. Il est possible d'affecter des pondérations égales aux points d'extrémité afin de répartir le trafic de manière égale ou d'affecter des pondérations personnalisées pour l'équilibrage de la charge par ratio. Les moniteurs et les sondes sur demande d'Oracle Cloud Infrastructure Health Checks sont utilisées pour évaluer l'état du point d'extrémité. Si un point d'extrémité n'est pas sain, le trafic DNS est automatiquement réparti entre les autres points d'extrémité.
Politique de basculement
Les politiques de basculement vous permettent de prioriser l'ordre dans lequel vous voulez que les réponses soient traitées dans une politique (par exemple, principale et secondaire). Les moniteurs et les sondes sur demande du service Vérifications d'état pour OCI sont utilisées pour évaluer l'état des réponses dans la politique. Si la réponse principale n'est pas saine, le trafic DNS est automatiquement associé à la réponse secondaire.
Politique de pilotage par géolocalisation
Les politiques de pilotage par géolocalisation répartissent le trafic DNS vers différents points d'extrémité en fonction de l'emplacement de l'utilisateur final. Les clients peuvent définir des régions géographiques constituées du continent, des pays ou des États/provinces d'origine (Amérique du Nord) et définir un point d'extrémité ou un jeu de points d'extrémité distinct pour chaque région.
Politique de pilotage par ASN
Les politiques de pilotage par ASN vous permettent de piloter le trafic DNS en fonction des numéros de système autonome. Les interrogations DNS provenant d'un ASN ou d'un jeu d'ASN particulier peuvent être dirigées vers un point d'extrémité spécifique.
Politique de pilotage par préfixe IP
Les politiques de pilotage par préfixe IP permettent aux clients de piloter le trafic DNS en fonction du préfixe IP de l'interrogation d'origine.

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

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

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

Description de 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 politiques de pilotage pour la gestion du trafic OCI pour émuler un équilibreur de charge global :

Temps de réaction de basculement
Le temps de réponse à une défaillance du 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 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 avant l'expiration de la durée de vie DNS précédente dans leur cache local. Pour minimiser les retards de basculement, il est recommandé de définir une valeur de durée de vie de politique faible.
Limitation de persistance de session
Comme l'équilibrage de la charge avec ces politiques repose sur des valeurs de réponse DNS, il n'existe aucun mécanisme intégré pour la persistance de session. Par conséquent, lors de l'utilisation d'une politique d'équilibreur de charge aléatoire ou simple, la réponse DNS fournie aux clients peut changer à tout moment, ce qui peut avoir une incidence sur les sessions d'application qui nécessitent une persistance. Si votre application nécessite des sessions persistantes, assurez-vous que tous les emplacements possibles des clients sont explicitement définis dans les 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 politiques de pilotage pour la gestion du trafic OCI pour un système de grappes étendu Oracle Fusion Middleware (FMW) déployé dans les régions de Francfort et d'Amsterdam, avec trois éléments frontaux : un pour Oracle SOA, un pour OSB et un autre pour la console distante WebLogic. L'adresse IP de l'équilibreur de charge (LBR) à Francfort est 111.111.111.111 et celle de l'équilibreur de charge à Amsterdam est 222.222.222.222. Dans cet exemple, les politiques de pilotage définissent les règles suivantes :

Pour les éléments frontaux SOA et OSB, les clients d'Allemagne, d'Europe, d'Asie et d'Amérique du Sud recevront de DNS l'adresse IP de l'équilibreur de charge de Francfort en tant que réponse principale.
Pour les éléments frontaux SOA et OSB, les clients des Pays-Bas, d'Afrique, d'Océanie et d'Amérique du Nord recevront de DNS l'adresse IP de l'équilibreur de charge d'Amsterdam comme réponse principale.
Pour tous les autres clients (qui ne sont pas attendus, puisque toutes les régions sont incluses dans les règles de géolocalisation), le DNS retournera une réponse par défaut afin qu'ils soient redirigés vers Francfort.
Les vérifications d'état d'OCI sont définies pour chaque élément frontal. Par conséquent, si l'élément principal est marqué comme non disponible, le trafic est dirigé vers l'enregistrement d'adresse IP de remplacement.
L'élément frontal de la console distante WebLogic utilise un modèle de basculement. Le DNS retourne 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 retourne l'adresse IP de l'équilibreur de charge d'Amsterdam.

Voici les politiques de pilotage pour la gestion du trafic OCI définies :

Politique de pilotage par géolocalisation permettant d'accéder à l'élément frontal SOA.

Article configurable	Exemples de valeurs
Nom de politique	strecthed_cluster_steering_policy-SOA
Modèle	Pilotage par géolocalisation
Durée de vie de la politique	60s
Réponse Pool1 (Frankfurt_Pool)	Nom : Frankfurt_LBR_IP Type : A RDATA : 111.111.111.111
Groupe de réponses 2 (Amsterdam_Pool)	Nom : Amsterdam_LBR_IP Type : A RDATA : 222.222.222.222
Règle de pilotage par géolocalisation 1	Géolocalisation : Allemagne, Europe, Asie, Amérique du Sud Priorité du groupe 1 : Frankfurt_Pool Priorité du groupe 2 : Amsterdam_Pool
Règle de pilotage par géolocalisation 2	Géolocalisation : Pays-Bas, Afrique, Océanie, Amérique du Nord Priorité du groupe 1 : Amsterdam_Pool Priorité du groupe 2 : Frankfurt_Pool
Priorité attrape-tout	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

Politique de pilotage par géolocalisation permettant d'accéder à l'élément frontal OSB.

Article configurable	Exemples de valeurs
Nom de politique	strecthed_cluster_steering_policy-OSB
Modèle	Pilotage par géolocalisation
Durée de vie de la politique	60s
Groupe de réponses 1(Frankfurt_Pool)	Nom : Frankfurt_LBR_IP Type : A RDATA : 111.111.111.111
Groupe de réponses 2 (Amsterdam_Pool)	Nom : Amsterdam_LBR_IP Type : A RDATA : 222.222.222.222
Règle de pilotage par géolocalisation 1	Géolocalisation : Allemagne, Europe, Asie, Amérique du Sud Priorité du groupe 1 : Frankfurt_Pool Priorité du groupe 2 : Amsterdam_Pool
Règle de pilotage par géolocalisation 2	Géolocalisation : Pays-Bas, Afrique, Océanie, Amérique du Nord Priorité du groupe 1 : Amsterdam_Pool Priorité du groupe 2 : Frankfurt_Pool
Priorité attrape-tout	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 politique de basculement est utilisée pour accéder à la console distante WebLogic. Pendant le fonctionnement normal, le serveur d'administration ne s'exécute que sur l'un des sites (Francfort dans ce cas). Ce n'est qu'en cas de panne du site qu'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 politique de basculement.

Article configurable	Exemples de valeurs
Nom de politique	strecthed_cluster_steering_policy-ADMIN
Modèle	Basculer
Durée de vie de la politique	60s
Réponse Pool1 (Frankfurt_Pool)	Nom : Frankfurt_LBR_IP Type : A RDATA : 111.111.111.111
Groupe de réponses 2 (Amsterdam_Pool)	Nom : Amsterdam_LBR_IP Type : A RDATA : 222.222.222.222
Priorité du groupe 1	Frankfurt_Pool
Priorité du groupe 2	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 d'état OCI utilisées par chaque politique de pilotage DNS :

Vérification de l'état de l'élément frontal SOA. SOA fournit une page simple pour 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 spécifier le nom d'extrémité frontale à 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.

Article configurable	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 États-Unis
Type	HTTP
Protocole	HTTPS
Port	443
Chemin d'accès	`/soa-infra/services/isSoaServerReady`
En-têtes	Hôte : soafrontend.example.com :443
Méthode	Tête
Intervalle	30 secondes
Temporisation	10 secondes

Vérification de l'état de l'élément frontal OSB. OSB ne met pas en oeuvre d'URL d'état pour ses services. Certaines des URL normalement utilisées pour vérifier le statut d'OSB (telles que /sbinspection.wsil) nécessitent une authentification et les vérifications d'état OCI ne prennent pas en charge l'en-tête authorization. Par conséquent, pour vérifier le statut d'OSB, déployez un service mandataire REST personnalisé simple. Cette vérifications d'état OCI effectue une demande HEAD à un tel point d'extrémité sur HTTPS. L'en-tête host est nécessaire pour spécifier le nom d'extrémité frontale à 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.

Article configurable	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 États-Unis
Type	HTTP
Protocole	HTTPS
Port	443
Chemin d'accès	/`default/isOSBReadySample`
En-têtes	Hôte : osbfrontend.example.com :443
Méthode	Tête
Intervalle	30 secondes
Temporisation	10 secondes

Vérification de l'état de la console frontale WebLogic Remote Console EM_IS_ALIVE.

Le service Vérifications d'état pour OCI effectue une demande HEAD avec HTTPS vers le chemin /em/faces/targetauth/emasLogin pour vérifier le statut de la console de contrôle FMW.

Article configurable	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 États-Unis
Type	HTTP
Protocole	HTTPS
Port	443
Chemin d'accès	`/em/faces/targetauth/emasLogin`
En-têtes	Hôte : admin.example.com :445
Méthode	Tête
Intervalle	30 secondes
Temporisation	10 secondes

Utiliser un équilibreur de charge global de tierce partie

Comme alternative aux politiques de pilotage pour la gestion du trafic Oracle Cloud Infrastructure (OCI), vous pouvez utiliser un équilibreur de charge global de tierce partie (GLBR).

Il sera responsable de l'exécution du 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. L'appareil fournit un serveur virtuel qui est mappé à 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 des sites 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 au GLBR de mapper les utilisateurs au même site lors des demandes initiales et suivantes. Le GLBR gère un pool qui se compose des adresses de tous les équilibreurs de charge locaux. En cas de défaillance de l'un des sites, les utilisateurs sont automatiquement redirigés vers le site actif survivant.

Dans chaque site, un équilibreur de charge local reçoit la demande du 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 pour les 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 est acheminé vers le LBR dans site1.
Si les demandes proviennent de site2 (par exemple, les demandes proviennent des serveurs WebLogic du site 2), le GLBR est acheminé vers le LBR dans site2.
Si les demandes proviennent d'une autre adresse (appels clients), le GLBR équilibre la charge des connexions aux deux LBR.
Des règles d'acheminement supplémentaires peuvent être définies dans le GLBR pour acheminer 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 magasins d'identités, les magasins de politiques, les destinations JMS (Java Message Service), les services Web externes, Oracle Cloud Infrastructure Object Storage, etc.

Les détails de configuration de ces ressources externes ne sont pas inclus dans le champ d'application de ce document. Il est toutefois nécessaire que ces ressources soient cohérentes dans les deux régions pour assurer un comportement uniforme.

Par exemple, dans Oracle SOA, les rappels asynchrones peuvent réhydrater les instances lancées dans une autre région. De même, dans le cas d'une récupération automatique, tout Oracle WebLogic Server peut assumer le rôle de maître de grappe 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.