Автор Тема: Мы подготовили релиз-кандидат ReOpenLDAP 2.4.41 «Christmas»  (Прочитано 39949 раз)

Леонид Юрьев

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

Эта версия базируется на кодовой базе готовящегося к выпуску OpenLDAP 2.4.41, куда изначально направлялись все наши исправления. Проект реализован силами компании Петер-Сервис (www.billing.ru) для использования в телеком-проектах федерального масштаба.

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

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

Подробности на github:
« Последнее редактирование: 11 Январь 2015, 07:13:26 от Леонид Юрьев »

Леонид Юрьев

  • Новичок
  • *
  • Сообщений: 46
    • Просмотр профиля
Участники (переводчики) проекта Pro-LDAP.ru приглашаются к участию.
Мы заинтересованы в интеграции переведенных man-ов в ReOpenLDAP.

egor

  • Администратор
  • Старожил
  • *****
  • Сообщений: 456
    • Просмотр профиля
Здравствуйте, Леонид! Спасибо за пост. 50K записей в каталог в секунду -- это сильно =) .

Всегда прискорбно видеть, что из-за недопонимания между людьми ПО разделяется на два. Ховарда тоже можно понять -- наверняка у него десятки, а то и сотни обращений в день с "гениальными" улучшениями, а на отделения зёрен от плевел времени нет, особенно когда человек стал заниматься коммерцией.

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

Разумеется, Вы всегда можете использовать в своём проекте наши переводы, тем более в этом году я планирую вплотную заняться именно man-страницами OpenLDAP, хотя стабильности в этом вопросе не обещаю -- для меня это всё-таки хобби, а не работа.

Егор Левинца

Леонид Юрьев

  • Новичок
  • *
  • Сообщений: 46
    • Просмотр профиля
К сожалению, в программировании и развитии проекта Ховард придерживается "стиля старой школы", от которого все большие (и особенно успешные) проекты целенаправленно уходят последние лет 20-25. Лучшая иллюстрация этому - развития ядра Linux, а оборот "стиль старой школы" - тут очень дипломатично, скажем так.

В большом проекте ясность и прозрачность программного кода становится крайне важной, равно как и полноценное использование инструментов c методиками. Начиная от средств языка и компилятора для страховки от человеческих ошибок, заканчивая принципами Continuous Integration. Иначе learning curve становится неприемлемой, авторам становится труднее поддерживать проект, а новых разработчиков не приходит. Изменения и совершенствования становятся очень тяжелыми и баго-опасными, падает мотивация, накапливается технический долг (aka technical debt). Такие проекты либо осуществляют революцию (что дорого), либо обречены на постепенную консервацию и медленную смерть. Корифеи таких проектов нередко пытаются отрицать проблему, проявляя признаки психологической защиты.

Именно всё перечисленное мы наблюдаем в OpenLDAP:
  • Факт: В багтрекере много ошибок вида "у нас засбоило, примерно вот таком случае", которые годами остаются в подвешенном состоянии.
  • Факт: Много недоделанных, полу-заброшенных features - как например sql-бакенд.
  • Факт: Изменений со стороны практически не поступает - их как-раз таки не сотни и не десятки, а единицы.
  • IMHO: Качества кода оставляет желать лучшего, несчетное количество "карточных домиков" когда внешне безобидное изменение приводит к скрытым ошибкам.

Прошу понять, что я достаточно объективен, хотя есть и эмоциональная составляющая. Меня позвали спасать внутренний проект когда пришли к тупиковой ситуации - под нагрузкой (не целевой промышленной, а просто при циклических тестах) все официальные версии OpenLDAP работают не более нескольких часов, как правило 5-10 минут. После погружения в исходный код OpenLDAP я впал в facepalm. Приходится ассенизировать по производственной необходимости, что "доставляет".

На фоне вышесказанного, позиция Ховарда выглядит как попытка сохранить лицо и "мыши кололось, но продолжали есть кактус". Его ответы на замечания и комментарии в дискуссиях уже давно "широко известны в узких кругах", так сказать репутация заработана. Казалось-бы, тут можно поспорить с критикой, оттолкнувшись от тезиса "так оно же работает", но увы - наши опыты и официально найденные и признанные ошибки (по нашему списку ITS, например c отсутствием volatile) показывают, что это скорее миф и удачное стечение обстоятельств "повезло, не сбойнуло".

