Les nœuds JBoss 4.2.2 commencent à se grouper puis se suspectent mutuellement

J'ai un site web fonctionnant avec JBoss 4.2.2 sur un serveur Red Hat existant. Je configure un deuxième serveur de manière à avoir une paire groupée (qui sera alors équilibrée en charge). Cependant, je ne peux pas les amener à se regrouper avec succès.Les nœuds JBoss 4.2.2 commencent à se grouper puis se suspectent mutuellement

Le serveur existant démarre JBoss avec:

run.sh -c default -b 0.0.0.0

(je sais la configuration « par défaut » ne prend pas en charge le regroupement de la boîte - J'utilise une version modifiée de celui-ci qui inclut le support de regroupement .) Lorsque je lance la seconde instance de JBoss avec la même commande, elle forme son propre cluster sans remarquer le premier. Les deux utilisent le même nom de partition et l'adresse et le port de multidiffusion.

J'ai essayé les programmes McastReceiverTest et McastSenderTest pour vérifier que les machines pouvaient communiquer par multidiffusion; ils pourraient.

Je remarquai alors l'info à http://docs.jboss.org/jbossas/docs/Clustering_Guide/beta422/html/ch07s07s07.html, en disant que JGroups ne peut se lier à toutes les interfaces, et se fixe à la place de l'interface par défaut; donc probablement c'était lier à 127.0.0.1, et de ce fait ne pas obtenir les messages à travers. Ainsi, au lieu que je mets les instances de dire JGroups utiliser les adresses IP internes:

run.sh -c default -b 0.0.0.0 -Djgroups.bind_addr=10.51.1.131 
run.sh -c default -b 0.0.0.0 -Djgroups.bind_addr=10.51.1.141

(.131 est le serveur existant, 0,141 est le nouveau serveur).

Les nœuds se remarquent maintenant et forment un cluster - au début. Cependant, tout en essayant de déployer le .ear, le journal du serveur dit ceci:

2010-08-07 22:26:39,321 DEBUG [org.jgroups.protocols.FD] sending are-you-alive msg to 10.51.1.131:46294 (own address=10.51.1.141:47629) 
2010-08-07 22:26:45,412 WARN [org.jgroups.protocols.FD] I was suspected by 10.51.1.131:48733; ignoring the SUSPECT message and sending back a HEARTBEAT_ACK 
2010-08-07 22:26:49,324 DEBUG [org.jgroups.protocols.FD] sending are-you-alive msg to 10.51.1.131:46294 (own address=10.51.1.141:47629) 
2010-08-07 22:26:49,324 DEBUG [org.jgroups.protocols.FD] heartbeat missing from 10.51.1.131:46294 (number=0) 
2010-08-07 22:26:49,529 DEBUG [org.jgroups.protocols.MERGE2] initial_mbrs=[[own_addr=10.51.1.141:60365, coord_addr=10.51.1.141:60365, is_server=true]] 
2010-08-07 22:26:52,092 WARN [org.jboss.cache.TreeCache] replication failure with method_call optimisticPrepare; id:18; Args: (arg[0] = GlobalTransaction:<10.51.1.131:46294>:5421085 ...) exception org.jboss.cache.lock.TimeoutException: failure acquiring lock: fqn=/Yudu_ear,Yudu-ejb_jar,Yudu-ejbPU/com/yudu/ejb/entity, caller=GlobalTransaction:<10.51.1.131:46294>:5421085, lock=read owners=[GlobalTransaction:<10.51.1.131:46294>:5421081] (activeReaders=1, activeWriter=null, waitingReaders=0, waitingWriters=1, waitingUpgrader=0)

... et le .ear ne se déploie pas.

Si je change CacheMode dans ejb3-entity-cache-service.xml de REPL_SYNC à LOCAL, le .ear se déploie correctement, bien que la réplication du cache d'entité ne se produise bien sûr pas. Cependant, le journal montre encore des signes intéressants du même problème.

Il ressemble à:

d'abord le nouveau nœud trouve une et forme un cluster
existant alors les contrôles FD échouent, et après un certain nombre d'échecs le nouveau nœud se sépare du cluster et forme son propre cluster d'un
puis il le retrouve, re-clusters et cette fois les vérifications FD fonctionnent.

Bits importants du fichier journal:

2010-08-07 23:47:07,423 INFO [org.jgroups.protocols.UDP] socket information: local_addr=10.51.1.141:35666, mcast_addr=228.1.2.3:45566, bind_addr=/10.51.1.141, ttl=2 sock: bound to 10.51.1.141:35666, receive buffer size=131071, send buffer size=131071 mcast_recv_sock: bound to 0.0.0.0:45566, send buffer size=131071, receive buffer size=131071 mcast_send_sock: bound to 10.51.1.141:59196, send buffer size=131071, receive buffer size=131071 
2010-08-07 23:47:07,431 DEBUG [org.jgroups.protocols.UDP] created unicast receiver thread 
2010-08-07 23:47:09,445 DEBUG [org.jgroups.protocols.pbcast.GMS] initial_mbrs are [[own_addr=10.51.1.131:48888, coord_addr=10.51.1.131:48888, is_server=true]] 
2010-08-07 23:47:09,446 DEBUG [org.jgroups.protocols.pbcast.GMS] election results: {10.51.1.131:48888=1} 
2010-08-07 23:47:09,446 DEBUG [org.jgroups.protocols.pbcast.GMS] sending handleJoin(10.51.1.141:35666) to 10.51.1.131:48888 
2010-08-07 23:47:09,751 DEBUG [org.jgroups.protocols.pbcast.GMS] [10.51.1.141:35666]: JoinRsp=[10.51.1.131:48888|61] [10.51.1.131:48888, 10.51.1.141:35666] [size=2] 
2010-08-07 23:47:09,752 DEBUG [org.jgroups.protocols.pbcast.GMS] new_view=[10.51.1.131:48888|61] [10.51.1.131:48888, 10.51.1.141:35666] 
... 
2010-08-07 23:47:10,047 INFO [org.jboss.ha.framework.interfaces.HAPartition.DefaultPartition] Number of cluster members: 2 
2010-08-07 23:47:10,047 INFO [org.jboss.ha.framework.interfaces.HAPartition.DefaultPartition] Other members: 1 
... 
2010-08-07 23:47:20,034 DEBUG [org.jgroups.protocols.FD] sending are-you-alive msg to 10.51.1.131:48888 (own address=10.51.1.141:35666) 
2010-08-07 23:47:30,037 DEBUG [org.jgroups.protocols.FD] sending are-you-alive msg to 10.51.1.131:48888 (own address=10.51.1.141:35666) 
2010-08-07 23:47:30,038 DEBUG [org.jgroups.protocols.FD] heartbeat missing from 10.51.1.131:48888 (number=0) 
2010-08-07 23:47:40,040 DEBUG [org.jgroups.protocols.FD] sending are-you-alive msg to 10.51.1.131:48888 (own address=10.51.1.141:35666) 
2010-08-07 23:47:40,040 DEBUG [org.jgroups.protocols.FD] heartbeat missing from 10.51.1.131:48888 (number=1) 
... 
2010-08-07 23:48:19,758 WARN [org.jgroups.protocols.FD] I was suspected by 10.51.1.131:48888; ignoring the SUSPECT message and sending back a HEARTBEAT_ACK 
2010-08-07 23:48:20,054 DEBUG [org.jgroups.protocols.FD] sending are-you-alive msg to 10.51.1.131:48888 (own address=10.51.1.141:35666) 
2010-08-07 23:48:20,055 DEBUG [org.jgroups.protocols.FD] [10.51.1.141:35666]: received no heartbeat ack from 10.51.1.131:48888 for 6 times (60000 milliseconds), suspecting it 
2010-08-07 23:48:20,058 DEBUG [org.jgroups.protocols.FD] broadcasting SUSPECT message [suspected_mbrs=[10.51.1.131:48888]] to group 
... 
2010-08-07 23:48:21,691 DEBUG [org.jgroups.protocols.pbcast.NAKACK] removing 10.51.1.131:48888 from received_msgs (not member anymore) 
2010-08-07 23:48:21,691 INFO [org.jboss.ha.framework.server.DistributedReplicantManagerImpl.DefaultPartition] I am (127.0.0.1:1099) received membershipChanged event: 
2010-08-07 23:48:21,691 INFO [org.jboss.ha.framework.server.DistributedReplicantManagerImpl.DefaultPartition] Dead members: 0 ([]) 
2010-08-07 23:48:21,691 INFO [org.jboss.ha.framework.server.DistributedReplicantManagerImpl.DefaultPartition] New Members : 0 ([]) 
2010-08-07 23:48:21,691 INFO [org.jboss.ha.framework.server.DistributedReplicantManagerImpl.DefaultPartition] All Members : 1 ([127.0.0.1:1099]) 
... 
2010-08-07 23:49:59,793 WARN [org.jgroups.protocols.FD] I was suspected by 10.51.1.131:48888; ignoring the SUSPECT message and sending back a HEARTBEAT_ACK 
2010-08-07 23:50:09,796 WARN [org.jgroups.protocols.FD] I was suspected by 10.51.1.131:48888; ignoring the SUSPECT message and sending back a HEARTBEAT_ACK 
2010-08-07 23:50:19,144 DEBUG [org.jgroups.protocols.FD] Recevied Ack. is invalid (was from: 10.51.1.131:48888), 
2010-08-07 23:50:19,144 DEBUG [org.jgroups.protocols.FD] Recevied Ack. is invalid (was from: 10.51.1.131:48888), 
... 
2010-08-07 23:50:21,791 DEBUG [org.jgroups.protocols.pbcast.GMS] new=[10.51.1.131:48902], suspected=[], leaving=[], new view: [10.51.1.141:35666|63] [10.51.1.141:35666, 10.51.1.131:48902] 
... 
2010-08-07 23:50:21,792 DEBUG [org.jgroups.protocols.pbcast.GMS] view=[10.51.1.141:35666|63] [10.51.1.141:35666, 10.51.1.131:48902] 
2010-08-07 23:50:21,792 DEBUG [org.jgroups.protocols.pbcast.GMS] [local_addr=10.51.1.141:35666] view is [10.51.1.141:35666|63] [10.51.1.141:35666, 10.51.1.131:48902] 
2010-08-07 23:50:21,822 INFO [org.jboss.ha.framework.interfaces.HAPartition.lifecycle.DefaultPartition] New cluster view for partition DefaultPartition (id: 63, delta: 1) : [127.0.0.1:1099, 127.0.0.1:1099] 
2010-08-07 23:50:21,822 DEBUG [org.jboss.ha.framework.interfaces.HAPartition.DefaultPartition] membership changed from 1 to 2 
... 
2010-08-07 23:50:31,825 DEBUG [org.jgroups.protocols.FD] sending are-you-alive msg to 10.51.1.131:48902 (own address=10.51.1.141:35666) 
2010-08-07 23:50:31,832 DEBUG [org.jgroups.protocols.FD] received ack from 10.51.1.131:48902

Mais je suis à une perte de comprendre pourquoi les contrôles FD échouent la première fois ronde; et bien qu'il semble finalement se regrouper avec l'autre nœud, l'échec initial semble être suffisant pour gâcher le déploiement quand il essaie de partager l'état de l'entité, et ainsi l'empêcher de fonctionner réellement d'une manière utile.

Si quelqu'un peut faire la lumière sur cela, je serai énormément reconnaissant!

Source

2010-08-07 minamikuni

C'est un problème embarrassant, pour être sûr. Je suppose qu'il y a une raison pour laquelle vous utilisez JBoss 4.2.2 & une configuration de serveur personnalisée, mais pouvez-vous le recréer avec JBoss 4.2.3 (qui incluait des changements de jgroups) et/ou la configuration "tout"? – pra

La configuration personnalisée est conçue pour être un compromis entre 'default' et 'all' - c'est-à-dire 'all' sans les bits que nous n'utilisons pas. Il faudra un peu de travail pour pouvoir essayer des configurations alternatives (parce que je ne peux pas jouer librement avec le nœud existant, donc je devrai en ajouter un troisième), mais je verrai si je peux essayer ces - merci pour le suggestion. – minamikuni

Je suggère fortement de réduire la configuration 'all' plutôt que d'ajouter des éléments à la configuration' default'. Il est trop facile de manquer un élément critique qui ne semble pas utile. – skaffman

Je pense qu'avant de passer à JBoss 4.2.3 (ce qui est probablement un bon endroit pour être éventuellement) ou la construction d'une nouvelle configuration (je suis d'accord avec la taille @skaffman au sujet d'être plus facile que l'ajout), vous pouvez essayer ce qui suit:

Sur 10.51.1.131:

run.sh -c default -b 10.51.1.131 -Djgroups.bind_addr=10.51.1.131

sur 10.51.1.141:

run.sh -c default -b 10.51.1.141 -Djgroups.bind_addr=10.51.1.141

Selon tous les documents que je peux trouver sur ce point, le paramètre -b est le SERV Par exemple, l'adresse de liaison d'instance, et le fait qu'elles soient différentes peut créer une schizophrénie significative pour JGroups. J'avais un environnement en cluster à quatre serveurs qui fonctionnait avec succès depuis plus de trois ans, et cela faisait partie de la configuration recommandée de RH/JBoss (nous avions un contrat de support, et nous avons reçu l'aide de Bela Ban).

Source

2010-12-02 02:45:17 mlschechter

Les nœuds JBoss 4.2.2 commencent à se grouper puis se suspectent mutuellement

Répondre

Questions connexes