Распределение сессий JMS через балансировщик нагрузки
Очень остро стоит проблема с распределением сессий через балансировщик в случае восстановления одного из упавших узлов.
Я кратко опишу, как организовано взаимодействие двух модулей:
С одной стороны, приложение на сервере приложений WebShere (далее просто WAS)
С другой стороны, это не известно, какое приложение
Между ними - 2 сервера WebSphere MQ
Приложения WAS подключаются к WebShere MQ через балансировщик
Вторая сторона подключается непосредственно к серверам MQ (поскольку она может распределять соединения самостоятельно)
Когда возникает проблема:
- Один из серверов MQ аварийно завершает работу. На этом этапе балансировщик распределяет все сеансы на один из оставшихся серверов MQ. Второе приложение также продолжает работать только с одним сервером MQ. Нет проблем.
- Требуется некоторое время, и сервер 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> Планирование> Архитектуры на основе нескольких администраторов очередей> Планирование распределенных очередей и кластеров> Проектирование кластеров> Унифицированные кластеры> Автоматическая балансировка приложений :
Когда существует по крайней мере столько же экземпляров одного и того же приложения, сколько и администраторов очередей, единый кластер постоянно гарантирует, что к каждому администратору очередей подключен хотя бы один экземпляр приложения.