Cluster d’un Jboss EAP 6.2 (à partir de 7.x), les nodes du cluster ne se trouvent pas. Erreur du type: "dropping unicast message to wrong destination" ou "null: no physical address for"
Lors de la mise en cluster d’un Jboss EAP 6.2 (mais quelques soit la version à partir de 7.x), il se peut que les nodes du cluster (sur différent serveur) ne se voient pas et que certains messages apparaissent dans la console de JBOSS alors que si vous essayer de faire un cluster sur une même machine le cluster fonctionne.
Si vous utilisez la stack TCP.
14:21:51,523 WARN [org.jgroups.protocols.TCP] (MPING) null: no physical address for 0105a729-0fdd-8e84-0214-11dc6d90526e, dropping message
Si vous utilisez la stack UDP:
11:48:54,484 WARN [org.jgroups.protocols.TP$ProtocolAdapter] (Incoming-2,shared=udp) dropping unicast message to wrong destination node02/web; my local_addr is node01/web
Vous possédez deux machines avec un jboss installé sur chaque. Dans cet exemple nous avons monté deux jboss en mode standalone HA avec la stack UDP. Voici une liste de point à voir pour déterminer pourquoi le cluster ne communique pas correctement.
Premièrement avant toute chose, il faut tester si la connectivité réseau fonctionne correctement avec la commande ping.
Si la commande ping fonctionne, il se peut que vous possédiez un problème de multicast UDP. Pour tester, il suffit d’utiliser l’outil iperf comme dans l’article suivant. Tester le traffic multicast
Si le réseau et la traffic multicast fonctionne, le problème peut venir d’une autre chose. En effet, il se trouve que la configuraion de jboss écoutant sur toutes les interfaces ne fonctionne pas avec le mode HA. Il est nécessaire de bien configurer l’adresse IP de l’interface réseau qui doit servir au mode HA. Par exemple
<
inet-address value="192.168.100.1">
<
/inet-address><
/interface>
<
interface name="public">
<
inet-address value="192.168.100.1">
<
/inet-address><
/interface>
<
interface name="unsecure">
<
inet-address value="127.0.0.1">
<
/inet-address><
/interface>
et ne pas utiliser cette configuration:
<
any-address>
<
/any-address><
/interface>
<
interface name="public">
<
any-address>
<
/any-address><
/interface>
<
interface name="unsecure">
<
inet-address value="127.0.0.1">
<
/inet-address><
/interface>
Avec cette modification, les node du cluster JBOSS, se connectent bien et communiquent entre eux soit en UDP soit en TCP en fonction de stack choisie.
Article sur l’industrialisation de la mise en cluster de JBOSS
Plus d’information sur Jboss dans la catégorie JBOSS
Si vous souhaitez être rappeler pour que l’un de nos experts vous aide, n’hésitez pas à nous contacter.
Derrière le terme « cloud » se cache bien plus qu’un simple mot à la mode ou un lointain serveur hébergé quelque part sur Internet. Depuis une dizaine d’années, le cloud computing s’est imposé comme LE modèle incontournable pour déployer ces applications. Mais de quoi parle-t-on réellement quand on évoque le cloud ? Pourquoi tout le monde fait-il cette transition ? Quels sont les avantages, mais aussi les limites de ce modèle ?
Les tests E2E, c’est quoi ? Définition, implémentation et retour d’expériences des librairies de tests E2E !
Optimiser l’architecture de son SI, ce n’est pas une mince affaire… Vous connaissez peut-être déjà l’analogie qui compare les systèmes d’information à des villes. De la même manière que l’un des enjeux de l’urbanisme réside dans l’harmonie parfois précaire entre les vieux bâtiments et les tours flambant neuves, maintenir un SI est avant tout une question d’équilibre entre l’ancien et le neuf. N’étant pas spécialistes du sujet, on ne saurait pas vous dire à quoi devrait ressembler la ville parfaite. Par contre, on peut vous assurer qu’un bon SI est un SI avec une architecture maîtrisée qui répond aux besoins de l’entreprise, et qui maximise les fonctionnalités tout en réduisant les coûts.