Étapes pour rendre un service JNDI HornetQ existant en tant que HA?


177

TL; DR

Quelles sont les étapes pour configurer un service HA-JNDI avec une configuration HornetQ? Je pense que la documentation est un peu dispersée. J'ai lu les documents ici mais ne semble pas illustrer en détail.

Version plus longue:

Nous avons donc une configuration HornetQ JMS avec JNDI. Nous avons disons 5 serveurs, qui exécutent l'instance principale HornetQ JMS avec le service JNDI sur chacun. Sur chacun de ces 5 serveurs, nous avons également un esclave fonctionnant pour un autre maître HornetQ.

Pour illustrer:

Server A - HornetQa_master, JNDI, HornetQb_slave
Server B - HornetQb_master, JNDI, HornetQc_slave
Server C - HornetQc_master, JNDI, HornetQd_slave
Server D - HornetQd_master, JNDI, HornetQe_slave
Server E - HornetQe_master, JNDI, HornetQa_slave

Chacun de ces serveurs HornetQ sert d'intermédiaire pour nos divers besoins de backend, ce qui signifie 5 serveurs, 5 instances maîtres HornetQ, 5 instances esclaves HornetQ et 5 serveurs JNDI. Le problème, cependant, avec cette configuration est que si un hôte serveur (pas seulement le processus, l'hôte lui-même), disons A tombe en panne, idéalement le service devrait se replier sur HornetQ fonctionnant sur le serveur E qui héberge l'esclave HornetQ de A. Cependant, pour reprendre en tant que maître HornetQ, le HornetQa_slave doit parler au processus JNDI en cours d'exécution sur le serveur A (je présume de répliquer les messages). Puisque l'hôte A est lui-même en panne, le HornetQa_slave fonctionnant sur E n'a aucun moyen de parler au JNDI sur A, et ne peut donc pas reprendre en tant que processus maître.

Si le service JNDI avait été hautement disponible, le processus HornetQ esclave pourrait reprendre en tant que maître comme prévu. Quelqu'un pourrait-il gentiment pointer vers la documentation ou illustrer en étapes simples comment nous pourrions convertir notre configuration existante en HA-JNDI? Pour ce que ça vaut, j'ai lu plusieurs sources , mais cela ne semble pas illustrer en détail comment commencer à configurer un HA-JNDI. Veuillez me faire savoir si vous avez besoin de plus d'informations sur notre configuration actuelle.


8
Où fonctionnent vos clients? S'exécutent-ils sur les mêmes instances AS ou à partir d'une autre instance / JVM, ou les deux?
jjhavokk

3
@jjhavokk ils fonctionneraient sur une autre JVM
gravetii

4
Pourriez-vous activer HornetQ en mode haute disponibilité (réplication active - passive)? Ajoutez à cela la découverte dynamique du serveur et vous devriez avoir une solution de secours fiable. Voir docs.jboss.org/hornetq/2.4.0.Final/docs/user-manual/html/… et docs.jboss.org/hornetq/2.4.0.Final/docs/user-manual/html/…
diginoise

4
Quelle version de jboss utilisez-vous?
2017 à

5
Je vois que c'est vraiment vieux, mais je me demande si vous avez trouvé la réponse. À présent, vous savez probablement que la haute disponibilité nécessite <forward-when-no-consumers> true </forward-when-no-consumers> pour propager les messages, mais que la restauration vers master ne fonctionne pas. J'ai eu la même configuration dans weblogic et websphere où la restauration fonctionne, mais pas avec jboss. Y a-t-il quelque chose à définir pour permettre au maître de synchroniser et de mettre à jour les messages manqués afin qu'une restauration correcte fonctionne?
user1442498

Réponses:


1

Avec l'architecture décrite, cela me semble difficile, car en effet il faut reconfigurer l'esclave en maître et alors il y aura une certaine panne.

HornetQ HA est fourni via une paire de sauvegarde en direct et l'équilibrage de charge est fourni via un cluster.

Si vous voulez à la fois la haute disponibilité et l'équilibrage de charge, vous aurez besoin de 2 paires de sauvegarde en direct groupées ensemble.

Source: https://developer.jboss.org/thread/254232

Vous pouvez référencer le maître non pas par le nom d'hôte mais en utilisant une adresse IP virtuelle , de sorte qu'en cas de panne du maître, vous pouvez reconfigurer l'un des esclaves en tant que maître et démarrer l'IP virtuelle pour ne pas avoir à reconfigurer le reste des esclaves. (Pour conserver HA même lorsque le maître est hors service, vous voulez avoir 2 esclaves, de sorte que vous puissiez redémarrer l'un d'entre eux en tant que maître et qu'un autre fonctionnera).

Une autre façon d'obtenir le même résultat consiste à utiliser un nom d'hôte DNS spécifique au maître que vous pouvez reconfigurer pour pointer vers une adresse IP différente si un hôte est en panne. Puisque DNS est mis en cache, ces entrées devraient mieux se trouver dans le fichier «hosts».

Si 3 hôtes par domaine HA représentent trop de matériel, vous pouvez accomplir cela plus facilement avec des serveurs virtuels sans avoir besoin d'acheter plus de matériel.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.