Шаги, чтобы сделать существующий сервис JNDI HornetQ как HA?


177

TL; DR

Как выполнить настройку службы HA-JNDI с помощью настройки HornetQ? Я считаю, что документация немного разбросана. Я прочитал документы здесь, но, кажется, не иллюстрирую в деталях.

Более длинная версия:

Итак, у нас есть установка HornetQ JMS вместе с JNDI. У нас есть, скажем, 5 серверов, которые запускают мастер-экземпляр HornetQ JMS со службой JNDI на каждом. На каждом из этих 5 серверов у нас также есть подчиненный, работающий для какого-либо другого мастера HornetQ.

Проиллюстрировать:

Server A - HornetQa_master, JNDI, HornetQb_slave
Server B - HornetQb_master, JNDI, HornetQc_slave
Server C - HornetQc_master, JNDI, HornetQd_slave
Server D - HornetQd_master, JNDI, HornetQe_slave
Server E - HornetQe_master, JNDI, HornetQa_slave

Каждый из этих серверов HornetQ служит промежуточным программным обеспечением для наших различных внутренних нужд, то есть 5 серверов, 5 главных экземпляров HornetQ, 5 подчиненных экземпляров HornetQ и 5 серверов JNDI. Проблема, однако, в этой настройке состоит в том, что если хост сервера (а не только процесс, сам хост), скажем, A, выходит из строя, в идеале служба должна переключиться на HornetQ, работающий на сервере E, на котором размещено ведомое устройство HornetQ A. Тем не менее, чтобы возобновить работу в качестве мастера HornetQ, HornetQa_slave должен связаться с процессом JNDI, работающим на сервере A (я полагаю, для репликации сообщений). Так как хост A сам не работает, HornetQa_slave, работающий на E, не может связаться с JNDI на A и, следовательно, не может возобновить работу как главный процесс.

Если бы служба JNDI была высокодоступной, подчиненный процесс HornetQ мог бы возобновить работу в качестве мастера, как ожидалось. Может ли кто-нибудь любезно указать на документы или проиллюстрировать в простых шагах, как мы можем преобразовать нашу существующую установку в HA-JNDI? Что бы это ни стоило, я прочитал несколько источников , но, похоже, он не очень подробно иллюстрирует, как начать настройку HA-JNDI. Пожалуйста, дайте мне знать, если вам нужна дополнительная информация о наших текущих настройках.


8
Где работают ваши клиенты? Работают ли они на одном экземпляре AS или на другом экземпляре / JVM, или на обоих?
jjhavokk

3
@jjhavokk они будут работать на другой JVM
gravetii

4
Не могли бы вы включить HornetQ в режиме высокой доступности (активно-пассивная репликация)? Соедините это с динамическим обнаружением сервера, и вы получите надежный запасной вариант. См. Docs.jboss.org/hornetq/2.4.0.Final/docs/user-manual/html/… и docs.jboss.org/hornetq/2.4.0.Final/docs/user-manual/html/…
diginoise.

4
Какую версию jboss вы используете?
EIS

5
Я вижу, что это действительно старый, но мне интересно, если вы нашли ответ. К настоящему времени вы, вероятно, знаете, что HA требует <forward-when-no-consumer> true </ forward-when-no-consumer> для распространения сообщений, но откат к master не работает. У меня был тот же конфиг в weblogic и websphere, где восстановление после отказа работает, но не с jboss. Есть ли что-то, что нужно настроить, чтобы мастер мог синхронизировать и обновлять пропущенные сообщения, чтобы сработал правильный откат?
user1442498

Ответы:


1

С описанной архитектурой это кажется мне трудным, потому что на самом деле вам нужно перенастроить подчиненное устройство как главное, и тогда у вас будет определенный сбой.

HornetQ HA предоставляется через пару live-backup, а балансировка нагрузки - через кластер.

Если вы хотите и HA, и балансировку нагрузки, вам понадобятся две пары оперативного резервного копирования, сгруппированные вместе.

Источник: https://developer.jboss.org/thread/254232

Вы можете ссылаться на мастер не по имени хоста, а по виртуальному IP-адресу , так что в случае, если мастер не работает, вы можете перенастроить одного из подчиненных в качестве главного и запустить виртуальный ip, чтобы вам не пришлось перенастраивать остальные из рабов. (Чтобы сохранить HA, даже когда мастер не работает, вы хотите иметь 2 подчиненных, чтобы вы могли перезапустить одного из них как главного, и все равно один будет работать).

Другим способом достижения того же результата является использование DNS-имени хоста, определенного для мастера, который можно перенастроить так, чтобы он указывал на другой IP-адрес, если один хост не работает. Поскольку DNS кешируется, эти записи должны быть лучше в файле 'hosts'.

Если 3 хоста на домен HA - это слишком много оборудования, вы можете сделать это проще с виртуальными серверами без необходимости покупать больше оборудования.

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.