Сетевые каталоги и NDS

Если число пользователей и ресурсов в вашей сети постоянно растет, то без точной дорожной карты не обойтись.

ОБЪЕКТЫ NDS ПОД ЛУПОЙ
Люди, места и вещи

ПРОТОКОЛ ДОСТУПА К КАТАЛОГУ ДЛЯ МАСС
LDAP облегчает ношу

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

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

Основной игрок на рынке служб каталогов - это компания Novell с ее Novell Directory Services (NDS). В данной статье мы сравним структуру и функции NDS с другими службами каталогов. Мы оценим также сравнительные достоинства решений с применением других служб каталогов.

ЧТО ТАКОЕ СЛУЖБА КАТАЛОГОВ?

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

Во многом служба каталогов аналогична "желтым страницам". С их помощью вы можете определять местоположение нужной службы по имени в известном окружении (например городе) или производить поиск по определенным категориям (скажем по ресторанам).

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

Чтобы служба каталогов распространялась на разные архитектуры, вы должны иметь возможность обращаться к базе данных о каталогах с любой платформы. Целый ряд компаний реализовал службу каталогов в своих сетевых архитектурах, среди которых DECnet компании Digital Equipment для миникомпьютерной среды и VINES StreetTalk Directory Services компании Banyan для микрокомпьютерной среды. Но на сегодня каждая из этих служб каталогов ориентирована на определенный продукт и поддерживает только сервисы в среде конкретного поставщика.

Отсутствие интероперабельности подвигло комитеты по стандартизации выработать методы реализации и доступа к службе каталогов. Так появился на свет стандарт X.500, разработанный CCITT (теперь это ITU) и принятый ANSI.

Служба каталогов содержит многочисленные типы объектов, каждый из которых имеет набор свойств, определяющих характеристики объекта, предоставляемые сервисы, местоположение и права доступа. Одним из примеров такого объекта является пользователь сети. Профайл пользователя включает информацию об его принадлежности к группам, физическом местоположении, типе компьютера и правах доступа к коммуникационным сервисам, печати и томам, а также к любым другим сервисам, помимо тех, к которым он имеет право доступа как член той или иной группы. Отличие от прежнего сервиса bindery компании Novell в том, что эти права распространяются на всю сеть целиком, а не ограничены одним файловым сервером. (Дополнительную информацию см. во врезке "Люди, места и вещи".)

DNS И СЕТЬ

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

В службах каталогов хостов и определения адреса на базе Unix структура адресов TCP/IP предполагает, что каждый узел имеет уникальный IP-адрес. Потенциально сетевых адресов свыше 2 миллионов, а адресов отдельных узлов свыше 3,5 миллиардов. Очевидно, если пользователь обращается по своей работе к нескольким сотням хостов, то все их IP-адреса отследить довольно сложно.

В мире TCP/IP данная проблема решается посредством иерархической системы управления именами хостов с распределенной базой данных. Система имен доменов (DNS) позволяет определить по уникальному имени хоста его IP-адрес.

Серверы имен DNS хранят соответствия между всеми именами хостов и IP-адресами для данного домена (домен охватывает все нижележащие ветви для данного узла дерева DNS). Домен может делегировать полномочия серверу имен поддомена, в этом случае последний становится источником информации для своего поддомена. База данных DNS предполагает наличие многочисленных взаимосвязанных административных доменов.

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

Информация об адресуемых объектах хранится в записях о ресурсах базы данных DNS, а записями о ресурсах управляют серверы имен. Для получения IP-адреса какого-либо хоста прикладные программы посылают запрос клиенту DNS (DNS resolver). Если сервер имен не содержит информации, то запрос передается в следующий домен в иерархии. Так продолжается до тех пор, пока искомый IP-адрес не будет найден.

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

Служба каталогов должна также иметь возможность адресовать, идентифицировать и обращаться ко всем средствам и сервисам в Internet. Служба "белых страниц" Internet (Internet White Pages Service, IWPS) предоставляет средства поиска информации о пользователях и организациях в Internet. Однако она не интегрирована в другие службы каталогов. Кроме того, IWPS реализуется на добровольных началах, так что содержащиеся в ней данные часто являются устаревшими.

Один из наиболее популярных аналогов службы поиска IWPS - это whois, предоставляющая информацию о доменах, хостах, сетях и пользователях, зарегистрированных официально Internet-агентствами. В настоящее время доступ к информации IWPS осуществляется преимущественно по стандарту службы каталогов X.500.

ЭЛЕКТРОННЫЙ ROLODEX

