Учебно-методические материалы для студентов кафедры АСОИУ

Централизованное управление ресурсами. Службы каталогов

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

Что такое служба каталогов?

Служба каталогов — это сетевой сервис, представляющий централизованные средства управления ресурсами автоматизированной системы. Под ресурсами подразумеваются все компоненты сетевой инфраструктуры, которые используются для выполнения функций АСУ: пользователи, файлы и каталоги, устройства, сетевые сервисы и т.д. (рис.1).

Служба каталогов

Рис. 1. Служба каталогов

Как правило, служба каталогов состоит из базы данных, в которой размещены сведения о сетевых ресурсах и серверного ПО, представляющего механизмы доступа к этой базе. Как база данных сервиса каталогов, так и ее управляющая программа могут быть распределены на несколько серверов (рис. 2).

Распределенная служба каталогов

Рис. 2. Распределенная служба каталогов

Основными функциями службы каталогов являются следующие:

Среди дополнительных функций сервиса каталогов можно указать, например, такие:

Сетевая политика — совокупность правил, определяющих методы и средства взаимодействия с общими ресурсами в корпоративной сети.

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

Рассмотрим основные особенности некоторых сервисов каталогов, различных по представляемым возможностям.

Популярные службы каталогов

Network Information Service (NIS/YP)

NIS (Сетевая Информационная Служба) — служба каталогов, разработанная и реализованная Sun Microsystems для систем на основе UNIX. NIS первоначально назывались Yellow Pages (YP), но из-за проблем с торговым знаком Sun изменила это название. Старое название (yp) используется в названиях утилит NIS.

NIS - это иерархическая система, в которой существует три типа хостов: основные (master) серверы, вторичные (slave) серверы и клиентские машины (рис. 3). В качестве источников данных для клиентов используются системные файлы (в терминах NIS — карты ресурсов) основного сервера NIS: passwd, hosts, group, services и прочие. В сети может быть один основной сервер NIS и ни одного или более вторичных серверов. Вторичные серверы хранят копии общих файлов основного сервера для обеспечения избыточности. Клиенты могут быть настроены как на работу с основным сервером NIS, так и со вторичными. Чтобы получить доступ к запрашиваемой информации клиент должен являться членом домена NIS.

Элементы структуры NIS

Рис. 3. Структура Network Information Service (NIS)

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

Общий доступ реализуется по следующей схеме: когда клиентскому приложению требуется доступ к некоему ресурсу, то локальные обращения (например, к файлу hosts) транслируются в вызовы удаленных процедур сервера NIS, с которым связан клиент. Поскольку NIS использует RPC, то NIS-серверы работают на тех портах, которые им представляет сервис RPC (т.е. у службы NIS нет выделенного номера порта, в отличие от, например, ftp-сервера или веб-сервера).

Установление связи с сервером NIS выполняется путем широковещательной рассылки запросов. Если в сети имеется несколько серверов (основной и несколько вторичных), то клиент NIS (обычно это программа ypbind) будет использовать адрес первого ответившего и направлять все свои запросы на этот сервер. Время от времени ypbind будет проверять доступность сервера. Если тот не ответит за разумное время, то клиент снова начнет процедуру опроса сети в поисках «живого» сервера.

Сервис NIS поддерживается большинством UNIX-систем общего назначения и представляет простые и удобные средства для организации централизованного управления сетью. NIS хорошо интегрируется с такими сетевыми сервисами, как например DHCP или NFS.

Среди сновных проблемы NIS выделим две:

Из-за второго недостатка NIS не рекомендуется применять в публичных сетях. Для устранения недостатков NIS были разработаны усовершенствованные спецификации протокола (NYS и NIS+), но они не столь популярны.

Практическое задание по развертыванию NIS в локальной сети приведено в этой лабораторной работе. Исходную спецификацию NIS можно получить на сервере Sun Microsystems (теперь Oracle), в разделе документации (Network Information Service), а практические советы по планированию и развертыванию этой службы — например, на сервере Linux Documentation Project (NIS-HOWTO).

LDAP

Модель OSI определяет самые разные аспекты взаимодействия открытых систем. Имеется в ней и спецификация X.500, описывающая службу каталогов. X.500 — это серия рекомендаций разработанных ITU-T в 1993 г. и получивших статус международного стандарта (ISO/IEC 9594-1). Спецификация X.511 описывает протокол DAP для доступа к каталогам X.500. DAP, принятый в качестве международного стандарта, оказался избыточным и сложным в реализации и на его основе были разработаны адаптированные версии, среди которых NDS и LDAP.

