Процесс репликации

🕛 19.01.2009, 20:30

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

Типы обновлений

Существуют два типа обновлений информации Active Directory, касающейся определенного контроллера домена. Первый тип обновлений - исходное обновление (originating update). Исходное обновление выполняется при добавлении, изменении или удалении объекта на контроллере домена. Второй тип обновлений - реплицируемое обновление (replicated update). Репликация выполняется тогда, когда изменение, сделанное на одном контроллере домена, копируется на другой контроллер домена. По определению исходное обновление, касающееся любого конкретного изменения, только одно, оно выполняется на том контроллере домена, где было сделано. Затем исходное обновление копируется на все контроллеры домена, которые имеют реплику раздела Active Directory, затронутого обновлением.

Исходные обновления Active Directory происходят в следующих случаях:
* к Active Directory добавлен новый объект; * из Active Directory удален существующий объект; * атрибуты существующего объекта изменены. Эта модификация может включать добавление нового значения атрибуту, удаление значения атрибута или изменение существующего значения; * объект Active Directory перемещен в новый родительский контейнер. Если изменяется имя родительского контейнера, то каждый объект контейнера перемещается в переименованный контейнер.

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

Репликация изменений

После передачи исходного обновления изменение должно реплицироваться на другие контроллеры домена, которые содержат реплику этого раздела. В пределах сайта контроллер домена, на котором произошло исходное обновление, ждет 15 с перед началом копирования изменений своим прямым партнерам по репликации. Это ожидание предназначено для того, чтобы несколько модификаций к базе данных можно было реплицировать одновременно, что увеличивает эффективность репликации. Между сайтами исходное обновление будет копироваться партнерам по репликации в соответствии с графиком, сконфигурированным на связях сайта.

Для репликации изменений информации каталога контроллерам домена требуется механизм для управления потоком репликации. Для оптимизации репликации Active Directory следует пересылать только те изменения, которые должны реплицироваться между двумя контроллерами домена. Контроллеры домена должны уметь определять эти изменения, если таковые вообще имеются, а затем копировать только ту часть изменений, которая требуется. Для управления репликацией каталога в Active Directory используются порядковые номера обновлений (USN - update sequence number), значения уровня (high-watermark value), векторы новизны (up-to-dateness vectors) и отметки об изменениях (change stamps). Эти компоненты обсуждаются далее.

Порядковые номера обновлений

Когда объект базы данных модифицируется, то изменению присваивается порядковый номер обновления. Порядковые номера обновления (USN - update sequence number) являются спецификой баз данных сервера. Например, если изменению номера телефона одного из пользователей был назначен номер USN 5555, то следующее изменение базы данных, независимо от изменяемого объекта, будет иметь номер USN 5556. Один номер USN назначается для каждого совершенного изменения. Если в одной модификации

изменено несколько атрибутов (например, адрес, номер телефона и местоположение офиса), то этой модификации назначается только один USN.

Существует три способа использования USN при выполнении модификаций. Во-первых, локальное значение USN сохраняется вместе с атрибутом, который был модифицирован. Локальное значение идентифицирует USN измененного атрибута. Во-вторых, USN используется для атрибута uSNChanged объекта. Этот атрибут хранится с каждым объектом и идентифицирует самый высокий USN для атрибутов данного объекта. Рассмотрим пример. Предположим, что был изменен номер телефона пользователя, и этому изменению был назначен USN, равный 5556. И локальный USN, и атрибут uSNChanged будут установлены на 5556. Если следующая модификация, сделанная в каталоге на том же сервере, состоит в изменении адреса того же самого пользователя, то местный USN на атрибуте адреса и атрибут uSNChanged для пользовательского объекта будут изменены на 5557. Однако местный USN для атрибута номера телефона останется равным 5556, потому что это USN для последней модификации этого конкретного атрибута.

Локальный USN и атрибут uSNChanged относятся как к исходным, так и к реплицируемым обновлениям. В последнем способе USN используется как USN исходной модификации атрибута. Это значение устанавливается только для исходных модификаций, оно копируется на все другие контроллеры домена как часть репликации атрибутов. Когда на сервере изменяется номер телефона пользователя, то USN этого изменения назначается равным исходному значению USN. Когда измененный номер телефона копируется на другой контроллер домена, исходный USN посылается вместе с модификацией, и это значение не изменяется на контроллере домена адресата. Локальный USN и атрибут uSNChanged будут изменены на контроллере домена адресата, но исходный USN не изменится до тех пор, пока сам атрибут не будет снова модифицирован. Исходный USN используется для демпфирования распространения, которое рассматривается далее в этой главе.

