Узлы JBoss 4.2.2 начинают кластеризоваться, а затем подозревают друг друга

У меня есть веб-сайт, работающий с JBoss 4.2.2 на существующем сервере Red Hat. Я настраиваю второй сервер, чтобы получить кластерную пару (которая затем будет сбалансирована по нагрузке). Однако я не могу заставить их успешно кластеризоваться.

Существующий сервер запускает JBoss с:

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 и, таким образом, не получал сообщения. Поэтому вместо этого я установил экземпляры, чтобы указать JGroups использовать внутренние IP-адреса:

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 - существующий сервер, .141 - новый сервер).

Теперь узлы замечают друг друга и сначала образуют кластер. Однако при попытке развернуть .ear журнал сервера сообщает следующее:

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 не может развернуться.

Если я изменю CacheMode в ejb3-entity-cache-service.xml с 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 терпят неудачу в первый раз; и хотя в конечном итоге кажется, что он объединяется в кластер с другим узлом, первоначального сбоя кажется достаточно, чтобы испортить развертывание, когда он пытается поделиться состоянием объекта, и тем самым помешать ему действительно работать полезным способом.

Если кто-нибудь сможет пролить свет на это, я буду безмерно благодарен!


cluster-computing jboss jgroups
person minamikuni    schedule 07.08.2010    source источник
comment
Безусловно, это непростой вопрос. Я предполагаю, что есть причина, по которой вы используете JBoss 4.2.2 и настраиваемую конфигурацию сервера, но можете ли вы воссоздать ее с помощью JBoss 4.2.3 (который включал некоторые изменения jgroups) и / или всей конфигурации?   -  person pra    schedule 08.08.2010
comment
Настроенная конфигурация предназначена для компромисса между «по умолчанию» и «все», то есть «все» без битов, которые мы не используем. Потребуется некоторая работа, чтобы попробовать альтернативные конфигурации (потому что я не могу свободно связываться с существующим узлом, поэтому мне нужно добавить третий), но я посмотрю, смогу ли я попробовать их - спасибо за предположение.   -  person minamikuni    schedule 08.08.2010
comment
Я настоятельно рекомендую сократить конфигурацию all, а не добавлять что-то в конфигурацию default. Слишком легко пропустить какой-то важный компонент, который не выглядит полезным.   -  person skaffman    schedule 09.08.2010

Ответы (1)


arrow_upward
2
arrow_downward

Я думаю, что прежде чем вы перейдете к JBoss 4.2.3 (который, вероятно, в конечном итоге станет хорошим местом) или создадите новую конфигурацию (я согласен с @skaffman, что обрезка проще, чем добавление), вы можете попробовать следующее:

On 10.51.1.131:

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

On 10.51.1.141:

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

Согласно всей документации, которую я могу найти по этому поводу, параметр -b - это адрес привязки экземпляра сервера, и их различие может вызвать серьезную шизофрению для JGroups. У меня была кластерная среда с четырьмя серверами, успешно работавшая более трех лет, и это было частью рекомендуемой конфигурации от RH / JBoss (у нас был контракт на поддержку, и мы получили помощь от Бела Бана).

person mlschechter    schedule 02.12.2010