Comments 41
Да, но...
1) если ваш сервер сервер упадёт при сохранении физической доступности DNS, то будет ой. Причем, во можете сами захотеть вывести из работы один из серверов на время. Нужно будет все равно городить мониторинг и исправление зон, а тогда уже лучше сделать одного мастера, а уже в случае его недоступности, пусть клиенты стучатся куда получится.
2) кэширование DNS нужно отключить или сделать очень небольшим, а это замедляет доступ к ресурсам и повышает нагрузку на сам DNS. К тому же уменьшение времени кэширования запросов перемещает точку отказа вверх к DNS серверу.
Вы, видимо, невнимательно читали и не поняли сути изложенного.
если ваш сервер сервер упадёт при сохранении физической доступности DNS, то будет ой
Это буквально одни и те же машины.
Причем, во можете сами захотеть вывести из работы один из серверов на
время. Нужно будет все равно городить мониторинг и исправление зон
Если на машине не отвечает её coredns, то трафик на неё не пойдёт. Об этом явно сказано в самом последнем абзаце.
кэширование DNS нужно отключить или сделать очень небольшим, а это замедляет доступ к ресурсам и повышает нагрузку на сам DNS.
Расскажите всем вендорам DNS-based GTM-ов, что они какой-то неправильный сервис сделали.
п.1 то же сразу бросился в глаза.
Схема в части обработки отказов будет работать только при полной недоступности всей ноды. Если отвалится только полезная нагрузка - DNS всё равно будет кидать "на себя" коннекты, в пустоту.
Очень длинное вступление, очень много текста - но фактически предложен ещё один костыль. <>Тут должна быть картинка с троллейбусом из буханки хлеба</>
Увы, чудес не бывает...
Схема в части обработки отказов будет работать только при полной
недоступности всей ноды. Если отвалится только полезная нагрузка - DNS
всё равно будет кидать "на себя" коннекты, в пустоту.
Согласен, здесь есть пространство для улучшений. Желательно добиться, чтобы DNS там гасился в таких случаях. Однако haproxy или nginx редко сами по себе падают с концами, либо будут просто перезапущены systemd. По этой части риски минимальные.
Это не кластер высокой доступности, а не понятно что: при падении сервиса, пока запись в кеше DNS не "стухнет", юзеры будут резолвить "упавший" IP. При этом многие DNS сервера не обращают внимания на TTL зоны, а используют свои значения, чтобы снизить нагрузку. То есть время переключения клиентов на рабочий сервер вообще не прогнозируется.
Это не кластер высокой доступности, а не понятно что: при падении сервиса, пока запись в кеше DNS не "стухнет"
AWS Route53 работает так же, используя TTL в 30 секунд. Время переключения клиентов хорошо известно.
30 сек недоступности, это не равно "кластер высокой доступности". Ну никак. Вводите людей в заблуждение.
Опять же 30 сек - это Ваш TTL, некоторые операторы не обращают внимания на TTL зоны и резолвят из кэша по своему усмотрению (тут и прописывание DNS гугла часто не помогает, так как оператор перехватывает DNS запросы - про QUIC не говорим пока). Или в AD/прокси (если про корпоративных пользователей) прописывают жестко время жизни записей.
Ну, опять же, скажите AWS тогда с их Route53 и вендорам всех других GTM, основанных на DNS, что они какой-то не такой продукт выпустили.
А какое отношение route53 имеет к кластерам высокой доступности?
DNS failover к высокой доступности имеет отношение весьма опосредованное из-за кэширования промежуточными DNS-серверами. Более того, этот файловер работает гораздо медленее, чем просто перебор A-записей клиентом. Сервис высокодоступной балансировки у амазона называется ELB.
DNS failover к высокой доступности имеет отношение весьма опосредованное из-за кэширования промежуточными DNS-серверами
И всё-таки имеет прямое отношение.
Более того, этот файловер работает гораздо медленее, чем просто перебор A-записей клиентом.
Нет. Может быть разве что при условии, что 1. клиент перебирает адреса (что обычно так для HTTP-клиентов, но в общем случае это не так), 2. Сбойный сервер будет не таймаутить, а слать TCP-reset.
Более того, в случае отказа предложенная мной схема через ~30 секунд приведёт всё в норму для всех без дополнительных задержек на каждый запрос, а схема с перебором A-записей так и будет таймаутить для части запросов.
На хабре, кстати, тоже есть статьи про него: https://habr.com/ru/post/122238/
Вот именно, что время переключения хорошо известно.
Long story short: DNS TTL is a lie. Even though we have TTL of one minute for www.dropbox.com, it still takes 15 minutes to drain 90% of traffic, and it may take a full hour to drain 95% of traffic
Выглядит примерно вот так:
Источник: https://dropbox.tech/infrastructure/dropbox-traffic-infrastructure-edge-network
решение неплохое.
Теперь нам нужна босяцкая междатацентровая симметричная репликация БД
А что мешает настроить anycast на lvs (ipvs)? Для этого даже не надо владеть своей AS.
Не совсем понял сути вашего предложения. LVS это сам по себе лоадбалансер, кто или что будет подавать или не подавать нагрузку на него?
Нагрузка идёт из канала на оба сервера сразу, далее на серверах в дело вступает динамическая маршрутизация для ipvs адресов, которые вы можете разместить на локальных петлях. Здесь в данном случае ipvs это балансировщик (может выполнять эту роль), а lvs название комплекса ПО. При этом всё что делает ipvs можно как всегда реализовать другим путём, отдельным сетевым неймспейсом и адресом на петле. А для синхронизации сетевых состояний используется conntrackd.
Так а почему она пойдёт на оба сервера сразу? В обычных условиях роутер направит трафик для конкретного IP-адреса на конкретный MAC, который подключён через конкретный порт. Что по итогу шлёт трафик для одного IP или VIP на оба сервера сразу?
Через мультикаст получает трафик, далее уже ipvs эникастом через динамическую маршрутизацию отправит пакет на сервис. Сервис уже дубли сбрасывает, за счёт избыточности повышается надёжность.
За счёт кэширования ответов (в первую очередь на клиентах), long tail-drop может составлять минуты, иногда часы (вот тут есть хороший пример: https://www.youtube.com/watch?v=Hh9Ibckztds). Т.е. использовать DNS для HA можно только в очень специфических сценариях типа ConsulDNS
Использование своей AS доступно не только операторам, но и вполне себе обычным компаниям. Основные затраты - аренда IP-адресов.
2 - ну, например в РФ вам потребуется лицензия сетевого оператора для этого. Что проще, получить AS, блок адресов, пириться с кем-то или просто установить демон на две виртуалки? Как по мне так вообще даже не сравнимо.
Не потребуется, т.к. нет факта предоставления услуг по передаче данных. Да, РКН убедительно попросит завести ЛК в ЦМУ ССОП и ещё пару телодвижений, но именно лицензии (и связанных с этим обязательств, типа установки СОРМ) не потребуется.
Собственно, вопрос всегда в том, какую цель вы хотите достичь (например, доступность сервиса 99,99% времени в год), какой у вас на это есть бюджет и какая экспертиза (в крайнем случае, её можно купить). Создание "кластера высокой доступности", в общем случае, не решается установкой "демонов на две виртуалки".
Вы просто описали вариант балансировки нагрузки с помощью DNS с возможностью быстрого вывода из ротации в случае необходимости - он рабочий и довольно "дешёвый", но имеет ряд ограничений, и их нужно учитывать.
Интересное решение.
Вот ещё одна идея: на каждом сервере через крон чекать соседа и в случае фейла - через api днс провайдера удалять А запись соседа 🙃
Босяцкий keepalived? ;-)
Не взлетит. Нужен третий наблюдатель и голосование 2 из 3. Если сервис видит ненорму второго сервиса и наблюдатель это подтверждает, то только тогда сервис перенастраивает DNS на себя. Иначе это сделать просто невозможно.
Как это невозможно? Как это не взетит?
В ДНС две А записи на домен - 10.0.0.1 и 10.0.0.2
На 10.0.0.1 крутится крон, который запрашивает у 10.0.0.2 главную страницу.
На 10.0.0.2 крутится крон, который запрашивает у 10.0.0.1 главную страницу.
Если 0.1 не ответит 0.2 - то 0.2 удалит из ДНС запись.
Если 0.2 не ответит 0.1 - то 0.1 удалит из ДНС запись.
Тут же решение из разряда "на коленке" - сервер чекает соседа и удаляет о нем запись если сосед не ответил.
Если нам нужен кворум, какая-то защита от дурака (когда 0.1 не видит 0.2, но 0.2 работает) то да, уже схема так себе :)
А если мне нужна условно "высокая" доступность?
Скажем, если какой-то клиент не будет видеть сервер N минут, где N >= TTL, то это не критично.
То какие еще варианты реализации есть, кроме как самому рулить DNS? На своем хостинге или через API - неважно.
Весёлая статейка, автор видимо не дождался первого апреля :). И кто так сделает - дуралей.
Объясняю - ещё лет 15-20 назад мне пришлось отказаться от стандартной схемы резервирования dns для клиентов (это где клиенту прописываем несколько серверов). Причина проста - если лёг первый DNS то клиент ждёт некое положенное время (заложено в операционке) и лезет к следующему серверу. Так вот этот значение этого таймаута выбирается с рациональной целью не зафлудить сеть и сервера запросами, поэтому он хоть и выглядит небольшим, но довольно ощутимый. Далее ответы сервера кэшируется на время ttl записи, но всё равно, при казалось-бы нормально работающем оборудовании, эта задержка при обращении к новому серверу напрягает конкретно и даёт ощущение офигенных тормозов сети.
У меня всё решилось созданием простейшего кластера высокой готовности для DNS, там ещё пяток сервисов кластеризовалось без напрягов, включая балансировщик нагрузки.
ЗЫЖ Схемы в аскях - такое было популярно в моей фидошной молодости (особенно в хаутушках) и в различных RFC :)
О, я такое делал в 2007-м.
Босяцкий кластер высокой доступности