Глава 6. OpenLDAP slapd.conf, базы данных bdb и hdb

Этот раздел документации посвящён директивам, специфичным для баз данных bdb (и hdb). Общие директивы раздела database описаны здесь. Berkeley DataBase (BDB или HDB) (ныне принадлежит Oracle) — некогда был предпочтительным и рекомендуемым механизмом манипуляции данными OpenLDAP (в настоящее время вытеснен механизмом mdb), требующий, однако, тщательной настройки в случае, когда приложению необходима высокая производительность. Указанные здесь параметры — только часть настроек производительности. Другие настройки могут содержаться в файле DB_CONFIG file (смотрите также главу, посвящённую производительности).

Предупреждение: Файл журнала транзакций BDB (log.xxxxxxxxxxxx в директории базы данных LDAP, определяемой директивой directory) может очень быстро и очень сильно разрастаться, и потому требует регулярного обслуживания. Описание процедур обслуживания можно найти в документации BDB, в частности, утилиты обслуживания обсуждаются в главе 25, удаление файла журнала — в главе 12.

Часть параметров данного раздела файла slapd.conf напрямую обрабатывается базой данных BDB. Такие параметры могут быть заменены соответствующими директивами файла настройки базы данных DB_CONFIG (для cn=config его расположение определяется в атрибуте olcDbConfig) и удалены из cn=config (файла slapd.conf). Видимо, разработчики OpenLDAP всё больше склоняются к использованию директив DB_CONFIG, нежели эквивалентных им атрибутов конфигурации или директив slapd.conf. Если такая замена возможна, это указывается в описании каждой конкретной директивы.

Содержание

1. cachesize
2. checkpoint
3. dbnosync
4. directory
5. dirtyread
6. index
7. lockdetect
8. mode
9. searchstack
10. Пример файла DB_CONFIG
11. Фрагменты-примеры раздела database bdb

Формат:

cachesize integer

Директива cachesize определяет количество записей, которое механизм манипуляции данными LDAP будет обслуживать в памяти. Не путайте данную директиву с директивой BDB set_cachesize — они управляют различным поведением.

Для достижения максимальной производительности этот показатель должен соответствовать, либо быть максимально приближен к количеству записей, содержащихся в каталоге. Значение по умолчанию — 1000. Примеры:

cachesize 10000
# LDAP обслуживает в памяти 10,000 записей

Смотрите также главу о настройках производительности.

Формат:

checkpoint kbyte min

Директива checkpoint определяет промежуток времени между выполнением операции сброса данных в контрольной точке (checkpoint) в базе данных BDB, то есть записи данных из оперативной памяти на диск. Восстановить базу данных можно только из последней контрольной точки.

По сути, частота выполнения операции сброса данных в контрольной точке определяет промежуток времени; если за этот промежуток времени в каталог будут внесены изменения, то, в случае краха системы, их невозможно будет восстановить средствами BDB. Если dbnosync НЕ ИСПОЛЬЗУЕТСЯ, в качестве данного промежутка времени может быть установлен достаточно длительный период, скажем, 10 минут или больше; если же директива dbnosync ИСПОЛЬЗУЕТСЯ, то лучше установить его в 5 — 15 минут или менее. Параметр kbytes — количество килобайт, записанных в каталог, а параметр min — время в минутах. То значение, которое будет достигнуто первым, и определяет окончание периода между операциями сброса в контрольной точке.

По умолчанию OpenLDAP НЕ ПРОИЗВОДИТ ОПЕРАЦИЙ СБРОСА В КОНТРОЛЬНОЙ ТОЧКЕ, таким образом, нужно всегда явно указывать директиву checkpoint. Дополнительную информацию можно найти в разделе 15 главы 12 документации BDB. Данную директиву можно заменить директивой txn_checkpoint файла DB_CONFIG. Примеры:

checkpoint 128 15
# сброс данных в контрольной точке происходит либо после записи 128k данных,
# либо по прошествии 15 минут, в зависимости от того, что произойдёт раньше

Формат:

dbnosync

