Pull to refresh

Как создать кластер в JBoss AS 7.1 в автономном (standalone) режиме?

Reading time 6 min
Views 10K
Original author: middlewaremagic
Статья переведена и опубликована здесь с целью дополнить ее рецептом от себя, добытом на основе личного опыта. Есть надежда, что кто-то сэкономит полдня-день гугления и массу проб и ошибок, с которыми пришлось столкнуться мне. Далее следует вольный перевод и дополнение лично от меня. Основная решаемая задача: репликация сессий пользователей на все узлы кластера. За счет репликации сессий, в случае потери одного из узлов кластера балансировщик прозрачно для пользователя может переключить его на другой узел. Работа балансировщика выходит за рамки данного перевода и будет описана в следующей статье.

JBoss AS 7 кардинально отличается от предыдущих версий JBoss, следовательно, если вы хотите создать кластер в JBoss AS 7, вам следует знать несколько вещей, чтобы не столкнуться с проблемами.

В JBoss AS 7 есть два режима: режим домена (domain) и автономный (standalone) режим, в этой статье мы расскажем о автономном режиме. В автономном режиме есть различные XML-файлы в папке конфигурации, но поддержка кластеризации включена только в standalone-ha.xml и standalone-full-ha.xml, поэтому убедитесь, что вы используете при старте один из них (см. ниже команду запуска).

Шаги для создания кластера в JBoss AS 7.1


После того как вы распаковали JBoss-как-7.1.1.Final.zip (от переводчика: проверено в версии 7.2.2), сделайте две копии папки standalone и переименуйте их, например, в standalone-node1 и standalone-node2, как показано ниже:
1 Home/user/jboss-as-7.1.1.Final/standalone-node1
2 Home/user/jboss-as-7.1.1.Final/standalone-node2
Примечание: Убедитесь, что вы сохранили оригинальную копию папки standalone для возможного будущего использования.

Теперь вы должны запустить JBoss следующей командой, чтобы он работал как узел в кластере
Node1
./standalone.sh -c standalone-ha.xml -b 10.10.10.10 -u 230.0.0.4 -Djboss.server.base.dir=../standalone-node1 -Djboss.node.name=node1 -Djboss.socket.binding.port-offset=100

Node2
./standalone.sh -c standalone-ha.xml -b 10.10.10.10 -u 230.0.0.4 -Djboss.server.base.dir=../standalone-node2 -Djboss.node.name=node2 -Djboss.socket.binding.port-offset=200

Где:
-c = файл настроек сервера, который будет использоваться
-b = предназначен для указания адреса, который прослушивает JBoss
-u = групповой (multicast) адрес. (от переводчика: предполагается, что будет использоваться при объединение узлов в кластер, но с этим могут быть проблемы, см. ниже)
-Djboss.server.base.dir = путь к папке, в которой развернут узел
-Djboss.node.name = имя узла
-Djboss.socket.binding.port-offset = смещение по портам

Примечание: Обратите внимание на следующие вещи:
— Оба узла должны иметь одинаковый широковещательный адрес
— Оба узла должны иметь разные имена узлов
— В случае запуска на одном компьютере, оба узла должны иметь разные разное смещение по портам, во избежание конфликтов. Для одного из узлов параметр -Djboss.socket.binding.port-offset можно опустить, он запустится на портах по-умолчанию. Также этот параметр можно не использовать в случае запуска на разных компьютерах.

После запуска узлов в кластерной конфигурации вы не увидите никаких изменений. Чтобы убедиться в том, что оба узла объединились в кластер, вам нужно будет развернуть веб-приложение, которое имеет тег <distributable/> в web.xml. Вы можете скачать один из наших примеров кластерного приложения здесь.

После загрузки ClusterWebApp.war вы просто должны скопировать его в (/home/user/jboss-as-7.1.1.Final/standalone-nodeX/deployments) на обоих узлах, и сразу после этого вы увидите подобные сообщения:
Лог JBoss
18:32:46,863 INFO  [stdout] (pool-13-thread-1) -------------------------------------------------------------------
18:32:46,863 INFO  [stdout] (pool-13-thread-1) GMS: address=node1/web, cluster=web, physical address=10.10.10.10:55300
18:32:46,863 INFO  [stdout] (pool-13-thread-1) -------------------------------------------------------------------
18:32:47,572 INFO  [org.infinispan.configuration.cache.EvictionConfigurationBuilder] (MSC service thread 1-8) ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be pasivated.
18:32:47,581 INFO  [org.infinispan.configuration.cache.EvictionConfigurationBuilder] (MSC service thread 1-1) ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be pasivated.
18:32:47,771 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (pool-15-thread-1) ISPN000078: Starting JGroups Channel
18:32:47,791 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (pool-15-thread-1) ISPN000094: Received new cluster view: [node1/web|1] [node1/web, node2/web]


