Кластер RabbitMQ на Ubuntu 20.04

Диаграмма кластера RabbitMQ

Что такое RabbitMQ

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

Краткое определение термина: брокер сообщений — сервер, который принимает, хранит и пересылает сообщения между приложениями.

Требования

Три сервера с Ubuntu 20.04 (можно виртуальные инстансы).
На каждом сервере настроен root-доступ или пользователь с sudo.
Межузловая связность по IP и доступ по SSH.
Базовые знания командной строки Linux.

Общая архитектура и идеи

Один узел будет выступать в роли начального кластерного узла (node1). Остальные узлы присоединяются к нему.
Для кластера важно, чтобы файл /var/lib/rabbitmq/.erlang.cookie был одинаковым на всех узлах — это ключ доверия между узлами Erlang.
По умолчанию очереди привязываются к одному узлу. Для отказоустойчивости используются политики зеркалирования (ha-политики).

Подготовка узлов

Обновите пакеты на каждом сервере:

apt-get update -y
apt-get upgrade -y

Добавьте записи в /etc/hosts на каждом узле, чтобы имена node1/node2/node3 резолвились в IP:

nano /etc/hosts

Добавьте строки (пример):

192.168.0.10 node1
192.168.0.11 node2
192.168.0.12 node3

Сохраните файл и проверьте пинг по имени:

ping -c 2 node2

Важно: при использовании облачных провайдеров может потребоваться работа с конфигурацией сетевого межсетевого экрана (security groups). Убедитесь, что порты 22(SSH), 25672(cluster), 5672(AMQP) и 15672(HTTP management) доступны между узлами и с вашей рабочей станции, если нужно.

Установка RabbitMQ

Установите пакет RabbitMQ на каждом узле:

apt-get install rabbitmq-server -y

Запустите и включите сервис при старте системы:

systemctl start rabbitmq-server
systemctl enable rabbitmq-server

Проверьте статус:

systemctl status rabbitmq-server

Ожидаемый результат: сервис active (running). Если нет, просмотрите логи:

journalctl -u rabbitmq-server -b --no-pager | tail -n 80

Включение веб-менеджера

Менеджер RabbitMQ предоставляет HTTP-интерфейс для мониторинга и управления. Он слушает порт 15672.

На каждом узле включите плагин менеджера:

rabbitmq-plugins enable rabbitmq_management

Перезапустите сервис:

systemctl restart rabbitmq-server

Проверьте, что порт слушается (на примере netstat):

netstat -tunelp | grep 15672

Если netstat отсутствует, установите пакет net-tools или используйте ss:

ss -tunelp | grep 15672

Настройка кластера RabbitMQ

Ключевая часть: сделать файл .erlang.cookie одинаковым на всех узлах.

На node1 выполните:

scp /var/lib/rabbitmq/.erlang.cookie [email protected]:/var/lib/rabbitmq/
scp /var/lib/rabbitmq/.erlang.cookie [email protected]:/var/lib/rabbitmq/

Затем на node2 и node3 выполните перезапуск и остановку приложения перед присоединением:

systemctl restart rabbitmq-server
rabbitmqctl stop_app

На node2 присоединитесь к node1:

rabbitmqctl join_cluster rabbit@node1
rabbitmqctl start_app

Аналогично на node3:

rabbitmqctl join_cluster rabbit@node1
rabbitmqctl start_app

Проверьте статус кластера на node1:

rabbitmqctl cluster_status

Вы должны увидеть все три узла в секциях Disk Nodes и Running Nodes. Если видите разделение или отсутствующий узел, проверьте логи и сетевую доступность.

Настройка административного пользователя

Создайте администратора и удалите гостя. Пример создания пользователя “hitesh” с паролем “password”:

rabbitmqctl add_user hitesh password
rabbitmqctl set_user_tags hitesh administrator
rabbitmqctl set_permissions -p / hitesh ".*" ".*" ".*"
rabbitmqctl delete_user guest
rabbitmqctl list_users

Важно: используйте надёжные пароли и при необходимости интегрируйте аутентификацию через LDAP/внешние системы.

Примечание: созданный пользователь автоматически реплицируется в кластер.

Политики зеркалирования очередей

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

Зеркалирование всех очередей на все узлы:

rabbitmqctl set_policy ha-all ".*" '{"ha-mode":"all"}'

Зеркалирование очередей с префиксом two. ровно на двух узлах и синхронизация автоматически:

rabbitmqctl set_policy ha-two "^two\." '{"ha-mode":"exactly","ha-params":2,"ha-sync-mode":"automatic"}'

Зеркалирование очередей с префиксом nodes. на двух конкретных узлах node2 и node3:

rabbitmqctl set_policy ha-nodes "^nodes\." '{"ha-mode":"nodes","ha-params":["rabbit@node2","rabbit@node3"]}'

Проверьте политики:

rabbitmqctl list_policies

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

Доступ к веб-интерфейсу

Откройте в браузере адрес любого узла с портом 15672, например:

http://192.168.0.10:15672/

Страница входа RabbitMQ

Используйте учётные данные администратора. После входа вы увидите панель мониторинга:

Панель управления RabbitMQ

В разделе Admin → Policies находятся применённые политики:

Экран политик RabbitMQ

Проверка и тестирование

Минимальные тесты, которые стоит выполнить после развёртывания:

