Просмотр сообщений

В этом разделе можно просмотреть все сообщения, сделанные этим пользователем.


Темы - Леонид Юрьев

Страницы: [1]
1
Общий раздел / Голосуйте за ReOpenLDAP на "Positive Hack Days"
« : 07 Май 2019, 15:13:18 »
https://hackathon.phdays.com/

P.S.
Для голосования нужен аккаунт на github.

2
Общий раздел / ReOpenLDAP 1.1.7 "Red Army Soldier"(ReleaseCandidate)
« : 14 Февраль 2018, 23:08:19 »
Всем желающим предлагается потестировать релиз-кандидат.
https://github.com/leo-yuriev/ReOpenLDAP/releases/tag/v1.1.7-rc

Релиз версии 1.1.7 "Красноармеец" состоится 23 февраля 2018.

3
Общий раздел / ReOpenLDAP на LDAPCon 2017 в Брюсселе
« : 14 Август 2017, 16:22:11 »
Доклад о ReOpenLDAP принят в программу конференции LDAPCon 2017, которая пройдет 19-20 Октября в Брюсселе.
https://ldapcon.org/2017/

К сожалению, есть вероятность что я не смогу выступить на конференции.
Поэтому (на всякий случай) ищу человека, который сможет меня заменить.

4
Общий раздел / ReOpenLDAP 1.1.6 - рекомендуется (авторами) как замена OpenLDAP
« : 14 Август 2017, 16:07:27 »
Приветствую.

12 августа вышла версия 1.1.6 (более подробно см новость на OpenNet), которую предлагается использовать как стабильную замену всех версий OpenLDAP, включая 2.4.45.

5
Общий раздел / ReOpenLDAP-1.1.2 released
« : 30 Июль 2016, 23:39:45 »
Кратко:
  • Исправлено несколько ошибок сборки, которые были внесены при переходе на актуальные версии autoconf и automake.
  • Устранена ранее внесенная ошибка в механизме репликации.
  • Для configure реализованы дополнительные опции.
https://github.com/ReOpen/ReOpenLDAP/releases/tag/v1.1.2

6
Общий раздел / Сквозь тернии в МегаФон: ReOpenLDAP на конференции Highload++2016 в Сколково
« : 26 Июль 2016, 15:03:38 »
Москва, Сколково, 7-8 Ноября.

Уже два года длится наша битва с техническим долгом и проблемами исходного OpenLDAP. За последний год мы починили (переработали) механизм репликации и теперь всё больше приходим к выводу, что только ReOpenLDAP обеспечивает горячую синхронизацию по RFC4533 в мульти-мастер топологии, в объемах и с производительностью необходимыми для промышленной эксплуатации в инфраструктуре крупнейшего мобильного оператор России.

В докладе будут тезисно рассмотрены обнаруженные недостатки RFC4533, проблемы OpenLDAP и движка хранения LMDB, а также соответствующие доработки в ReOpenLDAP и MDBX.

Событие https://www.facebook.com/events/1066650220057553/
Заявка доклад http://www.highload.ru/2016/abstracts/2266.html

Новости проекта https://www.facebook.com/ReOpenLDAP
Исходный код https://github.com/ReOpen/ReOpenLDAP


7
Общий раздел / full-mesh multi-master репликация работает в ReOpenLDAP на 100% (и больше нигде)
« : 24 Март 2016, 22:15:17 »
Репликация/синхронизация починена, полностью. Плюс попутно ещё десяток-другой багов.
Пока не известны другие LDAP-сервера, репликация в которых 100% работоспособна в конфигурации full-mesh multi-master.

В драконовских тестах multi-master режима остался только один экстремальный сценарий, который изредка (с вероятностью 1/1000) подглючивает - это многократное циклическое добавление/удаление ограниченного набора DN-записей на фоне циклического развала-схождения full-mesh multi-master кластера из 4-х или более узлов (в графе связей должно быть два или более цикла разной длины). При этом на части узлов кластера может остаться одна-две удаленные записи.

Грубо говоря, если смотреть на версионные отметки, то add или modify после delete как-бы экранирует это удаление и увидеть его можно только сравнив local и remote базы поэлементно. Но это уже проблема не реализации, а самой идеи RFC4533.

В ReOpenLDAP с этим можно бороться двумя способами:
- включить limit-concurrent-refresh (см. man pages) = проблема не проявится.
- произвести развал-схождение кластера (перезапустить) = благодаря доработкам расхождение в данных будет устранено.

https://github.com/ReOpen/ReOpenLDAP/releases/tag/ReOpenLDAP-1.0-beta

