ReOpenLDAP: продолжаем развитие/ассенизацию, решаем что можно отрезать...

Щас, все пошли на левый форум.

Для начала нужно написать ЗДЕСЬ что это за поделка. А вижу я кастрированный openldap, пустые слова о якобы лучшем тестировании, репозиторий с похеренной историей который скорее всего не будет ни синхронизироваться с апстримом, ни отправлять в него фиксы. И что-то мне ещё говорит что вы захотите за это бабла.

Да, и при чём тут порты FreeBSD если вы не собираетесь его поддерживать?

Для начала нужно написать ЗДЕСЬ что это за поделка. А вижу я кастрированный openldap, пустые слова о якобы лучшем тестировании, репозиторий с похеренной историей который скорее всего не будет ни синхронизироваться с апстримом, ни отправлять в него фиксы. И что-то мне ещё говорит что вы захотите за это бабла.

Так писано это всё было и здесь и там, повторять каждый раз как-то неудобно. https://github.com/ReOpen/ReOpenLDAP/wiki

Да, и при чём тут порты FreeBSD если вы не собираетесь его поддерживать?

Для наших проектов FreeBSD не релевантно (ну совсем никак), но похоронить как-то жалко. Может быть найдется чел желающий поддерживать порт для FreeBSD.

Сколково, нагрузки r/w 1:1 или 2:1... Имхо, вы не ту БД для данных выбрали. И добавлю, что все патчи с вашей стороны «нормальным» людям не понадобятся. Возьмите рсубд нормальную и посмотрите сколько она выдержит на вашем суперкластере.

Ну, а так, дело ваше, пилите и успехов.

Сколково, нагрузки r/w 1:1 или 2:1... Имхо, вы не ту БД для данных выбрали.

Нагрузку по чтению мы особо не измеряем, так как в обозримом будущем у нас она будет расти кратно относительно записи. Сейчас отношение r/w плавает где-то между 1:1 и 5:1. Выбирать движок БД относительно не приходиться, видимо вы не в теме.

И добавлю, что все патчи с вашей стороны «нормальным» людям не понадобятся.

Надеюсь «нормальным» людям OpenLDAP не потребуется, потому как есть OpenDJ, 386DS, в крайнем случае Active Directoty. Соглашусь что наши потребности совсем не рядовые, уж точно. Но и наши патчи мы не навязываем, просто решаем свои задачи и соблюдаем лицензию.

Возьмите рсубд нормальную и посмотрите сколько она выдержит на вашем суперкластере.

Чушь порете, батенька ;)

Возможно будут удалены возможности, которые сложно тестировать (обеспечить качество), либо которые редко затребованы (вопрос требует изучения): perl/shell, rwm (rewrite), chain, pcache, translucent, relay.

Хм... А я на прошлой неделе настраивал pcache. Работает он местами странновато, но таки работает.

Извиняюсь, проглядел целевое использование (телеком), поэтому так резко «напал» :)

Сборку под centos не планируете? А то я не осилил.

Сборку под centos не планируете? А то я не осилил.

rpm-ами пока не занимаемся, не до этого. Позде, после релиза я думай пройтись по закормам собрать для всех основных платформ.

Но оно из сейчас «из коробки» собирается. если доставить нужные пакеты. Минут 5-10 возьни, не больше.

Если вы будете бэкпортировать новый функционал в OpenLDAP обратно в ReOpenLDAP - честь вам и хвала. В противном случае нужно было долбить разработчиков всеми возможными методами, но добиться того, чтобы они приняли патчи.

И да, нельзя подробнее рассказать о том, почему они их не прнинимали?

Относительно глюков репликации - в режиме мультимастера они проявлялись и без высоких нагрузок, во всяком случае в 2.4.1X и 2.4.2X я регулярно прозводил тонны кирпичей при виде Segmentation fault'ов на ровном месте.

То есть безусловно всё, что вы сделали с точки зрения чистки кода от багов - правильно. Сомнения вызывает лишь организационная сторона вопроса: в проекте OpenLDAP работают Курт Зейленга и Говард Чу - я думаю, не считаться с мнением этих людей и тупо форкать проект - это как-то самонадеяно, мягко говоря.

