Зеркальные очереди RabbitMQ в нескольких кластерах

Можно ли использовать RabbitMQ HA, используя несколько (2) кластеров RabbitMQ?

Вот мое требование:

У нас есть 2 кластера RabbitMQ (каждый по 4 узла). Все узлы в обоих кластерах будут использовать один и тот же файл cookie Erlang. Таким образом, хотя эти 2 кластера физически находятся в разных местах, но будут действовать как единый кластер с 8 узлами.

Мы планируем использовать HAProxy для балансировки нагрузки обоих кластеров (8 узлов). И издатель, и потребитель будут использовать этот прокси для подключения к брокеру.

Мы хотели бы использовать зеркальные очереди для HA с ha-mode: точно, ha-params: 4, ha-sync-mode: automatic вместе с автоматическим лечением для cluster_partition_handling.

Вопрос:

  1. В случае HA, есть ли способ указать использовать 2 узла из первого кластера и 2 узла из второго кластера. Насколько я понимаю, это можно сделать с помощью политики ha-mode: nodes и использовать имена узлов, но при этом всегда будет использоваться один и тот же узел, может ли эта настройка быть динамической?

  2. Поскольку оба кластера очень надежны, будет ли правильным подходом использовать автоматическое лечение для cluster_partition_handling (в случае разделения мозга)?

  3. Согласно этому «По умолчанию очереди в кластере RabbitMQ расположены на одном узле (узле, на котором они были впервые объявлены). Это контрастирует с обменами и привязками, которые всегда можно рассматривать как присутствующие на всех узлах». . Означает ли это, что обмены по умолчанию зеркалируются? Итак, когда сообщение приходит на обмен и этот узел выходит из строя, будет ли сообщение доступно на другом обмене на другом узле?


person abhdeb    schedule 14.11.2017    source источник


Ответы (1)


Команда RabbitMQ отслеживает этот список рассылки и лишь иногда отвечает на вопросы по StackOverflow. .


Таким образом, хотя эти 2 кластера физически находятся в разных местах, но будут действовать как единый кластер с 8 узлами.

Пожалуйста, не делайте этого. Кластеры RabbitMQ требуют надежных сетевых подключений с низкой задержкой. Если ваш кластер пересекает WAN или зону доступности, ваши шансы на наличие сетевых разделов значительно возрастают. Дополнительную информацию см. В этом разделе документации. Вы должны использовать либо лопату, либо функцию федерации.

Означает ли это, что обмены по умолчанию зеркалируются? Итак, когда сообщение приходит на обмен и этот узел выходит из строя, будет ли сообщение доступно на другом обмене на другом узле?

Да и да.

person Luke Bakken    schedule 16.11.2017
comment
Наша цель - высокая доступность, у нас есть 2 физически разделенных центра обработки данных, подключенных через локальную сеть с задержкой в ​​сети 1 мс. В этом сценарии следует ли рассматривать федеративный обмен RabbitMQ и объединенные очереди или единый кластер (с одинаковыми файлами cookie в обоих центрах обработки данных) с зеркальными очередями? - person abhdeb; 17.11.2017