В качестве ответа на его очень популярный вопрос: Почему отказоустойчивый DNS не рекомендуется?Я думаю, было решено, что отказоустойчивость DNS не на 100% надежна из-за кеширования.
Однако в ответе, получившем наибольшее количество голосов, на самом деле не обсуждалось, какое лучшее решение для переключения при отказе между двумя разными центрами обработки данных. Единственное представленное решение - это локальная балансировка нагрузки (единый центр обработки данных).
Так что мой вопрос очень прост: каково реальное решение для переключения при отказе центра обработки данных?
Это началось как комментарий ... но становится слишком длинным.
К сожалению, большинство ответов на предыдущий вопрос ошибаются: они предполагают, что переключение имеет какое-то отношение к TTL. Ответ, получивший наибольшее количество голосов, ЗНАЧИТЕЛЬНО неверен и, в частности, не содержит ссылок на источники. TTL применяется к записи зоны в целом и не имеет ничего общего с циклической переборкой.
Из RFC 1794 (который посвящен Round Robin DNS сервировка)
There is no use in handing out information with TTLs of an hour [or less]
(IME ближе к 3 часам, прежде чем вы получите полное распространение).
Из RFC 1035
When several RRs of the same type are available for a
particular owner name, the resolver should either cache them
all or none at all
В RFC 1034 изложены требования для отрицательного кэширования - метода, указывающего, что все запросы должны обслуживаться только что с полномочного DNS-сервера (в этом случае TTL действительно управляет переключением при отказе) - по моему опыту, поддержка для этого варьируется.
Поскольку любой отказоустойчивый процесс должен быть реализован в клиентском стеке, он, вероятно, не является частью TCP / IP или DNS - в действительности, SIP, SMTP, RADIUS и другие запущенные протоколы. наверху TCP / IP определяют, как клиент должен работать с циклическим перебором - RFC 2616 (HTTP / 1.1) примечателен тем, что не упоминает, как он должен себя вести.
Однако, по моему опыту, каждый браузер и большинство других HTTP-клиентов, написанных за последние 10 лет, будут прозрачно проверять дополнительные записи A RR, если соединение занимает больше времени, чем ожидалось. И это не только я:
Время восстановления после отказа зависит от реализации, но находится в пределах секунд. Это не идеальное решение, поскольку (из-за ограничений DNS) публикация отказавшего узла требует TTL DNS - в то же время вы должны полагаться на обнаружение на стороне клиента.
Round-Robin не заменяет другие механизмы высокой доступности. в пределах сайт. Но он дополняет его (ребята, написавшие HAProxy, рекомендуют использовать пару установок, доступ к которым осуществляется через циклический DNS). Это лучший поддерживаемый механизм для реализации высокой доступности на нескольких сайтах: действительно, насколько я могу определить, это единственный поддерживаемый механизм аварийного переключения, доступный на стандартных клиентах.
Чтобы это применило, весь центр обработки данных должен был выйти из строя или стать недоступным. Тогда ваша резервная копия в другом центре обработки данных будет доступна путем маршрутизации IP-адресов в другой центр обработки данных. Это могло произойти из-за того, что объявления маршрута BGP от основного центра обработки данных больше не предоставляются. Затем будут использоваться вторичные объявления из вторичного центра обработки данных.
Небольшие предприятия, как правило, недостаточно велики, чтобы оправдать расходы на выделение переносимых IP-адресов и собственный номер автономной системы для объявления маршрутов BGP. В этом случае поставщик будет использовать несколько мест.
Вы должны быть доступны либо через ваши исходные IP-адреса, либо через изменение IP-адреса через DNS. Поскольку DNS не предназначен для этого способами, необходимыми для того, что означает «аварийное переключение» (пользователи могут быть вне досягаемости, по крайней мере, до вашего TTL или TTL, установленного некоторыми серверами кэширования), переход на сайт резервного копирования с одинаковые IP-адреса - лучшее решение.
Простейшим подходом к двойному резервированию DC будет L2 MPLS VPN между двумя сайтами, а также поддержание сеансов BGP между ними.
По сути, вы можете просто иметь физический IP-адрес для каждого сервера и виртуальный IP-адрес, который перемещается между ними (HSRP / VRRP / CARP и т. Д.). Ваш DNS будет направлен на этот конкретный IP-адрес и направлен соответственно.
Следующим соображением будет разделение мозга, но это другой вопрос в другой раз.
Juniper написал хороший технический документ о двойном управлении DC с помощью MPLS, вы можете скачать PDF здесь http://www.juniper.net/us/en/local/pdf/whitepapers/2000407-en.pdf