Проверка статуса кластера: rabbitmqctl cluster_status
Создание тестовой очереди и отправка сообщений с одного узла, приём с другого с проверкой зеркалирования.
Имитируйте отключение одного узла и проверьте, что сообщения всё ещё доступны (в зависимости от выбранной политики).
Нагрузочное тестирование на небольших объёмах, чтобы убедиться в отсутствии узкого места в сети или хранении.

Пример отправки/приёма через rabbitmqadmin (потребуется установить инструмент):

rabbitmqadmin publish routing_key=test payload="hello"
rabbitmqadmin get queue=test requeue=false

Безопасность и жёсткая настройка

Отключите гостевой аккаунт и создайте отдельные учётные записи с минимальными правами для сервисов.
Разрешайте доступ к management-интерфейсу только администраторам или через VPN/SSH-туннель.
Настройте firewall (ufw/iptables) так, чтобы открытые порты были доступны только там, где необходимо:

ufw allow from 192.168.0.0/24 to any port 25672
ufw allow from 192.168.0.0/24 to any port 5672
ufw allow from  to any port 15672

Включите TLS для AMQP и HTTP API, если трафик идёт по публичным сетям.
Регулярно обновляйте Erlang и RabbitMQ до поддерживаемых версий.

Резервирование и мониторинг

Для мониторинга используйте встроенные метрики management API или интеграции (Prometheus exporter, Grafana).
Настройте оповещения (CPU, память, queue_lag, disk_alarm).
Планируйте бэкапы конфигурации и экспорт политик/пользователей.

Чек-листы по ролям

Администратор инфраструктуры:

Убедиться, что сеть разрешает межузловое соединение.
Настроить firewall и VPN.
Создать файл .erlang.cookie и распространить на все узлы.

Системный инженер RabbitMQ:

Установить rabbitmq-server и плагины.
Включить rabbitmq_management.
Настроить политики зеркалирования.
Контролировать алёрты и логи.

Разработчик приложения:

Подключаться к портам AMQP 5672.
Использовать отдельные виртуальные хосты и учетные записи с минимальными правами.
Обрабатывать повторные доставки и подтверждения сообщений.

Мини-руководство по откату и восстановлению при отказе узла

Если один узел ушёл в офлайн:

Убедитесь, что остальные узлы работают: rabbitmqctl cluster_status
Если узел вернулся, проверьте синхронизацию очередей и флаг sync_status на зеркальных очередях.
Если узел потерян навсегда, удалите его из кластера с другого узла:

rabbitmqctl forget_cluster_node rabbit@<имя_узла>

Важно: прежде чем забыть узел, убедитесь, что у вас есть резервные копии данных и политики корректны.

Частые проблемы и их устранение

Проблема: узлы не видят друг друга

Проверьте /etc/hosts, DNS и сетевые правила.
Убедитесь, что .erlang.cookie идентичен и права на файл 400 (rw——-) и владелец rabbitmq.

Проблема: service не запускается

Просмотрите journalctl -u rabbitmq-server
Возможны ошибки несовместимости Erlang vs RabbitMQ — проверьте версии.

Проблема: очередь не синхронизируется

Убедитесь, что политика применена к нужному vhost и имени очереди.
Проверьте ha-sync-mode и состояние синхронизации через rabbitmqctl list_queues name node synchronised_slave_nodes

Альтернативные подходы

Одноранговый кластер с использованием распределённых очередей (quorum queues) вместо классических mirrored queues — рекомендуется для новых установок при интенсивной нагрузке.
Использовать управляемые сервисы (например cloud-managed RabbitMQ) для упрощённого управления и поддержки.
Рассмотреть альтернативы брокерам сообщений (Kafka, NATS) для других паттернов (логирование, стриминг событий).

Когда такой кластер не подходит

Если нужен только простой очередной механизм с высокими требованиями к длительному хранению и масштабированию по пропускной способности — лучше Kafka.
Если инфраструктура маломощная и нет ресурсов на межузловую сетевую синхронизацию.

Факто-бокс

Менеджер по умолчанию слушает порт 15672.
AMQP по умолчанию на порту 5672.
Erlang cookie располагается в /var/lib/rabbitmq/.erlang.cookie.
Команды управления: rabbitmqctl, rabbitmq-plugins, rabbitmqadmin.

Небольшая методология при развёртывании

Подготовьте и протестируйте сеть и SSH.
Установите RabbitMQ и убедитесь, что сервис стартует локально.
Синхронизируйте .erlang.cookie.
Объединяйте узлы по одному и проверяйте кластерный статус.
Настройте пользователей, политики и мониторинг.
Проведите smoke-тесты и отказоустойчивые сценарии.

Глоссарий в одну строку

vhost — виртуальный хост в RabbitMQ, логическая изоляция.
ha-политика — правило для зеркалирования очередей.
.erlang.cookie — файл аутентификации узлов Erlang.

Критерии приёмки

Все три узла отображаются в rabbitmqctl cluster_status.
Admin UI доступен и авторизация проходит под новым администратором.
Зеркальные очереди создаются согласно политике и синхронизируются.
При отключении одного узла сообщения доступны на оставшихся узлах (в рамках выбранной политики).

Заключение

Поздравляем — вы развернули трёхузловой кластер RabbitMQ на Ubuntu 20.04. После запуска важно наладить мониторинг, резервирование и регулярные обновления. Настройте политики зеркалирования не для всех очередей без анализа нагрузки: выбор неправильной политики может ухудшить производительность.

Важно: поддерживайте версии RabbitMQ и Erlang совместимыми и следуйте рекомендациям по безопасности при доступе к management-интерфейсу.