Комментарии 30
Поскольку кролик горизонтально не масштабируется (производительность кластера равна производительности самого медленного сервера)
Разве? Мне казалось, что он масштабируется при помощи шардирования, то есть у вас может быть, например, 5 нод и 3 очередей, причем для каждой очереди две копии. В таком случае добавление еще одной ноды вроде как может помочь. Или я не прав?
Масштпбируется раббит настройками репликации очередей
В нашем случае недостаточно, т.к. необходим баланс производительности/отказоустойчивости/доступности. Причём, скорость работы не является самым важным параметром этого баланса. По приоритетам получается Доступность-отказоустойчивость-скорость работы.
Можно политиками поиграть и приземлять разные очереди на разные ноды, но это сильно снизит доступность сервиса в случае сбоев. Неоднократно происходили ситуации, когда по сети доступна оставалась только одна нода, и она обеспечивала работу, пока остальные не вернулись в строй. Причем со стороны подсистем это происходило незаметно.
Можно политиками поиграть и приземлять разные очереди на разные ноды, но это сильно снизит доступность сервиса в случае сбоев. Неоднократно происходили ситуации, когда по сети доступна оставалась только одна нода, и она обеспечивала работу, пока остальные не вернулись в строй. Причем со стороны подсистем это происходило незаметно.
в данной фразе идет недосказанность — кролик горизонтально не масштабируется при используемых у нас политиках отказоустойчивости. Описание политик дано ниже в статье (ha-mode, lazy)
RabbitMQ при больших нагрузках — это боль. Точнее, для достижения нормального RPS нужно уж больно много ресурсов/нод/CPU.
Перешли на Redis Cluster Streams и счастливы.
Перешли на Redis Cluster Streams и счастливы.
Kafka рассматривали? Геораспределенный кролик — это прмя боль.
В данном случае нельзя заменить одно на другое. Нам необходим именно транспорт, а не хранилище. Кафка это хранилище, но не маршрутизируемый на лету транспорт. При всём желании, передать асинхроном гигабайты сообщений с одного края страны на другой, кафкой будет минимум затруднительно. Каждое решение хорошо для своих задач. На мой взгляд, их вообще сравнивать можно только в ситуациях локального применения, когда не используется сильно распределённые потоки данных.
Спасибо за статью! Мы как раз сейчас на распутье, проблемы с кроликом начались, когда пришлось делать кластер. Разваливается достаточно часто, а процесс восстановления такое себе удовольствие. Сейчас как раз думаем, городить ли велосипеды типа вашего, либо переходить на что-то другое.
Смотря по какой причине разваливается. У нас падения были ровно до тех пор, пока lazy не появилось. Сейчас у нас пока до конца не решена проблема network partition, но уже есть мысли как решить:
1. На уровне хапов проверку доступности сделать через lua скрипты — при получении через API overview получить имя ноды, с которой идут расхождения.
2. заблокировать поток сообщений на неё.
3. Отправить команду на рестарт.
1. На уровне хапов проверку доступности сделать через lua скрипты — при получении через API overview получить имя ноды, с которой идут расхождения.
2. заблокировать поток сообщений на неё.
3. Отправить команду на рестарт.
Расскажите, как сообщения переносите на резервный кластер.
в конце статьи приведена ссылка на гитхаб. Там документ с описанием работы тулзы для администрирования. В том числе и перенос сообщений.
но если кратко — shovel для всех не пустых очередей.
главное допущение: считается, что порядок сообщений в очереди не важен. Либо если он критичен, то в виду уже произошедшей аварии потеря порядка исправляется на другом уровне.
но если кратко — shovel для всех не пустых очередей.
главное допущение: считается, что порядок сообщений в очереди не важен. Либо если он критичен, то в виду уже произошедшей аварии потеря порядка исправляется на другом уровне.
По моему опыту хапрокси не очень хорошо взаимодействует с раббит кластером, и одного check было недостаточно, сокет ноды может отвечать, но нода может быть нерабочей. Сейчас на нодах раббита используется keepalived со скриптом проверки статуса ноды и привязкой вирт. айпи, плюс отказ от хапрокси позволил повысить пропускную способность кластера.
Можете рассказать — что за «сложная» логика инкапсулирован в скрипт «проверки статуса ноды»?
Поскольку кролик работает внутри виртуальной машины любое его падение, даже kill успевает вызвать запись в лог. Вот эти записи и анализируем. Других вариантов быстро не нашлось, а данное решение уже несколько лет успешно выполняет свою работу на нескольких сотнях серверов. Оно не претендует на какую-то красоту или элегантность. Простое как лом и такое же эффективное.
А можете мне объяснить, почему haproxy, а не предположим consul dns + consul health check? Их тогда не было или они чем-то хуже?
Наличие или отсутствие хапа у нас никак не сказывается на пропускной способности кластера: Нагрузка по ресурсам на хапах 10-15%, а нагрузка на сетевой интерфейс всего 2-4 гигабита из 10. Входящий хап это самое ненагруженное (по сети) место. Самая большая сетевая нагрузка как раз между нодами кластера. У нас кролик настроен именно для high availability и как раз синхронизационный трафик даёт основную сетевую нагрузку. При входящем 2-4 гигбита между нодами бегает 4-6 гигабит. Хап очень неплохо размазывает входящую нагрузку на ноды: все получаются равномерно нагружены.
не было подобных проблем? RabbitMQ and HAProxy: a timeout issue – Tony's press
deviantony.wordpress.com ›…
deviantony.wordpress.com ›…
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&cf=1
Обращаю внимание на наш конфиг хапа — значения таймаутов.
А почему выбрали RabbitMQ, а не EMQ X Enterprise?
Рекомендую ещё задать лимиты на пользователя и vhost на количество подключений. Без этих лимитов неосторожное приложение может отставить от кролика только шкурку…
Опыт эксплуатации показывает несколько иную картину:
Несколько раз были сбои в работе подсистем и они начинали со страшной силой плодить входящие каналы: Кролик выжил при 80000 каналов. Веб-морда тормозила нещадно, но падать отказался.
Кролик вполне спокойно держит нагрузку например такую: 9000 коннектов/9000 каналов, скорость обмена 5-8 тыс сообщений, объём 50-200 Мегабайт/секунду.
Мы пошли по пути:
Лучше отладить код подсистем, работающих с кроликом, нежели городить костыли, которые ограничат транспорт.
Несколько раз были сбои в работе подсистем и они начинали со страшной силой плодить входящие каналы: Кролик выжил при 80000 каналов. Веб-морда тормозила нещадно, но падать отказался.
Кролик вполне спокойно держит нагрузку например такую: 9000 коннектов/9000 каналов, скорость обмена 5-8 тыс сообщений, объём 50-200 Мегабайт/секунду.
Мы пошли по пути:
Лучше отладить код подсистем, работающих с кроликом, нежели городить костыли, которые ограничат транспорт.
Я имею ввиду костыль — как средство ограничения. Ограничить можно что угодно и где угодно. Причем ещё на уровне хапа. Но решение у нас всё таки архитектурное. Если неожиданно наплодилось нештатное количество коннектов — это всё отображается на мониторинге и принимаются меры. Устраняется баг в коде или изменяется архитектурная часть.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Эксплуатация кроликов (RabbitMQ) в режиме «Выжить любой ценой»