Отказоустойчивый кластер для балансировки нагрузки

[kvaps]

Спасибо за статью, очень познавательно!

Расскажите, вы пробовали СlusterIP?
Очень интересно сравнение обоих методов, какие плюсы и минусы у LVS по сравнению с СlusterIP?

[redfs]

Если у вас возникли вопросы по статье или что-то показалось спорным — пожалуйста, оставляйте свои комментарии, будем рады обсудить.

Спорного тут есть, давайте обсудим.
Навскидку — для горизонтального масштабирования схема неоптимальна. Если уж вы используйте VRRP, то для балансировщика проще прописать два VIP в DNS, каждый из keepalived будет одновременно работать и как MASTER и как BACKUP (зеркально). Если один из них упадет, его VIP переедет на соседний сервер. И не надо никаких дополнительных скриптов с пробросом портов.
Более подробно схема описана например тут.

[NetAngels]

Согласны с Вами, тоже рабочий вариант.

Однако, на наш взгляд, при таком варианте могут возникнуть потенциальные сложности с настройками персистентности в будущем. Например, в самом простом случае не получится отправлять каждый отдельный IP на один и тот же конечный сервер с приложением. Т.е., в зависимости от работы DNS, запрос может уходить на разные конечные сервера, проходя через разные балансеры. Если при этом конечные сервера ничего друг про друга не знают, могут появиться ошибки с сессиями и т.п.

В предлагаемом нами решении можно включить настройки персистентности на уровне LVS и на уровне Nginx, что в итоге позволит закрепить каждый отдельный IP за конкретным конечным сервером.

Т.е, нам кажется, что наш вариант в этом плане более универсальный.

[pfactum]

Для балансировки DNS UDP есть специализированные решения типа dnsdist'а или dnsbalancer'а.

[NetAngels]

Спасибо, будем иметь их ввиду.

Если говорить про наш внутренний DNS, то основное, что нам был нужно — это чтобы DNS продолжал работать, если один их backend серверов упадет или мы сами его выключим. Нам оказалось достаточно возможностей Nginx.

[pfactum]

Если не секрет, какая нагрузка? Интересует количество DNS-запросов в секунду, которые пропускает через себя балансировщик, и объём этого трафика в мегабитах.

[NetAngels]

Нагрузка там минимальная. В пиковые моменты, когда запускаются всякие "ночные" скрипты по крону, бывает около 150-200 запросов в секунду.

[pfactum]

А, ну это не очень серьёзно. Мне хотелось посмотреть, как nginx ведёт себя на десятках тысяч QPS, ибо те специализированные балансеры на такую нагрузку и рассчитаны.

[NetAngels]

Пока мы не встречали никаких проблем именно с работой протокола VRRP и его реализацией в Keepalived.

Были некоторые нарекания именно к работе Keepalived. Не всегда корректно отрабатывал механизм reload (версия 1.2.2, в wheezy). Приходилось именно перезагружать, со всеми вытекающими.

А с сетевым оборудованием проблем не было. Тот сегмент сети, где обитает VRRP трафик, состоит из обычных коммутаторов (L2). Плюс мы помещаем трафик разных VRRP групп в разные vlan'ы.

Будем признательны, если Вы сможете поделиться с нами опытом касательно возможных проблем.

[NetAngels]

Немного непонятно из вашего комментария, о чём конкретно вы говорите. Давайте вы уточните и мы продолжим беседовать? А проблемы могут возникнуть и не только из-за VRRP.

[sshikov]

А где такой, простейший в общем-то, случай, когда один или несколько серверов server-1, server-2 и т.д. недоступны? Причем вообще говоря, они могут быть недоступны как полностью, так и частично.

[porutchik]

Непонятно, зачем dns резервировать. Он же отказоустойчивый по природе своей.

[Aristarkh]

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