8
Общий раздел / ReOpenLDAP - почти починили репликацию :)
« : 16 Январь 2016, 17:02:55 »
"Починили" - так как встроенные тесты теперь проходят 42 итерации при параллельном тестировании разных сборок в 4 сессии.
"Почти" - так как проблема расхождения экземпляров кластера по-прежнему может быть воспроизведена в некоторых жестких сценариях.

В сравнении с оригинальным OpenLDAP это просто супер-стабильное решение и мега-надежное решение:
- оригинальный openldap по-прежнему генерирует около 5000 предупреждений компилятора при сборке, из которых порядка 20 о реальных проблемах/ошибках.
- прогон тестов openldap с включенным ThreadSanitizer генерирует порядка 100 предупреждений о "гонках" между потоками.
- оригинальный openldap никогда не проходил более 10 итераций при параллельном тестировании, в среднем около 5.

Детали проблемы, которую "почти устранили" можно посмотреть здесь = https://github.com/ReOpen/ReOpenLDAP/issues/43#issuecomment-172208085
Эта ревизия помечена тегом "2016" = https://github.com/ReOpen/ReOpenLDAP/releases/tag/2016

Актуальная стабильная версия ReOpenLDAP всегда доступна в ветке master = https://github.com/ReOpen/ReOpenLDAP
Пояснения зачем мы занялись этим можно найти на wiki = https://github.com/ReOpen/ReOpenLDAP/wiki

9
Общий раздел / ReOpenLDAP на "12-й Конференции разработчиков свободных программ"
« : 12 Октябрь 2015, 08:27:30 »
ALT Linux проводить традиционную осеннюю тусовку.
Вход = СВОБОДНЫЙ.

В субботу, 17 октября, в 13:00.
http://www.altlinux.ru/news/item/743/

Тезисы моего выступления по теме ReOpenLDAP на 80% совпадают с http://www.highload.ru/2015/abstracts/1829.html

Народу будет не много, давки не будет точно.
Поэтому можно общаться, задать вопросы и т.д.

Подъезжайте.

10
Общий раздел / В ближайшую пятницу, 19 июня, доклад о ReOpenLDAP и LMDB на конференции DevConf
« : 18 Июнь 2015, 00:41:22 »
Регистрируйтесь, приходите, задавайте вопросы...
Мой доклад в 19:15 на "посошок", к этому времени думаю уже можно "с пивом" ;)
Страница регистрации: http://devconf.ru/ru/orders/add

Место проведения конференции:
Конгресс-центр Гостиницы Измайлово Бета.
105613, Москва, Измайловское шоссе, 71, корпус 2Б (станция метро "Партизанская").

Анонс доклада:
Lightning Memory-Mapped Database (LMDB) - представляет собой интересный, во многом уникальный, движок базы данных класса Berkeley DB / Level DB. Будучи относительно малоизвестным, LMDB показывает чемпионскую производительность по чтению и предлагает ряд компромиссов для достижения невероятной производительности по записи.

Так получилось, что мы сделали клон/fork исходного проекта и создали высокопроизводительное стабильное решение промышленного масштаба с открытым исходным кодом. Расскажу о внутреннем устройстве LMDB, о выявленных недостатках и наших доработках для их устранения.

Доклад точно будет интересен разработчикам, интересующимся "внутренностями" баз данных, а также специалистам, эксплуатирующим OpenLDAP в промышленном высоконагруженном масштабе: десятки миллионов записей, десятки тысяч запросов в секунду, геораспределенный кластер, многогигабайтные базы, 24x7.

LMDB был создан для использования внутри известного проекта OpenLDAP с открытым исходным кодом. Как разработчик и поставщик решений для «больших телекомов», компания «Петер-Сервис» решила задействовать связку OpenLDAP+LMDB в одном из своих проектов. Это был вход в кротовую нору, всё было как в сказке – чем дальше, тем страшнее...

Полный текст:
http://devconf.ru/ru/offers/offer/46

11
Общий раздел / ReOpenLDAP - новости стоящие внимания
« : 22 Май 2015, 18:09:34 »
Пока представляется более удобным и целесообразным публиковать новости по проекту здесь, нежели вести отдельный "сферический блог в вакууме".

Новости, тезисно:
  • Важная, принципиальная новость: Были устранены две большие недоделки связанные с согласованностью данных после системного сбоя при использовании LMDB-движка для хранения данных. Грубо говоря, мы сделали то, что в OpenLDAP посчитали невозможным, подробности см. ниже.
  • Принято решение сохранить поддержку только POSIX-совместимых платформ, с набором предоставляемых набор возможностей не хуже чем RedHad Enterprise Linux 6. Всё более старое или несовместимое, в том числе: Windows, SunOS, Solaris, старые версии *BSD - поддерживаться не будут.
  • В июне планируется оформить сборку пакетов (deb, rpm) для распространенных дистрибутивов Linux. Поддержки FreeBSD в виде порта/пакета не планируется (не найдено меинтейнера, готового взяться за работу).

