Корректный способ настроить DNS, основной/вторичный / … для дублирования и сокращения задержки?

Существует действительно большое, хотя довольно технический документ "Лучших практик", который может оказаться полезным при борьбе с системным администратором. http://www.cisco.com/web/about/security/intelligence/dns-bcp.html

Если он не распознает законность статей, написанных Cisco, то Вы могли бы также прекратить спорить с системным администратором - повышаются уровень управления.

Много других документов "Лучших практик" рекомендуют разделить Ваши основные и вторичные серверы имен не только блоком IP, но и физическим местоположением. На самом деле RFC 2182 рекомендует, чтобы вторичные сервисы DNS были географически разделены. Для многих компаний это означает арендовать сервер в другом центре обработки данных или подписываться на размещенного поставщика DNS, такого как ZoneEdit или UltraDNS.

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

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

Лично, я убежден, что мы не единственная компания с этим видом проблемы и что это, скорее всего, уже - решенная проблема. Я не могу вообразить все те интернет-компании, затрагиваемые нашим видом проблемы.

Вы не единственная компания, и это было, вероятно, перехешировано миллион раз в компаниях во всем мире.

Однако я не могу найти хорошие документы онлайн, которые объясняют, что происходит в случаях возникновения отказов (например, клиентские тайм-ауты) и как работать вокруг них.

Какие аргументы я могу использовать для ввода по абсолютному адресу дыр в обосновании наших системных администраторов? Какие-либо ресурсы онлайн, с которыми я могу консультироваться для лучше понимания проблем, которых они требуют, существуют?

• Я говорю об авторитетном DNS для посторонних для нахождения наших серверов, не рекурсивных серверов DNS для наших локальных клиентов.

Можно сделать все виды вещей, включая установку внешнего сервиса DNS, который регистрируется как полномочия для зоны, но тайно создание (внешних) авторитетных вторичных устройств серверов к собственному (в) серверах DNS. Эта конфигурация ужасна, неправильно, шоу, что я - действительно злой SysAdmin, и котенок умирает каждый раз, когда я рекомендую это. Но это делает две вещи:

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

Причины, что это - неправильный поступок:

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

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

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

Если клиент собирается настоять на том, чтобы запрашивать определенный IP-адрес, игнорируя IP-адрес вторичного устройства (или требуя времени к тайм-ауту к нему), то просто необходимо предложить решение, которое сохраняет ту работу IP-адреса, даже если основной сервер снижается.

Некоторые направления для исследования были бы подсистемой балансировки нагрузки, которая может перенаправить трафик для единственного IP-адреса к нескольким серверам в различных дата-центрах; или возможно маршрутизация передачи любому из узлов.

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

Наша установка:

• 2 физических центра обработки данных (отдельные схемы, ISPs и восходящие поставщики)
• 2 физических сервера запроса в кластере позади SLB в каждом средстве
• 2 устройства выравнивания нагрузки для обслуживания определенных записей, из которых мы хотим управлять балансом между этими двумя центрами обработки данных
• скрытое ведущее устройство, внутренне доступное обоими кластерами сервера (я верю очень сильно в скрытые основные установки для безопасности),

Эта установка была достаточно эффективной, чтобы дать нам примерно 5 9's времени работы за прошлые 6 или 7 лет, даже со случайным временем простоя сервера для обновлений, и т.д. Если Вы готовы потратить несколько дополнительных долларов, можно посмотреть на произведенный на стороне хостинг зоны с кем-то как ultradns...

Относительно разговора загрузки, что упомянутый KPWINC, который на 100% корректен. Если Ваш самый маленький центр обработки данных не может обработать 100% Вашей загрузки, то Вы, вероятно, сняты с костей так или иначе, потому что Ваше отключение электричества собирается произойти, когда Вы меньше всего хотите это =)

