Пошаговое руководство по развертыванию активного-пассивного кластера RabbitMQ

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

Это руководство показывает сторону RabbitMQ для развертывания в стиле активный-пассивный. Отказоустойчивость клиентов обычно обеспечивается балансировщиком нагрузки, изменением DNS, обнаружением сервисов или виртуальным IP, управляемым вне RabbitMQ.

Предварительные требования для активного-пассивного кластера

Перед началом настройки убедитесь, что выполнены следующие предварительные требования на всех узлах кластера (Узел A - Активный, Узел B - Пассивный):

Совместимые версии программного обеспечения: Поддерживайте согласованность версий RabbitMQ Server и Erlang/OTP на всех узлах. На практике используйте одну и ту же версию RabbitMQ на каждом узле, если вы не следуете документированному пути поэтапного обновления RabbitMQ.
Сетевая доступность: Узлы должны обмениваться данными через порты AMQP, используемые клиентами, порт распределения, используемый для кластеризации, а также любые порты управления или TLS, которые вы включаете.
Разрешение имен хостов: Настройте файл /etc/hosts (или DNS) на всех узлах, чтобы каждый узел мог надежно разрешать имена хостов всех других узлов.
Согласованность файлов cookie: «Волшебный cookie» Erlang должен быть идентичным на всех узлах. Это критически важно для того, чтобы узлы доверяли друг другу при кластеризации.

Установка согласованности файлов cookie

Cookie Erlang определяет, могут ли узлы безопасно обмениваться данными. Он должен быть скопирован с первого инициализированного узла на все остальные.

На узле A (первый узел):

Найдите файл cookie (обычно /var/lib/rabbitmq/.erlang.cookie или ~/.erlang.cookie в зависимости от метода установки) и скопируйте его содержимое.

На узле B (и последующих узлах):

Остановите службу RabbitMQ:
```
sudo systemctl stop rabbitmq-server
```

Замените существующий файл cookie содержимым, скопированным с узла A, убедившись в правильных правах доступа (обычно 400).

# Пример с использованием echo (замените содержимое по необходимости)
echo "YOUR_LONG_COOKIE_STRING" | sudo tee /var/lib/rabbitmq/.erlang.cookie
sudo chmod 400 /var/lib/rabbitmq/.erlang.cookie

Запустите службу на узле B:
```
sudo systemctl start rabbitmq-server
```

Шаг 1: Настройка имен хостов и сети

Убедитесь, что файлы хостов на обоих узлах A и B правильно сопоставляют их имена хостов.

Пример /etc/hosts (на обоих серверах):

192.168.1.10   rabbitmq-node-a
192.168.1.11   rabbitmq-node-b

Шаг 2: Инициализация первого узла кластера (Активный)

Узел A будет начальным основным узлом, на котором сначала создается кластер.

Запустите службу на узле A (если она еще не запущена):
```
sudo systemctl start rabbitmq-server
```
Проверьте статус: Убедитесь, что узел работает корректно.
```
rabbitmqctl status
```

Шаг 3: Присоединение второго узла (Пассивный) к кластеру

Теперь мы даем команду узлу B присоединиться к кластеру под руководством узла A.

Остановите приложение RabbitMQ на узле B, оставив узел Erlang доступным:
```
sudo rabbitmqctl stop_app
```
Сбросьте локальное состояние узла B, если он уже был инициализирован как отдельный узел:
```
sudo rabbitmqctl reset
```
Команда присоединения: Выполните команду присоединения на узле B, указав имя хоста узла A в качестве пира.
```
sudo rabbitmqctl join_cluster rabbit@rabbitmq-node-a
```
Совет: Используйте имя хоста, определенное в /etc/hosts.
Запустите приложение RabbitMQ на узле B:
```
sudo rabbitmqctl start_app
```

Шаг 4: Проверка формирования кластера

Войдите на узел A и проверьте, что оба узла видят друг друга.

rabbitmqctl cluster_status

Ожидаемый фрагмент вывода:

Вы должны увидеть как rabbitmq-node-a, так и rabbitmq-node-b в списке running_nodes.

Cluster status of node rabbit@rabbitmq-node-a ...
[{nodes,[{disc,[rabbit@rabbitmq-node-a,rabbit@rabbitmq-node-b]}]},
 {running_nodes,[rabbit@rabbitmq-node-a,rabbit@rabbitmq-node-b]},
 ...
]

Шаг 5: Настройка высокой доступности для очередей

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

Для современных развертываний RabbitMQ используйте очереди кворума для реплицированных надежных очередей. Классические зеркальные очереди использовали политики ha-mode в старых версиях RabbitMQ, но этот подход устарел и удален из новых основных версий.

Объявление очереди кворума

Вы можете объявить очереди кворума из вашего приложения или с помощью rabbitmqadmin. Этот пример создает надежную очередь кворума:

rabbitmqadmin declare queue name=orders durable=true arguments='{"x-queue-type":"quorum"}'

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

Шаг 6: Тестирование отказоустойчивости

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

Опубликуйте несколько постоянных тестовых сообщений в очередь кворума.
Остановите приложение RabbitMQ на активном узле с помощью sudo rabbitmqctl stop_app.
Подтвердите, что клиенты переподключаются через ваш балансировщик нагрузки, цель DNS или настройку обнаружения сервисов.
Получите тестовые сообщения из выжившего узла.
Запустите остановленное приложение снова с помощью sudo rabbitmqctl start_app и проверьте rabbitmqctl cluster_status.

Заключительный вывод

Кластеризация RabbitMQ дает вам общие метаданные брокера, но доступность очередей зависит от типа очереди и дизайна отказоустойчивости клиентов. Используйте очереди кворума для реплицированных надежных очередей, держите как минимум три узла для реальной отказоустойчивости и тестируйте отказоустойчивость с тем же путем подключения, который используют ваши приложения.