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

Обновлено: 16.05.2024

В этой статьe мы разобрали как развернуть контроллер домена на базе Windows Server 2012 R2. Теперь наша задача развернуть дополнительный контроллер домена, который будет подстраховкой в случае если основной выйдет из строя.

Итак мы имеем в работе:

Основной контроллер домена Windows Server 2012 R2 (DC1, jakonda.local, 192.168.0.2) с развернутыми службами AD DS, DNS, DHCP.

Развернуть дополнительный контроллер домена на базе Windows Server 2012 R2, выполнить предварительную настройку системы.
Поднять на дополнительном контроллере роли AD DS, DNS, DHCP.
Настроить репликацию данных.
Выполнить настройку работы DHCP сервера совместно с основным контроллером домена.

Проделываться все действия будут на виртуальной машине.

Установка Windows Server 2012 R2 и подготовительная настройка системы

Устанавливаем Windows Server 2012 R2 Standart with GUI. После установки системы обязательно:

Устанавливаем все имеющиеся обновления на текущий момент.
Выставляем корректную временную зону (+03:00 Moscow, St. Petersburg, Volgograd).
Изменяем имя системы на (прим. DC2).
Указываем в системе статический IP-адрес (в моем случае это будет 192.168.0.3), в качестве предпочитаемого DNS сервера указываем адрес DNS сервера на основном контроллере домена DC1 (192.168.0.2) и в качестве альтернативного DNS сервера указываем адрес который мы присвоили на текущем сервере DC2 (192.168.0.3).

Вводим систему в имеющийся домен jakonda.local.

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

Поднимаем роли AD DS + DNS + DHCP на дополнительном контроллере домена

Все действия по развертыванию и настройке ролей на дополнительном контроллере домена, мы будем производить с основного контроллера домена. Поэтому заходим в моем случае на основной контроллер домена DC1 (192.168.0.2) и добавим наш дополнительный сервер в основной, Manage — Add Servers.

Переходим во вкладку DNS, в поле Search вбиваем IP-адрес нашего дополнительного сервера (в моем случае 192.168.0.3), сервер должен появится в списке найденных, выделяем его и нажимаем кнопку переместить (>). Нажимаем ОК.

После добавления сервера, если перейти в All Servers, то мы увидим что у нас там теперь два сервера. Теперь можно из основного сервера добавлять, настраивать роли на другом сервере.

Добавляем новую роль на дополнительном сервере DC2. Переходим Server Manager — Manage — Add Roles and Features.

Выбираем первый пункт Role-based or feature-based installation (Базовая установка ролей и компонентов).Нажимаем Next.

Выбираем Select a server from the server pool и выбираем сервер из списка, т.к. мы настраиваем дополнительный сервер, то выделяем dc2.jakonda.local и нажимаем Next.

Далее все как и в статье по развертыванию контроллера домена:

Отмечаем галочкой роль Active Directory Domain Services, в подтверждающем запросе добавления роли и компонентов, необходимых для установки AD нажимаем Add Features.
В выборе установки дополнительных компонентов, ничего не выбираем.
На завершающих этапах установки нажимаем Next и Install.

По завершении установки роли AD DS в Server Manager нажимаем на значок Флажка с восклицательным знаком и выбираем Promote this server to a domain controller (Повысить этот сервер до контроллера домена). Запустится мастер конфигурирования AD DS для сервера DC2.

Т.к. мы разворачиваем дополнительный контроллер домена, то нужно добавить его в уже существующий домен. Выбираем Add a domain controller to an existing domain. Автоматические подставится название текущего домена (jakonda.local) и какую доменную учетную запись использовать при выполнении данной операции. Нажимаем Next.

Проверяем установлены ли галочки (Domain Name System (DNS) Server, Global Catalog (GC)), в пункте Site name оставляем значение Default-First-Site-Name и задаем пароль для восстановления служб каталогов. Нажимаем Next.

Предупреждение о том что не может быть создано делегирование разворачиваемого DNS сервера, игнорируем. Нажимаем Next.

