Серверы LDAP выстраиваются по росту

Прежде чем выкладывать кругленькую сумму за сервер каталогов на базе протокола Lightweight Directory Access Protocol (LDAP), постарайтесь определиться, что вы планируете с ним делать в дальнейшем.

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

Единство в разнообразии

Затевая настоящее тестирование, мы решили проанализировать широкий спектр решений, объединяемых общим названием «серверы каталогов LDAP». Сюда вошли и простейшие (правда, весьма производительные) серверы, пригодные для организации крупных Internet-узлов, и серверы каталогов для корпоративных сетей с интегрированными средствами поддержки LDAP, и серверы X.500 с клиентскими приложениями LDAP, и, наконец, реляционные СУБД, поверх которых функционируют средства LDAP.

Наши приглашения предоставить свои разработки для испытаний получили более 30 компаний. Основные требования заключались в простоте администрирования, соответствии стандартам и высокой производительности серверов каталогов. В целом нас интересовало, насколько успешно они взаимодействуют с LDAP-клиентами (т.е. с пользователями и приложениями, поддерживающими данный протокол) с точки зрения доступа к данным. Кроме того, мы исследовали характеристики инструментальных средств доступа, поставляемых с каждым продуктом. Их традиционное назначение — изменение формата данных перед их записью в БД, а также генерация запросов для просмотра содержимого каталога. В инструментарий могут входить и дополнительные модули вроде редактора схем каталогов, который заметно облегчает работу администратора, но сам по себе не является составной частью сервера LDAP.

С целью предоставить участникам тестирования равные стартовые условия мы попросили производителей направить версии своих разработок под Windows NT. В результате в нашем распоряжении оказалось семь продуктов (табл. 1). Системы Directory Server компании iPlanet и IDDS фирмы Innosoft являются обычными серверами LDAP. NDS eDirectory Server for NT производства Novell относится к серверам каталогов общего назначения. Серверы, основанные на стандарте X.500, были представлены пакетами Global Directory Server компании Critical Path (бывшая Isocor), eTrust Directory фирмы Computer Associates и DirX корпорации Siemens, а Oracle Internet Directory (OIF) оказался единственным продуктом, выросшим из технологии баз данных. К сожалению, сжатые сроки испытаний не позволили нам завершить тестирование указанной разработки Oracle, поэтому сведения приведенные в табл. 2, неполны.

Помимо перечисленных продуктов мы исследовали работу службы Active Directory от Microsoft, функционирующей на платформе Windows 2000, и альтернативный вариант — систему OpenLDAP для операционной среды Red Hat Linux, коды которой открыты для всех желающих. Однако полученные нами результаты не фигурируют в итоговых таблицах, поскольку они зависели от параметров конфигурации, которые задаются в отличных от Windows NT операционных системах.

На грани объективности

Эталонные тесты проводились для изучения скорости выполнения различных функций LDAP. Набор генерировавшихся запросов включал в себя сообщения, запросы по адресам и запросы на обновление базы данных. Тесты с обработкой сообщений были призваны воспроизвести нагрузку на службу каталога, создаваемую шлюзом электронной почты или приложением электронной коммерции, причем содержание запроса совпадало со значениями полей в каталожных записях. Адресные запросы позволяли смоделировать такие приложения, как каталоги справочной информации (типа «желтых страниц»). В этом случае выдаваемые запросы требуют поиска по нескольким полям и иногда могут содержать символы обобщения. Модификационные тесты включали в себя обновление отдельных элементов каталогов в онлайновом режиме (в противоположность операциям загрузки в оперативную память больших объемов информации).

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

Многоликая производительность

«Голубую ленту» лидера мы присудили Directory Server компании iPlanet, поскольку он продемонстрировал самое высокое быстродействие и содержит эффективнейшие средства управления. Этот сервер вышел победителем в шести из восьми тестов на производительность (в двух случаях он уступил пальму первенства пакету IDDS производства Innosoft).

В испытаниях, которые мы условно назвали «обработкой сообщений», производительность характеризует скорость извлечения записей каталога при точном соответствии запроса содержимому проиндексированных полей. Продукты компаний, издавна специализирующихся на выпуске средств обработки сообщений, а к ним относятся iPlanet, Innosoft и Critical Path, продемонстрировали наилучшие результаты в тестах этой группы. NDS eDirectory Server for NT от Novell также оказался на высоте, возможно, потому, что профиль типичных операций с каталогами операционной системы довольно точно соответствовал характеру наших тестов на обработку сообщений: было много запросов и несколько раз использовались символы обобщения.

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

