Отказоустойчивость на базе Microsoft DNS
Иногда бывает так, что ресурсы ограничены не потому, что нет новых серверов или нет возможности развернуть новый виртуальный сервер, а потому, что нельзя создавать новые “точки отказа”. Нельзя усложнять систему, а особенно систему, которая критична для бизнеса.
Задача: сделать отказоустойчивый сервис с терминальными серверами в рамках двух подсетей в разных ЦОДах на базе Microsoft DNS.
Схема сети.
Сложность состоит в том, что ЦОД №1 в приоритете. То есть, пользователи должны попадать на сервера ЦОДа №1 в случае его доступности, и ЦОДа #2 - в случае недоступности первого. На момент проведения работ, в сети был только родной Active Directory с Microsoft DNS. Именно с помощью его настройки и была решена задача.
План действий:
- описание полной цепочки движения DNS запросов между сетями, ЦОДами и конечными пользователями (подойдёт карандаш и лист бумаги)
- понимание принципов работы DNS. Хорошо помогут статьи: Типы ресурсных записей DNS, DNS (структура, обработка запросов, ресурсные записи)
- полное понимание того что делаем. С учетом того, что ЦОД №1 должен быть в приоритете, надо забыть про алгоритм маршрутизации запросов RoundRobin.
Итак, приступим:
Все вторичные и последующие сервера должны получать актуальную корректную информацию с головных держателей зоны. Для этого в каждом из DNS серверов отличных от зоны BOX.LOCAL необходимо настроить Conditional Forwarder (Зоны условной пересылки) на ближайший к нему DNS сервер.
На схеме схеме это зона WG.LOCAL. Зачем это нужно? В схеме сети запрещено прямое обращение в зону BOX для компьютеров и серверов из зоны WG.LOCAL кроме Домен Контроллеров. (Вы можете сократить эти хождения DNS запросов просто указав в Conditional Forwarder тех, кого надо.)
Настроились, проверяем, что DNS сервера BOX.LOCAL полностью доступны с каждого узла зон которые есть. А если они доступны для DNS серверов зон, то и, как следствие, доступны для клиентских компьютеров и серверов.
Далее, настраиваем A и CNAME записи на корневом держателе зоны BOX.LOCAL. Для этого заходим в управление DNS на сервере. В моем случае это 2008, но в Windows Server 2003 и Windows Server 2012 все выглядит практически так же.
Предварительная проверка:
В BOX.LOCAL существуют четыре A записи следующего вида:
trm-01 3600 IN A 192.168.0.10,
trm-02 3600 IN A 192.168.1.10,
web-01 3600 IN A 192.168.0.20,
web-02 3600 IN A 192.168.1.20.
И соответствующие PTR записи в зонах обратного просмотра. Надо сделать так, чтобы пользователи "стучались" на DNS запись trm.box.local и при доступности попадали на trm-01, а при недоступности trm-01 попадали на trm-02. И для web.box.local соответственно также.
Поехали!
- создаем две A записи trm-2A 3600 IN A 192.168.0.10, trm-2A 0 IN A 192.168.1.10.
- создаем две A записи web-2A 3600 IN A 192.168.0.20, web-2A 0 IN A 192.168.1.20.
- создаем CNAME запись trm 600 IN CNAME trm-2A.
- создаем CNAME запись web 600 IN CNAME web-2A.
Ждем репликации на вторичный контроллер домена. Проверяем.
Методы проверки будут одинаковы во всех случаях - nslookup (ссылка). Для особо продвинутых я ниже выкладываю скрипт (dns-ms-check.sh), чтобы была возможность проверить не единоразовым входом или выходом, а полноценно раз в минуту проверять результат выполненных действий.
Проверки:
1. на сервере (основной контроллер домена BOX.LOCAL)
nslookup
server dc-01.BOX.LOCAL
trm.BOX.LOCAL
2. на сервере (добавочный контроллер домена BOX.LOCAL)
nslookup
server dc-02.BOX.LOCAL
trm.BOX.LOCAL
3. на сервере (основной контроллер домена FOOBOX.LOCAL)
nslookup
server dc-01.FOOBOX.LOCAL
trm.BOX.LOCAL
4. на сервере (добавочный контроллер домена FOOBOX.LOCAL)
nslookup
server dc-02.FOOBOX.LOCAL
trm.BOX.LOCAL
Проверяем что работает mstsc -v trm.box.local
Попадаем на нужную нам машину (зеленая)
Выключаем "Зеленый" терминальный сервер.
Проверяем что работает mstsc -v trm.box.local
Попадаем на нужную нам машину (желтая)
Все работает!
Вывод: приведенный пример настройки - это не задокументированное решение, а, скорее, разрешенный лайфхак в рамках работы протокола DNS. Основная запись, которая у нас в приоритете, находится в кэше DNS сервера, а вторичная будет каждый раз запрашиваться. Таким образом, основная запись будет всегда первой.
Для тех, у кого есть несколько ресурсов в сети, и не требуется выдачи приоритетных записей, используйте обычные A записи с одинаковым TTL. Это надежнее и быстрее.
Если вам нужна помощь с настройкой нетривиальных конфигураций серверов Microsoft - мы готовы провести консультацию и предложить нашу квалифицированную помощь.
Обращайтесь к нам на почту info@zixo.ru
