Коротко. Справка RX 25.2 строит кластер RabbitMQ на 3.13.7 с политикой ha-all, а в 4.0 зеркалирование удалено, и 4.x такую политику отклоняет. Варианты: остаться на 3.13, один узел 4.x или кворумные очереди после проверки на стенде, потому что их поддержка в справке не описана. Перед обновлением на 4.x убрать политики ha-* и включить флаги.

Администратор собирает кластер RabbitMQ для Directum RX по справке, доходит до шага с политикой зеркалирования и получает отказ брокера. Или обновляет уже работающий кластер на свежую версию RabbitMQ, а инструкция по-прежнему велит задать ту же политику. Причина не в опечатке: в RabbitMQ 4.0 функцию, на которую опирается эта политика, удалили. Разбираем, что именно говорит справка, что поменялось в брокере и какие варианты остаются.

Симптом

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

$ rabbitmqctl set_policy -p drx_host ha-all "" '{"ha-mode":"all"}'
...
[{<<"ha-mode">>,<<"all">>}] are not recognised policy settings

Так это выглядит на RabbitMQ 4.4.0 (проверено в контейнере). На 3.13 та же команда выполняется, но брокер пишет предупреждения об устаревшей функции. Разбор самой ошибки есть в справочнике.

Второй вариант того же симптома тише. Кластер на 3.13 с политикой ha-all обновили до 4.x, ошибок нет, но очереди больше не реплицируются. Узнают об этом при первой остановке узла: часть очередей недоступна, пока узел не вернётся.

Почему так

Что говорит справка RX. В справке Directum RX 25.2 статья «Настройка кластера RabbitMQ» для Linux (admin_cluster_rmq.htm) описывает три узла, ставит Erlang 26.2.3 и RabbitMQ 3.13.7 из пакетов, а последним шагом задаёт на виртуальный хост RX политику ha-all с пустым шаблоном (то есть на все очереди) и параметрами ha-mode: all, ha-sync-mode: automatic. Смысл шага по справке: очереди постоянно реплицируются между узлами, а при подключении нового узла репликация запускается сама.

При этом в той же справке поставляется уже RabbitMQ 4.0. Для Windows в дистрибутиве лежит установщик rabbitmq-server-4.0.6 с Erlang OTP 27.2.4 (inst_ust_rabbitmq.htm). Для Linux пример настройки Directum Launcher указывает образ rabbitmq:4.0-management-alpine и упоминает обновление брокера с 3.7, 3.11 и 3.12 на 4.0 (inst_ust_rabbitmq_linux_dl.htm). Получается, что инструкция по кластеру написана под 3.13, а брокер из поставки уже 4.0, и на нём шаг с политикой не выполнится.

Список поддерживаемых версий RabbitMQ в самой справке не приведён: она ссылается на отдельный документ «Типовые требования к аппаратному и программному обеспечению».

Что поменялось в RabbitMQ. Зеркалирование классических очередей объявили устаревшим в 3.9, а в 4.0 удалили совсем. В примечаниях к выпуску 4.0 сказано, что классические очереди остались, но только без репликации, с одной копией. Ключи ha-mode, ha-sync-mode, ha-params и остальные ha-* брокер 4.x больше не знает: новую политику с ними он отклоняет, а у политик, перенесённых при обновлении, эта часть просто перестаёт действовать. Реплицируемые очереди в 4.x это кворумные очереди и потоки (streams).

Чего справка не говорит. Про кворумные очереди для сервисов RX в справке 25.2 ничего нет: ни того, что RX с ними работает, ни того, какой тип очереди объявляют сервисы. Значит, переход на них сейчас не описанная вендором настройка, а ваша проверка.

Диагностика

Сначала понять, какой у вас брокер и что на нём уже задано:

# версия брокера на каждом узле
rabbitmqctl version

# политики в виртуальном хосте RX
rabbitmqctl list_policies -p <vhost>

# типы очередей: classic, quorum, stream
rabbitmqctl list_queues -p <vhost> name type durable auto_delete exclusive

# флаги функций: перед обновлением все стабильные должны быть enabled
rabbitmqctl list_feature_flags name state

На 3.13 есть отдельные проверки на политики зеркалирования:

rabbitmq-diagnostics check_if_cluster_has_classic_queue_mirroring_policy
rabbitmq-diagnostics list_policies_with_classic_queue_mirroring
Что видим Что это значит Что дальше
версия 4.x, set_policy с ha-mode отклонена зеркалирования нет выбрать вариант ниже
версия 4.x, политика ha-all в списке есть перенесена с 3.13, не действует удалить, решить вопрос репликации
версия 3.13, политика ha-all есть зеркалирование работает перед обновлением на 4.x убрать политику
флаги в состоянии disabled обновление может не пройти включить до обновления