После того как мы запустили тесты на операции с адресами, картина несколько изменилась. Directory Server фирмы iPlanet опять был быстрее всех, однако отрыв от конкурентов оказался уже не столь внушительным. Когда между запросом и полями записей каталога нет точного соответствия, измерение производительности становится непростым делом. Чтобы гарантировать действительно высокое быстродействие сервера каталогов при работе с конкретным приложением, вы должны учесть характер выдаваемых запросов и позаботиться об адекватности используемых показателей производительности тем величинам, которыми обычно оперируете вы.

Каталоги, в которые приходится часто вносить изменения, также требуют к себе особого подхода. В то время как Directory Server, IDDS и Global Directory Server продемонстрировали способность обрабатывать около 100 изменений в секунду, остальные продукты даже близко не подошли к этой отметке. Комментируя данный факт, представители Novell сообщили нам, что компания никогда не стремилась оптимизировать свой продукт для выполнения операций загрузки каталогов большого объема в среде Windows NT. И действительно, такие операции оказываются крепким орешком для многих серверов каталогов, существенно замедляя их работу. Если служба каталогов, используемая в вашей организации, базируется на комбинации других серверных БД или хранилищ данных, не исключено, что выгружать и снова загружать каталоги в память придется чуть ли не каждый день.

В выполнении подобных процедур наилучшие результаты показали все те же системы IDDS и Directory Server. А вот NDS eDirectory компании Novell и службы каталогов, построенные на базе протокола X.500 и поэтому загружающие данные через протокол LDAP, наоборот, работали из рук вон плохо. Скажем, система от Novell функционировала со скоростью 0,8 записи в секунду, так что на выполнение всего теста ей требовалось ни много ни мало 35 ч. Символичный результат, особенно если учесть, что победитель в данном испытании — сервер IDDS компании Innosoft — справился сзаданием всего за 4 мин.

Реальное быстродействие серверов производства Innosoft и iPlanet может оказаться даже выше тех значений, которые были получены в лабораторных условиях. На практике, загружая один каталог, сервер LDAP способен работать с другим, переключение же с одного каталога на другой осуществляется практически мгновенно.

Администраторам, более всего желающим получить удачную реализацию функций протокола LDAP, стоит выбрать ПО Directory Server фирмы iPlanet, хотя его преимущество перед IDDS в данной области не столь значительно.

Если в перечисленных номинациях выбор достаточно очевиден, то не столь ясно, может ли служба каталогов общего назначения (типичным экземпляром которой является NDS eDirectory) выступать по отношению к приложениям в роли сервера LDAP или она пригодна исключительно для выполнения базовых функций с каталогами ОС? Пример с продуктом Novell не совсем удачен, по крайней мере если идет речь о среде Windows NT. Службу каталогов, которая зависает при значительной нагрузке, вряд ли нужно рекомендовать к использованию. При тестировании в условиях небольшой нагрузки (интенсивный поток запросов, но только от одного клиента) эта система функционировала вполне сносно, однако когда мы увеличили нагрузку и запросы к каталогу начали поступать от десяти клиентских станций, NDS eDirectory перестала работать. Глобальная служба каталогов NDS присуствует на рынке в течение многих лет и, возможно, именно поэтому чувствует себя гораздо уверенней в родной операционной среде. Мы же выбрали для тестирования единую операционную систему Windows NT, стремясь достичь корректности в сопоставлении разных серверов LDAP, и Novell охотно предоставила нам свою разработку.

С каталогами на базе X.500 картина оказалась довольно противоречивой. Системы этой категории, за исключением сервера Global Directory Server, продемонстрировали весьма посредственную производительность. Но даже остановив свой взор на продукте компании Critical Path, вы должны принять во внимание, каким приложениям LDAP предстоит взаимодействовать со службой каталогов. Мы рекомендуем применять продукты X.500 совместно с серверами LDAP только в том случае, если вам жизненно необходимы серверные функции службы каталогов X.500. Выбор конкретного продукта зависит от требований, предъявляемых к функциям X.500, и от необходимой вам степени интеграции со средствами LDAP.

