Архитектура отказоустойчивого LDAP-кластера
LDAP-каталог, обслуживающий аутентификацию пользователей, DNS-зоны или конфигурации сервисов, не может быть единой точкой отказа. Когда единственный сервер OpenLDAP выходит из строя, останавливаются все зависящие от него системы: VPN, почта, веб-приложения. Решение - кластер из мастер-сервера и одной или нескольких slave-реплик, синхронизированных через механизм Syncrepl. Эта архитектура проверена в production-средах с нагрузкой от сотен до десятков тысяч запросов в минуту.
Мастер принимает все операции записи: добавление, изменение, удаление записей. Реплики обслуживают исключительно чтение, разгружая мастер и обеспечивая мгновенное переключение при его отказе. Клиенты, настроенные на список LDAP URI, автоматически переходят на доступную реплику без ручного вмешательства. Такой подход даёт два ключевых преимущества: непрерывность сервиса и горизонтальное масштабирование операций поиска.
Роли серверов: мастер и реплики
В кластере OpenLDAP каждый узел выполняет строго определённую функцию. Мастер - единственный источник истины, принимающий LDAP-запросы на модификацию данных. Любая попытка записи на реплику завершится ошибкой referral, перенаправляющей клиента на мастер. Это исключает конфликты данных, неизбежные в multi-master конфигурациях без внешнего разрешения коллизий.
Slave-реплика хранит полную копию каталога и отвечает на поисковые запросы. При потере связи с мастером реплика продолжает обслуживать клиентов, используя последнее согласованное состояние данных. После восстановления соединения Syncrepl автоматически навёрстывает пропущенные изменения. Для критичных сервисов рекомендуется минимум две реплики: одна принимает нагрузку, вторая страхует на случай одновременного сбоя мастера и первой реплики.
Как Syncrepl обеспечивает синхронизацию
Syncrepl работает в режиме refreshAndPersist - комбинации полной синхронизации и постоянного отслеживания изменений. При первом подключении реплика загружает всё содержимое каталога мастера (фаза refresh). Затем соединение не разрывается: мастер отправляет реплике каждое изменение в реальном времени (фаза persist). Это не периодический опрос, а непрерывный поток обновлений, минимизирующий задержку репликации.
Ключевые параметры конфигурации Syncrepl:
- provider - LDAP URI мастера, например
ldap://master.example.com - searchbase - корень реплицируемого дерева, обычно совпадает с базовым DN каталога
- binddn - DN учётной записи с правами чтения всего каталога
- credentials - пароль этой учётной записи
- type - режим репликации, для отказоустойчивого кластера используется
refreshAndPersist - retry - стратегия переподключения при обрыве связи, формат:
"интервал количество_попыток таймаут +"
Параметр retry заслуживает отдельного внимания. Запись retry="60 10 300 +" означает: при разрыве соединения повторять попытки каждые 60 секунд первые 10 раз, затем каждые 300 секунд неограниченно долго (символ +). Это гарантирует, что реплика не останется в рассинхронизированном состоянии после кратковременного сетевого сбоя.
Подготовка среды: установка и базовые настройки OpenLDAP
Единая версия OpenLDAP на всех узлах кластера - обязательное условие корректной репликации. Разные мажорные версии slapd могут использовать несовместимые форматы индексов или протоколы синхронизации. Перед началом настройки проверьте, что на мастере и всех будущих репликах установлен один и тот же пакет slapd одной версии.
Установка OpenLDAP на Debian/Ubuntu
Установка на Debian 12 или Ubuntu 24.04 выполняется двумя командами:
apt update apt install slapd ldap-utils
В процессе установки пакет slapd запустит мастер настройки. Если он не сработал автоматически, выполните:
dpkg-reconfigure slapd
Ответьте на вопросы мастера: пропустите начальную конфигурацию (No), укажите домен (например, example.com), задайте пароль администратора. После завершения проверьте версию:
slapd -V
Вывод должен содержать строку вида @(#) $OpenLDAP: slapd 2.5.13. Запишите эту версию - она потребуется при развёртывании реплик.
Создание учетной записи для репликации
Использовать root DN для репликации небезопасно. Создайте выделенную учётную запись с минимально необходимыми правами - чтение всего каталога. Подготовьте LDIF-файл replicator.ldif:
dn: cn=replicator,dc=example,dc=com
objectClass: simpleSecurityObject
objectClass: organizationalRole
cn: replicator
userPassword: {SSHA}сгенерированный_хэш_пароля
description: Replication user for Syncrepl
Хэш пароля получите утилитой slappasswd:
slappasswd -s ваш_пароль
Добавьте учётную запись в каталог:
ldapadd -x -D cn=admin,dc=example,dc=com -W -f replicator.ldif
Теперь предоставьте этой учётной записи права на чтение. Создайте LDIF acl-replicator.ldif:
dn: olcDatabase={1}mdb,cn=config
changetype: modify
add: olcAccess
olcAccess: {0}to * by dn.exact="cn=replicator,dc=example,dc=com" read by * break
Примените изменения:
ldapmodify -Y EXTERNAL -H ldapi:/// -f acl-replicator.ldif
Проверьте, что учётная запись работает и видит данные:
ldapsearch -x -D cn=replicator,dc=example,dc=com -W -b dc=example,dc=com
Успешный вывод содержимого каталога подтверждает готовность мастера к настройке репликации.
Пошаговая настройка Syncrepl на slave-сервере
На slave-сервере установлен OpenLDAP той же версии, что и на мастере, но его база данных пока пуста. Задача - добавить конфигурацию Syncrepl, которая запустит начальную синхронизацию и переведёт реплику в режим постоянного отслеживания изменений. Все операции выполняются через механизм динамической конфигурации cn=config, без правки slapd.conf.
Конфигурация Syncrepl через LDIF
Создайте файл syncrepl-config.ldif со следующим содержимым. Каждый параметр критичен, проверьте адреса и учётные данные перед применением:
dn: olcDatabase={1}mdb,cn=config
changetype: modify
add: olcSyncrepl
olcSyncrepl: rid=001
provider=ldap://master.example.com
searchbase="dc=example,dc=com"
binddn="cn=replicator,dc=example,dc=com"
credentials=ваш_пароль
type=refreshAndPersist
interval=00:00:01:00
retry="60 10 300 +"
schemachecking=on
bindmethod=simple
starttls=no
Разбор полей:
- rid - уникальный идентификатор реплики в пределах сервера. Для первой реплики используйте 001, для второй на том же хосте - 002. Значение должно быть трёхзначным числом от 001 до 999.
- provider - полный LDAP URI мастера. Для продакшена используйте
ldaps://с TLS. - searchbase - корень реплицируемого поддерева. Совпадает с базовым DN каталога.
- binddn и credentials - учётные данные replicator, созданного на предыдущем шаге.
- type=refreshAndPersist - режим непрерывной репликации.
- interval - период повторных попыток синхронизации в формате
дд:чч:мм:сс. Значение 00:00:01:00 означает повтор каждую минуту при сбое. - retry - стратегия переподключения: каждые 60 секунд первые 10 попыток, затем каждые 300 секунд бесконечно.
- schemachecking=on - проверка соответствия схемы данных мастера и реплики. Отключайте только если точно уверены в идентичности схем.
Применение конфигурации и проверка синхронизации
Примените LDIF на slave-сервере:
ldapmodify -Y EXTERNAL -H ldapi:/// -f syncrepl-config.ldif
После успешного выполнения команды репликация запускается немедленно. Проверьте, что данные появились на реплике:
ldapsearch -x -b dc=example,dc=com
Вывод должен содержать все записи, присутствующие на мастере. Для мониторинга процесса синхронизации проверьте логи:
grep syncrepl /var/log/syslog
Успешная синхронизация отражается строками:
slapd[1234]: syncrepl_entry: rid=001 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) slapd[1234]: syncrepl_entry: rid=001 inserted UUID ...
Если вместо этого видите ошибки аутентификации или таймауты - переходите к разделу «Типичные проблемы и их решение».
Настройка клиентов для автоматического переключения (Failover)
Репликация данных решает проблему сохранности информации, но не обеспечивает непрерывность сервиса. Когда мастер недоступен, клиенты должны автоматически переключиться на реплику. Реализуется это на стороне клиента - через конфигурацию LDAP URI или DNS. Оба метода совместимы и могут использоваться совместно для максимальной надёжности.
Настройка нескольких LDAP URI в конфигурации клиента
Файл /etc/ldap/ldap.conf на каждом клиенте поддерживает указание нескольких серверов через пробел в директиве URI:
URI ldap://master.example.com ldap://slave1.example.com ldap://slave2.example.com BASE dc=example,dc=com TIMEOUT 5 NETWORK_TIMEOUT 3
Порядок серверов определяет приоритет: клиент подключается к первому доступному. Если мастер отвечает - используется он. При недоступности мастера клиент пробует slave1, затем slave2. Таймауты TIMEOUT и NETWORK_TIMEOUT управляют временем ожидания ответа: 5 секунд на операцию, 3 секунды на установку соединения. При срабатывании таймаута клиент немедленно переходит к следующему URI.
Для сервисов, использующих NSS (nslcd), конфигурация задаётся в /etc/nslcd.conf:
uri ldap://master.example.com uri ldap://slave1.example.com uri ldap://slave2.example.com base dc=example,dc=com bind_timelimit 5 timelimit 10
Этот метод не требует дополнительной инфраструктуры и обеспечивает мгновенное переключение при отказе. Недостаток - при восстановлении мастера клиенты не возвращаются на него автоматически до перезапуска сервиса или нового соединения.
Использование DNS Round-Robin для балансировки и отказоустойчивости
Альтернативный подход - создать DNS-запись с несколькими A-записями:
ldap.example.com. IN A 192.168.1.10 ; мастер ldap.example.com. IN A 192.168.1.11 ; slave1 ldap.example.com. IN A 192.168.1.12 ; slave2
Клиенты настраиваются на единый URI ldap://ldap.example.com. DNS-сервер возвращает IP-адреса в циклическом порядке, распределяя запросы между всеми узлами. Для отказоустойчивости критичен параметр TTL: при значении 300 секунд и выше клиенты кэшируют IP-адрес и не переключаются при отказе узла в течение этого времени. Установите TTL=5 или TTL=10 для минимизации окна недоступности.
Комбинированный подход даёт наилучший результат: настройте DNS round-robin с низким TTL для распределения нагрузки, а в клиентском ldap.conf укажите несколько статических URI как fallback - на случай, если DNS-сервер тоже окажется недоступен.
Балансировка нагрузки между репликами
Когда количество клиентов измеряется сотнями или тысячами, DNS round-robin распределяет запросы статистически, но не учитывает реальную загрузку серверов и не проверяет их доступность перед отправкой трафика. Для production-сред с жёсткими требованиями к производительности используйте выделенный балансировщик.
Настройка HAProxy для LDAP-трафика
HAProxy работает на уровне TCP, прозрачно проксируя LDAP-трафик без необходимости терминировать TLS. Установите пакет:
apt install haproxy
Минимальная конфигурация /etc/haproxy/haproxy.cfg для балансировки LDAP:
frontend ldap_front
bind :389
mode tcp
default_backend ldap_back
backend ldap_back
mode tcp
balance roundrobin
option tcp-check
server master 192.168.1.10:389 check
server slave1 192.168.1.11:389 check
server slave2 192.168.1.12:389 check
Директива option tcp-check включает проверку доступности каждого сервера перед отправкой трафика. Если узел не отвечает на TCP-порт 389, HAProxy исключает его из ротации. При восстановлении сервер автоматически возвращается в пул. Параметр balance roundrobin равномерно распределяет новые соединения между всеми доступными узлами.
Балансировщик решает две задачи одновременно: распределение нагрузки и автоматическое исключение отказавших узлов без задержек, связанных с кэшированием DNS. Недостаток - HAProxy сам становится единой точкой отказа. Для устранения этой уязвимости разверните два экземпляра HAProxy с общим виртуальным IP через keepalived.
Мониторинг и диагностика репликации
Репликация, работающая без видимых ошибок, не гарантирует актуальность данных на реплике. Сетевые задержки, высокая нагрузка на мастер или ошибки записи могут привести к отставанию, которое останется незамеченным до первого сбоя. Регулярная проверка состояния репликации - обязательная часть эксплуатации кластера.
Проверка статуса репликации через contextCSN
contextCSN - это метка времени последнего изменения в каталоге, общая для всех узлов кластера. Сравнение значений на мастере и реплике показывает, синхронизированы ли данные на текущий момент:
# На мастере ldapsearch -x -b dc=example,dc=com -s base contextCSN # На реплике ldapsearch -H ldap://slave1 -x -b dc=example,dc=com -s base contextCSN
Оба запроса должны вернуть одинаковое значение, например:
contextCSN: 20260729120000.123456Z#000000#001#000000
Расхождение означает, что реплика отстаёт. Время в метке contextCSN указывает на момент последнего синхронизированного изменения. Разница более чем в несколько секунд при стабильной сети - повод проверить логи и соединение.
Системный мониторинг организуйте через отслеживание логов slapd. Ключевые события для алертов:
syncrepl_entry: rid=001 LDAP_RES_SEARCH_ENTRY- штатная синхронизация записиdo_syncrepl: rid=001 retrying- попытка переподключения после сбояdo_syncrepl: rid=001 connection lost- потеря соединения с мастером
Настройте отправку алертов при появлении строк connection lost или при отсутствии LDAP_RES_SEARCH_ENTRY дольше заданного интервала. Это можно сделать через скрипт, анализирующий /var/log/syslog, или через штатную интеграцию с Zabbix, Prometheus либо Nagios.
Типичные проблемы и их решение
За годы эксплуатации LDAP-кластеров выявлены повторяющиеся сценарии отказов. Каждый из них имеет чёткие симптомы и проверенный алгоритм устранения. Этот раздел - ваш чек-лист для быстрой диагностики.
Ошибки TLS при подключении к мастеру
Симптом: в логах реплики строки TLS negotiation failure или certificate verification failed. Репликация не запускается.
Причина: не настроены сертификаты на мастере или реплике, либо сертификаты не совпадают с указанными в конфигурации.
Решение: на мастере добавьте в cn=config параметры TLS:
dn: cn=config changetype: modify add: olcTLSCACertificateFile olcTLSCACertificateFile: /etc/ssl/certs/ca-certificates.crt - add: olcTLSCertificateFile olcTLSCertificateFile: /etc/ssl/certs/ldap-master.crt - add: olcTLSCertificateKeyFile olcTLSCertificateKeyFile: /etc/ssl/private/ldap-master.key
Примените через ldapmodify -Y EXTERNAL -H ldapi:///. На реплике в конфигурации Syncrepl укажите starttls=yes или измените URI на ldaps://master.example.com. Проверьте соединение:
ldapsearch -H ldaps://master.example.com -x -b dc=example,dc=com -ZZ
Репликация не запускается: таймауты и права доступа
Симптом: в логах syncrepl: rid=001 failed to connect или invalid credentials. Данные на реплике отсутствуют.
Причина: сетевые ограничения (firewall), неверные учётные данные replicator или недостаточные права.
Решение - пошаговая проверка:
- Проверьте сетевую доступность:
telnet master.example.com 389илиnc -zv master.example.com 389. Если порт закрыт - проверьте firewall на мастере (ufw statusилиiptables -L). - Проверьте учётные данные: выполните
ldapsearch -x -D cn=replicator,dc=example,dc=com -W -H ldap://master.example.com -b dc=example,dc=com. Ошибка аутентификации указывает на неверный пароль или DN. - Проверьте права replicator: в ACL на мастере должна быть запись, разрешающая чтение всего дерева для этого DN. При отсутствии - добавьте согласно разделу «Создание учетной записи для репликации».
- Проверьте таймауты: в конфигурации Syncrepl добавьте параметр
timeout=10для увеличения времени ожидания ответа от мастера при высокой нагрузке.
Отдельная проблема - конфликт rid. Если на одном сервере настраивается несколько реплик, каждая должна иметь уникальный rid. Дублирование приводит к ошибке rid=001 already in use. Назначайте rid последовательно: 001, 002, 003.
При несовпадении схем данных (schemachecking=on, а на реплике отсутствует нужный objectClass) Syncrepl выдаст ошибку и остановит синхронизацию этой записи. Решение - либо загрузить недостающую схему на реплику через ldapadd -Y EXTERNAL -H ldapi:/// -f /etc/ldap/schema/нужная_схема.ldif, либо временно отключить schemachecking на период начальной синхронизации.