Архитектура Multi-Master репликации в службе каталога корпоративного уровня

09.10.2026

В распределенной корпоративной инфраструктуре служба каталогов (Directory Service) выступает единым источником доверия для аутентификации, авторизации и управления правами доступа. С ростом масштаба организации — при наличии филиальной сети, изолированных ЦОД и геораспределенных команд — критически важным требованием становится непрерывная доступность операций записи и чтения на любом узле. Традиционная модель репликации Single-Master (Master-Slave / Read-Only Replica), где запись выполняется строго на одном первичном сервере, быстро становится узким местом: она уязвима к сетевым изоляциям (split-brain) и сбоям центрального узла, а также генерирует недопустимые задержки (latency) при межрегиональных транзакциях.

Для преодоления этих ограничений в enterprise-системах применяется архитектура Multi-Master (Active-Active) репликации. В такой модели каждый контроллер каталога является равноправным мастером, способным локально принимать и фиксировать изменения объектов (создание учетных записей, модификацию атрибутов, смену паролей, членство в группах) с последующей асинхронной или полусинхронной трансляцией обновлений на остальные узлы кластера. Реализация подобной архитектуры требует сложных механизмов отслеживания версий, разрешения коллизий и гарантирования целостности распределенной базы данных.

1. Модели согласованности данных: строгая против слабой

Согласно теореме CAP, распределенная система хранения данных в условиях сетевого разделения (Partition tolerance) вынуждена выбирать между абсолютной согласованностью (Consistency) и непрерывной доступностью (Availability). Службы каталогов исторически оптимизированы для интенсивного чтения (соотношение операций чтения к записи обычно превышает 90:10) и минимального времени отклика для клиентов локального сегмента сети.

По этой причине в Multi-Master архитектурах каталогов классически применяется модель конечной согласованности (Eventual Consistency):

• Изменение немедленно коммитится в локальное хранилище узла, и клиент получает подтверждение успешной операции;
• Изменение помещается в очередь исходящей репликации и асинхронно передается партнерам;
• Временная рассинхронизация данных между географически удаленными контроллерами считается допустимой на период интервала конвергенции;
• При отсутствии новых модификаций все реплики гарантированно сходятся к идентичному состоянию.

Исключение делается лишь для критически чувствительных событий, таких как немедленная блокировка скомпрометированной учетной записи или срочная инвалидация тикетов Kerberos, для которых могут задействоваться механизмы срочной/внеочередной нотификации (Urgent Replication).

2. Механизмы отслеживания изменений и вектор времени

Ключевая задача репликатора — определить, какие именно данные изменились, где и когда, не передавая базу целиком и не перегружая каналы связи. Для этого применяются специализированные структуры метаданных версионирования.

Порядковые номера обновлений (USN / CSN)

Каждый узел ведет локальный строго монотонно возрастающий счетчик транзакций — Update Sequence Number (USN) в терминах Active Directory или Change Sequence Number (CSN) в стеке 389 Directory Server / OpenLDAP. При каждой локальной модификации счетчик инкрементируется и привязывается к изменившемуся атрибуту или объекту. Это позволяет контроллерам при сеансе репликации запрашивать только те дельты, где локальный номер партнера превышает ранее зафиксированное значение.

Векторы версий и водяные знаки (High-Watermark Vector)

Чтобы исключить циклический перенос изменений («эхо») и передачу избыточных данных по цепочке партнеров, каждый узел хранит метаданные о состоянии всех известных ему мастеров кластера:

• Вектор актуальности (Up-To-Dateness Vector): содержит наивысший порядковый номер изменений (USN/CSN), который данный сервер уже получил от каждого конкретного мастера репликации, включая транзитивные обновления.
• High-Watermark Vector: фиксирует точку прогресса прямого обмена с непосредственным сетевым соседом по топологии.

Благодаря сопоставлению этих векторов узел-источник отправляет узлу-приемнику строго уникальные дельты изменений, сгенерированные в домене.

3. Топологии межсерверного взаимодействия

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

4. Разрешение коллизий (Conflict Resolution)

Поскольку разные администраторы или автоматизированные системы могут одновременно изменить один и тот же объект на двух географически изолированных контроллерах, возникновение коллизий в Multi-Master системах неизбежно. Разрешение конфликтов реализуется на аппаратном и логическом уровнях ядра каталога.

Конфликты уровня атрибутов (Property-Level Conflict)

Если на узле А изменен телефон сотрудника, а на узле Б — его почтовый адрес, коллизии не возникает: современные каталоги реплицируют не объект целиком, а дифференцированные атрибуты (Attribute-Level Replication). Оба изменения успешно объединяются.

Если же один и тот же атрибут модифицирован одновременно, применяется детерминированное правило LWW (Last-Write-Wins):

1. Сравнивается локальная версия версионирования атрибута (Version Number). Побеждает атрибут с большим номером версии;
2. При равных версиях сравнивается временная метка (Timestamp) по UTC. Изменение с более поздним временем признается истинным;
3. Если метки совпали с точностью до микросекунды, сравниваются GUID или строковые идентификаторы исходных серверов-мастеров (Tie-Breaker). Это гарантирует, что все узлы придут к математически одинаковому решению.

