Адресная запись "Address". Балансировка нагрузки. Round Robin. Учет топологии сетей.

2004 г

Система доменных имен

Материалы книги П.Б. Храмцова
iнфоцентр

Адресная запись "Address". Балансировка нагрузки. Round Robin. Учет топологии сетей.

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

Основное назначение адресной записи - установить соответствие между доменным именем машины и IP-адресом. Собственно, это главная задача всей системы доменных имен. По этой причине адресная запись описания ресурса является одной из ключевых записей описания зоны.

Вообще говоря, перед прикладным программным обеспечением, которое работает с DNS, всегда стоит две основных задачи. Во-первых, зная доменное имя хоста, найти его IP-адрес, а, во-вторых, зная IP-адрес, установить доменное имя. Первую задачу будем называть "прямой", а вторую "обратной".

При описании зон используется та же терминология. "Прямая" зона служит для решения "прямой задачи", а "обратная" зона - для решения "обратной" задачи. Решение как прямой, так и обратной задачи не являются тривиальными, т.к. каждому доменному имени можно поставить в соответствие несколько IP-адресов и, наоборот, каждому IP-адресу можно поставить в соответствие несколько доменных имен.

Обе задачи система DNS решает посредством так называемых стандартных запросов (standard queries), в которых указывается доменное имя (QNAME), тип записи описания ресурсов(QTYPE) и класс записи описания ресурсов (QCLASS).

Как при помощи этих трех параметров решается "обратная" задача мы рассмотрим в материале, посвященном записи описания ресурсов типа PTR (Pointer, указатель). "Прямую" задачу решают при помощи адресной записи описания ресурсов, которая имеет тип "A".

Адресная запись - это основа файла описания "прямой" зоны. Запись имеет следующий формат:

[host][ttl] IN A [address]

Поле host определяет доменное имя хоста (например, компьютера, на котором установлена и производит обслуживание программа, реализующая один из сетевых сервисов, например, web-сервер).

Чаще всего, это имя указывается относительно имени текущей зоны, поэтому на конце имени не проставляется символ ".", т.е. задается неполное имя хоста.

Если же надо описать машину из другой зоны, то следует указать ее полное доменное имя (fully qualified name) и не забыть в конце этого имени символ ".". Например, "quest.polyn.kiae.su.", указанное в поле host ссылается на машину с именем quest.polyn.kiae.su. Можно также применить директиву управления $ORIGIN и переопределить имя текущей зоны.

Поле ttl обычно оставляют пустым. Поле ttl определяет время хранения адресной записи в кэше сервера доменных имен или кэше "умного" resolver-а. Если значение поле ttl не задано, то оно берется из директивы управления $TTL для BIND 8 и 9 версий, или из поля minimum записи SOA для старых версий BIND.

Приемлемым временем кэширования можно принять значение "3 часа", что обычно записывается в виде числа секунд - 10800:

My-host	10800	IN	A	192.168.0.1

В поле address указывают IP-адрес машины. В этом адресе точку на конце ставить не надо.

При делегировании доменов и в самом начале описания зоны (поле primary master сервера записи SOA и NS) возникает проблема описания серверов, поддерживающих описания зоны и описания поддоменов. В этих записях указываются доменные имена серверов, но не указывается их IP-адресов.

DNS - это только информационный сервис, который сам опирается на TCP/IP. При маршрутизации пакетов по сети нужно знать IP-адреса, а их-то как раз и не хватает для обращения к серверам поддоменов и к серверу зоны, если он расположен в той же зоне.

Для решения этой проблемы используются "приклеенные" (буквально "glue") записи типа "А". При этом нет разницы что будет указано в описании зоны раньше - использование доменного имени или определение соответствия этого имени IP-адресу.

Теперь приведем пример записи типа A и использование "приклеенных" адресных записей. Во-первых, рассмотрим простую запись типа A:

$ORIGIN vega.ru.
vega-gw		IN	A	194.226.43.1

В данном случае в зоне vega.ru определяется доменное имя для машины с IP-адресом 194.226.43.1. Для каждой машины зоны будет указана такая же запись. Таким образом мы назначаем каждому хосту в локальной сети доменное имя.

