В сети любого Интернет-провайдера можно встретить такой обязательный элемент, как кэширующий DNS сервис. А поскольку работа сети Интернет без службы DNS невозможно, серверов таких будет минимум два, с обязательным резервированием и балансировкой. В заметке я постараюсь описать один из вариантов балансировки нагрузки между несколькими кэширующими серверами на основе Cisco IP SLA. Самым простым способом резервирования кэширующего DNS является настройка на клиентской стороне нескольких записей с адресами DNS-серверов. Адреса DNS-серверов можно сообщить клиенту различными способами: через соответствующие атрибуты DHCP (для тех абонентов кто использует технологию IPoE и автоматическую настройку); по протоколу LCP для абонентов PPPoE (или любой другой PPP-технологии); Клиент, в случае недоступности первого сервера, автоматически переключиться на второй и т.д. Но этот способ имеет два очевидных недостатка. Первый — отсутствует полноценная балансировка нагрузки. Пока первый сервер доступен и работает (а мы исходим из того, что отказ сервера вещь хоть и неприятная, но крайне редкая), у абонентов нет никакого резона переключаться на второй, и тот простаивает. Второй недостаток полностью проистекает из первого, но имеет куда большее значение. Критерии переключения на резервный сервер полностью определяются настройками на клиентской стороне. Вот, например, описание стандартных таймингов DNS клиента Windows XP. Из статьи следует, что Windows XP переключиться на использование резервного сервера только в том случае, если основной не ответит в течении одной секунды. Т.е. можно представить ситуацию, когда, в результате перегрузки, ошибки конфигурирования или сбоя, основной сервер работает неудовлетворительно, но отвечает в течении 0,95 сек. Очевидно, что при такой задержке ни о какой нормальной работе Интернет у абонента речи быть не может. Но, поскольку время ответа менее одной секунды, абоненты "будут плакаться, колоться, но продолжать есть кактус", точнее будут испытывать деградацию сервиса, но не переключатся на простаивающий резервный DNS-сервер. Конечно, подобное поведение службу DNS является аварийным и должно быть обнаружено системой мониторинга с последующей эскалацией проблемы. Но вопрос мониторинга находится в стороне от темы заметки. Другой способ балансировки — destination NAT. Это решение, которое активно применяется для распределения нагрузки на кластерах web-серверов. В этом случае абоненты используют единственный адрес DNS-сервера, который является адресом интерфейса NAT, а реальные DNS-сервера имеют приватную адресацию. При обращении абонентов к DNS-серверу происходит трансляция в запросе Destination IP-address в адрес одного из серверов. При таком подходе нагрузку можно распределить равномерно. Но подобный метод является несколько избыточным, так как полноценный NAT, в случае с web-серверами, оправдан в силу того, что транспорт там обеспечивает протокол TCP, который является stateful, в отличии от stateless транспорт UDP, обычно применяемого для запросов DNS. В отличии от обмена трафика с web-сервером, диалог клиента с DNS-сервером очень лаконичен и предполагает только пару запрос-ответ. Более простой способ — статические маршруты. Представим, что у нас есть три DNS-сервера с IP-адресами: На каждом из которых сконфигурирован Loopback-интерфейс 10.10.10.10. Служба DNS настроена на получение запросов на данный адрес, а в firewall есть правила для TCP/UDP-портов 53. В таком случае любой из этих серверов готово обслуживать DNS-запросы с destination-адресом 10.10.10.10. Это и будет IP-адрес DNS-сервера, которым пользуются все наши абоненты. Осталось распределить их запросы между реальными серверами. Тут ничего особенного делать не требуется. Сконфигурируем на маршрутизаторе, куда подключены наши сервера три статических маршрута: В результате мы получим такую картину: Теперь стандартный механизм балансировки per-flow будет последовательно раскладывать запросы от разных абонентов по трем имеющимся маршрутам:  Теперь, когда мы позаботились о балансировке, осталось решить вопрос с переключением трафика в случае отказа одного из серверов. В этом нам поможет механизм Cisco IP SLA, а точнее функция IP SLAs DNS Operation. Кратко работу данной функции можно описать следующим образом: В конфигурации маршрутизатора создается три записи IP SLA, которые периодически выполняют запрос к каждому из трех DNS-серверов (например, стандартный запрос A-RR www.google.com). Результат запроса определяет состояние записи. С записями IP SLA связаны три объекта Track, которые переходят в статус DOWN, если состояние соответствующего IP SLA отлично от ОК. Теперь, если в определенный момент один из серверов не ответит или ответит некорректно на DNS-запрос, соответствующий объект Track перейдет в состояние DOWN, а связанный с ним статический маршрут исчезнет из таблицы маршрутизации. В результате проблемный сервер будет исключен из механизма балансировки. Конфигурация IP SLA: Активация и настройка трэкинга: Настройка маршрутов с привязкой к трэкингу: Сейчас, кроме самих маршрутов у нас есть три IP SLA, которые в настоящее время работают, а результат последнего запроса у всех OK. Попробуем отключить сервис DNS на сервере DNS-1. При следующей проверки (они у нас происходят раз в девять секунд) соответствующий IP SLA сообщит о проблеме: А соответствующий маршрут с next-hop 10.0.0.1 исчезнет из таблицы маршрутизации: Теперь запросы клиентов распределяются между двумя оставшимися серверами. Если мы вновь запустим сервис, то при следующей проверке IP SLA вернет маршрут и сервер вновь начнет участвовать в балансировке. Основной и самый существенный недостаток данного метода — минимально возможная периодичность опроса девять секунд. Очень часто подобная "оперативность" является критической. К сожалению — это ограничение функционала Cisco. Если кто-то подскажет, как его обойти — буду очень благодарен. Мы рассмотрели применение статической маршрутизации и Cisco IP SLA при балансировке и резервировании сервиса кэшируюего DNS. Очевидные преимущества метода: Недостаток: Сетевой инженер