У меня есть 3 сервера, на каждом из которых работает сервер имен и веб-сервер. Сегодня вышли из строя 2 сервера. Я думал, что с тех пор последний сервер будет обрабатывать все будущие запросы, но это, казалось, происходило лишь в небольшой части времени. В других случаях время ожидания запросов истекало.
На каждом из моих серверов есть записи о следующих зонах:
ns1 IN A <SERVER IP 1>
ns2 IN A <SERVER IP 2>
ns3 IN A <SERVER IP 3>
example.com. IN A <SERVER IP 1>
example.com. IN A <SERVER IP 2>
example.com. IN A <SERVER IP 3>
www IN CNAME example.com.
Должен ли я просто вести одну запись A для example.com на каждом сервере? Я хочу настроить свои серверы так, чтобы любой сервер мог прозрачно обрабатывать все запросы, если другие серверы выходят из строя.
Вероятно, произошло следующее: когда 2 из 3 вышли из строя, третий ничего не знал об этом и продолжал предоставлять записи A для отказавших серверов. DNS-сервер не будет отдавать предпочтение своему собственному IP-адресу в возвращаемом результате - в зависимости от программного обеспечения, он может выбирать в порядке или случайным образом из A-записей. Таким образом, 2 раза из 3 он вернет запись A на 2 сервера, которые вышли из строя.
Чтобы решить эту проблему полностью в DNS, вам понадобится какой-то балансировщик нагрузки DNS (либо в системах, либо в качестве стороннего устройства / службы).
Сохранение одной записи A на каждом DNS-сервере позволит каждому работать независимо, хотя вы можете столкнуться с огромной нагрузкой на первый сервер (по сравнению с двумя другими) по порядку (то есть: ns1 сопоставляется с server1 и имеет server1 A запись в этой зоне, скорее всего, это будет та, которую сначала опрашивают клиенты, и поэтому, если она активна, она получит почти весь трафик).
Итак, это будет РАБОТАТЬ, но может не работать так, как вы надеетесь.
Вы имеете в виду праймериз или резолверы?
Если это праймериз, их устраивает множество людей. Для резолверов в вашей собственной инфраструктуре отработка отказа проблематична, так как большинство библиотек резолверов просто пробуют все резолверы в порядке предпочтения. Неудачный 1-й преобразователь означает, что 2-й и 3-й преобразователи будут опробованы, но только после ужасно долгой задержки, которая сильно ухудшит производительность (для таких вещей, как почтовые серверы, которым необходимо выполнять разрешение имен на своем критическом пути выполнения).
Таким образом, избыточность - не единственная проблема, но постоянная доступная высокая производительность - нельзя допустить, чтобы производительность упала в случае отказа некоторых преобразователей. Сейчас мы используем LVS для балансировки нагрузки наших внутренних преобразователей, поскольку это доказало, что это единственный способ получить достаточную производительность и избыточность для разрешения имен больших томов.
Вы настроили Циклический перебор DNS; пока это обеспечит балансировки нагрузки, он не обеспечит прозрачного динамического переключения при отказе. Это связано с тем, что, когда клиенты запрашивают запись A 'example.com', хотя они получат все 3 IP-адреса сервера, они часто кэшируют один, который будет использоваться для будущих подключений к этому доменному имени. Даже если вы установите низкий TTL для своей зоны, в общедоступном Интернете вы не можете контролировать количество кэширующих преобразователей между вами и вашими клиентами, не говоря уже о том, какое кеширование записей DNS на уровне приложения может происходить на клиентском компьютере (Интернет Explorer, например, поддерживает собственный DNS-кеш).
Вы ищете инженера высокая доступность. Для этого потребуется либо аппаратное устройство, либо некоторая форма кластеризации программного обеспечения. Варианты оборудования включают Citrix Netscaler, F5 ig IP или Foundry NetIrons. Покупка собственного, скорее всего, будет непрактичной, если только вы не работаете на большом предприятии, где размещено множество приложений. Возможно, стоит проконсультироваться с вашим хостинг-провайдером, так как многие из них предоставляют доступ к общему устройству высокой доступности за дополнительную плату.
Варианты программного обеспечения включают Балансировка сетевой нагрузки Microsoft в Windows или Ucarp в Linux; не зная ваших точных требований и того, как выглядит ваша текущая инфраструктура, трудно быть более конкретным. Есть еще несколько вопросов по научной фантастике, которые могут оказаться более полезными - ознакомьтесь с высокая доступность и кластеризация теги в частности.