Сообщения

1

Конфигурация через cn=config / Re: Как проверить состояние реплики?

« : 07 Август 2018, 15:02:32 »

Здравствуйте Леонид.
Мы, как раз, ваш ReOpenLDAP и используем.
Я тогда вас спрашивал по поводу WiredTiger и реплик.

Посмотрите в man-страницах (будут доступны после установки ReOpenLDAP) описание syncprov-showstatus для syncprov, и requirecheckpresent для syncrepl.

Спасибо - сейчас я туда посмотрю.

2

Конфигурация через cn=config / Как проверить состояние реплики?

« : 31 Июль 2018, 12:04:17 »

Такой вопрос. Сейчас у нас крутится реплика с 3 миллионами пользователей на двух серверах.
Возник вопрос контроля ее состояния с отдачей в заббикс.

Пока что нашли два варианта решения этой задачи:

1. На всех серверах, участвующих в реплике выполнять команду ldapsearch -x -H "ldap://reopenldap-m1" -D "cn=admin,cn=config" -w1wUZVgvCjT0V -b "dc=privatix,dc=net" -s base contextCSN
В выводе мы получаем, в том числе и строку - contextCSN: 20180731090040.366612Z#000000#001#000000
Если эти строки совпадают - то получаем валидность реплики. Если не совпадают - то не валидность.
Единственное, что - в скрипте сравнения нужно учитывать ответ, когда полностью лежит сам сервер ldap.

2. Ну тут ранний вариант. Просто снимать раз в сутки со всех участников реплики slapd-ом бекап и считать количество строк, содержащих dn, сравнивая их на двух серверах
Но, ИМХО, вариант очень плохой - из-за того, что в нем учитывается только количество записей. Да и нагружает сервера слегка.

Поэтому вопрос. Может быть есть еще какие-то методы контроля состояния реплики в openLDAP?

3

Конфигурация через cn=config / Re: wiredTiger и дополнительные настройки

« : 28 Март 2018, 12:58:34 »

Ну нам было бы интересно увидеть вашу систему с связке с wiredTiger движком.

4

Конфигурация через cn=config / Re: Вопрос по реплике/производительности

« : 28 Март 2018, 12:08:49 »

Спасибо за оперативный ответ.
Будем изучать документацию дальше.

Пока что на тесте решили проблему относительно реплики тюнингом файловой системы. Мы используем zfs. Достаточно оказалось выключить atime в делегированном датасете с базой и увеличить zfs_rec_size (он же ZFS Record Size) до максимального.
В принципе, то что догонялось в течении 3 суток оперативно вылилось за 10 часов, что нас устраивает.
Сейчас докинем третьего участника и будем сравнивать.

5

Конфигурация через cn=config / Re: Вопрос по реплике/производительности

« : 26 Март 2018, 10:44:57 »

Леонид, а подскажите такой практический вопрос.

С репликой все хорошо, она живая и не разваливается на огромных объемах.
Но обнаружили другой момент.
Юзаем ее для базы в размере 2590000 записей (два с половиной миллиона). В одиночную базу записывается достаточно быстро (там у нас импортируется скриптом) за 22-24 часа.
А вот потом дальнейшая синхронизация с другим сервером - первые миллиона полтора идут быстро.
А потом начинает скорость падать и падать до 400 записей за 5 минут.
И очень сильно растет нагрузка на жесткие диски.

Несмотря на виртуализацию, ресурсы выделены достаточные. Проц практически не нагружается.
Что бы вы могли посоветовать в данном вопросе?

6

Конфигурация через cn=config / Re: Вопрос по реплике/производительности

« : 11 Январь 2018, 13:46:38 »

Ну на тестах запустили. Будем смотреть сейчас на прокачку 200к записей в базу.
И еще такой момент подскажите - в гите, где у вас лежит ReOpenLDAP - там уже движок хранения mdbx? --enable-mdb включает его? Или нужны какие-то дополнительные действия по его интеграции?

Да, движок уже внутри https://github.com/leo-yuriev/ReOpenLDAP/tree/devel/libraries/libmdbx (вставлен посредством git subtee).

Да, --enable-mdb включает его.
В целом, по историческим причинам, mdbx внутри ReOpenLDAP виден как LMDB/mdb.
Дополнительные опции описаны в man-страницах.

