Особенности использования транспорта ibm mq для распределенных систем

tldr: не надо использовать этот транспорт.

Во время работы в одном энтерпразе пришлось столкнуться с одним интересным риском - отказ транспорта при утрате канала до одного из ЦОДов. Несмотря на то, что энтерпрайз был большим и все понимали, что нужно стараться делать софт геораспределенным, иногда забивали на некоторые детали.

Но безики и инфраструктурщики бдят. После череды сессий с инженерами и рассмотрения различных вариантов мутаций топологий пришли к выводу, что используемый на тот момент транспорт в виде imb mq 6, 7 и 8 не закрывает все риски. Даже с добавлением балансировщиков, как программных, так и аппаратных.

Обозначения и договоренности

Следует понимать, что обозреваемый ландшафт анонимизирован, так же как и квалификация коллег. Вполне возможно, что в последующих версиях транспорта озвученные проблемы уже устранены. Так же как и в последующих версиях коллег) Так что, при закупке лицензий на новье вам следует активнее пытать сейлзов как ведет себя софт в тех или иных случаях.

Так же на схемах будет встречаться такие обозначения как

Rq - управляющий запрос

Rs - ответ с деталями

Active node - в случае использовании виртуализации (в моем случае инфраструктуры - VPLEX) - активный узел

Passive node - в случае использования виртуализации - пассивный узел, не обрабатывающий сообщения, режим работы standby  

Текущая топология

Когда я заступил на службу, в большей части подсистем была довольно простая топология

В качестве меры защиты от даунтайма ЦОД2 было использование активного узла и standby узла брокера сообщения. Что было в распоряжении в лохматом 2015, то и ставили)

При моделировании аварийной работы, поток данных перестраивался на георезервное плечо.

Довольно неплохо должны были себя чувствовать потребители и поставщики, но только после утраты некоторого количества сообщений. При средней нагрузке 50 RPS и пиковой 150 RPS, при скорости миграции брокера на другое плечо 3,5 секунды, количество потраченных сообщений могло достигать 500. Неприятно, особенно с учетом того, что далеко не все потребители умели ретраить сообщения. Прямо единицы из сотки.

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

Простое усложнение

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

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

Софтовый шлюз успешно перестраивал соединения со стороны поставщика. Шлюз со стороны потребителей так же это делал бы, если бы находился на одном плече с шлюзом потребителей. Проблема была в том, что шлюзы можно было располагать или на одном плече или по диагонали. Критически важная возможность - иметь одновременно запущенные шлюзы (2x2) на обоих плечах - отсутствовала. Можно было бы вспомнить про vplex и возюкать инстансы шлюзов между цодами, но и тут были определённые ограничения. В основном экономическая.

Во первых, лицензии стоили денег. И это очень не нравилось топ менеджерам. И в какой-то момент они просто закрыли бюджетирование этой технологии всем, кроме проектов уровня mission critiacal. Всем остальным приходилось изворачиваться или подлизыавться. Со вторым у нас было плохо, пошли первым путем.

Во вторых, моделирование нагрузки показало интересную картину. IMB'вские брокеры, должны где то хранить сообщеньки. Для скорости доступа большую часть они аллоцируют в RAM. WebSphere может аккуратно рестартовать узел с сохранением данных из ram на hdd. Но это будет происходить только при софт рестарте. Что бы сообщения были прореплицированы на другой ЦОД, они должны быть в специальной области hdd, которая резервируется. Т.е. будут или очень медленно, порядка 17-25 RPS, или не безопасно. Напомню, большая часть поставщиков не умеет в ретраи. Пришлось идти дальше

Средней тяжести

При переборе альтернатив решили посмотреть на аппаратные балансировщики.

Они были тяжелее в настройке и стоили ощутимых денег. Но их хотя бы выдавали без подлизывания и кислород перекрывать не собирались. К тому же Alteon был не просто баланисировщиков aka HAproxy, это был програмно-аппаратный комплекс. Это означало, что он монтировался на 2х плечах и умел в "умный" роутинг исходя из состояния готовности плеча.

Это означало, что проблема "софтового" шлюза о недоступности или поставщиков или потребителей - решена. Одно плечо выживает, находит узлы на своей стороне и пропихивает сообщения.

Но у решения объявился ряд проблем: проблема залипшей сессии и потраченных сообщений.

С первым еще можно было работать: в случае падения одного плеча, инфраструктура как бы в курсе проблемы. И может запустить скрипт софтового рестарта адаптеров поставщиков и потребителей. Долго, печально, но возможно. Но к сожалению, надо что бы рестарт был каскадным, а не одновременным, иначе компания все же встает колом. Вкладываться в подобную автоматизацию не хотелось ни кому, ресурсов не хватало.

Так же масла в огонь подливала неприятность с протраченными сообщениями из runtime'a брокера сообщения. Напоминаю о качественном проектировании приложений и компонент при работе с сетью в энтерпрайзе

Композит

Мысленное перекапывание IT ландшафта бысто уперлось в идею совместить оба подхода.

Казалось бы: зальем проблему железом и победим ее. Но нет, mailru, все еще нет)

Моделирование сценария отказа показало, что композитный подход все еще не решает обе проблемы до конца.

Поставщик будет  ожидать ответы все еще по залипшей сессии. Только рестарт поможет сбросить сессию на узле адаптера и дотянуться до живого алтеона.

Ну и протраченный пейлоад - никак не восстановить и не отреплицировать.

Выводы

Было принято решение остановить ход мысли в этом направлении и задуматься о смене технологий.

К тому моменту все слышали про kafka, и его встроенный механизм репликации сообщений, но технологию в голом виде не готовы были выпускать в продакшн. Скорее всего по политическим причинам: непонятная ответственность за регулярное доумощнение дисковой подситсемы; малое количество внутренних корпоративных ресурсов по сопровождению; сложности с доказательством для безиков, что tls сертификаты в кафке ничем не хуже, ibm'овских, а утащить их и подменить сообщения могут все те же сопровожденцы; а так же наличие альтернативного политического курса.

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