В дополнительных опциях в пункте Replicate from (Репликация из) выбираем основной контроллер домена DC1.jakonda.local. Это мы указываем дополнительному контроллеру домена откуда производить репликацию даннных AD, DNS. Нажимаем Next.

Пути к каталогам оставляем по-умолчанию, далее просматриваем сводную информацию по конфигурации AD DS. Нажимаем Next.

Если проверка выполнена успешно, то нажимаем Install.

После того пройдет установка, если зайти на DC2, то увидим что роли AD, DNS подняты, произведена репликация из DC1.

Если необходимо посмотреть, изменить параметры репликации, то заходим Server Manager — Tools — Active Directory Sites and Services.

Так же можно с помощью командной строки принудительно запустить процесс репликации, с помощью утилиты repadmin:

N.B. Надеюсь все понимают что мы говорим о репликации каталога AD, которая не имеет никакого отношения к репликации папки Sysvol. И еще, если вы никогда не слышали об USN, KCC, Up-to-dateness Vector и прочих ~~гадостях~~ терминах, то дальше можете не читать, будет непонятно.

~~А вот и нифига!~~ К сожалению, в описанном на Technet способе есть одно существенное ограничение: уведомления об изменениях начинают работать только если AD DS connection был создан автоматически, посредством KCC. Такие AD DS connections имеют имя <automatically generated>, это если вы вдруг не знали :). Если же в вашей организации KCC по какой-то причине не доверяют и создают соединения вручную, то увы и ах, в той статье нам предлагали довольствоваться 15-минутным интервалом репликации.

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

Итак, у нас есть инструкция, ~~шаловливые ручки~~ энтузиазм и немного свободного времени. Давайте пробовать!

Собираем полигон из двух виртуальных контроллеров домена под управлением Windows Server 2012 Datacenter Edition.
Уровень леса и домена Windows Server 2012. Оба контроллера являются серверами DNS и серверами глобального каталога, находятся в одном сетевом сегменте.

Разносим контроллеры по разным сайтам:

После этого вручную создаем дублирующие AD DS Connections, подталкиваем репликацию и затем удаляем автоматически сгенерированные соединения.

Note! Настоятельно рекомендую заменять соединения в указанном порядке, чтобы в любой момент времени между контроллерами существовала как минимум одна пара AD DS Connections, иначе может порушиться репликация, во всяком случае на некоторое время. Для надежности после каждого изменения вручную подталкивайте репликацию.

На контроллере ReplTest-DC2 в окне PowerShell запускаем скрипт:

Он позволит нам в реальном времени (раз в секунду) отслеживать изменение Up-To-Dateness vector контроллера ReplTest-DC2, выделяя из него строку, относящуюся к партнеру репликации с именем ReplTest-DC1.

Обратите внимание, в выделенной строке USN изменился с 12575 на 12605. Это произошло после того, как на ReplTest-DC1 был создан тестовый юзер и репликация была инициирована вручную.

Итак, мы убедились что репликация работает. Переходим непосредственно к проверке статьи Джонатана.

Устанавливаем четвертый бит атрибута Options в единицу для вручную созданного AD DS Connection (для верности я сделал это для обоих соединений: от ReplTest-DC1 и от ReplTest-DC2).

Не забываем подтолкнуть репликацию.

После этого редактируем произвольный атрибут произвольного объекта на ReplTest-DC1. Я, например, поменял поле Description у недавно созданного юзера.

Смотрим на состояние репликации на ReplTest-DC2:

Ноль реакции! USN не меняется!
Ждем пять секунд… ничего не меняется, ждем пять минут… опять не меняется!
Пытаемся проделать зеркальную операцию: вносим изменения в AD на ReplTest-DC2 и отлеживаем изменения на ReplTest-DC1. Тот же результат.

Несколько часов разнообразных тестов не изменили картины.

Признаюсь, я ожидал этого, потому что еще тогда, прекрасным весенним утром, я уже проделал те же самые действия для 2008 контроллеров.

