Introduction
La configuration de ce livre de jeu utilise un seul domaine Oracle WebLogic Server dans lequel les serveurs de deux sites participent à la même grappe (appelée grappe étendue) et s'appuient sur Data Guard pour assurer la protection de la base de données.
Dans OCI, des fonctions telles que la gestion du trafic, les vérifications d'état, les équilibreurs de charge, les vues privées DNS et les passerelles de routage dynamique offrent des capacités améliorées pour prendre en charge cette configuration. Pour les environnements sur place, des composants de réseau et d'infrastructure équivalents doivent être utilisés pour répondre à ces exigences.
La latence réseau entre les sites ou les régions doit être suffisamment faible pour minimiser la pénalité de performance introduite par le retard des appels et é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 au temps aller-retour (RTT) de 10 ms.
Pour optimiser les performances et les comportements de basculement, Oracle recommande d'analyser chaque application s'exécutant dans une grappe étendue WebLogic et d'ajuster les différents paramètres discutés dans ce livre de jeu (temporisations, configuration de la réplication de session, location pour la migration de service, API de transaction Java (JTA), etc.) en conséquence.
En savoir plus sur les grappes étirées Oracle Fusion Middleware
Fournir l'architecture MAA (Maximum Availability Architecture) d'Oracle est l'une des exigences clés pour tout déploiement d'entreprise Oracle Fusion Middleware.
Oracle Fusion Middleware comprend un jeu complet de fonctions haute disponibilité, telles que la détection et le redémarrage des processus, la mise en grappe de serveurs, la migration de 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 planifiées, qui protègent un déploiement d'entreprise contre les temps d'arrêt non planifiés et réduisent les temps d'arrêt planifiés. Ces fonctionnalités offrent une solution locale à haute disponibilité 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 un centre de données entier. La plupart des systèmes traditionnels de protection contre les catastrophes utilisent le modèle actif-passif qui implique la mise en place 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 regroupement entre les deux sites. Cette approche offre une protection complète de l'architecture MAA (Maximum Availability Architecture). Cependant, cela entraîne des coûts d'exploitation et d'administration supplémentaires, car le système intergiciel de secours reflète 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 d'Oracle Fusion Middleware.
Ce livre de jeu décrit un autre modèle : le modèle actif-actif basé sur les grappes étendues d'Oracle Fusion Middleware, qui peut être utilisé pour protéger un système Oracle Fusion Middleware contre les temps d'arrêt dans plusieurs emplacements. 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 grappes étendues FMW.
Ce livre de jeu explique en particulier comment mettre en oeuvre ce modèle dans les régions Oracle Cloud Infrastructure (OCI). Il fournit les étapes de configuration permettant de configurer la topologie recommandée et des conseils sur les incidences de cette configuration sur les performances et le basculement en cas de panne.
Les résultats et les exemples de ce livre de jeu 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 comprend 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 des 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 intergiciel)
Le niveau intermédiaire (middle tier) fait référence à la couche d'une architecture d'application à plusieurs niveaux située 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é, servant de pont entre l'utilisateur et la base de données.
-
Oracle Fusion Middleware
Oracle Fusion Middleware est une gamme complète de produits d'intergiciel d'entreprise d'Oracle qui permet aux organisations de créer, de déployer et de gérer des applications de manière efficace et sécurisée. Il comprend des solutions pour les serveurs d'applications, l'intégration, la gestion des processus d'affaires, l'intelligence d'affaires, la sécurité, la gestion des identités, les serveurs Web, etc.
-
Catastrophe
Événement catastrophique soudain et non planifié qui cause des dommages ou des pertes inacceptables sur 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 critiques pendant une période inacceptable et qui amène l'organisation à invoquer ses plans de reprise.
-
Récupération après sinistre
Capacité de se protéger contre les pannes naturelles ou non planifiées sur un site de production en ayant un programme de récupération des applications et des données sur un site de secours géographiquement distinct.
-
Architecture de disponibilité maximale d'Oracle
L'architecture de disponibilité maximale d'Oracle (Oracle MAA) est le modèle de meilleures 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 d'Oracle MAA est l'une des exigences clés pour tout déploiement Oracle. Il fournit des recommandations pour la configuration et la gestion d'un système Oracle. Oracle MAA inclut les recommandations d'Oracle Fusion Middleware Enterprise Deployment Guide et ajoute les meilleures pratiques de protection en cas de sinistre afin de réduire 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. Consultez la section Explorer 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 pour exécuter un groupe d'applications. Par exemple, un site peut comprendre des instances Oracle Fusion Middleware, des bases de données, du 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é de la base de données, du module d'écoute, du serveur d'applications et des cibles d'hôtes sur lesquelles l'application s'exécute.
-
Grappe étirée
Un cluster étendu fait référence à une architecture de cluster dans laquelle les noeuds d'un cluster logique unique sont répartis entre des centres de données ou des emplacements géographiquement distincts.
-
Permutation
La permutation 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 courant. Lors d'une permutation, le site de secours courant devient le nouveau site de production et le site de production courant devient le nouveau site de secours. Ce livre de jeu utilise également le terme de permutation pour désigner une permutation de site.
-
Rétablir
La fonction Switchback consiste à rétablir les rôles initiaux du site de production et du site de secours en cours. Les opérations de permutation sont des opérations planifiées effectuées une fois l'opération de permutation terminée. Un switchback restaure 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 livre de lecture utilise également le terme switchback pour désigner un site switchback.
-
Basculer
Le basculement consiste à faire du site de secours courant le nouveau site de production une fois que le site de production devient indisponible de manière inattendue en raison, par exemple, d'un sinistre sur le site de production. Ce livre de jeu utilise également le terme basculement pour désigner un basculement de site.
-
Objectif de point de recouvrement
L'objectif du point de récupération est la quantité de perte de données qu'un système peut tolérer d'un point de vue commercial, telle que la quantité de perte de données acceptable en cas de panne.
-
Objectif de délai de récupération
L'objectif de délai de récupération est le temps d'arrêt qu'un système peut tolérer ou le temps acceptable pendant lequel une application ou un service peut rester indisponible lorsqu'une panne se produit, d'un point de vue commercial.
- Oracle Cloud Infrastructure
Oracle Cloud Infrastructure (OCI) est un jeu de services en nuage complémentaires qui vous permettent de créer et d'exécuter une gamme d'applications et de services dans un environnement hébergé hautement disponible. OCI fournit des fonctions de calcul de haute performance (en tant qu'instances matérielles physiques) et une capacité de stockage dans un réseau virtuel flexible accessible de manière sécurisée à partir de votre réseau local.
-
Région OCI
Une région OCI est une zone géographique localisée qui contient un ou plusieurs centres de données, des domaines de disponibilité d'hébergement. Les régions sont indépendantes les unes des autres, et de grandes distances peuvent les séparer (à travers les pays ou même les continents).
Une région est un site en termes de reprise après sinistre.
- Domaine de disponibilité
Les domaines de disponibilité sont des centres de données indépendants et autonomes dans une région. Les ressources physiques de chaque domaine de disponibilité sont isolées des ressources des autres domaines de disponibilité, ce qui garantit la tolérance aux pannes. Les domaines de disponibilité ne partagent pas les éléments d'infrastructure (alimentation ou refroidissement, par exemple) ni le réseau de domaines de disponibilité interne. Ainsi, une défaillance d'un domaine de disponibilité ne doit pas avoir d'incidence sur les autres domaines de disponibilité de la région.
- Réseau en nuage virtuel et sous-réseau OCI
Un réseau en nuage virtuel (VCN) est un réseau défini par logiciel personnalisable, configuré dans une région OCI. Comme les réseaux de centre de données traditionnels, les réseaux en nuage virtuels vous permettent de contrôler votre environnement de réseau. Un VCN peut disposer de plusieurs blocs de routage inter-domaine (CIDR) sans chevauchement que vous pouvez modifier après avoir créé le VCN. Vous pouvez segmenter un VCN en sous-réseaux, dont la portée peut concerner une région ou un domaine de disponibilité. Un sous-réseau est constitué d'un intervalle contigu d'adresses qui ne chevauchent pas les autres sous-réseaux dans le réseau en nuage 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 (DRG)
La passerelle DRG est un routeur virtuel qui fournit un chemin pour le trafic réseau privé entre des réseaux en nuage virtuels de la 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 place ou un réseau dans un autre fournisseur de nuage.
- DNS OCI
Le service de système de noms de domaine (DNS) d'Oracle Cloud Infrastructure est un réseau mondial hautement évolutif de système de noms de domaine d'unidiffusion aléatoire (DNS) qui offre une performance, une résilience et une extensibilité améliorées au service de DNS, afin que les utilisateurs finaux se connectent rapidement aux applications Internet, de n'importe où.
-
Vue privée de DNS d'OCI
Une vue privée du DNS OCI est une collection d'une ou de plusieurs 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 d'un réseau en nuage virtuel (VCN) ou 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 réseau physique ou à un périphérique particulier. Au lieu de cela, il est abstrait et peut se déplacer entre les appareils ou être utilisé pour diverses fonctions réseau.
-
Gestion du trafic OCI
OCI Traffic Management dirige intelligemment le trafic des utilisateurs vers des points d'extrémité optimaux à l'aide de politiques DNS avancées (politiques de pilotage du trafic OCI). Il permet aux organisations de contrôler la façon dont les interrogations DNS sont résolues, en optimisant l'acheminement des demandes des clients pour améliorer la disponibilité, la performance et la résilience des applications ou des services déployés sur OCI ou ailleurs.
-
Équilibreur 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 d'assurer une haute disponibilité, une fiabilité et une performance optimale des applications.
-
Équilibreur de charge OCI
Le service Équilibreur de charge OCI est un service Oracle Cloud Infrastructure entièrement géré qui répartit automatiquement le trafic entrant entre plusieurs serveurs ou ressources dorsaux pour assurer une haute disponibilité, une meilleure performance et une meilleure extensibilité pour les applications.
-
Stockage par blocs
Le stockage par blocs est un type de stockage de données où les informations sont enregistrées dans des blocs de taille fixe et accessibles directement par les serveurs ou les applications via des protocoles de stockage tels que iSCSI ou Fibre Channel.
- Volumes par blocs OCI
Avec Oracle Cloud Infrastructure Block Volumes, vous pouvez créer, attacher, connecter et déplacer des volumes de stockage et modifier la performance des volumes pour répondre à vos exigences en matière de stockage, de performance et d'applications. 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'associer à une autre instance sans perdre de données.
-
Stockage partagé
Le stockage partagé désigne un système de stockage ou une ressource auquel plusieurs serveurs, ordinateurs ou applications accèdent simultanément 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, une collaboration, une haute disponibilité et une évolutivité des données.
- Stockage de fichiers pour OCI
Le service de stockage de fichiers pour Oracle Cloud Infrastructure fournit un système de fichiers de réseau durable, évolutif, sécurisé et adapté à l'entreprise. Vous pouvez vous connecter au stockage de fichiers OCI à partir de n'importe quelle instance sans système d'exploitation, de machine virtuelle ou de conteneur dans un VCN. Vous pouvez également accéder au service Stockage de fichiers OCI à partir de l'extérieur du VCN à l'aide d'Oracle Cloud Infrastructure FastConnect et du RPV 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 bases de données dans Oracle Cloud, prenant en charge différentes charges de travail, besoins en performance 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 tenir à jour, de gérer et de surveiller une ou plusieurs bases de données de secours et de permettre aux bases de données Oracle de production de rester disponibles sans interruption. Oracle Data Guard gère 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 interruption 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, réduisant ainsi le temps d'arrêt associé à l'interruption. Oracle Active Data Guard offre la possibilité supplémentaire de décharger les charges de travail en lecture la plupart du temps vers les bases de données de secours et offre également des fonctions avancées de protection des données.
Ce livre de jeu utilise OCI comme exemple d'infrastructure pour déployer des grappes étendues Oracle Fusion Middleware. Il s'agit des équivalences sur place à OCI pour les principaux composants requis pour la configuration de grappe étendue d'Oracle Fusion Middleware :
| Sur place (ou générique) | Équivalent OCI |
|---|---|
| Site (ou centre de données) | Région OCI |
| Stockage partagé (par exemple, NFS) | Service de stockage de fichiers pour OCI |
| Stockage par blocs | Volumes par blocs OCI |
| Équilibreur de charge global | Gestion du trafic OCI et politiques de pilotage |
| Équilibreur de charge local | Équilibreur de charge OCI |
| Réseau | Réseau en nuage virtuel OCI |
| Règles de pare-feu/pare-feu | Règles de sécurité de réseau OCI |
| DNS interne | Vue privée de DNS d'OCI |
| Serveur physique / machine virtuelle | Instance de calcul OCI |
| Base de données sur place | Service de base de données OCI |
| Connectivité sur place entre les sites | Appairage distant OCI avec passerelle de routage dynamique |
Architecture
Les considérations suivantes s'appliquent à l'architecture de cluster étendue FMW :
- Régions
Il y a 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 charges utiles traités par chaque système, mais un minimum de 1 ou 2 gigabits par seconde (Gbit/s) 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 site. Le serveur d'administration s'exécute sur un site, mais peut basculer vers l'autre site si nécessaire. Cette configuration est communément appelée grappe étirée.
- Niveau de 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 principale est située sur un site, tandis que la base 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 une Oracle Real Application Clusters (Oracle RAC). Oracle RAC permet à une base de données Oracle de s'exécuter sur une grappe de serveurs dans le même centre de données, ce qui assure la tolérance aux pannes, la performance et l'évolutivité, sans qu'aucune modification d'application ne soit 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 de disque ou la réplication de site1 vers site2 et inversement est recommandée pour fournir une copie récupérable des artefacts de chaque site.
- Magasins persistants
Les magasins persistants WebLogic (Java Message Service (JMS) et l'API de transaction Java (JTA)) sont configurés en tant que magasins JDBC (Java Database Connectivity) dans la base de données. De cette façon, ils sont accessibles à partir des deux sites. Cela permet à la fonction de migration automatique de service 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 dans le même site. Il n'y a pas de communication inter-région entre les serveurs Web (instances Oracle HTTP Server) et les serveurs WebLogic de l'autre site afin de réduire la latence et le trafic inter-région.
- Équilibreurs 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'y a pas de communication inter-région entre les équilibreurs de charge et les serveurs Web situés sur l'autre site.
- Accès frontal
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 des sites 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 grappe étendue d'Oracle Fusion Middleware
stretched-cluster-topology-oracle.zip
Le diagramme suivant illustre le domaine WebLogic et les grappes dans la topologie de grappe étendue d'Oracle Fusion Middleware :
Avantages
- Administration simplifiée
Les déploiements actifs-passifs entraînent une surcharge d'administration supplémentaire pour assurer 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. Ainsi, 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 mise en oeuvre de différentes façons (rsync, réplique au niveau du stockage, etc.).
Dans le modèle de grappes étendues FMW, toutefois, l'infrastructure Oracle WebLogic Server maintient la configuration synchronisée entre les plusieurs noeuds du même domaine. La plupart de cette configuration réside généralement dans le répertoire du domaine du serveur d'administration. Cette configuration est propagée automatiquement aux 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ù une réplication constante des modifications de configuration est requise.
- Disponibilité améliorée et RTO et RPO inférieurs pour certains scénarios de basculement
Le modèle de cluster étendu FMW offre 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 ces scénarios :
- Échec complet du niveau intermédiaire dans un événement de site
Si tous les serveurs de niveau intermédiaire d'un emplacement échouent, le système peut continuer à traiter immédiatement les demandes avec les serveurs de niveau intermédiaire du site pair. L'objectif de délai de récupération et l'objectif de point de reprise sont nuls dans ce type de scénario.
Pour ce faire, les serveurs de niveau intermédiaire (middle tier) situés dans un autre emplacement doivent être en mesure de supporter la charge globale combinée des deux emplacements. Une planification appropriée des capacités doit être effectuée pour tenir compte de ces scénarios. Selon la conception, les demandes des clients finaux peuvent devoir être ralenties lorsqu'un seul site est actif. Dans le cas contraire, les sites doivent être conçus avec une capacité excesdive, ce qui contredit partiellement l'objectif d'une utilisation constante et efficace de la capacité.
- Échecs dans les événements de niveau base de données
Une permutation de base de données entraîne les mêmes objectifs de point de reprise (RTO) et d'objectif de point de reprise (RPO) dans un modèle de cluster actif-passif et étendu FMW. Toutefois, l'objectif de délai de récupération global du système est plus faible dans le modèle de cluster étendu, car les serveurs de niveau intermédiaire (middle tier) sont déjà actifs sur le site secondaire. Un redémarrage des niveaux intermédiaires n'est pas nécessaire. Une configuration de source de données appropriée, à l'aide d'une chaîne de connexion double avec les avis GridLink et FAN (Fast Application Notification), automatise le basculement des connexions de base de données à partir des niveaux intermédiaires, réduisant ainsi l'ODR du système.
- Échec complet du niveau intermédiaire dans un événement de site
Points à considérer
- Planification des capacités
Ce modèle nécessite une planification de la capacité pour tenir compte des 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 toute la charge de travail. Sinon, le site disponible peut ne plus répondre en raison de la surcharge. Cela signifie que pendant un 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 traiter toutes les demandes du système.
- Débit réseau entre les sites
Le débit du réseau dépend principalement de deux choses : la distance parcourue par les sites et la façon dont le réseau gère la fiabilité et la congestion. Peu importe la vitesse des serveurs ou des logiciels, il y a une limite à la vitesse à laquelle les données peuvent se déplacer entre les sites. Deux facteurs importants sont la latence et la gigue :
-
Latence : Temps requis pour que les données circulent sur le réseau d'un site à un autre. Il peut être mesuré unidirectionnel (de la source à la destination) ou aller-retour (là et là). Le temps 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 la performance de ce modèle (où certaines instances Oracle WebLogic Server de la grappe se trouvent dans un site différent de celui de la base de données) se dégrade considérablement lorsque la latence (RTT) dépasse 10 millisecondes.
Plusieurs tests ont été effectués par Oracle avec différentes configurations affectées par différentes latences. Les latences de référence indiquées dans ce livre de jeu distinguent 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 le temps d'activité de l'API JTA (Java Transaction API) pour un système SOA Oracle Fusion Middleware exécutant Fusion Order Demo (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 global du système dans les 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).
Note :
Compte tenu de tout ce qui précède et des pénalités de performance observées dans de nombreux tests, Oracle ne prend pas en charge les grappes étendues d'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. Les latences au-delà de 10 millisecondes (RTT) entraîneront également des problèmes dans la grappe Oracle Coherence utilisée pour le déploiement et JTA, les services Web ou les temporisations d'application. Cela rend les solutions présentées dans ce livre de jeu adaptées principalement aux sites ou régions à faible latence entre eux.
-
- Trafic inter-régions
Dans le modèle courant, 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 typique, 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.
-
Appel HTTP entrant à partir d'instances d'équilibreurs de charge (LBR) ou d'instances Oracle HTTP Server et de rappels HTTP.
-
Java Naming and Directory Interface (JNDI)/Remote Method Invocation (RMI) and Java Message Service (JMS) invocations between Oracle WebLogic Server instances.
-
Avis 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 état qui peuvent s'appuyer sur la réplication de session pour permettre le basculement transparent des sessions sur tous les serveurs. Selon les modèles d'utilisation et le nombre d'utilisateurs, cela peut générer une quantité considérable de données de réplication.
-
L'accès au magasin 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 devrait disposer d'un magasin d'identités et de politiques indépendant qui est synchronisé régulièrement pour minimiser les appels d'un site à l'autre. Alternativement, les deux sites peuvent 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. Par exemple :
-
Les serveurs d'un site ne doivent recevoir que les appels provenant d'instances Oracle HTTP Server du même site.
-
Les serveurs d'un même site doivent faire des appels JMS, RMI et JNDI uniquement aux serveurs du même site et doivent obtenir des rappels générés par les serveurs uniquement sur le même site.
-
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 rentabilisation, 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 (Network File System) sur les sites peut entraîner une grave dégradation des performances. Les serveurs doivent utiliser des périphériques de stockage locaux sur leur site pour éliminer les contentions dans les demandes de lecture/écriture adressées aux systèmes de fichiers. Le stockage partagé doit être limité à l'intérieur de chaque site.
- Autres ressources
Les deux sites peuvent partager d'autres ressources externes, telles que LDAP, des destinations JMS externes, des services Web externes, etc. Il est nécessaire 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 livre de jeu.