По нашему убеждению, официальные релизы OpenLDAP и LMDB нельзя назвать production ready. В этом контексте вызывают озабоченность публичные заявления Ховарда и Symas. Грубо говоря, людей сознательно вводят в заблуждение. Насколько я понял, у нашего менеджмента есть намерение очень серьезно развенчать мифы Symas Corp о готовности, стабильности и вообще пригодности их продуктов для какой-либо промышленной эксплуатации, особенно сферы broadband-телекома (в инфраструктуре сетей мобильной связи на LDAP очень многое возложено). Хотя моя задача сейчас - как раз добиться этой декларируемой стабильности и работоспособности :)

Леонид Юрьев

  • Новичок
  • *
  • Сообщений: 46
    • Просмотр профиля
Егор, еще раз приветствую.

Хотелось-бы обсудить интеграцию с вашими переводами.
Для адекватного процесса нам необходимо получать результат через git-репозиторий.

Соответственно, я предлагаю вам завести такой на github или еще где-нибудь.
Могу предложить завести репозиторий в https://github.com/ReOpen.
Как вариант, могу предложить gerrit на своем сервере для внутри-командного ревью изменений, но только для небольшой команды (скажем 5-10 человек, максимум 25).

Если переведенные руководства будут структурно оформлены в git, то станет возможным автоматическая генерация html-версии, а также использование переводов для дополнения официальной документации в дистрибутивах Linux. Думаю отечественные разработчики (РОСА, ALT и т.д.) будут заинтересованы.

Допускаю что подобный процесс у вас уже налажен, тогда мне нужны координаты.

egor

  • Администратор
  • Старожил
  • *****
  • Сообщений: 456
    • Просмотр профиля
Леонид, здравствуйте!

Мне кажется, что логичнее всего положить переводы man-страниц туда, где им и положено быть: в /doc/man/ru/ дистрибутива. Зачем заводить отдельное место?

Чтобы разобраться с git мне понадобится какое-то время. Если Вам нужно срочно, сами возьмите архив и положите страницы куда нужно, а я уже буду добавлять по мере появления новых переводов.

Маленькая тонкость: страницы уже "собраны", то есть в них присутствует версия и дата последнего релиза и "Acknowledgement Text", так что, возможно, их придётся немного подправить.

Егор

Леонид Юрьев

  • Новичок
  • *
  • Сообщений: 46
    • Просмотр профиля
Егор, доброе утро.

"Отдельное место" только ради удобства управления изменениями.

Скорее всего вы будете заинтересованы в поддержке перевода оригинальной документации для OpenLDAP, без каких-либо добавлений наших фичей.
Нам же требуется обогатить оригинальное содержимое описанием наших нововведений и доработок, см https://github.com/ReOpen/ReOpenLDAP/releases.
Для решения подобных проблем есть http://habrahabr.ru/post/106912/, там же становиться понятно "почему git", а не svn.

Также необходимо отслеживать все изменения и синхронизировать их с доработкой программного кода.
Поддерживать документацию для линейки версий 2.4 и 2.5 (скоро обещают релиз).
Соответственно, чтобы результат вашей работы можно были отделять от наших правок man-страницы необходимо поместить в отдельную ветку (branch), а дальше действовать в соответствии с git branching model.

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

Поэтому это должен быть самостоятельный репозиторий (отдельная копия), в котором вы полностью хозяйничаете сами (я могу вам помогать если будут трудности с git).
А изменения от вас мы будем получать через pull request, см http://habrahabr.ru/post/125999/

Ну и нам конечно нужны "не собранные" страницы, чтобы получать актуальные версии со всеми отметками по make install.

Итого, предлагаю вам список ближайших шагов:
  • Зарегистрироваться на github
  • Сделать в своем аккаунте fork нашего https://github.com/ReOpen/ReOpenLDAP
  • Завести отдельную ветку и залить в ней все исходные man-страницы
  • Направить pull request

