[ 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.
Совет
While troubleshooting, if you notice one node is refusing to join the cluster, it is definitely worth checking if the erlang cookie matches the other nodes. When the cookie is misconfigured (for example, not identical), RabbitMQ will log errors such as «Connection attempt from disallowed node» and «Could not auto-cluster». See clustering for more information.
Чтобы сформировать кластер RabbitMQ, вы начинаете с того, что берете независимых брокеров RabbitMQ и перенастраиваете эти узлы в конфигурацию кластера.
Используя пример с тремя узлами, вы сообщаете узлам 2 и 3 о необходимости присоединиться к кластеру первого узла.
Авторизуйтесь во 2-й и 3-й узлы и остановите приложение RabbitMQ.
Присоединитесь к кластеру, затем перезапустите приложение:
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¶
Запустите
rabbitmqctl cluster_statusс любого узла.
Вы увидите, что rabbit1 и rabbit2 оба работают, как и прежде.
The difference is that the cluster status section of the output, both nodes are now grouped together:
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 на третьем узле.
Присоедините к кластеру и перезапустите приложение на третьем узле.
Выполните
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
Однако, вы можете заметить некоторые проблемы с вашим приложением, поскольку клиенты могут пытаться отправлять сообщения на недоступный узел. Чтобы исправить это, уберите узел из кластера, выполнив следующее:
Убедитесь, что RabbitMQ не запущен на узле:
# rabbitmqctl stop_app
На втором узле 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.
Repair a partitioned RabbitMQ cluster for a multi-node cluster¶
Те же концепции применимы к кластеру с несколькими узлами, которые существуют в кластере с одним узлом. Единственное отличие заключается в том, что различные узлы фактически будут работать на разных хостах. Ключевые моменты, которые следует иметь в виду при работе с кластером с несколькими узлами:
When the entire cluster is brought down, the last node to go down must be the first node to be brought online. If this does not happen, the nodes will wait 30 seconds for the last disc node to come back online, and fail afterwards.
Если последний отключившийся узел не может быть восстановлен, его можно удалить из кластера с помощью команды forget_cluster_node.
If all cluster nodes stop in a simultaneous and uncontrolled manner, (for example, with a power cut) you can be left with a situation in which all nodes think that some other node stopped after them. In this case you can use the force_boot command on one node to make it bootable again.
Consult the rabbitmqctl manpage for more information.
Миграция между очередями 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
Чтобы воспользоваться этими шагами, мы предлагаем установить oslomsg_rabbit_quorum_queues на False перед обновлением до 2024.1. Затем, после обновления, установите oslomsg_rabbit_quorum_queues обратно на значение по умолчанию True и запустите приведенные выше сценарии.