Рекомендации X.500 и родственные стандарты предназначены для поддержки коммуникаций между сетевыми системами объектов, таких, например, как данные, приложения, оборудование, пользователи и все, что представляется важным для целей управления. (Документ, опубликованный Гаральдом Альвестрандом с обоснованием рекомендаций X.500, можно найти по адресу: wwwcs.cern.ch/wwcs/public/ftp/pub/internet/draft-ietf-ids-ds-bcp-01.txt.)

Для доступа к информационной базе каталога (Directory Information Base, DIB) пользователям предоставляется интерфейс под названием агент пользователя каталога (Directory User Agent, DUA). DUA обращается к серверному компоненту, именуемому системным агентом каталога (Directory System Agent) по протоколу доступа к каталогу (Directory Access Protocol). После чего DSA выполняет поиск в DIB (см. Рисунок 1).

DIB хранит информацию в иерархической древовидной структуре, известной как информационное дерево каталога (Directory Information Tree, DIT). DSA управляет информацией, а также копиями деревьев и поддеревьев. В реализуемой NDS службе каталогов эти копии называются разделами (логические подмножества более крупных объектов) и репликами (копии или образы разделов).

Рекомендации X.500 предусматривают также приложение для управления логической информацией, в том числе создание, удаление, модификацию классов и атрибутов (или свойств) объектов. (Логика, или схема, NDS - это правила, определяющие типы объектов NDS и их свойства.) Данное приложение управляет также правилами DIT.

X.500 имеет некоторые ограничения. Например, полное имя пользователя не является обязательной частью объекта типа пользователь. Однако многие поставщики мощных служб каталогов добавили это свойство в свои продукты - Banyan в StreetTalk, Novell в NDS и т. д.

NDS ПРИХОДИТ НА ПОМОЩЬ

Novell Directory Services состоит из базы данных с информацией о локальных и глобальных сетях, а также инструментов и утилит для управления и навигации по базе данных. Эта многомерная база данных содержит всю информацию о корпоративной сети. Разбитая на логические разделы, база данных тиражируется между несколькими серверами. Тиражирование повышает производительность и обеспечивает избыточность. Например, если файловый сервер выйдет из строя, то каталог все равно будет доступен. Кроме того, пользователи могут входить в сеть, даже если файловый сервер по тем или иным причинам недоступен.

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

Каждый раздел имеет только одну главную реплику. Среди других видов реплик - реплика для чтения/записи и реплика только для чтения.

Как следует из имени, информацию в реплике только для чтения можно просматривать, но нельзя изменять. Однако поскольку реплики для чтения/записи можно менять, объекты в разделе добавляются или удаляются с помощью реплик этого типа. После внесения изменений NDS обновляет главную реплику и все остальные реплики для приведения их в соответствие со сделанными изменениями.

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

NDS свободно согласована: она имеет различные уровни согласования на уровне объектов. Цель состоит в синхронизации разделов и реплик, но, например, при изменении одной реплики время, через которое данное изменение будет занесено во все реплики, может различаться. В течение этого временного промежутка база данных находится в несогласованном состоянии, но в процессе согласования.

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

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

NDS базируется на появившейся в 1988 году начальной версии стандарта X.500. Кроме того, NDS содержит такие усовершенствования, как контроль доступа и расширяемость. Цель NDS - обеспечить взаимодействие и обмен информацией между другими базами имен X.500 посредством передачи сертификатов от сертифицированных уполномоченных и других компонентов X.500.

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

ИМЕНА И АДРЕСА

Каталог NDS хранит данные в файлах, расположенных в томах специальных серверов. Эти файлы образуют DIB, а каждая DIB содержит данные для находящихся на соответствующих серверах реплик, а также другие типы глобальной информации.

Кроме того, DIB содержит определения "записей" для каждого допустимого типа объектов каталога. Особый набор полей, называемых свойствами объекта, уточняет определение каждого объекта. Вводимые в поля свойства значения определяют объекты NDS в DIB.

Объекты NDS делятся на две основные категории: физические объекты (например принтеры, серверы, тома и пользователи) и логические объекты (в частности группы, карты каталогов и очереди на печать). Кроме того, логическими объектами являются такие объекты, как организации и организационные единицы, помогающие упорядочить и управлять как физическими, так и логическими объектами.

Объекты NDS - это структуры, хранящие информацию, а не сама информация.

Схема именования в NDS схожа с принятой в StreetTalk компании Banyan, но она не имеет ограничения на число составных частей имени (три части в StreetTalk). В NDS компоненты имени отделены точкой (в StreetTalk они отделяются символом @).

Создавая NDS на базе X.500, Novell предугадала, что отрасль примет его в качестве стандарта, и потому NDS стала одной из первых служб каталогов, поддерживающих облегченный протокол доступа к каталогам (Lightweight Directory Access Protocol, LDAP). (Дополнительную информацию см. во врезке "LDAP облегчает ношу".)

