Практическое использование LDAP
Разработчики уже давно указывают на необходимость создания стандарта каталога промышленного уровня, и эта потребность становится все более настоятельной ввиду появления многочисленных (и постоянно развивающихся) приложений, функционирующих в среде Directory Enabled Network (DEN). К ним, в частности, относятся приложения, взаимодействующие с существующими сетевыми устройствами, файлы системной конфигурации, средства организации видеоконференций и т.д.
Авторов спецификации DEN интересовала прежде всего возможность создания мощной расширяемой инфраструктуры, способной моделировать различные элементы сети и службы для обеспечения удобного хранения и извлечения информации из LDAP-каталогов и хранилищ данных.
Реализации LDAP
В таблице 2 отражены основные функциональные возможности основных серверов LDAP. Все шесть рассматриваемых серверов (кроме OpenLDAP) обеспечивают тиражирование с несколькими ведущими серверами. В ходе такой операции два первичных LDAP-сервера, предоставляющих для тиражирования изменения в своем содержимом, могут принимать обновления, синхронизировать их друг с другом и обновлять содержимое всех LDAP-серверов, на которые передаются тиражируемые данные. Последние, в свою очередь, могут направлять двум ведущим серверам запросы на обновление.
Таблица 2. Основные функциональные возможности серверов LDAP
Созданный корпорацией IBM интерфейс Standalone LDAP HTTP API (Slaphapi) позволяет выводить полученные данные в виде текста в формате HTML или DSML и обращаться к каталогам LDAP по протоколу HTTP. Кроме того, в IBM разработали инструментальное средство XML Data Mediator (прежнее названиеXML Integrator), предназначенное для двунаправленного преобразования данных (таких, как реляционные данные или данные LDAP) между XML и структурированными форматами.
Разработанный в Sun Microsystems интерфейс Java naming and directory interface API совместим с языком DSML (developer. java.sun.com/developer/earlyAccess/jndi).
Microsoft оснащает средствами DSML сервис Active Directory. Кроме того, она работает над механизмом отображения данных каталога в структуре DOM, к которой можно обращаться с помощью XPath.
LDAP Processor представляет собой процессор, выполняющий запросы LDAP, транслирующий полученные результаты в фрагмент XML-текста и вставляющий данный фрагмент в исходный документ. LDAPHTTP транслирует данные XML в формат LDAP. Шлюз XMLDAP — это созданное в соответствии со стандартами решение, позволяющее разработчикам представлять данные каталога LDAP в иных форматах.
Благодаря столь мощной поддержке стандарта потенциальные клиенты LDAP имеют широкие возможности выбора.
Выбор сервера LDAP
Требования по времени. В ходе типичных тестов сопоставляется время выполнения серверами LDAP операций считывания данных, а также их поиска, записи и загрузки. Для повышения надежности результатов база данных загружается более одного раза. Некоторые исследователи испытывали приложения с высокими требованиями к времени выполнения [8-10], другие анализировали время отклика на запрос в сочетании с совокупной полосой пропускания и задержкой [11, 12].
Связывание информации. При LDAP-взаимодействиях роль операций связывания исключительно велика. Направляя сведения для аутентификации клиента, эти операции инициируют установление соединений сервером LDAP. Метрики, относящиеся к операциям связывания (включая время отклика, число запросов на связывание и ошибок связывания), могут существенно задерживать выполнение LDAP-операции. Время отклика при связывании зависит от метода аутентификации [12].
Функциональность поиска. Этот критерий включает в себя запросы на поиск и ошибки, среднее число и размеры результатов поиска, время отклика при поиске и текущие операции поиска. Время отклика при поиске зависит от нескольких факторов, в том числе от фильтрации запросов, от места в иерархической структуре данных точки начала поиска, от числа внесенных в запрос атрибутов и того, включены ли в запрос индексированные атрибуты. Многие организации, работающие с LDAP-серверами, регулярно собирают статистические данные по операциям поиска, что позволяет им отслеживать эксплуатационные характеристики серверов. К таким организациям относятся, например, Университет Вермонта и Университет Торонто.
Управление кэш-памятью. Этот показатель важен потому, что для уменьшения времени отклика серверы каталогов используют кэши каталогов. Исследователи изучили идею использования LDAP-кэшей и предложили алгоритм снижения времени отклика [13]. Метрики управления кэш-памятью составляются путем сопоставления числа плодотворных обращений к кэш-памяти и общего числа запросов к кэшу каталога; в кэш-службах LDAP пользователи обычно определяют размер кэша.
Интенсивность обменов данными. Эта характеристика определяется числом переданных байтов и отправленных записей в ходе обменов между сервером LDAP и его клиентами. Интенсивность обменов данными зависит от разных метрик, таких как запросы на соединения, текущие соединения, средняя длина соединения и средний размер результатов поиска. Для мониторинга интенсивности обменов, особенно когда речь идет об отображении состояния в масштабе почти реального времени, администраторы LDAP-серверов могут пользоваться различными инструментами [14], например средством Mirabai-LDAP Metrics.