В сети любого Интернет-провайдера можно встретить такой обязательный элемент, как кэширующий DNS сервис. А поскольку работа сети Интернет без службы DNS невозможно, серверов таких будет минимум два, с обязательным резервированием и балансировкой. В заметке я постараюсь описать один из вариантов балансировки нагрузки между несколькими кэширующими серверами на основе Cisco IP SLA.

Возможные решения

Балансировка на клиентской стороне

Самым простым способом резервирования кэширующего DNS является настройка на клиентской стороне нескольких записей с адресами DNS-серверов. Адреса DNS-серверов можно сообщить клиенту различными способами:

• через соответствующие атрибуты DHCP (для тех абонентов кто использует технологию IPoE и автоматическую настройку);

• по протоколу LCP для абонентов PPPoE (или любой другой PPP-технологии);

• указав в приложении к договору или инструкции для абонентов, чье подключение по IP настраивается вручную.

Клиент, в случае недоступности первого сервера, автоматически переключиться на второй и т.д. Но этот способ имеет два очевидных недостатка.

Первый — отсутствует полноценная балансировка нагрузки. Пока первый сервер доступен и работает (а мы исходим из того, что отказ сервера вещь хоть и неприятная, но крайне редкая), у абонентов нет никакого резона переключаться на второй, и тот простаивает.

Второй недостаток полностью проистекает из первого, но имеет куда большее значение. Критерии переключения на резервный сервер полностью определяются настройками на клиентской стороне. Вот, например, описание стандартных таймингов DNS клиента Windows XP ^[1]. Из статьи следует, что Windows XP переключиться на использование резервного сервера только в том случае, если основной не ответит в течении одной секунды. Т.е. можно представить ситуацию, когда, в результате перегрузки, ошибки конфигурирования или сбоя, основной сервер работает неудовлетворительно, но отвечает в течении 0,95 сек. Очевидно, что при такой задержке ни о какой нормальной работе Интернет у абонента речи быть не может. Но, поскольку время ответа менее одной секунды, абоненты "будут плакаться, колоться, но продолжать есть кактус", точнее будут испытывать деградацию сервиса, но не переключатся на простаивающий резервный DNS-сервер.

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

Destination NAT

Другой способ балансировки — destination NAT. Это решение, которое активно применяется для распределения нагрузки на кластерах web-серверов. В этом случае абоненты используют единственный адрес DNS-сервера, который является адресом интерфейса NAT, а реальные DNS-сервера имеют приватную адресацию. При обращении абонентов к DNS-серверу происходит трансляция в запросе Destination IP-address в адрес одного из серверов. При таком подходе нагрузку можно распределить равномерно. Но подобный метод является несколько избыточным, так как полноценный NAT, в случае с web-серверами, оправдан в силу того, что транспорт там обеспечивает протокол TCP, который является stateful, в отличии от stateless транспорт UDP, обычно применяемого для запросов DNS. В отличии от обмена трафика с web-сервером, диалог клиента с DNS-сервером очень лаконичен и предполагает только пару запрос-ответ.

Статическая маршрутизация

Более простой способ — статические маршруты. Представим, что у нас есть три DNS-сервера с IP-адресами:

• 10.0.0.1,
• 10.0.0.2,
• 10.0.0.3.

На каждом из которых сконфигурирован Loopback-интерфейс 10.10.10.10. Служба DNS настроена на получение запросов на данный адрес, а в firewall есть правила для TCP/UDP-портов 53.

В таком случае любой из этих серверов готово обслуживать DNS-запросы с destination-адресом 10.10.10.10. Это и будет IP-адрес DNS-сервера, которым пользуются все наши абоненты. Осталось распределить их запросы между реальными серверами. Тут ничего особенного делать не требуется. Сконфигурируем на маршрутизаторе, куда подключены наши сервера три статических маршрута:

ip route 10.10.10.10 255.255.255.255 10.0.0.1
ip route 10.10.10.10 255.255.255.255 10.0.0.2
ip route 10.10.10.10 255.255.255.255 10.0.0.3

В результате мы получим такую картину:

Router#show ip route 10.10.10.10
Routing entry for 10.10.10.10/32
  Known via "static", distance 1, metric 0
  Routing Descriptor Blocks:
  * 10.0.0.1
      Route metric is 0, traffic share count is 1
    10.0.0.2
      Route metric is 0, traffic share count is 1
    10.0.0.3
      Route metric is 0, traffic share count is 1

Теперь стандартный механизм балансировки per-flow будет последовательно раскладывать запросы от разных абонентов по трем имеющимся маршрутам:

Применение IP SLAs DNS для Failover

