Комментарии 15
У "гигантов" DNS в RR - это эникаст адреса, которые в первую очередь делают шардирование, а не резервирование. Т.е. они отдают пачку адресов, которые ведут на пачку серверов, чтобы если конкретный сервер воспламенился, то это задело не всех, а только запросы части клиентов.
Нормальное резервирование высокого уровня делают с участием сети. Например, делают ibgp на пачку серверов, у которых med разный. Как только предыдущий победитель сдох, автоматически есть следующий, и переключение занимает единицы секунд (или даже меньше).
Попробуйте BGP балансировку. Она гораздо более управляемая, чем DNS.
Одна и та же /24 подсеть анонсируется с обоих площадок в интернет. ip адрес сайта входит в эту /24 сеть. Дальше ваши сетевые инженеры уже подкрутят распределение трафика между площадками. Хоть active/standby, хоть 50/50.
Можно настроить одну площадку, как active, а вторую, как standby. Это удобно с точки зрения того, где держать мастер БД.
Кстати, правильная DNS балансировка - это когда какой-то сервис чекает доступность площадки. И отдает ее IP адрес, только если она живая. Как в кубере, например.
Как с bgp-балансировкой и вышеуказанной схемой предлагаете обрабатывать перестроение машрутов у клиентов? Судя по ripestat это довольно часто происходит. Представьте что посередине tcp-сессии у кого-то на пути трафика поменялись приоритеты и трафик клиента полетел на другую площадку на другой сервер, которому это tcp-соединение совершенно незнакомо.
Я примерно представляю как это решается, но в вашей схеме с "ip адрес сайта входит в эту /24 сеть" это не особо очевидно.
Судя по ripestat это довольно часто происходит.
Смотря что считать "часто". Например, раз в сутки или раз в неделю - это часто или нет?) На ровном месте маршруты не меняются так, чтобы трафик всея рунета стал течь в другой ДЦ. Это какие-то изменения или аварии. А они происходят не так часто. Кроме того, у сетевых инженеров огромные возможности для управления анонсами для разных сетей.
С другой стороны, web - это на 99% короткие tcp сессии. Время их жизни измеряются секундами, не минутами. Браузер умеет в переповторы. Поэтому, клиенты почти не чувствуют результатов перестроений.
Я это рассказываю, имея опыт нескольких лет работы в ivi.ru. Там годами используются и несколько ДЦ, и CDN в десятках городах. И все работает не основе анонсов сетей по BGP.
Ну вот сейчас посмотрел для https://stat.ripe.net/widget/bgplay#w.resource=91.233.218.122 и это 242 события за два дня. Понятно что не все приведут к тому что трафик полетит в другой ДЦ и если не мониторить те же rst-пакеты, то про проблему можно и не заметить. Опять же если это статика, наверное даже клиенты не всегда её замечают или просто перезагружают страницу. Для statefull клиентов она заметна сильнее.
Что самое плохое - чтобы заметить её надо знать что она моет проявиться и кто в группе риска. В основном это клиенты, которые находятся где-то посередине между двумя ДЦ. Более того, подобную проблему находил и репортил гуглу с их глобальными ип-адресами.
Лично я всегда рассматривал балансировку BGP с оффлоадом tcp сессий на какой нибудь машине(ах) с lvs (linux virtual server) с сервисом conntrackd (синхронизация состояния tcp). В современном мире, по возможностям бизнеса, я бы заменил conntrackd на DPDK, так производительней и контролируемость выше.
Мне кажется глобальное отслеживание соединений, когда имеешь датацентры по всему миру, будет накладным (если вообще будет работать). Я думал о каком-то L4-балансировщике в каждом ДЦ, который бы уже роутил трафик в нужный датацентр, используя какое-то общее правило для всех балансировщиков по всем датацентрам. Например, используя geoIP БД, приземлять трафик пользователя в принадлежащий ему регион, вне зависимости от того в какой регион прилетел трафик. Отслеживание соединений в этом случае будет работать только в пределах одного ДЦ (или одного L4/L7 балансировщика в одном ДЦ для раскидывания по локальным апстримам).
А как это делают крупные игроки на самом деле я не знаю.
Google DNS 8.8.8.8 больше не поддерживает DNS RR
https://habr.com/ru/company/southbridge/blog/282638/
DNS Round Robin has never been an effective means of load-balancing, and is less so today, as applications switch from gethostbyname to getaddrinfo for IPv6 support
Попробуйте вот так LB
Действительно ли глобальные балансировщики так часто падают, чтобы нужно было изобретать свой велосипед?
Чем, например, плохо решение поставить TTL 5 минут, и в случае проблем - перевести DNS-записи на статику? Или как раз эту проблему и пытаетесь решить наперёд?
Как один из вариантов простого решения - использования службы типа Azure Traffic Manager - он делает именно DNS-резолв в нужный датацентр в зависимости от заданных параметров (в т.ч. доступности ДЦ). Сам же HTTP трафик будет идти напрямую от клиента в датацентр.
Ну и наконец если и этот вариант не подходит - можно достаточно просто соорудить эту конструкцию с помощью NS-серверов, например:
www.sportmaster.ru -> (CNAME) www.dc-selector.sportmaster.ru (это отдельный под-домен)
Зона dc-selector должна иметь 2 NS: по одному в каждом DC.
Соответственно, NS для этой зоны будет отдавать только IP своего DC:
www.dc-selector.sportmaster.ru (из DC1) -> x.x.1.1 (IP DC1)
www.dc-selector.sportmaster.ru (из DC2) -> x.x.2.1 (IP DC2)
Если DC1 недоступен, то ответит только NS из DC2, и отрезолвит в правильный IP
Таким образом выбор DC будет осуществляться рекурсивным резолвером, а клиент будет получать готовый результат.
Единственное "но" - это опять изобретение велосипеда - того же Traffic Manager.
Резервирование резервирования. Как я наш интернет труба шатал