Эксплуатация кроликов (RabbitMQ) в режиме «Выжить любой ценой»

[SirEdvin]

Поскольку кролик горизонтально не масштабируется (производительность кластера равна производительности самого медленного сервера)

Разве? Мне казалось, что он масштабируется при помощи шардирования, то есть у вас может быть, например, 5 нод и 3 очередей, причем для каждой очереди две копии. В таком случае добавление еще одной ноды вроде как может помочь. Или я не прав?

[JuriM]

Масштпбируется раббит настройками репликации очередей

[spirtus_78]

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

[ctapmex]

в данной фразе идет недосказанность — кролик горизонтально не масштабируется при используемых у нас политиках отказоустойчивости. Описание политик дано ниже в статье (ha-mode, lazy)

[neenik]

RabbitMQ при больших нагрузках — это боль. Точнее, для достижения нормального RPS нужно уж больно много ресурсов/нод/CPU.
Перешли на Redis Cluster Streams и счастливы.

[spirtus_78]

Опять же повторюсь: зависит от того, какие задачи предполагается решать. Если нужно обеспечить максимальную скорость передачи сообщений — это одно, но опять: сильно зависит от размера каждого сообщения. А если нужно обеспечить непрерывный доступный маршрут — это уже совсем другое.

[gecube]

Kafka рассматривали? Геораспределенный кролик — это прмя боль.

[spirtus_78]

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

[gecube]

Ну, Вы прям совсем не правы.
Кафка — прекрасно работает в качестве транспорта.

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

а кроликом нормально… ну-ну.

[spirtus_78]

Кафка это решение в основном для хранения сообщений, а кролик для транспортировки. Разные подходы для разных целей. Кроликом вполне нормально. Многолетняя успешная эксплуатация это подтверждает.

[Frank59]

Спасибо за статью! Мы как раз сейчас на распутье, проблемы с кроликом начались, когда пришлось делать кластер. Разваливается достаточно часто, а процесс восстановления такое себе удовольствие. Сейчас как раз думаем, городить ли велосипеды типа вашего, либо переходить на что-то другое.

[spirtus_78]

Смотря по какой причине разваливается. У нас падения были ровно до тех пор, пока lazy не появилось. Сейчас у нас пока до конца не решена проблема network partition, но уже есть мысли как решить:
1. На уровне хапов проверку доступности сделать через lua скрипты — при получении через API overview получить имя ноды, с которой идут расхождения.
2. заблокировать поток сообщений на неё.
3. Отправить команду на рестарт.

[Frank59]

Расскажите, как сообщения переносите на резервный кластер.

[ctapmex]

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

[JuriM]

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

[gecube]

Можете рассказать — что за «сложная» логика инкапсулирован в скрипт «проверки статуса ноды»?

[spirtus_78]

Поскольку кролик работает внутри виртуальной машины любое его падение, даже kill успевает вызвать запись в лог. Вот эти записи и анализируем. Других вариантов быстро не нашлось, а данное решение уже несколько лет успешно выполняет свою работу на нескольких сотнях серверов. Оно не претендует на какую-то красоту или элегантность. Простое как лом и такое же эффективное.

[SirEdvin]

А можете мне объяснить, почему haproxy, а не предположим consul dns + consul health check? Их тогда не было или они чем-то хуже?

[spirtus_78]

Наличие или отсутствие хапа у нас никак не сказывается на пропускной способности кластера: Нагрузка по ресурсам на хапах 10-15%, а нагрузка на сетевой интерфейс всего 2-4 гигабита из 10. Входящий хап это самое ненагруженное (по сети) место. Самая большая сетевая нагрузка как раз между нодами кластера. У нас кролик настроен именно для high availability и как раз синхронизационный трафик даёт основную сетевую нагрузку. При входящем 2-4 гигбита между нодами бегает 4-6 гигабит. Хап очень неплохо размазывает входящую нагрузку на ноды: все получаются равномерно нагружены.

[JuriM]

не было подобных проблем? RabbitMQ and HAProxy: a timeout issue – Tony's press
deviantony.wordpress.com ›…

[JuriM]

www.google.com/url?sa=t&source=web&rct=j&url=https://deviantony.wordpress.com/2014/10/30/rabbitmq-and-haproxy-a-timeout-issue/amp/&ved=2ahUKEwiagrmNobjfAhVphaYKHdJyB-8QFjAAegQIBBAB&usg=AOvVaw17dBygIt5ZMifs9AkEhA1q&ampcf=1

[spirtus_78]

Обращаю внимание на наш конфиг хапа — значения таймаутов.

[JuriM]

Сейчас уже не вспомню, пробовали разные варианты, ставили 3 часа таймаут тоже и получали зависшие сессии периодически

[spirtus_78]

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

[jt5]

А почему выбрали RabbitMQ, а не EMQ X Enterprise?

[ctapmex]

на момент проработки архитектуры (2014 год) был выбран RabbitMQ по соотношению цена/качество/возможности

[Asten]

Рекомендую ещё задать лимиты на пользователя и vhost на количество подключений. Без этих лимитов неосторожное приложение может отставить от кролика только шкурку…

[spirtus_78]

Опыт эксплуатации показывает несколько иную картину:
Несколько раз были сбои в работе подсистем и они начинали со страшной силой плодить входящие каналы: Кролик выжил при 80000 каналов. Веб-морда тормозила нещадно, но падать отказался.
Кролик вполне спокойно держит нагрузку например такую: 9000 коннектов/9000 каналов, скорость обмена 5-8 тыс сообщений, объём 50-200 Мегабайт/секунду.
Мы пошли по пути:
Лучше отладить код подсистем, работающих с кроликом, нежели городить костыли, которые ограничат транспорт.

[Asten]

это не костыли, это настройка лимитов кролика. в веб морде вкладка limit

[spirtus_78]

Я имею ввиду костыль — как средство ограничения. Ограничить можно что угодно и где угодно. Причем ещё на уровне хапа. Но решение у нас всё таки архитектурное. Если неожиданно наплодилось нештатное количество коннектов — это всё отображается на мониторинге и принимаются меры. Устраняется баг в коде или изменяется архитектурная часть.