Наиболее устойчивая форма (частной) кластеризации DNS?

Вы можете значительно уменьшить проблемы, установив несколько параметров в файле resolv.conf:

options rotate timeout:2

rotate заставляет распознаватель выбирать один из ваших серверов имен случайным образом, а не использовать первый, если он не истечет. timeout: 2 уменьшает время ожидания DNS до двух секунд, а не до значения по умолчанию.

(NB: это было протестировано на Debian / Ubuntu, но я не думаю, что это специфическое изменение Debian)

Anycast DNS позволит вам настроить один IP-адрес преобразователя для всех ваших клиентов; клиентские запросы будут перенаправлены на «ближайший» (с точки зрения сетевой маршрутизации) сервер.

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

С точки зрения реализации это можно сделать либо с помощью аппаратных устройств (например, F5 Big IP, Citrix Netscaler), либо с помощью вашей собственной конфигурации. Вы можете либо запустить демон маршрутизации (например, Quagga), работающий на ваших DNS-серверах, либо иметь несколько пользовательских скриптов, которые входят в ваши маршрутизаторы, чтобы изменить состояние каждого виртуального IP-адреса anycast.

Исправьте клиента - используйте лучший резолвер.

lwresd является частью Bind. Он работает как локальная служба. Вы настраиваете libc для использования через /etc/nsswitch.conf, поэтому его использование прозрачно для всех программ, кроме статически скомпилированных.

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

Я запускаю внутренний рекурсивный DNS-кластер BGP anycast на двух балансировщиках нагрузки виртуального сервера Linux (IPVS), и он отлично работает.

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

Проблема с использованием VRRP для IP-адреса службы заключается в том, что он будет перемещаться между двумя вашими серверами, и, следовательно, вашему серверу имен необходимо будет быстро подключиться к нему, чтобы иметь возможность отвечать на запросы в случае аварийного переключения. Вы можете обойти это с помощью NAT, как и в моей настройке IPVS, но я бы рекомендовал балансировку нагрузки с активными проверками служб, чтобы вы знали, когда что-то не так.

Обратите внимание, что, хотя существуют реализации DNS, которые используют многоадресную рассылку (например, Apple Bonjour / mdns), они обычно не подходят для надежной или рекурсивной службы DNS большого объема, а также обычно ограничены для использования в одном и том же домене конфликтов, то есть в локальной сети.

Простой немой способ:

Попросите ваш Linux быть более агрессивным на DNS-серверах в resolv.conf: options timeout: 0.1 rotate

Таким образом, тайм-аут быстрый, а чередование заставляет его использовать оба для циклического перебора нагрузки, без каких-либо VIP / VRRP / персонала для управления, всего 2 DNS-сервера, выполняющих свою работу ...

Anycast часто используется для решения этого требования. Anycast DNS - это использование политик маршрутизации и адресации для воздействия на наиболее эффективный путь между одним источником (DNS-клиент) и несколькими географически разнесенными целями, которые «слушают» службу (DNS) в группе получателей. В Anycast одни и те же IP-адреса используются для адресации каждой из целей прослушивания (в данном случае DNS-серверов). Маршрутизация уровня 3 динамически обрабатывает вычисление и передачу пакетов от нашего источника (DNS-клиент) к его наиболее подходящей цели (DNS-сервер).

Пожалуйста, посетите www.netlinxinc.com для получения всей серии сообщений в блоге, посвященных Anycast DNS. Там вы найдете рецепты настройки Anycast DNS. В этой серии статей рассматривается Anycast DNS с использованием статической маршрутизации и RIP, и в ближайшее время я опубликую рецепты по OSPF и BGP.

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

#!/bin/sh
localns=192.168.0.1
remotens=192.168.0.2
currentns=`cat /etc/resolv.conf | grep nameserver | awk '{print $2}'`

