Настройка кластера rabbitmq в windows

Обновлено: 05.07.2024

A RabbitMQ broker is a logical grouping of one or several Erlang nodes , each running the RabbitMQ application and sharing users , virtual hosts , queues , exchanges , bindings , and runtime parameters . Sometimes we refer to the collection of nodes as a cluster .

All data / state required for the operation of a RabbitMQ broker is replicated across all nodes . An exception to this are message queues , which by default reside on one node , though they are visible and reachable from all nodes . To replicate queues across nodes in a cluster , see the documentation on high availability ( note that you will need a working cluster first ) .

By default , contents of a queue within a RabbitMQ cluster are located on a single node ( the node on which the queue was declared ) . This is in contrast to exchanges and bindings , which can always be considered to be on all nodes . Queues can optionally be made mirrored across multiple nodes .

Each mirrored queue consists of one master and one or more mirrors . The master is hosted on one node commonly referred as the master node . Each queue has its own master node . All operations for a given queue are first applied on the queue ' s master node and then propagated to mirrors . This involves enqueueing publishes , delivering messages to consumers , tracking acknowledgements from consumers and so on .

Messages published to the queue are replicated to all mirrors . Consumers are connected to the master regardless of which node they connect to , with mirrors dropping messages that have been acknowledged at the master . Queue mirroring therefore enhances availability , but does not distribute load across nodes ( all participating nodes each do all the work ) .

If the node that hosts queue master fails , the oldest mirror will be promoted to the new master as long as it synchronised

RabbitMQ-клиенты поддерживают подключение к нескольким нодам кластера(большинство клиентских библиотек позволяет задать несколько нод для подключения), но в конкретный текущий момент времени клиент может подключиться только к одной ноде из кластера. Если эта нода т.н. мастер для этой очереди(т.е. на этой ноде была создана эта очередь и реплицирована на все остальные ноды кластера), то именно эта нода и обработает запрос. Но, если клиент подключается к НЕ мастер ноде, то внутренним механизмом/транспортом RabbitMQ перенаправит подключение клиента к мастер ноде для этой очереди. Если, например, мастер нода не доступна, то клиент переподключается к одной из оставшихся нод в кластере(одна из slave-нод будет выбрана в качестве нового мастера и клиент будет перенаправлен на этот новый мастер в случае, если клиент переподключился к другим нодам кластера, после выхода со строя старой мастер ноды, на котором создавалась очередь)

Краткое введение в RabbitMQ

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

RabbitMQ реализован на Erlang, что немного необычно, но одна из причин, по которой он так надежен.

Предпосылки

В этом руководстве я буду использовать локальный кластер Vagrant из трех узлов. Если у вас уже есть три доступные машины (виртуальные или нет), вы можете использовать их вместо этого. Обратите внимание на порты и сети.

Установите VirtualBox

Следуйте инструкциям по установке VirtualBox.

Установить Vagrant

Следуйте инструкциям по установке Vagrant

Создать кластер RabbitMQ

Вот Vagrantfile, который создаст локальный трехузловой кластер на вашем компьютере. ОС Ubuntu 14.04 (Trusty).

Чтобы создать пустой кластер, введите: vagrant up .

Настройка SSH

Чтобы упростить ssh для узлов кластера, введите: vagrant ssh-config >>

Если вы наберете: cat

/ .ssh / config , вы должны увидеть записи для rabbit-1, rabbit-2 и rabbit-3.

Теперь вы можете использовать ssh на каждой виртуальной машине по имени: ssh rabbit-1 .

Убедитесь, что узлы достижимы по имени

Самый простой способ - отредактировать файл /etc/hosts. Например, для rabbit-1 добавьте адреса rabbit-2 и rabbit-3.

plain 192.168.77.11 rabbit-2 192.168.77.12 rabbit-3

Повторите процесс для всех узлов.

Установка RabbitMQ

Я буду использовать apt-get здесь для операционных систем Debian/Ubuntu. Если ваш кластер работает в другой ОС, следуйте инструкциям на странице установки RabbitMQ.

Обратите внимание, что иногда довольно устаревшая версия RabbitMQ доступна по умолчанию. Если вы хотите установить самую последнюю и лучшую версию, вы можете загрузить пакет .deb напрямую или добавить apt-репозиторий RabbitMQ, используя эти инструкции.

