Форум проекта Pro-LDAP.ru
Общие вопросы по LDAP => Общий раздел => Тема начата: Леонид Юрьев от 10 Январь 2015, 02:25:15
-
ReOpenLDAP (https://github.com/ReOpenLDAP) — это форк OpenLDAP, который стал ответом на отказ принимать исправления, улучшающие качество кода (было убрано порядка 5000 предупреждений) и добавления новых возможностей. Причиной отказа являлась консервативность исходных целей проекта OpenLDAP и позиция меинтейнеров (Symas Corp).
Эта версия базируется на кодовой базе готовящегося к выпуску OpenLDAP 2.4.41, куда изначально направлялись все наши исправления. Проект реализован силами компании Петер-Сервис (https://ru.wikipedia.org/wiki/%D0%9F%D0%B5%D1%82%D0%B5%D1%80-%D0%A1%D0%B5%D1%80%D0%B2%D0%B8%D1%81) (www.billing.ru (http://www.billing.ru)) для использования в телеком-проектах (http://www.billing.ru/news/746) федерального масштаба.
Главное качество этой версии — работа без падений и без отказов сервиса под высокой нагрузкой с репликацией в кластере, что ранее было невозможно. В частности, исправлено 8 heisenbugs, которые существовали годами, особенно в коде репликации и LMDB-движке (http://en.wikipedia.org/wiki/Lightning_Memory-Mapped_Database). Одному из багов (http://www.openldap.org/its/index.cgi/Software%20Bugs?id=5452) официально почти 7 лет ;)
Добавленные функции позволяют держать нагрузку по изменениям в 2-10 раз больше оригинального OpenLDAP и до 50 — при наличии у системы хранения write-back кэша (проще говоря, RAID с батарейкой). Для точности следует отметить, что «без батарейки» производительность повышается в результате компромисса, за счет более редкой фиксации данных на диск.
Подробности на github: - FAQ (https://github.com/ReOpen/ReOpenLDAP/wiki)
- Новые возможности и исправления (https://github.com/ReOpen/ReOpenLDAP/releases)
- Известные проблемы (https://github.com/ReOpen/ReOpenLDAP/issues) (все существуют в оригинальном OpenLDAP)
- Исходный код (архив этой RC-версии) (https://github.com/ReOpen/ReOpenLDAP/archive/ReOpenLDAP-2.4.41-rc.tar.gz)
-
Участники (переводчики) проекта Pro-LDAP.ru приглашаются к участию.
Мы заинтересованы в интеграции переведенных man-ов в ReOpenLDAP.
-
Здравствуйте, Леонид! Спасибо за пост. 50K записей в каталог в секунду -- это сильно =) .
Всегда прискорбно видеть, что из-за недопонимания между людьми ПО разделяется на два. Ховарда тоже можно понять -- наверняка у него десятки, а то и сотни обращений в день с "гениальными" улучшениями, а на отделения зёрен от плевел времени нет, особенно когда человек стал заниматься коммерцией.
Насколько я понял, Ваша компания кровно заинтересована в разрабоке высоконагруженных серверов, поэтому проект брошен не будет. Здорово, что решили поделиться наработками, надеюсь, кому-нибудь они пригодятся.
Разумеется, Вы всегда можете использовать в своём проекте наши переводы, тем более в этом году я планирую вплотную заняться именно man-страницами OpenLDAP, хотя стабильности в этом вопросе не обещаю -- для меня это всё-таки хобби, а не работа.
Егор Левинца
-
К сожалению, в программировании и развитии проекта Ховард придерживается "стиля старой школы", от которого все большие (и особенно успешные) проекты целенаправленно уходят последние лет 20-25. Лучшая иллюстрация этому - развития ядра Linux, а оборот "стиль старой школы" - тут очень дипломатично, скажем так.
В большом проекте ясность и прозрачность программного кода становится крайне важной, равно как и полноценное использование инструментов c методиками. Начиная от средств языка и компилятора для страховки от человеческих ошибок, заканчивая принципами Continuous Integration. Иначе learning curve становится неприемлемой, авторам становится труднее поддерживать проект, а новых разработчиков не приходит. Изменения и совершенствования становятся очень тяжелыми и баго-опасными, падает мотивация, накапливается технический долг (aka technical debt). Такие проекты либо осуществляют революцию (что дорого), либо обречены на постепенную консервацию и медленную смерть. Корифеи таких проектов нередко пытаются отрицать проблему, проявляя признаки психологической защиты.
Именно всё перечисленное мы наблюдаем в OpenLDAP:
- Факт: В багтрекере много ошибок вида "у нас засбоило, примерно вот таком случае", которые годами остаются в подвешенном состоянии.
- Факт: Много недоделанных, полу-заброшенных features - как например sql-бакенд.
- Факт: Изменений со стороны практически не поступает - их как-раз таки не сотни и не десятки, а единицы.
- IMHO: Качества кода оставляет желать лучшего, несчетное количество "карточных домиков" когда внешне безобидное изменение приводит к скрытым ошибкам.
Прошу понять, что я достаточно объективен, хотя есть и эмоциональная составляющая. Меня позвали спасать внутренний проект когда пришли к тупиковой ситуации - под нагрузкой (не целевой промышленной, а просто при циклических тестах) все официальные версии OpenLDAP работают не более нескольких часов, как правило 5-10 минут. После погружения в исходный код OpenLDAP я впал в facepalm. Приходится ассенизировать по производственной необходимости, что "доставляет".
На фоне вышесказанного, позиция Ховарда выглядит как попытка сохранить лицо и "мыши кололось, но продолжали есть кактус". Его ответы на замечания и комментарии в дискуссиях уже давно "широко известны в узких кругах", так сказать репутация заработана. Казалось-бы, тут можно поспорить с критикой, оттолкнувшись от тезиса "так оно же работает", но увы - наши опыты и официально найденные и признанные ошибки (по нашему списку ITS (https://github.com/ReOpen/ReOpenLDAP/releases), например c отсутствием volatile) показывают, что это скорее миф и удачное стечение обстоятельств "повезло, не сбойнуло".
По нашему убеждению, официальные релизы OpenLDAP и LMDB нельзя назвать production ready. В этом контексте вызывают озабоченность публичные заявления Ховарда и Symas. Грубо говоря, людей сознательно вводят в заблуждение. Насколько я понял, у нашего менеджмента есть намерение очень серьезно развенчать мифы Symas Corp о готовности, стабильности и вообще пригодности их продуктов для какой-либо промышленной эксплуатации, особенно сферы broadband-телекома (в инфраструктуре сетей мобильной связи на LDAP очень многое возложено). Хотя моя задача сейчас - как раз добиться этой декларируемой стабильности и работоспособности :)
-
Егор, еще раз приветствую.
Хотелось-бы обсудить интеграцию с вашими переводами.
Для адекватного процесса нам необходимо получать результат через git-репозиторий.
Соответственно, я предлагаю вам завести такой на github или еще где-нибудь.
Могу предложить завести репозиторий в https://github.com/ReOpen.
Как вариант, могу предложить gerrit (https://ru.wikipedia.org/wiki/Gerrit) на своем сервере для внутри-командного ревью изменений, но только для небольшой команды (скажем 5-10 человек, максимум 25).
Если переведенные руководства будут структурно оформлены в git, то станет возможным автоматическая генерация html-версии, а также использование переводов для дополнения официальной документации в дистрибутивах Linux. Думаю отечественные разработчики (РОСА, ALT и т.д.) будут заинтересованы.
Допускаю что подобный процесс у вас уже налажен, тогда мне нужны координаты.
-
Леонид, здравствуйте!
Мне кажется, что логичнее всего положить переводы man-страниц туда, где им и положено быть: в /doc/man/ru/ дистрибутива. Зачем заводить отдельное место?
Чтобы разобраться с git мне понадобится какое-то время. Если Вам нужно срочно, сами возьмите архив (http://pro-ldap.ru/tr/man/download.html) и положите страницы куда нужно, а я уже буду добавлять по мере появления новых переводов.
Маленькая тонкость: страницы уже "собраны", то есть в них присутствует версия и дата последнего релиза и "Acknowledgement Text", так что, возможно, их придётся немного подправить.
Егор
-
Егор, доброе утро.
"Отдельное место" только ради удобства управления изменениями.
Скорее всего вы будете заинтересованы в поддержке перевода оригинальной документации для 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).
Леонид.
-
Егор, приветствую.
Я включил man-страницы из доступного архива в наши исходные тексты и сборку.
https://github.com/ReOpen/ReOpenLDAP/tree/man-ru-2.4
Леонид.
-
Первый pull-request c переводом man-страницы ldif влит в ветку 2.4
Егор, большое спасибо.
-
Приветствую.
Как представитель команды разработчиков 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' логично задавать персонально для каждого суффикса/бэкенда.
- самый гибкий вариант - сделать две настройки "общую" для всех и "уточняющую для каждого суффикса/бэкенда", но (видимо) это может запутать пользователей?
- идеи и пожелания приветствуются.
Леонид.
-
Ок, будем считать, что молчание - знак согласия ;)
-
Продолжу информировать о ходе нашего проекта здесь на форуме, пока так просто удобнее.
После создания форка у нас была небольшая дилемма. Требовалось как-то "идейно" определиться с балансом/компромиссом между сохранением набора возможностей относительно родительского 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% повышение производительности.
Как и прежде идеи и пожелания приветствуются.
-
В ReOpenLDAP добавлена поддержка "кворума" при репликации, плюс внесено несколько доработок для обхода неоднозначных ситуаций при multi-master репликации.
Актуальная стабильная версия в ветке master на https://github.com/ReOpen/ReOpenLDAP.
Новая "фича" и опции её настройки описаны в русскоязычных man-страницах (пока только в русскоязычных), см. https://github.com/ReOpen/ReOpenLDAP/commit/1c94bc17ec285388e8a8299399ed537754fc3028
-
В 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
Леонид
-
Несколько дополнений к новости:
- Эта последняя версия, которую можно собрать для Windows.
- Ищется меинтейнер для *BSD платформ, иначе выпилим.
- Ищется волонтер для обратного перевода man-страниц и популяризации/продвижения проекта среди англоязычной аудитории.
-
Продолжаю сообщать о новостях и советоваться, точнее пытаюсь ;)
В ReOpenLDAP, как и в исходном OpenLDAP, до последнего времени не было какого-либо средства контроля LMDB-базы.
При этом НЕ важно что вероятность таких ошибок мала, и также НЕ столь важно что стало из причиной: программные ошибки в LMDB, slapd, драйвере диска или прошивки системы хранения.
Важно, что без средства контроля их не возможно своевременно обнаружить, а только "когда всё упало".
Дискуссии о необходимости контроля быстро заканчивают, как только становиться понятно что последствия придётся компенсировать за счет собственной зарплаты...
На днях возможность такого контроля была добавлена - теперь есть утилита mdb_chk.
Это решает массу проблем, но не достаточно для промышленной эксплуатации с учетом всех особенностей LMDB.
В LMDB есть три недочета, или проблемы если угодно:
- при включении writemap (без которого не обойтись при нагрузке по записи) база может быть повреждена, см. https://github.com/ReOpen/ReOpenLDAP/issues/1
- нет какого-либо контроля целостности отдельных содержания страниц, например контрольной суммы.
- нет надежного способа проверить консистентность базы (mdb_chk проверяет только целостность структуры, но не потерю изменений или искажение данных).
Самая актуальная проблема пожалуй первая, но устранение любой из трех ведет к потере совместимости с оригинальной версией LMDB из OpenLDAP.
--
Первая проблема будет устранена расширением списка атрибутов meta-страниц. Будет добавлен атрибут "datasync", ненулевое значение которого будет означать что мета-страница была зафиксирована правильным надежным образом - после записи всех страниц с данными. В противоположность этому, при быстрой фиксацией транзакций с последующей асинхронной дозаписью данных, datasync будет устанавливаться в ноль, а при повторной быстрой фиксации будет использоваться та же мета-страница. Полноценная "правильная" фиксация будет выполняться при формировании контрольных точек (параметр checkpoint для mdb) и при штатном (не аварийном) закрытии базы.
Далее, при открытии базы будут преимущественно выбираться безопасно зафиксированные страницы, с ненулевым datasync. Таким образом, после крушения всей системы (например при внезапном выключении питания), база данных будет открываться с точки гарантирующей консистентность всех данных. А мета-страницы "быстрой" фиксации будут использоваться фактически только во время работы нескольких процессов с одной базой.
Предположительно, файлы LMDB-базы созданные новой версией будут совместимы с оригинальной версией LMDB. Но при этом наша новая версия будет воспринимать старые файлы только как не небезопасные.
--
Вторая проблема будет устранена добавлением в заголовок каждой страницы контрольной сумму данных. К сожалению, это точно поломает совместимость с оригинальной версией LMDB, так как измениться формат заголовка и размер полезных данных страницы.
--
С третьей проблемой сложнее. У нас есть хорошее инженерное понимание как следует её устранять (см. http://en.wikipedia.org/wiki/Merkle_tree, кстати, git действует именно так). Но объем изменений программного кода при этом будет (предположительно) кардинальным. Поэтому пока представляется не рациональным "лечить" LMDB. Возможно что проще будет переписать как было задумано (см. https://github.com/ReOpen/ReOpenLDAP/issues/7)
--
Как обычно, конструктивная критика, пожелания и соображения - всё приветствуется.