while 1; do
    if ping -W1 -q -c3 -i0.5 $localns > /dev/null 2>&1; then
        # Local DNS is up
        [ $currentns != $localns ] || echo "nameserver $localns" > /etc/resolv.conf
        currentns=$localdns
    else;
        # Local DNS is down
        [ $currentns != $remotens ] || echo "nameserver $remotens" > /etc/resolv.conf
        currentns=$remotedns
    sleep 2 # Will detect failures in no more than 5 secs

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

Мой Kemp Loadmaster 1500s можно настроить для циклического переключения с переключением при отказе. Это будет использовать их сервисную проверку, чтобы убедиться, что каждый DNS-сервер работает каждые несколько секунд, и разделить трафик между двумя серверами. Если кто-то умирает, он выпадает из пула RR, и запрашивается только «активный» сервер.

Вам просто нужно указать свой resolv.conf на VIP на балансировщике нагрузки.

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

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

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

NIS решила эту проблему, сохранив состояние ypbind. Корявое решение, но обычно работает.

Решение здесь - положиться на поставщиков, которые предложат разумное решение этой проблемы. С IPV6 ситуация ухудшается, поскольку запросы AAAA увеличивают время, потраченное впустую на таймауты. Я видел, как протоколы терпят неудачу (например, соединение sshd), потому что они тратили много времени на ожидание таймаутов DNS из-за единственного недоступного DNS-сервера.

Тем временем, как предлагалось ранее, напишите сценарий, который заменяет resolv.conf на сценарий, содержащий только допустимые серверы имен. Поделитесь этим сценарием с поставщиками, чтобы продемонстрировать нечистое решение, которое вы были вынуждены реализовать.

Это не было серьезно протестировано и предполагает, что nslookup выполняет синтаксический анализ, как мой, и grep, который поддерживает "-q".

Выполняйте это из cron каждые 5 минут или около того.

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

Чтобы проверить это на практике, измените строку «nameservers =» вверху, измените resolv_conf вверху на /etc/resolv.conf, а не на /tmp/resolv.conf, и заголовок по умолчанию для resolv.conf, который содержит example.com .

Вам может потребоваться перезапустить nscd, если вы замените resolv.conf.

#!/bin/bash
# full list of nameservers
nameservers="127.0.0.1 192.168.0.1 192.168.1.1"

# resolv.conf filename, change to /etc/resolv.conf for production use
resolv_conf="/tmp/resolv.conf"

# for tracking during the test
failed_nameservers=""
good_nameservers=""

# test loop
for nameserver in $nameservers; do
    if nslookup localhost $nameserver | grep -q 'Address.*127\.0\.0\.1'; then
        good_nameservers="$good_nameservers $nameserver"
    else
        failed_nameservers="$failed_nameservers $nameserver"
    fi
done

# if none succeded, include them all
if [ -z "$good_nameservers" ]; then
    good_nameservers="$nameservers"
fi

# error reporting, consider writing to syslog
if [ -n "$failed_nameservers" ]; then
    echo warning: failed nameservers $failed_nameservers
fi

# create the temporary replacement resolv.conf
new_rc="$resolv_conf.new.$$"
echo domain example.com  > $new_rc
echo search example.com >> $new_rc
for nameserver in $good_nameservers; do
    echo nameserver $nameserver >> $new_rc
done

# don't deploy a corrupt resolv.conf
if ! grep -q nameserver $new_rc; then
    echo warning: sanity check on $new_rc failed, giving up
    exit 1
fi

# keep a backup
if [ -f $resolv_conf ]; then
    rm -f $resolv_conf.previous
    ln $resolv_conf $resolv_conf.previous
fi
# deploy the new one
mv $new_rc $resolv_conf

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

DNS1 = первичный vip1, вторичный vip2 DNS2 = первичный vip2, вторичный vip1

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

Есть ли шанс, что у вас есть балансировщики нагрузки на обоих сайтах? В противном случае вы могли бы расти с LVS.

Имейте адрес службы DNS на каждом сайте, который является VIP на балансировщике нагрузки. Затем активная / пассивная балансировка нагрузки каждого VIP на двух DNS-серверах в пользу локального.