Я думал, что первичный / вторичный DNS для целей избыточности прост. Насколько я понимаю, у вас должен быть первичный и хотя бы один вторичный, и что вы должны настроить вторичный в географически другом месте, но также за другим маршрутизатором (см., Например, https://serverfault.com/questions/48087/why-are-there-several-nameservers-for-my-domain)
В настоящее время у нас есть два сервера имен в нашем основном центре обработки данных. Недавно мы столкнулись с некоторыми сбоями в работе по разным причинам, из-за которых вышли из строя оба сервера имен, и мы и наши клиенты остались без работы DNS в течение нескольких часов. Я попросил команду системных администраторов завершить настройку DNS-сервера в другом центре обработки данных и настроить его как вторичный сервер имен.
Однако наши системные администраторы утверждают, что это мало помогает, если другой центр обработки данных не так надежен, как основной центр обработки данных. Они утверждают, что большинство клиентов по-прежнему не смогут правильно выполнить поиск или слишком долго будут отключены, когда основной центр обработки данных не работает.
Лично я убежден, что мы не единственная компания, у которой есть такая проблема, и, скорее всего, это уже решенная проблема. Я не могу себе представить, чтобы все эти интернет-компании были затронуты нашим видом проблемы. Однако я не могу найти хорошую онлайн-документацию, объясняющую, что происходит в случаях сбоя (например, тайм-аут клиента) и как их обойти.
Какие аргументы я могу использовать, чтобы пробить брешь в рассуждениях наших системных администраторов? К каким интернет-ресурсам я могу обратиться, чтобы лучше понять проблемы, которые, по их мнению, существуют?
Некоторые дополнительные примечания после прочтения ответов:
Существует действительно отличный, хотя и довольно технический документ "Best Practices", который может оказаться полезным при борьбе с вашим системным администратором. http://www.cisco.com/web/about/security/intelligence/dns-bcp.html
Если он / она не признает достоверность статей, написанных Cisco, тогда вы можете прекратить спорить с системным администратором - подняться на уровень управления.
Многие другие документы с рекомендациями рекомендуют разделять первичный и вторичный серверы имен не только по блоку IP, но и по физическому расположению. Фактически, RFC 2182 рекомендует, чтобы вторичные службы DNS были географически разделены. Для многих компаний это означает аренду сервера в другом центре обработки данных или подписку на размещенного поставщика DNS, такого как ZoneEdit или UltraDNS.
К сожалению, DNS-преобразователь Linux, похоже, не имеет прямой поддержки для обнаружения и отработки отказа для DNS-серверов. Он продолжает подавать запросы на ваш первичный разрешающий сервер имен, ждет заданного тайм-аута, повторяет попытки и т. Д.
Это часто означает задержку до 30 секунд для любого запроса. Без предварительной попытки вторичного, пока первичный не работает.
Я хотел решить эту проблему, поскольку наш разрешающий сервер имен Amazon EC2 недоступен для многих наших сотрудников. Это вызывает большие задержки в наших процессах и даже простои в некоторых случаях, потому что мы полагаемся на разрешение. Я хотел получить хорошее переключение на серверы имен Google / Level3 на случай, если Amazon снова выйдет из строя. И откатитесь как можно скорее, потому что тогда Amazon будет преобразовывать имена хостов в локальные адреса, где это применимо, с меньшей задержкой, например, для связи с экземпляром.
Но независимо от сценария использования необходимо лучшее переключение при отказе. Я хотел это решить. Я хотел держаться подальше от демонов прокси, сервисов и т. Д., Поскольку это только добавило бы больше единой точки отказа. Я хотел использовать как можно более архаичную и надежную технологию.
Я решил использовать crontab и bash и написал nsfailover.sh. Надеюсь это поможет.
Однако наши системные администраторы утверждают, что это не очень помогает, если другой центр обработки данных не такой, как надежный в качестве основного центра обработки данных. Они утверждают, что большинство клиентов по-прежнему не смогут правильно выполнить поиск или слишком долго будут отключены, когда основной центр обработки данных не работает.
Ах, фокус надежный. Похоже, они делают удар по вашей ссылке извне, вместо того, чтобы настраивать вторичный DNS. Тем не менее, настройте вторичный DNS и действуйте оттуда. Это поможет с нагрузкой и поддержит ситуацию в крайнем случае ... но спросите, почему они думают, что другое место не подходит. надежный.
Лично я убежден, что мы не единственная компания, у которой есть такая проблема, и, скорее всего, это уже решенная проблема. Я не могу себе представить, чтобы все эти интернет-компании были затронуты нашим видом проблемы.
Вы не единственная компания, и, вероятно, это повторяли миллион раз в компаниях по всему миру.
Однако я не могу найти хорошую онлайн-документацию, объясняющую, что происходит в случаях сбоя (например, тайм-аут клиента) и как их обойти.
Какие аргументы я могу использовать, чтобы пробить брешь в рассуждениях наших системных администраторов? К каким интернет-ресурсам я могу обратиться, чтобы лучше понять проблемы, которые, по их мнению, существуют?
- Я говорю об авторитетном DNS для посторонних, чтобы найти наши серверы, а не о рекурсивных DNS-серверах для наших локальных клиентов.
Вы можете делать все, что угодно, в том числе настраивать внешнюю службу DNS, которая зарегистрирована в качестве органа управления для вашей зоны, но тайно делать (внешние) авторитетные серверы вторичными по отношению к вашим собственным (внутренним) DNS-серверам. Эта конфигурация ужасна, неверна, показывает, что я действительно злой системный администратор, и котенок умирает каждый раз, когда я рекомендую ее. Но он делает две вещи:
Причины того, что это неправильно вещь которую нужно сделать:
Похоже, проблема в том, что клиенты- кем угодно и где угодно - увидите два DNS-сервера, и если один из них выйдет из строя, они либо не переключатся на вторичный сервер, либо пройдет много времени, прежде чем они это сделают.
Я согласен с тем, что первичный и вторичный DNS-серверы должны быть расположены в разных помещениях, но я не знаю, как это решить данную проблему.
Если клиент будет настаивать на запросе определенного IP-адреса, игнорируя вторичный IP-адрес (или время ожидания для него истекло), то вам просто нужно найти решение, которое поддерживает этот IP-адрес в рабочем состоянии, даже если основной сервер не работает.
Некоторые направления для изучения - это балансировщик нагрузки, который может перенаправлять трафик с одного IP-адреса на несколько серверов в разных центрах обработки данных; или, возможно, произвольная маршрутизация.
Пока каждый из ваших центров обработки данных находится в разных цепях (в идеале с разными вышестоящими провайдерами далеко в облаке), вы можете настроить довольно надежный DNS только с двумя центрами обработки данных. Вам просто нужно убедиться, что выбранный вами регистратор заполняет соответствующие записи привязки к большим серверам в небе.
Наша установка:
Эта установка оказалась достаточно эффективной, чтобы дать нам примерно 5 9 безотказной работы за последние 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 в качестве услуги.
Томас,
Прочитав ваше обновление, я отредактировал свой пост (в предыдущем посте есть ссылка на программное обеспечение Windows).
Для меня это почти звучит так, как будто ваш системный администратор (ы) говорит вам, что в вашем дополнительном местоположении нет необходимого оборудования для обработки ПОЛНОЙ ЗАГРУЗКИ?
Похоже, он говорит: «Привет, приятель, если наше основное местоположение (которое включает в себя основной DNS) выйдет из строя, то DNS - НАИМЕНЕЕ из наших проблем, потому что если COLO1 не работает, то COLO2 все равно не сможет справиться с нагрузкой».
Если это так, то я предлагаю вам изучить вашу инфраструктуру и попытаться придумать лучший дизайн. Легче сказать, чем сделать, особенно сейчас, когда вы живете в производственной среде.
Помимо всего прочего, в идеальном мире COLO1 и COLO2 могли бы самостоятельно справиться с вашим грузом.
Как только это было сделано ... DNS на самом деле является не чем иным, как наличием достаточного количества DNS-серверов с достаточно быстрым обновлением, и если одна из сторон выйдет из строя, вы можете переписать свой DNS, чтобы он указывал на серверы, которые работают.
Я использовал этот метод в средах небольшого или разумного размера, и он отлично работает. Восстановление после сбоя обычно занимает менее 10 минут.
Вам просто нужно убедиться, что ваши DNS-серверы могут справиться с дополнительной нагрузкой, связанной с коротким TTL (время жизни).
Надеюсь это поможет.
Ваши системные администраторы (в основном) неправы.
Рекурсивные серверы, которые запрашивают ваши официальные серверы, очень быстро заметят, если какой-либо из сайтов не отвечает.
Да, есть вероятность, что клиенты могут испытывать очень скромные задержки разрешения DNS при сбое, но они будут всего на секунду или две, и как только собственные DNS-серверы клиента узнают, что один из серверов не работает, они будут использовать оставшиеся серверы предпочтительнее отказавшего.
Если необходимо (чтобы успокоить системных администраторов), продолжайте запускать два сервера в основном центре обработки данных, но поставьте хотя бы еще один снаружи.
Вторичный DNS-сервер никогда не повредит, в зависимости от того, где он размещен, он даст вам более или менее функциональные возможности.
Если ваш основной хост выходит из строя, дополнительный может взять на себя управление независимо от того, находится он рядом с ним или в удаленном месте. Если, однако, исходящий канал вашего центра обработки данных не работает, вы все равно можете получать ответы DNS от сервера в другом центре обработки данных, но вы все равно не сможете связаться со своими серверами. Таким образом, ваши конечные пользователи не получат прямой выгоды от вторичного DNS в удаленном месте.
Различные клиенты по-разному реагируют на недоступность DNS-серверов, поэтому есть доля правды в том, что клиенты истекают по таймауту, но не все.
Однако вторичный DNS в удаленном центре обработки данных по-прежнему сможет разрешить IP-адрес сервера, к которому вы хотите подключиться, чтобы вы могли отладить маршрутизацию и посмотреть, когда они снова появятся. А если вы правильно настроили вторичные серверы MX, вы даже не потеряете почту.