Готов помочь если что-то непонятно, но чтобы не спамить на форуме напишите мне на leo@yuriev.ru

И на всякий случай - в git лекго пролучить список изменений для отдельного файла или каталога после какой-либо версии или даты (например чтобы узнать что по шагам менялось в оригинальной документации после релиза 2.4.40). Аналогично легко сравнить две ветки или версии (например чтобы увидеть разницу между 2.4 и 2.5).

Леонид.


Леонид Юрьев

  • Новичок
  • *
  • Сообщений: 46
    • Просмотр профиля
Егор, приветствую.

Я включил man-страницы из доступного архива в наши исходные тексты и сборку.
https://github.com/ReOpen/ReOpenLDAP/tree/man-ru-2.4

Леонид.

Леонид Юрьев

  • Новичок
  • *
  • Сообщений: 46
    • Просмотр профиля
Первый pull-request c переводом man-страницы ldif влит в ветку 2.4

Егор, большое спасибо.

Леонид Юрьев

  • Новичок
  • *
  • Сообщений: 46
    • Просмотр профиля
Развитие ReOpenLDAP
« Ответ #9 : 30 Январь 2015, 14:32:01 »
Приветствую.

Как представитель команды разработчиков 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' логично задавать персонально для каждого суффикса/бэкенда.
- самый гибкий вариант - сделать две настройки "общую" для всех и "уточняющую для каждого суффикса/бэкенда", но (видимо) это может запутать пользователей?
- идеи и пожелания приветствуются.

Леонид.

Леонид Юрьев

  • Новичок
  • *
  • Сообщений: 46
    • Просмотр профиля
Re: Развитие ReOpenLDAP
« Ответ #10 : 09 Февраль 2015, 14:20:35 »
Ок, будем считать, что молчание - знак согласия ;)
« Последнее редактирование: 13 Февраль 2015, 19:36:00 от Леонид Юрьев »

Леонид Юрьев

  • Новичок
  • *
  • Сообщений: 46
    • Просмотр профиля
Развитие ReOpenLDAP
« Ответ #11 : 13 Февраль 2015, 20:52:06 »
Продолжу информировать о ходе нашего проекта здесь на форуме, пока так просто удобнее.

После создания форка у нас была небольшая дилемма. Требовалось как-то "идейно" определиться с балансом/компромиссом между сохранением набора возможностей относительно родительского OpenLDAP и обеспечением качества/стабильности.
Суть проблемы в том, что крайне сложно обеспечить тестирование всех возможностей OpenLDAP, всех комбинаций наложений (оверлеев) и механизмов манипуляции данными (бакендов).
Если поддерживать весь спектр аппаратных платформ и операционных систем, на которых (теоретически) может работать OpenLDAP, то проблема существенно усугубляется.

С одной стороны, в оригинальном OpenLDAP, декларируется поддержка всего этого "зоопарка". С другой стороны, от меинтейнеров OpenLDAP не удалось получить какого-либо конкретного списка платформ, операционных систем и компиляторов, с которыми производится тестирование или хотя-бы сборка проекта.
По сообщениям в списке рассылке, точнее по обращениям за помощью из-за проблем и сбоев, можно сделать выводы о том, что текущая версия OpenLDAP может гарантированно успешно эксплуатироваться только на 64-битных Linux системах, а также на 64-битных версиях Windows при сборке с помощью 64-битной версии MinGW. Работа на 32-битных системах возможна с ограничениями, например без LMDB. Есть проблемы совместимости с OSX и т.д.

