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

Автоматическая настройка кластера 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.

Единственный способ, которым это, по-видимому, сработает, — это применить файл конфигурации на всех трех узлах и заставить их начать сточнов то же время. Я пытаюсь развернуть это с помощью 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}}]}].

Связанный контент