Кратко о самом важном:
  • Обе недоделки были зафиксированны ранее в issues №1 и №2, сразу как только стало ясно, что их устранение в оригинальном OpenLDAP не возможно и для этого требуется клонировать исходный проект.
  • В оригинальном OpenLDAP первая недоделка считается feature (как-бы "не баг, а фича"), а вторая не актуальна, так как LIFO-reclaiming для LMDB есть только в ReOpenLDAP.
  • Переписав часть кода отвечающую за фиксацию изменений на диске, мы обеспечили гарантию согласованности данных (т.е. не разрушение всей базы при системном сбое, например из-за выключении питания), одновременно сохранив возможность компромисса между высокой производительностью по-записи и частотой фиксации изменений на диске.

Подробно:
  • Обе недоделки касаются внутренностей движка базы данных LMDB (aka Symas Lightning Memory-Mapped Database).
    • Исходная реализация LMDB обеспечивает целостность данных, но ориентирована на обеспечение чемпионской производительности по-чтению, а не по-записи.
    • Для гарантии согласованности (не разрушения базы) на диске, требовалась фиксация данных после каждой транзакции.
    • Проблема в том, что при большой нагрузке по-записи (десятки тысяч изменений в секунду) для этого требуется подсистема хранения с фантастической производительностью.
    • С технической точки зрения проблема известна как LMDB write-amplification.
    • Другими словами, даже минимальные изменения в базе данных, могут приводить к необходимости записи на диск относительно большого объема данных.
  • Поэтому, во многих случаях, для получения требуемой производительности приходилось отказываться от фиксации изменений после каждой транзакции:
    • Для этого в LMDB предусмотрены специальные режимы, управляемые опцией envflags: dbnosync, nometasync, writemap и mapasync (подробности см. в документации).
    • Не вдаваясь в детали, можно сказать, что суть всех этих режимов в отложенной фиксации изменений на диске.
    • С этой целью предлагается механизм периодического формирования "контрольных точек", конфигурируемый директивой checkpoint <kbyte> <min>.
  • Однако и тут не обошлось без нескольких "ведер дегтя":
    • Контрольные точки по задаваемому размеру изменений (параметр <kbyte>) в OpenLDAP не реализованы.
    • Периодические контрольные точки с задаваемым интервалом (параметр <min>) в OpenLDAP возможны только с гранулярностью в одну минуту, что полностью их обесценивает: при большой нагрузке за минуту будет огромный объем изменений, который не получится "быстро" записать на диск, и который одновременно слишком опасно потерять в случае сбоя.
    • Повторное использование (aka reclaiming) страниц базы данных выполняется в FIFO-порядке(тут была очепятка), что делает полностью неэффективным кеш обратной записи в системах хранения (дисковых массивах) промышленного уровня.
    • Кроме этого, в режимах writemap и mapasync согласованность данных не гарантируется даже в контрольных точках, так как операционная система может (имеет полное право) записать страницы с мета-данными раньше страниц данных.
  • Таким образом, исходный LMDB движок в OpenLDAP:
    • В реальности оказывается непригодным для промышленной эксплуатации в условиях высокой нагрузки по-записи.
    • Для устранения этих и многих других проблем мы и стартовали ReOpenLDAP как отдельный проект в начале 2015 года.
  • Сейчас в ReOpenLDAP:
    • 2014-Q3: Реализован возможность автоматического формирования контрольных точек как по объему изменений, так и периодически с гранулярностью до секунды. Что позволило использовать режимы dbnosync и mapasync с гораздо меньше вероятностью потери данных в случае системного сбоя.
    • 2014-Q4: Реализован, отлажен и проверен режим повторного использования (aka reclaiming) страниц базы данных в LIFO-порядке. Что позволило получить эффект от кэша обратной записи в развитых системах хранения, что дало прирост производительности в 10-50 раз (в некоторых сценариях до 100 и более раз). Реализованы механизмы oom-handler (поведение при исчерпании места в БД) и dreamcatcher (рестарт долгих операций чтения мешающих освобождению места).
    • 2015-Q1: Устранена масса проблем в механизме репликации при работе в multi-master режиме, в том числе несколько застарелых проблем с возрастом более 5 лет.
    • 2015-Q2: Реализованы возможности "кворума" при репликации, ограничение сеансов syncrepl в фазе refresh, что в разы снизило пиковое потребления механизмом репликации оперативной памяти и процессорного времени.
    • На днях устранены вышеописанные проблемы с согласованностью данных и добавлена утилита mdb_chk для максимально полной проверки структуры базы.
    • Таким образом, в ReOpenLDAP устранены все известные на текущий момент проблемы и недоработки, мешающие промышленной эксплуатации в условиях высоких нагрузок, как по-чтению, так и по-записи (но приемочные испытания перед "боевой работой" еще не завершены).

