Как сделать кластер на ubuntu

Обновлено: 06.07.2024

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

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

Требования

Серверы, использованные в руководстве, имеют 4 Гб памяти, что позволяет воспользоваться преимуществами более высокой вычислительной мощности. Однако для подобной настройки можно использовать и серверы с меньшим объёмом памяти.

Ведущий сервер (Control):

Имя хоста: command
Внутренний IP-адрес: 1.1.1.1

Ведомый сервер 1 (Worker):

Имя хоста: work1
Внутренний IP-адрес: 1.1.1.2

Ведомый сервер 2:

Имя хоста: work2
Внутренний IP-адрес: 1.1.1.3

Ведомый сервер 3:

Имя хоста: work3
Внутренний IP-адрес: 1.1.1.4

Система Ubuntu 12.04.
Пользователь с доступом к sudo (инструкции здесь).
Частная сеть.

Начальная настройка ведущей ноды

Создание пользователя

Сначала нужно создать непривилегированного пользователя для управления кластером (не путайте его с пользователем с доступом к sudo, который уже существует в системе). В данном руководстве такой пользователь условно называется cluster:

sudo adduser cluster --uid 900

Параметр –uid указывает id пользователя, который будет связан с данным аккаунтом. Если порядковый номер ниже 1000, то такой пользователь не будет выполнять системных задач.

Установите надёжный пароль для нового пользователя cluster. На остальные запросы можно просто нажать Enter.

Создание учётных данных

Теперь создайте учётные данные SSH для нового пользователя. Ноды кластера будут взаимодействовать по SSH и обмениваться данными путём монтирования NFS. Создайте пару ключей SSH.

Перейдите в сессию пользователя cluster:

Сгенерируйте ключ RSA:

Чтобы принять опции по умолчанию, нажмите Enter.

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

Чтобы принять ключ, введите yes и укажите пароль пользователя cluster.

Чтобы вернуться в сессию предыдущего пользователя, введите:

Установка MPI

Ноды кластера будут взаимодействовать с помощью системы MPI (Message Passing Interface), что позволит параллельным процессам легко обмениваться данными о состоянии и рабочей информацией.

В руководстве используется популярная версия MPICH2.

Чтобы установить её, введите:

sudo apt-get install mpich2

Развёртывание ведомых нод с помощью ведущей

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

Также для дальнейшей работы вам понадобится IP-адрес частной сети для каждой ноды.

Установка NFS

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

Перейдите на ведущий сервер.

Как говорилось ранее, данный кластер будет использовать NFS-монтирование для распространения домашнего каталога между всеми нодами. Сервер NFS будет установлен на ведущей ноде. Для этого запустите команду:

sudo apt-get update && sudo apt-get install nfs-kernel-server

Экспортируйте домашний каталог пользователя cluster на все ноды:

sudo nano /etc/exports

Добавьте в конец файла:

Перезапустите сервер NFS:

sudo service nfs-kernel-server restart

Настройка нод

Теперь нужно добавить файл hosts на каждую ноду кластера, чтобы они могли взаимодействовать.

Примечание: Данный раздел нужно выполнить на всех нодах кластера.

Отредактируйте файл /etc/hosts и добавьте данные о нодах в следующем формате.

1.1.1.1 command
1.1.1.2 work1
1.1.1.3 work2
1.1.1.4 work3

Примечание: Замените условные IP-адреса IP-адресами своих серверов.

Откройте файл hosts:

sudo nano /etc/hosts

Вставьте в файл следующие строки:

127.0.0.1 localhost command
1.1.1.1 command
1.1.1.2 work1
1.1.1.3 work2
1.1.1.4 work3

Сохраните и закройте файл.

Настройка ведомых нод

Затем нужно установить и настроить компоненты NFS на ведомые ноды.

Примечание: Выполните данный раздел на всех ведомых нодах кластера.

sudo apt-get install nfs-common -y

Теперь ноды могут получить экспортируемые данные:

sudo showmount -e command
Export list for command:
/home/cluster *