Конфликты создания и перемещения объектов (CNF/Conflict Munging)

Если в разных сегментах сети в одном и том же подразделении (OU) одновременно созданы две учетные записи с одинаковым Relative Distinguished Name (RDN), возникает конфликт уникальности пространства имен. В этом случае проигравший объект переименовывается путем добавления суффикса конфликта:

CN=Иванов Иван\0ACNF:3d9b4b92-8a4e-4f3b-bc8e-671c53e8d9a1,OU=Users,DC=corp,DC=local

Это сохраняет данные от удаления и позволяет администраторам вручную расследовать инцидент коллизии.

5. Специфика реализации в гетерогенных и корпоративных средах

В условиях масштабной цифровой трансформации и перехода на открытые и доверенные стеки технологий enterprise-архитекторам приходится сопрягать принципы репликации между различными платформами. Если в среде Microsoft Active Directory репликация опирается на протокол RPC через IP и внутреннюю базу ESE (NTDS.dit), то в среде Linux/Unix доминируют стандарты на базе протокола LDAP/LDAPS, механизмов RFC 4533 (LDAP Content Synchronization Operation) и ядра 389 DS.

В рамках построения импортонезависимых контуров ключевую роль начинает играть российская служба каталога, такая как ALD Pro или решения на базе FreeIPA и Samba DC. В этих системах реализация Multi-Master репликации адаптирована под требования отечественных регуляторов по информационной безопасности: применяются строгая аутентификация хостов через Kerberos, взаимная проверка TLS-сертификатов (mTLS), криптографическая защита каналов репликации по ГОСТ и гранулярное логирование межсерверных транзакций.

Переход на такие платформы требует учета архитектурных тонкостей: синхронизации времени по протоколу NTP с точностью до миллисекунд, корректной изоляции репликационного трафика в выделенные VLAN и управления жизненным циклом удаленных объектов (Tombstone Lifetime), чтобы избежать появления «зомби-объектов» (Lingering Objects) при длительном отключении филиальных узлов.

6. Безопасность и целостность репликационного канала

Поскольку по каналам репликации передаются критически важные данные — включая парольные хеши, структуры прав доступа и списки рассылки — защита транспорта является приоритетом первого уровня.

• Шифрование транзита: использование IPsec, mTLS или SASL/GSSAPI (Kerberos) поверх LDAPS исключает перехват и модификацию трафика типа Man-in-the-Middle (MitM);
• Изоляция ролей FSMO: несмотря на общую Multi-Master архитектуру, ряд операций (Schema Master, Domain Naming Master, PDC Emulator) принципиально выносятся в квази-Single-Master режим для предотвращения деструктивных конфликтов схем;
• Контроль задержки репликации (Replication Lag): непрерывный мониторинг очередей синхронизации предотвращает рассогласование политик безопасности между географическими площадками.

FAQ (Часто задаваемые вопросы)

Чем Multi-Master репликация отличается от распределенного консенсуса Raft или Paxos?

Алгоритмы Raft и Paxos требуют кворума (большинства голосов узлов) для фиксации каждой транзакции записи, что обеспечивает строгую согласованность (Strong Consistency), но снижает доступность при сетевых изоляциях. Multi-Master в каталогах ориентирован на модель конечной согласованности (Eventual Consistency), позволяя записывать данные локально даже при отсутствии связи с большинством узлов.

Что такое Lingering Objects («зомби-объекты») и как они появляются?

Это объекты, удаленные на активных контроллерах, но сохранившиеся на узле, который был отключен от сети дольше, чем время жизни метки удаления (Tombstone Lifetime / Garbage Collection period). При повторном включении такого узла без очистки он может «воскресить» удаленные объекты на остальных серверах.

Можно ли использовать Multi-Master репликацию по ненадежным спутниковым каналам?

Да, при условии перехода от полносвязной топологии (Full Mesh) к топологии Hub-and-Spoke с увеличенным интервалом репликационного опроса (Schedule-based) и сжатием передаваемых дельт на транспортном уровне.

Как предотвратить рассинхронизацию времени между мастерами?

Критически важно развернуть иерархическую структуру синхронизации NTP/Chrony от доверенных стратумов времени. Рассинхронизация часов свыше 5 минут не только нарушает работу протокола Kerberos, но и приводит к некорректной работе механизма разрешения конфликтов Last-Write-Wins.

Заключение

Архитектура Multi-Master репликации — краеугольный камень отказоустойчивости корпоративных служб каталогов. Она обеспечивает непрерывность бизнес-процессов, высокую производительность авторизационных сервисов и локальную автономность филиалов. Однако надежность подобной системы требует высокой квалификации инженеров: точного проектирования топологии, строгого контроля временных меток, корректного мониторинга задержек репликации и применения защищенных криптографических протоколов обмена данными.