Теперь рассмотрим использование "приклеенной" записи для сервера зоны, который указан в записи SOA:

$ORIGIN	vega.ru.
@	IN	SOA 	vega-gw.vega.ru	paul.kiae.su (
			101		; serial number
			86400		; refresh within a day
			3600		; retry every hour
			3888000		; expire after 45 days
			10800 )		; negative caching
	IN	NS	vega-gw.vega.ru.
	IN	A	194.226.43.1
;
vega-gw	IN	A	194.226.43.1

В данном примере при назначении сервера зоны в записи NS IP-адрес этого сервера еще не определен, но это и не суть важно, главное, чтобы он был определен далее в одной из адресных записей описания зоны.

Кроме этого, для обслуживания почтовых адресов типа:

/usr/paul>mail paul@vega.ru

"приклеена" еще одна адресная запись, которая назначает текущему домену IP-арес 194.226.43.1.

Формально эта запись определяет адрес для запросов по неполному имени. В данном случае для всех запросов, которые используют имя зоны, определен адрес шлюза, на котором установлено обслуживание всех сервисов, например, http://vega.ru/ или gopher://vega.ru/. Обычно такой подход используют в маленьких сетях для упрощения работы с сервисами этих сетей.

На самом деле, адресная запись для доменного имени зоны и доменного имени сервера vega-gw.vega.ru "приклеенными" не являются. "Приклеенными" называют только те записи, которые необходимы для поиска IP-адреса, который в контексте запроса невозможно найти путем обращения к авторитативному серверу соответствующей зоны. В нашем же случае мы уже добрались до описания нашей зоны, а в ней есть адресная запись соответствия имени зоны некоторому IP-адресу. Скорее всего, это произошло благодаря настоящей "приклеенной" записи адреса нашего сервера в родительской зоне.

Вообще говоря, правильнее проблему "приклеенных" записей рассматривать с точки зрения выполнения запросов к DNS. В откликах на запросы эти записи помещаются в специальную дополнительную секцию, откуда и извлекаются resolver-ом. Собственно, по этой причине их и называют "приклеенными", т.е. дополнительными.

Примером настоящей "приклеенной" записи может служить делегирование зон внутри домена. Если сервер поддомена будет находиться в самом этом поддомене, то кроме как через приклеенную адресную запись мы не сможем узнать его IP-адрес. Он является авторитативным за зону и в описании зоны, которая хранится у него, задано соответствие его собственного доменного имени и IP-адреса. Но как до него добраться? При помощи "приклеенных записей" в описании родительской зоны!

Пусть мы создаем два поддомена zone1 и zone2, серверы которых также расположены в этих же поддоменах:

$ORIGIN	vega.ru.
@	IN	SOA 	vega-gw.vega.ru	paul.kiae.su (
			101		; serial number
			86400		; refresh within a day
			3600		; retry every hour
			3888000		; expire after 45 days
			10800 )		; negative caching
	IN	NS	vega-gw.vega.ru.
	IN	A	194.226.43.1
;
vega-gw	IN	A	194.226.43.1
.........
; Glue address records.
zone1-gw.zone1	IN	A	194.226.43.2
zone2-gw.zone2	IN	A	194.226.43.3
; Subdomain delegation.
zone1	IN	NS	zone1-gw.zone1.vega.ru.
zone2	IN	NS	zone2-gw.zone2.vega.ru.

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

Всегда существует соблазн задать лишние "приклеенные" записи. Например, адресную запись для сервера доменных имен провайдера, на котором поддерживается slave для вашей зоны. Такая практика встречалась раньше довольно часто, встречается она и сейчас. На самом деле, такая запись лишняя. Соответствие имени адресу можно получить непосредственно из зоны провайдера.

Размещать ненужные "приклеенные" записи в своей зоне не стоит по целому ряду причин. Во-первых, IP-адрес сервера провайдера может измениться, а Вы этого не узнаете, соответственно, возникнет коллизия некорректного делегирования зоны, и отвечать на запросы будет только один ваш сервер. Во-вторых, современные версии BIND все равно проигнорируют ваши некорректно "приклеенные" записи J.

Рассмотрим пример описания зоны с некорректно "приклеенной" записью:

$ORIGIN ru.
webstatistics 3600 IN SOA ns.webstatistics.ru. hostmaster.webstatistics.ru. (
                                1 3600 600 86400 3600 )
        3600    IN      NS      ns.webstatistics.ru.
        3600    IN      NS      ns4.nic.ru.
                IN      A       144.206.192.60
$ORIGIN webstatistics.ru.
ns      3600    IN      A       144.206.192.60
$ORIGIN nic.ru.
ns4     IN      A       194.226.96.8 ; некорекктно "приклеенная" запись

Запись сообщения named при запуске сервера об игнорировании некорректных приклеенных записей будет выглядеть следующим образом:

Oct  7 12:15:34 generate named[136]:
dns_master_load: webstatistics.ru:10: ignoring out-of-zone data (ns4.nic.ru)

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

Если у вас возникнут проблемы с доступностью сети, то ваша зона вообще может лишиться авторитативных серверов, что тоже является нежелательным, т.к. приводит к увеличению трафика в системе доменных имен, а также к негативному кэшированию отказов.

Рассмотрим теперь случай, когда одному и тому же доменному имени присваивается несколько IP-адресов. Ситуация эта не такая уж и редкая. Пример, который лежит на поверхности - это корневые серверы доменных имен, т.е. серверы, которые обслуживают корневую зону.

Мы знаем, что их 13 и, что за каждым именем корневого сервера скрывается много машинный комплекс. У каждого из этих хостов свой собственный IP-адрес, следовательно, доменное имя соответствует нескольким IP-адресам.

Другой пример - хост выполняет функции шлюза. У него одно доменное имя, но каждый из интерфейсов имеет свой собственный IP-адрес, следовательно, одному имени будет соответствовать несколько IP-адресов.

Еще один пример - балансировка нагрузки на Web-серверах. Балансировка нагрузки через DNS - это, видимо, не самое оптимальное решение, но в качестве первого приближения решения проблемы оно проходит.

Предыдущее замечание относится главным образом к тому, что называют Round Robin алгоритмом. Существуют более оптимальные решения, построенные на основе DNS, например, RFC 1794, но они не реализованы в виде стандартных опций BIND.

Смысл Round Robin алгоритма в DNS легко понять, опираясь на содержание сообщения отклика сервера доменных имен. Дело в том, что в ответ на стандартный запрос сервер отправляет список записей описания ресурсов, которые отвечают требованиям запроса.

Когда запрашиваются записи адресного типа, то клиенту (resolver или локальный сервер) возвращается список записей в том порядке, как они встретились в описании зоны. Именно в этом порядке прикладная программа и начинает проверять адреса с целью установки соединения.

Понятно, что в этом случае первый адрес будет использоваться наиболее часто. Если реализовать циклическую перестановку адресов в отклике сервера доменных имен, то тогда все IP-адреса будут задействованы относительно равномерно.

Рассмотрим пример:

$ORIGIN ru.
Webstatistics 3600 IN SOA ns.webstatistics.ru. hostmaster.webstatistics.ru. (
                1 3600 600 86400 3600 )
        3600    IN      NS      ns.webstatistics.ru.
        3600    IN      NS      ns4.nic.ru.
                IN      A       144.206.192.60
$ORIGIN webstatistics.ru.
ns      3600    IN      A       144.206.192.60
;
www     3       IN      A       144.206.192.60
        3       IN      A       144.206.192.61
        3       IN      A       144.206.192.62

Мы задали три адреса для одного и того же доменного имени. Теперь посмотрим при помощи nslookup, как будет сервер реагировать на наши запросы:

> www.webstatistics.ru
Server:  [144.206.192.60]
Address:  144.206.192.60


Name:    www.webstatistics.ru
Addresses:  144.206.192.62, 144.206.192.60, 144.206.192.61


> www.webstatistics.ru
Server:  [144.206.192.60]
Address:  144.206.192.60


Name:    www.webstatistics.ru
Addresses:  144.206.192.61, 144.206.192.62, 144.206.192.60


> www.webstatistics.ru
Server:  [144.206.192.60]
Address:  144.206.192.60