Директива dbnosync указывает, что для базы данных НЕ требуется немедленная синхронизация при изменении какой-либо записи в памяти. Данная опция увеличивает производительность при операциях записи, но есть и недостаток: если крах системы произошёл до того, как данные на диске и в памяти синхронизировались, то часть данных может быть утеряна. Синхронизация данных между памятью и диском управляется директивой checkpoint. По умолчанию (при отсутствии данной директивы) обновление данных на диске происходит сразу же. Примеры:

dbnosync
# разрешено отложенное обновление данных на диске

Данная директива аналогична опции BDB set_flag DB_TXN_NOSYNC — смотрите главу о настройках производительности.

Формат:

directory /path/to/directory

Директива directory определяет местонахождение файлов базы данных BDB. По соглашению эти файлы размещаются в /var/db/openldap-data (BSD) или /var/lib/ldap (FC/Linux), но их можно размещать в любом удобном месте. Указанная в директиве директория ДОЛЖНА существовать перед первым запуском OpenLDAP.

Если Вы не определили данную директиву, OpenLDAP по умолчанию будет использовать директорию /var/db/openldap-data (BSD) или /var/lib/ldap (FC). Если Вы указали относительное имя для директории (без '/' в начале), BDB будет подставлять в начало пути содержимое своей переменной окружения DB_HOME, которая может указывать на любую точку вселенной.

Хотя значения по умолчанию предусмотрены, документация OpenLDAP утверждает (но не настаивает), что директива directory является ОБЯЗАТЕЛЬНОЙ. Мы рекомендуем всегда указывать эту директиву хотя бы затем, чтобы не тратить время на поиски месторасположения файлов базы данных.

Если Вы собираетесь создавать или обслуживать каталог с несколькими DIT (для этого нужно несколько разделов database), целесообразно заранее продумать и создать систему именования поддиректорий для хранения файлов этих баз данных. Примеры:

directory /var/ldap/example-com
# директория example-com должна существовать, на неё должны
# быть назначены права на чтение и запись пользователю ldap

directory example-com
# в начало пути добавляется значение переменной BDB DB_HOME
# и директория будет /user/local/share/openldap/example-com (BSD)

Формат:

dirtyread

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

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

dirtyread
# пользователь МОЖЕТ получить данные, которые 
# не соответствуют конечному состоянию каталога

Лучше определять директивы index файла slapd.conf перед первоначальной загрузкой каталога (с помощью ldapadd), тогда при первоначальной загрузке соответствующие индексы будут созданы автоматически. При внесении изменений в настройки индексов после первоначальной загрузки требуется переиндексирование (повторное создание индексов) каталога с помощью slapindex (предупреждение: перед этим slapd должен быть остановлен).

В конфигурации OLC (cn=config) используется атрибут olcDbIndex, который может присутствовать только в записи olcDatabase={Z}xxx,cn=config. Кроме того, переиндексирование происходит в режиме реального времени, то есть любые изменения данного атрибута срабатывают немедленно и индексирование изменяется (выполнять slapindex не нужно). Однако, при использовании OLC (cn=config) трудно понять, когда переиндексирование завершается (никаких видимых признаков окончания процесса нет).

Формат:

# форма OLC (cn=config)
olcDbIndex: attrlist | default indices

# форма slapd.conf
index attrlist | default indices

# indices = [pres [,approx] [,eq] [,sub] [,special]]

Атрибуты olcDbIndex (директивы index) определяют, какие индексы будут обслуживаться OpenLDAP. Может быть включено любое количество параметров индексирования. Даже если атрибут не был указан в директивах index, его всё равно можно использовать в поисковых фильтрах — если это будет происходить часто, то конечно, производительность будет страдать, а если раз в жизни — ничего страшного.

attrlist может быть единичным атрибутом, или списком атрибутов, разделённых запятыми.

Необязательный параметр default содержит те индексы, которые должны поддерживаться по умолчанию. Они применяются к атрибутам в последующих атрибутах olcDbIndex (директивах index), в которых пропущен список индексов. Атрибут olcDbIndex (директива index) со значением default должен быть определён до появления атрибутов olcDbIndex (директив index) без списка индексов. Если определено несколько атрибутов olcDbIndex (директив index) со значением default, каждая из них будет влиять на атрибуты olcDbIndex (директивы index), следующие непосредственно за ней, до появления очередного атрибута olcDbIndex (директивы index) со значением default.

