Introduction
La configuration de ce guide utilise un domaine Oracle WebLogic Server unique dans lequel les serveurs de deux sites participent au même cluster (connu sous le nom de cluster étendu) et s'appuient sur Data Guard pour assurer la protection de la base de données.
Dans OCI, des fonctionnalités telles que la gestion du trafic, les vérifications de l'état, les équilibreurs de charge, les vues privées DNS et les passerelles de routage dynamique offrent des fonctionnalités améliorées pour prendre en charge cette configuration. Pour les environnements sur site, des composants d'infrastructure et de réseau équivalents doivent être utilisés pour répondre à ces exigences.
La latence du réseau entre les sites ou les régions doit être suffisamment faible pour minimiser la pénalité de performances introduite par le retard des appels et pour éviter les incohérences lors du déploiement et de l'exécution. Oracle prend en charge cette topologie uniquement lorsque la latence entre les serveurs WebLogic et la base de données est inférieure à 10 ms pour les allers-retours.
Pour optimiser les performances et les comportements de basculement, Oracle recommande d'analyser chaque application exécutée dans un cluster étendu WebLogic et d'ajuster les différents paramètres abordés dans ce guide (délais d'attente, configuration de réplication de session, location de migration de service, API Java Transaction (JTA), etc.) en conséquence.
En savoir plus sur les clusters étendus Oracle Fusion Middleware
Fournir l'architecture de disponibilité maximale (MAA) d'Oracle est l'une des principales exigences pour tout déploiement d'entreprise Oracle Fusion Middleware.
Oracle Fusion Middleware inclut un vaste ensemble de fonctionnalités de haute disponibilité, telles que la détection et le redémarrage des décès de processus, la mise en cluster des serveurs, la migration des services, GridLink, l'équilibrage de charge, le basculement, la sauvegarde et la récupération, les mises à niveau non simultanées et les modifications de configuration non simultanées, qui protègent un déploiement d'entreprise contre les temps d'arrêt imprévus et réduisent les temps d'arrêt planifiés. Ces fonctionnalités fournissent une solution de haute disponibilité locale au sein d'un seul centre de données.
En outre, les applications ont besoin d'une protection contre les catastrophes imprévues, les catastrophes naturelles et les temps d'arrêt qui peuvent affecter l'ensemble d'un centre de données. La plupart des systèmes traditionnels de protection contre les catastrophes utilisent le modèle actif-passif qui implique la configuration d'un site de secours à un emplacement géographiquement différent de celui du site de production. Ce modèle est généralement adopté lorsque la latence entre les sites est élevée et ne permet pas le clustering entre les deux sites. Cette approche offre une protection complète de l'architecture de disponibilité maximale (MAA). Toutefois, cela entraîne des coûts d'exploitation et d'administration supplémentaires, car le système middleware de secours met en miroir le système principal et nécessite une réplication continue. Ce modèle est décrit dans le Guide de récupération après sinistre Oracle Fusion Middleware.
Ce guide décrit un autre modèle : le modèle actif-actif basé sur des clusters étendus Oracle Fusion Middleware, qui peut être utilisé pour protéger un système Oracle Fusion Middleware contre les temps d'arrêt sur plusieurs sites. Ce modèle utilise une configuration active-active pour le niveau intermédiaire, tandis que le niveau de base de données utilise une configuration active-passive avec Data Guard. Il est conçu pour optimiser la capacité et répartir les charges de travail entre les sites. Il utilise les ressources plus efficacement que le modèle actif-passif en utilisant toutes les ressources disponibles plutôt que de laisser les machines de secours inactives. Ce modèle est appelé déploiement de clusters étendus FMW.
En particulier, ce guide explique comment implémenter ce modèle dans les régions Oracle Cloud Infrastructure (OCI). Il fournit les étapes de configuration pour configurer la topologie recommandée et des conseils sur les implications de cette configuration en matière de performances et de basculement.
Les résultats et les exemples de ce guide sont basés sur un système Oracle SOA Suite 14.1.2 qui suit l'architecture Enterprise Deployment Guide. Il s'agit d'un exemple significatif car il inclut de nombreuses fonctionnalités telles que les composants Jakarta standard, la réplication de session HTTP, la persistance des métadonnées de base de données, un cluster Coherence et les espaces de stockage persistants JMS (Java Message Service) et JTA (Java Transaction API), entre autres considérations pertinentes pour les clusters étendus. Par conséquent, la topologie et les recommandations décrites peuvent également être appliquées à d'autres environnements Oracle Fusion Middleware.
Terminologie
-
Niveau intermédiaire (également niveau intermédiaire ou middleware)
Le niveau intermédiaire fait référence à la couche au sein d'une architecture d'application à plusieurs niveaux qui se situe entre l'interface utilisateur (front-end) et le stockage de données (back-end). Il gère la logique métier, le traitement des données et la sécurité, et sert de pont entre l'utilisateur et la base de données.
-
Oracle Fusion Middleware
Oracle Fusion Middleware est une gamme complète de produits middleware d'entreprise d'Oracle qui permet aux entreprises de créer, de déployer et de gérer des applications de manière efficace et sécurisée. Il inclut des solutions pour les serveurs d'applications, l'intégration, la gestion des processus métier, la business intelligence, la sécurité, la gestion des identités, les serveurs Web, etc.
-
Catastrophe
Un événement catastrophique soudain et imprévu qui cause des dommages ou des pertes inacceptables dans un site ou une zone géographique. Un sinistre est un événement qui compromet la capacité d'une organisation à fournir des fonctions, des processus ou des services essentiels pendant une période inacceptable et qui amène l'organisation à appeler ses plans de récupération.
-
Récupération après sinistre
Possibilité d'assurer une protection contre les arrêts naturels ou non planifiés au niveau d'un site d'une production, en mettant en oeuvre un programme de récupération des applications et des données vers un site d'une secours géographiquement distinct.
-
Architecture de disponibilité maximale d'Oracle
L'architecture de disponibilité maximale d'Oracle (Oracle MAA) est le modèle de bonnes pratiques pour la protection et la disponibilité des données des produits Oracle (Oracle Database, Oracle Fusion Middleware, Applications). La mise en œuvre des meilleures pratiques Oracle MAA est l'une des principales exigences de tout déploiement Oracle. Il fournit des recommandations pour la configuration et la gestion d'un système Oracle. Oracle MAA inclut les recommandations du Guide de déploiement Oracle Fusion Middleware Enterprise et ajoute les meilleures pratiques de protection contre les sinistres afin de minimiser les temps d'arrêt planifiés et non planifiés pour les pannes affectant l'ensemble d'un centre de données ou d'une région. Reportez-vous à la section En savoir plus pour obtenir des liens vers la documentation connexe et d'autres ressources.
-
Site (ou centre de données)
Un site est l'ensemble des différents composants d'un centre de données nécessaires à l'exécution d'un groupe d'applications. Par exemple, un site peut être composé d'instances Oracle Fusion Middleware, de bases de données, de stockage, etc.
-
Système
Un système est un ensemble de cibles (hôtes, bases de données, serveurs d'applications, etc.) qui fonctionnent ensemble pour héberger vos applications. Par exemple, pour surveiller une application dans Oracle Enterprise Manager, vous devez d'abord créer un système composé des cibles de base de données, de processus d'écoute, de serveur d'applications et d'hôtes sur lesquelles l'application s'exécute.
-
Cluster étendu
Un cluster étendu fait référence à une architecture de cluster dans laquelle les noeuds d'un cluster logique unique sont répartis dans des centres de données ou des emplacements géographiquement distincts.
-
Permutation
La permutation est le processus qui consiste à inverser les rôles du site de production et du site de secours. Les permutations sont des opérations planifiées effectuées pour une validation périodique ou pour effectuer une maintenance planifiée sur le site de production actuel. Lors d'une permutation, le site de secours actuel devient le nouveau site de production et le site de production actuel devient le nouveau site de secours. Ce manuel utilise également le terme permutation pour faire référence à une permutation de site.
-
Retour en arrière
La permutation est le processus qui consiste à rétablir les rôles d'origine du site de production actuel et du site de secours actuel. Les permutations sont des opérations planifiées effectuées une fois l'opération de permutation terminée. Une permutation rétablit les rôles d'origine de chaque site : le site de secours actuel devient le site de production et le site de production actuel devient le site de secours. Ce playbook utilise également le terme switchback pour faire référence à un switchback de site.
-
Basculement en cas d'incident
Le basculement est le processus qui consiste à faire du site de secours actuel le nouveau site de production une fois que le site de production est indisponible de manière inattendue en raison, par exemple, d'un sinistre sur le site de production. Ce manuel utilise également le terme de basculement pour faire référence à un basculement de site.
-
Objectif du point de récupération
L'objectif de point de récupération est la quantité de perte de données qu'un système peut tolérer du point de vue de l'entreprise, telle que la quantité de perte de données acceptable lorsqu'une panne survient.
-
Objectif de temps de récupération
L'objectif de temps de récupération est la durée d'inactivité qu'un système peut tolérer ou la durée acceptable pendant laquelle une application ou un service peut rester indisponible en cas de panne, d'un point de vue commercial.
- Oracle Cloud Infrastructure
Oracle Cloud Infrastructure (OCI) est un ensemble de services cloud complémentaires qui vous permettent d'élaborer et d'exécuter un éventail d'applications et de services dans un environnement hébergé hautement disponible. OCI fournit des fonctionnalités de calcul hautes performances (comme des instances matérielles physiques) et de capacité de stockage sur un réseau virtuel superposé flexible accessible de manière sécurisée à partir de votre réseau sur site.
-
Région OCI
Une région OCI est une zone géographique précise qui contient des centres de données, hébergeant des domaines de disponibilité. Les régions sont indépendantes les une des autres et peuvent les séparer d'un pays ou d'un continent à l'autre par de grandes distances.
Une région est un site en termes de récupération après sinistre.
- Domaine de disponibilité
Les domaines de disponibilité sont des centres de données autonomes indépendants au sein d'une région. Les ressources physiques de chaque domaine de disponibilité sont isolées de celles des autres, ce qui garantit la tolérance aux pannes. Les domaines de disponibilité ne partagent ni infrastructure (par exemple, alimentation, système de refroidissement), ni réseau de domaine de disponibilité interne. Par conséquent, une panne sur un domaine de disponibilité ne doit pas affecter les autres domaines de disponibilité de la région.
- Réseau et sous-réseau cloud virtuel OCI
Un réseau cloud virtuel est un réseau personnalisable défini par logiciel que vous configurez dans une région OCI. Comme les Réseaux de centre de données traditionnels, les Réseaux cloud virtuels vous donnent un contrôle sur l'environnement réseau. Un VCN peut comporter plusieurs blocs de routage interdomaine sans classe (CIDR) qui ne se chevauchent pas et que vous pouvez modifier une fois le VCN créé. Vous pouvez segmenter un réseau cloud virtuel en plusieurs sous-réseaux ciblant une région ou un domaine de disponibilité. Chaque sous-réseau est composé d'une plage contiguë d'adresses qui ne chevauchent pas celles des autres sous-réseaux du réseau cloud virtuel. Vous pouvez modifier la taille d'un sous-réseau après sa création. Un sous-réseau peut être public ou privé.
- Passerelle de routage dynamique
Le DRG est un routeur virtuel qui fournit un chemin pour le trafic de réseau privé entre les réseaux cloud virtuels d'une même région, entre un VCN et un réseau en dehors de la région, tel qu'un VCN dans une autre région OCI, un réseau sur site ou un réseau dans un autre fournisseur cloud.
- DNS OCI
Le service Oracle Cloud Infrastructure Domain Name System (DNS) est un réseau DNS anycast mondial hautement évolutif qui offre des performances DNS, une résilience et une évolutivité améliorées, afin que les utilisateurs finaux se connectent rapidement aux applications Internet, où qu'ils se trouvent.
-
Vue privée OCI DNS
Une vue privée DNS OCI est un ensemble de zones DNS privées OCI, utilisées pour regrouper logiquement les zones DNS et contrôler leur résolution. Une vue est attachée à un résolveur DNS privé, qui peut être le résolveur par défaut pour un réseau cloud virtuel (VCN) ou un résolveur personnalisé. Cela vous permet de gérer des configurations DNS distinctes pour différents environnements ou applications au sein de votre VCN.
-
Adresse IP virtuelle
Une adresse IP virtuelle (VIP) fait référence à une adresse IP qui n'est pas liée à une interface ou un périphérique réseau physique particulier. Au lieu de cela, il est abstrait et peut se déplacer entre les périphériques ou être utilisé pour diverses fonctions réseau.
-
Gestion du trafic OCI
OCI Traffic Management dirige intelligemment le trafic utilisateur vers des adresses optimales à l'aide de stratégies avancées basées sur DNS (stratégies de pilotage du trafic OCI). Elle permet aux entreprises de contrôler la façon dont les requêtes DNS sont résolues, en optimisant le routage des demandes client pour améliorer la disponibilité, les performances et la résilience des applications ou des services déployés sur OCI ou ailleurs.
-
Equilibreur de charge
Un équilibreur de charge est un système ou un service qui répartit le trafic réseau entrant entre plusieurs serveurs afin de garantir une haute disponibilité, une fiabilité et des performances optimales des applications.
-
Equilibreur de charge OCI
OCI Load Balancer est un service Oracle Cloud Infrastructure entièrement géré qui répartit automatiquement le trafic entrant entre plusieurs serveurs ou ressources back-end afin de garantir une haute disponibilité, de meilleures performances et une évolutivité optimale pour les applications.
-
Mode "block storage"
Le stockage de blocs est un type de stockage de données où les informations sont enregistrées dans des blocs de taille fixe et sont accessibles directement par les serveurs ou les applications via des protocoles de stockage tels que iSCSI ou Fibre Channel.
- Volumes de blocs OCI
Avec Oracle Cloud Infrastructure Block Volumes, vous pouvez créer, associer, connecter et déplacer des volumes de stockage, et modifier les performances de volume pour répondre aux exigences de stockage, de performances et d'application. Une fois un volume attaché et connecté à une instance, vous pouvez l'utiliser comme un disque dur classique. Vous pouvez également déconnecter un volume et l'attacher à une autre instance sans perdre des données.
-
Stockage partagé
Le stockage partagé fait référence à un système ou une ressource de stockage accessible simultanément par plusieurs serveurs, ordinateurs ou applications au sein d'un environnement informatique. Cette configuration permet à tous les systèmes participants de lire et d'écrire dans le même référentiel de données, ce qui le rend idéal pour les scénarios nécessitant une cohérence des données, une collaboration, une haute disponibilité et une évolutivité.
- OCI File Storage
Oracle Cloud Infrastructure File Storage offre un système d'exploitation réseau durable, évolutif, sécurisé et approprié à l'entreprise. Vous pouvez vous connecter à OCI File Storage à partir de n'importe quelle instance Bare Metal, de machine virtuelle ou de conteneur dans un VCN. Vous pouvez également accéder à OCI File Storage en dehors du VCN à l'aide d'Oracle Cloud Infrastructure FastConnect et du VPN IPSec.
-
Services de base de données OCI
Les services de base de données OCI font référence au portefeuille de solutions de base de données gérées fournies par Oracle Cloud Infrastructure (OCI). Ces services offrent une variété d'options de déploiement et de gestion de base de données dans Oracle Cloud, prenant en charge différents workloads, besoins en performances et modèles de données, tels qu'Oracle Base Database Service et Oracle Exadata Database Service.
- Oracle Data Guard
Oracle Data Guard et Active Data Guard fournissent un ensemble complet de services permettant de créer, de maintenir, de gérer et de surveiller des bases de données de secours afin que des bases de données Oracle de production puissent rester disponibles sans interruption. Oracle Data Guard conserve ces bases de données de secours en tant que copies de la base de données de production à l'aide de la réplication en mémoire. Si la base de données de production devient indisponible en raison d'une coupure planifiée ou non planifiée, Oracle Data Guard peut basculer n'importe quelle base de données de secours vers le rôle de production, ce qui réduit le temps d'inactivité associé à la coupure. Oracle Active Data Guard offre la possibilité supplémentaire de décharger les charges globales en lecture principalement vers les bases de données de secours et fournit également des fonctionnalités avancées de protection des données.
Ce guide utilise OCI comme exemple d'infrastructure pour déployer des clusters étendus Oracle Fusion Middleware. Voici les équivalences sur site vers OCI pour les principaux composants requis pour la configuration de cluster étendu Oracle Fusion Middleware :
| Sur site (ou générique) | Equivalent OCI |
|---|---|
| Site (ou centre de données) | Région OCI |
| Stockage partagé (par exemple, NFS) | OCI File Storage |
| Mode "block storage" | Volumes de blocs OCI |
| Equilibreur de charge global | OCI Traffic Management et stratégies de pilotage |
| Equilibreur de charge local | Equilibreur de charge OCI |
| Réseau | Réseau cloud virtuel OCI |
| Règles de pare-feu/pare-feu | Règles de sécurité du réseau OCI |
| DNS interne | Vue privée OCI DNS |
| Serveur physique/machine virtuelle | Instance OCI Compute |
| Base de données sur place | Service de base de données OCI |
| Connectivité sur site entre les sites | Appairage à distance OCI avec passerelle de routage dynamique |
Architecture
Les considérations suivantes s'appliquent à l'architecture de cluster étendue FMW :
- Régions
Il existe deux régions, ou sites, dans cette topologie. La latence entre eux ne doit pas être supérieure à 10 ms de temps aller-retour (RTT). Les exigences en matière de bande passante dépendent des types de charge utile gérés par chaque système, mais un minimum de 1 ou 2 gigabits par seconde (Gbps) est recommandé.
- Niveau intermédiaire
Le niveau intermédiaire fonctionne dans un modèle actif-actif, avec un seul domaine. La moitié des serveurs gérés sont déployés sur un site, le reste sur l'autre. Le serveur d'administration s'exécute sur un site mais peut basculer sur l'autre si nécessaire. Cette configuration est généralement appelée cluster étendu.
- Niveau base de données
Le niveau de base de données utilise une architecture active-passive, prise en charge par Oracle Data Guard. La base de données principale est située sur un site, tandis que la base de données de secours réside sur l'autre site. Tous les serveurs de niveau intermédiaire (middle tier) sont configurés pour se connecter à la base de données qui sert actuellement de base principale, quel que soit son emplacement. Oracle Database configuré dans chaque site est un Oracle Real Application Clusters (Oracle RAC). Oracle RAC permet à une base de données Oracle de s'exécuter sur un cluster de serveurs au sein du même centre de données, offrant tolérance aux pannes, performances et évolutivité sans aucune modification d'application nécessaire.
- Stockage
Le stockage partagé est local pour chaque site. Pour des raisons de contention et de sécurité, il n'est pas recommandé d'utiliser le stockage partagé entre les sites. La mise en miroir ou la réplication de disque de site1 vers site2 et vice versa est recommandée pour fournir une copie récupérable des artefacts dans chaque site.
- Emplacements de stockage persistants
Les banques persistantes WebLogic (Java Message Service (JMS) et l'API de transaction Java (JTA)) sont configurées en tant que banques JDBC (Java Database Connectivity) dans la base de données. De cette façon, ils sont accessibles à partir des deux sites. Cela permet à la fonctionnalité de migration automatique des services de fonctionner entre les deux sites.
- Demande de transfert
Les serveurs Web de chaque site transmettent les demandes uniquement aux instances Oracle WebLogic Server situées sur le même site. Il n'existe aucune communication inter-région entre les serveurs Web (instances Oracle HTTP Server) et les serveurs WebLogic de l'autre site pour minimiser la latence et le trafic inter-région.
- Equilibreurs de charge
Chaque site dispose de son propre équilibreur de charge dédié, qui dirige les demandes exclusivement vers les serveurs Web de ce site local. Il n'existe aucune communication inter-région entre les équilibreurs de charge et les serveurs Web situés sur l'autre site.
- Accès front-end
Devant le système, la solution fournit un accès frontal unique au système. Les clients se connectent à l'aide d'une seule adresse qui reste la même, quel que soit le site vers lequel ils sont dirigés. Ce mécanisme offre un nom de système de noms de domaine (DNS) accessible à tous les clients et achemine les demandes vers l'un ou l'autre site en fonction de critères et de règles prédéfinis, tels que l'emplacement géographique du client.
Le diagramme suivant illustre la topologie de cluster étendu Oracle Fusion Middleware.
cluster étendu-topologie-oracle.zip
Le diagramme suivant illustre le domaine et les clusters WebLogic dans la topologie de cluster étendu Oracle Fusion Middleware :
Avantages
- L'administration simplifiée
Les déploiements actifs-passifs entraînent une surcharge d'administration supplémentaire pour maintenir la synchronisation de la configuration entre le site principal et le site de secours. Bien que la plupart des informations et métadonnées d'exécution résident dans la base de données, la configuration Oracle WebLogic Server réside dans le système de fichiers. Par conséquent, en plus de la réplication Oracle Data Guard pour la base de données, le modèle actif-passif nécessite une réplication continue du système de fichiers, qui peut être implémentée de différentes manières (rsync, réplique au niveau du stockage, etc.).
Toutefois, dans le modèle de clusters étendus FMW, l'infrastructure Oracle WebLogic Server conserve la synchronisation de la configuration entre les différents noeuds d'un même domaine. La plupart de cette configuration se trouve généralement sous le répertoire de domaine du serveur d'administration. Cette configuration est propagée automatiquement vers les autres noeuds du même domaine au démarrage des serveurs gérés ou lors de l'implémentation d'une modification. Pour cette raison, la surcharge d'administration du déploiement est très faible par rapport à toute approche active-passive, où la réplication constante des modifications de configuration est requise.
- Disponibilité améliorée et réduction du RTO et du RPO pour certains scénarios de basculement
Le modèle de cluster étendu FMW fournit un meilleur objectif de point de récupération (RPO) et un meilleur objectif de temps de récupération (RTO) que le modèle actif-passif dans les scénarios suivants :
- Echec complet du niveau intermédiaire dans des événements de site
Si tous les serveurs de niveau intermédiaire d'un même emplacement échouent, le système peut continuer à traiter les demandes avec les serveurs de niveau intermédiaire du site homologue immédiatement. Le RTO et le RPO sont nuls dans ce type de scénario.
Pour ce faire, les serveurs de niveau intermédiaire de l'emplacement alternatif doivent être en mesure de supporter la charge de travail combinée des deux emplacements. Une planification appropriée de la capacité doit être effectuée pour tenir compte de ces scénarios. Selon la conception, il peut être nécessaire de limiter les demandes des clients finaux lorsqu'un seul site est actif. Sinon, les sites doivent être conçus avec une capacité excessive, ce qui va en partie à l'encontre de l'objectif d'une utilisation constante et efficace de la capacité.
- Echecs dans les événements de niveau base de données
Une permutation de la base de données implique les mêmes RTO et RPO dans un modèle de cluster actif-passif et étendu FMW. Toutefois, le RTO global du système est plus faible dans le modèle de cluster étendu car les serveurs de niveau intermédiaire sont déjà actifs sur le site secondaire. Il n'est pas nécessaire de redémarrer les niveaux intermédiaires. Une configuration de source de données appropriée, à l'aide d'une chaîne de connexion double avec des notifications GridLink et FAN (Fast Application Notification), automatise le basculement des connexions de base de données à partir des niveaux intermédiaires, réduisant ainsi le RTO du système.
- Echec complet du niveau intermédiaire dans des événements de site
Points à prendre en compte
- Planification de la capacité
Ce modèle nécessite la planification de la capacité pour prendre en compte les scénarios de basculement entre les deux sites. Si un site entier perd les niveaux intermédiaires, l'autre doit être en mesure de supporter l'intégralité de la charge globale. Sinon, le site disponible peut ne plus répondre en raison de la surcharge. Cela signifie que pendant le fonctionnement normal, les noeuds de niveau intermédiaire doivent être sous-utilisés pour permettre une capacité suffisante pour gérer les scénarios de basculement. La même règle s'applique au niveau Web. Si un site perd tous ses serveurs Web, les serveurs Web de l'autre site doivent être capables de gérer toutes les demandes du système.
- Débit réseau sur les sites
Le débit du réseau dépend principalement de deux choses : la distance des sites et la capacité du réseau à gérer la fiabilité et la congestion. Peu importe la vitesse à laquelle les serveurs ou les logiciels sont, il y a une limite à la vitesse à laquelle les données peuvent se déplacer entre les sites. Deux facteurs importants qui affectent ceci sont la latence et la gigue :
-
La latence est le temps nécessaire pour que les données circulent sur le réseau d'un site à un autre. Il peut être mesuré à sens unique (de la source à la destination) ou aller-retour (là et retour). Le temps d'aller-retour (RTT) est plus courant et peut être vérifié avec la commande
ping. -
Jitter est la variation du temps nécessaire à l'arrivée des paquets de données.
Pour le modèle actuel, le maintien de la latence faible est particulièrement important, car la gigue n'a généralement d'importance que lorsque la latence est déjà très faible. Par conséquent, le contrôle de la latence est la priorité principale pour de bonnes performances dans ce type de configuration. La distance est généralement la cause de latence la plus pertinente.
Les tests effectués ont montré que les performances de ce modèle (où certaines instances Oracle WebLogic Server du cluster se trouvent sur un site différent de celui de la base de données) se dégradent considérablement lorsque la latence (RTT) dépasse 10 millisecondes.
Oracle a effectué plusieurs tests avec différentes configurations affectées par différentes latences. Les latences de référence présentées dans ce guide différencient les clusters avec :- Tous les membres du même domaine de disponibilité
- Membres dans différents domaines de disponibilité
- Membres dans deux régions OCI proches mais différentes
L'image suivante présente le débit (transactions par seconde) d'un système SOA Oracle Fusion Middleware exécutant la démonstration de commande Fusion (FOD) pour différentes latences entre le serveur WebLogic et la base de données :
L'image suivante présente l'heure d'activité de l'API Java Transaction (JTA) pour un système SOA Oracle Fusion Middleware exécutant la démonstration de commande Fusion (FOD) qui utilise une base de données sur un site différent avec des latences différentes entre les sites :
L'image suivante montre la dégradation observée dans le débit système global des transactions par seconde pour différentes latences entre les sites (les deux sites travaillant ensemble avec la base de données dans l'un des sites).
Remarques :
Compte tenu de tout ce qui précède et des pénalités de performances observées dans de nombreux tests, Oracle ne prend pas en charge les clusters étendus Oracle Fusion Middleware qui dépassent 10 millisecondes de latence (RTT) entre les sites. Les systèmes peuvent fonctionner sans problème, mais les temps de transaction augmenteront considérablement. Des latences supérieures à 10 millisecondes (RTT) entraîneront également des problèmes dans le cluster Oracle Coherence utilisé pour le déploiement et JTA, les services Web ou les délais d'expiration des applications. Cela rend les solutions présentées dans ce livre de jeux adaptées principalement aux sites ou régions à faible latence entre eux.
-
- Trafic inter-région
Dans le modèle actuel, vous devez réduire le trafic entre les sites afin de réduire l'effet de la latence sur le débit du système. Dans un système FMW classique, les communications entre les différents niveaux ou éléments sont les suivantes :
-
Accès à la base de données à partir des instances Oracle WebLogic Server pour l'accès aux métadonnées et d'autres opérations de lecture/écriture de base de données.
-
Appels HTTP entrants à partir d'instances d'équilibreurs de charge ou d'Oracle HTTP Server et de callbacks HTTP.
-
Java Naming and Directory Interface (JNDI)/appels de méthode distante (RMI) et Java Message Service (JMS) entre les instances Oracle WebLogic Server.
-
Notifications Oracle Coherence entre tous les serveurs du système. Par exemple, SOA utilise Coherence pour fournir une image composite et de métadonnées cohérente.
-
Réplications de session HTTP entre les instances Oracle WebLogic Server. Certains composants utilisent des applications Web avec conservation de statut qui peuvent s'appuyer sur la réplication de session pour permettre un basculement transparent des sessions entre les serveurs. En fonction des modèles d'utilisation et du nombre d'utilisateurs, cela peut générer une quantité considérable de données de réplication.
-
L'accès au stockage LDAP (Lightweight Directory Access Protocol)/policy/identity est effectué par l'infrastructure Oracle WebLogic Server à des fins d'autorisation et d'authentification. Idéalement, chaque site doit disposer d'une banque d'identités et de stratégies indépendante qui est synchronisée régulièrement afin de minimiser les appels d'un site à l'autre. Les deux sites peuvent également partager le même magasin. L'impact du partage du magasin dépendra du type de magasin et du modèle d'utilisation du système.
Dans la mesure du possible, tout ce qui précède doit être contenu dans le site pour améliorer les performances. Exemple :
-
Les serveurs d'un même site ne doivent recevoir que les appels des instances Oracle HTTP Server du même site.
-
Les serveurs d'un même site ne doivent faire appel à JMS, RMI et JNDI qu'aux serveurs du même site et doivent recevoir des rappels générés par les serveurs du même site uniquement.
-
La réplication de session HTTP doit être limitée aux autres serveurs du même site uniquement. Les exigences en matière de réplication et de basculement doivent être analysées pour chaque analyse de rentabilité, mais idéalement, le trafic de réplication de session doit être réduit autant que possible entre les sites.
-
- Stockage partagé
La latence des écritures NFS sur les sites peut entraîner une dégradation grave des performances. Les serveurs doivent utiliser des périphériques de stockage locaux sur leur site pour éliminer les conflits dans les demandes de lecture/écriture adressées aux systèmes de fichiers. Le stockage partagé doit être limité à être dans chaque site.
- Autres ressources
Les deux sites peuvent partager d'autres ressources externes, telles que LDAP, les destinations JMS externes, les services Web externes, etc. Il faut que ces ressources soient toujours disponibles dans les deux sites. Les détails de configuration de ces ressources externes ne sont pas inclus dans ce guide.