Интерфейсы управления

Оценив скорость реакции сервера LDAP на запросы разных типов, вы сумеете разглядеть только одну сторону медали под названием «Реализация серверов каталогов на основе LDAP». Другая ее сторона связана с функциями управления и серверными услугами, которые обеспечивают масштабирование продуктов в распределенной сетевой среде.

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

Как показали испытания, «чистые» LDAP-продукты, предлагаемые, например, компаниями iPlanet и Innosoft, наиболее просты в управлении, что в значительной мере объясняется ограниченностью их функциональных возможностей. После инсталляции администратор не должен беспокоиться ни о чем, кроме функционирования сервисов LDAP.

Программное обеспечение Directory Server фирмы iPlanet и пакет IDDS производства Innosoft поставляются с редуцированными Web-серверами, значительно упрощающими большинство процедур настройки конфигурации. (Конечно, неисправимые приверженцы старого стиля администрирования могут заняться редактированием конфигурационных файлов вручную и выдавать инструкции в командной строке.)

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

Если обратиться к серверам, которые основаны на стандарте X.500 и содержат более сложные в управлении компоненты, то лидером окажется DirX корпорации Siemens, с большим отрывом обогнавший и ПО Global Directory Server фирмы Critical Path, и пакет eTrust Directory компании Computer Associates.

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

Управление сервером eTrust Directory преимущественно ориентировано на использование командного интерфейса в сеансе telnet, запускаемом с локальной консоли. На наш взгляд, такой подход оправдан лишь в том случае, когда потребность в ежедневной настройке или модификации сервера сведена к минимуму.

В службе каталогов Global Directory Server управляющие процедуры интуитивны только на уровне стандарта X.500, качество же интеграции функций LDAP и X.500 оставляет желать лучшего. Кроме того, мы обнаружили опечатки в той схеме каталогов, которую вместе с продуктом предлагает сам разработчик. За время тестирования мы просто не успели должным образом исправить их. Было проще внести изменения в наши собственные данные, чем разбираться в деталях того, как выполнена интеграция функций X.500 и LDAP программистами из Critical Path.

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

Необходимость работать с несколькими управляющими интерфейсами (а для настройки конфигурации и администрирования LDAP-сервера вам придется использовать как минимум четыре интерфейса!) в NDS eDirectory не может не раздражать. Продукт Novell настолько сильно привязан к архитектуре операционной системы и средствам управления ресурсами корпоративной сети, что избыточного многообразия пользователю не избежать. Так, каждый объект каталога NDS eDirectory фигурирует в списке прав доступа модели безопасности, а это ограничивает перечень доступных вам операций и тех объектов, на которые будет распространяться их действие. Администратор ресурсов корпоративной сети, стремящийся обеспечить поддержку глобального каталога, наверное, двумя руками поддержит комплексный подход, но при работе с NDS eDirectory в среде LDAP подобная всеядность явно не на пользу.

В целом интерфейс Console One, поддерживающий язык Java, не соответствует обещаниям компании предоставить решение с единым центром администрирования. Вместо одного интерфейса пользователь вынужден взаимодействовать с несколькими, каждый из которых вызывается по-своему, а предоставляемые ими методы просмотра и модификации управляющей информации плохо согласуются друг с другом. Нас разочаровало и то, что некоторые базовые инструментальные средства, присутствующие в версии для NetWare, не вошли в вариант для Windows NT; к ним относятся, например, функции контроля за атрибутами объектов каталога, подлежащими индексированию. В свое оправдание представители Novell заявили, что исключенные функции появятся в следующей версии программы, которая будет выпущена уже в этом году.

В приложении Oracle Internet Directory (OID) доступ к функциям управления организован более отчетливо. Поначалу мы боялись, что не имея опыта работы администратором БД Oracle «общаться» с ними окажется невозможно. Однако выяснилось, что OID очень умело скрывает от пользователя функций LDAP архитектуру БД, на которой они базируются. Правда, людям, вообще не знакомым с продуктами Oracle, все же придется не сладко. Так или иначе, но сервисы LDAP функционируют поверх СУБД Oracle 8, и после инсталляции 800 Мбайт свободное дисковое пространство «заканчивается». Помогает то, что разработанный специалистами Oracle пользовательский интерфейс достаточно интуитивен. Минимизировав излишества, эта компания создала для управления сервером и схемой каталогов лучший интерфейс среди имеющихся в протестированных продуктах.