ЕМНИП суть ldap это каталог, в который редко пишуть но очень много читают, если у вас r/w сопоставимы - вам точно не ldap нужен.

Кстати, у меня есть идея, если интересно :) Я думаю, нужно попробовать использовать MongoDB в качестве бэкенда. LDAP-каталог - это структурированный по ирерархческому принципу, а также связанный горизонатльными ссылками распределённый каталог объектов. Mongo - примитивно просто тупо каталог объектов key=>value. Я думаю, они здорово друг другу подходят, тем паче, что над оптимизацией Mongo бьются тысячи людей, которым лень понять концепции Каталогов :)

Ненада mongodb, ну пожалуйста. Лучше ту-же cassandra или еще какую приблуду, но не mongodb.

LDAP - это каталог объектов. Если совокупность свойств, описывающих объект, периодически меняется, а объектов, скажем так, очень много, то и запись будет частой, почему же нет.

Например, состояние абонента: подключен к услуге/отключен от услуги. Для одного абонента это состояние меняется редко. А для 10 миллионов абонентов отключения/подключения будут происходить по 8000 раз в минуту, а то и чаще.

Лучше LDAP.

Каталоги нельзя сравнивать с наколеночной NoSQL ширпотребщиной. Это всё равно что сравнивать жёлтую прессу с добротной научной периодикой.

Подключение и отключения это сессии как Я понял? Если так — им не место в ldap. Еще раз, ldap это каталог, тоесть хранилище редко меняющейся информации где чтение не сопоставимо с записью. Как, допусти, картотека какая и является прообразом ldap, точнее dap который оказался сложноват.

Cassandra ширпотребщина? Ок, да. Но вот только Я не говорил о замене кассандрой ldap'а, но о работе для ldap'а как бекенд. И да, стандартная фраза про инструменты и задачи тут вполне релевантна.

Подключение и отключения это сессии как Я понял?

Нет конечно. Это статус пользователя: предоставляется ему услуга или нет. Мне, например, пчелайн не предоставляет уже: денег на счету нет :)

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

Насчёт чтения - тоже не очень согласен. Чтение ничего никому не должно, его может и не быть вовсе, каталог может читаться редко. Например, какой-нибудь исправно обновляемый справочник всего и вся, который никому не нужен или находится ещё на стадии разработки и не предоставлен в открытый доступ.

Сопоставимые чтение и запись означает, что практически на каждое чтение идет запись. Что явно выбивается из приведенного вами примера. Или клиент будет отменять подписку и подписываться на каждый звонок к нему?

Сопоставимые чтение и запись из иерархического реестра объектов - это странно, но возможно: скорее всего, в каталог отправляется любая информация о клиенте оператора сотовой связи. Например, информация об изменении баланса после отправки СМС-сообщения.

Я бы так делать не стал: с моей точки зрения нужно подобные вещи хранить в оптимизированных на запись СУБД, при этом ссылаясь на каталог в какой-нибудь таблице people с полями uid и dn (первое-идентификатор внутри СУБД, второе - ссылка на объект в LDAP, являющийся «паспортом пользователя»).

Но здесь есть ещё один тонкий момент: до тех пор, пока с тем же каталогом LDAP работает всего одна программа - его действительно можно использовать после надлежащей оптимизации как просто «древовидную СУБД».

А LDAP-каталог - это авторитетный реестр объектов, предназначенный для совместного использования приложениями информационной системы.

LDAP-каталоги разрабатывались для того, чтобы служить объектным «скелетом» информационной модели, хранящим свойства объектов, но не их методы, то есть не их собственную программную логику.

Кости скелета не должны ничего «знать» о взаимодействии нейронов головного мозга или работе клапанов сердца. И LDAP-каталог не должен содержать сведений, которые интересны только одному конкретному приложению. Иначе получается, что приложение хранит данные своих собственных «внутренних» объектов, касающиеся того или иного объекта общей информационной модели, в самом объекте информационной модели.

Безусловно, в каких-то случаях можно копировать данные приложения в объект информационной модели, чтобы другие приложения могли ими воспользоваться , но вот хранить их прямо в каталоге - это, конечно, противоречит задаче Каталогов. И задача эта максимально кратко и ёмко формулируется одним словом - интеграция.

