Mise en grappe de Websphere MQ

Question

Je suis assez novice en matière de Websphere MQ, alors pardonnez-moi si je n'utilise pas les bons termes. Nous réalisons un projet dans lequel nous devons configurer un cluster MQ pour la haute disponibilité.

L'application client maintient un pool de connexion avec le gestionnaire de files d'attente pour les abonnés et les éditeurs. Supposons que nous ayons deux gestionnaires de files d'attente dans un cluster hébergeant les files d'attente avec les mêmes noms. Chacune des files d'attente a son propre ensemble d'abonnés et d'éditeurs qui sont mis en cache par l'application cliente. Supposons que l'un des gestionnaires de files d'attente tombe en panne, les abonnés et les éditeurs des files d'attente sur ce gestionnaire de files d'attente mourront, rendant les objets de l'application client défunts.

Dans ce cas, les scénarios suivants peuvent-ils être pris en charge ?

1] Lorsque le premier QueueManager tombe en panne, les messages de ses files d'attente sont transférés vers d'autres QueueManager du cluster.

2] Lorsque QueueManager se remet en marche, existe-t-il un mécanisme pour restaurer les éditeurs et les abonnés. Actuellement, nous avons écrit un thread de récupération automatique dans l'application client qui tente de reconnecter les éditeurs et les abonnés défaillants. Mais dans le cas d'une configuration en cluster, nous craignons que les éditeurs et les abonnés se reconnectent à l'autre qmanager en cours d'exécution. Et lorsque le gestionnaire de files d'attente défaillant est restauré, il n'y aura plus d'éditeurs et d'abonnés.

Quelqu'un peut-il m'expliquer comment résoudre les deux scénarios ci-dessus ?

Answer 1

Le clustering WMQ est un sujet avancé. Vous devez d'abord vous documenter sur WMQ et comprendre ce que signifie le clustering dans le monde WMQ avant de tenter quoi que ce soit.

WMQ Cluster diffère à bien des égards des clusters traditionnels. Contrairement aux clusters traditionnels, par exemple dans un cluster actif/passif, les données seront partagées entre les instances actives et passives d'une application. À tout moment, l'instance active de l'application traitera les données. Lorsque l'instance active s'arrête, l'instance passive prend le relais et commence le traitement. Ce n'est pas le cas dans les clusters WMQ où les gestionnaires de file d'attente d'un cluster sont uniques et où les files d'attente/sujets hébergés par ces gestionnaires ne sont pas partagés. Vous pouvez avoir les mêmes files d'attente/sujets dans les deux gestionnaires de files d'attente, mais comme les gestionnaires de files d'attente sont différents, les messages, les sujets, les abonnements, etc. ne seront pas partagés.

Je réponds à vos questions.
1) Non. Les messages, s'ils sont persistants, resteront dans le gestionnaire de file d'attente écrasé. Ils ne seront pas transférés vers un autre gestionnaire de file d'attente. Puisque le gestionnaire de file d'attente lui-même n'est pas disponible, rien ne peut être fait jusqu'à ce que le gestionnaire de file d'attente soit rétabli.
2)Non. Le gestionnaire de la file d'attente ne peut pas faire ça. C'est le devoir de l'application de vérifier la disponibilité du gestionnaire de file d'attente et de se reconnecter. WMQ fournit une fonction de reconnexion automatique des clients où les bibliothèques clientes WMQ se reconnectent automatiquement au gestionnaire de file d'attente lorsqu'elles détectent des erreurs de rupture de connexion. Cette fonction est disponible à partir de WMQ v7.x et plus avec les clients C et Java. Le client C# supporte cette fonctionnalité à partir de la version 7.1.