Это значит, что данные были успешно переданы с ведущего сервера command.

Примечание: В случае сбоя или ошибки попробуйте перезапустить сервер NFS на ведущей ноде:

sudo service nfs-kernel-server restart

Вернитесь на ведомую ноду и смонтируйте домашний каталог пользователя cluster.

sudo mount command:/home/cluster /home/cluster

Домашний каталог будет смонитрован. Чтобы монтирование каталога выполнялось автоматически, добавьте эту команду в файл /etc/fstab. Откройте файл:

sudo nano /etc/fstab

И вставьте в конец файла следующую строку:

command:/home/cluster /home/cluster nfs

Сохраните и закройте файл.

Заключительные действия

Теперь ведущий сервер передаёт свой домашний каталог на остальные серверы кластера при помощи монтирования NFS.

Проверьте подключения SSH. При создании такого подключения не должен запрашиваться пароль.

Откройте сессию пользователя cluster на ведущей ноде:

Создайте SSH подключение к каждой ноде в кластере:

Введите yes, чтобы принять хост. Чтобы вернуться, введите:

Затем повторите это на каждой ведомой ноде по очереди (ssh work1, ssh work2 и т.д.). Убедитесь, что все ноды могут взаимодействовать по SSH.

Создание файла hosts

Теперь нужно создать ещё один файл hosts, в котором будет храниться список рабочих нод кластера.

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

Ведущую ноду не нужно добавлять в кластер, иначе в случае высокой нагрузки она может отказать. На ведущей ноде войдите как пользователь cluster:

Создайте файл hosts:

Добавьте в него список рабочих нод:

work1
work2
work3

Сохраните и закройте файл.

Затем создайте локальный каталог bin, в котором будут храниться приложения кластера:

Тестирование кластера

Соберите необходимые приложения на ведущей ноде в сессии обычного пользователя с доступом к sudo:

sudo apt-get build-dep mpich2

Теперь можно получить исходные файлы с веб-сайта проекта:

Распакуйте архив и перейдите в полученный каталог:

tar xzvf mpich*
cd mpich*

Выполнение команды займёт некоторое время. После этого откройте сессию пользователя cluster:

Скопируйте программу, скомпилированную в каталоге bin:

cp /home/regular_user/mpich2-1.4.1/examples/cpi /home/cluster/bin

С помощью этой программы можно протестировать кластер.

Для этого нужно сослаться на файл hosts и указать номер процесса, который нужно запустить. Также нужно зажать интерфейс.

mpiexec -f hosts -iface eth1 -n 12 /home/cluster/bin/cpi
Process 6 of 12 is on work1
Process 2 of 12 is on work3
Process 9 of 12 is on work1
Process 11 of 12 is on work3
Process 0 of 12 is on work1
Process 5 of 12 is on work3
Process 8 of 12 is on work3
Process 3 of 12 is on work1
Process 7 of 12 is on work2
Process 10 of 12 is on work2
Process 4 of 12 is on work2
Process 1 of 12 is on work2
pi is approximately 3.1415926544231256, Error is 0.0000000008333325
wall clock time = 0.003485

Как видите, в кластере выполняется 12 процессов. Если проверить каждый процесс в отдельности, вы увидите, что каждый из них работает по принципу round robin.

Заключение

Теперь у вас есть полностью рабочий кластер Beowulf. При необходимости в кластер можно добавить новые ноды.

Этот документ описывает, как создать кластер с тремя узлами в Ubuntu 20.04 и добавить в него ранее созданную группу доступности в качестве ресурса. Для обеспечения высокого уровня доступности группе доступности в Linux требуется три узла — см. статью Высокий уровень доступности и защита данных для конфигураций групп доступности.