Индекс pres следует использовать, если предполагается, что будут выполняться поисковые запросы в форме 'objectclass=person' или 'attribute=mail'.

Индекс approx НЕОБХОДИМО использовать, если предполагается, что будут выполняться поисковые запросы в форме 'sn~=person' (поиск 'созвучных' значений).

Индекс eq следует использовать, если предполагается, что будут выполняться поисковые запросы в форме 'sn=smith', то есть без применения поисковых шаблонов (используется только правило EQUALITY).

Индекс sub следует использовать, если предполагается, что будут выполняться поисковые запросы в форме 'sn=sm*', то есть с применением поисковых шаблонов (используется правило SUBSTR). Данный индекс можно задать более конкретно, указывая subinitial (оптимизация под 'sn=*s'), subany (оптимизация под 'sn=*n*') или subfinal (оптимизация под 'sn=th*'). Для одного атрибута можно указать несколько индексов типа sub.

Параметр special связан с подтипами (subtype) и может быть либо nolang, либо nosubtypes.

Будьте очень внимательны при выборе того, какие индексы будут поддерживаться каталогом. Лучше делать это на основании требований приложений; если их не учитывать, это может серьёзно повлиять на производительность каталога. И наоборот, нет никакого смысла индексировать те атрибуты, поиск по которым никогда не осуществляется. Если в поисковых запросах используются только правила EQUALITY, нет смысла устанавливать индексирование sub. Индексы потребляют память (чем больше индексов, тем больше они занимают оперативную память). Кроме того, операции записи и модификации при большом количестве индексов будут выполняться дольше, поскольку требуется время и ресурсы на обновление индексов.

Примеры:

# Простое использование значения default
# форма OLC (cn=config)
olcDbIndex: default pres,eq
olcDbIndex: cn,sn,uid

# форма slapd.conf
index default pres,eq
index cn,sn,uid

# Определяем индексы наличия и соответствия
# для атрибутов cn, sn и uid
# две приведённые выше директивы index выполняют
# абсолютно то же, что и три, приведённые ниже
index cn pres,eq
index sn pres,eq
index uid pres,eq

index cn eq,sub,subinitial
# Создаём индексы для атрибута cn (commonname)
# для поисков EQUALITY, SUBSTR, а также дальнейшая оптимизация
# для поисков типа sc=a*

index sn eq,approx,sub
# Создаём индексы для атрибута sn (surname)
# для поисков EQUALITY и SUBSTR
# Примечание: Индекс approx index - пустая трата времени,
#     поскольку для sn не определено правило ORDERING,
#     требуемое для поисков approx. Приводится лишь для
#     иллюстрации возможности использования

index mail pres,eq,sub
# Создаём индексы для атрибута mail on
# для поисков на наличие, EQUALITY и SUBSTR

index objectclass eq
# Оптимизируем поиски по форме objectclass=person

Обзор других настроек производительности можно найти в соответствующей главе.

Считается устаревшей в пользу параметра set_lk_detect файла DB_CONFIG.

Формат:

mode mask

Директива mode определяет права на файлы, назначаемые при первоначальном создании файлов базы данных BDB. Значение по умолчанию — 0600 (чтение и запись разрешены только пользователю ldap, остальным доступ запрещён). Примеры:

mode 0660
# пользователь ldap - чтение и запись
# группа ldap - чтение и запись
# остальные - нет доступа 

Формат:

searchstack depth

Директива searchstack определяет глубину (depth) стека, используемого для оценки поискового фильтра. Оценка поисковых фильтров происходит по стеку, в который помещаются вложенные условия AND / OR. Для каждого потока сервера выделяется собственный стек. Глубина стека определяет, насколько комплексные фильтры могут быть оценены без необходимости выделения дополнительной памяти.

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

