
Документ по кластеризации 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.
Единственный способ, которым это, по-видимому, сработает, — это применить файл конфигурации на всех трех узлах и заставить их начать сточнов то же время. Я пытаюсь развернуть это с помощью Ansible, который создает узлы последовательно, так что это не работает.
Что я здесь упускаю?
решение1
Я также развертываю кластеры 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
Для создания куки-файлов 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.
решение2
Я добился определенного прогресса в этом вопросе.
Проблема, по-видимому, связана с выбором использованиябаранузлы, а недискузлы в файле rabbitmq.config. Из документации:
Узлы RAM — это расширенный вариант использования; при настройке вашего первого кластера вы просто не должны их использовать. У вас должно быть достаточно дисковых узлов для удовлетворения ваших требований к избыточности, затем при необходимости добавьте дополнительные узлы RAM для масштабирования.
Кластер, содержащий только узлы RAM, является хрупким; если кластер остановится, вы не сможете запустить его снова и потеряете все данные. RabbitMQ предотвратит создание кластера, состоящего только из узлов RAM, во многих ситуациях, но он не может полностью предотвратить это.
Когда я изменил файл конфигурации, чтобы использовать «disc» вместо «ram», создание кластера стало намного стабильнее.
[{rabbit,
[{cluster_nodes, {['rabbit@rabbit1', 'rabbit@rabbit2', 'rabbit@rabbit3'],disc}}]}].