[ English | русский | Deutsch | Indonesia | English (United Kingdom) ]

Обслуживание кластера RabbitMQ

Брокер сообщений RabbitMQ — это логическая группировка одного или нескольких узлов Erlang, на каждом из которых запущено приложение RabbitMQ и используются общие пользователи, виртуальные хосты, очереди, обмены, привязки и параметры времени выполнения. Набор узлов часто называют кластером. Для получения дополнительной информации о кластеризации RabbitMQ см. Кластер RabbitMQ.

В OpenStack-Ansible все данные и состояния, необходимые для работы кластера RabbitMQ, реплицируются на все узлы, включая очереди сообщений, обеспечивая высокую доступность. Узлы RabbitMQ обращаются друг к другу с помощью доменных имен. Имена хостов всех членов кластера должны быть доступны со всех узлов кластера, а также с любых машин, на которых могут использоваться инструменты CLI, связанные с RabbitMQ. Существуют альтернативы, которые могут работать в более строгих окружениях. Более подробную информацию об этой настройке см. в разделе Конфигурация Inet.

Создать кластер RabbitMQ

Кластеры RabbitMQ могут быть сформированы двумя способами:

  • Вручную с помощью rabbitmqctl

  • Декларативно (список узлов кластера в конфигурации с плагинами rabbitmq-autocluster или rabbitmq-clusterer)

Примечание

Брокеры RabbitMQ могут допускать отказ отдельных узлов в кластере. Эти узлы могут запускаться и останавливаться по желанию, пока они имеют возможность достичь ранее известных членов в момент отключения.

Существует два типа узлов, которые вы можете настроить: дисковые и RAM-узлы. Чаще всего вы будете использовать свои узлы как дисковые узлы (предпочтительно). В то время как RAM-узлы — это скорее специальная конфигурация, используемая в кластерах высокой производительности.

Узлы RabbitMQ и инструменты CLI используют erlang cookie для определения того, есть ли у них разрешение на общение. Файл cookie представляет собой строку буквенно-цифровых символов и может быть настолько коротким или длинным, насколько вам нужно.

Примечание

Значение cookie-файла является общим секретом и должно быть защищено и сохранено в тайне.

Расположение cookie по умолчанию в средах *nix - /var/lib/rabbitmq/.erlang.cookie или $HOME/.erlang.cookie.

Совет

Если при устранении неполадок вы заметили, что один узел отказывается присоединяться к кластеру, определенно стоит проверить, соответствует ли куки-файл erlang другим узлам. Если куки-файл настроен неправильно (например, не идентичен), RabbitMQ будет регистрировать ошибки, такие как «Попытка подключения с запрещенного узла» и «Не удалось выполнить автокластеризацию». Подробнее см. в разделе кластеризация <https://www.rabbitmq.com/clustering.html>.

Чтобы сформировать кластер RabbitMQ, вы начинаете с того, что берете независимых брокеров RabbitMQ и перенастраиваете эти узлы в конфигурацию кластера.

Используя пример с тремя узлами, вы сообщаете узлам 2 и 3 о необходимости присоединиться к кластеру первого узла.

  1. Авторизуйтесь во 2-й и 3-й узлы и остановите приложение RabbitMQ.

  2. Присоединитесь к кластеру, затем перезапустите приложение:

    rabbit2$ rabbitmqctl stop_app
Stopping node rabbit@rabbit2 ...done.
rabbit2$ rabbitmqctl join_cluster rabbit@rabbit1
Clustering node rabbit@rabbit2 with [rabbit@rabbit1] ...done.
rabbit2$ rabbitmqctl start_app
Starting node rabbit@rabbit2 ...done.

Проверьте состояние кластера RabbitMQ

  1. Запустите rabbitmqctl cluster_status с любого узла.

Вы увидите, что rabbit1 и rabbit2 оба работают, как и прежде.

Разница заключается в том, что в разделе состояния кластера в выводе оба узла теперь сгруппированы вместе:

rabbit1$ rabbitmqctl cluster_status
Cluster status of node rabbit@rabbit1 ...
[{nodes,[{disc,[rabbit@rabbit1,rabbit@rabbit2]}]},
{running_nodes,[rabbit@rabbit2,rabbit@rabbit1]}]
...done.