Каждый поисковый стек использует 512Kb для одного вложенного уровня условий. Глубина стека по умолчанию — 16, то есть используется 8MB памяти для каждого потока. Примеры:

searchstack 5
# позволяет размещать в стек до 5-ти вложенных инструкций поиска

Ответ на вопрос, стоит или нет использовать файл DB_CONFIG, прост: если Вы заботитесь о производительности — используйте его, если не заботитесь — забудьте о нём. ОДНАКО, если Вы решили не использовать DB_CONFIG, то Вы ДОЛЖНЫ определить директиву checkpoint в файле slapd.conf. Разработчики OpenLDAP всё чаще советуют использовать DB_CONFIG вместо определения аналогичных директив в slapd.conf.

Файл DB_CONFIG располагается в директории, указанной в директиве directory. Используемые в этом файле директивы полностью описаны в руководстве по BDB. Можно заменить директивы checkpoint, lockdetect, dbnosync файла slapd.conf эквивалентными директивами файла DB_CONFIG, а также добавить дополнительные директивы настройки производительности по мере необходимости.

Пример файла DB_CONFIG:

# замена директивы lockdetect
set_lk_detect DB_LOCK_EXPIRE
# ЛИБО set lk_detect DB_LOCK_DEFAULT

# раскомментируйте, если требуется dbnosync
# set_flags DB_TXN_NOSYNC
# разрешено использовать несколько директив set_flags

# устанавливает максимальный размер журнала в 5Mb (по умолчанию для BDB - 10Mb)
set_lg_max 5242880

set_cachesize 0 5242880 1
# устанавливает кэш базы данных в 5Mb
# разрешается фрагментация
# НЕ заменяет директиву cachesize в slapd.conf
# это параметр базы данных

txn_checkpoint 128 15 0
# замена директивы checkpoint в slap.conf
# сброс в контрольной точке при записи 128K или каждые 15 минут
# 0 говорит о том, что если не было операций записи, то обновлений не производится

Примечание:

1. Если у Вас несколько DIT (несколько разделов database в slapd.conf), файл DB_CONFIG требуется для каждой директории, содержащей файлы базы данных.
2. Для проверки некоторых показателей статистики базы данных используйте:

   cd /to/bdb/directory
   db_stats -m
   
   # ИЛИ на BSD
   
   db4_stat -m
   

3. Из документации не совсем понятно, что произойдёт, если параметры в slapd.conf и в DB_CONFIG будут конфликтовать друг с другом. В общем случае — НЕ ДОПУСКАЙТЕ этого! Например, если у Вас в slapd.conf присутствует директива checkpoint, а в DB_CONFIG — директива txn_checkpoint, — удалите одну из них.

Следующие фрагменты раздела database иллюстрируют настройку базы данных BDB. Цель оптимизации производительности не ставится.

Пример 1 — файл DB_CONFIG не используется:

database bdb
...
# только фрагмент раздела database
# порядок директив не важен
cachesize 10000
checkpoint 128 15
directory /var/ldap/first-dit
dbnosync
dirtyread
index mail pres,eq
index objectclass pres
index default eq,sub
index sn eq,sub,subinitial
index telephonenumber
index cn
searchstack 5

Та же конфигурация с использованием файла DB_CONFIG:

Фрагмент slapd.conf:

database bdb
...
# только фрагмент раздела database
# порядок директив не важен
cachesize 10000
directory /var/ldap/first-dit
dirtyread
index mail pres,eq
index objectclass pres
index default eq,sub
index sn eq,sub,subinitial
index telephonenumber
index cn
searchstack 5

Файл DB_CONFIG:

Файл DB_CONFIG располагается в директории, указанной в директиве directory. Используемые в этом файле директивы полностью описаны в руководстве по BDB. Можно заменить директивы checkpoint, lockdetect, dbnosync файла slapd.conf эквивалентными директивами файла DB_CONFIG, а также добавить дополнительные директивы настройки производительности по мере необходимости.

set lk_detect DB_LOCK_DEFAULT
set_flags DB_TXN_NOSYNC
set_lg_max 5242880
set_cachesize 0 5242880 1
txn_checkpoint 128 15 0