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

Фронты в одной сети? keepalived подойдёт?

Фронты в одной сети?

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

AWS Route53 и Health checks, из разряда «работает из коробки за не слишком уж большие деньги».

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

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

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

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

Мне кажется, что мысль о том, что несколько A записей не помогут неверна. Обычно при проблемах с подключением приложение просто использует следующую запись.

http://www.tenereillo.com/GSLBPageOfShame.htm

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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