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

Я думал, что первичный / вторичный DNS для целей резервирования был прост. Насколько я понимаю, у вас должен быть основной и, по крайней мере, один дополнительный, и что вы должны установить свой дополнительный в географически другом месте, но также и за другим маршрутизатором (см., Например, /server/48087 / почему-там-несколько-серверов-имен-для-моего-домена )

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

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

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

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

Некоторые дополнительные заметки после прочтения ответов:

• мы на линуксе
• у нас есть дополнительные сложные потребности DNS; нашими записями DNS управляет какое-то специальное программное обеспечение, причем в настоящее время BIND работает в режиме реализации Twisted DNS, а также некоторые представления в миксе. Однако мы полностью способны настроить наши собственные DNS-серверы в другом центре обработки данных.
• Я говорю об авторитетном DNS для посторонних, чтобы найти наши серверы, а не о рекурсивных DNS-серверах для наших локальных клиентов.

Существует действительно отличный, хотя и довольно технический документ «Best Practices», который может оказаться полезным при борьбе с вашим системным администратором. 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-распознаватель Linux, похоже, не имеет прямой поддержки для обнаружения и выполнения отработки отказа для DNS-серверов. Он продолжает отправлять запросы на ваш основной разрешающий сервер имен, ожидает установленного времени ожидания, повторных попыток и т. Д.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Прочитав ваше описание, я понял, что не ясно, имеете ли вы в виду авторитетный DNS для посторонних, чтобы найти ваши серверы, или рекурсивные DNS-серверы для ваших локальных клиентов. Поведение этих двух очень отличается.

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

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

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

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

Томас,

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

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

Звучит так, как будто он говорит: «Эй, приятель, если наше основное местоположение (которое включает в себя основной DNS) выходит из строя, то DNS - это НАИМЕНОВАНИЕ наших проблем, потому что, если COLO1 не работает, COLO2 не может справиться с нагрузкой в ​​любом случае».

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

Помимо всего прочего, в идеальном мире COLO1 и COLO2 смогут стоять в одиночестве и справляться с вашей нагрузкой.

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

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

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

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

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

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

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

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

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

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

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

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