Предотвращение тайм-аутов DNS при сбое DNS-сервера
У нас есть небольшой центр обработки данных с около ста хостами, указывающими на 3 внутренних DNS-сервера (bind 9). Наша проблема возникает, когда один из внутренних серверов DNS становится недоступным. В этот момент все клиенты, которые указывают на этот сервер, начинают работать очень медленно.
Похоже, проблема в том, что в стандартном средстве разрешения проблем linux отсутствует концепция "переключения при сбое" на другой DNS-сервер. Вы можете настроить время ожидания и количество повторных попыток, которые он использует (и установить поворот, чтобы он работал через список), но независимо от того, какие настройки используются нашими службами, они работают намного медленнее, если основной DNS-сервер становится недоступным. На данный момент это один из крупнейших источников перебоев в обслуживании для нас.
Мой идеальный ответ - что-то вроде "RTFM: настроить /etc/resolv.conf как этот...", но если это вариант, я его не видел.
Мне было интересно, как другие люди справились с этой проблемой?
Я вижу 3 возможных типа решений:
Используйте linux-ha/Pacemaker и ips отработки отказа (чтобы IP-адреса DNS "всегда" были доступны). Увы, у нас нет хорошей инфраструктуры фехтования, а без фехтования кардиостимулятор работает не очень хорошо (по моему опыту, кардиостимулятор снижает доступность без фехтования).
Запустите локальный DNS-сервер на каждом узле и укажите resolv.conf на localhost. Это будет работать, но даст нам гораздо больше услуг для мониторинга и управления.
Запустите локальный кеш на каждом узле. Люди, кажется, считают nscd "неработающим", но dnrd, похоже, имеет правильный набор функций: он помечает DNS-серверы как включенные или выключенные и не использует "выключенные" DNS-серверы.
Любое приведение, кажется, работает только на уровне маршрутизации ip и зависит от обновлений маршрута при сбое сервера. Многоадресная рассылка казалась идеальным ответом, но bind не поддерживает широковещательную или многоадресную рассылку, и документы, которые я мог найти, по-видимому, указывают на то, что многоадресный DNS больше ориентирован на обнаружение и автоматическую настройку службы, чем на обычное разрешение DNS.,
Я пропускаю очевидное решение?
8 ответов
Пара вариантов. Оба будут распределять нагрузку DNS на ваши DNS-серверы.
- Попробуйте использовать
options rotateв resolv.conf. Это минимизирует влияние неработающего основного сервера. Если один из других серверов не работает, это замедлит действия. - Используйте другой порядок имен серверов на разных клиентах. Это позволит некоторым клиентам нормально работать, если основной DNS-сервер не работает. Это распространяет влияние неработающего DNS-сервера.
Эти параметры можно комбинировать с options timeout:1 attempts:5, Увеличьте количество попыток, если сократите время ожидания, чтобы вы могли обрабатывать медленные внешние серверы.
В зависимости от конфигурации вашего маршрутизатора вы можете настроить DNS-серверы так, чтобы они принимали IP-адрес основного DNS-сервера, когда он не работает. Это можно сочетать с вышеуказанными методиками.
ПРИМЕЧАНИЕ: я работаю годами без внеплановых отключений DNS. Как уже отмечали другие, я бы работал над решением проблем, вызывающих сбой DNS-серверов. Вышеуказанные действия также помогают при неправильной настройке DNS-серверов с указанием недоступных серверов имен.
Проверьте "man resolv.conf". Вы можете добавить опцию тайм-аута в resolv.conf. Значение по умолчанию - 5, но добавление следующего в resolv.conf должно привести к уменьшению его до 1 секунды:
время ожидания:1
Запустите локальный DNS-сервер на каждом узле и укажите resolv.conf на localhost. Это будет работать, но даст нам гораздо больше услуг для мониторинга и управления.
FWIW, это единственное работоспособное решение, которое я нашел для этой проблемы. Вам нужно ограничить сервер только прослушиванием на локальном хосте, но он полностью исключил пользователей, замечающих перебои с DNS в нашей среде.
Один интересный побочный эффект заключается в том, что если по какой-либо причине сервер localhost выходит из строя, стандартные библиотеки распознавателя, по-видимому, обрабатывают переход на другой сервер гораздо быстрее, чем в стандартном случае.
Мы занимаемся этим уже около 3 лет, и я не видел ни одной проблемы, которая может быть связана с отказом / отключением DNS-сервера, работающего на локальном хосте.
Кластерное программное обеспечение, такое как сердцебиение или кардиостимулятор /corosync, ваш друг здесь. Например, мы настроили кардиостимулятор /corosync следующим образом:
- Соедините каждый сервер с другим
- На пару есть 2 днс випа, обычно по одному на каждого
- В случае сбоя привязки или сбоя сервер перемещается на другой сервер за миллисекунды.
Рабочие часы работают круглосуточно, но мы твердо убеждены в том, что каждый сервер должен иметь возможность выходить из строя, не влияя на клиентов. вариант поворота - это просто обходной путь, я бы этого не делал.
Если сервер имен отключается из-за обслуживания, это нормальная процедура сокращения времени ожидания в SOA для этого домена заблаговременно, чтобы при изменении обслуживания происходило изменение (например, удаление записей NS перед обслуживанием и возврат их после обслуживания).) размножаться быстро. Обратите внимание, что это подход на стороне сервера - смена распознавателей - это подход на стороне клиента и... если вы не можете поговорить с каждым из ваших клиентов и заставить их выполнить эту настройку на своем компьютере... это может быть невозможно правильный подход. Ну, я полагаю, вы сказали, что только сто клиентов все в центре обработки данных, использующих внутренние DNS-серверы, но действительно ли вы хотите изменить конфигурацию на сотне клиентов, когда вы можете просто изменить зону?
Я бы сказал вам, какие значения в SOA нужно изменить, но я просматривал Интернет, чтобы узнать точную информацию, когда натолкнулся на этот вопрос.
Возможно, вы можете поставить свои DNS-серверы на балансировщик нагрузки? Очевидно, LVS может балансировать UDP. Очевидно, что ваш LB очень доступен, так что это не единственная точка отказа.
Более сетевое решение будет использовать два DNS-сервера с одинаковым (выделенным) IP-адресом и маршрутизацией Anycast. (Я не заметил этот ответ в этой теме до сих пор, но это то, что используется здесь.)
Пока оба активны, используется ближайший сервер. Если один из них выходит из строя, трафик для этого IP-адреса будет направляться на другой узел, пока он снова не появится. Это особенно имеет смысл, если у вас есть два или более местоположений или центров обработки данных.
Я знаю, что это может звучать банально, но как насчет создания более стабильной, отказоустойчивой инфраструктуры DNS в качестве постоянного решения проблемы.