JBoss 4.2.2 노드가 클러스터로 시작한 다음 서로 의심됩니다.

Question

기존 Red Hat 서버에서 JBoss 4.2.2로 실행되는 웹 사이트가 있습니다. 두 번째 서버를 설정하여 클러스터 된 쌍 (로드 균형 조정 됨)을 갖도록 설정합니다. 그러나, 나는 그들을 클러스터 성공적으로 얻을 수 없습니다. 내가 클러스터링 지원을 포함 그것의 수정 된 버전을 사용하고 있습니다 -

run.sh -c default -b 0.0.0.0 

(나는 상자에서 클러스터링을 지원하지 않는 '기본'구성을 알고

기존 서버와 제이보스를 시작 .) 동일한 명령으로 두 번째 JBoss 인스턴스를 시작하면 첫 번째 노드를 알지 않고 자체 클러스터를 구성합니다. 둘 다 동일한 파티션 이름과 멀티 캐스트 주소 및 포트를 사용합니다.

컴퓨터가 멀티 캐스트를 통해 통신 할 수 있는지 확인하기 위해 McastReceiverTest 및 McastSenderTest 프로그램을 시도했습니다. 그들은 할 수 있었다.

그런 다음 http://docs.jboss.org/jbossas/docs/Clustering_Guide/beta422/html/ch07s07s07.html에있는 정보에 주목하여 JGroups가 모든 인터페이스에 바인드 할 수없고 대신 기본 인터페이스에 바인딩합니다. 아마도 127.0.0.1에 바인딩되어 메시지를받지 못했을 것입니다. 그래서 그 대신 나는 내부 IP를 사용하기 위해 JGroups에게 인스턴스를 설정합니다

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 

(0.131는 0.141 새로운 서버로, 기존 서버입니다).

이제 노드는 서로를 인식하고 클러스터를 형성합니다.

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) 

을 ... 그리고 된 .ear 배포에 실패하십시오 된 .ear를 배포하는 동안 그러나, 서버 로그이 말했다.

ejb3-entity-cache-service.xml의 CacheMode를 REPL_SYNC에서 LOCAL로 변경하면 엔티티 캐시 복제가 발생하지 않지만 .ear가 올바르게 배포됩니다. 그러나 로그에는 여전히 동일한 문제의 흥미로운 징후가 표시됩니다.

• 먼저 새 노드가 기존의 것을 발견하고 클러스터
• 다음 FD의 검사가 실패를 형성하고, 실패의 일련 번호 다음에 새로운 노드가 클러스터으로부터 분할 : 같은

  은 같습니다 자신의 클러스터 하나를 형성합니다.

• 그런 다음 다시 클러스터되고 FD가 작동하는지 확인합니다. 로그 파일의

관련 비트 :

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 

하지만이 FD 검사가 라운드 처음으로 실패 이유를 이해하기 위해 손실에 있어요; 결국 다른 노드와 클러스터되는 것처럼 보이지만 초기 실패는 엔티티 상태를 공유하려고 할 때 배포를 엉망으로 만들어 실제로 유용한 방식으로 작동하지 못하게합니다.

누구든지이 부분을 밝힐 수 있다면 나는 대단히 감사 할 것입니다!

Answer 1

JBoss 4.2로 옮기기 전에 생각했습니다.

10.51.1.131에 :하거나 새 구성을 구축 (아마 좋은 결국이 될 수있는 장소입니다) (3) (내가 추가하는 것보다 더 쉽게되는 가지 치기에 대한 @skaffman 동의), 다음 시도 할 수도 있습니다

10.51.1.141에

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

:

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

나는이에서 찾을 수있는 모든 문서에 따르면은 -b 매개 변수는 SERV입니다 어 인스턴스 바인드 주소를 가지고 있고, 그것들을 다르게하는 것이 JGroups에 대한 중요한 정신 분열증을 일으킬 수 있습니다. 3 년 넘게 성공적으로 작동하는 4 서버 클러스터 환경이 있었으며 이는 RH/JBoss (우리는 지원 계약이 있었고 Bela Ban의 도움을 받음)의 권장 구성의 일부였습니다.