A. Изменения по сравнению с предыдущей версией

В следующих подразделах предпринята попытка обобщить новые возможности и изменения в программном обеспечении OpenLDAP по сравнению с версией 2.3.x и в Руководстве администратора OpenLDAP.


A.1. Новые разделы руководства

Чтобы Руководство администратора стало более глубоким и охватывало большинство вопросов, задаваемых в списках рассылки OpenLDAP и обсуждаемых там способов их решения, мы добавили следующие разделы:

Кроме того, для облегчения навигации в содержании теперь представлены разделы 3-го уровня вложенности.


A.2. Новые функции и возможности в версии 2.4

A.2.1. Лучшая функциональность cn=config

Появилась новая man-страница slapd-config(5) для механизма манипуляции данными cn=config. В версии 2.3 была декларирована, но не реализована оригинальная конструкция, позволяющая, при добавлении или удалении конфигурационных записей с именами, которые могут быть упорядочены, автоматически переименовывать такие записи. Теперь эта возможность доступна в 2.4. Это означает, что если у Вас, к примеру, есть база данных

   olcDatabase={1}mdb,cn=config
   olcSuffix: dc=example,dc=com

и Вы хотите добавить новую подчинённую базу данных, теперь Вы можете добавить такую запись с помощью ldapadd:

   olcDatabase={1}mdb,cn=config
   olcSuffix: dc=foo,dc=example,dc=com

Новая база данных back-mdb будет добавлена в слот 1, а все последующие базы данных будут смещены на единицу; таким образом, оригинальная база данных back-mdb теперь будет называться:

   olcDatabase={2}mdb,cn=config
   olcSuffix: dc=example,dc=com

A.2.2. Лучшая функциональность cn=schema

В версии 2.3 Вы могли лишь добавлять новые элементы схемы, а удалять или изменять существующие элементы - нет. В 2.4 Вы можете изменять схему по своему желанию (конечно, за исключением жёстко закодированной системной схемы).

A.2.3. Более тонкая настройка Syncrepl

Оригинальная реализация Syncrepl в OpenLDAP 2.2 была предназначена для поддержки нескольких потребителей для одной базы данных, но эта возможность никогда не работала и была исключена в OpenLDAP 2.3; в этой версии Вы могли настроить только одного потребителя для каждой базы данных.

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

A.2.4. Разнонаправленная репликация с несколькими поставщиками

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

В используемых для репликации значениях entryCSN метки времени теперь сохраняются с точностью до микросекунд, а не просто в секундах.

A.2.5. Репликация конфигурации slapd (syncrepl и cn=config)

Syncrepl над cn=config был явно отключен в 2.3. В 2.4 он полностью поддерживается; Вы можете использовать syncrepl для репликации всей конфигурации сервера с одного сервера на сколь угодно большое количество других серверов. Можно клонировать всю конфигурацию работающего slapd, используя небольшое количество настроек (менее 10 строк), можно реплицировать только поддерево схемы данных, можно придумать и другие варианты. В тестах 049 и 050 из набора тестов есть рабочие примеры этих возможностей.

A.2.6. Репликация в режиме посылок

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

В версии 2.4 Вы можете определить базу данных как "hidden", это означает, что при проверке конфликта имён её суффикс будет проигнорирован, и что база данных не будет использоваться для ответов на поступающие извне запросы. Использование данной возможности скрытых ("hidden") баз данных позволяет настроить несколько баз данных с одним и тем же суффиксом, что в свою очередь позволяет настроить несколько экземпляров back-ldap для отправки репликации одной базы данных на несколько целевых серверов. Есть и другие способы применения скрытых баз данных (например, использование потребителя syncrepl для поддержки *локального* зеркала базы данных на отдельной файловой системе).

A.2.7. Более гибкое управление конфигурацией TLS

В версии 2.3 настройки TLS в slapd использовались только для входящих подключений к демону slapd. Для исходящих подключений, используемых, например, back-ldap или syncrepl, параметры TLS этих подключений брались из системного файла ldap.conf.

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

A.2.8. Улучшения производительности

Слишком много, чтобы всё перечислить. Некоторые заметные изменения - ldapadd когда-то был на два порядка медленнее, чем "slapadd -q". Теперь он в худшем случае в два раза медленнее slapadd -q. Некоторые сравнения всех релизов OpenLDAP 2.x доступны по адресу http://www.openldap.org/pub/hyc/scale2007.pdf.

В этом исследовании сравниваются версии 2.0.27, 2.1.30, 2.2.30, 2.3.33 и текущую из репозитория CVS. По диаграмме "Производительность кэшированных запросов" трудно увидеть разницу, поскольку время отклика очень мало, но новый код примерно на 25% быстрее чем 2.3, который примерно на 20% быстрее чем 2.2, который примерно на 100% быстрее чем 2.1, который примерно на 100% быстрее чем 2.0 в данном конкретном сценарии поиска. В этом тесте производился поиск по базе данных размером 1.3GB, содержащей 380836 записей (все в кэше записей slapd) менее чем за 1 секунду, таким образом, на CPU 2.4GHz с RAM DDR400 ECC/Registered мы можем производить поиск со скоростью более чем 500 тысяч записей в секунду. Поиск осуществлялся по неиндексированным атрибутам с использованием фильтра, не соответствующего ни одной записи, чтобы заставить slapd исследовать каждую запись в базе данных на соответствие фильтру.

По существу, кэш записей slapd в back-bdb/back-hdb настолько эффективен, что время на осуществление самого поиска практически незаметно; время отклика ограничивается только пропускной способностью памяти машины (скорость поиска данных соответствует примерно 3.5GB/сек; пропускная способность памяти машины составляет примерно 4GB/сек, что связано с задержками ECC и регистров).

A.2.9. Новые наложения

A.2.10. Новые возможности в существующих наложениях

A.2.11. Новые возможности в slapd

A.2.12. Новые возможности в libldap

A.2.13. Новые клиенты, инструменты и усовершенствования существующих инструментов

A.2.14. Новые опции сборки


A.3. Устаревшие возможности, удалённые из версии 2.4

Следующие возможности серьёзно устарели в 2.3 и были удалены в версии 2.4.

A.3.1. Slurpd

Чтобы ознакомиться с тем, почему этот демон больше не присутствует в OpenLDAP, прочитайте раздел Репликация.

A.3.2. back-ldbm

back-ldbm был и медленным, и ненадёжным одновременно. Его устаревший код индексирования был склонен к спонтанному разрушению, это было связано с основополагающими библиотеками баз данных (GDBM или NDBM), которые обычно использовались с данным механизмом манипуляции данными. back-bdb и back-hdb превосходят данный механизм во всех аспектах: упрощённое индексирование, позволяющее избежать разрушения индексов, высокоточная блокировка для улучшения параллельной работы, иерархическое кэширование для повышения производительности, модернизированный формат хранения данных на диске для повышения эффективности и переносимости, и полная поддержка транзакций для повышения надёжности.