Interopération lorsque les serveurs d'applications WebSphere et le gestionnaire de files d'attente IBM MQ sont mis en cluster.
Les gestionnaires de files d'attente IBM MQ sont généralement mis en cluster afin de distribuer la charge de travail des messages et de permettre aux autres gestionnaires de files d'attente de poursuivre le traitement en cas de défaillance de l'un d'entre eux.
- Les gestionnaires de files d'attente s'exécutent sur des hôtes différents des serveurs d'applications.
- Les gestionnaires de files d'attente s'exécutent sur les mêmes hôtes que les serveurs d'applications.
Les gestionnaires de files d'attente s'exécutent sur des hôtes différents 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.
- Les gestionnaires de files d'attente 1, 2 et 3 se trouvent dans le même cluster IBM MQ.
- Le gestionnaire de files d'attente 1 s'exécute sur l'hôte 3.
- Le gestionnaire de files d'attente 2 s'exécute sur l'hôte 4.
- Le gestionnaire de files d'attente 3 s'exécute sur l'hôte 5.
- Le gestionnaire de files d'attente 3 est chargé de distribuer les messages entre les files d'attente du cluster de manière à équilibrer la charge.
- 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 et 2 se connectent en mode client au gestionnaire de files d'attente 1.
- Le serveur d'applications 3 se connecte en mode client au gestionnaire de files d'attente 2.

- En cas de défaillance du serveur d'applications 1 :
- Le serveur d'applications 2 peut traiter sa charge de travail, car ils sont tous les deux connectés au gestionnaire de files d'attente 1.
- Si le serveur d'applications 2 tombe en panne :
- Le serveur d'applications peut traiter sa charge de travail, car ils sont tous les deux connectés au gestionnaire de files d'attente 1.
- Si le serveur d'applications 3 tombe en panne :
- Vous devez le redémarrer dès que possible pour les raisons suivantes :
- Les autres serveurs d'applications du cluster peuvent traiter sa charge de travail externe, mais aucun autre serveur d'applications peut traiter sa charge de travail IBM MQ, car aucun autre serveur d'applications n'est connecté au gestionnaire de files d'attente 2. La charge de travail générée par le serveur d'applications 3 s'arrête.
- Le gestionnaire de files d'attente 3 continue de distribuer le travail entre les gestionnaires de files d'attente 1 et 2, même si la charge de travail qui arrive dans le gestionnaire de files d'attente ne peut pas être traitée par le serveur d'applications 1 ou 2.
Remarque : Si vous décidez de ne pas redémarrer, vous pouvez alléger cette situation en configurant manuellement Q1 dans le gestionnaire de files d'attente 2 de sorte que l'insertion de messages y est impossible. Tous les messages sont donc envoyés au gestionnaire de files d'attente 1 où ils sont traités par les autres serveurs d'applications. - Si le gestionnaire de files d'attente 1 tombe en panne :
- Vous devez le redémarrer dès que possible pour les raisons suivantes :
- Les messages gérés par le gestionnaire de files d'attente 1 ne sont traités que quand vous le redémarrez.
- Aucun nouveau message des applications IBM MQ n'est envoyé au gestionnaire de files d'attente 1 ; les nouveaux messages sont envoyés au gestionnaire de files d'attente 2 et consommés par le serveur d'applications 3.
- Comme les serveurs d'applications 1 et 2 ne sont pas connectés au gestionnaire de files d'attente 2, ils ne peuvent pas consommer sa charge de travail.
- Comme les serveurs d'applications 1, 2 et 3 se trouvent dans le même cluster WebSphere Application Server, leur charge de travail non-IBM MQ continue d'être distribuée entre eux tous, même si les serveurs d'applications 1 et 2 ne peuvent pas utiliser IBM MQ suite à la défaillance du gestionnaire de files d'attente 1.
Bien que cette topologie de réseau procure à la fois la disponibilité et l'évolutivité souhaitées, la relation entre la charge de travail des différents gestionnaires de files d'attente et les serveurs d'applications auxquels ils sont connectés est complexe. N'hésitez pas à contacter votre représentant IBM® pour demander un avis d'expert.
Les gestionnaires de files d'attente s'exécutent sur les mêmes hôtes que les serveurs d'applications.
Dans l'illustration qui suit :
- Les serveurs d'applications 1, 2 et 3 se trouvent dans le 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.
- Les gestionnaires de files d'attente 1, 2 et 3 se trouvent dans le même cluster IBM MQ.
- Le gestionnaire de files d'attente 1 s'exécute sur l'hôte 1.
- Le gestionnaire de files d'attente 2 s'exécute sur l'hôte 2.
- Le gestionnaire de files d'attente 3 s'exécute sur l'hôte 3.
- Le gestionnaire de files d'attente 3 est chargé de distribuer les messages entre les files d'attente du cluster de manière à équilibrer la charge.
- 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 se connectent au gestionnaire de files d'attente 1 en mode bindings.
- Le serveur d'applications 2 se connecte au gestionnaire de files d'attente 2 en mode bindings.