От переводчика

Если дублировать папку JBoss целиком, а не только standalone, то можно не указывать параметр -Djboss.server.base.dir.

Несколько IP-адресов

В данной статье, и в большей части ресурсов в Сети не решается одна проблема. Многие (в т.ч. и я) при старте указывают параметр -b 0.0.0.0, который сообщает JBoss-у о том, что следует прослушивать все доступные сетевые интерфейсы. Это требуется если у вашего сервера, например, есть внешний и внутренний IP адреса, или требуется чтобы он был доступен также и по адресам по-умолчанию (например, localhost). Так вот, проблема в том, что jgroups, используемый JBoss-ом для объединения кластера отказывается работать если указан параметр -b 0.0.0.0. При старте узлов выводится сообщение:
GMS: address=node1/web, cluster=web, physical address=0.0.0.0:55200

а при попытке их объединения появляется ошибка:
[org.jgroups.protocols.UDP] (OOB-14,shared=udp) failed sending message to node2/web (117 bytes): java.lang.Exception: dest=/0.0.0.0:55500 (120 bytes), cause: java.net.BindException: Cannot assign requested address: Datagram send failed

Насколько я понял, jgroups требует конкретного IP-адреса, и отказывается работать с абстрактным 0.0.0.0, а параметр запуска -u 230.0.0.4 в этом случае просто игнорируется.

Судя по сообщениям на форумах, нет каких-либо других возможностей заставить JBoss прослушивать несколько адресов, кроме как указать параметр запуска -b 0.0.0.0. Можно в файле конфигурации standalone-ha.xml/standalone-full-ha.xml указать тэг <any-address/> для вместо <inet-address value="${jboss.bind.address:127.0.0.1}"/>, но, как оказалось его действие аналогично параметру -b 0.0.0.0, т.е. кластер отказывается объединяться.

Долгий поиск по форумам дал в конце концов простое работающее решение: следует добавить параметр -Djgroups.bind_addr=IP-адрес, чтобы указать jgroups по какому именно адресу ему объединяться. Если не уверены, осуществите запуск кластера без параметра -b 0.0.0.0, и в логе увидите какой адрес выберет jgroups, и сообщит об этом в логе. У меня под Windows я увидел следующее:
GMS: address=node1/web, cluster=web, physical address=127.0.0.1:55200

Соответственно, после этого возвращаем на место -b 0.0.0.0 и указываем в дополнение к нему -Djgroups.bind_addr=127.0.0.1.

Несколько кластеров в одной сети

Есть еще одна проблема: если кроме вашего кластера JBoss в той же сети доступны другие сервера/кластера JBoss 7, и на них развернуты distributable-приложения, то с высокой степенью вероятности "чужой" сервер подключится в ваш кластер. В предыдущих версиях проблема решалась путем указания уникального имени для каждого кластера. В 7-й версии этого нет, на форумах пишут о том, что теперь кластера следует разделять путем указания различных UDP адресов (параметр -u). Это обосновывается тем, что если идентифицировать группы серверов лишь на уровне их имен, то различные группы будут постоянно обрабатывать UDP-запросы от соседних групп, только для того, чтобы отвергнуть их. Указание же разных UPD адресов, насколько я понял, избавляет JBoss от обработки чужих запросов вообще.

UPD адрес по умолчанию для jgroups в конфигурации указан как 230.0.0.4, следует для разных групп серверов указать разные адреса групповой рассылки в параметре -u. Какой же адрес выбрать? Википедия говорит о том, что "Технология IP Multicast использует адреса с 224.0.0.0 до 239.255.255.255". При смене адреса по умолчанию, даже если он входит в этот диапазон, нет гарантии что кластер объединится, например, после указания адреса 230.0.0.5, мои два узла, работающие под Windows, перестали объединяться в кластер. Пара других адресов - 230.0.0.3 и 231.0.0.4 - прекрасно работают. Возможно, существуют средства для того, чтобы точно узнать какой адрес будет работать корректно, но я с ними незнаком, и мне, к сожалению, пришлось использовать метод "научного тыка".

С продолжением темы вы можете ознакомиться в этой статье.
Tags:
Hubs:
+8
Comments 3
Comments Comments 3

Articles