У нас есть небольшой дата-центр с примерно сотней хостов, указывающих на 3 внутренних DNS-сервера (привязка 9). Наша проблема возникает, когда один из внутренних DNS серверов становится недоступным. В этот момент все клиенты, которые указывают на этот сервер, начинают работать очень медленно.
Проблема, похоже, в том, что стандартный преобразователь Linux на самом деле не имеет концепции «переключения при отказе» на другой DNS-сервер. Вы можете настроить время ожидания и количество повторных попыток, которые он использует (и установить ротацию, чтобы он работал по списку), но независимо от того, какие настройки используются, наши службы работают намного медленнее, если основной DNS-сервер становится недоступным. На данный момент для нас это один из крупнейших источников сбоев в обслуживании.
Мой идеальный ответ был бы что-то вроде «RTFM: настройте /etc/resolv.conf вот так ...», но если это возможно, я его не видел.
Мне было интересно, как другие люди справились с этой проблемой?
Я вижу 3 возможных варианта решения:
Используйте linux-ha / Pacemaker и failover ips (так что IP-адреса DNS "всегда" доступны). Увы, у нас нет хорошей инфраструктуры для ограждений, а без ограждений кардиостимулятор работает не очень хорошо (по моему опыту, Pacemaker снижает доступность без ограждений).
Запустите локальный DNS-сервер на каждом узле и укажите в resolv.conf localhost. Это сработает, но даст нам гораздо больше сервисов для мониторинга и управления.
Запустите локальный кеш на каждом узле. Люди, кажется, считают nscd «сломанным», но dnrd, похоже, имеет правильный набор функций: он отмечает DNS-серверы как работающие или неработающие и не использует «неработающие» DNS-серверы.
Any-casting работает только на уровне 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 секунды:
варианты тайм-аута: 1
Программное обеспечение для кластеризации, такое как сердцебиение или кардиостимулятор / коросинхронизация, здесь ваш друг. Например, мы настроили кардиостимулятор / corosync следующим образом:
Рабочие часы работают круглосуточно, без выходных, но мы твердо убеждены в возможности выхода из строя любого сервера без ущерба для клиентов. option rotate - это просто обходной путь, я бы не стал этого делать.
Запустите локальный DNS-сервер на каждом узле и укажите в resolv.conf localhost. Это сработает, но даст нам гораздо больше сервисов для мониторинга и управления.
FWIW, это единственное работоспособное решение, которое я нашел для этой проблемы. Вам действительно нужно ограничить сервер только прослушиванием на localhost, но это полностью устранило пользователей, замечающих сбои DNS в нашей среде.
Один интересный побочный эффект заключается в том, что если по какой-то причине локальный сервер выходит из строя, стандартные библиотеки преобразователя, похоже, обрабатывают переключение на следующий сервер намного быстрее, чем в стандартном случае.
Мы занимаемся этим около 3 лет, и я не видел ни одной проблемы, которая могла бы быть связана с отказом / отключением DNS-сервера, работающего на localhost.
Если сервер имен выходит из строя для обслуживания, это нормальная процедура - заранее сократить тайм-ауты в SOA для этого домена, чтобы при выполнении обслуживания вносились изменения (например, удаление записей NS перед обслуживанием и их возврат после обслуживания). ) быстро размножаются. Обратите внимание, что это подход на стороне сервера - смена преобразователей - это подход на стороне клиента, и ... если вы не можете поговорить с каждым из ваших клиентов и заставить их выполнить эту настройку на своей машине ... может не быть правильный подход. Ну, я полагаю, вы сказали, что только сотня клиентов в центре обработки данных использует внутренние DNS-серверы, но действительно ли вы хотите изменить конфигурацию на сотне клиентов, когда вы можете просто изменить зону?
Я бы сказал вам, какие значения в SOA нужно настроить, но когда я наткнулся на этот вопрос, я искал в Интернете эту точную информацию.
Возможно, вы сможете разместить свои DNS-серверы за балансировщиком нагрузки? Видимо LVS может балансировать UDP. Очевидно, сделайте свой LB высокодоступным, чтобы он не стал единственной точкой отказа.
Более сетецентрическим решением будет использование двух DNS-серверов с одинаковым (выделенным) IP-адресом и Anycast маршрутизация. (Я пока не заметил этого ответа в этой теме, но здесь используется именно он.)
Пока работают оба, используется ближайший сервер. Если один из них выйдет из строя, трафик для этого IP-адреса будет перенаправлен на другой узел, пока он не появится снова. Это особенно важно, если у вас два или более филиала или центров обработки данных.
Я знаю, что это может показаться банальным, но как насчет создания более стабильной и отказоустойчивой инфраструктуры DNS в качестве постоянного решения проблемы.