Вопрос или проблема
В данный момент я сталкиваюсь с проблемой, когда небольшой кластер RabbitMQ не удается создать. Кластер работает в Docker и, насколько я могу судить, все функционирует правильно. Я могу пинговать хосты через rabbitmqctl и даже выполнять команды удаленно с другого узла без проблем, так что я уверен, что epmd и аутентификация работают правильно. В логах ничего не фиксируется по поводу неудачи, кластер просто не формируется через автокластер, и когда я пытаюсь кластеризовать вручную, я получаю ошибку, но без информации о том, что может вызывать проблему. Вот копия моей консоли, показывающая проблему, когда я пытаюсь провести ручное формирование.
bash-5.0# rabbitmqctl -n rabbit@rabbit2 stop_app
Stopping rabbit application on node rabbit@rabbit2 ...
bash-5.0# rabbitmqctl -n rabbit@rabbit2 reset
Resetting node rabbit@rabbit2 ...
bash-5.0# rabbitmqctl -n rabbit@rabbit2 join_cluster rabbit@rabbit1
Clustering node rabbit@rabbit2 with rabbit@rabbit1
Error: unable to perform an operation on node 'rabbit@rabbit1'. Please see diagnostics information and suggestions below.
Наиболее распространенные причины этого:
* Целевой узел недоступен (например, из-за проблем с разрешением имени хоста, TCP-соединением или настройками файрвола)
* Инструмент CLI не может пройти аутентификацию на сервере (например, из-за несоответствия cookies Erlang инструмента CLI и сервера)
* Целевой узел не запущен
В дополнение к информации диагностики ниже:
* Ознакомьтесь с руководствами по CLI, кластеризации и сетевому взаимодействию на https://rabbitmq.com/documentation.html, чтобы узнать больше
* Обратитесь к логам сервера на узле rabbit@rabbit1
* Если целевой узел настроен на использование длинных имен узлов, не забудьте использовать --longnames с инструментами CLI
ДИАГНОСТИКА
===========
попытка связаться с: ['rabbit@rabbit1']
rabbit@rabbit1:
* подключение к epmd (порт 4369) на rabbit1
* узел rabbit@rabbit1 запущен, приложение 'rabbit' работает
Текущие данные по узлу:
* имя узла: 'rabbitmqcli-7700-rabbit@rabbit1'
* эффективный домашний каталог пользователя: /var/lib/rabbitmq
* Хеш cookie Erlang: nomnomnom
Я пробовал практически все, что указано на странице устранения неполадок RabbitMQ, и насколько я могу судить, сетевых проблем нет. Единственная ошибка, которую я получаю при просмотре логов, когда узлы пытаются автокластеризоваться, это badrpc, nodedown.
Я бы хотел, чтобы кто-то предоставил мне шаги, которые я мог бы предпринять для дальнейшей диагностики. Я установил логирование на уровень отладки, но после увеличения уровня в логах не появляется ничего интересного. Я заметил, что в секции окружения установлен уровень loglevel ядра на notice после глобальной установки debug. Честно говоря, я потерян на данный момент, поэтому любая информация будет очень признательна.
Я запускал несколько инструментов диагностики, чтобы проверить такие вещи, как разрешение имен, аутентификация, возможные проблемы с файрволом и т. д., но ничего не заваливается, и все участвующие узлы показывают, что работают нормально в одиночку. Удаленные команды через диагностические инструменты выполняются успешно. Это важно, поскольку это доказывает, что аутентификация работает как и ожидалось. Я также делал захват пакетов, а также проверял доступ к портам с помощью netcat и т. д., и все кажется работающим как и ожидалось.
Чтобы было ясно, я не ищу, чтобы кто-то решил это за меня, поскольку я чувствую, что это вполне может быть проблема, не связанная с RabbitMQ. Я ищу некоторое руководство по дальнейшим шагам, так как я исчерпал большинство ресурсов.
Вот версия сервера и erlang.
Erlang/OTP: 23.0.3 Rabbit Server: 3.8.6
Ответ или решение
Конечно, создание кластера RabbitMQ может быть непростой задачей, особенно если проблема кажется скрытой и не имеет явных симптомов. Рассмотрим несколько теоретических аспектов, примеров и практическое применение знаний для диагностики и решения проблемы кластера RabbitMQ на конкретном хосте.
Теория
RabbitMQ — это система обмена сообщениями, построенная на Erlang, что делает её сильно зависимой от сетевых особенностей и настройки окружения. Кластеризация обеспечивает надежность и масштабируемость, но требует точной настройки и идеально настроенной сетевой инфраструктуры.
Наиболее распространенные проблемы при создании кластера RabbitMQ могут быть связаны с:
-
Имя хоста и разрешение DNS: Узел рабочей станции должен быть правильно разрешён как другим узлам в кластере, так и локально.
-
Аутентификация и Erlang cookie: Вся коммуникация между узлами происходит через Erlang cookie — специальный файл, который должен быть одинаковым на всех узлах кластера.
-
Сетевые проблемы: Ограничения на уровне фаерволла, неверно настроенные подсети или блокирование необходимых портов.
-
Конфигурации в Docker: Использование Docker может добавить дополнительные сложности в виде виртуальных сетевых интерфейсов и перенаправления портов.
Пример
Рассмотрим ваш случай. Вы упоминали, что узлы могут пинговаться, а команды запускаются успешно, что может свидетельствовать о правильно настроенной сети на базовом уровне. Однако ошибка «badrpc, nodedown» указывает на то, что может быть проблема с соединением на уровне Erlang.
Диагностическая информация, которую вы предоставили, говорит о возможности успешного подключения к epmd на порту 4369, что свидетельствует о том, что базовые сетевые настройки, такие как разрешение имен хостов и доступность портов, работают правильно. Однако сама связь между нодами не устанавливается, что может указывать на проблему с настройками Erlang или конфигурацией Docker.
Практическое применение
Вот некоторые шаги, которые вы можете предпринять для решения проблемы:
-
Проверка Erlang cookie: Убедитесь, что файл
.erlang.cookieидентичен на всех узлах, участвующих в кластере. Он обычно находится в домашнем каталоге пользователя RabbitMQ. -
Долгие имена узлов: Убедитесь в использовании долгих имен узлов, особенно если хост может быть доступен через полное доменное имя. Это может быть выполнено путем добавления
-longnameв командной строке или настройки соответствующего параметра в конфигурации. -
Проверка конфигурации Docker:
- Убедитесь, что все нужные порты (4369, 25672 и диапазон портов, используемых для передачи сообщений) правильно проброшены между контейнерами и хостами.
- Проверьте, что сети Docker настроены правильно и все контейнеры имеют доступ друг к другу.
-
Логи и уровень логирования: Увеличьте уровень логирования RabbitMQ и Erlang с
noticeнаdebug, убедившись, что настройки применились. Для этого проверьте конфигурационные файлы и перезапустите сервис при необходимости. -
Расширенная диагностика сети: Используйте утилиты, такие как
tcpdumpилиwireshark, для захвата и анализа трафика между узлами, чтобы убедиться, что все пакеты доходят до целевых узлов. -
Сравнение конфигураций: Проверьте конфигурационные файлы RabbitMQ и Erlang, чтобы убедиться, что между узлами нет конфликта конфигураций, особенно в настройках сетевых интерфейсов и кластеризации.
-
Синхронизация системных часов: Убедитесь, что все узлы имеют синхронизированное время через NTP. Несинхронизированное время может вызвать проблемы в соединении и обработке сообщений.
Заключение
Ваша проблема, скорее всего, комплексная, связанная с несколькими аспектами одновременно. Кластеризация RabbitMQ в контейнерах Docker добавляет слоя усложнения, который необходимо учитывать. Надеюсь, предложенные шаги помогут вам в диагностике и решении проблемы создания вашего кластера RabbitMQ. Если проблема сохраняется, может быть полезно пересмотреть архитектуру сети и обеспечить её соответствие всем требованиям RabbitMQ и Erlang. Удачи в решении вашей проблемы!