Нам нужно было хорошо подумать и принять решение — что поддерживать и тестировать, а что точно вычеркнуть. На этой неделе мы пришли к идее такого решения с учетом наших возможностей и собственных целей. Точнее говоря, мы выработали принцип, по которому будем «отрезать».
Итак, ReOpenLDAP будет ориентирован на промышленную эксплуатацию в сфере телекоммуникаций (высокие нагрузки, высокая доступность, стабильность, 24x7). Соответственно:
  • Будет ликвидирована поддержка (ReOpenLDAP точно не будет даже собираться): ОС Windows, OSX и устаревших клонов Unix, компиляторов не совместимых с gcc и clang.
  • Будет ограниченна поддержка (ReOpenLDAP вероятно можно будет собрать, но какого-либо тестирования мы проводить не будем): 32-битные платформ, FreeBSD и прочих BSD-клонов, как минимум пока не найдется меинтейнер.
  • Будут удалены возможности, которые в родительском OpenLDAP считаются плохо поддерживаемыми, экспериментальными и/или нестабильными: dnssrv, sql, ndb (mysql cluster).
  • Возможно будут удалены возможности, которые сложно тестировать (обеспечить качество), либо которые редко затребованы (вопрос требует изучения): perl/shell, rwm (rewrite), chain, pcache, translucent, relay.
  • Возможности linux и gcc/clang будут использовать более полно. Например, точно будет сборка с использование LTO (link time optimization), что дает на 10% меньший размер кода и на 5-10% повышение производительности.

Как и прежде идеи и пожелания приветствуются.
« Последнее редактирование: 13 Февраль 2015, 21:06:36 от Леонид Юрьев »

Леонид Юрьев

  • Новичок
  • *
  • Сообщений: 46
    • Просмотр профиля
В ReOpenLDAP добавлена поддержка "кворума" при репликации, плюс внесено несколько доработок для обхода неоднозначных ситуаций при multi-master репликации.

Актуальная стабильная версия в ветке master на https://github.com/ReOpen/ReOpenLDAP.

Новая "фича" и опции её настройки описаны в русскоязычных man-страницах (пока только в русскоязычных), см. https://github.com/ReOpen/ReOpenLDAP/commit/1c94bc17ec285388e8a8299399ed537754fc3028
« Последнее редактирование: 29 Апрель 2015, 07:39:31 от Леонид Юрьев »

Леонид Юрьев

  • Новичок
  • *
  • Сообщений: 46
    • Просмотр профиля
В ReOpenLDAP добавлена возможность ограничения synrepl-сеансов, находящихся в стадии первоначальной синхронизации.
В итоге это уменьшает время синхронизации кластера при старте, одновременно существенно уменьшая пиковое потребление ресурсов (оперативной памяти и процессорного времени).

--

Такая синхронизации, или иначе говоря сверка записей в локальной базе с удаленной стороной, происходит всегда для refreshOnly режима и вначале refreshAndPersist.
При этом syncrepl формирует и сверяет в памяти списки записей c удаленной стороны (через поставщика syncprov) и записей в локальной базе.
Соответственно, именно в этот момент времени можно наблюдать пиковое потребление памяти и процессорного времени.

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

Проблема усугубляется тем, что при конкурентной первоначальной синхронизации каждый экземпляр syncrepl будет пытаться внести в локальную базу практически идентичные изменения.
Соответственно, суммарно только один экземпляр syncrepl отрабатывает эффективно, а остальные просто в холостую, при этом мешая друг-другу.
Особо это актуально при подключении к кластеру нового сервера с "пустой" базой.

Наши нагрузочные тесты показывают уменьшение потребление памяти в 2-5 раз и одновременно уменьшение времени синхронизации multimaster-кластера от 3 до 25 раз.

--

Актуальная стабильная версия в ветке master на https://github.com/ReOpen/ReOpenLDAP.

Новая "фича" и опции её настройки описаны в русскоязычных man-страницах (пока только в русскоязычных), см. https://github.com/ReOpen/ReOpenLDAP/commit/4d9505532f8ac6f294ae780e33c4f495fd06b7d0

Леонид
« Последнее редактирование: 07 Май 2015, 18:02:04 от Леонид Юрьев »

Леонид Юрьев

  • Новичок
  • *
  • Сообщений: 46
    • Просмотр профиля
Несколько дополнений к новости:

  • Эта последняя версия, которую можно собрать для Windows.
  • Ищется меинтейнер для *BSD платформ, иначе выпилим.
  • Ищется волонтер для обратного перевода man-страниц и популяризации/продвижения проекта среди англоязычной аудитории.