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.

Pour savoir si vous devez laisser le gestionnaire de haute disponibilité activé pour un processus donné du serveur d'applications, demandez-vous si le processus requiert l'un des services suivants du gestionnaire :
  • Réplication mémoire-à-mémoire
  • Reprise sur un serveur uniquement
  • Routage de la gestion de charge de travail
Eviter les incidents Eviter les incidents: La plupart des composants internes utilisent l'infrastructure du gestionnaire haute disponibilité ou dépendent des services internes qui utilisent le gestionnaire haute disponibilité. Par conséquent, la liste des services du gestionnaires haute disponibilité n'est pas nécessairement une liste exhaustive de services affectés par la désactivation du gestionnaire haute disponibilité. En outre, la liste peut changer, car un plus grand nombre de services peuvent changer pour utiliser le gestionnaire haute disponibilité à tout moment. gotcha
Pratiques recommandées Pratiques recommandées: Au lieu de désactiver le gestionnaire de haute disponibilité, créez plusieurs cellules ou partitionnez une cellule en plusieurs groupes centraux et créez des ponts. Même si vous n'utilisez pas actuellement un composant qui nécessite le gestionnaire de haute disponibilité, vous pouvez devoir en utiliser un plus tard.bprac

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][IBM i]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 :
  • 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.

[z/OS]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

La fonction de gestion de la charge de travail (WLM) propage les classes ou types d'informations de routage suivants :
  • [AIX Solaris HP-UX Linux Windows][IBM i]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.

Par exemple, si :
  • 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é.

Eviter les incidents Eviter les incidents: Un cluster de serveurs proxys ne dispose pas de toutes les fonctions d'un cluster d'un serveur d'applications.

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.

gotcha

Exemple de sortie :

myCluster1(cells/mycell/clusters/myCluster1|cluster.xml#ServerCluster_1)

Icône indiquant le type de rubrique Rubrique de concept



Icône d'horodatage Dernière mise à jour: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=crun_ha_ham_required
Nom du fichier : crun_ha_ham_required.html