Технические детали доработок для обеспечения согласованности данных:
  • Чистка кода и прекращение поддержки:
    • В LMDB отброшена поддержка не-POSIX платформ, включая Windows.
    • Самой "старой" эталонной поддерживаемой платформой считается RedHad Enterprise Linux 6, требуется поддержка PTHREAD_PROCESS_SHARED и PTHREAD_MUTEX_ROBUST.
    • Ликвидирована поддержка нерелевантного режима работы, при котором разделение доступа обеспечивается приложением (выброшен флажок MDB_NOLOCK).
  • Полностью переработан (переписан код) путь сброса данных на диск:
    • Появилась возможность гарантировать последовательность (линерализуемость) обновлений мета-страниц относительно страниц с данными.
    • Теперь возможно полностью контролировать режим фиксации на диске каждой транзакции.
    • Гарантируется правильная работа на системах с багом без дополнительной потери производительности.
  • В meta-страницы добавлен признак о том, как данные были зафиксированы на диске - надежно (steady) или по-быстрому (weak):
    • При "быстрой" записи в режимах dbnosync, writemap и mapasync обновляемая meta-страница помечается "не-надежной" (weak).
    • При надежной записи сначала всегда полностью сохраняются страницы с данными, а затем обновляются и записывается meta-страница помечаемая "надежной" (steady).
    • Крайне важно, что этот порядок гарантируется всегда, в том числе и для режимом writemap и mapasync. Этим устраняется проблема №1.
  • Фиксация состояния базы и откат (rollback) потенциально несогласованных данных:
    • При штатном (не аварийном) закрытии базы, в контрольных точках, а также после каждой транзакции в "синхронных" режимах выполняется надежная фиксация всех изменений на диске.
    • При открытии базы происходит автоматический возврат к последней из надежно зафиксированных точек.
  • Повторное использование страниц и поведение при исчерпании доступных:
    • Переработка записей таблицы freeDB (aka reclaiming) не пересекает границу последней надежной фиксации данных. Этим устраняется проблема №2.
    • В ситуации исчерпания доступных страниц и наличия незафиксированных данных производится их надежная фиксация, что позволяет переработать "заблокированные" записи freeDB.
    • В ситуации исчерпания доступных страниц из-за их блокировки долгими операциями чтения, как и прежде, доступны oom-handler и dreamcatcher.

Как последние доработки меняют поведение:
  • В любом из "синхронных" режимов фиксации транзакций всё будет как раньше.
  • В процессе работы, при асинхронной записи (режимы dbnosync или mapasync) и ВЫКЛЮЧЕННЫХ checkpoint, внешне будет почти как раньше:
    • Никакой явной фиксации не будет, до тех пор пока не будут израсходованы доступные страницы.
    • Повторное использование страниц (aka reclaiming) "упрется" в последнюю надежную фиксацию и будет приостановлено.
    • При исчерпании доступных страниц будет сформирована надежная контрольная точка и повторное использование страниц продолжится до этой границы.
    • Так как асинхронная запись в общем случае будет выполняться ядром ОС, то в совокупности мы получим максимальную производительность по-записи с периодической гарантией согласованности данных на диске.
  • В процессе работы, при асинхронной записи (режимы dbnosync или mapasync) и ВКЛЮЧЕННЫХ checkpoint:
    • Согласно параметрам checkpoint будет выполняться надежная фиксация с гарантией согласованности данных на диске.
    • Плюс контрольные точки будут дополнительно формироваться при исчерпании доступных страниц, как описано выше.
  • По завершению работы, в режимах без синхронной записи (envflags: dbnosync или mapasync):
    • Если база будет закрыта штатно (без "срубания" или "падения" slapd, и без system wide failure), то гарантируется согласованность данных на диске.
    • Если же slapd будет "срублен" или "упадет", либо будет обще-системный сбой, то потеряются все изменения после последней надежной записи при формировании checkpoint или из-за исчерпания свободных страниц.

Актуальная версия доступна в ветке master на github.

12
Общий раздел / Мы подготовили релиз-кандидат ReOpenLDAP 2.4.41 «Christmas»
« : 10 Январь 2015, 02:25:15 »
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:

Страницы: [1]