Таблица 4. Итоги тестирования: за и против

Прежде чем выкладывать кругленькую сумму за сервер каталогов на базе протокола 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, этот факт не должен стать определяющим при выборе продукта, если только вы не испытываете острой необходимости в активном использовании конкретных серверных функций.

ОБ АВТОРЕ

Джоэл Снайдер (Joel Snyder) сотрудничает с компанией Opus One, специализирующейся на технологиях защиты данных и обработки сообщений. С ним можно связаться по адресу joel.snyder@opus1.com.


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

Для формирования среды тестирования использовалось несколько серверов и десять рабочих станций с процессорами фирмы Intel. Сервер каталогов был установлен на компьютере с двумя 650-МГц процессорами Pentium III, 380 Мбайт оперативной памяти под управлением ОС Windows NT Version 4 с Service Pack 6a. Жесткий диск производства Seagate c интерфейсом Fast/Wide SCSI подключался через контроллер фирмы Adaptec. Станции-клиенты представляли собой серверы Density компании Cubix с 366-МГц процессорами Celeron. Передача данных между компьютерами осуществлялась по коммутируемым дуплексным соединениям со скоростью 100 Мбит/с. В состав сети входило управляющее устройство Autoboot Commander 4XP фирмы Cybex, позволяющее подключать десятки персональных компьютеров к одному монитору. Не располагая столь удобным средством, мы не смогли бы в полной мере контролировать все процессы, происходящие в сети.

Тестовый набор данных состоял из 100 тыс. «персональных» записей, сгенерированных с использованием схемы InetOrgPerson. Отдельная запись содержала 23 атрибута, суммарный объем данных равнялся 75 Мбайт. По нашим прикидкам, каждая из служб каталогов может целиком разместить информацию такого объема в оперативной памяти.

Для анализа производительности при обработке запросов к каталогу большого размера применялись несколько эталонных тестов, заимствованных из пакета Directorymark 1.1 компании Mindcraft, а также инструментальные средства от Innosoft и Netscape. Последние позволили удостовериться в том, что тесты Mindcraft не дают фору какому-нибудь продукту. Поскольку в структуре тестов Directorymark 1.1 имеется ряд неопределенностей, мы решили поместить в табл. 3 исходные значения производительности продуктов при выполнении операций разных типов, а не публиковать данные, усредненные по всем тестам.

Перед началом собственно тестирования каждому продукту было дано 10 мин на «разминку». В течение этого времени содержимое базы данных загружалось в кэш-память. Такая загрузка давала существенное преимущество поддерживающим ее серверам — мы заметили резкий рост производительности после нескольких минут «разминки».

В трех тестах использовались профили запросов, рекомендованные фирмой Mindcraft для набора Directorymark 1.1. Они были связаны с обработкой сообщений, поиском адресов, а также с модификацией элементов каталога.

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

Тест с адресами в принципе был аналогичен предыдущему, только число типов запросов заметно увеличилось. На сей раз процедура связывания LDAP осуществлялась после каждых пяти операций поиска и системе предстояло обнаружить точное соответствие содержимому запроса в четырех различных полях записей, произвести поиск при наличии символов обобщения и при необходимости выдать результат «Запрашиваемый объект не обнаружен» (точное описание теста можно найти на Web-сервере компании Mindcraft). Как и в предыдущем случае, тест выполнялся сначала с одной клиентской станцией, а затем с десятью одновременно.

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

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

Наконец, мы воспользовались инструментарием компаний Innosoft и iPlanet для обработки запросов к каталогам, которые допускали точное соответствие содержимого запроса значениям индексируемых полей. Теоретически, при выполнении тестов фирмы Mindcraft, связанных с обработкой сообщений, результаты использованных в тестировании двух конфигураций должны совпадать; на практике же они различались на несколько процентов. Вот почему применение нескольких средств тестирования является жизненно необходимым: тогда можно гарантировать, что ни один из тестов не содержит ошибок, приводящих к некорректным результатам.


Active Directory против OpenLDAP

В дополнение к испытаниям семи серверов LDAP в среде Windows NT мы проанализировали поддержку этого протокола в службе каталогов Active Directory компании Microsoft и в продукте OpenLDAP с открытыми исходными кодами. Ни Active Directory, ни Open-LDAP не стали участниками основного тестирования, поскольку эти системы не поддерживают ОС Windows NT. Active Directory функционирует под управлением только Windows 2000, а OpenLDAP — в среде Linux.

