LINUX.ORG.RU

Выпущен релиз-кандидат ReOpenLDAP 2.4.41 «Christmas»

 , , , ,


0

7

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

Новая версия базируется на кодовой базе готовящегося к выпуску OpenLDAP 2.4.41, куда изначально направлялись все наши исправления.

Главное качество этой версии — работа без падений и без отказов сервиса под высокой нагрузкой с репликацией в кластере, что ранее было невозможно. В частности, исправлено 8 heisenbugs, которые существовали годами, особенно в коде репликации и LMDB-движке http://en.wikipedia.org/wiki/Lightning_Memory-Mapped_Database. Одному из багов официально почти 7 лет ;)

Добавленные функции позволяют держать нагрузку по изменениям в 2—10 раз больше оригинального OpenLDAP и до 50 — при наличии у системы хранения write-back кэша (проще говоря, RAID с батарейкой). Для точности следует отметить, что «без батарейки» производительность повышается в результате компромисса, за счет более редкой фиксации данных на диск.

>>> Подробности на github: Описание исправлений и новых фич, исходные тексты.



Проверено: leave ()

Ответ на: комментарий от Macil

А сторону wiredtiger смотреть не пробовали? Вроде бы — тру.

Смотрели. Да, тру, но не reasonable.

Во-первых, WiredTiger это большой самостоятельный проект, грубо говоря - не библиотека. Клеить его непосредственно в openldap не разумно и криво, т.е. для использования нужно сделать бакенд, который будет транслировать запросы из внутренней OpenLDAP-кухни в запросы к тигру. А вот тут два подводных камня:

  • Со стороны LDAP каждый чих будет порождать несколько запросов к WirerTiger, которые пойдут через сокеты. Это оверхед даже по syscall-ам, плюс latency будет суммироваться. Т.е. при всей прелести тигра, скорее всего, никакого выигрыша не будет.
  • Написание storage-бакенда для OpenLDAP дело гиблое, ибо нет вразумительной доки «как должно быть», ну тесты тоже так себе. Бакенд для SQL-storage (видимо) навечно в статусе экспериментального и по оценки самих «афтаров» толком не работает и не поддерживается.

Если вытаскивать из WiredTiger отдельные куски и эмулировать из них lmdb-подобный интерфейс - в принципе вариант, но пока совсем не до этого.

Мне лично интересней переписать LMDB с опорой на 1Hippeus. Точнее на основе менеджера разделяемой памяти 1Hippeus воссоздать концепт MVCC снимков из LMDB, а поверх положить Adaptive Radix Tree или еще что-нибудь (хотя и btree для начала пойдет). Тогда получится mdb-подобный движок со скоростью LMDB и zero-copy & zero-overhead из «гипер-коника».

Во-вторых, цитата: «We're proud to announce that MongoDB has acquired WiredTiger, and we've joined the MongoDB team!

We will be directly involved in supporting the WiredTiger storage engine in MongoDB 2.8 and will continue to develop WiredTiger for future MongoDB releases. WiredTiger will remain available as an open source, standalone storage engine and we will continue to support our existing customers at MongoDB» - пока не ясно что реально из этого выйдет.

ly ()
Последнее исправление: ly (всего исправлений: 1)
Ответ на: комментарий от anonymous

т.е. openldap, несмотря на накопившиеся шероховатости, всё равно работает лучше, чем альтернативы: 389ds, apacheds, opendj?

OpenLDAP с lmdb-бакендом быстрее и read-scalable, но глючнее и баго-опасней.

Мы поправили проблемы (все кроме одной) замеченные в нашем производственном use case. Сколько их там еще - хрен знает, как-то работает, imho код плохой (rebus codesyle).

Сейчас основная (для нас) проблема https://github.com/ReOpenLDAP/reopenldap/issues/3

ly ()
Ответ на: комментарий от ly

OpenDJ так не может, масштабирования чтения по ядрам не будет.

а можно пруф откуда ноги?

Я начал копать и нашел заявление людей о том, что у них в тестах на чтение при 10M пользователей показатели доходят до 200 000 запросов в сек.(в рассылке)

alfss ()
Ответ на: комментарий от Xintrea

Работа проделана большая, авторам (у?) респект.

Спасибо. Исходную версию lifo-feature год назад сделал Алексей Петров. Текущую версию lifo, остальные фичи и фикс большинства багов я. Упомянутый в суе Howard Chu (aka скрипач) ревьювил патчи, поправил некоторые багфиксы. С тестированием серьезно помогали другие сотрудники.

Но не загнется ли этот проект, будет ли перекрестное опыление, хватит ли сил на поддержку форка?