Средства мониторинга

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

В системе eTrust Directory компании CA использован схожий подход, однако вывод статистических данных через административный Web-сервер здесь невозможен. В результате пользователю приходится довольствоваться средствами SNMP или CMIP (Common Management Information Protocol — аналог SNMP, одобренный Международной организацией по стандартизации).

Любопытно сопоставить утилиты мониторинга, имеющиеся в продуктах iPlanet и CA, с теми, что предлагаются компаниями Oracle и Novell. Как узнать, «зависло» ПО NDS eDirectory или еще работает? На сегодняшний день способ только один — взглянуть на световой индикатор обращений к жесткому диску. Представители Novell сообщили нам, что средства мониторинга производительности функций LDAP появятся только в следующей версии продукта. Oracle также не предлагает никакого специального инструментария для контроля за работоспособностью службы каталогов, а прозрачность связей между базой данных и сервером LDAP не позволяет преобразовать статистическую информацию, относящуюся к БД Oracle, в статистику LDAP.

Средства мониторинга, хотя и довольно среднего качества, присутствуют в пакетах Global Dirrectory Server фирмы Critical Path и DirX корпорации Siemens. В обоих случаях сведения о производительности помещаются в каталог X.500. Эти данные доступны для просмотра, однако связать каталоги X.500 с существующей платформой сетевого администрирования — задача не из легких.

Функции сервера

Функции LDAP этой группы не предъявляют каких-либо специальных требований к серверу каталогов. Однако «вкусы» у сетевых администраторов бывают разные. Например, в сильно распределенной корпоративной сети может возникнуть необходимость в серверах, отвечающих за тиражирование данных, в децентрализованных моделях администрирования каталоги должны поддерживать сложные схемы информационной безопасности, а в организациях, активно использующих экстрасети, не обойтись без proxy-серверов и средств защиты, реализованных вне сервера каталогов.

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

Правда, дело не сводится к одной фразе вроде «Служба X.500 имеет больше функций, чем служба LDAP». Так, сервер каталогов фирмы iPlanet способен выявлять факты «взлома» системы защиты и активизировать специальные сценарии, заставляющие сотрудников использовать более надежные пароли. А у службы каталогов компании Novell, опирающейся на архитектуру операционной системы NetWare, есть свои сильные стороны, особенно в части распространения данных по сети и организации управления многосерверными конфигурациями. Тем не менее службы каталогов на базе стандарта X.500 в функциональном отношении, как правило, оказываются богаче. Все они имеют полный набор средств тиражирования, тогда как, скажем, система Directory Server поддерживает только схему тиражирования информации с ведущего узла на ведомые.

Отдельного упоминания в этом отношении заслуживает продукт eTrust Directory, поскольку в нем реализовано тиражирование не только между разными каталогами X.500, но и между каталогами X.500 и LDAP. Это единственная система, в которой полностью ликвидирована разобщенность каталогов, построенных на двух упомянутых протоколах. В ней применен высокопроизводительный патентованный алгоритм тиражирования, который характеризуется низкой долей «накладных расходов» и использует встроенные функции тиражирования базовой СУБД OpenIngres. Аналогичным образом обстоит дело и в системе OID, которая также построена на реляционной СУБД. Фирма Novell уже давно предлагает собственный инструментарий тиражирования данных между распределенными службами каталогов.

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

Сцепления представляют собой естественное развитие схемы ссылок. С их помощью одна служба каталогов может направить запрос другой от имени клиента. Вместо того чтобы отсылать пользователя к новому источнику информации, служба каталогов выполнит за него все необходимые действия и выдаст готовый ответ. Схема сцеплений является органичной частью стандарта X.500, но не предусмотрена протоколом LDAP. Как оказалось, сцепления в каталогах, не основанных на X.500, поддерживает только система IDDS компании Innosoft.

Сцепление можно задействовать для построения proxy-сервера службы каталогов. В Innosoft разработана соответствующая программа-агент с развитыми средствами контроля доступа для каталогов LDAP; она предлагается в качестве самостоятельного продукта. Фирма Computer Associates также реализовала некоторые функции proxy-сервера и ретрансляции запросов в eTrust Directory.

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

ОБ АВТОРЕ

Процедура тестирования

Active Directory против OpenLDAP