Выбор службы имен и кэширование


Любая UNIX-подобная операционная система выполняет неисчислимое множество проверок с помощью различных служб имен. Мы уже говорили о службе доменных имен (Domain Name System, DNS), которая отображает имена хостов в IP-адреса (глава 14), но есть еще служба поиска учетных записей, служба сопоставления номера порта TCP/IP с именем сетевой службы, служба сопоставления имени и номера IP- протокола и т. д. С помощью службы nsswitch (name service switching — выбор службы имен) вы можете указать, как FreeBSD должна выполнять все эти запросы и какие источники информации при этом должны использоваться. Кроме того, в состав операционной системы входит демон службы кэширования имен nscd(8), который хранит результаты обращений к службе имен, производившихся ранее, уменьшая объем сетевого трафика и время выполнения последующих запросов.

/etc/nsswitch.conf

Система выбора службы имен, управляющая тем, как FreeBSD отыскивает сетевую информацию, настраивается с помощью файла /etc/nsswitch.conf. В этом файле для каждой службы имен имеется отдельная запись, которая включает тип службы и используемые источники информации. В одном из предыдущих примеров (глава 14) мы уже встречались с выбором службы имен. Помните запись, управляющую порядком поиска хостов?

hosts: files dns

Она означает следующее: «Искать IP-адреса сначала в локальных файлах, а затем использовать службу DNS». Остальные источники информации работают похожим образом. Как и многие другие UNIX-подобные операционные системы, FreeBSD поддерживает возможность выбора служб имен, перечисленных в таблице 15.1, при определении источника информации.

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

Таблица 15.1. Службы имен, поддерживаемые системой

Служба Функция
groups Проверка принадлежности к группе (/etc/group)
hosts Проверка имени хоста и IP-адреса (DNS)
networks Поиск информации о сетях (/etc/networks)
passwd Поиск информации об учетных записях (/etc/passwd)
shells Проверка наличия командного интерпретатора (/etc/shells)
services Поиск служб TCP и UDP (/etc/services)
rpc Удаленный вызов процедур (/etc/rpc)
proto Протоколы в сетях TCP/IP (/etc/protocols)

Для каждой службы имен необходимо определить один или больше источников информации. Многие из этих служб имен очень просты и по умолчанию имеют единственный авторитетный источник информации — файл. Более сложные, такие как служба hosts, могут иметь несколько источников информации. Некоторые службы сложны лишь благодаря большому числу источников информации и многообразию способов получения этой информации. Поскольку в этой книге не рассматриваются технология Kerberos, сетевая информационная служба NIS и другие пользовательские системы управления уровня предприятия, мы не обсуждаем возможность изменения источников информации для служб passwd, groups и shells. Если вы работаете в такой среде, обращайтесь за дополнительной информацией к странице руководства nsswitch.conf(5).

Службы, которые мы будем рассматривать, могут иметь три источника информации: файлы, dns и кэш. Файлы — это стандартные текстовые файлы, содержащие информацию для службы. Например, названия сетевых протоколов традиционно хранятся в файле /etc/protocols, имена сетевых служб — в файле /etc/services, сведения об учетных записях — в файле /etc/passwd и в файлах, сопутствующих ему. Источник dns означает, что требуемая информация доступна на сервере DNS (обычное дело для службы hosts). Наконец, кэш означает, что информацию можно получить у локального демона службы кэширования имен.

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

hosts: cache files dns

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

Кэширование имен с помощью nscd(8)

При анализе протоколов моего сервера DNS очень быстро выяснилось, что большая часть запросов исходит от прокси-сервера и сервера управления сетью. В конце концов, этого и следовало ожидать, потому что прокси-сервер каждую секунду запрашивает десятки веб-страниц для пользователей, а система управления опрашивает все жизненно важные системы в моей сети каждые несколько минут. Хотя эти два сервера и не производят существенную нагрузку, тем не менее нет никаких причин продолжать запрашивать одни и те же данные, которые изменяются чрезвычайно редко. Например, рабочая станция управления сетью отыскивает IP-адреса всех маршрутизаторов и коммутаторов каждые 60 секунд. Эти адреса практически не изменяются, поэтому такое решение не только выглядит неэлегантным, но и раздражает, особенно когда мне приходится просматривать файлы протоколов моего сервера DNS. Точно так же, если сервер интегрирован в крупную сеть, вам может потребоваться аутентификация в домене Kerberos или каталоге LDAP, что может привести систему к необходимости выполнять по сети проверку тысяч учетных записей в минуту. Даже файл /etc/services может содержать несколько тысяч записей, а синтаксический анализ файла в любом случае занимает какое-то время.