Патчи из OpenLDAP я уже подтягиваю. Исправленные баги будем отправлять в багтрекер OpenLDAP со ссылкой на коммиты в нашем коде. Новые фичи проталкивать в OpenLDAP я больше не будут, но могут взять сами.

Для нашего production и состояния «спасть спокойно» я буду устранять все баги из https://github.com/ReOpenLDAP/reopenldap/issues

Что будет дальше - посмотрим. Но нужно понимать ситуацию правильно. Я решаю производственные задачи компании и компания (PeterService) делится этим результатом согласно идеи open-source и лицензии.

Существенно развивать и оздоровить проект очень сложно и дорого (как минимум по времени). В OpenLDAP жуткий codestyle (а-ля ребус) и большой технический долг, мало документации о внутреннем устройстве и API, т.е. по-хорошему его нужно переписывать (как минимум развить автотесты и CI).

Поэтому в далекой перспективе я вижу переписывание LMDB с опорой на 1Hippeus и (например) подключение в качестве бакенда к OpenDJ.

С другой стороны, я точно не буду так консервативен с доработками как меинтейнеры исходного проекта. Если народ подтянется с патчами или будет участвовать в поддержке (ROSA, ALT и т.п.), тем более если кто-то решит купить поддержку - будем пилить сколько потребуется.

ly ()
Ответ на: комментарий от ly

Во-вторых, цитата: «We're proud to announce that MongoDB has acquired WiredTiger, and we've joined the MongoDB team!

Ах ты ж, ёшкин кот! Продались.

Да, кстати, удачи вам. LDAP — совершенно незаслуженно забытая концепция. Здорово, что на свете есть те кому не «всё равно»!

Macil ★★★★★ ()
Ответ на: комментарий от alfss

а можно пруф откуда ноги?

Я начал копать и нашел заявление людей о том, что у них в тестах на чтение при 10M пользователей показатели доходят до 200 000 запросов в сек.(в рассылке)

Из доступных открытых источников есть http://www.slideshare.net/ldapcon/benchmarks-on-ldap-directories Нет оснований сильно сомневаться в результатах, хотя проверку производила заинтересованная сторона (Symas Corp - это меинтейнеры OpenLDAP и авторы LMDB).

Но дьявол в деталях...

Во-первых, ситуация сильно зависит от того, помещается ли вся БД в RAM или нет. LMDB будет работать в любом случае, при нехватке будет подкачка страниц. Тогда производительность будет какая-то совсем другая, но опять таки - какие диски, может уже актуально тестировать только на SSD.

Во-вторых, как для чистой MVCC производительность OpenLDAP+LMDB по чтению почти не зависит от нагрузки по записи, если база помещается в память, то узким местом для чтения будет RAM Bandwidth. Насколько я понимаю, в OpenDJ (и во многих других кейсах) read-only доступ может быть очень быстрый, но только пока нет параллельной нагрузки записи/модификации данных.

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

Если смотреть на производительность по записи, то LMDB тоже очень быстрый движок, а OpenLDAP не создает большого оверхеда (меньше чем 389DS от RedHat). Однако и тут тонкости - LMDB может работать в разных режимах. Если включить writemap+dbnosync, то производительность по записи упрется только в CPU и RAM. Если же фиксировать базу на диске после каждой транзакции, то вероятно упремся в диск. Да, WAL в LMDB нет ни в каком виде, даже зачаточном.

Наши сравнительные тесты годичной давности (когда выбирали LDAP, это до меня) всё это подтверждают. Но после того, как мы «женились» на OpenLDAP, дергаться уже было не с руки, т.е. после этого мы больше не делали сравнительное тестирование OpenDJ и 389DS - может в последних версиях есть какой-то прорыв.

Если у вас есть другая инфа - дайте ссылки.

ly ()
Ответ на: комментарий от ly

Гм, а чем ваше подразделение во Владивостоке занимается? :)

h4tr3d ★★★★★ ()
Ответ на: комментарий от h4tr3d

Гм, а чем ваше подразделение во Владивостоке занимается? :)

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

Ну совсем off-topic...

ly ()
Ответ на: комментарий от ly

а можно получить эти тесты? именно набор скриптов.

alfss ()
Ответ на: комментарий от ly

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

т.е. только саппорт?

Ну совсем off-topic...

Ну это же LOR :-)

h4tr3d ★★★★★ ()
Ответ на: комментарий от ly

Достигнута предварительная договоренность с Егором Левинца об интеграции переведенных man-страниц, которые сейчас доступны на http://pro-ldap.ru/

ly ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.