Репликация данных каталога

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

Реплицируемые данные

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

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

Объекты группируются в логические категории, которые соответствуют разделам (партициям) каталога. Контроллеры домена хранят полные (все атрибуты объектов) или частичные (только часто используемые атрибуты объектов) реплики разделов, обновление которых выполняется следующим образом:

Раздел (партиция) каталога Уровень (лес/домен) Объекты Особенности репликации

Раздел конфигурации

Один раздел на лес

Сайты, разделы каталога, сервисы, расширенные полномочия и т. д.

Реплицируется на все контроллеры домена в лесу

Раздел схемы

Один раздел на лес

Определения классов и атрибутов для всех объектов службы каталогов

Реплицируется на все контроллеры домена в лесу

Доменный раздел

Один раздел на домен

Пользователи, компьютеры, подразделения, группы и т. д.

Реплицируется только на контроллеры в рамках домена

Доменный раздел (глобальный каталог)

Один раздел на домен

Частичный набор атрибутов из разделов каталога, относящихся к разным доменам

Реплицируется на контроллеры домена, выступающие в качестве серверов глобального каталога, в лесу

Раздел приложений

Произвольное количество разделов

Данные приложений и служб; зоны DNS уровня леса (ForestDNSZones) и домена (DomainDNSZones)

Реплицируются на определенные контроллеры домена в лесу; данные о зонах DNS реплицируются на серверы DNS на всех контроллерах домена в лесу (ForestDNSZones) или на все контроллеры в определенном домене (DomainDNSZones)

Принципы репликации

Передача данных между участвующими в репликации контроллерами домена выполняется в соответствии со следующими базовыми принципами:

  • равноправие участников репликации (multimaster-репликация);

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

    Полные реплики разделов каталога могут быть доступны как для записи и чтения, так и только для чтения. Недоступность любой из реплик не блокирует процесс репликации. Изменения, внесенные в одну реплику, распространяются на все остальные реплики.

  • репликация по запросу (pull-репликация);

    При возникновении изменений в данных контроллер домена уведомляет о них своих партнеров по репликации. В ответ партнеры запрашивают у него изменения.

  • репликация в режиме «сохрани и передай»;

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

  • репликация с учетом текущего состояния.

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

Механизмы репликации

Эллес всегда использует модель репликации по запросу (pull-репликация).

Взаимодействие между контроллерами домена в процессе репликации осуществляется с использованием следующих механизмов:

  • механизм уведомления об изменениях (notification):

    1. Контроллер домена уведомляет об изменениях в своей базе данных другие контроллеры домена, являющиеся его партнерами по репликации, с заданной периодичностью (по умолчанию — 5 секунд).

    2. При получении уведомления о наличии изменений целевые контролеры инициируют запросы (pull request) для репликации изменений с контроллера-источника.

  • механизм опроса об изменениях (polling):

    1. Контроллер домена опрашивает другие контроллеры, являющиеся его партнерами по репликации, о наличии изменений в их базах данных с момента последней репликации с заданной периодичностью (по умолчанию — 300 секунд).

    2. В случае наличия изменений контроллер домена инициирует запрос (pull request) для их репликации с контроллера-источника.

Данные механизмы не являются взаимоисключающими и используются как для внутрисайтовой (intra-site), так и для межсайтовой (inter-site) репликации.

Репликация между сайтами происходит через выделенные контроллеры (bridgehead-контроллеры). В случае смены предпочтительного bridgehead-контроллера в сайте требуется вручную пересоздать для него соединения с bridgehead-контроллерами в других сайтах.

Настройка механизмов репликации

Для настройки механизмов уведомления и опроса об изменениях в данных для целей репликации могут использоваться следующие конфигурационные параметры в файле smb.conf (в примере приводятся значения, используемые по умолчанию; все значения задаются в секундах):

[global]
    ...
    dreplsrv:periodic_startup_interval = 15
    dreplsrv:notify_interval = 5
    dreplsrv:periodic_interval = 300
    ...

Описание параметров:

  • dreplsrv:periodic_startup_interval — задержка (в секундах) перед первой попыткой репликации после запуска службы inno-samba (значение по умолчанию — 15);

  • dreplsrv:notify_interval — периодичность (в секундах) отправки контроллером домена уведомлений о наличии изменений в его базе данных другим контроллерам домена, являющимся его партнерами по репликации (значение по умолчанию — 5);

  • dreplsrv:periodic_interval — периодичность (в секундах) опроса контроллером домена других контроллеров домена, являющихся его партнерами по репликации, о наличии изменений в их базах данных с момента последней репликации между ними (значение по умолчанию — 300).

Эллес не использует расписания из объектов nTDSConnection и siteLink. Периодическая репликация всегда выполняется согласно внутренним настройкам Эллес.

Разрешение конфликтов репликации

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

Каждая метка состоит из трех компонентов:

  • версия — числовое значение, которое увеличивается инкрементально при каждом изменении, подлежащем репликации;

  • время — время внесения изменения с точностью до секунды в соответствии с системным временем контроллера домена, на котором выполняется исходная операция изменения;

  • контроллер домена — значение invocationID контроллера домена, на котором выполняется исходная операция изменения.

Сравнение меток осуществляется в следующем порядке: версия –> время –> контроллер домена.

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

Использование меток позволяет разрешать следующие типы конфликтов:

Конфликт репликации Описание Способ разрешения

Конфликт значения атрибута

На одном контроллере домена в рамках операции изменения устанавливается новое значение для атрибута. Одновременно на другом контроллера домена для того же самого атрибута задается другое значение

На всех контроллерах домена атрибут принимает значение с наибольшим номером версии в метке

Добавление или перемещение объекта в удаленный контейнер, удаление неконечного объекта

В результате операции добавление или перемещения объект становится дочерним объектом другого родительского объекта (контейнера). Одновременно с этим на другом контроллере домена выполняется операция удаления соответствующего родительского объекта (контейнера)

Родительский объект (контейнер) удаляется на всех контроллерах домена, а дочерний объект помещается в специальный контейнер LostAndFound в соответствующем разделе каталога. Метки при разрешении конфликта не используются

Конфликт относительного DN-имени объекта

В результате операции добавления или перемещения дочерний объект получает имя в рамках родительского объекта (контейнера). Одновременно с этим на другом контроллере домена в результате операции добавления или перемещения в том же самом родительском объекте (контейнере) создается другой дочерний объект с тем же именем, в результате чего в рамках родительского объекта появляется два дочерних объекта с одинаковыми относительными DN-именами

Дочерний объект, атрибут имени которого имеет больший номер версии в метке, сохраняет полученное имя. Дочерний объект, чей атрибут с относительным DN-именем (например, CN для большинства объектов, OU для подразделений, DC для контроллеров домена) имеет меньший номер версии в метке, получает новое имя, которое должно отличаться от конфликтующего с ним имени, а также не должно конфликтовать ни с какими значениями, которые могут быть назначены дочернему объекту клиентами. Например, если относительное DN-имя дочернего объекта до разрешения конфликта — CN=ABC, то в процессе разрешения конфликта оно заменяется значением CN=ABC\0ACNF:<GUID>, где \0A — зарезервированный символ, CNF — константа, указывающая на то, что имя сформировано при разрешении конфликта, а <GUID> — значение атрибута objectGUID