Задача LDAP-каталога - интеграция приложений, реализующих логику информационной системы на основе единой информационной модели, костяком которой каталог и является, поскольку предоставляет авторитетный/авторитативный реест объектов информационной модели.

Давайте расскажу, пока тесты фигачат...

И да, нельзя подробнее рассказать о том, почему они их не прнинимали?

Формальная причина в использовании variadic macro из C99, т.е. __VA_AGRS__ для избавления от предупреждений типа «лишние аргументы printf». Говард заявил что в целях OpenLDAP сборка всяческими компиляторами и они не могут согласиться на __VA_AGRS__. Предлагаемый рецепт «отключите предупреждения компилятора», с этого началось...

Карму variadic macro сильно попортил microsoft, они долго упирались и всячески консервировали развитие своего С-компилятора, предлагая переходить на C++. Но в результате visial C++ уже несколько лет как поддерживает __VA_AGRS__.

С одной стороны, Говард прав - негоже требовать поддержку C99.

Но с другой стороны, фича variadic macro это не весь C99. __VA_AGRS__ поддерживаются всеми жизнеспособными компиляторами. Да, и как выяснилось (тупо grep по исходникам) __VA_AGRS__ уже используется для отладки.

После этого я попросил пояснить как происходить тестирование OpenLDAP. Например, перечислить платформы и компиляторы, которыми хотя-бы проверяется компилируемость. Никакого списка названо не было... Плюс есть обращения из-за неработоспособности и глюков в Windows, OSX и *BSD.

Короче, выяснилось что декларируемая переносимость OpenLDAP - это на 99% только декларация и демагогия, а тестируется он сейчас только на Linux x86_64.

--

Всего я убрал порядка 5000 предупреждений. Большинство были безобидными, т.е. создавали проблем. Но из-за такого кол-ва обращать внимание на ругань компилятора было не возможно. Примерно в 20-25 случаях компилятор был прав, а где-то 10 - серьезные ошибки, например использование обращение по неинициализированному указателю когда if (condition=false).

Все эти правки были проигнорированы, хотя разделены по патчам.

Через пару дней после срача, Говард прогнал OpenLDAP через Coverity и поправил часть замеченных багов. Но в целом это выглядело странно:

• если не нравиться __VA_AGRS, то почему-бы не взять остальные мои патчи, если видно что там исправляются явные баги.
• в результатах прогона Сoverity осталось около 1800 замечаний, которые Говард назвал «смехотворными», т.е. десяток найденых мной багов был как-бы поправлен после прогона Coverity, а еще 1800 предупреждений Coverity проигнорены.
• много проблем типа SIGSEGV-падений или выдаче мусора были «скомканы» и закоммичены как «minor cleanup», т.е. возникает ощущение что Говард пытается маскировать проблемы с качеством кода.
• при этом OpenLDAP продолжал падать на тестах при включенном контроле памяти, т.е. продукт глючит и падает, а Говард называет результат Covery «смехотворным».

Перед этим я нашел где-то 10 багов, из которых меня особо впечатлило отсутствие volatile в LMDB. Пришлось объяснять как работает компилятор и почему он может «свернуть» и/или выкинуть вызовы многих функций...

Тут у меня закрылись сомнения, как-бы сказать точнее - в адекватности, что-ли. Только поймите правильно, я не любитель критиковать. Тут всё-таки OpenSource, не нравиться - поправь. Но в сухом остатке у меня серьезные претензии к стилю кодирования (aka 'rebus' code style) и объему технического долга.

--

Относительно глюков репликации - в режиме мультимастера они проявлялись и без высоких нагрузок, во всяком случае в 2.4.1X и 2.4.2X я регулярно прозводил тонны кирпичей при виде Segmentation fault'ов на ровном месте.

Думаю мы поправили 99% этих проблем, т.е. сейчас не падает. Большинство правок вошло в оригинальный OpenLDAP, но не все. Что-то у нас сделано просто иначе. Как пример, так называемый 'dreamcatcher' не подвержен http://www.openldap.org/its/index.cgi/Software Bugs?id=8036;page=7

