Шаги по созданию существующей службы JNDI HornetQ как HA?

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. Тем не менее, чтобы возобновить работу в качестве мастера HornetQ, HornetQa_slave должен связаться с процессом JNDI, работающим на сервере A (я полагаю, для репликации сообщений). Поскольку хост A сам по себе не работает, HornetQa_slave, работающий на E, не может связаться с JNDI на A и, следовательно, не может возобновить работу как главный процесс.

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

Ответ 1

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

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

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

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

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

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

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