Репликация данных каталога
Пакет inno-samba предоставляет ряд возможностей для управления топологией сети, включая создание сайтов и подсетей, для обеспечения эффективной маршрутизации трафика при обработке запросов аутентификации и репликации с учетом особенностей физической структуры сети.
Общие сведения
Для поддержания данных в актуальном и непротиворечивом состоянии на всех контроллерах домена служба каталогов использует механизм репликации: когда какой-либо объект создается, изменяется или удаляется в службе каталогов, данные о нем реплицируются с одних контроллеров домена на другие таким образом, чтобы на всех контроллерах они были одинаковыми.
Реплицируемые данные
Примерами реплицируемых данных могут служить изменения в данных пользователей, групп, групповых политик, схемы каталога, записей DNS, а также информация о добавлении и удалении контроллеров домена, компьютеров и устройств в домене, перемещении объектов по иерархии каталогов, изменении паролей и т. д.
Все объекты в службе каталогов представляют собой экземпляры классов, состоящих из наборов атрибутов. Классы и атрибуты описываются в схеме каталога. В определениях атрибутов задается признак возможности их изменения с помощью инструментов администрирования. Данные о неизменяемых атрибутах не обновляются и поэтому не подлежат репликации. Большинство объектов службы каталогов имеют атрибуты, значения которых могут изменяться.
Объекты группируются в логические категории, которые соответствуют разделам (партициям) каталога. Контроллеры домена хранят полные (все атрибуты объектов) или частичные (только часто используемые атрибуты объектов) реплики разделов, обновление которых выполняется следующим образом:
| Раздел (партиция) каталога | Уровень (лес/домен) | Объекты | Особенности репликации |
|---|---|---|---|
Раздел конфигурации |
Один раздел на лес |
Сайты, разделы каталога, сервисы, расширенные полномочия и т. д. |
Реплицируется на все контроллеры домена в лесу |
Раздел схемы |
Один раздел на лес |
Определения классов и атрибутов для всех объектов службы каталогов |
Реплицируется на все контроллеры домена в лесу |
Доменный раздел |
Один раздел на домен |
Пользователи, компьютеры, подразделения, группы и т. д. |
Реплицируется только на контроллеры в рамках домена |
Доменный раздел (глобальный каталог) |
Один раздел на домен |
Частичный набор атрибутов из разделов каталога, относящихся к разным доменам |
Реплицируется на контроллеры домена, выступающие в качестве серверов глобального каталога, в лесу |
Раздел приложений |
Произвольное количество разделов |
Данные приложений и служб; зоны DNS уровня леса ( |
Реплицируются на определенные контроллеры домена в лесу; данные о зонах DNS реплицируются на серверы DNS на всех контроллерах домена в лесу ( |
Принципы репликации
Передача данных между участвующими в репликации контроллерами домена выполняется в соответствии со следующими базовыми принципами:
-
равноправие участников репликации (multimaster-репликация);
Все контроллеры домена принимают LDAP-запросы на внесение изменений в атрибуты объектов службы каталогов, которые относятся к их зоне ответственности, с учетом действующих ограничений безопасности. Каждое исходящее изменение реплицируется на один и более контроллеров домена, которые фиксируют его как полученное в результате репликации.
Полные реплики разделов каталога могут быть доступны как для записи и чтения, так и только для чтения. Недоступность любой из реплик не блокирует процесс репликации. Изменения, внесенные в одну реплику, распространяются на все остальные реплики.
-
репликация по запросу (pull-репликация);
При возникновении изменений в данных контроллер домена уведомляет о них своих партнеров по репликации. В ответ партнеры запрашивают у него изменения.
-
репликация в режиме «сохрани и передай»;
Контроллеры домена сохраняют изменения, запрошенные ими у партнеров по репликации, и передают эти изменения другим контроллерам домена. Таким образом, контроллеру домена, являющемуся источником изменений, не требуется самостоятельно уведомлять о них все остальные контроллеры домена, которым они должны быть переданы.
-
репликация с учетом текущего состояния.
При репликации учитывается разница между текущим состоянием (то есть текущими значениями всех атрибутов) реплики раздела каталога на исходном и целевом контроллерах домена. Состояние описывается метаданными, которые используются при разрешении конфликтов и позволяют избежать необходимости передавать полную реплику в каждом цикле репликации.
Сайты
Для достижения оптимального баланса между временем задержки и объемом трафика репликация происходит с учетом физической структуры сети, представленной в службе каталога сайтами.
Сайт объединяет в себе ресурсы службы каталогов, располагающиеся в одной или нескольких подсетях с надежными и быстрыми сетевыми соединениями. Подсеть – это сегмент сети TCP/IP с закрепленным диапазонов IP-адресов, который используется для группировки компьютеров по признаку их физической близости друг к другу.
Каждый контроллер домена в лесу связывается с сайтом в соответствии с IP-адресом, назначенным ему администраторами. При этом в пределах одного сайта могут быть контроллеры из нескольких доменов, а ресурсы одного домена могут быть распределены по нескольким сайтами.
В службе каталогов сайты связываются между собой логическими путями, которые отражают сетевую связность между ними и задают разрешенные направления репликации. Каждый такой логический путь соответствует набору сайтов, взаимодействия между которыми характеризуются одинаковой стоимостью и происходят по однотипным сетевым соединениям.
Связи для сайтов задаются вручную при создании. При развертывании служба каталогов создает связь по умолчанию (DEFAULTSITELINK). При необходимости могут создаваться новые связи с требуемыми свойствами.
По умолчанию связи сайтов являются транзитивными, что позволяет связать два сайта, если между ними отсутствует прямая связь, но у них есть связи с общим третьим сайтом.
Если транзитивной связи недостаточно, то есть в сайте, который является общим для двух несвязанных напрямую сайтов, нет контроллера домена с разделом каталога, который требуется реплицировать, и при этом отсутствует альтернативный путь с меньшей стоимостью, между связями сайтов устанавливается «мост».
Таким образом, обеспечивается возможность комбинирования связей сайтов для определения пути репликации с наименьшей стоимостью с учетом того, какие разделы присутствуют на участвующих в репликации контроллерах домена в пределах сайтов.
Помимо репликации информация о сайтах также используется службой каталогов для определения оптимального маршрута обработки клиентских запросов на аутентификацию. По IP-адресу клиента, от которого получен запрос, определяется сначала подсеть, а затем — и сайт, который обслуживает данную подсеть. Клиент кэширует полученную информацию о сайте, запрашивает в DNS относящуюся к сайту SRV-запись и таким образом находит работающий контроллер домена в пределах сайта.
Если в сайте отсутствуют работающие контроллеры домена, служба каталогов находит контроллер домена в другом сайте, оптимизируя поиск такого сайта с учетом общей топологии сети.
В одном сайте могут быть контроллеры домена и другие ресурсы, относящиеся к разным доменам.
Процесс репликации
Каждый контроллер домена является членом одного сайта, в рамках которого он представлен отдельным объектом службы каталогов — объектом «сервер». У каждого сервера есть дочерний объект NTDS Settings, который представляет реплицирующий контроллер домена в сайте.
Подключение между исходным контроллером домена и целевым контроллером домена для целей репликации также представлено в службе каталогов отдельным объектом. На целевом сервере подключение является дочерним объектом объекта NTDS Settings. Чтобы между двумя контроллерами домена происходила репликация, объект «сервер» одного из них должен иметь объект «подключение», представляющий входящую репликацию от другого. Все подключения, существующие у контроллера домена для целей репликации, хранятся в виде объектов «подключение» в рамках родительского объекта NTDS Settings. Каждый такой объект «подключение» содержит информацию о сервере — источнике репликации, расписании репликации и транспорте, используемом для целей репликации.
Объекты «подключение» формируются автоматически службой синхронизации данных (Knowledge Consistency Checker, KCC). Администраторы могут создавать новые подключения вручную и вносить изменения в автоматически созданные подключения. KCC не вносит изменения в такие объекты.
KCC представляет собой процесс, который работает на всех контроллерах домена, формируя топологию репликации для леса в соответствии с распределением контроллеров домена по сайтам. При этом для репликации внутри сайтов и репликации между сайтами формируются отдельные топологии.
KCC динамически корректирует топологии при добавлении новых контроллеров домена, удалении существующих контроллеров домена, перемещении контроллеров домена между сайтами, изменении стоимости связей между сайтами и расписания репликации, а также временной недоступности контроллеров домена или возникновении ошибок в их работе. При обнаружении неработающего подключения KCC автоматически создает временные подключения к другим партнерам по репликации (если они доступны). Тем самым обеспечивается отказоустойчивость процесса репликации.
Внутри сайта подключения между контроллерами домена с доступными для записи репликами разделов каталога всегда образуют двунаправленное кольцо с дополнительными сквозными подключениями, обеспечивающими сокращение времени задержки в рамках больших сайтов. Топология репликации между сайтами представляет собой наслоение остовных деревьев, обеспечивающее наличие одного подключения между любыми двумя сайтами для каждого раздела каталога, и, как правило, не включает сквозные подключения.
На каждом контроллере домена KCC создает маршруты репликации в виде однонаправленных входящих объектов «подключение», определяющих параметры подключений от других контроллеров домена. Для контроллеров домена внутри одного сайта KCC создает подключения автоматически без необходимости вмешательство со стороны администратора. При наличии нескольких сайтов администраторы настраивают связи между ними, после чего процессы KCC в рамках отдельных сайтов автоматически создают межсайтовые подключения.
Репликация внутри сайта
Для репликации внутри одного сайта используются RPC-вызовы по протоколу IP. По умолчанию объекты данных передаются без предварительного сжатия. При необходимости сжатие может быть активировано путем изменения атрибутов подключения между контроллерами.
Репликация между контроллерами домена внутри сайта использует механизм нотификации об изменениях: при возникновении изменений на контроллере домена он отправляет запросы на синхронизацию данных (с помощью функции API DsReplicaSync) своим партнерам по репликации, перечисленным в атрибуте RepsTo (заполняется динамически KCC). Тем самым он уведомляет своих партнеров об изменениях. Получив нотификацию, партнеры формируют запросы на получение изменений (с помощью функции API DSGetNCChanges) на контроллеры домена, перечисленные в атрибуте RepsFrom (заполняется динамически KCC). Если запросы возвращают ненулевое количество изменений, выполняется репликация.
Существует возможность настроить репликацию таким образом, чтобы после завершения репликации в одну сторону автоматически инициировалась репликация в обратную сторону.
Для уменьшения нагрузки на сервер и оптимизации сетевого трафика уведомление на первый связанный контроллер отправляется с задержкой (по умолчанию — 15 секунд). Уведомления на последующие связанные контроллеры домена также отсылаются с задержкой (по умолчанию — 3 секунды).
Наряду с репликацией по уведомлению выполняется периодическая репликация. Период может конфигурироваться. По умолчанию в Эллес он составляет 5 минут.
Топология репликации внутри сайта строится исходя из допущения, что контроллеры домена находятся в одной подсети или в соседних подсетях (то есть пропускная способность сети и время задержки не являются значимыми факторами), по следующему алгоритму:
-
Контроллеры сортируются по своим глобальным уникальным идентификаторам (значение атрибута
objectGUIDобъектаnTDSDSA, представляющего контроллер домена). -
Для каждого раздела каталога строится граф репликации в форме двунаправленного кольца, где вершины — это доступные для записи реплики на контроллерах домена, а ребра — подключения между ними.
-
Для оптимизации времени задержки при репликации в сайте с большим количеством реплик для каждого контроллера домена могут создаваться дополнительные подключения (с учетом ограничения — не более 50 подключений на контроллер).
При создании подключений для репликации раздела конфигурации внутри сайта KCC учитывает роль сервера глобального каталога. Если контроллер домена является сервером глобального каталога, KCC строит дополнительный граф репликации для раздела конфигурации, добавляя в последовательность только реплики, которые находятся на серверах глобального каталога.
Репликация между сайтами
Поскольку подключения между контроллерами домена в разных сайтах заведомо медленнее, чем между контроллерами домена в одном сайте, репликация между сайтами происходит по расписанию независимо от фактического наличия накопленных изменений. В этом случае время ожидания репликации в доменном лесу определяется суммой интервалов репликации в соответствии с расписанием по самому длинному пути репликации между контроллерами домена в разных сайтах.
Интервал репликации задается в свойствах связи между сайтами. По умолчанию он составляет 180 минут. Минимальное значение интервала — 15 минут. Его рекомендуется использовать при сравнительно небольшом количестве реплицируемых данных и высоких требованиях к консистентности данных в разных сайтах.
При наличии нескольких связей между сайтами для них может быть задана разная стоимость (по умолчанию — 100): чем ниже стоимость связи, тем выше вероятность того, что KCC выберет ее для подключения.
Для репликации между сайтами используются RPC-вызовы по протоколу IP.
При репликации между сайтами объекты данных передаются с предварительным сжатием. При наличии гарантированно быстрых сетевых соединений между сайтами оно может быть отключено с помощью атрибутов соединения между сайтами.
В каждом сайте по определенному алгоритму выбирается один контроллер домена, за KCC которого закрепляется роль генератора топологии взаимодействия между сайтами (Intersite Topology Generator, ISTG). ISTG автоматически назначает из числа доступных контроллеров домена серверы (bridgehead-серверы), которые в рамках сайта служат точками входа и выхода соединений с другими сайтами для целей репликации. При этом администратор может вручную указывать определенные контроллеры домена как предпочтительные для выбора в качестве bridgehead-серверов (независимо для каждого протокола). Для обеспечения отказоустойчивости должно быть не менее двух предпочтительных bridgehead-серверов.
KCC, являющиеся владельцами роли ISTG, на всех сайтах используют один и тот же алгоритм для коллективного создания топологии репликации:
-
KCC создает граф, вершинами которого являются сайты, а ребрами — связи между сайтами и связи-«мосты».
-
Далее KCC «раскрашивает» каждую вершину, чтобы указать, какие виды реплик разделов каталога она содержит, и определяет, есть ли недоступные контроллеры домена, которые необходимо обойти.
-
Наконец, KCC создает соединения для репликации между сайтами, используя алгоритмы, обеспечивающие нахождение минимальных остовных деревьев, кратчайшего пути и наименьшей стоимости.
Разрешение конфликтов репликации
Служба каталогов гарантирует, что после завершения репликации значение измененного атрибута является одинаковым на всех контроллерах домена. Для устранения возможных конфликтов операции добавления, изменения, перемещения и удаления выстраиваются в последовательность, для чего каждое исходное обновление получает глобальную уникальную метку (на уровне объекта и на уровне атрибута) в момент выполнения соответствующей операции. Эта метка реплицируется вместе с измененным значением.
Каждая метка состоит из трех компонентов:
-
версия — числовое значение, которое увеличивается инкрементально при каждом изменении, подлежащем репликации;
-
время — время внесения изменения с точностью до секунды в соответствии с системным временем контроллера домена, на котором выполняется исходная операция изменения;
-
контроллер домена — значение
invocationIDконтроллера домена, на котором выполняется исходная операция изменения.
Сравнение меток осуществляется в следующем порядке: версия –> время –> контроллер домена.
Если две метки имеют одинаковые версии, выбирается изменение с наибольшим значением времени. В крайне редких случаях, когда один и тот же атрибут изменяется на двух контроллерах домена с разницей во времени менее секунды, случайным образом выбирается один из двух контроллеров и реплицируется выполненное на нем изменение.
Использование меток позволяет разрешать следующие типы конфликтов:
| Конфликт репликации | Описание | Способ разрешения |
|---|---|---|
Конфликт значения атрибута |
На одном контроллере домена в рамках операции изменения устанавливается новое значение для атрибута. Одновременно на другом контроллера домена для того же самого атрибута задается другое значение |
На всех контроллерах домена атрибут принимает значение с наибольшим номером версии в метке |
Добавление или перемещение объекта в удаленный контейнер, удаление неконечного объекта |
В результате операции добавление или перемещения объект становится дочерним объектом другого родительского объекта (контейнера). Одновременно с этим на другом контроллере домена выполняется операция удаления соответствующего родительского объекта (контейнера) |
Родительский объект (контейнер) удаляется на всех контроллерах домена, а дочерний объект помещается в специальный контейнер |
Конфликт относительного DN-имени объекта |
В результате операции добавления или перемещения дочерний объект получает имя в рамках родительского объекта (контейнера). Одновременно с этим на другом контроллере домена в результате операции добавления или перемещения в том же самом родительском объекте (контейнере) создается другой дочерний объект с тем же именем, в результате чего в рамках родительского объекта появляется два дочерних объекта с одинаковыми относительными DN-именами |
Дочерний объект, атрибут имени которого имеет больший номер версии в метке, сохраняет полученное имя. Дочерний объект, чей атрибут с относительным DN-именем (например, |
Пример разрешения конфликта
Например, если на двух контроллерах в одном домене по каким-либо причинам удается создать пользователя с одним и тем же относительным DN-именем, после выполнения репликации между ними в каталоге будут существовать два объекта со следующими наборами атрибутов (конкретные значения в таблице приводятся для примера):
| Объект 1 | Объект 2 |
|---|---|
dn: CN=namesake,CN=Users,DC=domain,DC=name objectClass: top objectClass: person objectClass: organizationalPerson objectClass: user cn: namesake instanceType: 4 whenCreated: 20240528142100.0Z whenChanged: 20240528142100.0Z uSNCreated: 4077 name: namesake objectGUID: f3910a06-f2c5-4d9b-beef-93d72ae7e4f6 badPwdCount: 0 codePage: 0 countryCode: 0 badPasswordTime: 0 lastLogoff: 0 lastLogon: 0 primaryGroupID: 513 objectSid: S-1-5-21-3233713020-2931839877-2596318144-1601 accountExpires: 9223372036854775807 logonCount: 0 sAMAccountName: namesake sAMAccountType: 805306368 userPrincipalName: namesake@domain.name objectCategory: CN=Person,CN=Schema,CN=Configuration,DC=domain,DC=name pwdLastSet: 133613796600794550 userAccountControl: 512 uSNChanged: 4079 distinguishedName: CN=namesake,CN=Users,DC=domain,DC=name |
dn: CN=namesake\0ACNF:a8d1d571-df29-437b-bd08-e7ed0f25ad78,CN=Users,DC=domain,DC=name objectClass: top objectClass: person objectClass: organizationalPerson objectClass: user instanceType: 4 whenCreated: 20240528142059.0Z uSNCreated: 4080 objectGUID: a8d1d571-df29-437b-bd08-e7ed0f25ad78 userAccountControl: 512 codePage: 0 countryCode: 0 pwdLastSet: 133613796595878070 primaryGroupID: 513 objectSid: S-1-5-21-3233713020-2931839877-2596318144-1107 accountExpires: 9223372036854775807 sAMAccountName: namesake sAMAccountType: 805306368 userPrincipalName: namesake@domain.name objectCategory: CN=Person,CN=Schema,CN=Configuration,DC=domain,DC=name cn:: bmFtZXNha2UKQ05GOmE4ZDFkNTcxLWRmMjktNDM3Yi1iZDA4LWU3ZWQwZjI1YWQ3OA== name:: bmFtZXNha2UKQ05GOmE4ZDFkNTcxLWRmMjktNDM3Yi1iZDA4LWU3ZWQwZjI1YWQ3OA== whenChanged: 20240528142103.0Z uSNChanged: 4082 distinguishedName: CN=namesake\0ACNF:a8d1d571-df29-437b-bd08-e7ed0f25ad78,CN=U sers,DC=domain,DC=name |
Таким образом, к имени пользователя с большим значением версии или времени внесения изменения в каталог добавляется блок \0ACNF:<GUID>.
При работе с этими пользователями с помощью утилиты samba-tool могут быть получены следующие результаты:
-
в списке пользователей домена отображается два пользователя с одинаковым именем:
samba-tool user list ... namesake ... namesake ...
При работе с некоторыми типами объектов каталога (например, подразделения, контакты, сайты) в списке отображается полное имя дублирующего объекта. -
при запросе информации о пользователе отображается сообщение об ошибке:
samba-tool user show namesake ERROR: Failed to get password for user 'namesake': Matched 2 multiple users with filter "(&(sAMAccountType=805306368)(sAMAccountName=namesake))"
При работе с некоторыми типами объектов каталога (например, группы, компьютеры) соответствующая команда возвращает список атрибутов обоих объектов. -
при выполнении операции удаления случайным образом выбирается один из двух объектов.
Ожидается, что дальнейшая работа по разрешению возникшего конфликта выполняется администратором с помощью доступных инструментов.
Поддержка репликации и работы с сайтами в Эллес
Пакет inno-samba поддерживает работу с подсетями, сайтами и репликацией, предоставляя необходимые инструменты администрирования (см. описание доступных подкоманд утилиты samba-tool в разделах
«Администрирование сайтов и подсетей» и «Администрирование репликации»).
Репликация между контроллерами домена внутри сайта происходит как с использованием механизма нотификации об изменениях, так и с определенной периодичностью (по умолчанию — с интервалом 5 минут).
Для настройки задержки отсылки уведомления при изменении данных и интервала запроса изменений могут использоваться следующие параметры в конфигурационном файле smb.conf (в примере приводятся значения по умолчанию в секундах):
[global]
dreplsrv:notify_interval=5
dreplsrv:periodic_interval=300
Репликация между сайтами выполняется через bridgehead-серверы по уведомлениям или с заданным интервалом.
Существует возможность гибко настраивать покрытие контроллером домена сайтов с учетом особенностей топологии сети (см. раздел «Покрытие сайтов контроллерами домена»).
Поддерживается возможность включения репликации в обратную сторону.
Поддерживаются стандартные механизмы разрешения следующих конфликтов (см. описание в «Разрешение конфликтов»):
-
внесение изменений в свойства одного объекта на разных контроллерах домена с небольшой разницей во времени;
-
создание объектов с одинаковыми именами на разных контроллерах домена с небольшой разницей во времени;
-
одновременное выполнение операций создания объекта в контейнере и удаления данного контейнера.
Рекомендации по настройке репликации с использованием Эллес
Для оптимизации репликации при большом количестве контроллеров домена рекомендуется:
-
разделить домен или доменный лес на сайты;
-
установить значение параметра
dreplsrv:periodic_intervalдостаточно большим, например —900(15 минут); при этом репликация внутри сайта будет происходить быстро по уведомлениям, а между сайтами — с интервалом 15 мин; -
выполнять операции, сопряженные с существенным ростом объема трафика при репликации (миграция пользователей, массовая смена паролей, массовое добавление пользователей в группы), в нерабочее время (например, по ночам или в выходные);
-
оптимизировать задержку отправки уведомлений об изменениях внутри сайта (15-30 секунд); при увеличении задержки она не должна превышать пороговое значение, соответствующее требованиям к консистентности данных на разных контроллерах.