Назад | Перейти на главную страницу

Распределение сессий JMS через балансировщик нагрузки

Очень остро стоит проблема с распределением сессий через балансировщик при восстановлении одного из упавших узлов.

Кратко опишу, как устроено взаимодействие двух модулей:

С одной стороны, приложение на сервере приложений WebShere (далее просто WAS)

С другой стороны, неизвестно, какое приложение

Между ними - 2 сервера WebSphere MQ

Приложения WAS подключаются к WebShere MQ через балансировщик

Вторая сторона подключается напрямую к серверам MQ (потому что она может сама распределять соединения)

Когда возникает проблема:

  1. Один из серверов MQ выходит из строя. На этом этапе все сеансы распределяются балансировщиком на один из оставшихся серверов MQ. Второе приложение также продолжает работать только с одним сервером MQ. Нет проблем.
  2. Это займет некоторое время, и MQ-сервер будет восстановлен для работы. Второе приложение мгновенно восстанавливает подключения ко второму серверу MQ. Балансировщик продолжает держать все сеансы на одном узле, так как этого JMS и пула соединений вполне достаточно (здесь, наверное, стоит сказать, что приложение работает только через фабрику соединений очереди и без спецификаций активации). Таким образом, серверы WAS не читают сообщения, которые приложение 2 размещает на сервере MQ, до тех пор, пока пул соединений не станет недостаточным и не откроется новый сеанс, который уже распределяется балансировщиком на второй MQ. Но этот период может быть очень длинным и 50% сообщений попадут в таймауты (приложение 2).

Отсюда вопрос.

Можно ли как-то организовать процесс так, чтобы при восстановлении второго MQ часть сессий на балансировщике либо переносилась на второй сервер MQ, либо просто генерировалась новая сессия (мгновенно) со стороны WAS (для Например, если мы начнем использовать спецификацию активации, возможно)?

Если приложение в левой части диаграммы обслуживает только запросы из приложения справа, в текущем IBM MQ v9.1 LTS и ниже одним из вариантов является развертывание приложения дважды на каждом сервере WAS, где каждый экземпляр настроен для подключения напрямую к одному администратору очередей IBM MQ, минуя балансировщик нагрузки. Таким образом, когда один сервер MQ выходит из строя, каждый сервер приложений Websphere по-прежнему имеет подключения от одного экземпляра приложения к другому серверу MQ для обслуживания запросов, идущих к доступному серверу MQ, а когда отказавший сервер MQ возвращается к работе, второй экземпляр приложения на каждом Сервер приложений Websphere повторно подключится к этому администратору очередей и будет обслуживать соединения.

В MQ v9.1 CD (непрерывная доставка) IBM добавляет новую функцию, называемую единообразными кластерами, в которых администратор очередей и клиент работают вместе, чтобы поддерживать балансировку нагрузки соединений между доступными администраторами очередей. Благодаря этой новой функции при восстановлении 2-го администратора очередей 1-й администратор очередей уведомит половину подключенных клиентов об отключении и повторном подключении ко 2-му администратору очередей.

См. Страницу Центра знаний IBM IBM MQ 9.1.x> IBM MQ> Планирование> Архитектуры на основе нескольких администраторов очередей> Планирование распределенных очередей и кластеров> Проектирование кластеров> Унифицированные кластеры> Автоматическая балансировка приложений:

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