Отметки об изменениях и разрешение конфликтов
И последнее, что используется для управления репликацией между контроллерами домена, — это отметка об изменении (change stamp). Всякий раз, когда атрибут модифицируется, эта модификация помечается отметкой об изменении. Затем отметка об изменении посылается вместе с модификацией, когда модификация копируется на другие контроллеры домена. Отметка об изменениях используется для того, чтобы определить, какое изменение будет принято в случае конфликта репликации. Отметка об изменениях состоит из трех компонентов.
Номер версии. Он используется для отслеживания количества изменений, которые были сделаны к атрибуту объекта. Когда объект создается, номер версии у всех атрибутов устанавливается на 1, даже если поле атрибута оставлено пустым. Когда происходит назначение «пустого» атрибута, значение номера версии остается равным 1. Однако когда атрибут обновляется после начального изменения, номер версии каждый раз увеличивается на единицу.
Время последней записи. Оно используется для отслеживания времени, когда произошла последняя модификация атрибута. Значение времени регистрируется на том сервере, где атрибут был модифицирован, и копируется вместе с объектом на другие контроллеры домена.
Исходный сервер (Originating server). Этот компонент представляет собой GUID сервера, на котором была применена последняя исходная модификация атрибута.
Эти три компонента формируют отметку об изменениях для каждой модификации атрибута. Когда атрибут копируется на другой контроллер домена, эта информация копируется вместе с атрибутом. Если один и тот же атрибут изменен на двух различных контроллерах домена одновременно, то отметка об изменениях используется для определения того, какой атрибут будет принят в качестве заключительного изменения. В случае конфликта решение относительно заключительного изменения делается в следующем порядке.
Номер версии. Всегда принимается изменение с самым высоким номером версии. Если изменение на одном контроллере домена имеет номер версии 3, а изменение на другом контроллере домена - номер версии 4, будет всегда приниматься изменение с номером версии 4.
Время последней записи. Если номера версий идентичны, то будет принято изменение с самым недавним временем последней записи.
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, где значок номера (#) является символом дублирования. Если второй пользовательский объект потребуется, то его можно будет переименовать.
Содержание раздела
