Компания HP
Опубликован: 22.09.2006 | Доступ: свободный | Студентов: 675 / 67 | Оценка: 4.22 / 3.72 | Длительность: 22:59:00
ISBN: 978-5-9556-0042-6
Лекция 2:

Планирование устойчивой системы доменных имен

< Лекция 1 || Лекция 2: 1234 || Лекция 3 >
Аннотация: Значение службы DNS для NNM. История /etc/hosts. Интерфейсы маршрутизаторов и DNS. Модели надежности для DNS. Делегирование. Коэффициенты загрузки систем DNS. Кэширование в NNM.
Ключевые слова: network node, manager, система доменных имен, DNS, поиск, прямой, обратный, значение, файл, масштабируемость, кэширование, делегирование полномочий, делегирование, информация, Unix, RED, hat, сервер, диаграмма, архитектура, ICMP, пространство имен, поддомен, объединение, эффективный механизм, Web, Internet, HTML, вывод, адрес, поле, хост, размер файла, host, мегабайт, масштабируемость решения, e-mail, domain name, nameserver, daemon, маршрутизатор, fast, Ethernet, адаптер, команда, интерфейс, список, представление, HSSI, loopback, циклический список, сетевые приложения, надежность, приложение, resolver, Windows, GUI, маршрут, программное обеспечение, время ожидания, конфигурирование, локальный кэш, базы данных, диск, корпоративные сети, единица, домен, контроль, локальный хост, EAST, COM, шлюз, email, распознаватель, демон, указатель, network controller, Panel, сигнал SIGINT, операции, свопинг, память, intranet, производительность, SNMP, база данных, кэш, синтаксис, множества, RFC, журнализация, подчиненный сервер, средство синхронизации, DHCP, dynamic, configuration, protocol, очередь

Введение

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

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

До появления DNS поддерживался файл /etc/hosts — простой линейный файл, содержащий имена и IP-адреса сетевых систем. Проблемы, связанные с размером файла и его распространением, заметно ограничивали масштабируемость.

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

В DNS обеспечивается ряд средств повышения надежности, гарантирующих бесперебойное предоставление сервиса клиентским системам (таким как NNM). Эти средства включают наличие у клиента нескольких серверов имен, кэширование, основные и вспомогательные серверы и иерархию серверов имен для делегирования полномочий.

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

В этой лекции приводятся примеры конфигурационных файлов для клиента и сервера DNS (для ОС UNIX). Предполагается наличие восьмой версии BIND; примеры файлов являются реальными, проверенными на моей системе Red Hat Linux.

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

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

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

Полное руководство по DNS приводится в книге Abitz и Liu DNS and BIND, Third Edition, O’Reilly & Associates Inc., ISBN 1-56592-010-41Имеется переводное издание на русском языке: Альбитц П., Ли К.. DNS и BIND. – Пер. с англ. – СПб: Символ-Плюс, 2002. – 696 с. Прим. переводчиков.

Почему служба DNS настолько важна для NNM

NNM раскрывает устройства с помощью IP-адреса, обнаруживаемого в ARP-кэшах, начальных файлах, таблицах маршрутизации и откликах ICMP. В IP-сетях устройствам приписываются имена, и в больших сетях это пространство имен разбивается на иерархию поддоменов. Это устраняет возможность коллизии имен в больших сетях, где поддерживается высокий уровень проверки конфигурации, порождающий высокую интенсивность прямого и обратного DNS-поиска. Такой механизм поиска может стать узким местом производительности.

Распространенной проблемой является объединение системой NNM двух маршрутизаторов в один узел. Это обычно случается из-за дефектных данных DNS.

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

Все крупные компании с большими сетями полагаются на свои реализации DNS, чтобы распределить полномочия по назначению имен и IP-адресов между более мелкими и легко управляемыми официальными поддоменами. Заметим, что основанные на web сервисы в Internet вообще не функционировали бы без DNS. Как бы происходило создание HTML с жестко закодированными IP-адресами? DNS очень хорошо масштабируется к самым большим сетям.

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

Можно использовать команду NNM ovtopodump, чтобы отыскивать устройства, для которых нет записей DNS:

ovtopodump –Lr > report_name

С помощью этой команды можно получить очень полезную однострочную сводку для каждого устройства в базе данных NNM. В системе UNIX можно направить вывод команды ovtopodump в один или несколько фильтров (таких как sort ) с какой-либо особой целью. Например, предположим, что желательно выяснить, для каких устройств домена управления отсутствуют записи DNS. Для этого достаточно выполнить команду

ovtopodump –Lr | sort > report_name

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

История /etc/hosts

Исторически в Internet-системах для распространения информации об IP-адресах и именах хостов использовался файл HOSTS.TXT. Это плоский текстовый файл, который просматривается от начала до конца при каждом прямом поиске (задается имя, а возвращается IP-адрес) или обратном поиске (задается IP-адрес, а возвращается имя). Формат файлов HOSTS.TXT и /etc/hosts приведен на рисунке 2.1.

Формат файла /etc/hosts

увеличить изображение
Рис. 2.1. Формат файла /etc/hosts

Поля разделяются пробелами. Поле 1 – это IP-адрес. Поле 2 содержит формальное имя системы. Дополнительные поля (до символа комментария #) являются альтернативными именами для этого устройства. После знака # могут располагаться необязательные комментарии.

HOSTS.TXT должен был всегда содержать самые свежие данные, поэтому он обновлялся в одном узле в соответствии с информацией, обеспечиваемой многими хост-мастерами Internet, и ежедневно загружался всеми системами, которые им пользовались. Эта процедура обеспечивала согласованность содержимого файла HOSTS.TXT в Internet. Со временем размер файла HOST.TXT вырос до нескольких мегабайт, и объем трафика, который требовался для его загрузки, стал слишком велик. Коротко говоря, оказалось, что HOST.TXT не является масштабируемым решением.

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

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

Механизм HOST.TXT немного стоил и в отношении информации. Например, чтобы послать e-mail в систему, не подключенную напрямую к Internet, отправителю нужно было знать почтовые системы по всему пути и включать их адреса в качестве части e-mail-адреса.

Таким образом, в Internet требовался сервис имен, который бы:

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

Этим сервисом стал DNS/BIND (Domain Name Service/Berkeley Internet Nameserver Daemon). Он полностью отвечает каждому из приведенных выше требований, в особенности требованию масштабирования. DNS масштабируется до размеров Internet и абсолютно необходим для работы web-приложений.

< Лекция 1 || Лекция 2: 1234 || Лекция 3 >