Назад | Перейти на главную страницу

RabbitMQ автоматическая настройка кластера

Документ кластеризации RabbitMQ

https://www.rabbitmq.com/clustering.html

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

[{rabbit,
  [{cluster_nodes, {['rabbit@rabbit1', 'rabbit@rabbit2', 'rabbit@rabbit3'], ram}}]}].

Вы применяете этот файл на каждом из 3 узлов в /etc/rabbitmq/rabbitmq.config, а затем запускаете rabbitmq на каждом, и, очевидно, сформируется кластер.

Это не работает, например,

Если вы запустите rabbit2, а rabbit3 еще не запущен, служба не запустится на rabbit2, так как он пытается создать кластер с rabbit3.

Точно так же, если вы примените конфигурацию только к rabbit1 и предварительно запустили rabbit2 и rabbit3, rabbit1 сформирует кластер только с rabbit2, как, согласно документации (я не понимаю, почему):

RabbitMQ will try to cluster to each node provided, and stop after it can cluster with one of them.

Единственный способ, которым это сработает, - это если вы примените файл конфигурации ко всем 3 узлам и начнете их с именно в то же время. Я пытаюсь развернуть это с помощью Ansible, который последовательно создает узлы, поэтому это не работает.

Что мне здесь не хватает?

Я также развертываю кластеры RabbitMQ с помощью Puppet, и на самом деле вам не нужно раскручивать все узлы в одно и то же время.

Что я обычно делаю и до сих пор работаю для меня:

  • установить RabbitMQ (RPM или DEB)
  • настроить файл hosts на каждом узле, чтобы сохранить записи для всех трех. пример:

.

192.168.1.11    dev-c1n01-rabbitmq.example.com  dev-c1n01-rabbitmq
192.168.1.12    dev-c1n02-rabbitmq.example.com  dev-c1n02-rabbitmq
192.168.1.13    dev-c1n03-rabbitmq.example.com  dev-c1n03-rabbitmq

узлы, которые мы объединяем в кластер (потому что я не хочу полагаться на доступность DNS) * развернуть rabbitmq.config

.

[
  {rabbit, [
    {cluster_nodes, {['rabbit@dev-c1n01-rabbitmq', 'rabbit@dev-c1n02-rabbitmq', 'rabbit@dev-c1n03-rabbitmq'], disc}},
    {cluster_partition_handling, pause_minority},
    {disk_free_limit, 2147483648},
    {heartbeat, 0},
    {tcp_listen_options, [binary, {backlog, 1024}, {nodelay, true}, {keepalive, true} ]},
    {vm_memory_high_watermark, 0.6},
    {default_user, <<"admin">>},
    {default_pass, <<"somedefaultpass">>}
  ]},
  {kernel, [

  ]}
,
  {rabbitmq_management, [
    {listener, [
      {port, 15672}
    ]}
  ]}
].
% EOF
  • развернуть erlang.cookie

Для создания cookie Erlang я обычно использую http://passwordsgenerator.net/ и настроить его для создания строки из 20 символов, состоящей только из символов верхнего регистра. Затем поместите эту строку в /var/lib/rabbitmq/.erlang.cookie, например:

echo -n 'LCQLSHVOPZFHRUXMMAPF' > /var/lib/rabbitmq/.erlang.cookie
  • начальные узлы (порядок не имеет значения, если у них одинаковые erlang.cookie и rabbitmq.config)

Это должно сработать для вас. Проверено на версиях 3.2, 3.3 и 3.5.

Я добился в этом некоторого прогресса.

Проблема, похоже, связана с выбором использования ОЗУ узлы, а не диск узлы в файле rabbitmq.config. Из документации:

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

Кластер, содержащий только узлы RAM, хрупок; если кластер остановится, вы не сможете запустить его снова и потеряете все данные. RabbitMQ предотвратит создание кластера только для RAM-узла во многих ситуациях, но не может полностью предотвратить это.

Когда я изменяю файл конфигурации, чтобы использовать «диск» вместо «оперативной памяти», создание кластера было намного более стабильным.

[{rabbit,
    [{cluster_nodes, {['rabbit@rabbit1', 'rabbit@rabbit2', 'rabbit@rabbit3'],disc}}]}].