Я беру максимальную нагрузку от всех своих граничных маршрутизаторов, добавьте их всех вместе и затем разделитесь на 0,65..., который является минимальной пропускной способностью, которую мы должны иметь в каждом центре обработки данных. Я поместил то правило в место приблизительно 5 лет назад, с некоторыми документами для выравнивания по ширине его я собрался из CCO и об Интернете, и оно никогда не приводило нас к сбою. Однако необходимо проверить ту статистику, по крайней мере, ежеквартально. У нас было наше транспортное увеличение почти 3 сгиба между ноябрем и февралем в прошлом году, и я не был подготовлен к нему. Та положительная сторона - то, что ситуация действительно позволяла мне генерировать некоторые очень ясные точные данные, который говорит при 72%-й нагрузке на нашу схему WAN, мы начинаем отбрасывать пакеты. Никакое дополнительное выравнивание никогда не требовалось меня для большего количества пропускной способности.

Я понял от чтения Вашего описания, что не ясно, означаете ли Вы авторитетный DNS для посторонних находить Ваши серверы или рекурсивные серверы DNS для Ваших локальных клиентов. Поведение тех двух очень отличается.

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

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

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

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

Thomas,

После чтения Вашего обновления я пересмотрел свое сообщение (предыдущее сообщение имеет ссылку на программное обеспечение Windows).

Это почти звучит мне как Ваш системный администратор (администраторы), говорят Вам, что Ваше вторичное местоположение не имеет необходимых аппаратных средств для обработки ПРЕДЕЛЬНОЙ НАГРУЗКИ?

Кажется будто он говорит, "Эй приятель, если наше основное местоположение (который включает основной DNS) спускается затем по DNS, является НАИМЕНЬШИМ КОЛИЧЕСТВОМ наших забот, потому что, если COLO1 снижается затем, COLO2 не может обработать загрузку так или иначе".

Если это так, затем я предложил бы, чтобы Вы просмотрели свою инфраструктуру и попытались придумать лучший дизайн. Это легче сказать чем сделать, особенно теперь, когда Вы живы в продуктивной среде.

Все, что в стороне, в идеальном мире, COLO1 и COLO2 смогли бы к одинокому и обработали бы Вашу загрузку.

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

Я использовал этот метод в маленьком к разумным размерным средам, и он работает отлично. Обработка отказа обычно занимает меньше чем 10 минут.

Просто необходимо удостовериться, что серверы DNS могут обработать дополнительную загрузку короткого TTL (время жизни).

Надеюсь, это поможет.

Ваши системные администраторы (главным образом) неправы.

Рекурсивные серверы, которые запрашивают Ваши авторитетные серверы, заметят очень быстро, если любой сайт будет безразличен.

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

При необходимости (для успокоения системных администраторов) продолжают выполнять два сервера в первичном информационном центре, но действительно помещают по крайней мере еще одну внешнюю сторону.

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

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

Различные клиенты реагируют другими способами к серверам DNS, не являющимся доступным, таким образом, существует некоторая истина клиентам, испытывающим таймаут, но не всем.

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

К сожалению, DNS-распознаватель Linux, похоже, не имеет прямой поддержки для обнаружения и отработки отказа для DNS-серверов. Он продолжает подавать запросы на ваш первичный разрешающий сервер имен, ждет установленного тайм-аута, повторяет попытки и т. Д.

Это часто означает задержку до 30 секунд для любого запроса. Не пытаясь сначала использовать вторичный, пока основной не работает.

Я хотел решить эту проблему, поскольку наш разрешающий сервер имен Amazon EC2 недоступен для многих наших сотрудников. Это вызывает большие задержки в наших процессах и даже простои в некоторых случаях, потому что мы полагаемся на разрешение. Я хотел получить хорошее переключение на серверы имен Google / Level3 на случай, если Amazon снова выйдет из строя. И откатитесь как можно скорее, потому что тогда Amazon преобразует имена хостов в локальные адреса, где это возможно, разрешение с меньшей задержкой, например, для связи с экземпляром.

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

Я решил использовать crontab & bash и написал nsfailover.sh . Надеюсь, это поможет.