На этом этапе интеграция SQL Server с Pacemaker в Linux реализована не на таком уровне, как с WSFC в Windows. Внутри SQL сведения о наличии кластера отсутствуют, вся оркестрация осуществляется снаружи, а сама служба управляется Pacemaker как автономный экземпляр. Кроме того, имя виртуальной сети относится только к WSFC. В Pacemaker его эквивалент отсутствует. Динамические административные представления Always On, запрашивающие сведения о кластере, возвращают пустые строки. Вы по-прежнему можете создать прослушиватель, чтобы использовать его для прозрачного переподключения после отработки отказа, но требуется вручную зарегистрировать имя прослушивателя на DNS-сервере с IP, использованным для создания ресурса виртуального IP-адреса (как описано в следующих разделах).

В следующих разделах описаны действия по настройке решения отказоустойчивого кластера.

Схема действий

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

Настройте диспетчер ресурсов кластера, например Pacemaker. Эти инструкции приведены в этом документе.

Способ настройки диспетчера ресурсов кластера зависит от конкретного дистрибутива Linux.

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

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

Ограждение обычно реализуется в операционной системе и зависит от среды. Инструкции по установке ограждений см. в документации распространителя операционной системы.

Установка и настройка Pacemaker в каждом узле кластера

Откройте порты брандмауэра на всех узлах. Откройте порт для службы высокой доступности Pacemaker, экземпляра SQL Server и конечной точки группы доступности. TCP-порт по умолчанию для сервера, где выполняется SQL Server, имеет значение 1433.

Кроме того, можно просто отключить брандмауэр.

Установите пакеты Pacemaker. Выполните следующие команды на всех узлах.

Задайте пароль для пользователя по умолчанию, который создается при установке пакетов Pacemaker и Corosync. Используйте на всех узлах один и тот же пароль.

Включение и запуск службы pcsd и Pacemaker

Следующая команда включает и запускает службу pcsd и Pacemaker. Выполните ее на всех узлах. Это позволяет узлам повторно подключаться к кластеру после перезагрузки.

Команда включения Pacemaker может завершиться с ошибкой "pacemaker Default-Start contains no runlevels, aborting" (pacemaker Default-Start не содержит уровни выполнения, прерывание). Она безвредна и позволяет продолжить настройку кластера.

Создание кластера

Удалите любые существующие конфигурации кластера со всех узлов.

Команда sudo apt-get install pcs одновременно устанавливает pacemaker, corosync и pcs и запускает все 3 эти службы. При запуске corosync создается файл шаблона /etc/cluster/corosync.conf. Для успешного выполнения дальнейших действий этот файл должен отсутствовать, поэтому можно остановить выполнение pacemaker/corosync и удалить /etc/cluster/corosync.conf, тогда дальнейшие действия пройдут успешно. Команда pcs cluster destroy делает то же самое, и вы можете использовать ее в качестве средства однократной начальной настройки кластера.

Следующая команда удаляет все существующие файлы конфигурации кластера и останавливает все службы кластера. Это приводит к окончательному уничтожению кластера. Запустите ее в качестве первого шага в подготовительной среде. Обратите внимание, что команда pcs cluster destroy отключает службу pacemaker, которую требуется снова включить. Выполните на всех узлах следующую команду.

Команда уничтожает все существующие ресурсы кластера.

Из-за известной проблемы, изучением которой уже занимается поставщик услуг кластеризации, при запуске кластера (pcs cluster start) возникает указанная ниже ошибка. Это связано с тем, что файл журнала, который настроен в /etc/corosync/corosync.conf и создается при выполнении команды установки кластера, является неверным. Чтобы обойти эту ошибку, измените файл журнала на /var/log/corosync/corosync.log. Кроме того, можно создать файл /var/log/cluster/corosync.log.

Указанная ниже команда создает кластер с тремя узлами. Перед выполнением данного сценария замените значения между < . > . Выполните следующую команду на первичном узле.

Если кластер был настроен ранее на тех же узлах, используйте параметр --force при выполнении команды pcs cluster setup. Обратите внимание, что это эквивалентно команде pcs cluster destroy. Службу Pacemaker необходимо включить повторно с помощью команды sudo systemctl enable pacemaker.

Настройка ограждения (STONITH)

