Большая часть эластичной формы (частной) кластеризации DNS?

Можно в широком масштабе смягчить проблемы путем установки нескольких опций в resolv.conf:

options rotate timeout:2

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

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

Я работаю, внутренний BGP передал одному из узлов рекурсивный Кластер DNS на двух Виртуальных серверах Linux (IPVS) Loadbalancers, и он работает как очарование.

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

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

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

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

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

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

#!/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 как виртуальный сервис.

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

Необходимо было бы просто указать resolv.conf на VIP на loadbalancer.

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

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

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

NIS обработал эту проблему при наличии ypbind, сохраняют состояние. Неуклюжее решение, но это обычно работает.

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

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

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

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

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

Для тестирования этого на реальный измените "серверы имен =" строка наверху, измените 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 вторичный

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

Простой немой путь:

Попросите, чтобы Ваш Linux был намного более агрессивен на серверах DNS в resolv.conf: опции timeout:0.1 вращаются

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

Шанс у Вас есть loadbalancers на обоих сайтах? Если не Вы могли бы произвести своими силами с LVS.

Сделайте, чтобы DNS обслужил адрес на каждом сайте, который является VIP на loadbalancer. Затем активный/пассивный loadbalance каждый VIP через два сервера DNS, способствуя локальному.

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

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

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