Это печалит, но в данным момент я вынужден констатировать:

Возможно, в статье опущен какой-то шаг или существуют дополнительные требования, но результат обескураживает. Я привык верить статьям команды AD DS.

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

Наконец-то собрался переписать свои заметки по теме из черновика в тетрадке в электронный формат. Изложить постарался максимально кратко и ёмко.

1. Основные сведения

Все данные Active Directory хранятся в специализированной базе данных на движке ESENT. Физически она представляет собой файл NTDS.DIT. Все изменения в AD производятся на конкретном контроллере домена и вносятся в его NTDS.DIT и лишь потом эти изменения передаются на остальные контроллеры домена.

Логически база данных состоит из четырёх разделов:

Schema — содержит описания объектов и их атрибутов, которые могут быть созданы в AD. Меняется редко — при процедуре расширения схемы, которая производится, например, при установке MS Exchange или при апгрейде ОС контроллеров домена. Расширение схемы необратимо, его нельзя откатить никак, кроме способа восстановления всех DC, успевших реплицировать данные, из бэкапа. Репликацию данного раздела может инициировать только контроллер домена, имеющий роль Schema master. Реплицируется на все контроллеры леса.

Configuration — содержит сведения о конфигурации AD (сколько доменов, сайтов, сайтлинков и т.д.). Инициатором репликации может выступать любой DC. Реплицируется на все контроллеры леса.

Domain — содержит учётные записи (пользователей, группы, компьютеры, принтеры…). Инициатором выступает любой DC. Реплицируется на все контроллеры домена.

Следует иметь ввиду, что связи, созданные вручную, сервисом KCC не управляются, то есть восстанавливать им замену, в случае недоступности одного из партнёров по репликации, сервис не будет.

Можно не ждать 15 минут, и инициировать создание связей силами KCC принудительно:

repadmin /kcc — принудительное создание связи для

repadmin /kccsite — принудительное создание связей для всех DC в сайте

repadmin /kcc * — запустить процесс на всех контроллерах доменов в лесу.
2. Механизмы репликации

На каждом контроллере домена ведётся учёт количества изменений с помощью счётчика highestCommittedUSN. Создание/изменение объекта включает в себя создание/изменение нескольких атрибутов, каждое из которых увеличивает highestCommittedUSN на 1. Каждый атрибут, помимо прочих, имеет параметры:

Посмотреть атрибуты и значения их параметров объекта можно командой repadmin /showmeta. Например:

В случае конфликтов:

сравнивается параметр Ver конфликтного атрибута. Чей выше, тот и прав.
если Ver равны, сравнивается время изменения. Чьё позже, тот и прав.
если и время равно, то прав будет контроллер домена с большим GUID.
В случае, если на двух контроллерах одновременно создали учётную запись с одинаковым именем, более ранняя будет переименована (старое имя+GUID контроллера)
В случае, если на одном контроллере в какой-то OU создаётся объекта, а на другом в это же время удаляется OU, объект, в ходе репликации, будет перенесён в служебный контейнер «Lost and Found«

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

Принудительный запуск репликации:

repadmin /syncall — синхронизация указанного сервера со всеми партнёрами по репликации.
2.1 Внутрисайтовая репликация

Через 15 секунд после внесения изменений, контроллер домена оповещает своих партнёров о необходимости репликации. Если партнёров несколько, то каждому следующему оповещение отправляется с 3-секундной задержкой.

repadmin /notifyopt — настройка таймингов оповещений.

Изменение пароля пользователя и блокировка учётной записи инициируют репликацию без 15-секундной задержки.

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

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

За репликацию между сайтами отвечают не все подряд контроллеры доменов, а в каждом сайте выбирается специально обученный — Bridgehead (сервер плацдармов). То есть именно он занимается репликацией изменений данного сайта с аналогичным bridgehead’ом другого сайта. Как и в случае с репликационными связями между контроллерами доменов, за выбор сервера-плацдарма отвечает служба KCC. Точно также эта служба не работает с назначенными вручную Bridgehead’ами и если таковой выйдет из строя, репликация скорее всего будет невозможна (если не был также вручную назначен ещё один-несколько).