Поставщики кластера Pacemaker требуют, чтобы STONITH был включен, а устройство ограждения настроено для поддерживаемой установки кластера. Если диспетчер ресурсов кластера не может определить состояние узла или ресурса в нем, для перевода кластера в известное состояние используется ограждение. Ограждение на уровне ресурсов гарантирует отсутствие повреждений данных в случае сбоя за счет настройки ресурса. Вы можете использовать ограждение на уровне ресурсов, например с распределенным реплицируемым блочным устройством (DRBD), чтобы пометить диск в узле как устаревший при отключении канала связи. Ограждение на уровне узлов гарантирует, что в узле не выполняются никакие ресурсы. Это осуществляется путем сброса узла, а соответствующая реализация для Pacemaker называется STONITH (что дословно расшифровывается как "застрелить другой узел"). Pacemaker поддерживает множество разных устройств ограждения, например источник бесперебойного питания или карты интерфейса управления для серверов. Дополнительные сведения см. в статьях Кластеры Pacemaker с нуля и Ограждение и Stonith

Так как конфигурация ограждения на уровне узлов сильно зависит от вашей среды, мы отключим ее для этого руководства (ее можно настроить позже). Запустите следующий скрипт на первичном узле.

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

Задание свойства кластера cluster-recheck-interval

cluster-recheck-interval указывает интервал опроса, с которым кластер проверяет наличие изменений в параметрах ресурсов, ограничениях или других параметрах кластера. Если реплика выходит из строя, кластер пытается перезапустить ее с интервалом, который связан со значениями failure-timeout и cluster-recheck-interval . Например, если для failure-timeout установлено значение 60 с, а для cluster-recheck-interval — 120 с, то повторная попытка перезапуска предпринимается с интервалом, который больше 60 с, но меньше 120 с. Мы рекомендуем установить для failure-timeout значение, равное 60 с, а для cluster-recheck-interval значение больше 60 с. Задавать для cluster-recheck-interval небольшое значение не рекомендуется.

Чтобы изменить значение свойства на 2 minutes , выполните следующую команду:

Чтобы изменить значение свойства на true , выполните следующую команду:

Измените существующее свойство failure-timeout ресурса группы доступности на выполнение 60s (замените ag1 именем ресурса группы доступности).

Установка агента ресурсов SQL Server для интеграции с Pacemaker

Выполните следующие команды на всех узлах.

Создание учетных данных SQL Server для Pacemaker

На всех серверах SQL Server создайте имя для входа на сервер с помощью Pacemaker. Следующий запрос Transact-SQL создает имя для входа:

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

На всех серверах SQL Server сохраните учетные данные для входа SQL Server.

Создание ресурса группы доступности

Чтобы создать ресурс группы доступности, используйте команду pcs resource create и задайте свойства ресурса. Приведенная ниже команда ocf:mssql:ag создает ресурс типа «основной/подчиненный» для группы доступности ag1 .

При создании ресурса и периодически после этого агент ресурсов Pacemaker автоматически задает в группе доступности значение REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT на основе ее конфигурации. Например, если группа доступности содержит три синхронные реплики, агент задаст для REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT значение 1 . Дополнительную информацию и параметры конфигурации см. в разделе High Availability and Data Protection for Availability Group Configurations (Высокий уровень доступности и защита данных для конфигураций групп доступности).

Создание ресурса виртуального IP-адреса

Чтобы создать ресурс виртуального IP-адреса, выполните указанную ниже команду на одном узле. Используйте доступный статический IP-адрес из сети. Перед выполнением этого скрипта замените значения между < . > на допустимый IP-адрес.

В Pacemaker эквивалент имени виртуального сервера отсутствует. Чтобы использовать строку подключения, указывающую на строковое имя сервера, а не IP-адрес, зарегистрируйте IP-адрес ресурса и требуемое имя виртуального сервера в DNS. Для конфигураций аварийного восстановления зарегистрируйте имя и IP-адрес нужного виртуального сервера на DNS-серверах на основном сайте и сайте аварийного восстановления.

