Connexion de serveurs WebSphere Application Server à IBM MQ for z/OS avec des groupes de partage de files d'attente
Sur les systèmes z/OS, un serveur d'applications peut se connecter à un gestionnaire de files d'attente membre d'un groupe de partage de files d'attente IBM MQ for z/OS. Vous pouvez configurer la connexion afin qu'elle sélectionne un gestionnaire de files d'attente désigné, spécifique ou vous pouvez la configurer pour accepter n'importe quel gestionnaire de files d'attente dans le groupe de partage de files d'attente.
Si vous configurez une connexion pour sélectionner un gestionnaire de files d'attente désigné spécifique, vos options de haute disponibilité sont identiques à celles de la connexion à IBM MQ sur d'autres plateformes. Toutefois, vous pouvez améliorer la disponibilité si vous configurez la connexion pour accepter n'importe quel gestionnaire de files d'attente dans le groupe de partage de files d'attente. Dans ce cas, lorsque le serveur d'applications se reconnecte à la suite d'une défaillance du gestionnaire de files d'attente IBM MQ, le serveur d'applications peut accepter la connexion à un gestionnaire de files d'attente différent qui n'est pas défaillant.
Une connexion que vous configurez pour accepter n'importe quel gestionnaire de files d'attente doit uniquement être utilisée pour accéder aux files d'attente partagées. Une file d'attente partagée est une file d'attente unique à laquelle peuvent accéder tous les gestionnaires de files d'attente du groupe de partage de files d'attente. Le gestionnaire de files d'attente utilisé par une application pour accéder à une file d'attente partagée n'a pas d'importance. Y compris si la même instance d'application utilise des gestionnaires de files d'attente différents pour accéder à la même file d'attente partagée, les résultats obtenus sont toujours cohérents.
- Les serveurs d'applications et les gestionnaires de files d'attente s'exécutent dans la même partition logique (LPAR).
- Les serveurs d'applications et les gestionnaires de files d'attente s'exécutent dans des partitions logiques différentes (LPAR).
Les serveurs d'applications et le gestionnaires de files d'attente s'exécutent dans la même partition logique (LPAR)
L'illustration suivante montre une connexion en mode de liaisons de WebSphere Application Server vers IBM MQ for z/OS. L'illustration suivante montre la configuration ci-après :
- Les serveurs d'applications 1 et 2 appartiennent à un cluster WebSphere Application Server.
- Le serveur d'applications s'exécute dans la LPAR 1.
- Le serveur d'applications 2 s'exécute dans la LPAR 2.
- Les gestionnaires de files d'attente 1 et 2 sont membres d'un groupe de partage de files d'attente IBM MQ qui héberge une file d'attente partagée, Q1. Cette file d'attente partagée se trouve dans une unité de couplage.
- Le gestionnaire de files d'attente 1 s'exécute dans la LPAR 1.
- Le gestionnaire de files d'attente 2 s'exécute dans la LPAR 2.
- 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 établie avec un gestionnaire de file d'attente en
cours d'exécution sur le même hôte. Une connexion bindings s'appelle également "Connexion par appel".
- Le serveur d'applications 1 et le gestionnaire de files d'attente 1 sont interconnectés en mode bindings.
- Le serveur d'applications 2 et le gestionnaire de files d'attente 2 sont interconnectés en mode bindings.

Cette topologie de réseau peut bénéficier de l'équilibrage de charge "pull" si plusieurs instances d'application, y compris des instances s'exécutant sur différentes partitions logiques, traitent des messages provenant de la même file d'attente partagée.
Vous pouvez renforcer la disponibilité de cette topologie en utilisant z/OS Automatic Restart Manager (ARM) pour redémarrer les serveurs d'applications ou les gestionnaires de files d'attente défaillants. Si un gestionnaire de files d'attente dans la LPAR est défaillant, ARM peut redémarrer un serveur d'applications dans une LPAR différente dans laquelle le serveur d'applications peut se connecter à un gestionnaire de files d'attente actif au lieu d'attendre le redémarrage du gestionnaire de files d'attente qu'il utilisait précédemment. Dans l'exemple de cette section, ARM peut redémarrer le serveur d'applications 1 WebSphere Application Server dans la LPAR 2 où il peut se connecter au gestionnaire de files d'attente 2 IBM MQ au lieu d'attendre le redémarrage du gestionnaire de files d'attente 1.
Les serveurs d'applications et les gestionnaires de files d'attente s'exécutent dans des partitions logiques différentes (LPAR)
L'illustration suivante montre une connexion en mode Client de WebSphere Application Server vers IBM MQ for z/OS. L'illustration suivante montre la configuration ci-après :
- Les gestionnaires de files d'attente 1 et 2 sont membres d'un groupe de partage de files d'attente IBM MQ qui héberge une file d'attente partagée, Q1. Cette file d'attente partagée se trouve dans une unité de couplage. Les deux gestionnaires de file d'attente s'exécutent sur des partitions logiques différentes.
- 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".
- Plusieurs serveurs d'applications ont une connexion (TCP/IP) en mode client aux gestionnaires de files d'attente. Toutes les connexions de mode client sont gérées par le distributeur de sysplex z/OS qui sélectionne le gestionnaire de files d'attente 1 ou le gestionnaire de files d'attente 2 pour chaque demande de connexion.
Figure 2. WebSphere Application Server avec une connexion en mode client à IBM MQ for z/OS
De même que dans l'exemple de connexion en mode bindings, cette topologie de réseau peut bénéficier de l'équilibrage de charge "pull" si plusieurs instances d'application s'exécutant sur des serveurs d'applications différents ou identiques, traitent des messages provenant de la même file d'attente partagée.
L'utilisation du distributeur de sysplex z/OS améliore la disponibilité de cette topologie de réseau. Si l'un des gestionnaire de files d'attente est défaillant, le distributeur z/OS sysplex peut connecter les applications exécutées dans les serveurs d'applications à l'autre gestionnaire de files d'attente sans attendre le redémarrage du gestionnaire de files d'attente défaillant. Dans l'exemple de cette section, si le gestionnaire de files d'attente 1 est défaillant, le distributeur z/OS sysplex peut sélectionner le gestionnaire de files d'attente 2 pour chaque demande de connexions jusqu'à ce que le gestionnaire de files d'attente 1 redémarre.