Репликация LDAP (часть 1)

Написал admin . Опубликовано в Databases, Unix просмотров 879

Так себеПойдетХорошоПонравилосьОтличный пост (No Ratings Yet)
Загрузка...

Обзор

Репликация LDAP может пригодиться в тех случаях, когда необходимо иметь несколько идентичных копий директорий LDAP. К примеру клиенты директории LDAP географически распределены и локальные копии директории были бы более предпочтительны в плане скорости доступа. Репликацию можно настроить как на полное дерево, так и на отдельные ветки директории.

Стандартная модель репликации LDAP выглядит в виде иерархии, где есть один master сервер и несколько slave (еще их называют shadow) серверов.

Master сервер отвечает за поддержание slave серверов в актуальном состоянии. Все изменения в директории вносятся на нем и по средством репликации переносятся на slave.
Slave сервера предоставляют каталог для поиска пользователям. Все запросы на поиск обрабатывают они, а не master. Все slave сервера соответственно работают в режиме read-only и не позволяют вносить изменения в данные директории. Этим занимается только master сервер. В случае попытки сделать на slave сервере операцию изменения данных (удаление, изменение или добавление записи), он вернет клиенту ссылку (refferal) на master сервер. Клиент при получении такой ссылки, будет обязан повторно выполнить операцию на предложенном master сервере.

Такая схема репликации предотвращает возникновение коллизий, которые бы могли возникнуть, если бы была возможность вносить изменения в директорию на множестве сервером, а не на одном master. Впрочем в версии OpenLDAP 2.4 реализована multimaster репликация, но она все же может приводить к коллизиям.

В OpenLDAP реализовано два метода репликации:

1. Метод PUSH — мастер сервер сам отправляет изменения директории на все slave сервера (master to slave)
2. Метод PULL — slave сервера периодически ходят на master за изменениями (slave from master)

В OpenLDAP до версии 2.2 был реализован только первый метод и работал на основе отдельного демона slurpd.  С версии 2.4 от него отказались. На его основе был разработан новый протокол Synchronization-Replication (SyncRepl) который и является на данный момент актуальным. Для его работы не надо иметь дополнительных демонов — все уже есть в самом slapd.

SyncRepl может использовать как PULL метод, так и гибридный PULL/PUSH.

В PULL методе (названном refresh-only) slave сервера периодически ходят на master сервер и запрашивают все изменения в директории за последнее время и master посылает им все изменения.

В гибридном методе PULL/PUSH (в конфигурации он называется refresh and persist) slave сервера инициируют коннект к master серверу и держат коннекты открытыми все время. Все изменения в директории передаются с мастера на slave через эти открытые коннекты. Если slave по какой-то причине разорвал коннект, то ему будут переданы все изменения в директории за период отсутствия коннекта, сразу же после восстановления им коннекта к мастеру. Если есто желание более подробно разобраться с реализацией репликации в OpenLDAP, милости прошу в RFC 4533.

Какой из методов использовать, зависит от структуры сети. К примеру в сильно распределнной и медленной сети, метод PULL (refresh-only) более предпочтителен, так как slave серверам нет необходимости держать постоянно открытыми коннекты к master серверу. В этом случае на сеть будет минимальная нагрузка, но изменения в директории будут приходить на slave с задержкой.

Для LAN лучше использовать гибридный метод (refreshAndPersist), в этом случае держать открытые коннекты не так сложно, а задержки в получении изменений slave серверами минимальны.

Настройка SyncRepl

Для использования SyncRepl нам понадобится OpenLDAP версии 2.4 (ниже не стоит). Никаких дополнительных демонов нам не понадобится, все есть в slapd и настраивается в его конфигурационном файле slapd.conf

Настройка Master сервера

Мастер сервер должен быть один и должен принимать коннекты от наших slave серверов и отдавать им все изменения в директории.

Функционально master сервер реализован через Synchronization Provider (syncprov) котороый подгружается модулем:

modulepath      /usr/local/libexec/openldap
moduleload      back_hdb
moduleload      refint
moduleload      unique
moduleload      accesslog
moduleload      syncprov

Далее нам необходимо добавить дополнительные индексы для аттрибутов entryCSN и entryUUID.

В первом аттрибуте Change Sequence Number (CSN) хранится время изменения записи. Второй аттрибут содержит уникальный UID номер записи в директории, по которому можно точно идентифицировать запись и по которой производится поиск записи на master и slave серверах.

Добавим индексы для этих аттрибутов в slapd.conf сразу после объявления всех индексов.

index entryCSN,entryUUID eq

Теперь необходимо загрузить оверлей модуля SyncRepl

overlay syncprov
syncprov-checkpoint 50 10
syncprov-sessionlog 100

Первая опция фактически включает репликацию. Вторая опция предписывает производить запись изменений не сразу, а только в случае 50 изменений или по истечению 10 минут. И последняя опция говорит сколько изменений (100) необходимо хранить в логе, который используется мастером для посылки изменений на slave сервера.

После внесения изменений в конфиг, не забываем запустить slaptest для проверки на наличие ошибок и slapindex для построения новых индексов.

Настройку Slave сервера мы рассмотрим в следующий раз.

Похожие статьи:

Метки: , , , , , ,

Trackback from your site.

Comments (4)

  • ffsdmad

    |

    надо будет попробовать на досуге

    Reply

  • ffsdmad

    |

    привет братец лис, можно ли с тобой в чате побеседовать по поводу LDAP ?

    Reply

  • Trololo

    |

    Пробовал настроить репликацию с авторизацией по kerberos, после включения репликации ( при условии что на мастер и слейве базы одинаковые) после изменениий данных на местере, слей получает иземениния, но только удаляет те данные в своей базе, а новые не вносит.
    Еще вопрос как можно включить нормальный debug куда-нибудь в отдельных лог-файл все что делает с репликацией, а то идет куча запросов еще параллельно и ничего не возможно slapd.log

    Reply

  • cOnf

    |

    конечно нужна!

    Reply

Leave a comment