> Я перед тем, как написать, прочитал такое:
> Коротко говоря: AD - это база данных служб каталогов, а LDAP -
> один из протоколов, которые вы можете использовать для общения с ней.
> LDAP - это протокол, а Active Directory - это сервер.

Не то чтобы врут, но искажают.

Чуть раньше Novell взяла LDAP, напихала туда фичей и собственных велосипедов, а потом назвала "Novell Directory Service".

В M$ испугались что "мопед не их", напихала туда-же еще большую кучу несовместимых велосипедов, придумали массу оголтелой виндовой специфики и назвали это Active Directory.
Потом еще 20 лет латали, скрещивали с Kerberos, чинили и переделывали весь этот кошмар.

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

Упрощенно LDAP + маркетинг = Active Directory.

> У нас 6 мастер-мастер OpenLDAP разбросанный по всему миру (разные регионы). Трафик
> конечно не 10К апдейтов в секунду, но где-то чуть меньше половины.
> Собираем метрики, есть мониторинг - каких либо крупных проблем не наблюдаем.
> У вас есть пошаговая инструкция как воспроизвести эту проблему?

Как уже отвечал где-то рядом - достаточно зациклить собственные тесты OpenLDAP, которые тестируют репликацию.
Желательно на сильно загруженной машине.

Использовавшийся сценарий для проверки _примерно_ такой:
- на машине настраивается четыре local-interface, например 10.{1,2,3,4}.0.0.1/24
- конфигурируется full-mesh мультмастер кластер из 4-х инстанции slapd, т.е. у каждого slapd по 3 штуки syncprov и syncrepl к другим;
- все syncprov и syncrepl настраиваются так, чтобы работали через соответствующие local-интерфейсы, т.е. получает что каждый slapd "сидит" в своем сегменте 10.{1,2,3,4}.0.0.1/24;
- кроме этого каждый slapd слушает свой порт на 0.0.0.0;
- запускается питоновский скрипт, который стохастически начинает одновременно создавать/изменять/удалять записи через подключения ко всем четырем сервера (но при этом изменения не конфликтуют между собой);
- этот-же питоновский скрипт проверяет что данные соответствуют ожидаемым (можно создать, удалить, изменить и т.п.)
- запускается еще набор скриптов, который через iptables стохастически временно рвет syncprov-syncrepl соединения между узлами.
- оставляем "на ночь", утром проверяем что не упало и DIT на всех узлах совпадает.
- повторяем с ASAN и затем с Valgrind...

Если вы готовы разбираться со скриптами, то я наверное смогу их отыскать.

В OpenLDAP достаточно быстро всплывали ошибки:
- race conditions, use-after-free и всяческие падения в десятках мест;
- зацикливания и зависания;
- утечки памяти;
- воскрешение удаленных записей;
- удаление недавно добавленных и/или обновленных;

Удаление части replication scope более редкая ошибка, но внимательно прочитав RFC можно примерно догадаться когда и почему она происходит.

> У нас 6 мастер-мастер OpenLDAP разбросанный по всему миру (разные регионы). Трафик
> конечно не 10К апдейтов в секунду, но где-то чуть меньше половины.
> Собираем метрики, есть мониторинг - каких либо крупных проблем не наблюдаем.
> У вас есть пошаговая инструкция как воспроизвести эту проблему?

На всякий, может пригодится https://ldapcon.org/2017/wp-content/uploads/2017/08/1_ReOpen...