Как настроить RabbitMQ с использованием архитектуры Active/Passive High Availability

Я пытаюсь настроить кластер серверов RabbitMQ, чтобы получить высокодоступные очереди с использованием активной/пассивной архитектуры сервера. Я следую этим руководствам:

Мои требования к высокой доступности просты, у меня есть два узла (CentOS 6.4) с RabbitMQ (v3.2) и Erlang R15B03. Node1 должен быть "активным", отвечающим на все запросы, а Node2 должен быть "пассивным" node, в котором все очереди и сообщения реплицируются (из Node1).

Для этого я настроил следующее:

Node1 с RabbitMQ работает нормально в некластерном режиме
Node2 с RabbitMQ работает нормально в некластерном режиме

Следующим, что я сделал, было создание кластера между обоими узлами: объединение Node2 в Node1 (руководство 1). После этого я настроил политику для зеркалирования очередей (руководство 2), реплицируя все очереди и сообщения среди всех узлов в кластере. Это работает, я могу подключиться к любому node и публиковать или потреблять сообщение, в то время как оба узла доступны.

Проблема возникает, когда у меня есть очередь queueA, которая была создана на Node1 (master on queueA), и когда Node1 остановлен, я не могу подключиться к очереди A в Node2 для создания или потребления сообщений, Node2 что Node1 недоступен (я думаю, что queueA не реплицируется в Node2, а Node2 не может быть назначен мастером очередиA).

Ошибка:

{ "Операция AMQP была прервана: AMQP close-reason, инициированный Peer, code = 404, text =\" NOT_FOUND - home node "rabbit @node1" прочного queue 'queueA' в vhost 'app01' недоступен \ ", classId = 50, methodId = 10, cause =" }

Последовательность используемых шагов:

Node1:

1. rabbitmq-server -detached
2. rabbitmqctl start_app

Node2:

3. Copy .erlang.cookie from Node1 to Node2
4. rabbitmq-server -detached

Присоедините кластер (Node2):

5. rabbitmqctl stop_app
6. rabbitmqctl join_cluster [email protected]
7. rabbitmqctl start_app

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

8. rabbitmqctl set_policy ha-all "" '{"ha-mode":"all","ha-sync-mode":"automatic"}'

Примечание. Шаблон, используемый для имен очередей, - "" (все очереди).

Когда я запускаю "rabbitmqctl list_policies" и "rabbitmqctl cluster_status", все нормально.

Почему Node2 не может ответить, если Node1 недоступен? Что-то не так в этой настройке?

Ответ 1

Вы не указали виртуальный хост (app01) в вызове set_policy, поэтому политика будет применяться только к виртуальному хосту по умолчанию (/). Эта командная строка должна работать:

rabbitmqctl set_policy -p app01 ha-all "" '{"ha-mode":"all","ha-sync-mode":"automatic"}'

Ответ 2

В консоли управления веб-сервером находится queueA, указанная как Node1 +1?

Похоже, что может возникнуть проблема с вашей настройкой. У меня есть набор бродячих коробок, которые предварительно настроены для работы в кластере, возможно, стоит попробовать и определить проблемы в вашей настройке?

Ответ 3

Убедитесь, что ваша очередь не является долговечной или эксклюзивной.

Из документации (https://www.rabbitmq.com/ha.html):

Эксклюзивные очереди будут удалены, когда закрытое соединение закрывается. По этой причине это не полезно для эксклюзивного очередь, которая должна быть зеркальной (или долговечной), поскольку, когда nodeхостинг он опустится, соединение закроется, и очередь будет необходимо в любом случае удалить.

По этой причине исключительные очереди никогда не отражаются (даже если они придерживаться политики, заявляющей, что они должны быть). Они также никогда (даже если объявлено как таковое).

Из вашего сообщения об ошибке:

{ "Операция AMQP была прервана: AMQP close-reason, инициированный Peer, code = 404, text =\" NOT_FOUND - home node 'rabbit @node1' of длительная очередь 'queueA' в vhost 'app01' недоступна \ ", classId = 50, methodId = 10, cause =" }

Похоже, вы создали прочную очередь.

Ответ 4

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

Ответ 5

Внимательно прочитайте свою ссылку

http://www.rabbitmq.com/ha.html

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