Документ кластеризации 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, и на самом деле вам не нужно раскручивать все узлы в одно и то же время.
Что я обычно делаю и до сих пор работаю для меня:
.
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
Для создания cookie Erlang я обычно использую http://passwordsgenerator.net/ и настроить его для создания строки из 20 символов, состоящей только из символов верхнего регистра. Затем поместите эту строку в /var/lib/rabbitmq/.erlang.cookie, например:
echo -n 'LCQLSHVOPZFHRUXMMAPF' > /var/lib/rabbitmq/.erlang.cookie
Это должно сработать для вас. Проверено на версиях 3.2, 3.3 и 3.5.
Я добился в этом некоторого прогресса.
Проблема, похоже, связана с выбором использования ОЗУ узлы, а не диск узлы в файле rabbitmq.config. Из документации:
Узлы RAM - расширенный вариант использования; при настройке вашего первого кластера вы просто не должны их использовать. У вас должно быть достаточно дисковых узлов для удовлетворения ваших требований к избыточности, а затем, при необходимости, добавьте дополнительные узлы RAM для масштабирования.
Кластер, содержащий только узлы RAM, хрупок; если кластер остановится, вы не сможете запустить его снова и потеряете все данные. RabbitMQ предотвратит создание кластера только для RAM-узла во многих ситуациях, но не может полностью предотвратить это.
Когда я изменяю файл конфигурации, чтобы использовать «диск» вместо «оперативной памяти», создание кластера было намного более стабильным.
[{rabbit,
[{cluster_nodes, {['rabbit@rabbit1', 'rabbit@rabbit2', 'rabbit@rabbit3'],disc}}]}].