На всякий уточню про wt-backend.
В своей версии (https://github.com/osstech-jp/openldap) японцы много чего доледали/исправили.
Поэтому она гораздо более работоспособна чем оригинальный OpenLDAP.
Тем не менее, они доработаювают только wt-backend.
Соответственно все баги в самом OpenLDAP остались как есть.
Предполагаю что проблемы с репликацией у вас именно из-за них.

Я предложил им влиться в ReOpenLDAP (https://github.com/osstech-jp/openldap/issues/6), но пока молчат.
Тем не менее, я думаю взять все их доработки wt-бэкенда в ReOpenLDAP.

По wt-backend было бы прикольно. Не зря же его монго взяло, как базовый.
И еще раз огромное спасибо за оперативные ответы.

Реплика на 200к прошла без проблем. Единственное, в логи постоянно валится syncrepl_process: rid=003 (-45) Unknown API error
по которому я пока информацию найти не смог. ( Но думаю - это дело наживное.

7

Конфигурация через cn=config / Re: Вопрос по реплике/производительности

« : 10 Январь 2018, 20:25:16 »

> Если вы используете OpenLDAP версии 2.4.38 или выше, то репликация там более-менее отлажена

Если вы используете OpenLDAP версии 2.4.38 или выше, то репликация там более-менее отлажена (по крайней мере с mdb), в прежних версиях были проблемы. Вообще, я попрошу Леонида Юрьева посмотреть Ваш вопрос, возможно, он что-то подскажет (у него большой опыт борьбы с репликацией =) ) .

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

1) Про репликацию.
Ни в одной из версий OpenLDAP репликация полноценно не работает. Причем чем старее версия, тем страшнее баги...
С multi-master (aka n-way) у OpenLDAP есть несколько принципиальных проблем.
Кратко они перечислены и пояснены на слайдах https://ldapcon.org/2017/reopenldap/
Еще пару раз пояснял тут и на linux.org.ru. Если будут конкретный вопросы, то могу ответить.
Обращаю внимание - в OpenLDAP может случится массивное удаление данных, вплоть до полной вычисти всего replication scope!!!
Короче, если нужен multi-master, то только ReOpenLDAP.

2) Про WiredTiger backend.
Он экспериментальный и точно не готов для использования, также как и SQL-backend.
Там достаточно ошибок и недочетов: использование не-инициализированных данных, игнорирование или неверная обработка ошибок и т.д.
Если у вас есть какие-то веские причины использовать wt, то нужно брать ReOpenLDAP и добиваться работы всех тестов в нагрузочно-паралельном режиме (например посредством https://github.com/leo-yuriev/ReOpenLDAP/blob/devel/build/ci/buzz.sh).
Кроме этого, я могу дать скрипты для нагрузочной проверки multi-master репликации.
Если же вы не готовы приложить описанные усилия, то не морочьте голову и переключайтесь на MDBX (mdb) в ReOpenLDAP.

На всякий - на мой взгляд у WiredTiger нет никаких преимуществ перед https://github.com/leo-yuriev/libmdbx для LDAP-сценариев.

Ну на тестах запустили. Будем смотреть сейчас на прокачку 200к записей в базу.
И еще такой момент подскажите - в гите, где у вас лежит ReOpenLDAP - там уже движок хранения mdbx? --enable-mdb включает его? Или нужны какие-то дополнительные действия по его интеграции?

8

Конфигурация через cn=config / Re: Вопрос по реплике/производительности

« : 10 Январь 2018, 14:55:23 »

Леонид, спасибо за оперативный ответ.
Подскажите, у вас сборка пакетов стандартная? Т.е. нет никаких подводных камней или спец.опций, не изложенных в доке?

9

Конфигурация через cn=config / Re: wiredTiger и дополнительные настройки

« : 10 Январь 2018, 11:38:08 »

http://source.wiredtiger.com/2.9.3/group__wt.html#ga9e6adae3fc6964ef837a62795c7840ed
Собственно вот тут описаны основные настройки этого бекенда. Если у кого-то возникнет желание копать дальше.

10

Конфигурация через cn=config / Re: Вопрос по реплике/производительности

« : 10 Январь 2018, 11:36:00 »

Т.е. это процентов на 99% проблема в wt, как в бекенде? Т.е. это не может быть какая-то проблема в самой лдап или в его библиотеке синхронизации?

11

Конфигурация через cn=config / Вопрос по реплике/производительности

« : 09 Январь 2018, 19:05:55 »

Добрый день.
Наблюдаю проблему с openLDAP следующего характера.
Есть некоторый скрипт, который создает пользователей в базу. База настроена на wt. И она же реплицируется на соседний такой-же сервер.
Репликация n-way master. Все отлично, все работает, пользователи реплицируются.
Но, в один прекрастный момент, когда записано более 60к пользователей - реплика останавливается. Причем без каких-то криминальных записей в логах.
Запись на первый сервер продолжается.
После его перезагрузки - получатель продолжает догонять поставщика. Иногда ldapsearch достучаться можно. Иногда нет.
Подскажите, в какую сторону копать?

12

Конфигурация через cn=config / Re: wiredTiger и дополнительные настройки

« : 21 Ноябрь 2017, 14:14:21 »

Нашел ответ на свой вопрос.

нужно изменить в файле WiredTiger.basecfg над строкой version=(major=2,minor=9) добавить log=(enabled=false)
cache_size=1000M

Цитирую из своего же мана небольшого.

13

Конфигурация через cn=config / wiredTiger и дополнительные настройки

« : 19 Октябрь 2017, 19:18:27 »

Добрый день, уважаемые коллеги.
Решили применить у себя в openLDAP движок wiredTiger, отталкиваясь от документации с гитхаба авторов.
Движок развернулся, все работает на тесте.
Но у товарищей есть целый ряд параметров - особенно интересует wtconfig log=(enabled=false)
Если использовать slapd.conf, прописав туда эти параметры - то видно, что параметр загружен.

59e8ceda slapd.conf: line 56 (wtconfig log=(enabled=false))

Однако, если использовать не slapd.conf, а cn=config - то возникают вопросы.
Через манипуляцию с ldapmodify - непонятно что писать в ldif.
Если сделать нормальную настройку slapd.config и запустить на ней, а потом переконвертировать файл - то в полученном файле olcDatabase={1}wt.ldif нет никаких указаний про этот параметр.
Может кто-то сталкивался или даст какие-то советы-рекомендации?