Демон кэширования nscd(8) способен обслуживать все источники информации, которые могут быть определены в nsswitch.conf. Каждому типу поискового запроса соответствует отдельная строка в файле конфигурации nscd, /etc/nscd.conf. По умолчанию nscd кэширует все шесть служб имен. Каждая запись содержит ключевое слово и либо название кэша и значение, либо просто значение. Например, запись для службы hosts по умолчанию выглядит так:

enable-cache hosts yes

Ключевое слово — enable-cache, название кэша — hosts, а значение — yes. При таких настройках nscd(8) будет сохранять информацию об именах хостов. Если теперь в файле /etc/nsswitch.conf в качестве первого источника информации для службы hosts указать демон nscd, то все запросы службы имен в первую очередь будут направляться локальному демону nscd. С такими настройками моему серверу DNS направляется лишь часть запросов от прокси-серверов и рабочей станции управления сетью.

nscd(8) и синхронизация

У демона nscd много параметров, которые редко могут пригодиться. Два параметра, наиболее полезных с моей точки зрения, связаны с синхронизацией. Длительностью периода хранения информации в кэше nscd(8) управляют параметры negative-time-to-live и positive-time-to-live.

Параметр positive-time-to-live определяет, как долго nscd(8) будет хранить ответы в кэше. Предположим, что демон nscd(8) кэширует информацию об именах хостов. Определив значение параметра positive-time-to-live, вы тем самым укажете демону nscd(8), сколько секунд должен храниться каждый ответ, прежде чем он будет удален из кэша. Следующая строка предписывает nscd(8) хранить информацию об именах хостов 600 секунд (10 минут):

positive-tine-to-live hosts 600

Через 10 минут nscd(8) сотрет все устаревшие ответы и позволит службе имен искать новый ответ. При получении этого нового ответа демон nscd(8) будет хранить его в своем кэше следующие 10 минут. По умолчанию параметр positive-time-to-live имеет значение 3600 секунд (1 час).

nscd(8) может хранить не только положительные, но и отрицательные ответы. Запросив IP-адрес хоста nonexistent.absolutefreebsd.com, вы узнаете, что такого хоста не существует. Демон nscd(8) сохранит и этот отрицательный ответ. Управлять длительностью хранения отрицательных ответов можно с помощью параметра negative-time-to-live, для определения которого используется тот же синтаксис, что и для параметра positive-time-to-live. По умолчанию параметр negative-time-to-live имеет значение 60 секунд, для любого вида информации.

Очистка кэша

Время от времени в кэше будет сохраняться неверная информация. Например, моя система управления сетью проверяет работоспособность всех жизненно важных сетевых устройств каждые несколько минут. Изменяя IP-адрес маршрутизатора, я вовсе не хочу, чтобы станция управления начала предупреждать меня об отсутствии маршрутизатора; мне требуется, чтобы она, не дожидаясь истечения ближайшего часа, обратилась за получением нового ответа. Пользователь может очистить свой кэш, вызвав nscd с ключом -i, а пользователь root может выполнить очистку всего кэша с помощью ключа -I.

Например, я могу очистить свой кэш хостов с помощью команды:

# nscd -i hosts

Если не выполнить очистку кэша, моя система обновит информацию в кэше только по истечении интервалов времени, заданных параметрами time-to-live.

Запуск nscd(8) на этапе загрузки

Чтобы автоматически запускать nscd(8) во время загрузки, необходимо добавить в файл /etc/rc.conf следующую строку:

nscd_enable="YES"

Комментарии запрещены.