Name:    www.webstatistics.ru
Addresses:  144.206.192.60, 144.206.192.61, 144.206.192.62


>

и далее по кругу. Вот это и есть Round Robin алгоритм.

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

Впервые "тасовать" адреса (Shuffle Addresses) предложил Брайн Бичер, но его идея требовала введения дополнительных записей описания ресурсов, поэтому прошло решение Маршала Розе, которое, собственно, и называется Round Robin код.

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

Следует заметить, что современные resolver-ы позволяют игнорировать при соответствующей настройке упорядочивание записей в отклике сервера и опираться на топологию сети, т.е. обращаться к наиболее предпочтительному с их точки зрения IP-адресу. Таким resolver-ом является, например, resolver операционной системы Windows2000.

В последних версиях сервера доменных имен компании Microsoft (для Windows 2000 и NT) Round Robin по умолчанию не используется, а используются предпочтения, основанные на так называемой эвристике LocalNetPriority. Это значит, что в локальной сети всегда предпочтение отдается локальным адресам.

Естественно, что при применении Round Robin алгоритма время кэширования адресных записей следует уменьшить. Встречаются рекомендации, которые советуют установить TTL в 300 секунд. В примере задан интервал в 3 секунды (фактически кэширование отменено) только для того, чтобы кэширование не влияло на сообщения nslookup.

Вообще говоря, 8-я версия BIND позволяет настраивать "тасование" записей. Записи в откликах могут переставляться не циклически, а случайным образом. Для этого в файл конфигурации named в директиву options следует включить нечто похожее на следующий блок:

rrset-order {
	class IN type A name "www.kyky.ru" order random;
	order cyclic;
}

В данном случае адресные записи для хоста www.kyky.ru будут "тасоваться" случайным образом, а все остальные записи - циклически. При этом Round Robin будет применяться не только к адресным записям.

К сожалению, в 9-ой версии BIND заказать тип "тасования" нельзя. В этой версии применяется только random-cycling, т.е. начальная точка циклической перестановки выбирается случайным образом. Более того, он применяется по умолчанию, как только встретиться подходящий набор записей (RRset).

Если в вашей конфигурации встретиться опция rrset-order, а сервер эту опцию не поддерживает, то в логах появится запись вида:

Oct  7 12:44:47 generate named[136]:
/etc/named.conf:7: option 'rrset-order' is not implemented

Мы написали "к сожалению", но на самом деле существуют веские причины, по которым случайный выбор порядка адресов тоже не является удачным решением. Обычно это происходит из-за короткого списка IP-адресов, что не позволяет реально балансировать нагрузку.

Перестановка адресов в купе с негативным кэшированием также не является приятной особенностью системы DNS. Если вдруг из списка IP-адресов один из адресов окажется не доступен, то закэшированный отклик будет постоянно мешать установке соединения с сервисом, у которого остальные IP-адреса функционируют нормально.

В BIND существуют и другие возможности сортировки отклика, состоящего из нескольких записей описания ресурсов - это директивы sortlist и topology. Первая принудительно задает порядок адресов в отклике, например для запросов из локальной сети на первое место в отклике будут ставиться адреса из локальной сети, если они существуют.

Такая ситуация может возникнуть, например, при обращении к удаленному ресурсу, чье зеркало находится в локальном сегменте сети.

Приведем пример использования директивы sortlist. Сначала посмотрим на файл конфигурации named.conf:

options {
        directory "/etc/namedb";
        pid-file "named.pid";
        allow-query {any;};
        allow-recursion { "kiae"; };
        sortlist {
        { 144.206.192/24; { 144.206.192/24; 144.206.160/24;};};
        { 144.206.160/24; { 144.206.160/24; 144.206.192/24;};};
        };
};

В нем мы добавили в директиву options опцию sortlist. Она задает порядок отображения записей описания ресурсов при доступе из подсетей 144.206.192/24 и 144.206.160/24. Суть его (порядка) заключается в том, чтобы в списке отклика первыми указывались записи, указывающие на ресурсы соответствующей подсети.

При этом сам файл описания зоны будет содержать следующую информацию:

