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

У мережі будь-якого Інтернет-провайдера можна зустріти такий обов'язковий елемент, як сервіс, що кешує DNS. А оскільки робота мережі Інтернет без служби DNS неможлива, серверів таких буде мінімум два, з обов'язковим резервуванням та балансуванням. У замітці я спробую описати один з варіантів балансування навантаження між кількома серверами, що кешують, на основі Cisco IP SLA.

Можливі рішення

Балансування на клієнтській стороні

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

за протоколом LCP для абонентів PPPoE (або будь-якої іншої PPP-технології);

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

    • Клієнт, у разі недоступності першого сервера, автоматично переключиться на другий і т.д. Але цей спосіб має два очевидні недоліки.

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

    Другий недолік повністю походить з першого, але має значно більше значення. Критерії перемикання на резервний сервер повністю визначаються настройками клієнтської сторони. Ось наприклад опис стандартних таймінгів DNS клієнта Windows XP. З статті випливає, що Windows XP переключиться на використання резервного сервера лише в тому випадку, якщо основний не відповість протягом однієї секунди. Тобто. можна уявити ситуацію, коли, внаслідок навантаження, помилки конфігурування чи збою, основний сервер працює незадовільно, але відповідає протягом 0,95 сек. Очевидно, щопри такій затримці про жодну нормальну роботу Інтернет у абонента мови бути не може. Але, оскільки час відповіді менше однієї секунди, абоненти "плакатимуться, колотимуться, але продовжуватимуть їсти кактус", точніше відчуватимуть деградацію сервісу, але не переключаться на резервний DNS-сервер, що простоює.

    Звичайно, подібна поведінка служба DNS є аварійною і повинна бути виявлена ​​системою моніторингу з подальшою ескалацією проблеми. Але питання моніторингу осторонь теми нотатки.

    Destination NAT

    Статична маршрутизація

    В результаті ми отримаємо таку картину:

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

    кешування

    Застосування IP SLAs DNS для Failover

    Тепер, коли ми подбали про балансування, залишилося вирішити питання з перемиканням трафіку у разі відмови одного із серверів. У цьому допоможе механізм Cisco IP SLA, а точніше функція IP SLAs DNS Operation.

    Опис роботи

    Коротко роботу цієї функції можна описати так:

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

    З записами IP SLA пов'язані три об'єкти Track, які переходять у статус DOWN, якщо стан відповідного IP SLA відрізняється від ОК.

  • Три статичні маршрути з розділу вище зв'язуються зі своїм об'єктом Track

    • Тепер, якщо в певний момент один із серверів не відповість або відповість некоректно на 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. Очевидні переваги методу:

    1. простота налаштування;
    2. все працює на маршрутизаторі та не вимагає додаткових коштів;
    3. контролюється відповідь сервісу, а не тільки, наприклад, доступність ICMP echo request.

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