Избыточность с несколькими серверами на одном DNS

Избыточность с несколькими серверами на одном DNS

У меня есть доменное имя типа api.test.com. У меня также есть три сервера.

Мне нужно обеспечить избыточность между этими двумя серверами, чтобы если один сервер отключен, доменное имя api.test.comне перенаправлялось на него, а только на другие.

Я обнаружил, что мы можем иметь несколько записей A/ AAAAдля одного и того же доменного имени, но это не учитывает, пингуется компьютер или нет, а просто случайным образом выдает один из всех доступных IP-адресов.

Как мне сделать, чтобы иметь избыточность с ним? Должен ли я получить другой сервер, который перенаправляет все запросы, например прокси?

решение1

Нет, это не так работает. Вы можете настроить более одной записи определенного типа и имени в зоне. Клиент обычно не знает об этом; он запрашивает определенное имя и тип (например, браузер запрашивает имя, которое вы ввели в адресную строку, типа A, AAAA).

Если возвращается более одной записи, он выбирает одну наугад и пытается подключиться к ней. Клиенту нужно повторить попытку подключения к другой записи, если она там есть. Серверы также поощряют такое поведение, отвечая на один и тот же запрос с разным порядком записей каждый раз. Поэтому даже если какой-то клиент «всегда выбирает первую», рандомизация на сервере все равно происходит. Таким образом достигается примитивная форма балансировки нагрузки.

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

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


DNS обеспечивает избыточность совершенно другим механизмом, опять же, ожидая достаточно умного клиента. Существуют специальные типы записей DNS, называемыеСРВ(услуга), которая имеет 4 поля данных: приоритет, вес, порт, имя.

Имя — самое простое: имя записи A, которую описывает эта запись SRV. Порт — это порт TCP или UDP, на котором запрашиваемая служба находится на сервере с этим именем. Это должно быть имя, с которым связана запись A или AAAA; CNAME не допускается. Если для этого имени существует более одной записи A или AAAA, у нас будет обычное поведение DNS «попробовать один раз» для этой конкретной записи SRV (но клиент должен попробовать другие записи SRV, если таковые имеются, например, с более высокими значениями приоритета).

Вес позволяет более глубоко контролировать балансировку нагрузки: если есть несколько записей с одинаковым приоритетом, клиент должен попытаться распределить нагрузку в соответствии с их весами. Часто это делается вероятностно.

Приоритет нужен для избыточности: сначала нужно попробовать записи с наименьшим значением, затем с приоритетом и т. д. Но повторная попытка снова остается на усмотрение клиента.

Запись выглядит так:

_kerberos._tcp.example.net. SRV 0 100 88 dc.example.net.

Подчеркивания на самом деле являются буквальными подчеркиваниями в имени записи. Это говорит о том, что служба "kerberos" обслуживается по протоколу TCP на порту 88 dc.example.net. dc.example.net должна быть записью A или AAAA. Этот пример взят из MS Active Directory, которая в значительной степени полагается на DNS для правильной работы и использует его для ldap (каталог) и kerberos (инфраструктура безопасности). Если у вас более одного контроллера домена AD, таких записей будет больше, указывающих на разные контроллеры домена.

Этот тип записей используется, например, для ldap, kerberos, kpasswd (изменение пароля Kerberos), xmpp (jabber), sip (IP-телефония) инекоторые другиеуслуги.

МХэто как "особый случай SRV", который привязан к порту 25 и имеет только поле "приоритет", без "веса". Это просто "старый стиль", который был изобретен до SRV (и который его вдохновил). И он используется только для электронной почты.

SRV не может помочь вам с веб-сервисами. Он помогает только для сервисов, где клиент знает, что нужно использовать запись SRV для обнаружения сервера; веб-клиенты никогда этого не делают.

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