Планирование устойчивой системы доменных имен
Кэширование в NNM
Кэширование в NNM и кэширование в DNS – это не одно и то же, и я хочу уточнить, что применяются два вида кэширования.
Этот конфигурационный файл сервера имен содержит имена и соответствующие IP-адреса всех систем в домене north.acme.com.
NNM выполняет очень много повторяющихся операций на одних и тех же устройствах. Чтобы избежать потенциально затратного поиска информации от других служб, NNM кэширует эту информацию, чтобы повысить общую производительность. Информация записывается на диск и сохраняется после выполнения команд ovstop и ovstart или перезагрузки. Оборотная сторона такой "живучести" данных заключается в том, что внешние изменения конфигурации сети могут привести к потере контакта NNM с теми устройствами, которые изменились. В этом случае необходимо воспользоваться командой xnmsnmpconf — clearCache для очистки кэша конфигурации SNMP. Эту команду следует выполнять, когда меняются имена и IP-адреса устройств, управляемых SNMP, а NNM не отслеживает изменение. Перед очисткой кэша конфигурации SNMP может потребоваться удалить устройство-нарушитель из всех схем. Когда база данных NNM удаляется в порядке подготовки к "послестартовому" раскрытию, имеет смысл очистить и кэш конфигурации SNMP.
Первичность, вторичность и другие премудрости
С появлением восьмой версии BIND (Berkeley Internet Name Daemon) термины "основной сервер" и "вспомогательный сервер" заменены понятиями "ведущий сервер" и "подчиненный сервер" соответственно. Конфигурационный файл /etc/named.boot теперь именуется /etc/named.conf, и синтаксис файла усовершенствован для большей гибкости и удобочитаемости. Имеется даже Perl-скрипт ( named-bootconf.pl ) для обновления синтаксиса конфигурационного файла.
Этот конфигурационный файл сервера имен содержит IP-адреса и соответствующие имена всех систем в диапазоне 10.121.121.
Восьмая версия BIND является предпочтительной из-за множества новых возможностей. Она способна проверять, соответствуют ли имена в базе данных или в ответах RFC 953. Обеспечивается полное управление журнализацией сообщений. Список доступа разрешенных подчиненных серверов ограничивает возможности взломщиков по выполнению зонных пересылок. Это также означает, что требуется согласование с группой поддержки DNS, если решено запустить NNM в качестве вспомогательного/подчиненного DNS-сервера. Имеется средство синхронизации, позволяющее ведущему серверу уведомлять его подчиненные серверы об обновлении базы данных. Динамические обновления поддерживаются путем разрешения авторизованной системе посылать ведущему серверу сообщения об обновлениях. Это особенно полезно в средах DHCP (Dynamic Host Configuration Protocol).
Система NNM конфигурируется с только кэширующим сервером имен и ссылается на два ведущих сервера в зоне noth.acme.com. Они, в свою очередь, ссылаются на два корневых сервера имен, которые конфигурируются с полномочными записями, указывающими на шесть серверов имен.
Расширенная картина реализации DNS
В этом разделе рассматривается взаимосвязь между различными архитектурными элементами реализации DNS (см. рис. 2.8).