Чтобы добавить третий узел RabbitMQ в кластер, повторите описанный выше процесс, остановив приложение RabbitMQ на третьем узле.

  1. Присоедините к кластеру и перезапустите приложение на третьем узле.

  2. Выполните rabbitmq cluster_status, чтобы увидеть все 3 узла:

    rabbit1$ rabbitmqctl cluster_status
Cluster status of node rabbit@rabbit1 ...
[{nodes,[{disc,[rabbit@rabbit1,rabbit@rabbit2,rabbit@rabbit3]}]},
 {running_nodes,[rabbit@rabbit3,rabbit@rabbit2,rabbit@rabbit1]}]
...done.

Остановка и перезапуск кластера RabbitMQ

Чтобы остановить и запустить кластер, помните о порядке, в котором вы отключаете узлы. Последний узел, который вы останавливаете, должен быть первым узлом, который вы запускаете. Этот узел является master.

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

RabbitMQ и Mnesia

Mnesia — это распределенная база данных, которую RabbitMQ использует для хранения информации о пользователях, обменах, очередях и привязках. Однако сообщения не хранятся в базе данных.

Более подробную информацию о Mnesia можно найти в Обзоре Mnesia.

Чтобы просмотреть расположение важных файлов RabbitMQ, см. раздел Расположение файлов.

Восстановление разделенного кластера RabbitMQ для одного узла

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

Если хост по-прежнему отображается как часть кластера, но не запущен, выполните:

# rabbitmqctl start_app

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

  1. Убедитесь, что RabbitMQ не запущен на узле:

    # rabbitmqctl stop_app

  2. На втором узле RabbitMQ выполните:

    # rabbitmqctl forget_cluster_node rabbit@rabbit1

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

Важно

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

rabbit1$ rabbitmqctl start_app
Starting node rabbit@rabbit1 ...

Error: inconsistent_cluster: Node rabbit@rabbit1 thinks it's clustered
       with node rabbit@rabbit2, but rabbit@rabbit2 disagrees

rabbit1$ rabbitmqctl reset
Resetting node rabbit@rabbit1 ...done.
rabbit1$ rabbitmqctl start_app
Starting node rabbit@mcnulty ...
...done.

Восстановление разбитого на разделы кластера RabbitMQ для многоузлового кластера

Те же концепции применимы к кластеру с несколькими узлами, которые существуют в кластере с одним узлом. Единственное отличие заключается в том, что различные узлы фактически будут работать на разных хостах. Ключевые моменты, которые следует иметь в виду при работе с кластером с несколькими узлами:

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

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

  • Если все узлы кластера останавливаются одновременно и неконтролируемо (например, из-за отключения питания), вы можете оказаться в ситуации, когда все узлы думают, что какой-то другой узел остановился после них. В этом случае вы можете использовать команду force_boot на одном узле, чтобы снова сделать его загружаемым.

Более подробную информацию можно найти на странице руководства rabbitmqctl.

Миграция между очередями HA и Quorum

В выпуске 2024.1 (Caracal) OpenStack-Ansible переходит на использование RabbitMQ Quorum Queues по умолчанию вместо устаревших классических очередей High Availability. Миграция на Quorum Queues может быть выполнена во время обновления, но может привести к длительному простою плоскости управления, поскольку это требует перезапуска всех служб OpenStack с новой конфигурацией.

Чтобы ускорить миграцию, можно запустить следующие сценарии для миграции в или из Quorum Queues, пропуская установку пакетов и другие задачи конфигурации. Эти задачи доступны с версии 2024.1 и далее.

$ openstack-ansible openstack.osa.rabbitmq_server --tags rabbitmq-config
$ openstack-ansible openstack.osa.setup_openstack --tags common-mq,post-install

In order to take advantage of these steps, we suggest setting oslomsg_rabbit_quorum_queues to false before upgrading to 2024.1. Then, once you have upgraded, set oslomsg_rabbit_quorum_queues back to the default of true and run the playbooks above.