Репликация LDAP

[gto]

У вас на все филиалы одна подсеть? Рисковый вы человек.

[misha8282]

не на всех )))
это ж для примера.
сети могут быть и разные

на практике у меня главный 192.168.1.1 и два 192.168.2.1 и 192.168.5.1
у каждого своя подсеть

[gto]

Тогда, конечно, понятно. Еще такой вопрос, как проверяете консистентность нод?

[misha8282]

если вы про согласованность данных и их целостность, то при стабильной связи синхронизация происходит нормально. способ синхронизации — постоянное соеднинение. если оно пропадает то при появлении синхронизауия происходит штатно.
если вы об этом спрашивали.

[gto]

Меня больше интересовал вопрос идентичности данных. Проще говоря, как проверяете, что базы одинаковые в определённый момент времени?

[misha8282]

при устойчвой связи, после нажатия кнопки ПРИНЯТЬ в GQ(ldap клиент) информация распространяется мгновенно.

[misha8282]

базы одинаковые сразу же после синхронизации

[gto]

Тогда повторюсь, рисковый вы человек, так доверять сервису. Мы вот себе проверялки на contextCSN поставили. Потому как были неприятные случаи.

[misha8282]

вы про то что бы добавить в файл contextCSN?
для использовагия метки времени

[misha8282]

contextCSN
syncprov-checkpoint 10 10

# сохранение каждые 10 обновлений или каждые 10 минут

[gto]

Нет, я про то, чтобы contextCSN переодически проверять на всех машинах.

[misha8282]

contextCSN
syncprov-checkpoint 10 10

доабвить на всех машинах

[kelevra]

тоже мучался от парнойи на тему идентичности данных, поэтому рядом со всеми ldap серверами стоит костыль из ldapsearch | sort | diff — перезапускает slapd, если содержимое различается. помогает отловить негодяев, которые решили писать в slapd, не являющийся мастером. а вот при штатной эксплуатации проблем ни разу не возникало, хотя каналы связи довольно стабильные.

[gto]

На любой стабильный канал найдётся безопасник с фаерволом и большим количеством свободного времени

[misha8282]

ну это уже частности. где то есть безопасники, где то их нет.

[gto]

Это для примера, просто были случаи когда репликация отваливалсь, а замечали это только после жалобы пользователей. Поэтому и поставили дополнительные проверялки на contextCSN.

[shtirlitsus]

reopenldap не смотрели? намного стабильней

[misha8282]

не смотрел.

[misha8282]

я так понимаю это промышленное решение? у меня нет адских нагрузок на сервер. поэтому пока использщую openldap

[kelevra]

молодец, что разобрался, но статья получилась не очень. для мультимастерной репликации весь конфиг принято хранить в slapd.d, для того, чтобы при его изменении не перелопачивать все сервера. синхронизируется он так же с помощью syncprov, но работать с ним, разумеется, сложнее, чем с текстовым конфигом. например, можно прострелить себе ногу, отключив этот самый оверлей. причём ноги, в этом случае, будут прострелены сразу у всех серверов :)

к слову, в данной архитектуре, можно сделать мастерами лишь часть серверов. для этого достаточно, чтобы в списке мастеров были прописаны только те, серера, с которых нужно забирать изменения. такая схема позволяет держать свой slapd практически на каждом сервере или виртуалке, который должен использовать ldap, не нагружая мастеров.

ну и, если уж до конца придираться, то статье не хватает оформления.

[Sleuthhound]

Было бы очень интересно и полезно, если бы автор рассказал как проверять статус репликации и отлаживать это дело. Потому как у меня на 2 серверах по вашей методике репликация не заработала и куда смотреть в чем дело непонятно :(

Единственное что я знаю это на одном сервере

# ldapsearch -z1 -LLLQY EXTERNAL -H ldapi:/// -s base contextCSN
dn: dc=office,dc=myorg,dc=ru
contextCSN: 20110218080539.685470Z#000000#000#000000
contextCSN: 20151112195135.967095Z#000000#001#000000
contextCSN: 20111130074952.286378Z#000000#002#000000

на другом

# ldapsearch -z1 -LLLQY EXTERNAL -H ldapi:/// -s base contextCSN
dn: dc=office,dc=myorg,dc=ru
contextCSN: 20110218080539.685470Z#000000#000#000000
contextCSN: 20151112183400.865998Z#000000#001#000000
contextCSN: 20111130074952.286378Z#000000#002#000000

как видно строки разные, но а дальше то что?

[misha8282]

если вы не против, то можете дать мне доступ по ssh я бы зашел и посмотрел на настройки.

[misha8282]

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

[gto]

запустите slapd вручную (на debian-е /usr/sbin/slapd -u openldap -d3), он вам сам расскажет, что ему не нравится

[saamich]

А что будет если сначала связь порвется и в 2 разных филиалах поменяют/создадут запись с одним и темже rdn, а потом связь восстановится?

[misha8282]

такой вариант я не пробовал. кстати надо воспроизвести.

[misha8282]

эксперимент такой.
отключил сеть на обеих машинах, добавил с через ldif файл на обе машины юзера с одинаковыми данными и запустил сети на обеих машинах.

результат:
1. при отключенной связи на двух машинах — синхронизация произошла сразу же после включения сети. коллизий не наблюдалось.
2. если связь отрубилась на какой то одной машине и в ее LDAP добавили/изменили что то — при появлении связи опять же без коллизий прошла синхронизация.

[misha8282]

может быть есть еще какие то изощренные варианты проверки, но я пока произвел только такую проверку