- En cas de défaillance du serveur d'applications 1 :
- Le serveur d'applications 3 peut traiter sa charge de travail, car ils sont tous les deux connectés au gestionnaire de files d'attente 1.
- Si le serveur d'applications 3 tombe en panne :
- Le serveur d'applications 1 peut traiter sa charge de travail, car ils sont tous les deux connectés au gestionnaire de files d'attente 1.
- Si le serveur d'applications 2 tombe en panne :
- Vous devez le redémarrer dès que possible pour les raisons suivantes :
- Comme aucun autre serveur d'applications n'est connecté au gestionnaire de files d'attente 2, aucun serveur d'applications ne peut prendre en charge sa charge de travail IBM MQ. La charge de travail qui était générée par le serveur d'applications 2 s'arrête. Toutefois, les autres serveurs d'applications du cluster peuvent prendre en charge sa charge de travail externe.
- Le gestionnaire de files d'attente 3 continue de distribuer le travail entre les gestionnaires de files d'attente 1 et 2, même si la charge de travail qui arrive dans le gestionnaire de files d'attente 2 ne peut pas être traitée par le serveur d'applications 2. Remarque : Si vous décidez de ne pas redémarrer, vous pouvez alléger cette situation en configurant manuellement Q1 dans le gestionnaire de files d'attente 2 de sorte que l'insertion de messages y est impossible. Tous les messages sont donc envoyés au gestionnaire de files d'attente 1 où ils sont traités par les autres serveurs d'applications.
- Si le gestionnaire de files d'attente 1 tombe en panne :
- Vous devez le redémarrer dès que possible pour les raisons suivantes :
- Les messages gérés par le gestionnaire de files d'attente 1 ne sont traités que quand vous le redémarrez.
- Comme les serveurs d'applications 1 et 3 ne sont pas connectés au gestionnaire de files d'attente 2, ils ne peuvent pas consommer sa charge de travail.
- Aucun nouveau message des applications IBM MQ n'est envoyé au gestionnaire de files d'attente 1 ; les nouveaux messages sont envoyés au gestionnaire de files d'attente 2 et consommés par le serveur d'applications 2.
- Comme le serveurs d'applications 1, 2 et 3 se trouvent dans le même cluster WebSphere Application Server, leur charge de travail non-IBM MQ continue d'être distribuée entre eux tous, même si les serveurs d'applications 1 et 3 ne peuvent pas utiliser IBM MQ suite à la défaillance du gestionnaire de files d'attente 1.
Bien que cette topologie de réseau procure à la fois la disponibilité et l'évolutivité souhaitées, la relation entre la charge de travail des différents gestionnaires de files d'attente et les serveurs d'applications auxquels ils sont connectés est complexe. N'hésitez pas à contacter votre représentant IBM pour demander un avis d'expert.