Interopération lorsque les serveurs d'applications WebSphere sont mis en cluster, mais pas le gestionnaire de files d'attente IBM MQ.

Les serveurs d'applications exécutés sur WebSphere Application Server peuvent être mis en cluster et connectés à des gestionnaires de files d'attente exécutés sur des IBM MQ qui ne sont pas en cluster. Cette configuration fournit une protection de basculement étendue par rapport aux topologies sans cluster.

Remarque : Dans cette rubrique, "serveur d'applications" fait référence à un serveur d'applications exécuté sur WebSphere Application Server et "gestionnaire de files d'attente" fait référence à un gestionnaire de files d'attente exécuté sur IBM MQ.
Il existe deux options de topologie :
  • Les serveurs d'applications s'exécutent sur plusieurs hôtes dont l'un d'entre eux hébergent un gestionnaire de files d'attente.
  • Le gestionnaire de files d'attente s'exécute sur un hôte ne correspondant à aucun des serveurs d'applications.

Le gestionnaire de files d'attente s'exécute sur un hôte ne correspondant à aucun des serveurs d'applications.

Dans l'illustration qui suit :
  • Les serveurs d'applications 1, 2 et 3 se trouvent dans un cluster WebSphere Application Server.
  • Les serveurs d'applications 1 et 3 s'exécutent sur l'hôte 1.
  • Le serveur d'applications 2 s'exécute sur l'hôte 2.
  • Le gestionnaire de files d'attente s'exécute sur l'hôte 3.
  • Une connexion "client" est utilisée lorsque le serveur d'applications et le gestionnaire de files d'attente sont exécutés sur des hôtes différents. Il s'agit d'une connexion réseau TCP/IP utilisée pour communiquer avec le gestionnaire de files d'attente. Une connexion client s'appelle également "Connexion par socket".
    • Les serveurs d'applications 1, 2 et 3 sont connectés au gestionnaire de files d'attente en mode client.
Figure 1. Mise en cluster de WebSphere Application Server : connexion en mode client avec le gestionnaire de files d'attente
Serveurs d'applications WebSphere Application Server 1 et 3 exécutés sur Host 1. Serveur d'applications WebSphere Application Server 2 exécuté sur Host 2. Un gestionnaire de files d'attente IBM MQ s'exécute sur Host 3.
  • Si un serveur d'applications clusterisé tombe en panne, ou l'hôte sur lequel il s'exécute, les autres serveurs d'applications du cluster peuvent reprendre sa charge de travail.
  • En cas de défaillance du gestionnaire de files d'attente ou de l'hôte sur lequel il s'exécute, l'interopération s'arrête.

Vous pouvez améliorer la disponibilité de cette topologie en utilisant, par exemple, High Availability Cluster Multi-Processing (HACMP) pour redémarrer automatiquement le gestionnaire de file d'attente défaillant.

Les serveurs d'applications s'exécutent sur plusieurs hôtes dont l'un d'entre eux hébergent un gestionnaire de files d'attente.

L'illustration suivante montre des serveurs d'applications exécutés sur le même hôte que le gestionnaire de files d'attente. Les autres serveurs d'applications du même cluster WebSphere Application Server s'exécutent sur un autre système hôte.

Dans l'illustration qui suit :
  • Les serveurs d'applications 1, 2 et 3 se trouvent dans un cluster WebSphere Application Server.
  • Les serveurs d'applications 1 et 3 s'exécutent sur l'hôte 1.
  • Le serveur d'applications 2 s'exécute sur l'hôte 2.
  • Le gestionnaire de files d'attente s'exécute sur l'hôte 1.
  • Le type de transport de la connexion est spécifié sous la forme "bindings". Une connexion "bindings" est utilisée lorsque le serveur d'applications et le gestionnaire de files d'attente sont exécutés sur le même hôte. Il s'agit d'une connexion réseau intermémoire utilisée pour communiquer avec le gestionnaire de files d'attente. Une connexion bindings s'appelle également "Connexion par appel".
    • Les serveurs d'applications 1 et 3 sont connectés au gestionnaire de files d'attente en mode bindings.
  • Une connexion "client" est utilisée lorsque le serveur d'applications et le gestionnaire de files d'attente sont exécutés sur des hôtes différents. Il s'agit d'une connexion réseau TCP/IP utilisée pour communiquer avec le gestionnaire de files d'attente. Une connexion client s'appelle également "Connexion par socket".
    • Le serveur d'applications 2 est connecté au gestionnaire de files d'attente en mode client.
Remarque : Pour les serveurs d'applications exécutés sur le même hôte qu'un gestionnaire de files d'attente, le type de transport IBM MQ pour la connexion est défini sous le mode "bindings then client", à savoir que si une tentative de connexion en mode bindings au gestionnaire de files d'attente échoue, une connexion en mode client est établie. Pour les serveurs d'applications qui ne s'exécutent pas sur le même hôte que le gestionnaire de files d'attente, le serveur d'applications utilise automatiquement le mode client.
Figure 2. Mise en cluster de WebSphere Application Server : connexion au gestionnaire de files d'attente en mode "liaisons puis client"
Les serveurs d'applications WebSphere Application Server 1 et 3 et un gestionnaire de files d'attente IBM MQ sont exécutés sur l'hôte 1. Le serveur d'applications WebSphere Application Server 2 est exécuté sur l'hôte 2.
  • En cas de défaillance des serveurs d'applications, les serveurs d'applications restants du cluster peuvent prendre en charge sa charge de travail.
  • Si l'hôte 2 est défaillant, le serveur d'applications 2 s'arrête. Les serveurs d'applications 1 et 3 peuvent prendre en charge sa charge de travail.
  • Si le gestionnaire de files d'attente est défaillant, l'interopération s'arrête.
  • Si l'hôte 1 est défaillant, le gestionnaire de files d'attente, le serveur d'applications 1 et le serveur d'applications 3 s'arrêtent. L'interopération s'arrête.

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=cmm_mq_top02_semiclustered1
Nom du fichier : cmm_mq_top02_semiclustered1.html