Pour votre exigence de haute disponibilité, vous pouvez envisager d'utiliser la fonction de gestionnaire de file d'attente multi-instance de WMQ. Cette fonction permet de faire tourner des instances actives/passives du même gestionnaire de file d'attente sur deux machines différentes. L'instance active du gestionnaire de file d'attente traitera les connexions des clients tandis que l'instance passive sera en mode veille. Les deux instances partageront les données et les journaux. Lorsque l'instance active s'éteint, l'instance passive devient active. Vous aurez accès à tous les messages persistants qui étaient dans les files d'attente avant que le gestionnaire de file d'attente actif ne s'arrête.

Lisez l'InfoCenter WMQ pour en savoir plus sur le gestionnaire de file d'attente à instances multiples.

Answer 2

Pour compléter la réponse de Shashi, pour tirer le meilleur parti de la mise en grappe de WMQ, vous devez disposer d'un saut de réseau entre les émetteurs et les récepteurs de messages. Le clustering WMQ concerne la façon dont les QMgrs parlent entre eux. Il n'a rien à voir avec la façon dont les applications clientes parlent à QMgrs et ne réplique pas les messages. Dans un cluster, lorsqu'un message doit aller d'un QMgr à un autre, le cluster détermine où l'acheminer. S'il existe plusieurs instances en cluster d'une même file d'attente de destination, le message peut être acheminé vers n'importe laquelle d'entre elles. S'il n'y a pas de saut de réseau entre les expéditeurs et les récepteurs, alors les messages n'ont pas besoin de quitter le QMgr local et donc le comportement de clustering de WMQ n'est jamais invoqué, même si les QMgrs impliqués peuvent participer au cluster.

Dans une architecture classique de cluster WMQ, les récepteurs écoutent tous plusieurs instances de la même file d'attente, avec le même nom, réparties sur plusieurs QMgr. Les expéditeurs ont un ou plusieurs QMgrs où ils peuvent se connecter et envoyer des requêtes (fire-and-forget), en attendant éventuellement des réponses (request-reply). Puisque les récepteurs des messages fournissent un certain service, j'appelle leurs QMgrs "QMgrs de fournisseur de services". Les QMgrs où vivent les expéditeurs de messages sont des QMgrs "consommateurs de services" car ces applications sont des consommateurs de services.

La diapositive ci-dessous est tirée d'une présentation que j'utilise dans le cadre de mes missions de conseil en architecture WMQ.

Notez que les consommateurs de services, c'est-à-dire les personnes qui envoient des messages de demande, ne sont pas pris en compte. Les éléments qui écoutent les files d'attente des points de terminaison des services et qui fournissent des services ne basculent PAS. Ceci est dû à la nécessité de s'assurer que chaque file d'attente active de point de terminaison de service est toujours servie. Typiquement, chaque instance d'application détient un handle d'entrée sur deux ou plusieurs instances de file d'attente. De cette façon, un QMgr peut tomber en panne et toutes les instances d'application restent actives. Si une instance d'application tombe en panne, une autre instance d'application continue à servir ses files d'attente. Cette affinité des fournisseurs de services avec des QMgr spécifiques permet également la transactionnalité XA si nécessaire.

Le meilleur moyen que j'ai trouvé pour expliquer WMQ HA est une diapositive de la conférence IMPACT :

Un cluster WebSphere MQ garantit qu'un service reste disponible, même si une instance d'une file d'attente en cluster peut être indisponible. Les nouveaux messages dans le cluster seront acheminés vers les instances de file d'attente restantes. Un cluster matériel ou un QMgr multi-instance (MIQM) permet d'accéder aux messages existants. Lorsqu'un côté de la paire active/passive tombe en panne, il y a une brève interruption de service. sur ce QMgr uniquement pendant que le basculement se produit, le nœud secondaire prend le relais et rend à nouveau disponibles tous les messages se trouvant dans les files d'attente. Un réseau qui combine à la fois des clusters WMQ et des clusters matériels/MIQM offre le plus haut niveau de disponibilité.

Gardez à l'esprit que dans aucune de ces configurations, les messages ne sont répliqués entre les nœuds. Un message WMQ a toujours un seul emplacement physique. Pour en savoir plus sur cet aspect, veuillez consulter Réflexions sur la reprise après sinistre .