Сейчас я заканчивают тестировать biglock и работу репликации при восстановлении из split brain, см. https://github.com/ReOpen/ReOpenLDAP/issues/12 и http://pro-ldap.ru/forum/index.php?topic=286.msg693#msg693

То есть безусловно всё, что вы сделали с точки зрения чистки кода от багов - правильно. Сомнения вызывает лишь организационная сторона вопроса: в проекте OpenLDAP работают Курт Зейленга и Говард Чу - я думаю, не считаться с мнением этих людей и тупо форкать проект - это как-то самонадеяно, мягко говоря.

Сделать форк не было самоцелью. Кроме исправлений нам нужны несколько features, которые навряд ли смогу попасть в оригинальный OpenLDAP. Например: lifo reclaiming для LMDB и dreamcatcher. Поэтому некий форк нам нужен как минимум для соблюдения OpenSource лицензии. Однако, идти столь радикально-самостийным путем изначально мы не собирались.

Откровенно говоря, у нас постоянный facepalm по поводу OpenLDAP. Ведь что в реальности произошло: проект выглядел стабильным, решили использовать, оно падало и местами тормозило, стали разбираться и справлять, получили facepalm, фиксим дальше, пока не выбросили (хотя уже подумываем).

Мнение Говарда я начинаю ценить все меньше и меньше из-за реального качества кода OpenLDAP. На прошлой неделе я заметил еще один чудесный баг, который заставляет задуматься. Вот, если угодно https://www.facebook.com/leo.yuriev/posts/345420485645555?pnref=story

МНИП суть ldap это каталог, в который редко пишуть но очень много читают, если у вас r/w сопоставимы - вам точно не ldap нужен.

Уточню. Сейчас r/w сопоставимы, то дальше r будет расти.

Грубо говоря, делается подсистема, которая изначально должна держать большую нагрузку по записи. Затем другие подсистемы-клиенты итеративно допеределываются и начинают использовать этот LDAP-справочник. Соответственно, в обозримом будущем нагрузка по чтению постепенно кратно растет и растет...

LDAP заложен в инфраструктуру управления сетью. Грубо говоря, есть «большое коммуникационное оборудование» промышленного уровня, которое желает общаться по LDAP-протоколу. Поэтому какой-то LDAP-сервер нам все равно нужен.

Кстати, у меня есть идея, если интересно :) Я думаю, нужно попробовать использовать MongoDB в качестве бэкенда. LDAP-каталог - это структурированный по ирерархческому принципу, а также связанный горизонатльными ссылками распределённый каталог объектов. Mongo - примитивно просто тупо каталог объектов key=>value. Я думаю, они здорово друг другу подходят, тем паче, что над оптимизацией Mongo бьются тысячи людей, которым лень понять концепции Каталогов :)

Да, монго подойдет. Но не так давно Олег Бартунов с командой сделал BJSON-индекс для PostgreSQL, что в моих глазах сильно «бьет» монгу.

Пока я не копался в mongo (в исходниках) достаточно глубоко чтобы сделать окончательный выбор/вывод, но качество исходников и решений в PostgreSQL вызывает уважение.

Однако, все это пока не очень релевантно. Проблема в OpenLDAP... Чтобы сделать backend нужно иметь хорошую спецификацию и набор тестов. Для OpenLDAP нет ни одного ни другого, а качество существующего кода меня сильно огорчает.

Поэтому, в текущем понимании, мы не будем делать backend для OpenLDAP. Если нам не удастся добиться стабильности, то мы либо возьмем OpenDJ и будем прикручивать к нему свой backend, либо вообще откажемся от LDAP в пользу «сырого» key-value (например Тарантул от команды Кости Осипова).

А OpenLDAP нас действительно пугает - мы находим баги, которые заставляют задуматься: если разработчики сделали «это», то что нам еще стоит ожидать? где дно?

Такой крайний баг - обновление поля bd_info в инфраструктуре оверлеев, т.е. чистой воды глобальный race condition при обработке любых запросов...

Задача LDAP-каталога - интеграция приложений, реализующих логику информационной системы на основе единой информационной модели, костяком которой каталог и является, поскольку предоставляет авторитетный/авторитативный реест объектов информационной модели.

Хорошо сформулировано.