NDS уже реализована на платформах наподобие UnixWare и HP-UX, а кое-кто из поставщиков, например IBM и Sun Microsystems, планируют реализовать ее на своих. Интерфейсы API для NDS, в том числе все API службы каталогов для клиентов и сервисов, можно получить бесплатно на узле Web компании Novell по адресу: devsup.novell.com.

Novell собирается интегрировать NDS во все основные серверные платформы. Компания уже предприняла в этом направлении определенные шаги: она предоставила бесплатные лицензии на исходный код NDS основным разработчикам операционных систем. Novell собирается также распространять односерверную двоичную версию NDS для Windows NT по Internet и на основе соглашений с независимыми разработчиками программного обеспечения и поставщиками оборудования.

О заключенных контрактах Novell намеревается объявить в ближайшие несколько месяцев.

STREETTALK КОМПАНИИ BANYAN

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

Корпоративная служба каталогов StreetTalk компании Banyan включена в ОС VINES. В своей третьей редакции StreetTalk позволяет именовать, описывать и находить пользователей и ресурсы во всей корпоративной сети предприятия. Она облегчает также организацию взаимодействия и управление сетью и ресурсами. StreetTalk позволяет находить сетевые ресурсы без проблем с помощью запросов на простом английском и разрешает использование коротких псевдонимов.

Имена StreetTalk имеют трехчастную структуру, в которой символ @ отделяет части имени. Как правило, первая часть имени StreetTalk (имя объекта) представляет собой полное имя пользователя, например Bob Harbison. Вторая часть имени (название группы) представляет группу взаимосвязанных пользователей, к примеру отдел кадров или отдел продаж. Третья часть имени StreetTalk (название организации) объединяет несколько взаимосвязанных групп пользователей, скажем администрацию, подразделение офисных систем или название компании. Таким образом, полное имя Боба Харбисона, работающего консультантом в компании Network Integration Consultants, будет выглядеть так: Bob Harbison@Consultants@NIC.

Как упоминалось ранее, StreetTalk позволяет вместо полных имен использовать короткие псевдонимы, называемые прозвищами. Прозвища упрощают и ускоряют процесс регистрации в сети. Например, вместо того чтобы вводить Bob Harbison@Consultants@NIC, я могу написать просто Bob.

Universal StreetTalk представляет собой независимую от VINES или Enterprise Network Services версию StreetTalk. Banyan предлагает ее бесплатно поставщикам для включения в их продукты.

Universal StreetTalk будет также поддерживать отраслевые стандарты, платформы, сетевые протоколы и протоколы каталогов (такие как DAP, LDAP и Directory System Protocol). Взаимодействуя с другими системами имен, в том числе NDS, Windows NT Directory Service и X.500, он будет предоствлять вход непосредственно в сеть (как это имеет место в NDS и Windows NT).

СЛУЖБА КАТАЛОГОВ MICROSOFT

Windows NT Directory Services компании Microsoft имеет по существу ту же доменную структуру, что и LAN Manager. Домены Windows NT Server образуют строительные блоки сетей на базе NT Server и базис службы каталогов операционной системы.

В Directory Services сервер конфигурируется как первичный контроллер домена (Primary Domain Controller, PDC). Этот сервер содержит информацию о бюджетах пользователей домена; все изменения в учетной информации производятся на PDC. Другие серверы домена можно сконфигурировать как резервные контроллеры домена (Backup Domain Controller, BDC) или обычные серверы.

BDC содержат копии информации о бюджетах пользователей и служат для идентификации пользователей при их регистрации в домене. BDC обеспечивают также отказоустойчивость процесса идентификации. Если PDC выключен, то BDC могут самостоятельно идентифицировать пользователя и предоставить ему доступ к сетевым ресурсам. Любому BDC можно предоставить статус PDC, чтобы он мог распространять по сети любые изменения в каталогах.

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

Тиражирование требует 2 Кбайт при установлении соединения и около 1 Кбайт в расчете на пользователя, так что требования к пропускной способности минимальны. Для задач обновления и резервирования все серверы и клиентские машины в сети сервера NT могут быть синхронизированы по одним системным часам.

Нагрузку по идентификации пользователей PDC делит с BDC. Во многих ситуациях, например в глобальных сетях, BDC ближе к точке входа пользователя, чем PDC. Способность BDC идентифицировать пользователей сокращает как время идентификации, так и сетевой трафик. Это особенно важно в крупных сетях с одним главным пользовательским доменом.

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