Что сделать

Вариантов три, выбор зависит от того, зачем вам кластер.

1. Остаться на 3.13.x. Если кластер нужен именно в том виде, как в справке, это версия, под которую написана инструкция (3.13.7). Сверьте её с типовыми требованиями к ПО для вашей версии RX. Это решение на время: 3.13 последняя линия с зеркалированием, и его возвращать не будут. Переход стоит планировать заранее, а не в день, когда понадобится новая версия брокера.

2. Один узел 4.x. Так брокер ставится в обычной установке через Directum Launcher. Отказоустойчивость тогда обеспечивают на уровне виртуальной машины и резервных копий. Посчитать память, диск и пороги для такого узла можно в калькуляторе настроек RabbitMQ.

3. Кластер 4.x на кворумных очередях, но после проверки. Справка этого не подтверждает, поэтому сначала тестовый стенд. Удобный способ проверить без правки чего-либо в RX: отдельный виртуальный хост с типом очередей по умолчанию quorum.

rabbitmqctl add_vhost rx_test --default-queue-type quorum

Очереди, объявленные без явного типа, на таком хосте создаются кворумными. Исключения по документации RabbitMQ: эксклюзивные, недолговечные (non-durable) и автоудаляемые очереди остаются классическими. Дальше:

  1. Подключить тестовый стенд RX к этому хосту и запустить сервисы.
  2. Посмотреть list_queues ... name type: какие очереди стали кворумными, какие остались классическими. Если сервис явно объявляет классическую очередь, хост её не переделает.
  3. Прогнать обычную работу: задачи и задания, уведомления, отчёты, индексация, фоновые процессы.
  4. Остановить один узел брокера и проверить, что сервисы переподключились к оставшимся. Для кластера справка (inst_ustanovka_rx_v_otkazoustoichivoi_arhitekture.htm) велит перечислить узлы в параметре QUEUE_ADDITIONAL_HOSTS.
  5. Читать журналы сервисов на ошибки объявления очередей и неподдерживаемых параметров. У кворумных очередей есть ограничения: нельзя эксклюзивные, нет глобального prefetch, приоритеты работают иначе.

Если в журналах появляется PRECONDITION_FAILED с x-queue-type, значит, очередь с таким именем уже существует с другим типом: на чистом тестовом хосте этого быть не должно. Результат проверки и вопрос о поддержке стоит отправить вендору до того, как переносить это на продуктив.

Обновление 3.13 → 4.x. Порядок по документации RabbitMQ:

  1. Выгрузить определения на случай отката: rabbitmqctl export_definitions /root/rmq-defs.json.
  2. Найти политики с ключами ha- и удалить их: rabbitmqctl clear_policy -p <vhost> ha-all. Если в политике были и другие параметры, задать её заново без ha-*. После этого очереди остаются классическими и живут на одном узле.
  3. Включить все стабильные флаги функций: rabbitmqctl enable_feature_flag all, затем снова list_feature_flags.
  4. Учесть путь обновления. С 3.13.x напрямую можно на 4.0, 4.1 или 4.2. На 4.3 и 4.4 только через 4.2. Кластер 3.13 с включённым Khepri обновить на месте нельзя, нужен новый кластер и перенос (blue-green).
  5. Обновлять узлы по одному и проверять очереди и подключения сервисов после каждого.

Про то, как замечать застрявшие очереди после такой работы, есть отдельная статья «RabbitMQ в Directum RX: очередь растёт, задания не двигаются».

Чего не делать

  • Подбирать другое написание политики. На 4.x зеркалирования классических очередей нет ни в каком виде, задать его другим синтаксисом не получится.
  • Считать, что после удаления политики ничего не изменилось. Классическая очередь без зеркалирования хранится на одном узле. Остановили узел, и очереди на нём недоступны до его возвращения.
  • Переводить продуктив на кворумные очереди без проверки. Поддержка этого режима для RX в справке не описана. Сначала тестовый стенд и ответ вендора.
  • Удалять очереди с сообщениями ради смены типа. Вместе с очередью удаляются задания и результаты интеграций. Тип меняют на пустых очередях при остановленных сервисах.
  • Прыгать через версию. На 4.0 обновляются только с 3.13.x, на 4.3 и 4.4 только с 4.2. Другие пути документация RabbitMQ не поддерживает.