Приветствую.
Как представитель команды разработчиков ReOpenLDAP хочу пояснить некоторые ближайшие намерения и обсудить их.
1) По производственной необходимости нам приходиться вносить несовместимость с оригинальным OpenLDAP.
Пока это выразилось только в опции checkpoint для mdb-бэкенда.
Напомню - в оригинале интервал задается в минутах, а у нас в секундах.
Однако для массового применения и "попробовать" подобные моменты очень неудобны, так как необходимо внимательно прочесть документацию и аккуратно поправить конфиг.
Поэтому наше предложение = добавить опцию конфигурацию с условным названием
iddqd.
Если опция есть, то действует "новый" смысл некоторых параметров, иначе режим совместимости.
Например в slapd.conf: reopenldap iddqd
2) Аналогично, условная опция
idkfa для включения дополнительного assert-контроля, включая контроль блоков динамической памяти.
Для ясности поясню:
- вопреки ожиданиям в оригинальном коде OpenLDAP достаточно ошибок, в том числе с использованием и повторным освобождением блоков памяти.
- мы придерживаемся стратегии fail-fast (
http://en.wikipedia.org/wiki/Fail-fast,
http://habrahabr.ru/post/218325/), с тем чтобы выявить максимум проблем при тестировании и в ходе промышленной эксплуатации видеть проблемы явно (и быстро исправлять их), а не гадать над "странными непонятными/редкими глюками".
- однако для многих сценариев использования такой жесткий контроль может приводить к неожиданно-неприемлемым падениям, причем когда без контроля ошибка может не проявляться вовсе.
- поэтому наш "фирменный" контроль будет включаться условной опцией idkfa (точнее говоря, выключаться при её отсутствии).
Например в slapd.conf: reopenldap iddqd idkfa
3) Было найдено несколько изъянов в реализации репликации, исправление которых требует некого аналога biglock (
http://en.wikipedia.org/wiki/Giant_lock).
В качестве иллюстрации проблемы - в фазе "delete non present" клиент репликации может удалить db-входы, которые отсутствует на сервере репликации, но были добавлены локально (или реплицированны с других серверов) после начала локального поиска (см.
https://github.com/ReOpen/ReOpenLDAP/issues/12).
Поэтому мы намерены реализовать "большую блокировку" для сериализации (последовательного атомарного выполнения) всех операций изменений данных (add, delete, modify, rename/modrnd).
Однако, при реализации функционала biglock мы несколько раз сталкивались с особенностями качества кода OpenLDAP.
Так например, даже тесты используют chain-наложение и ldap-бэкенд с подключением к "самому себе".
Соответственно при этом наша "большая блокировка" нарушает работу, так как одна операция взаимно блокируется другой.
Чтобы сохранить гибкость в конфигурировании, не хардкодить логику блокировок и сохранить возможность совместимости с оригинальным OpenLDAP предлагается добавить опцию конфигурации
biglock с режимами none, suffix и common.
- опция будет задавать режим использования блокировок для четырех операций изменения (add, delete, modify, modrdn/rename), опосредованно для смены паролей, конфига и т.п.
- операции чтения при этом ни как не блокируются, т.е. могут идти параллельно и асинхронно в зависимости от возможностей движка хранения данных.
- режим '
biglock none' = никаких глобальных блокировок, т.е. будет соответствовать штатному поведению OpenLDAP.
- режим '
biglock suffix' = блокировка на уровне каждого суффикса, т.е. изменение сериализуются отдельно для каждого backend-а используемого для хранения данных по суффиксу.
- режим '
biglock common' = использование общей блокировки, т.е. все изменения сериализуются через одну условную очередь.
Это даст больше гибкости в настройке и избавит от необратимого хард-кодинга логики.
Одновременно с безопасной сериализацией изменений сохранится возможность полной совместимости с оригинальным OpenLDAP.
Например в slapd.conf: biglock common
Однако, пока не очевидно как лучше - сделать ли эту установку одной общей или задавать отдельно для каждого суффикса/бэкенда, тут есть небольшой конфликт интересов:
- 'biglock common' логично задавать одной общей настройкой.
- режимы 'suffix' и 'none' логично задавать персонально для каждого суффикса/бэкенда.
- самый гибкий вариант - сделать две настройки "общую" для всех и "уточняющую для каждого суффикса/бэкенда", но (видимо) это может запутать пользователей?
-
идеи и пожелания приветствуются.
Леонид.
Просмотр сообщений