Значения уровней

Значения уровней (high-watermark values) используются для управления тем, какая информация реплицируется между контроллерами домена. Каждый контроллер домена поддерживает свой собственный набор уровней для каждого из своих прямых партнеров по репликации. Уровень -это последнее значение uSNChanged, которое контроллер домена получил от определенного партнера по репликации. Когда контроллер домена посылает модификацию партнеру по репликации, значение uSNChanged посылается вместе с модификацией. Контроллер домена адресата сохраняет его как значение уровня для партнера по репликации.

Значения уровней используются во время процесса репликации. Когда один контроллер домена запрашивает обновление у другого контроллера домена, то контроллер-адресат посылает свое значение уровня контроллеру-отправителю. Контроллер-отправитель использует значение уровня контроллера-адресата для фильтрации всех потенциальных обновлений и посылает только те изменения, которые имеют более высокое значение uSNChanged.

Примечание. Значение уровня поддерживается отдельно для каждого раздела каталога на контроллере домена и для каждого прямого партнера по репликации.

Векторы новизны и демпфирование распространения

Векторы новизны (up-to-dateness vectors) также используются для управления тем, какая информация должна копироваться между контроллерами домена. Векторы новизны используются для отслеживания всех исходных модификаций, которые данный контроллер домена получил от какого-либо контроллера домена. Например, изменен номер телефона пользователя на контроллере домена DC1, и атрибуту назначен исходный USN, равный 5556. Когда этот атрибут реплицируется на контроллер DC2, исходный USN копируется с обновленным атрибутом. Кроме того, GUID контроллера DC1 реплицируется вместе с атрибутом. Когда DC2 получает это обновление, он модифицирует свой вектор новизны, показывая, что самое последнее исходное обновление, полученное от DC1, теперь равно 5556. Вектор новизны используется для ограничения трафика репликации между контроллерами домена. Когда контроллер-адресат запрашивает обновление у контроллера-отправителя, он включает в запрос свои векторы новизны. Затем компьютер-отправитель использует эту информацию для фильтрации списка всех возможных модификаций, которые он может послать контроллеру-адресату. Такой выбор важен, когда имеется более двух контроллеров домена для данного раздела каталога. Например, если к сценарию, описанному в предшествующем параграфе, добавить контроллер DC3, то изменение номера телефона, сделанное на DC1, будет копироваться и на DC2, и на DC3. Теперь DC3 и DC2 будут иметь обновленный номер телефона, они изменят свои векторы новизны, показывая, что самая последняя модификация, которую они оба получили от DC1, имела исходный USN 5556. Приблизительно через 15 с после получения этой модификации DC2 уведомит DC3, что у него есть обновленная информация. Когда DC3 будет запрашивать обновления каталога у DC2, он включит свой вектор новизны в запрос. В этом случае DC2 определит, что вектор новизны контроллера DC3 для DC1 уже имеет новейший исходный номер USN. Если модификация номера телефона была единственным изменением, сделанным к каталогу в этот временной период, то информация между контроллерами домена DC2 и DC3 реплицироваться не будет. Процесс ограничения модификаций, посылаемых во время репликации, с помощью вектора новизны называется демпфированием распространения. Как уже говорилось, служба КСС создает избыточные репли-кационные связи между контроллерами домена. Одна из проблем, связанных с этим, состоит в том, что одни и те же модификации могут посылаться контроллеру домена от нескольких партнеров по репликации. Это ведет к увеличению трафика репликации, а также потенциально приводит к ситуации, когда одна и та же модификация посылается неоднократно всем контроллерам домена. Демпфирование распространения, использующее вектор новизны, устраняет такую возможность.

Просмотр информации USN