Мы обнаружили, что, несмотря на проблемы с производительностью при загрузке больших объемов данных и избыточность модулей управления, Active Directory неплохо справляется с обработкой запросов LDAP и содержит превосходный набор средств мониторинга, позволяющий эффективно контролировать работу сервера. Что же касается альтернативной разработки OpenLDAP, мы были сильно разочарованы ее производительностью и практически полным отсутствием средств администрирования. В этой связи ее лучше рассматривать как учебный продукт, который помогает познакомиться с основными фукнциями LDAP, но не предназначен для эксплуатации в реальной корпоративной сети.

Может ли Active Directory выступать в роли самостоятельной службы каталогов на базе протокола LDAP? Лишь отчасти. Эта система загружает в память большие объемы данных поистине с черепашьей скоростью — на уровне 33 записей в секунду (см. таблицу). К тому же в Active Directory не предусмотрено добавление некоторых атрибутов к записям каталога посредством выполнения единой операции; вместо этого система заставляет вас проверять корректность каждой записи по отдельности. Нам пришлось изменить схему каталога — без этого шага данные просто не удалось бы загрузить.

В то же время продукт довольно шустро обрабатывает запросы и редактирует записи каталога. Выполняя большинство операций LDAP, он может на равных конкурировать даже с самыми быстрыми автономными серверами из тех, что принимали участие в тестировании. Это означает, что для обеспечения разделяемого доступа по протоколу LDAP к каталогам Windows (из корпоративной сети и извне) естественного интерфейса к Active Directory вполне достаточно и вам не придется, например, специально экспортировать данные из Active Directory в другой каталог LDAP. Однако крайне низкая производительность при реализации операций загрузки значительных массивов данных не позволяет рекомендовать Active Directory в качестве «самодостаточного» сервера каталогов LDAP.

Заметим также, что созданные Microsoft средства управления каталогами LDAP не отличаются цельностью. Вместо того чтобы избрать единый подход к такому управлению и последовательно реализовать его в своем продукте, фирма попыталась внедрить сразу несколько концепций администрирования. Операционная система Windows 2000 поставляется с множеством инструментальных средств, которые частенько, пусть и по-разному, решают одну и ту же задачу. Из этого пестрого набора безусловно полезным нам показалось приложение, которое способно взаимодействовать с каталогами LDAP, непосредственно используя протокол LDAP, и потому — выдавать запросы к серверам разных поставщиков.

Что касается мониторинга, компания Microsoft, кажется, решила одновременно двигаться в двух противоположных направлениях. С одной стороны, показатели производительности службы каталогов можно увидеть непосредственно, запустив утилиту perfmon среды Windows 2000, которая предлагает чрезвычайно удобное графическое представление процессов загрузки содержимого каталога и обработки связанных с ним транзакций. С другой, те же статистические данные доступны через новый интерфейс в стандарте Web-Based Enterprise Management (WBEM), который сам по себе имеет мало проку. Правда, для среды Windows 2000 фирма предлагает преобразователи форматов, переводящие данные WBEM в форму SNMP, так что статистические сведения, относящиеся к Active Directory, удастся просмотреть с помощью любого средства сетевого мониторинга, поддерживающего управляющий протокол SNMP.

В системе OpenLDAP, которую также можно воспринимать в качестве автономного сервера LDAP, отсутствует графический интерфейс пользователя, поэтому для внесения изменений в каталоги нам пришлось вручную редактировать конфигурационные файлы и выдавать инструкции в командной строке. Кроме того, производительность данного продукта оказалась крайне низкой в большинстве тестов — почти каждый раз OpenLDAP уступал всем остальным продуктам. Счастливым исключением стала обработка многопользовательских запросов, содержавших символы обобщения: здесь OpenLDAP был среди лидеров. Простота данного сервера и легкость установки делают его хорошим инструментарием-прототипом для проектирования полномасштабной службы каталогов. Этот вывод будет вдвойне верным, если впоследствии вы решите использовать Directory Server фирмы iPlanet или IDDS компании Innosoft, поскольку конфигурации и основные процедуры трех указанных продуктов очень похожи.

Производительность Active Directory и OpenLDAP
ТестОpen LDAP под LinuxActive Directory под windows 2000
Время загрузки, записей/с23,533,3
Сообщения, операций/с:
с 1 клиентом4,6915
с 10 клиентами47,71536
Поиск адресов, операций/с:
с 1 клиентом5,92,6
с 10 клиентами48,611,6
Скорость поиска, операций/с:
с 1 клиентом4,5999
с 10 клиентами18,22199
Изменение каталога, операций/с9,321,7

Поделитесь материалом с коллегами и друзьями