repadmin /bridgeheads — посмотреть текущие серверы плацдармов.

Стоит также упомянуть тут такое явление, как Site Link Bridging — связь между Site1 и Site3 через сеть Site2, но минуя контроллеры домена, расположенные в Site2. То есть используя только маршрутизируемую сеть. Это при условии, что между Site1 и Site3 прямой связи нет, а контроллеры домена в Site2 по какой-то причине оказались недоступны.

Такой бриджинг настраивается также автоматически пресловутой службой KCC. Можно отключить (галочка в свойствах протокола-транспорта в оснастке Active Directory Sites and Services). К сожалению, автоматизация включается/отключается только полностью для всех сайтов. Однако, можно создать вручную только для нужных, предварительно отключив автоматику.

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

На картинке вначале статьи можно увидеть два таких моста — от DC3 к DC2 и от DC8 к DC1.
3. Диагностика репликации

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

В качестве отправной точки для диагностики, неплохой идеей будет использовать анализ логов Directory Services на проблемном контроллере домена.

Также поможет dcdiag /test:connectivity, а ещё nslookup, как средство проверки правильной работы DNS.

Ну и конечно repadmin. Часть его ключей описана выше, ещё часть можно увидеть в справке (repadmin /?), а кое-что — в расширенной справке (repadmin /? /experthelp).

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

На страницах журнала нам уже приходилось рассказывать о различных способах решения проблем репликации Active Derictory (AD). Четкое понимание того, как работает репликация при изменениях в каталоге, помогает устранять проблемы репликации AD на более глубоком уровне. Служба AD стала одним из первых каталогов LDAP, в котором была введена репликация с несколькими хозяевами, позволяющая вносить изменения в любую копию каталога (то есть на любом контроллере домена — DC). До этого, например в системе Windows NT 4.0, изменения могли выполняться только на одном контроллере домена — основном контроллере домена (PDC). , показанной на рисунке.

Рисунок 1. Простейший пример топологии репликации

Отслеживание процессов репликации

Служба AD использует несколько счетчиков и таблиц, позволяющих гарантировать наличие точной информации о каждом параметре и объекте на каждом контроллере домена и избежать зацикливания процессов репликации. Служба AD использует контексты именования (NC), также известные как разделы каталога, для сегментации репликации. Каждый лес имеет как минимум три контекста именования: контекст именования домена, контекст именования конфигурации и контекст именования схемы. Служба AD также поддерживает специальные контексты именования, более известные как разделы приложений или недоменные контексты именования (NDNC). Контексты NDNC используются службой DNS (например, DomainDnsZones, ForestDnsZones). Каждый контекст именования или недоменный контекст именования реплицируются независимо друг от друга.

Каждый контроллер домена содержит специальный счетчик, известный как счетчик номера последовательного обновления USN. Номер USN — это 64-разрядное число, которое вы можете рассматривать как часы. Значение счетчика USN никогда не уменьшается, а номер USN никогда не повторяется. Каждый контроллер домена содержит отдельный счетчик USN, который начинает отсчет в момент запуска процесса Dcpromo и продолжает увеличивать значения в течение всего времени существования контроллера домена. Маловероятно, что два контроллера домена в лесу будут одновременно иметь одинаковые номера USN. Значение счетчика USN увеличивается каждый раз, когда на контроллере домена происходит транзакция. В основном транзакции — это операции создания, обновления или удаления объекта. Транзакция обновления может состоять из обновлений только одного параметра или из обновлений множества параметров. В случае если транзакция не прошла и была отменена, номер USN, присвоенный ей, больше использоваться не будет. Когда объект изменяется (или создается), его параметру usnChanged присваивается номер USN транзакции, которая вызвала это изменение. Таким образом можно проследить изменения в каталоге AD, запросив у контроллера домена все объекты, у которых значение параметра usnChanged выше, чем последний зафиксированный номер USN.

