У нас есть небольшой центр обработки данных с около ста хостами, указывающими на 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 и зависит от обновлений маршрута при сбое сервера. Многоадресная рассылка казалась идеальным ответом, но связывание не поддерживает широковещательную или многоадресную рассылку, и документы, которые я мог найти, указывают на то, что многоадресный DNS больше ориентирован на обнаружение и автоматическую настройку службы, чем на обычное разрешение DNS. ,
Я пропускаю очевидное решение?
Ответы:
Пара вариантов. Оба будут распределять нагрузку DNS на ваши DNS-серверы.
options rotateв resolv.conf. Это сведет к минимуму влияние неработающего основного сервера. Если один из других серверов не работает, это замедлит действия.Эти параметры могут быть объединены с
options timeout:1 attempts:5. Увеличьте количество попыток, если сократите время ожидания, чтобы вы могли обрабатывать медленные внешние серверы.В зависимости от конфигурации вашего маршрутизатора вы можете настроить DNS-серверы так, чтобы они принимали IP-адрес основного DNS-сервера, когда он не работает. Это можно сочетать с вышеуказанными методиками.
ПРИМЕЧАНИЕ: я работаю годами без внеплановых отключений DNS. Как уже отмечали другие, я бы работал над решением проблем, вызывающих сбой DNS-серверов. Вышеуказанные действия также помогают при неправильной настройке DNS-серверов с указанием недоступных серверов имен.
источник
Проверьте "man resolv.conf". Вы можете добавить опцию тайм-аута в resolv.conf. Значение по умолчанию - 5, но добавление следующего в resolv.conf должно привести к уменьшению его до 1 секунды:
источник
Кластерное программное обеспечение, такое как сердцебиение или кардиостимулятор / corosync, ваш друг здесь. Например, мы настроили кардиостимулятор / corosync следующим образом:
Рабочие часы работают круглосуточно, но мы твердо убеждены в том, что каждый сервер должен иметь возможность выходить из строя, не влияя на клиентов. вариант поворота - это просто обходной путь, я бы этого не делал.
источник
FWIW, это единственное работоспособное решение, которое я нашел для этой проблемы. Вам нужно ограничить сервер только прослушиванием на локальном хосте, но он полностью исключил пользователей, замечающих перебои с DNS в нашей среде.
Один интересный побочный эффект заключается в том, что если по какой-либо причине сервер localhost выходит из строя, стандартные библиотеки распознавателя, по-видимому, обрабатывают переход на другой сервер гораздо быстрее, чем в стандартном случае.
Мы занимаемся этим уже около 3 лет, и я не видел ни одной проблемы, которая может быть связана с отказом / отключением DNS-сервера, работающего на локальном хосте.
источник
Если сервер имен отключается из-за обслуживания, это нормальная процедура, чтобы заранее сократить время ожидания в SOA для этого домена, чтобы при изменении обслуживания происходило изменение (например, удаление записей NS перед обслуживанием и возврат их после обслуживания). ) размножаться быстро. Обратите внимание, что это подход на стороне сервера - смена распознавателей - это подход на стороне клиента и ... если вы не можете поговорить с каждым из ваших клиентов и заставить их выполнить эту настройку на своем компьютере ... это может быть невозможно правильный подход. Ну, я полагаю, вы сказали, что только сто клиентов все в центре обработки данных, использующих внутренние DNS-серверы, но действительно ли вы хотите изменить конфигурацию на сотне клиентов, когда вы можете просто изменить зону?
Я бы сказал вам, какие значения в SOA нужно изменить, но я просматривал Интернет, чтобы узнать точную информацию, когда натолкнулся на этот вопрос.
источник
Возможно, вы можете поставить свои DNS-серверы на балансировщик нагрузки? Очевидно, LVS может балансировать UDP. Очевидно, что ваш LB очень доступен, так что это не единственная точка отказа.
источник
Я знаю, что это может звучать банально, но как насчет создания более стабильной, отказоустойчивой инфраструктуры DNS в качестве постоянного решения проблемы.
источник
Более сетевое решение будет использовать два DNS-сервера с одинаковым (выделенным) IP-адресом и маршрутизацией Anycast . (Я не заметил этот ответ в этой теме до сих пор, но это то, что используется здесь.)
Пока оба активны, используется ближайший сервер. Если один из них выходит из строя, трафик для этого IP-адреса будет направляться на другой узел, пока он снова не появится. Это особенно имеет смысл, если у вас есть два или более местоположений или центров обработки данных.
источник