Узлы и домены

Тиражирование Active Directory

Active Directory использует тиражирование типа мульти-мастер. Как уже упоминалось, в этой службе каталогов более не существует различий между контроллерами доменов — они все равноправны. Изменения, внесенные в каталог на одном контроллере, тиражируются на остальные.

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

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

- По номеру версии. У каждого свойства свой номер версии. С помощью этого номера определяется «наиболее актуальное», то есть имеющее наибольший номер версии, свойство. Это не всегда верное решение, однако оно позволяет согласовывать версии без дополнительных переговоров с партнером по тиражированию и гарантирует идентичность данных на всех контроллерах доменов.

- По временной отметке. Если свойства имеют одинаковый номер версии, то проверяется временная отметка, создаваемая вместе с номером версии при модификации свойств. При этом предполагается, что все контроллеры домена синхронизованы по времени. Предпочтение отдается версии, созданной позднее. И опять же, это не всегда верно, но лучше обслуживать пользователей, чем заниматься длительными переговорами относительно того, кто «главнее».

- По размеру буфера. Если и номер версии, и временные отметки совпадают, то выполняется сравнение в двоичном виде, причем предпочтение получает то свойство, которое в двоичном виде занимает больший объем. Если размеры одинаковы, то считается, что обе версии идентичны и в расчет не принимается ни одна из них.

Концепция узлов (sites) используется продуктами семейства Microsoft BackOffice для минимизации графика в глобальной сети. К сожалению, в каждом продукте эта концепция трактуется по-своему. В Windows NT 5.0 вводится еще одно новшество: концепция не оптимизирована под какое-либо определенное приложение, а предполагает в качестве основы сеть IP, для которой обеспечиваются наилучшие условия подключений. В будущем планируется, что все приложения BackOffice будут использовать именно эту концепцию узла.

Узел с Active Directory состоит из одной или нескольких подсетей IP. Администратор может определять эти подсети, а также добавлять к ним новые. При этом он исходит из следующих посылок:

- оптимизация графика тиражирования между узлами по медленным линиям;

- создание клиентам наилучших условий для быстрого обнаружения ближайших к ним контроллеров.

Тиражирование внутри узла и между узлами осуществляется по различным топологиям. Внутри узла контроллер домена задерживает оповещение о сделанных изменениях на некоторый устанавливаемый промежуток времени (по умолчанию равный 10 минутам). В отличие от Microsoft Exchange в Active Directory можно изменять топологию тиражирования внутри узла. По умолчанию это двунаправленное кольцо, однако Вы можете полностью переопределить топологию и задать ее, скажем, в виде звезды.

В любом случае служба каталогов будет отслеживать целостность топологии, то есть ни один контроллер домена не будет исключен из процесса тиражирования. Для этого на всех контроллерах домена исполняется отдельный контрольный процесс, так называемый КСС (Knowledge Consistency Checker). КСС восстанавливает топологию тиражирования в случае нарушения.

Концепция поиска ближайшего ресурса или контроллера домена позволяет сократить трафик в низкоскоростных частях глобальных сетей. Для поиска ближайших ресурсов или контроллеров домена клиенты могут использовать информацию об узле. Начиная вход в сеть, клиент получает от контроллера домена имя узла, к которому принадлежит, имя узла к которому относится контроллер домена, а также информацию о том, является ли данный контроллер домена ближайшим к клиенту. Если это не ближайший контроллер, то клиент может обратиться к контроллеру домена в собственном узле и в дальнейшем работать с ним, как с ближайшим контроллером. Так как данная информация сохраняется в реестре, клиент может ее использовать при следующем входе в сеть.

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

Дата добавления: 2014-01-04