Добавление ограничения совместного размещения

Почти каждое решение в кластере Pacemaker, например выбор места запуска ресурса, принимается путем сравнения оценок. Оценки вычисляются для каждого ресурса, а диспетчер ресурсов кластера выбирает узел с наивысшей оценкой для конкретного ресурса. (Если узел имеет отрицательную оценку для ресурса, последний не может выполняться в этом узле.) Используйте ограничения для настройки решений в кластере. Ограничения имеют оценку. Если ограничение имеет оценку меньше бесконечности (INFINITY), то это только рекомендация. Оценка, равная INFINITY, указывает на обязательный характер. Чтобы убедиться, что первичная реплика и ресурс виртуального IP-адреса находятся на одном узле, определите ограничение совместного размещения с оценкой INFINITY. Чтобы добавить ограничение совместного размещения, выполните приведенную ниже команду на одном узле.

Добавление ограничения упорядочения

Ограничение совместного размещения имеет неявное ограничение упорядочения. Оно перемещает ресурс виртуального IP-адреса перед перемещением ресурса группы доступности. Последовательность событий по умолчанию:

Пользователь выполняет команду pcs resource move с узла node1 на узел node2 для первичной реплики группы доступности.

Ресурс виртуального IP-адреса останавливается на node1.

Ресурс виртуального IP-адреса запускается на node2.

На этом этапе IP-адрес временно указывает на node2, пока node2 все еще является вторичной репликой перед отработкой отказа.

Первичная реплика группы доступности на node1 понижается до вторичной.

Вторичная реплика группы доступности на node2 повышается до первичной.

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

Чтобы добавить ограничение упорядочения, выполните приведенную ниже команду в одном узле.

После настройки кластера и добавления группы доступности в качестве ресурса кластера вы не можете использовать Transact-SQL для отработки отказа ресурсов группы доступности. Ресурсы кластера SQL Server в Linux не так сильно зависят от операционной системы, как если бы они находились в отказоустойчивом кластере Windows Server (WSFC). Служба SQL Server не имеет сведений о наличии кластера. Вся оркестрация осуществляется с помощью средств управления кластерами. В RHEL или Ubuntu используйте pcs .

Для установки линукс-кластера на основе дистрибутива Ubuntu вам потребуется установочный диск Ubuntu Desktop Edition, с помощью которого вы установить операционную систему на консоль (главный компьютер) кластера. С того же самого диска нужно будет установить операционную систему на вычислительные узлы кластера. Однако, если вычислительные узлы не предполагается использовать в качестве офисных машин, но только как узлы кластера, то на эти компьютеры правильнее будет установить серверную редакцию дистрибутива - Ubuntu Server Edition, не содержащую графического интерфейса, и соответственно более легкую и быструю.

Сеть кластера следует спроектировать так, чтобы все узлы имели доступ в интернет. Это нужно для большего комфорта при настройке кластера и установки необходимого программного обеспечения на его узлах. Дело в том, что установка ПО в Ubuntu выполняется посредством закачки новейших версий необходимых пакетов из внешних репозиториев. В действительности достаточно будет обеспечить выходом в Интернет только главный компьютер (консоль кластера), а для вычислительных узлов необходима только возможность загружать программные пакеты через прокси. Осуществить это можно, установив на консоли кластера пакет apt-cacher-ng, а на вычислительных узлах сконфигурировать менеджер пакетов apt-get для работы через прокси. Для этого на консоли кластера выполним команду:

sudo apt-get install apt-cacher-ng

После этого на всех остальных узлах выполним команды:

Здесь мы предполагаем, что адрес 192.168.1.1 - это адрес консоли кластера во внутренней сети кластера.

После установки базовой операционной системы необходимо доустановить необходимое для функциониования кластера по: компиляторы, библиотеки и программы OpenMPI, SSH, NFS. Выполнить это можно с помощью следующих команд:

sudo apt-get install mc build-essential fort77 gfortran libstdc++5 libltdl7-dev
sudo apt-get install openssh-server nfs-kernel-server
sudo apt-get install openmpi-bin openmpi-doc

Данная последовательность команд устанавливает в систему OpenMPI и компиляторы из набора Gnu Compiller Collection (gcc). Компиляторы gcc обладают одним существенным (в некоторых случаях) недостатком. В них нет поддержки работы с типами данных REAL*16 и COMPLEX*32 (в терминологии Фортрана). Если для ваших задач необходима такая точность вычислений, то вы вместо стандартного набора компиляторов и пакета OpenMPI из состава дистрибутива должны будете установить компиляторы фирмы Intel и скомпилировать OpenMPI с поддержкой этих компиляторов. Как это сделать - рассказано в следующих двух параграфах этой статьи. Если же точность REAL*8 и COMPLEX*16 вас устраивает, то следующие два параграфа вы можете пропустить.

Установив кластер RabbitMQ в Ubuntu 18.04, вы избежите единой точки отказа и достигнете более высокой пропускной способности по сравнению с настройкой RabbitMQ в одном экземпляре. Без лишних слов давайте углубимся в настройку кластера RabbitMQ на Ubuntu 18.04 LTS.

Требования к настройке

Эта установка имеет следующие требования

Установленные серверы Ubuntu 18.04 LTS
Как минимум два сервера RabbitMQ
Пользователь с привилегиями sudo
Серверы должны иметь доступ к интернету

Эта настройка RabbitMQ Cluster в Ubuntu 18.04 основана на двух серверах со следующими IP-адресами и именами хостов.

Шаг 1: Настройте имена хостов и DNS

Первым этапом установки кластера RabbitMQ в Ubuntu 18.04 является настройка правильных имен хостов и DNS.

MQ Server 1:

MQ Server 2:

Если у вас нет DNS-сервера, вы можете добавить записи в /etc/hosts

Затем обновите ваши системы::

Шаг 2: Установите сервер RabbitMQ на обоих узлах

Войдите на свои серверы и установите сервер RabbitMQ на всех узлах, используя приведенное ниже руководство:

Установка RabbitMQ в Ubuntu 18.04 состоит из двух частей:

Установка Erlang / OTP
Установка сервера RabbitMQ

Статус ваших серверов RabbitMQ должен быть запущен:

Шаг 3: Скопируйте RabbitMQ Server 1 Cookie RabbitMQ Server2

Для работы кластера RabbitMQ все узлы, участвующие в кластере, должны иметь одинаковые файлы cookie. Скопируйте Cookie на свой первый узел на все остальные узлы в кластере.

Шаг 4: Сброс RabbitMQ на Node2

Переконфигурируйте RabbitMQ на узле 2 и присоедините его к кластеру.

1. Перезапустите сервис RabbitMQ

2. Остановить приложение

3. Сбросить rabbitmq

3. Присоединить узел к кластеру

4. Запустить процесс подачи заявки

Проверьте статус кластера:

Шаг 5. Настройка политики RabbitMQ HA

Создайте политику, которая позволяет зеркалировать очереди для всех узлов в кластере.

Вы можете перечислить настроенные политики, используя:

Чтобы удалить политику, используйте:

Шаг 5: Тестирование

Наконец, проверьте настройку кластера RabbitMQ в Ubuntu 18.04. Включите веб-панель управления RabbitMQ Management для удобного управления.

Если у вас есть активный брандмауэр UFW, разрешите порты TCP 5672 и 15672

По умолчанию гостевой пользователь существует и может подключаться только с localhost . Вы можете войти с этим пользователем локально с паролем « гость»

Чтобы иметь возможность войти в сеть, создайте пользователя-администратора, как показано ниже:

Используйте созданного пользователя для входа в интерфейс управления RabbitMQ. Вы должны получить статус всех узлов кластера.

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

Вы успешно установили кластер RabbitMQ в Ubuntu 18.04. Наслаждайтесь и оставайтесь на связи для более информативного содержания

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