Балансування кешуючого DNS на основі Cisco IP SLA

DNS Fail
У мережі будь-якого Інтернет-провайдера можна зустріти такий обов'язковий елемент, як кешуючий DNS сервіс. А оскільки робота мережі Інтернет без DNS неможливо, серверів таких буде щонайменше два, з обов'язковим резервуванням і балансуванням. У замітці я постараюся описати один з варіантів балансування навантаження між декількома кэширующими серверами на основі Cisco IP SLA.
Можливі рішення
Балансування на клієнтській стороні
найпростішим способом резервування кешуючого DNS є налаштування на клієнтській стороні декількох записів з адресами DNS-серверів. Адреси DNS-серверів можна повідомити клієнта різними способами:
  • через відповідні атрибути DHCP (для тих абонентів, хто використовує технологію IPoE і автоматичне налаштування);
  • по протоколу LCP для абонентів PPPoE (або будь-який інший PPP-технології);
  • вказавши у додатку до договору або інструкції для абонентів, чиє підключення по IP налаштовується вручну.
Клієнт, у разі недоступності першого сервера, автоматично переключитися на другий і т. д. Але цей спосіб має два очевидних недоліки.
Перший — відсутня повноцінна балансування навантаження. Поки перший сервер доступний і працює (а ми виходимо з того, що відмова сервера річ хоч і неприємна, але дуже рідкісна), у абонентів немає ніякого резону перемикатися на другий, і той простоює.
Другий недолік повністю випливає з першого, але має набагато більше значення. Критерії перемикання на резервний сервер повністю визначаються параметрами на клієнтській стороні. Ось, наприклад, опис стандартних таймінгів DNS клієнта Windows XP. Зі статті випливає, що 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, 0 metric
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.
Опис роботи
Коротко роботу можна описати наступним чином:
  1. В конфігурації маршрутизатора створюється три запису IP SLA, які періодично виконують запит до кожного з трьох DNS-серверів (наприклад, стандартний запит A-RR www.google.com). Результат запиту визначає стан запису.
  2. З записами IP SLA пов'язані три об'єкта Track, які переходять у статус DOWN, якщо стан відповідного IP SLA відмінно від OK.
  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, 0 metric
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 секунд.
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.