I nodi JBoss 4.2.2 iniziano a cluster e si sospettano a vicenda

Ho un sito Web in esecuzione con JBoss 4.2.2 su un server Red Hat esistente. Sto configurando un secondo server in modo da avere una coppia di cluster (che verrà quindi bilanciata dal carico). Tuttavia, non riesco a farli raggruppare correttamente.I nodi JBoss 4.2.2 iniziano a cluster e si sospettano a vicenda

Il server esistente si avvia JBoss con:

run.sh -c default -b 0.0.0.0

(so che la configurazione di 'default' non supporta il clustering, fuori dalla scatola - che sto utilizzando una versione modificata di esso, che include il supporto di clustering .) Quando avvio la seconda istanza di JBoss con lo stesso comando, forma il proprio cluster senza notare il primo. Entrambi usano lo stesso nome di partizione e indirizzo e porta multicast.

Ho provato i programmi McastReceiverTest e McastSenderTest per verificare che le macchine potessero comunicare su multicast; potevano.

Ho poi notato l'info at http://docs.jboss.org/jbossas/docs/Clustering_Guide/beta422/html/ch07s07s07.html, dicendo che JGroups non può legarsi a tutti le interfacce, e invece si lega l'interfaccia predefinita; quindi presumibilmente era vincolante per 127.0.0.1, e quindi non riceveva i messaggi. Così, invece ho impostato le istanze di dire JGroups di utilizzare gli indirizzi IP interni:

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 è il server esistente, .141 è il nuovo server).

I nodi ora si notano l'un l'altro e formano un cluster - in un primo momento. Tuttavia, durante il tentativo di distribuire il .ear, il log del server dice questo:

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)

... e la .ear non riesce a distribuire.

Se cambio CacheMode in ejb3-entity-cache-service.xml da REPL_SYNC a LOCAL, il file .ear si implementa correttamente, sebbene, naturalmente, la replica della cache dell'entità non avvenga. Tuttavia, il registro mostra ancora segni interessanti dello stesso problema.

Assomiglia:

prima il nuovo nodo trova quella esistente e forma un gruppo
poi i controlli FD falliscono, e dopo un certo numero di fallimenti del nuovo nodo divide fuori dal cluster e forma il proprio cluster di uno
quindi lo trova di nuovo, ri-cluster e questa volta i controlli FD funzionano.

bit rilevanti del file di registro:

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

ma io sono in perdita per capire perché i controlli FD falliscono la prima volta turno; e anche se alla fine sembra un cluster con l'altro nodo, l'errore iniziale sembra essere sufficiente a rovinare la distribuzione quando tenta di condividere lo stato dell'entità e quindi impedire che funzioni effettivamente in un modo utile.

Se qualcuno può far luce su questo sarò enormemente grato!

fonte

2010-08-07 minamikuni

Questo è un problema sconcertante, per essere sicuro. Presumo che ci sia un motivo per cui utilizzi JBoss 4.2.2 e una configurazione server personalizzata, ma puoi ricrearla con JBoss 4.2.3 (che includeva alcune modifiche a jgroups) e/o la configurazione "all"? – pra

La configurazione personalizzata è intesa come un compromesso tra "default" e "all" - cioè "tutto" senza i bit che non stiamo utilizzando. Ci vorrà del lavoro per essere in grado di provare configurazioni alternative (perché non posso confondere liberamente il nodo esistente, quindi dovrò aggiungerne un terzo), ma vedrò se posso provarle - grazie per il suggerimento. – minamikuni

Suggerisco caldamente di eliminare la configurazione 'all', piuttosto che aggiungere elementi alla configurazione' default'. È troppo facile perdere alcuni componenti critici che non sembrano utili. – skaffman

Penso che prima di passare a JBoss 4.2.3 (che è probabilmente un buon posto per essere eventualmente) o la costruzione di una nuova configurazione (sono d'accordo con @skaffman circa potatura essere più facile di aggiungere), si potrebbe desiderare di provare la seguente:

Su 10.51.1.131:

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

su 10.51.1.141:

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

Secondo tutta la documentazione che posso trovare su questo, il parametro -b è il serv L'indirizzo di bind di istanza e il fatto che siano diversi potrebbe creare una significativa schizofrenia per i JGroup. Avevo un ambiente cluster a quattro server che funzionava con successo per oltre tre anni, e faceva parte della configurazione raccomandata da RH/JBoss (avevamo un contratto di supporto e ottenuto l'aiuto da Bela Ban).

fonte

2010-12-02 02:45:17 mlschechter

I nodi JBoss 4.2.2 iniziano a cluster e si sospettano a vicenda

risposta

Problemi correlati