Теперь, когда мы позаботились о балансировке, осталось решить вопрос с переключением трафика в случае отказа одного из серверов. В этом нам поможет механизм Cisco IP SLA, а точнее функция IP SLAs DNS Operation ^[2].

Описание работы

Кратко работу данной функции можно описать следующим образом:

1. В конфигурации маршрутизатора создается три записи IP SLA, которые периодически выполняют запрос к каждому из трех DNS-серверов (например, стандартный запрос A-RR www.google.com). Результат запроса определяет состояние записи.

2. С записями IP SLA связаны три объекта Track, которые переходят в статус DOWN, если состояние соответствующего IP SLA отлично от ОК.

3. Три статических маршрута из раздела выше связываются со своим объектом Track

Теперь, если в определенный момент один из серверов не ответит или ответит некорректно на DNS-запрос, соответствующий объект Track перейдет в состояние DOWN, а связанный с ним статический маршрут исчезнет из таблицы маршрутизации. В результате проблемный сервер будет исключен из механизма балансировки.

Пример конфигурации

Конфигурация IP SLA:

ip sla 1
 dns www.google.com name-server 10.0.0.1
 timeout 5000
 frequency 9

ip sla 2
 dns www.google.com name-server 10.0.0.2
 vrf internet
 timeout 5000
 frequency 9

ip sla 3
 dns www.google.com name-server 10.0.0.3
 timeout 5000
 frequency 9

Активация и настройка трэкинга:

ip sla schedule 1 life forever start-time now
ip sla schedule 2 life forever start-time now
ip sla schedule 3 life forever start-time now

track 1 ip sla 1
track 2 ip sla 1
track 3 ip sla 1

Настройка маршрутов с привязкой к трэкингу:

ip route 10.10.10.10 255.255.255.255 10.0.0.1 track 1
ip route 10.10.10.10 255.255.255.255 10.0.0.2 track 2
ip route 10.10.10.10 255.255.255.255 10.0.0.3 track 3

Тестирование

Сейчас, кроме самих маршрутов у нас есть три IP SLA, которые в настоящее время работают, а результат последнего запроса у всех OK.

Router# show ip sla statistics

IPSLA operation id: 1
    Latest RTT: 1 milliseconds
Latest operation start time: 15:33:27 UTC+7 Wed Aug 17 2016
Latest operation return code: OK
Number of successes: 373
Number of failures: 0
Operation time to live: Forever

IPSLA operation id: 2
    Latest RTT: 1 milliseconds
Latest operation start time: 15:33:27 UTC+7 Wed Aug 17 2016
Latest operation return code: OK
Number of successes: 373
Number of failures: 0
Operation time to live: Forever

IPSLA operation id: 3
    Latest RTT: 1 milliseconds
Latest operation start time: 15:33:27 UTC+7 Wed Aug 17 2016
Latest operation return code: OK
Number of successes: 373
Number of failures: 0
Operation time to live: Forever

Попробуем отключить сервис DNS на сервере DNS-1. При следующей проверки (они у нас происходят раз в девять секунд) соответствующий IP SLA сообщит о проблеме:

Router# show ip sla statistics 1

IPSLA operation id: 1
    Latest RTT: NoConnection/Busy/Timeout
Latest operation start time: 15:37:48 UTC+7 Wed Aug 17 2016
Latest operation return code: Timeout
Number of successes: 1
Number of failures: 1
Operation time to live: Forever

А соответствующий маршрут с next-hop 10.0.0.1 исчезнет из таблицы маршрутизации:

Router#show ip route 10.10.10.10
Routing entry for 10.10.10.10/32
  Known via "static", distance 1, metric 0
  Routing Descriptor Blocks:
  * 10.0.0.2
      Route metric is 0, traffic share count is 1
    10.0.0.3
      Route metric is 0, traffic share count is 1

Теперь запросы клиентов распределяются между двумя оставшимися серверами. Если мы вновь запустим сервис, то при следующей проверке IP SLA вернет маршрут и сервер вновь начнет участвовать в балансировке.

Недостаток метода

Основной и самый существенный недостаток данного метода — минимально возможная периодичность опроса девять секунд. Очень часто подобная "оперативность" является критической. К сожалению — это ограничение функционала Cisco. Если кто-то подскажет, как его обойти — буду очень благодарен.

Заключение

Мы рассмотрели применение статической маршрутизации и Cisco IP SLA при балансировке и резервировании сервиса кэшируюего DNS. Очевидные преимущества метода:

1. простота настройки;
2. все работает на маршрутизаторе и не требует дополнительных средств;
3. контролируется ответ сервиса, а не только, к примеру, доступность по ICMP echo request.

Недостаток:

1. минимальный период опроса 9 секунд, что означает время реакции до 9 * 2 = 18 секунд.

Автор: kvinogradov

Источник ^[3]