Номера USN (update sequence number) для любого объекта можно просмотреть с помощью средств администрирования, включенных в инструментальные средства поддержки Windows Server 2003. Один из способов просмотра локального USN исходного контроллера домена, исходного USN и отметки времени (time stamp) для любого атрибута состоит в использовании инструмента командной строки Repadmin. (Полную инструкцию по установке Repadmin смотрите в разделе «Мониторинг и поиск неисправностей репликации» далее в этой главе.) Напечатайте repadmin /showmeta object distinguished name (отличительное имя объекта) в командной строке. Значения uSNCreated и uSNChanged можно увидеть в ADSI Edit через свойства объекта. Чтобы получить доступ к информации репликации через Ldp.exe, найдите объект, щелкните правой кнопкой мыши на объекте, выберите Advanced (Расширенный), затем выберите Replication Metadata (Мета-данные репликации). Значения USN также можно присмотреть через Монитор репликации (см. рис. 4-10). Для этого добавьте сервер к списку мониторинга, а затем щелкните правой кнопкой мыши на сервере и выберите Show Attribute Meta-Data For Active Directory Object (Показать метаданные атрибута для объекта Active Directory). Введите мандат (credentials) для учетной записи с доступом к Active Directory, а затем напечатайте отличительное имя объекта. Часть USN-информации доступна также из обычных средств администрирования. Чтобы посмотреть текущие и исходные значения USN для объекта в инструменте администрирования Active Directory Users And Computers, включите Advanced Features (Расширенные функции) в меню View (Вид), а затем обратитесь к вкладке Object (Объект) в окне Properties (Свойства) объекта.

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

Рис. 4-10. Просмотр мета-данных репликации с помощью Replication Monitor (Монитор репликации)

Отметки об изменениях и разрешение конфликтов

И последнее, что используется для управления репликацией между контроллерами домена, - это отметка об изменении (change stamp). Всякий раз, когда атрибут модифицируется, эта модификация помечается отметкой об изменении. Затем отметка об изменении посылается вместе с модификацией, когда модификация копируется на другие контроллеры домена. Отметка об изменениях используется для того, чтобы определить, какое изменение будет принято в случае конфликта репликации. Отметка об изменениях состоит из трех компонентов.
* Номер версии. Он используется для отслеживания количества изменений, которые были сделаны к атрибуту объекта. Когда объект создается, номер версии у всех атрибутов устанавливается на 1, даже если поле атрибута оставлено пустым. Когда происходит назначение «пустого» атрибута, значение номера версии остается равным 1. Однако когда атрибут обновляется после начального изменения, номер версии каждый раз увеличивается на единицу. * Время последней записи. Оно используется для отслеживания времени, когда произошла последняя модификация атрибута. Значение времени регистрируется на том сервере, где атрибут был модифицирован, и копируется вместе с объектом на другие контроллеры домена. * Исходный сервер (Originating server). Этот компонент представляет собой GUID сервера, на котором была применена последняя исходная модификация атрибута.

Эти три компонента формируют отметку об изменениях для каждой модификации атрибута. Когда атрибут копируется на другой контроллер домена, эта информация копируется вместе с атрибутом. Если один и тот же атрибут изменен на двух различных контроллерах домена одновременно, то отметка об изменениях используется для определения того, какой атрибут будет принят в качестве заключительного изменения. В случае конфликта решение относительно заключительного изменения делается в следующем порядке.
1. Номер версии. Всегда принимается изменение с самым высоким номером версии. Если изменение на одном контроллере домена имеет номер версии 3, а изменение на другом контроллере домена - номер версии 4, будет всегда приниматься изменение с номером версии 4. 2. Время последней записи. Если номера версий идентичны, то будет принято изменение с самым недавним временем последней записи. 3. GXJID сервера. Если номера версий и времена последней записи идентичны, то используется GUID базы данных сервера для определения того, какое изменение должно быть принято. Будет принято изменение, прибывающее с сервера, имеющего более высокий GUID. Идентификаторы GUID назначаются при добавлении контроллера домена к домену, a GUID назначается произвольно.

Практический опыт. Конфликты репликации

Некоторые сетевые администраторы, похоже, очень озабочены возможностью возникновения конфликтов репликации и потенциальной потерей или перезаписью данных. В большинстве компаний вероятность их возникновения невелика. Во-первых, конфликты репликации касаются отдельных атрибутов. (Если номер телефона пользователя изменяется на одном контроллере домена в то же самое время, когда адрес пользователя изменяется на другом контроллере домена, никакой конфликт не возникает.) Во-вторых, большинство компаний имеют централизованный отдел, где делаются все изменения к учетным записям пользователя, так что вероятность того, что два человека сделают различные изменения к одному и тому же атрибуту одновременно, очень мала. Если администрирование учетных записей пользователя делегировано на уровень отдела, то каждый отдел делает изменения только к учетным записям пользователя своего отдела. Таким образом, в большинстве компаний, использующих структурированный способ работы с объектами Active Directory, конфликты репликации происходят очень редко.

Служба Active Directory способна разрешать конфликты, которые создаются, когда один и тот же атрибут объекта изменяется одновременно на двух контроллерах домена. Имеются два других типа конфликтов, которые могут возникать.
* Добавление или изменение объекта на одном контроллере домена в то же самое время, когда контейнерный объект этого объекта удаляется на другом контроллере домена. Рассмотрим пример, в котором на одном контроллере домена был добавлен новый пользователь к организационной единице (OU) Accounting (Бухгалтерия). В это же время на другом контроллере домена другой администратор удаляет OU Accounting. В этом случае объект, который был добавлен к удаленному контейнеру, будет перемещен в контейнер Active Directory с именем LostAndFound. * Добавление объектов с одним и тем же относительным отличительным именем (relative distinguished name) в один и тот же контейнер. Такой конфликт возникает, когда администратор на одном контроллере домена создает пользовательский объект с относительным отличительным именем BDiaz в OU Accounting, в то же самое время на другом контроллере домена пользователь, имеющий такое же относительное отличительное имя, перемещается в ту же самую OU или создается в той же самой OU. В этом случае для определения того, какой объект будет сохранен, а какой переименован, в модели разрешения конфликтов будет использоваться GUID, назначенный модифицируемому каталогу. Объект, имеющий более высокий GUID, будет сохранен, а объект с более низким GUID переименован на BDiaz#CNF:userGUID, где значок номера (#) является символом дублирования. Если второй пользовательский объект потребуется, то его можно будет переименовать.

Репликация удалений объектов

Репликация удалений объектов обрабатывается в Active Directory иначе, чем другие модификации каталога. Когда удаляется учетная записи пользователя, она не уничтожается немедленно. Вместо этого создается объект-памятник (tombstone). Объект-памятник является исходным объектом, у которого атрибут isDeleted установлен на true (истина), а большинство атрибутов объекта удалено. Сохранены только несколько атрибутов, типа GUID, SID, USN и отличительного имени, которые требуются для идентификации этого объекта.

Объект-памятник затем копируется на другие контроллеры домена в домене. По мере того как каждый контроллер домена получает модификацию, модификации, которые были сделаны на исходном контроллере домена, применяются на всех остальных контроллерах. Объекты-памятники остаются в базе данных домена в течение определенного периода времени, называемого временем жизни объекта-памятника (tombstone lifetime). В конце времени жизни объекта-памятника, установленного по умолчанию на 60 дней, каждый контроллер домена удаляет его из своей копии базы

данных. Процесс удаления объектов-памятников из базы данных называется сборкой мусора (garbage collection). По умолчанию интервал времени, через который производится сборка мусора, для леса установлен на 12 часов. Каждые 12 часов выполняется процесс сборки мусора, и удаляются все объекты-памятники, время жизни которых истекло.

В главе 1 говорилось о том, что служба Active Directory Windows Server 2003 обеспечивает поддержку неактивных объектов в Active Directory. Неактивный объект (lingering object) - это объект, который не был удален из контроллера домена, потому что контроллер находился в автономном режиме или был не способен к репликации в течение всего времени жизни объекта-памятника. Для удаления неактивных объектов используется инструмент Repadmin.

Совет. Время жизни объекта-памятника и интервал сборки мусора может быть изменен с помощью ADSI Edit или Ldp.exe. Эти свойства сконфигурированы в объекте CN=Directory Service,CN=Windows NT,CN=Services,CN = Configuration, DC=ForestRootDomain. Атрибуты garbageCollPeriod и tombstoneLifetime определяют эти параметры настройки. В большинстве случаев эти значения менять не требуется.