Протокол LDAP (Lightweight Directory Access Protocol, упрощенный протокол доступа к каталогу) — бинарный клиент-серверный протокол прикладного уровня, предназначенный для доступа к распределенной службе каталогов через Интернет. Этот протокол может использоваться как в качестве шлюза к любым X.500-совместимым каталогам (рис. 4), так и в качестве основного сервиса каталогов (рис. 5). Спецификация текущей версии (LDAP v3) приведена в RFC 4510.

LDAP as X.500 gateway

Рис. 4. LDAP в роли шлюза к каталогу X.500

LDAP as stand-alone service

Рис. 5. LDAP в качестве самостоятельного сервиса

В терминах X.500 каталог представляет собой «совокупность открытых систем, совместно предоставляющих службы каталогов». Проще говоря, это распределенная клиент-серверная база данных, доступ к которой возможен через унифицированные интерфейсы. Пользователь каталога, который может быть человеком или другим каким-то объектом, получает доступ к каталогу (Directory) с помощью клиентского приложения (DUA). Клиент взаимодействует с одним или более серверами через агентов системы каталогов (DSA) (рис. 4).

LDAP устанавливает порядок взаимодействия между клиентом и сервером на основе обмена сообщениями. Сообщения определяют запрашиваемые клиентом операции, ответы сервера и формат передаваемых данных. LDAP — это сессионный протокол, требующий установления, поддержания и разрыва соединения между клиентом и сервером, поэтому основным транспортом для него является TCP. Для сервиса LDAP имеется стандартный порт 389 (TCP/UDP, см. описание «хорошо известных» (well-known) портов в локальном файле /etc/services).

Основной единицей информации, хранимой в каталоге, является отдельная запись (entry). Каждая запись представляет какой-либо реальный объект: человека, компьютер, организацию и т.д. Запись описывает объект через набор присущих ему атрибутов. Атрибуты представляют собой пары вида «имя — значение». Фактическое значение атрибута зависит от его типа (рис. 6).

LDAP: записи и атрибуты

Рис. 6. Записи и атрибуты LDAP

Записи хранятся в иерархической структуре, называемой «Информационное дерево каталога» (Directory Information Tree, DIT). Обращение к записям осуществляется по их уникальным именам (DN, distinguished name). DN включает полный путь к записи от корня DIT и этим напоминает путь к файлу в файловой системе. Помимо DN используется и относительное уникальное имя (RDN, relative distinguished name).

Если сравнивать DN и RDN с именами файлов, то DN можно представить так:

/home/user/documents/somefile.txt

а, соответственно, RDN так:

somefile.txt

По сути же, DN есть цепочка из RDN'ов элементов структуры разного уровня.

В LDAP используется унифицированная схема именования и набор обязательных и опциональных атрибутов предопределенных типов, которые имеют короткие алиасы. Некоторые типы атрибутов записей приведены в табл. 1. Простой пример DIT с несколькими записями приведен на рис. 7.

Таблица 1. Атрибуты записей LDAP

Тип атрибутаКраткая запись (алиас)Пояснение
CommonNamecnОбщее имя
StateOrProvinceNamestГеографическое название региона
OrganizationNameoНазвание организации
OrganizationalUnitNameouНазвание структурного подразделения
CountryNamecСтрана
StreetAddressstreetУлица (как часть адреса)
domainComponentdcЭлемент домена
useriduidУникальный идентификатор пользователя
LDAP: Пример DIT

Рис. 7. Пример (и не более того!) информационного дерева каталога (DIT) в LDAP

LDAP изначально ориентирован на использование в сильно распределенной среде, поэтому каталог или его части могут быть размещены на различных серверах. Клиент может обращаться к любому из серверов LDAP. Доступ к ним может осуществляться по реферальному (рис. 8) или цепочечному (рис. 9) принципам.

Рис. 8. Реферальный опрос LDAP-серверов. Рис. 9. Опрос «по цепочке»

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

Репликация каталога LDAP может выполняться по следующим сценариям:

Наиболее известной (но не единственной) открытой реализацией протокола LDAP является проект Open LDAP.

Начиная с версии Windows 2000 Server Microsoft стала использовать собственную, LDAP-совместимую службу каталогов Active Directory. Об особенностях этой системы централизованного управления вы можете почитать здесь и здесь.

CC-BY-CA Анатольев А.Г., 31.01.2012