Cas d'utilisation d'un gestionnaire de haute disponibilité
Un gestionnaire de haute disponibilité consomme des ressources système de valeur, du type cycles CPU, segment de mémoire et sockets. Ces ressources sont consommées à la fois par le gestionnaire de haute disponibilité et par les composants du produit qui utilisent les services fournis par ce gestionnaire. La quantité de ressources consommées par le gestionnaire de haute disponibilité et ces composants du produit augmente de façon non linéaire avec la taille du groupe central.
Pour les groupes centraux volumineux, la quantité de ressources consommées par le gestionnaire de haute disponibilité peut devenir très importante. Désactiver le gestionnaire de haute disponibilité permet de libérer ces ressources. Mais auparavant, vous devez étudier dans les moindres détails les besoins actuels et futurs de votre système afin d'être sûr que cela ne désactive pas également d'autres fonctions qui vous sont nécessaires et qui utilisent les services du gestionnaire de haute disponibilité. Par exemple, la réplication de mémoire à mémoire et le distributeur de requêtes à distance (RRD) nécessitent tous les deux que le gestionnaire de haute disponibilité soit activé.
La possibilité de désactiver le gestionnaire de haute disponibilité est surtout utile dans les topologies lorsqu'aucun des services fournis par ce gestionnaire n'est utilisé. Dans certaines topologies, seuls certains processus utilisent le service fourni par le gestionnaire de haute disponibilité. Vous pouvez alors désactiver le gestionnaire par processus, ce qui optimise la quantité de ressources utilisées par le gestionnaire.
Ne désactivez pas le gestionnaire de haute disponibilité pour les processus administratifs, comme les agents de noeud et le gestionnaire de déploiement, sauf si le gestionnaire est désactivé pour tous les processus du serveur d'applications dans ce groupe central.
Certains des services fournis par le gestionnaire de haute disponibilité sont basés sur le cluster. Par conséquent, comme les membres d'un cluster doivent être homogènes, si vous désactivez le gestionnaire de haute disponibilité pour un des membres du cluster, vous devez le désactiver sur tous les autres membres du cluster.
- Réplication mémoire-à-mémoire
- Reprise sur un serveur uniquement
- Routage de la gestion de charge de travail


Réplication mémoire-à-mémoire
La réplication mémoire à mémoire est un service basé sur cluster que vous configurez ou activez au niveau du serveur d'applications. Si elle est activée sur un membre d'un cluster, le gestionnaire de haute disponibilité doit être activé sur tous les membres de ce cluster. La réplication mémoire à mémoire est automatiquement activée si :
- La réplication mémoire à mémoire est activée pour les sessions HTTP du conteneur Web.
- La réplication de cache est activée pour le service de mémoire cache dynamique.
- La reprise en ligne sur bean session avec état EJB est activée pour un serveur d'applications.
Reprise sur un serveur uniquement
![[AIX Solaris HP-UX Linux Windows]](../images/dist.gif)
![[IBM i]](../images/iseries.gif)
- Le cluster est configuré pour utiliser le gestionnaire de haute disponibilité pour gérer la reprise des journaux des transactions.
- Une ou plusieurs instances du fournisseur de messagerie par défaut sont configurées pour s'exécuter dans le cluster. Ce fournisseur, fourni avec le produit, est également appelé bus d'intégration de services.
La reprise sur un serveur uniquement est un service basé sur cluster.
Le gestionnaire de haute disponibilité doit être activé sur tous les membres d'un cluster si une ou plusieurs instances du fournisseur de messagerie par défaut sont configurées pour s'exécuter dans le cluster. Le fournisseur de messagerie par défaut est le moteur de messagerie fourni avec le produit.
Gestion de charge de travail
Informations de routage du trafic IIOP des beans.
- Informations de routage du moteur de messagerie par défaut, également appelé bus d'intégration de services.
- Routage des requêtes HTTP via le serveur proxy IBM® WebSphere Application Server.
- Routage des demandes d'adressage des services Web via le serveur proxy IBM WebSphere Application Server.
- Requête de routage SIP (Session Initiation Protocol).
La fonction WLM utilise le gestionnaire de haute disponibilité à la fois pour propager les informations de routage et pour les rendre accessibles en haute disponibilité. Bien que les informations de routage WLM s'appliquent généralement aux ressources en cluster, elles peuvent également s'appliquer à des ressources configurées de manière différente, telles que les moteurs de messagerie autonomes. Normalement, le gestionnaire de haute disponibilité doit toujours être activé sur tout serveur d'applications qui fournit ou consomme des informations de routage IIOP ou de moteur de messagerie.
- Le fournisseur des informations de routage est une application de bean enterprise qui réside dans le cluster 1.
- Le consommateur des informations de routage est un servlet qui réside dans le cluster 2.
Lorsque le servlet du cluster 2 appelle l'application de bean enterprise du cluster 1, le gestionnaire de haute disponibilité doit être activé sur tous les serveurs des deux clusters.
Les MBeans de gestion de charge de travail ClusterMgr et Cluster peuvent renvoyer des informations de base concernant un cluster. Toutefois, si le gestionnaire de haute disponibilité est désactivé dans une partie de votre topologie, vous ne pouvez pas modifier les paramètres en cours et propager vos modifications à tous les membres du cluster.
La gestion de charge de travail fournit une option permettant de générer statiquement et exporter des tables de routage vers le système de fichiers. Servez-vous de cette option pour éliminer toute dépendance au gestionnaire de haute disponibilité.

Par exemple, comme la réplication des données entre les membres d'un cluster de proxys n'existe pas, la reprise en ligne entre les serveurs proxy du cluster n'est pas prise en charge. Si un serveur proxy est arrêté, toutes les connexions actives appartenant au serveur proxy disparaissent et les demandes entrantes échouent. Toutefois, les serveurs proxy et les clusters de proxys prennent en charge la haute disponibilité et la reprise en ligne des serveurs dorsaux, de sorte que le serveur proxy peut détecter si un serveur dorsal est arrêté et acheminer les demandes à un serveur sur lequel la session est répliquée.
gotchaExemple de sortie :
myCluster1(cells/mycell/clusters/myCluster1|cluster.xml#ServerCluster_1)