12 августа вышла новая версия ReOpenLDAP — форка общеизвестного OpenLDAP, с устранением массы ошибок и ряда доработок для стабильной работы репликации.
Эта версия, в некотором смысле, является юбилейной — 3 года с момента инициации проекта (публичный форк появился чуть позже). Всё это время ReOpenLDAP работает 24x7 в инфраструктуре ПАО МегаФон, обеспечивая высоконагруженную обработку запросов в multi-master кластере с full-mesh репликацией.
30 июля вышла очередная стабильная версия 1.1.2 проекта ReOpenLDAP. Основные изменения:
Исправлена масса ошибок и недочетов, внесенных ранее при переходе на актуальные версии autoconf и automake. Этим завершен ряд доработок, необходимых для эффективного формирования пакетов «без костылей».
Сборка дополнительных (contributed) модулей интегрирована и включается посредством configure-опции --enable-contrib.
В configure также добавлены опции --enable-check, --enable-hipagut, --enable-valgrind и --enable-experimental.
Переработана система логирования. Опции configure --enable-debug и --enable-syslog теперь полностью независимы.
ReOpenLDAP, также известный как «TelcoLDAP» — это форк OpenLDAP для применения в телекоммуникационной индустрии, с исправлением массы ошибок и работающей репликацией в мульти-мастер топологии.
Проект реализован для применения в инфраструктуре ОАО МегаФон — крупнейшего в России оператора мобильной связи. Сейчас ReOpenLDAP работает по всей России и доступен для всех как OpenSource с лицензией AGPL.
ReOpenLDAP — форк общеизвестного OpenLDAP, созданный в начале 2015 года с целью получения функциональной работоспособности и стабильности, достаточных для высоконагруженной промышленной (коммерческой) эксплуатации.
Одним из важнейших требований при этом является возможность построения кластера из 4 (2+2) или более узлов. В свою очередь это требует стабильной работы механизма синхронизации (репликации) по RFC4533 в режиме multi-master для full mesh топологии.
Однако, оригинальный OpenLDAP неработоспособен в такой конфигурации, механизм репликации просто теряет часть изменений, а в некоторых случаях может удалить все данные. Более того, неизвестно ни одного другого сервера LDAP, который бы корректно реализовывал RFC4533 с поддержкой multi-master и с приемлемой для эксплуатации производительностью.
Проблемы в исходной реализации синхронизации/репликации были замечены в августе 2015, и почти 9 месяцев было потрачено на их устранение.
Теперь все известные проблемы устранены, а драконовские тесты уже несколько дней показывают только стабильные результаты.
Поэтому мы готовы заявить, что в нашем ReOpenLDAP репликация/синхронизация для multi-master полностью работает как положено. И похоже, что это единственный сервер, пригодный для высоконагруженной промышленной (коммерческой) эксплуатации, причём с открытым исходным кодом.
В ReOpenLDAP добавлена поддержка «кворума» при репликации и возможность ограничения syncrepl-сеансов, находящихся в стадии первоначальной синхронизации.
В итоге это уменьшает время синхронизации multimaster-кластера при старте, одновременно существенно уменьшая пиковое потребление ресурсов (оперативной памяти и процессорного времени).
Такая синхронизации, или иначе говоря сверка записей в локальной базе с удаленной стороной, происходит всегда для refreshOnly режима и вначале refreshAndPersist.
При этом механизм репликации syncrepl формирует и сверяет в памяти списки записей c удаленной стороны (через поставщика syncprov) и записей в локальной базе.
Соответственно, именно в этот момент времени можно наблюдать пиковое потребление памяти и процессорного времени.
В кластере, состоящим из нескольких серверов работающих в режиме multi-master репликации, первоначальная синхронизация может одновременно выполняться несколькими экземплярами syncrepl.
В этом случае потребление памяти и нагрузка на CPU могут быть в разы (10 и более раз) больше чем при штатной работе.
Проблема усугубляется тем, что при конкурентной первоначальной синхронизации каждый экземпляр syncrepl будет пытаться внести в локальную базу практически идентичные изменения.
Соответственно, суммарно только один экземпляр syncrepl отрабатывает эффективно, а остальные просто в холостую, при этом мешая друг-другу.
Особо это актуально при подключении к кластеру нового сервера с «пустой» базой.
Наши нагрузочные тесты показывают уменьшение потребление памяти в 2-5 раз и одновременно уменьшение времени синхронизации multimaster-кластера от 3 до 25 раз.
--
ReOpenLDAP — потомок общеизвестного OpenLDAP, но ориентирован на промышленную эксплуатацию в сфере телекоммуникаций (высокие нагрузки, высокая доступность, 24x7). Появился в результате консервативности целей родительского проекта, что выразилось в отказе меинтейнеров Symas Corp принимать изменения улучшающие качество кода и добавление новых возможностей.
Проект реализован силами компании Петер-Сервис R&D, резидента Сколково, для применения в телеком-проектах федерального масштаба.
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 с батарейкой). Для точности следует отметить, что «без батарейки» производительность повышается в результате компромисса, за счет более редкой фиксации данных на диск.
