Как настроить решение высокой доступности на уровне DNS?

Как настроить решение высокой доступности на уровне DNS?

Я купил домен на namecheap и настроил в клиентской панели свои личные NS-серверы:

ns1.example.com

ns2.example.com

1) В случае недоступности сервера ns1, все запросы по-прежнему приходят на ns1 или все они приходят на сервер ns2? Как настроить резкое переключение для всех запросов, если ns1 или ns2 становятся недоступными?

2) После NS-серверов ns1/2 у меня есть балансировщики нагрузки на случай, если один из LB останется недоступен, как настроить ns-сервер для проверки этого состояния (какое приложение использовать - bind или другое, может быть есть какой-то API или можно настроить его так, чтобы он перенаправлял все запросы только на работающий LB)?

решение1

1) В случае недоступности сервера ns1 все запросы поступают на ns1 или все они поступают на сервер ns2?

Нет, DNS так не работает. Он по умолчанию обеспечивает балансировку нагрузки, а не отказоустойчивость.

DNS имеет дело с наборами записей ресурсов. Не списками, а наборами. Списки упорядочены, наборы — нет.

Набор серверов имен для доменного имени содержит все имена, которые являются авторитетными для этого домена. Иначе говоря: если example.orgесть ns1.example.comиns2.example.com тогда оба сервера будут статистически получать 50% всех запросов в любое время. ЭтоНЕТ100% для ns1и только тогда, когда он терпит неудачу, он переходит на 100% к ns2.

Итак, 50% запросов на каждый, но что происходит, если один перестает отвечать по какой-либо причине: тогда резолвер переключится на другой, но только после того, как запросит его, потому что он не может знать, когда тот перестал отвечать, и он также должен регулярно проверять тот, который не отвечает, чтобы определить, когда он снова появится в сети. Это означает, что разрешение произойдет, но просто займет больше времени, потому что алгоритм будет первым: - спросить ns1 - подождать некоторое время - снова спросить ns1 - подождать некоторое время - и в какой-то момент (время ожидания между двумя запросами и количество повторных попыток часто настраивается и отличается в каждом программном обеспечении) он переключится на ns2и, следовательно, наконец получит ответ.

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

В настоящее время "высокая доступность DNS" обычно обеспечивается с помощью технологии anycast: серверы имен разрешают IP-адреса, которые anycasted в различных местах. Это обеспечивает как лучшую производительность за счет более "локального" доступа, так и автоматическое аварийное переключение (но из-за функции IP, а не конкретной функции DNS), поскольку другой узел будет забирать трафик, если какой-то не отвечает, из-за того, как работает BGP. Следовательно, не будет создаваться цикл тайм-аута и повторных попыток, изображенный выше.

После NS серверов ns1/2 у меня есть балансировщики нагрузки

Мне не ясно, но в любом случае не ставьте балансировщики нагрузки или что-то еще перед серверами имен. Чаще всего они создают больше проблем, чем предлагают решений (потому что они часто реализуют очень узкое подмножество протокола DNS и, следовательно, создают проблемы взаимодействия).

может быть есть какой-то API

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

решение2

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

Клиентам обычно назначается первичный, вторичный и в некоторых случаях третичный и далее поставщик DNS для использования в их локальной конфигурации IP. В случае, если у клиента еще нет кэшированной записи (на основе его времени жизни (TTL)) и он не может связаться со своим первичным поставщиком DNS во время запроса, он начнет работать через вторичного поставщика и далее до достижения своего интервала ожидания. Правильный способ думать об этом первичном-вторичном поставщике DNS клиента — это относительная версия активной-пассивной высокой доступности.

Современные решения по балансировке нагрузки, особенно высококлассные физические устройства, обычно имеют проверки работоспособности (обычно называемые «зондами»), которые можно использовать для проверки статуса сервиса, как вы ищете. Вам придется обратиться к документации вашего поставщика для реализации. Однако имейте в виду, что если вашНС1иNS2не работают, а записи имен вашего балансировщика нагрузки предоставляются теми же поставщиками DNS, на которые ссылаются клиенты, то полагаться на балансировщики нагрузки на этом, по сути, третьем этапе отказа не даст вам ничего (за исключением удачного кэширования клиентских записей).

Связанный контент