Текущая версия RabbitMQ на Ubuntu 14.04 - 3.2, что достаточно для наших целей. Убедитесь сами, набрав: apt-cache show rabbitmq-server .

Давайте продолжим и установим его на каждую машину:

plain sudo apt-get update sudo apt-get install rabbitmq-server -y

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

Обратите внимание, что Erlang будет установлен первым в качестве предварительного условия.

Включваем плагин Management RabbitMQ

plain sudo rabbitmq-plugins enable rabbitmq_management

Получаем инструмент командной строки управления

Основные понятия RabbitMQ

Управление вашим кластером

Для управления кластером используются три сценария. Скрипт rabbitmq-server запускает сервер RabbitMQ (запускает его). Rabbitmqctl используется для управления кластером (остановка, сброс, объединение узлов кластера и получение статуса). Rabbitmqadmin, который вы скачали ранее, используется для настройки и администрирования кластера (объявление vhosts, пользователей, обменов и очередей). Создание кластера включает в себя только rabbitmq-server и rabbitmqctl.

Во-первых, давайте запустим rabbitmq-сервер как сервис (демон) на каждом из наших хостов rabbit-1, rabbit-2 и rabbit-3.

plain sudo service rabbitmq-server start

Это запустит виртуальную машину Erlang и приложение RabbitMQ, если узел не работает. Чтобы убедиться, что он работает правильно, введите:

plain sudo rabbitmqctl cluster_status

Вывод должен быть таким (для rabbit-1):

Это означает, что узел еще не кластеризован ни с какими другими узлами и является дисковым узлом. Он также работает, как вы можете видеть, что он появляется в списке running_nodes.

Чтобы остановить сервер, введите следующую команду:

plain sudo rabbitmqctl stop_app

Затем, если вы проверите состояние кластера:

plain sudo rabbitmqctl cluster_status

Вывод должен быть таким:

plain Cluster status of node 'rabbit@rabbit-1' . []>] . done.

Нет больше работающих узлов.

Вы можете повторить процесс для других узлов (rabbit-2 и rabbit-3) и увидеть, что они знают только себя.

Эрланг Cookie

Прежде чем вы сможете создать кластер, все узлы в кластере должны иметь один и тот же файл cookie. Файл cookie - это файл, который среда исполнения Erlang использует для идентификации узлов. Он находится в /var/lib/rabbitmq/.erlang.cookie. Просто скопируйте содержимое с rabbit-1 на rabbit-2 и rabbit-3.

Узлы кластеризации вместе

Чтобы сгруппировать эти отдельные узлы в единый кластер, требуется определенная работа. Вот процедура:

Работает один узел (например, rabbit-1).
Остановите другой узел (например, rabbit-2).
Сброс остановленного узла (rabbit-2).
Кластеризация другого узла в корневой узел.
Запустите остановленный узел.

Давай сделаем это. ssh в rabbit-2 и выполните следующие команды:

plain sudo rabbitmqctl stop_app sudo rabbitmqctl reset sudo rabbitmqctl join_cluster rabbit@rabbit-1

Теперь наберите: sudo rabbitmqctl cluster_status .

Вывод должен быть следующим:

```plain Cluster status of node ‘rabbit@rabbit-2’ … []>] …Done. As you can see both nodes are now clustered. If you repeat this on rabbit-1 you’ll get following output:

Теперь вы можете начать rabbit-2.

plain sudo rabbitmqctl start_app

Если вы проверите статус снова, оба узла будут работать:

Обратите внимание, что оба узла являются узлами диска, что означает, что они хранят свои метаданные на диске. Давайте добавим rabbit-3 в качестве узла RAM. ssh to rabbit-3 и выполните следующие команды:

plain sudo rabbitmqctl stop_app sudo rabbitmqctl reset sudo rabbitmqctl join_cluster --ram rabbit@rabbit-2 sudo rabbitmqctl start_app

Проверка состояния показывает:

Все узлы кластера работают. Узлы диска - это rabbit-1 и rabbit-2, а узел ОЗУ - rabbit-3.

Поздравляем! У вас есть работающий кластер RabbitMQ.

Реальные осложнения

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

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

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

Надежная кластеризация RabbitMQ

Это сводится к следующему: вы не знаете, какой последний дисковый узел вышел из строя. Вы не знаете метаданные кластеризации каждого узла (возможно, они были сброшены во время сброса). Чтобы запустить все узлы, я использую следующий алгоритм:

Запустите все узлы (по крайней мере, последний дисковый узел должен быть в состоянии начать).
Если даже ни один узел не может запуститься, вы попали в точку. Просто выручите.
Отслеживайте все узлы, которые не удалось запустить.
Попробуйте запустить все неисправные узлы.
Если некоторые узлы не удалось запустить во второй раз, вы попали в шланг. Просто выручите.

Этот алгоритм будет работать до тех пор, пока ваш последний узел диска физически исправен.

После того, как все узлы кластера подключены, вы можете переконфигурировать их (помните, что вы не уверены, на каком узле какие метаданные). Ключ заключается в принудительном сбросе каждого узла. Это гарантирует, что любой след предыдущей конфигурации кластера будет удален со всех узлов. Сначала сделайте это для одного дискового узла:

plain stop_app force_reset start_app

Затем для каждого другого узла (диска или ОЗУ):

plain stop_app force_reset join_cluster [list of disc nodes] start_app

Удаленное управление кластером

Вы можете ввести SSH в каждый блок и выполнить вышеупомянутые шаги для каждого блока вручную. Это работает, но очень быстро устаревает. Кроме того, это нецелесообразно, если вы хотите построить и разрушить кластер как часть автоматизированного теста.

Одним из решений является использование Fabric. Одна серьезная ошибка, с которой я столкнулся, заключается в том, что когда я выполнял алгоритм кластера сборки вручную, он работал отлично, но когда я использовал Fabric, он таинственным образом не работал. После некоторой отладки я заметил, что узлы запустились успешно, но к тому времени, когда я попытался stop_app, узлы были недоступны. Это оказалось ошибкой новичка Fabric с моей стороны. Когда вы запускаете удаленную команду с помощью Fabric, она запускает новую оболочку на удаленном компьютере. Когда команда завершена, оболочка закрывается, отправляя сигнал SIGHUP (сигнал зависания) всем его подпроцессам, включая узел Erlang. Использование nohup позаботится об этом. Другой более надежный вариант - запуск RabbitMQ в качестве службы (демона).

Программное администрирование кластера

Администрирование означает создание виртуальных хостов, пользователей, бирж и очередей, настройку разрешений и привязку очередей к биржам. Первое, что вы должны сделать, если вы еще этого не сделали, это установить плагины управления. Я не уверен, почему вы должны включить его самостоятельно. Это должно быть включено по умолчанию.

Веб-интерфейс фантастический, и вы должны обязательно ознакомиться с ним. Однако для удаленного администрирования кластера можно использовать API-интерфейс управления RESTful. Существует также инструмент командной строки Python с именем rabbitmqadmin, для которого требуется Python 2.6+. Использовать rabbitmqadmin довольно просто. Единственная проблема, которую я обнаружил, это то, что я мог использовать только гостевую учетную запись по умолчанию для администрирования кластера. Я создал другого пользователя-администратора с именем «admin», установил его разрешения для всех (настройка/чтение/запись) и присвоил ему тег «администратор» (дополнительное требование API управления), но я продолжал получать ошибки разрешения.

Продолжаем серию статей по настройке отказоустойчивости сервисов для DirectumRX. В данной статье рассмотрим готовую реализацию отказоустойчивых Redis и RabbitMQ.

Почему эта тема актуальная:

Подготовка экспериментального стенда

Спроектируем инфраструктуру стенда от общего к частному:

Требуется, чтобы клиентское приложение обращалось к одному IP-адресу или одному доменному имени и портам для подключения к сервису RabbitMQ и Redis.
Клиентское приложение ничего не знает про отказоустойчивость сервисов и не может влиять на выбор работающего узла.

Уточним схему, введем узел реверс-прокси, который будет перенаправлять обращения к определенному порту на необходимый сервис:

Отказоустойчивость HAProxy может быть реализована за счет использования системной службы Keepalived. Сервис Keepalived реализует механизм «плавающего» виртуального IP адреса. В случае выхода из строя одного из узлов, виртуальный адрес переназначается дублирующему узлу. Для автоматического переключения IP адреса используется протокол VRRP (Virtual Router Redundancy Protocol).

Реализация вариантов отказоустойчивости Redis подробно рассмотрена в статье Горизонтальное масштабирование и отказоустойчивость Redis для сервисных служб DirectumRX. В данном случае будем использовать вариант Redis Cluster, поскольку этот вариант является наиболее простым в реализации и надежным.

В итоге получаем следующую схему размещения сервисных служб:

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

Для реализации кластера Redis рекомендуется использовать минимум 3 пары MASTER-SLAVE, в нашем случае будем использовать 4 пары, равномерно распределенные по 2 виртуальным машинам, которые в свою очередь размещены на двух разных физических серверах.

Сервисы RabbitMQ также должны размещаться на разных аппаратных узлах.

В рамках данного эксперимента примем допущение, что на всех виртуальных машинах в качестве ОС развернут дистрибутив ubuntu 18.04. Для других Linux настройка будет практически идентичной, могут отличаться некоторые команды, которые будут использоваться при развертывании, также могут отличаться расположения конфигурационных файлов сервисных служб.

Настройка HAProxy в режиме балансировки нагрузки

HAProxy - это специализированный инструмент, предназначенный для обеспечения высокой доступности и балансировки нагрузки, и используется повсеместно известными онлайн сервисами. Подробнее о HAProxy можно почитать на странице разработчика.

Установим HAProxy на узлы VM 1 и VM 2:

В конфигурационные файлы на узлах HAProxy /etc/haproxy/haproxy.cfg, добавим настройки для проксирования запросов к узлам Redis и RabbitMQ (в том числе для Management Panel ):

Блок настроек для Redis :

Блок настроек для RabbitMQ :

Разворачиваем сервис Keepalived:

По умолчанию конфигурационный файл keepalived отсутствует в папке сервиса. Необходимо его создать:

После чего занесем в конфигурационный файл на одном узле (на VM1 будет располагаться MASTER-узел):

На другом узле (на VM2 будет располагаться SLAVE-узел):

Данные конфигурационные файлы отличаются настройками:

state MASTER и state SALVE
priority 2 и priority 1

После перезапуска служб Keepalived в сети появится виртуальный IP адрес, который будет привязан к MASTER-узлу.

Проверить подключенные к сетевому интерфейсу виртуальные адреса можно с помощью команды:

Результат корректного выполнения команды:

Где «inet 192.168.43.97/32 scope global eth0» - искомый виртуальный адрес.

Настройка отказоустойчивого HAProxy завершена.

Настройка кластера Redis

Настройка кластера Redis выполняется по инструкции представленной в статье Горизонтальное масштабирование и отказоустойчивость Redis для сервисных служб DirectumRX. Но есть ряд отличий.

Поскольку для корректной работы кластера Redis требуется не менее трех MASTER-реплик, для симметрии мы будем использовать два виртуальных узла и разместим на них четыре MASTER-реплики и четыре SLAVE-реплик:

Для пары M1 – S1 будем использовать порт 6381

Для пары M2 – S2 будем использовать порт 6382

Для пары M3 – S3 будем использовать порт 6383

Для пары M4 – S4 будем использовать порт 6384

Итоговый скрипт создания кластера Redis :

Настройка кластера RabbitMQ

Проще говоря, уже «из коробки» RabbitMQ обладает возможностями масштабирования. Подключение узлов расширения фактически выполняется путем подключения новых узлов к первому.

Каждый узел кластера RabbitMQ будет иметь доступ ко всем очередям кластера и будет доступен как самостоятельный узел. Как и в случае с Redis, чтобы реализовать переключение на работающий узел также потребуется использовать HAProxy.

Для того, чтобы можно было подключить SLAVE-узлы к MASTER необходимо, чтобы файл /var/lib/rabbitmq/.erlang.cookie на всех подключаемых узлах был идентичный. В данном файле содержится уникальный ключ по которому процесс Erlang будет иметь доступ к процессам Erlang на других узлах.

Развернем RabbitMQ на узлах VM3 и VM4:

Также на узлах развернем Management Panel для удобного управления кластером RabbitMQ:

Выполним копирование файла .erlang.cookie с узла VM3 на VM4:

После чего, перейдем на узел VM4 и выполним присоединение узла:

Для проверки состояния кластера можно выполнить команду:

Результат работы команды:

Также за состоянием кластера можно следить из веб-панели управления:

Заметим, что по умолчанию очередь будет создаваться и храниться только на одном из узлов. В случае выхода из строя какого-либо узлов, его (узла) очереди не будут доступны в кластере.

Для того, чтобы очереди перераспределялись по узлам необходимо настроить политику зеркалирования очередей HA-MODE:

Name – наименование политики.

Pattern – выбираем все очереди «.*»

Priority – выбираем минимальный приоритет (0), чтобы политика не влияла на какие-либо дополнительные политики. Максимальное значение 255. Чем больше число, тем выше приоритет.

Definition – определяет задаваемый параметр политики. Параметр «ha-mode» определяет зеркалирование очередей. Укажем значение параметра «all», чтобы зеркалирование выполнялось для всех очередей.

Данную операцию можно также выполнить из командной строки:

Настроенная на одном узле политика тут же применяется и на других узлах.

Настройка кластера RabbitMQ завершена.

Вместо заключения

После завершения настройки необходимо выполнить тестовые отключения узлов и убедиться, что сервисы остаются доступны, а при включении узлов настройки кластера автоматически восстанавливаются.

Дополнительные ссылки, которые могут быть полезны при выполнении настроек:

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

RabbitMQ - это отличный инструмент, который выполняет свои задачи превосходно. Отличным преимуществом является качественная документация и широкий спектр функциональных возможностей.

RabbitMQ считается одной из самых продвинутых систем по работе с очередями. Это всё благодаря тому, что RabbitMQ имеет много возможностей. Если хорошо разобраться в этой системе, то, в дальнейшем, работа с другими системами очередей не вызовет у вас конфуза.

Но, прежде, чем писать RabbitMQ tutorial, как обычно, начнём с установки и запуска. В этой статье я шаг за шагом продемонстрирую процесс установки. Если вы ещё не знакомы, с системами очередей, и слабо понимаете механизм их работы, то советую прочитать ранее опубликованную статью об основам очередей.

Установка Erlang

RabbitMQ запускается в виртуальной среде Erlang. Не спрашивайте зачем, просто установите Erlang, без которого RabbitMQ не сможет работать. Последнюю версию для windows можно скачать по ссылке.

На странице скачивания установочного файла нужно выбрать версию, в зависимости от вашей системы (в моём случае, это версия для 64-разрядного процессора):

Установка RabbitMQ

Установка плагина управления RabbitMQ с WEB-интерфейса

После установки, RabbitMQ сразу же будет запущен, потому, можно сразу же начинать с ним работать.

Обычным для программиста является работа из консоли. Но, иногда, одной консоли бывает недостаточно. Потому, в этом шаге будет установлен плагин RabbitMQ Web для работы с очередями из WEB-интерфейса. Этот интерфейс предоставляет удобный вывод статистики, информацию о работающих процессах, логах, и т.д.

Для того, чтобы установить плагин, нужно из консоли перейти в папку sbin , которая находится по пути установки RabbitMQ (в моём случае C:\Program Files\RabbitMQ Server\rabbitmq_server-3.7.7\sbin ). При этом, запускать нужно от имени администратора.

Или же, проще нажать кнопку winsows, и начать печатать rabbit, и, из найденных результатов интересует в данном случае только RabbitMQ Command Prompt.

Запустив который мы окажемся в консоли, в нужной для работы директории.

В открывшейся консоли нужно выполнить команду
rabbitmq-plugins.bat enable rabbitmq_management ,
которая, как раз и включит этот плагин. Получиться должно что-то вроде этого:

Заключительным шагом от нас требуется перезапустить сервис, поочерёдно выполнив команды:

Ожидаемо должны увидеть страницу входа в WEB-интерфейс:

По умолчанию, данные для входа в панель управления:
Логин: guest
Пароль: guest

Вот, что вы должны увидеть в итоге:

На этом установка полностью завершена, и сервис RabbitMQ готов к работе. Теперь можно свободно работать, и использовать все функции этого мощного и полезного инструмента. В следующей статье по RabbitMQ будет рассмотрен практический пример по работе с системой очередей: добавление, удаление, обработка, и т.д.

Протестируем работу сервиса

Резюме

В этой статье я показал, как установить RabbitMQ на windows 10, как протестировать его работу, и установить плагин RabbitMQ WEB (для работы в WEB-интерфейсе). Это очень крутой инструмент, который рекомендовано освоить каждому программисту.

По поводу "рекомендовано" - это мягко говоря. Сейчас RabbitMQ используется почти во всех high-load проектах. И, зачастую, во всех вакансиях (на PHP программиста) требуют именно знание системы очередей RabbitMQ. Потому, хорошее понимание этого инструмента, и опыт работы с ним повышает шансы найти работу в хорошей компании.

Читайте также: