Keepalived. VRRP. Будет ли работать Keepalived, если 2 сервера в разных ЦОД?

Question

[Константин]

Здравствуйте.
Имеется 2 сервера, расположенных в разных ЦОД.
Необходимо сделать кластер из 2 серверов для высокой доступности сайта.
Подойдёт ли Keepalived для данного решения? Или он работает, если оба сервера в одном ЦОД?

Answer 1

[Георг Гаал]

Нет, keepalived не будет работать в разных ЦОД. Но есть исключение - если сделаете L2VPN или типа того.

Рассмотрите более продвинутые варианты обеспечения отказоустойчивости (вроде BGP анонсов, либо закройтесь внешним прокси вроде Qrator/cloudflare). И ОБЯЗАТЕЛЬНО ПРОКОНСУЛЬТИРУЙТЕСЬ с сотрудниками ЦОД - они наверняка хорошо знают свою инфраструктуру и могут предложить варианты (например, плавающий между ЦОДами IP адрес, если ЦОДы принадлежат одному владельцу)

Comments

[Константин]

Qrator/cloudflare - это точка отказа, в случае возникновения проблема на этих точках, дальнейшая цепочка не имеет смысла.
Если завтра РКН заблокирует cloudflare, а второго ЦОДа нету, работающего сайта тоже нету.
Решение ищется для обычных интернет магазинов, поэтому Qrator слишком дорогое удовольствие.

[Георг Гаал]

возможность отказа cloudflare (или любого аналогичного сервиса) существенно ниже, чем неправильно построенного HA, т.к. не у всех есть опыт его постройки.

[Константин]

Георг Гаал, если говорить конкретно про cloudflare, то там есть водводный камень.
Т.к. требуется направлять весь трафик только на 1 сервер, а на 2й только в случае недостпуности, то это уже у них идёт как дополнительная платная услуга, которая оплачивается после предоставления. И в случае паразитного трафика/ддос, может прийти счёт приличный

[Георг Гаал]

Несомненно, Ваше замечание верное. Но, а что лучше - строить отказоустойчивость на DNS? Упал сервер (кластер), быстренько пересоздаем записи A c указанием рабочего кластера (заранее TTL на записи - минимальный)? А BGP - это обычным смертным не осилить, т.к. надо настраивать + заранее откуда затащить пул адресов (купить AS? или арендовать пул). Поэтому я и указал, что проще всего реально поговорить с коллегам-инфраструктурщиками из ЦОДа и попросить их помочь проработать вопрос балансировки/отказоустойчивости.
Плавающий айпи тоже имеет подводные камни. В том же хетцнере его переназначить можно только "руками" между узлами, что при редких авариях и минимальных требованиях к RTO вполне допустимо

[Константин]

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

- два KVM VPS в разных ЦОД (400 - 700р за штуку)
- nginx:80 -> apache:8080
- Mysql репликация мастер-мастер
- репликация файлов через clsync
- репликация конфигов (nginx, apache, php, ssl, postfix) через clsync
- работа с конфигами только на 1 сервере. Обновление SSL только на 1 сервере
- php сессии реплицируем через memcachedrep
- DNS round-robin, 2 А записи
- весь трафик nginx направляет только на 1 сервер, второй помечен как backup
- добавляете мониторинг через zabbix на всё что есть, чтобы видеть что и как работает
- ещё можно использовать DNS-хостинг с API, чтобы через заббикс убирать недоступный ip из DNS выдачи.

Пример: один из серверов недоступен/отключён.
Если вы проверите как работает DNS round-robin, то заметите такой алгоритм:
1) браузер подключается к 1 выданному ip
2) пытается подключиться в течении 2 - 2.5 секунд
3) если не получилось, то подключается к следующему ip
4) т.к. 1 сервер недоступен, то nginx переключается к своему внутреннему apache и рабтает с ним
ПРОФИТ!

[Георг Гаал]

Round robin это худший способ обеспечения фейл овера. Любое лишнее кэширование у провайдера или на роутере клиенте, особенности кэша его компьютера - и мы имеем не фейл овер, а сплошное недоразумение.
Вариант с хождением в апи днс провайдера выглядит более оптимальным.
А ещё более оптимально использование CF и ко - у них точка входа изначально правильным образом защищена от сбоя.

Опять же - весь вопрос в том бюджете, который есть на реализацию отказоустойчивости. Возможно, что бюджета нет, да и потери не такие высокие, если сайт полежит
И чего тогда вообще запаривпться ?

> - Mysql репликация мастер-мастер

Я вообще не верю в мастер-мастер. Любая проблема, что нарушена связность между узлами, а при этом клиент видит оба узла и мы имеем неразрешимые конфликты. Я уж не говорю об неограниченной ничем задержке между узлами - там да стандартные каналы связи, которыми мы не управляем. И при "правильном" мастер мастер сбои на линии приведут к увеличенным таймаутам при хождении в бд

[Константин]

> кэширование у провайдера
что есть, то есть. Лучше уж задержка в 2.5 секунды, чем вообще недоступность сайта/магазина.

> сбои на линии приведут к увеличенным таймаутам при хождении в бд
если отключить 1 сервер, второй будет работать как ни в чём не бывало, т.к. каждый сервере использует свой localhost сервер.
В моей схеме, каждый сервер = самостоятельный локальный сервер, который при наличии сети с другим, превращается в реплицируемый сервер.

[Константин]

> Но есть исключение - если сделаете L2VPN или типа того.
подскажите, правильно ли я понял, что L2VPN будет работать, только если это сеть одной компании. Если я покупаю сервера в разных двух компаниях/датацентрах, то услуга не сработает?

[Георг Гаал]

> Если я покупаю сервера в разных двух компаниях/датацентрах, то услуга не сработает?

если договоритесь с самим цодом (цодами) - тогда да. Ну, или сделаете туннель поверх туннеля. Только вот дело в том, что не нужно пытаться строить избыточно сложные конструкции - они не надежны, а лучше работают простые решения.

[Константин]

Георг Гаал, про простые решения - да я к этому уже и сам пришёл, чем проще, тем лучше, как мой вариант :)
Если кто наткнётся на этот пост, то вот видео про простые решения репликации - https://www.youtube.com/watch?v=WM_dNIOSgkk
Для интереса и развития, всё равно хочется узнать какие варианты есть ещё.

Георг, а подскажите тогда ещё момент. Т.е. получается, что ip адрес можно перекидывать между ЦОДами разных компаний, правильно? но для этого надо договариваться между самими ЦОДами?
И я так понял, что этот IP должен быть моим, купленным, правильно?
Это я так общую картинку вырисовываю, как это работает.