Среди факторов, превративших каталоги в один из ключевых компонентов современных сетей, не последнюю роль сыграл Lightweight Directory Access Protocol (LDAP). Главное достоинство этого протокола — простота. После его появления на свет серверы каталогов, некогда представлявшие собой сложные приложения и воспринимавшиеся пользователями как настоящий кошмар, упростились до такой степени, что их развертывание и сопровождение не требует особых усилий.
Правда, выбрать своего фаворита в мире серверов каталогов LDAP по-прежнему непросто. На рынке присутствует множество продуктов, сильно различающихся по техническим характеристикам и функциональным возможностям. Поэтому прежде чем браться за серьезный проект, включающий в себя организацию сетевых каталогов, стоит уяснить, что же скрывается за аббревиатурой LDAP, как новые каталоги будут сосуществовать с имеющимися базами данных, каковы производительность и «аппетиты» приложений, которым предстоит работать с каталогами.
Истоки
LDAP является прямым потомком X.500 — серии рекомендаций, регламентирующих организацию служб каталогов и выпущенных Международным союзом электросвязи. Эти довольно старые спецификации разрабатывались телефонными компаниями в целях построения гигантских сетей, имеющих сложную топологию и связывающих между собой серверы каталогов по всему миру. Вселенские масштабы данного проекта (а на меньшее авторы X.500 не соглашались) не могли не отразиться на характере самих рекомендаций: в печатном виде они занимают не одну сотню страниц и крайне сложны в изучении. Неудивительно, что в один прекрасный день группа разработчиков Internet-технологий задалась вопросом: «Можно ли настолько упростить стандарт X.500, чтобы его начали использовать простые смертные?». Так было положено начало процессу создания протокола LDAP.
LDAP и X.500 тесно связаны друг с другом. По сути дела, LDAP разрабатывался в качестве удобного метода доступа к каталогам X.500. Он не требует, чтобы сам сетевой каталог был построен на базе X.500, однако для его описания использует определения и метафоры, впервые введенные в обиход этим стандартом. Подобное заимствование проявляется в полной мере, когда речь заходит о схеме, которая задает структуру объектов, хранящихся в базе данных каталога. При первом знакомстве со схемой LDAP/X.500 она может ошеломить своими размерами, но, к счастью, ее редактирование во многих серверах LDAP осуществляется на удивление просто. Например, в системе Oracle Internet Directory (OID) для добавления к объекту нового поля достаточно указать имя, тип и длину последнего, привязать его к этому объекту, а затем при помощи мыши и экранных кнопок определить способ индексирования.
Термин «lightweight» («облегченный») в названии LDAP отражает основную цель разработки протокола: создать инструментарий для построения службы каталогов, которая обладает достаточной функциональной мощью для решения базовых задач, но не перегружена сложными технологиями, отбивающими всякую охоту с ней работать. В настоящее время LDAP является стандартным методом доступа к информации сетевых каталогов и играет роль фундамента во множестве продуктов, таких как системы аутентификации, почтовые программы и приложения электронной коммерции. Сегодня на рынке присутствует более 60 коммерческих серверов LDAP, причем около 90% из них представляют собой самостоятельные серверы каталогов LDAP, а остальные предлагаются в качестве компонентов других приложений.
Заглавные буквы DAP в аббревиатуре LDAP также имеют особый смысл. Они напоминают об ограничениях, накладываемых стандартом на деятельность разработчиков ПО. В системах на базе X.500 протокол DAP используется для выдачи запросов к каталогам. Другими словами, LDAP — это всего лишь упрощенная версия протокола DAP, являющегося частью сложного мира глобальных служб каталогов. В компетенцию LDAP входят способы взаимодействия разнообразных приложений (от незамысловатых браузеров до сложных систем управления предприятием) с сетевыми каталогами. Что же касается построения, администрирования и эксплуатации служб каталогов, то реализация соответствующих функций оставлена на усмотрение разработчиков.
Каталог или база данных?
Одна из особенностей каталогов LDAP, которая нередко приводит в замешательство пользователей, заключается в их сходстве с обычными базами данных. Если вам доводилось составлять запросы на языке SQL или работать с реляционными БД, вы наверняка воспримете LDAP как способ организации простейшей базы данных.
Подобная точка зрения имеет право на существование. Действительно, протокол LDAP можно использовать для выдачи запросов к стандартным БД, что и продемонстрировали компании Oracle и Computer Associates, надстроив службы каталогов LDAP над реляционными СУБД собственного производства. Однако поставщики автономных серверов LDAP, в том числе фирмы Netscape и Innosoft, не в восторге от подобных сравнений. Во-первых, они не желают конкурировать с законодателями мод в области баз данных, ведь продавать собственные приложения БД, состязаясь с Oracle, — все равно что продвигать операционные системы для ПК, не имеющие ничего общего с продуктами Microsoft. Во-вторых, эти поставщики стремятся лишний раз подчеркнуть отличия серверов каталогов от традиционных СУБД.
Протокол LDAP четко определяет круг операций над каталогами, которые может выполнять клиентское приложение. Эти операции распадаются на пять групп: установление связи с каталогом, поиск в нем информации, модификация его содержимого, добавление и удаление объекта. Все остальные возможности, предоставляемые реляционными СУБД (а к ним относятся обработка транзакций, выдача запросов к нескольким таблицам, генерация представлений и операции слияния), в сфере каталогов LDAP аналогов не имеют. Сервер LDAP не содержит подобных функций, точнее — они не реализуются через интерфейс LDAP.
Может показаться, что здесь обнаруживается существенный недостаток серверов каталогов, но в действительности это их огромное преимущество. Хранение служебных сведений в каталоге LDAP позволяет резко повысить производительность операций с данными, снизить начальные затраты и эксплуатационные расходы, использовать упрощенные модели данных и заметно облегчить труд администратора.
Как было отмечено выше, LDAP задает метод доступа к базе данных, а кроме того, он определяет философию ее построения. Строго говоря, такой субстанции, как каталог LDAP, в действительности не существует. Однако появление этого протокола сделало структуру БД настолько рельефной, что подавляющее большинство пользователей называют каталог, для доступа к которому используется LDAP, просто каталогом LDAP.
Заметим также: построить каталог, специально оптимизированный для работы с рассматриваемым протоколом, гораздо легче, чем базу данных общего назначения. Например, в спецификациях LDAP отсутствуют упоминания о транзакциях и откатах, а это означает, что в среде LDAP исчезают трудности, связанные с блокированием записей или журналированием в реляционных БД.
Из сказанного следует, что если и найдется традиционная база данных, допускающая простое преобразование в каталог LDAP, то ей окажется не современная реляционная, а иерархическая БД (вроде Information Management System компании IBM). Это связано с тем, что в каталоге LDAP для хранения информации используются иерархические деревья, позволяющие скрыть взаимосвязи между описываемыми организационными структурами — начиная от местонахождения и названий административных подразделений и кончая фамилиями отдельных сотрудников, номерами комнат для переговоров и марками сетевых принтеров.
Размытые границы
Возможное число записей, помещаемых в каталог, и скорость доступа к нему определяют сегментацию современного рынка служб каталогов LDAP.
Создавая узел для настраиваемого Web-портала, который должен обслуживать в общей сложности 10 млн зарегистрированных пользователей и обрабатывать 1 млн обращений в день, вы, скорее всего, приобретете сервер LDAP, ориентированный на применение в экстрасетях или в сфере электронной коммерции. Такие продукты поддерживают ограниченное число типов запросов (например, запросы, содержащие точные регистрационные имена пользователей), способны обрабатывать гигантское количество запросов на чтение Web-страниц и вести огромную базу данных, чье содержимое мало подвержено изменениям.
Работая администратором электронной почты в компании из списка Fortune 500, вы, возможно, столкнетесь с тем, что на обращения к LDAP-каталогу экстрасети приходятся только 10% всех запросов, зато они допускают как точное, так и неточное соответствие содержимому проиндексированных полей, а кроме того, в них присутствуют символы обобщения. Количество записей в базе данных на сей раз будет не столь большим: для каталога LDAP корпоративной сети вполне разумно выглядит оценка в 50 тыс. записей. При такой сетевой модели нужен сервер LDAP, обладающий совершенно иными свойствами, чем продукт для Web-портала.
Впрочем, различие между указанными категориями отчасти условно. Казалось бы, разработки компаний Microsoft и Novell наилучшим образом соответствуют корпоративной модели, однако эти фирмы решительно возражают против подобного позиционирования. Они заявляют о поддержке каталогов с несколькими миллионами записей (Novell даже называет цифру в 1 млрд записей) и претендуют на лидирующие места в соревновании с конкурентами.
Практика показывает, что сегодня на рынке не существует службы каталогов, допускающей оптимизацию под любые приложения. Продукт корпорации iPlanet, стремящейся превратиться в ведущего поставщика служб каталогов для экстрасетей и приложений электронной коммерции (т.е. стать Netscape номер два), способен загрузить в память каталог объемом 1 млн записей менее чем за час. Подобная операция является обычной для каталогов LDAP, поскольку часто оказывается, что проще повторно загрузить в память их содержимое, чем вносить изменения, накопившиеся в течение дня. Что бы там ни говорили руководители компании Microsoft, ее система Active Directory вообще не рассчитана на такие задачи: базу данных указанного объема она сумеет загрузить в лучшем случае за 12 часов.
Службы каталогов, ориентированные на применение в корпоративных сетях, как правило, предлагают больший набор сервисов, чем их экстранет-собратья, и включают в себя несколько приложений для размещения в каталоге данных разных типов и их последующего извлечения. К тому же обычно они тесно интегрированы с ПО сетевого и системного администрирования. Novell и Microsoft предусматривают хранение данных о конфигурации и информационной безопасности в общем сетевом каталоге, что позволяет операционной системе выступать по отношению к нему в качестве крупного клиента.
Бремя выбора
Выбор конкретного продукта порой напрямую зависит от используемых приложений. ОС Windows 2000, в состав которой входит Active Directory, с трудом взаимодействует со службами каталогов других производителей. Компания Novell предприняла самоотверженный шаг, реализовав технологию Active Directory в своем продукте Novell Directory Services (NDS) eDirectory, который также функционирует под управлением Windows 2000. Однако эти игры на поле Microsoft чреваты тем, что степень несовместимости с другими приложениями может оказаться очень высокой.
Схожим образом обстоит дело и в области приложений, поддерживающих работу с каталогами. Многие прикладные программы, например серверы аутентификации пользователей и шлюзы электронной почты, используют LDAP, однако оптимизированы под конкретный API-интерфейс. В процессе тестирования мы воочию убедились в том, что поддержка стандартных вызовов LDAP в разных продуктах реализована совершенно по-разному. Не располагая исходным кодом установленного в сети приложения, вы не сумеете осуществить его тонкую настройку, а значит, при работе с сетевыми каталогами не достигнете желаемых результатов.
В любом проекте, предусматривающем поддержку каталогов, выбору конкретного продукта должна предшествовать стадия детального проектирования. Сегодня на книжном рынке имеется несколько хороших изданий, посвященных LDAP. Впрочем, мы обнаружили, что прекрасным введением в разработку и внедрение самых разных типов приложений, основанных на протоколе LDAP, может служить документация фирмы Netscape к предлагаемому ею серверу LDAP. Даже если вы не собираетесь использовать продукт Netscape, эту документацию стоит приобрести отдельно в самом начале процесса проектирования приложений для работы с каталогами.
После того как основные свойства будущего каталога LDAP определены (а сюда относятся профиль приложений, число записей, производительность, типы запросов и методы распространения информации по сети), вам не составит особого труда сократить до минимума список потенциальных кандидатов, а затем выбрать тот продукт, который отвечает вашим запросам в наибольшей степени.