Comments 16

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


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

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

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

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


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


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


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

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

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

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

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

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

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

Будем признательны, если Вы сможете поделиться с нами опытом касательно возможных проблем.
Хорошую рекомендацию вы себе делаете, видимо вы не знаете, что в сети бывают не только L2 устройства, но и L3, и что не только по теории, но и на практике, с ними тоже бывают проблемы.
Немного непонятно из вашего комментария, о чём конкретно вы говорите. Давайте вы уточните и мы продолжим беседовать? А проблемы могут возникнуть и не только из-за VRRP.
Система, которую описывает хостер, который что-то стоит, явно должна быть более надежной, чем надежной с надежностью коммутатора или пара коммататоров. И не должно быть вопросов у такого хостера, какие есть возможные проблемы. Проблемы могут быть везде, интересна схема, которая решает эти проблемы на уровне работы http, предлагаю как у вам ограничиться этим уровнем и не углубляться в базы и т.п. В целом в VRRP меня не устраивает скорость срабатывания и надежность работы, предпочитаю анонсировать VIP адреса на разные роутеры через ospf.

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

Непонятно, зачем dns резервировать. Он же отказоустойчивый по природе своей.
Чтобы уменьшить время простоя сервиса при недоступности одного dns-сервера. К тому же, некоторые сервисы чувствительны к задержкам и отваливаются по таймауту до того, как начнется опрос второго dns-сервера.
Only those users with full accounts are able to leave comments. Log in, please.
Information
Founded

18 January 2004

Location

Россия

Employees

31–50 employees

Registered

26 July 2012