Comments 28
У вас на все филиалы одна подсеть? Рисковый вы человек.
не на всех )))
это ж для примера.
сети могут быть и разные
на практике у меня главный 192.168.1.1 и два 192.168.2.1 и 192.168.5.1
у каждого своя подсеть
это ж для примера.
сети могут быть и разные
на практике у меня главный 192.168.1.1 и два 192.168.2.1 и 192.168.5.1
у каждого своя подсеть
Тогда, конечно, понятно. Еще такой вопрос, как проверяете консистентность нод?
если вы про согласованность данных и их целостность, то при стабильной связи синхронизация происходит нормально. способ синхронизации — постоянное соеднинение. если оно пропадает то при появлении синхронизауия происходит штатно.
если вы об этом спрашивали.
если вы об этом спрашивали.
Меня больше интересовал вопрос идентичности данных. Проще говоря, как проверяете, что базы одинаковые в определённый момент времени?
при устойчвой связи, после нажатия кнопки ПРИНЯТЬ в GQ(ldap клиент) информация распространяется мгновенно.
базы одинаковые сразу же после синхронизации
Тогда повторюсь, рисковый вы человек, так доверять сервису. Мы вот себе проверялки на contextCSN поставили. Потому как были неприятные случаи.
вы про то что бы добавить в файл contextCSN?
для использовагия метки времени
для использовагия метки времени
тоже мучался от парнойи на тему идентичности данных, поэтому рядом со всеми ldap серверами стоит костыль из ldapsearch | sort | diff — перезапускает slapd, если содержимое различается. помогает отловить негодяев, которые решили писать в slapd, не являющийся мастером. а вот при штатной эксплуатации проблем ни разу не возникало, хотя каналы связи довольно стабильные.
reopenldap не смотрели? намного стабильней
молодец, что разобрался, но статья получилась не очень. для мультимастерной репликации весь конфиг принято хранить в slapd.d, для того, чтобы при его изменении не перелопачивать все сервера. синхронизируется он так же с помощью syncprov, но работать с ним, разумеется, сложнее, чем с текстовым конфигом. например, можно прострелить себе ногу, отключив этот самый оверлей. причём ноги, в этом случае, будут прострелены сразу у всех серверов :)
к слову, в данной архитектуре, можно сделать мастерами лишь часть серверов. для этого достаточно, чтобы в списке мастеров были прописаны только те, серера, с которых нужно забирать изменения. такая схема позволяет держать свой slapd практически на каждом сервере или виртуалке, который должен использовать ldap, не нагружая мастеров.
ну и, если уж до конца придираться, то статье не хватает оформления.
к слову, в данной архитектуре, можно сделать мастерами лишь часть серверов. для этого достаточно, чтобы в списке мастеров были прописаны только те, серера, с которых нужно забирать изменения. такая схема позволяет держать свой slapd практически на каждом сервере или виртуалке, который должен использовать ldap, не нагружая мастеров.
ну и, если уж до конца придираться, то статье не хватает оформления.
Было бы очень интересно и полезно, если бы автор рассказал как проверять статус репликации и отлаживать это дело. Потому как у меня на 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
как видно строки разные, но а дальше то что?
Единственное что я знаю это на одном сервере
# 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
как видно строки разные, но а дальше то что?
А что будет если сначала связь порвется и в 2 разных филиалах поменяют/создадут запись с одним и темже rdn, а потом связь восстановится?
такой вариант я не пробовал. кстати надо воспроизвести.
эксперимент такой.
отключил сеть на обеих машинах, добавил с через ldif файл на обе машины юзера с одинаковыми данными и запустил сети на обеих машинах.
результат:
1. при отключенной связи на двух машинах — синхронизация произошла сразу же после включения сети. коллизий не наблюдалось.
2. если связь отрубилась на какой то одной машине и в ее LDAP добавили/изменили что то — при появлении связи опять же без коллизий прошла синхронизация.
отключил сеть на обеих машинах, добавил с через ldif файл на обе машины юзера с одинаковыми данными и запустил сети на обеих машинах.
результат:
1. при отключенной связи на двух машинах — синхронизация произошла сразу же после включения сети. коллизий не наблюдалось.
2. если связь отрубилась на какой то одной машине и в ее LDAP добавили/изменили что то — при появлении связи опять же без коллизий прошла синхронизация.
Sign up to leave a comment.
Репликация LDAP