четверг, 11 октября 2012 г.

Вариант балансировки сетевого трафика на базе DNS

imageБалансировка сетевого трафика (NLB) – это очень важный и ответственный вопрос в теме обеспечения отказоустойчивости. Те, у кого есть возможность, конечно же не задумываясь покупают аппаратные балансировщики и живут спокойно, те у кого денег не так много, реализуют NLB на базе службы Windows Network Load Balancing. Но есть и те, кому приходится реализовывать задачу балансировки при помощи DNS round robin (попросту создав две или более А-записей с одним именем и разными IP адресами). Прямо скажем, round robin – это совсем не удачны вариант в плане именно отказоустойчивости.

В данной статье я предлагаю вам обсудить ещё один вариант балансировки на базе DNS и прошу высказать все свои “за” и “против” в комментах ниже.

Итак, имеем локальную зону contosot.com, и будем балансировать 2 сервера по FQDN array.contoso.com

Для этого:

1. в локальной зоне (на вашем текущем DNS сервере) создадим делегирование для зоны array.contoso.com и укажем в настройках в качестве DNS серверов – сервера, которые мы будем балансировать (у меня это 192.168.111.7 и 192.168.111.8)

image

Рис.1: Настройка делегирования на основном DNS сервере.

2. Чтобы делегирования настроилось и заработало, нужно на указанных серверах предварительно установить службу DNS и создать Primary зону array.contoso.com. При этом в настройках этой зоны в качестве IP адреса “самой зоны” (А-запись same as parent folder) укажем IP адрес текущего сервера. На другом сервере сделаем тоже самое, только укажем уже его IP адрес.

image

Рис.2: Настройка DNS-зоны на одном из серверов.

3. Для того, чтобы обеспечить “отказоустойчивость” решения, нужно настроить параметры обновления записей (см. рис.2). В качестве примера, я установил все настройки в 5 секунд. В рабочей среде вы должны серьезно обдумать эти значения, чтобы не получить DDOS на сервера, в случае большого количества клиентов. Т.е. надо найти золотую середину между допустимым временем простоя и количеством запросов на сервер от клиентов.

Результат

Если мы попробуем пинговать адрес array.contoso.com с клиентского компьютера, то будем получать в разное время разный IP адрес (см. рис.3)

image

Рис. 3: Пинг имени array.contoso.com

Описание

Итак, что же у нас получилось:

Когда клиент запрашивает у DNS сервера имя array.contoso.com, ваш DNS сервер понимает, что эту зону обслуживают 2 других DNS сервера и сам запрашивает у одного из них IP адрес хоста array.contoso.com. Т.к. на каждом из серверов в качестве имени хоста array.contoso.com указан только один (свой собственный) IP адрес, то получается, что только он и возвращается клиенту.

Предполагается, что ваш DNS сервер будет приблизительно равномерно распределять запросы между 2-я DNS серверами, указанными в делегировании.

В чем отличие от round robin

Отличие в том, что если один из серверов не отвечает, то DNS не сможет запросить у него содержимое зоны и попытается разрезолвить IP адрес через другой DNS сервер. Такого в round robin не происходит!

Очевидно, что настройками TTL мы можем регулировать время, когда DNS зона будет запрашиваться заново и таким образом проверять работоспособность сервера.

Примечание: По факту, проверяется работоспособность службы DNS, а не самого сервера и уже тем более не Exchange`a, работающего на этом сервере.

5 комментариев:

Анонимный комментирует...

Если вести речь о балансировке в отношении Exchange, то этот способ также не работает как и RR DNS: клиент Outlook получит другой ip-адрес сервера и "закапризничает".

Если вести речь о самой схеме с делегированием зоны, то она вообще вне закона: primary зона должна быть одна и должна быть целостной - а тут на одном сервере одни адреса, на другом другие, а на третьем и то, и другое - полный криминал :-)

Unknown комментирует...

Попробовали у себя так сделать, ответ сервера кешируется на ДНС сервере и отдается клиентам постоянно один в итоге. Не подскажите как избежать?

mixroot комментирует...

Это не самый хороший вариант.. Лучше HAproxy.

Unknown комментирует...
Этот комментарий был удален автором.
Анонимный комментирует...

Неудачный вариант. Можете получить даже реальные проблемы с доступностью. Пример - если у клиента некоторые запросы DNS фейлятся (да, такое бывает, когда к примеру есть центральный офис с контроллером и пачка удаленных рабочих мест, включенных в домен).

Отправить комментарий