Active Directory: глубины репликации

На страницах журнала нам уже приходилось рассказывать о различных способах решения проблем репликации 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, — это идентификатор контроллера домена, полученный во время процесса репликации. Он может со временем меняться.

Идентификатор вызова хранится в параметре invocationId объекта NTDS Settings. Каждый раз во время восстановления системы на контроллере домена одним из поддерживаемых механизмов восстановления, таким как Windows Server Backup или NTBACKUP, идентификатор вызова этого контроллера домена сбрасывается. Сбрасывая идентификатор вызова, служба AD гарантирует, что контроллер домена получит копии всех изменений, произошедших на нем за период между созданием резервной копии и временем восстановления системы. Так как идентификатор вызова уникален для контроллера домена во время процесса репликации, сброс идентификатора вызова гарантирует, что контроллер домена войдет в процесс репликации как новый контроллер домена и система не будет «беспокоиться» о данных, которые уже могут быть на этом контроллере домена. Неправильное восстановление виртуального контроллера домена, например восстановление из копии или возврат к снимку, не сбрасывает идентификатор вызова. Это приводит к ситуации, известной как отмена номера USN, которая влечет за собой серьезные проблемы репликации.

Теперь, когда вы знаете, как процесс репликации отслеживает контроллеры домена и изменения, мы можем рассмотреть, каким образом система определяет, какие изменения необходимо реплицировать на заданный контроллер домена, а какие в репликации не нуждаются. Для этого нам понадобится две таблицы: 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

Таблица UTDV содержит наибольший исходный номер USN обновления, который контроллер домена получает от всех остальных контроллеров домена, реплицирующих данный контекст именования. Благодаря этой информации на контроллеры домена никогда не будут отправлены изменения, уже полученные другим путем (например, если изменение произошло на контроллере домена А, а контроллер домена С получил его через контроллер домена B. Такое поведение часто называют «распространением с затуханием». С помощью таблицы UTDV контроллер домена, посылающий информацию, способен определить, какие изменения не были посланы на контроллер домена, запросивший репликацию, а также не посылать изменения, полученные через другие контроллеры домена. Это позволяет избежать зацикливания процессов репликации изменений между контроллерами домена.

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

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

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

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

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

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

После создания учетной записи пользователя на контроллере домена А (как в шаге 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:

repadmin
/showobjmeta "DC-A" "CN=User
A, CN=Users, DC=contoso, DC=com"

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

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

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

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

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

В случае конфликтов на уровне объектов проблема заключается в недопустимости существования двух объектов с одинаковыми относительными уникальными именами (RDN) в одном контейнере. Если вы создали пользователя «Джон Доу» в каталоге AD, то по умолчанию этому пользователю будет присвоено имя RDN ‘CN=John Doe’. Если другой администратор создаст учетную запись для Джона Доу на другом контроллере домена в том же контейнере, до того как первый объект будет реплицирован, изменение будет разрешено, однако во время репликации службе AD нужно будет разобраться с дублирующими именами RDN. Служба AD решает эту задачу следующим образом: оставляет неизменным имя RDN объекта с наиболее поздней отметкой о времени изменения и переименовывает более старый объект (старые объекты), добавляя к имени объекта идентификатор GUID (например, «более ранний» Джон Доу будет иметь такое имя RDN: ‘CN=John Doe\0 ACNF:’). В случае когда конфликт вызван переименованием объекта, а не созданием нового, сначала учитывается номер версии параметра RDN (чаще всего это параметр CN). «Побеждает» объект с наибольшим номером версии.

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

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

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

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

Брайан Десмонд (brian@briandesmond.com) — старший консультант компании Moran Technology Consulting (Чикаго). Имеет сертификат Directory Services MVP. Автор книги «Active Directory», ведет блог www.briandesmond.com