$ORIGIN ru.
Webstatistics 3600 IN SOA ns.webstatistics.ru. hostmaster.webstatistics.ru. (
                1 3600 600 86400 3600 )
        3600    IN      NS      ns.webstatistics.ru.
        3600    IN      NS      ns4.nic.ru.
                IN      A       144.206.192.60
$ORIGIN webstatistics.ru.
ns      3600    IN      A       144.206.192.60
$ORIGIN nic.ru.
ns4             IN      A       194.226.96.8
$ORIGIN webstatistics.ru.
www     3       IN      A       144.206.192.60
        3       IN      A       144.206.192.61
        3       IN      A       144.206.192.62
        3       IN      A       144.206.160.32

Для адреса www.webstatistics.ru определены адресные записи из двух перечисленных в файле конфигурации подсетей. Посмотрим с хостов, расположенных в каждой из этих подсетей, что увидит программа nslookup.

Для хоста из 144.206.160.32 получим:

> www.webstatistics.ru
Server:  [144.206.192.60]
Address:  144.206.192.60


Name:    www.webstatistics.ru
Addresses:  144.206.160.32, 144.206.192.60, 144.206.192.61, 144.206.192.62


>

А для хоста 144.206.192.2 получим:

> www.webstatistics.ru
Server:  [144.206.192.60]
Address:  144.206.192.60


Name:    www.webstatistics.ru
Addresses:  144.206.192.60, 144.206.192.61, 144.206.192.62, 144.206.160.32


> www.webstatistics.ru
Server:  [144.206.192.60]
Address:  144.206.192.60


Name:    www.webstatistics.ru
Addresses:  144.206.192.60, 144.206.192.61, 144.206.192.62, 144.206.160.32


>

Из последнего примера видно, что алгоритм "тасования" записей при использовании sortlist не активируется.

Вторая директива (topology) имеет ограниченное применение, т.к. в BIND 9 не поддерживается.

Рассмотрим теперь обратную ситуацию, когда одному IP-адресу можно назначить несколько доменных имен. В принципе, в рамках DNS существует запись описания ресурса CNAME, которая позволяет поддерживать доменные имена синонимы для главного (канонического) имени, за которым и закреплен IP-адрес хоста.

Однако, использование CNAME, во-первых, порождает цикл обращений к серверу для получения сначала канонического имени, а потом уже IP-адреса, а, во-вторых, на использование CNAME наложен целый ряд ограничений.

Ни один документ не запрещает нам использовать несколько адресных записей, которые ставят разные доменные имена в соответствии с одним и тем же IP-адресом. При этом имена могут принадлежать совершенно разным доменам.

Примером такого сорта могут служить одна из разновидностей виртуальных web-серверов (software web server). В этом случае IP-адрес хоста остается постоянным, а вот доменное имя, по которому на сервер попадают запросы, может изменяться, при чем сам web-сервер, зная содержание URL, имеет возможность откликаться на запросы разными страницами.

Рекомендованная литература:

P. Mockapetris. RFC-1034. DOMAIN NAMES - CONCEPTS AND FACILITIES. ISI, 1987. (http://www.ietf.org/rfc/rfc1034.txt?number=1034)
P. Mockapetris. RFC-1035. DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION. ISI, 1987. (http://www.ietf.org/rfc/rfc1035.txt?number=1035)
M. Andrews. RFC 2308. Negative Caching of DNS Queries (DNS NCACHE). 1998.(http://www.ietf.org/rfc/rfc2308.txt?number=2308)
Альбитц П., Ли К.. DNS и BIND. - Пер. с англ. - СПб: Символ-Плюс, 2002. - 696 с.
Документация по BIND 9. Справочное руководство системного администратора. (http://www.nominum.com/resources/documentation/Bv9ARM.pdf)

Полезные ссылки:

http://support.microsoft.com/default.aspx?scid=KB;EN-US;Q177883& - это материал службы технической поддержки Microsoft, в котором поясняются детали настройки Round Robin.
http://www.ietf.org/rfc/rfc1794.txt?number=1794 - T. Brisco. RFC 1794. DNS Support for Load Balancing. Предложения по использованию DNS для баланса нагрузки. В реальной жизни не используется, но почитать интересно.

Назад Оглавление Вперед