В таблице 1 приведен простой пример изменений номеров USN у двух контроллеров домена с течением времени. Рассмотрим случай, когда вы создаете 5 новых групп на контроллере домена А. Это действие увеличит значение счетчика USN у контроллера домена А на пять единиц. Затем контроллер домена А реплицирует эти группы на контроллер домена B, значение счетчика USN которого также увеличится на пять единиц. Отметим, что начальные значения USN в таблице 1 были выбраны только для примера. Далее вы редактируете имя одной из групп на контроллере домена B. Значение счетчика USN контроллера домена B увеличивается на единицу. Когда изменение имени реплицируется на контроллер домена А, значение его счетчика USN также увеличивается на единицу.

Таблица 1. Изменение USN

Создание пяти групп — это, с точки зрения контроллера домена A, исходная запись. С точки зрения контроллера домена B, это репликационная запись. И наоборот, когда имя группы обновилось на контроллере домена B, он посчитал это действие исходной записью, а контроллер домена А посчитал его репликационной записью.

Процесс репликации AD идентифицирует все контроллеры домена, участвующие в этом процессе, с помощью двух глобальных уникальных идентификаторов GUID. Первый глобальный уникальный идентификатор, идентификатор агента службы каталогов DSA, задается во время выполнения процесса Dcpromo и не меняется в течение всего времени существования контроллера домена. Этот идентификатор хранится в параметре objectGuid объекта NTDS Settings, размещенного внутри узла DC консоли Active Directory Sites and Services. Второй глобальный уникальный идентификатор, идентификатор вызова Invocation ID, — это идентификатор контроллера домена, полученный во время процесса репликации. Он может со временем меняться.

Теперь, когда вы знаете, как процесс репликации отслеживает контроллеры домена и изменения, мы можем рассмотреть, каким образом система определяет, какие изменения необходимо реплицировать на заданный контроллер домена, а какие в репликации не нуждаются. Для этого нам понадобится две таблицы: High-Watermark Vector (HWMV) и Up-To-Dateness Vector (UTDV). Таблица HWMV используется независимо каждым контроллером домена, для того чтобы отследить точку прекращения репликации контекстного именования с заданным партнером (с учетом последнего номера USN). Таблица UTDV используется контроллерами домена, чтобы гарантировать отсутствие ненужных процессов репликации или циклов. Когда контроллер домена А посылает запрос контроллеру домена B, он добавляет в него таблицу UTDV, чтобы контроллер домена B отправил только те изменения, которые не получил контроллер домена А (например, в случае если изменения, произведенные на контроллере домена B, были реплицированы на контроллер домена С, с которого в свою очередь были реплицированы на контроллер домена А).

В таблице 2 приведена таблица HWMV контроллера домена А после изменений, зафиксированных ранее в таблице 1. В таблице 3 приведена таблица HWMV контроллера домена B после изменений, зафиксированных ранее в таблице 1.

Таблица 2. Таблица High-Watermark Vector (HWMV) контроллера DC-A

Таблица 3. Таблица High-Watermark Vector (HWMV) контроллера DC-B

Таким образом, каждый контроллер домена содержит независимый, изменяющийся только в сторону увеличения счетчик — счетчик USN. Значение счетчика USN на контроллере домена увеличивается каждый раз, когда на контроллере домена создается исходная запись (такая, как создание, удаление или обновление) в каталоге. Когда контроллеры домена производят репликацию, они создают запрос обо всех изменениях, которые произошли с момента установки последнего номера USN на этом контроллере домена. Данный номер USN хранится в таблице HWMV для того, чтобы контроллеры домена не запрашивали изменения, которые уже получили. В каждый запрос о репликации контроллеры домена добавляют свои таблицы UTDV. Каждый контроллер домена содержит таблицу UTDV для каждого реплицированного контекста именования, и внутри этой таблицы контроллер домена отслеживает наибольший исходный номер USN обновления, для которого были получены изменения, по каждому из контроллеров домена, реплицирующих соответствующий контекст именования. Такой подход предотвращает зацикливание и позволяет реализовать модель поведения, известную как распространение с затуханием, которая гарантирует, что обновления не будут реплицироваться без необходимости.

