Highly Available кластер RabbitMQ

… но у меня так и не получилось заставить этот способ работать.

Вот на этих словах заканчивается 95% всех HA-проектов.
Если вы не смогли автоматизировать процесс восстановления — это уже все что угодно, но не HA.

если узел доступен получаем ответ pang

либо исправить на pong, либо исправить на не доступен

Уж простите что здесь отвечаю… Тема уж больно до боли знакомая.

Что было у нас:

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



конфиг nginx

#
# Transport site
#

upstream rabbitmq {
        server  dev-queue1:15674 weight=5;
        server  dev-queue2:15674 weight=10;
        server  dev-back1:15674  weight=10;
        server  dev-back2:15674  weight=10;
        server  dev-back3:15674  weight=10;
        server  dev-back4:15674  weight=10;
        server  dev-back5:15674  weight=10;
        server  dev-back6:15674  weight=10;
        server  dev-back7:15674  weight=10;
        server  dev-back8:15674  weight=10;
}

server {
    listen          80;
    listen          88;

    server_name 10.76.156.241 dev-front1;
    access_log     off;
    error_log          /dev/null;

    root         /var/www;

    location /stomp/ {
        proxy_pass http://rabbitmq;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_buffering off;
    }

    location / {
    }

}


#
# end
#

Собственно как все решилось. Клиент использует websocket+stomp. кролик умеет stomp из коробки. между клиентами и кроликом стоит nginx, который умеет апстримы и вебсокеты. тем самым при выпадении любой нодды клиент просто переконекчивается и живет дальше. nginx так же осуществляет балансировку по нодам кролика. nginx балансируется DNS балансировкой с ТТЛ 60, тем самым решается автоматическое исключение фронта, т.е. кластер полностью автоматизирован.

Во что уперлись. Да собственно в канал, потому, что выдать всем клиентам одновременно 1024байт (json) в таких масштабах превращается в гигабиты траффика. Мы уперлись на 1Гб в сетевухи. Инженеры могли переделать на 10Гб, но нам уже было не надо.

Что имели при тестах. Без оптимизации ОС кролик благополучно падал так, что восстановить кластер было не возможно. Выедал всю память, Уходил в своп и тю-тю… kill -9 и кластера нет. Лечилось полной остановкой, удалением mnesia кролика и пересборкой кластера ручками.

Рекомендации. Не жалейте памяти. Для кролика оно все. Считайте циферки до, чем после. Прежде чем что-то сделать — нарисуйте на бумаге и покажите знакомым. Может что посоветуют.

Что использовали:

— CentOS release 6.5 (Final) (тюненый TCP стек и ядро под HA)
— {rabbit,«RabbitMQ»,«3.1.5»},
— {mnesia,«MNESIA CXC 138 12»,«4.5»},
— nginx version: nginx/1.4.4
— клиент sock.js stomp.js из коробки (проверяли почти во всех броузерах. все пашет именно по вебсокетам на постоянном коннекте. старые ИЕ летят по HRX по лонг-поллинг)

Резюме? Все работает почти из коробки. Немного напильника и жизнь удалась.

Спасибо за статью, особенно спасибо товарищу 440hz за полезный коментарий, так как в данный момент как раз работаю над подобной задачей

А эта упячка уже научилась не пересылать по сети лямбды?
Когда кластер разваливается от того, что на разных хостах разные версии виртуальной машины или самого кролика, ни о каком HA речи идти не может, поскольку оно не позволяет делать апгрейд без остановки.

мысль хорошая. про апгрейд даже пока не думали.