Domain Services позволяет создавать несколько доменов и доверительные бюджеты, с помощью которых пользователи одного домена могут получать доступ к данным в другом домене. Недостаток доверительных бюджетов в том, что другие администраторы сети добавляют к ним пользователей доверительного бюджета без вашего ведома. Главный администратор может открывать доверительные бюджеты для каждого нового домена и управлять ими индивидуально из центрального узла, но каждый домен администрируется независимо - всеобъемлющих средств администирования нет. Доверительными бюджетами управлять надо очень осторожно, а пользователи, имеющие к ним доступ, должны очень строго придерживаться мер безопасности.

Microsoft обязалась поддерживать протоколы DAP и LDAP. Так, следующая редакция Exchange Server будет поддерживать LDAP. Очередная редакция Internet Explorer так же, как и ожидаемая крупная редакция Windows NT Server под кодовым названием Cairo (ее появление ожидается в конце этого года), должна поддерживать эти протоколы.

ГЛОБАЛЬНЫЙ ЛОКАТОР

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

ОБЪЕКТЫ NDS ПОД ЛУПОЙ

Люди, места и вещи

Из-за многочисленности типов объектов в службе каталогов значение термина "объект" представляется для большинства неясным. В службе каталогов Novell (NDS) этот термин относится к ресурсам в базе данных NDS. Каталог NDS имеет иерархическую древовидную структуру; наверху дерева находится корень, от которого ответвляются все другие компоненты.

Местоположение объекта в дереве каталога называется его контекстом. Во время процесса установки администратор может задать контекст данного сервера в каталоге. Этот контекст может содержаться внутри имеющегося раздела или быть совершенно новым.

Каждый объект в NDS принадлежит к определенному классу, а каждый класс имеет специфический набор характеристик, называемых свойствами. Базовых классов объектов всего два: физические объекты (например принтеры и пользователи) и логические объекты (скажем очереди на печать и группы).

Каталог NDS содержит объекты-контейнеры и объекты-листья. Подобно ветвям иерархического дерева, объекты-контейнеры, как следует из названия, содержат другие объекты NDS, а также объекты-листья, о которых мы расскажем несколько ниже.

Разновидностей объектов-контейнеров три: страна, организация и организационная единица. Объект-страна позволяет организовать другие объекты с помощью двухбуквенных обозначений для конкретной страны. Этот объект не обязателен (иными словами, он не создается автоматически в процессе установки). Объекты-страны имеют только один уровень. Объект-организация - это объект-контейнер, имя которому дается по названию организации, использующей сеть. В отличие от объекта-страны, объект-организация обязателен. Каталог должен содержать по крайней мере один объект-организацию, но и эти объекты имеют только один уровень. Объект-организационная единица представляет такие элементы, как филиалы компании, отделения и отделы. Эти объекты могут быть многоуровневыми. Родительским объектом является объект-контейнер, содержащий другие объекты каталога.

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

ПРОТОКОЛ ДОСТУПА К КАТАЛОГУ ДЛЯ МАСС

LDAP облегчает ношу

Облегченный протокол доступа к каталогам (Lightweight Directory Access Protocol, LDAP) - это открытый стандартный протокол Internet для доступа к интерактивным службам каталогов. Он выполняется непосредственно над TCP и применяется почти всеми широко распространенными клиентами каталогов X.500.

LDAP ведет свое начало от протокола доступа к каталогам X.500 (Directory Access Protocol, DAP). LDAP (RFC 1487) был разработан в 1993 году и специфицирован в RFC 1777, 1778, 1779 и 1781.

Не так давно 40 компаний объявили о своем намерении поддерживать LDAP в качестве основного протокола доступа к службам каталогов через TCP/IP. Среди них IBM, Lotus Development, Microsoft, Netscape, Novell, Campbell Services (подразделение FTP Software и создатель OnTime) и Sunsoft.

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

С поддержкой каталогами различных поставщиков стандарта объектам будет проще взаимодействовать друг с другом. Благодаря этому поставщики смогут обеспечить охват всех внутренних сетевых ресурсов в масштабе предриятия и даже доступ к ним через Internet.

RFC 1777 определяет LDAP как протокол поиска в Internet. LDAP не поддерживает сложные средства просмотра, администрирование каталогов, управление логикой, полную идентификацию или инфраструктуру для интернационализации. Отсутствующие функции поддерживаются, однако, протоколом DAP X.500, от которого LDAP происходит. Информационный RFC о LDAP (RFC 1823) описывает функции протокола, которые Microsoft планирует встроить в свой открытый интерфейс службы каталогов (Open Directory Service Interface, ODSI). ODSI базируется на распределенной компонентной объектной модели (Distributed Component Object Model, DCOM), известной прежде как OLE. По существу ODSI - это набор API, с помощью которых разработчики могут обращаться к различным провайдерам службы каталогов.