Отслеживаем обновления объекта

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

название параметра;
отметка о времени изменения;
номер версии параметра;
исходный идентификатор контроллера домена (глобальный уникальный идентификатор DSA);
исходный номер USN контроллера домена.

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

Создание учетной записи пользователя на контроллере домена А.
Репликация объекта пользователя на контроллер домена В.
Изменение параметра объекта пользователя на контроллере домена В.
Репликация изменения обратно на контроллер домена А.

После создания учетной записи пользователя на контроллере домена А (как в шаге 1) метаданные репликации нового пользователя будут выглядеть аналогично содержимому таблицы 4. Чтобы упростить пример, я задал только три параметра (имя, фамилия, пароль), однако при реальном создании учетной записи задается намного больше параметров.

Таблица 4. Метаданные репликации нового пользователя на контроллере DC-A

Параметру usnCreated на контроллере домена А перманентно назначается значение 5001. Параметру usnChanged также присваивается значение 5001; однако этот параметр будет меняться каждый раз, когда изменения пользовательского объекта будут произведены (созданы) данным контроллером домена или будут получены (реплицированы) с других контроллеров. После репликации нового пользователя на контроллер домена B (шаг 2), метаданные репликации на контроллере домена В будут соответствовать содержимому таблицы 5.

Таблица 5. Метаданные репликации нового пользователя на контроллере DC-B

Когда на контроллере домена B происходит изменение пароля пользователя (шаг 3), метаданные для параметра пароля unicodePwd обновляются (таблица 6). Затем изменение реплицируется обратно на контроллер домена А, что приводит к обновлению локальных метаданных пользователя, согласно таблице 7.

Таблица 6. Обновленные метаданные репликации пользователя на контроллере DC-B

Таблица 7. Обновленные метаданные репликации пользователя на контроллере DC-A

Расшифровка истории объекта

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

Чтобы просмотреть метаданные репликации объекта, необходимо указать, какой контроллер домена будет запрашивать метаданные, а также уникальное имя объекта, для которого выполняется запрос. Чтобы просмотреть метаданные пользователя, можно ввести следующую команду для пользователя 'User A’ на контроллере DC-A:

Выходные данные будут аналогичны результатам, приведенным на экране.

Экран. Метаданные репликации пользовательского объекта

По результатам выполнения команды можно увидеть, что учетная запись пользователя была создана 24 марта 2008 года на контроллере домена А. Этот вывод сделан на основе отметки о времени изменения и начальном идентификаторе DSA параметра objectClass, версия которого имеет значение 1. В некоторых случаях параметр objectClass может быть изменен, и ответ придется искать с помощью других параметров (например, в метаданных параметра objectGuid). 22 марта 2010 года параметр givenName (имя) был изменен на контроллере домена B, о чем свидетельствуют все те же столбцы начального идентификатора DSA и отметки о времени изменения. По номеру версии можно определить, сколько раз параметр был изменен.

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

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

Последний из возможных вариантов — случай, когда подразделение или контейнер удаляется, но до того, как это удаление реплицируется на другие контроллеры домена, другой администратор создает дочерний объект внутри этого подразделения или контейнера. Простой пример: вы закрываете офис, например в Чикаго, поэтому удаляете подразделение для Чикаго. Тем временем администратор в Сан-Франциско отправляет учетную запись нового пользователя в подразделение Чикаго. Когда репликация удаления подразделения Чикаго дойдет до Сан-Франциско, служба AD не удалит учетную запись пользователя, который был послан в Чикаго. Вместо этого служба AD отправит объект пользователя в контейнер LostAndFound, размещенный в корне домена (или, в случае репликации контекстного именования конфигурации, в контейнер LostAndFoundConfig).

Сложные задачи

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

Читайте также: