LINUX.ORG.RU
ФорумAdmin

Есть мысли по резервированию гейта?

 , , ,


1

3

У меня в процессе проработки структуры полностью резервированного распределённого сайта возникла проблема. Суть в чём. Компоненты сайта (БД, файлопомойки, код) все дублированы, раскиданы по разным контейнерам на разных машинах. Могут переноситься с машины на машину и т.п. С момента прохождения через nginx на фронтенте, дальше всё понятно. И nginx может выбрать работающий бэкенд, и код может определить доступность базы и при отказе переключиться на другую. Но вот точка входа, фронтенд, получается одной. Куда DNS указывает, туда всё и идёт. Пропись мульти-IP тут не поможет, при падении кому-то выпадет живой IP, а кому-то — убитый.

Приходит в голову костыль, типа размещения NS-серверов вместе с фронтендами и выдача своих же IP. Тогда, при падении сервера, данный NS отвалится и отвечать будут другие, уже с другими IP. Но это совсем костыль :)

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

Есть что-то более правильное?

★★★★★

Ответ на: комментарий от Komintern

из коробки за не слишком уж большие деньги

Не. Нужен опенсорс бесплатный. Это не для коммерческих целей :)

KRoN73 ★★★★★ ()

И остаётся проблема времени распространения изменения DNS.

А какого оно будет, если будет TTL0?

DALDON ★★★★★ ()

Есть что-то более правильное?

Если по-взрослому — то это будет carp и сородичи. Ещё тут.

Если в краце, то один из сценариев: при падении одного gw, другой забирает себе его ip. Юзвери ничего не замечают.

beastie ★★★★★ ()
Последнее исправление: beastie (всего исправлений: 1)
Ответ на: комментарий от DALDON

А какого оно будет, если будет TTL0?

Зависит от левой ноги админа, настраивавшего кеширование локального DNS провайдера. Бывало, что при TTL=10 минут у некоторых довольно крупных московских провайдеров оно до суток ещё старый IP отдавало. Да и Google со своим 8.8.8.8 на столь малые величины кладёт. Иногда часы зона обновляется.

KRoN73 ★★★★★ ()
Ответ на: комментарий от astupnikov

Обычно при проблемах с подключением приложение просто использует следующую запись.

Надо будет проверить, спасибо.

KRoN73 ★★★★★ ()
Ответ на: комментарий от beastie

при падении одного gw, другой забирает себе его ip

Не получится. Разные сети, разные хостеры.

KRoN73 ★★★★★ ()

На прошлой работе была точно такая же задача. Очень долго ломал мозг и пришел к самому простому и отказоустойчивому решению (ИМХО). 3 фронтенда и 4 IP. Естественно все они в одной сетке. «A» запись домена смотрит на один конкретный IP. Использовал legion из комплекта uwsgi. У каждой ноды есть свой вес. Если одна из них не отвечает либо по какой-то причине uwsgi не отдает нужный ответ, между оставшимися живыми нодами проходят дебаты. Живая нода и с большим весом выигрывает, на всякий пожарный делает ARP бродкаст на предмет «есть ли где-то главный IP?». Если нет, поднимает его у себя, оповещает роутер мол теперь этот IP у меня и сообщает всем остальным нодам мол теперь я master. Если поднимается лежавшая нода, она проводит селф-тест и если все ок то перетаскивает главный IP на себя. Чтоб небыло колизий серваки чекают по внешней и внутренней сети. Все это замечательно работало долгое время. Потом, со временем, нагрузка стала очень больная и я сделал точно такую же схему только из 4-х серверов, 2-х рабочих IP ну и естественно две «A» записи домену. И это не значит что когда два работают и два других отдыхают. Два других являются бекендами для первых двух. Там еще была балансировка при помощи haproxy на бекенды + Galera Cluster. В общем, схема запутанная, но зато любым двум тачкам можно было сделать hard reset и все продолжит работать без сбоев. А когда загрузятся, починятся и перетащат функционал на себя.

Ах да... Вдруг инет в ДЦ упадет. Это я предусмотрел еще на этапе выбора ДЦ, у которого 3-5 включений инета с внутренней балансировкой при перегрузах, миграцией при ДоС-е и прочими плюшками.

iron ★★★★★ ()
Ответ на: комментарий от KRoN73

В разных. Суть в том, чтобы система работала даже при падении одной из сетей :)

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

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

anto215 ★★ ()
Ответ на: комментарий от anto215

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

да, верно.. этоже для клиентской стороны стандартное решение на основе функции getaddrinfo(...).

таким же образом решается и проблема гибридных IPv6+IPv4 серверов — (клиент попробовал подрубиться по IPv6, не вышло, затем попробовал по IPv4)

user_id_68054 ★★★★★ ()

gdnsd умеет в проверки серверов пуле, например.

Ip0 ★★★★ ()
Ответ на: комментарий от anto215

Забавно. Добавил сейчас на Cludflare две A-записи на одно имя. Выдаётся то две записи в случайном порядке (такое поведение, и ожидалось), то одна, первая по порядку в списке.

Жаль, что нельзя указать приоритет выдачи IP-адресов. Для распределёной системы подходит, а вот для резервирования (когда обычно вся нагрузка на одной машине, а вторая вызывается только при отказе первой) — нет.

KRoN73 ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.