Какая информация подвержена репликации и механизмы репликации.

Продолжение темы "Репликация". Начало здесь.

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

Вся информация из каталога Active Directory хранится в файле Ntds.dit  (смотрите здесь).  Но сам каталог Active Directory разделен на логические категории (это примерно как мы делим один жесткий диск из нашего компа на 3 логических   диска, допустим C,D, и Е). Эти категории называются разделами каталога (directory partitions) или контекстами наименования (naming context). Так вот эти разделы каталога и являются базовыми единицами репликации.

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

Примечание.  Схемой (schema)  в Active Directory называется список, который определяет виды объектов и типы информации о них. То есть атрибуты тех объектов, которые хранятся в Active Directory. А что у нас по умолчанию хранится в каталоге Active Directory мы с вами уже должны знать из предыдущих статьей. Схему можно расширять  (то есть изменять ее состояние от той, что принята  «по умолчании»  при инсталляции).  НО!, расширение схемы требует очень осторожный подход, так как можем здорово напортачить,  если что-то  не сделали правильно то – схему нельзя удалить (только отключить), а во -  вторых после расширения схемы Active Directory (учитывая и отключение, и включение),  в нашей сети генерируется огромный трафик для синхронизации этого расширения  в масштабе нашего леса. Так что к расширению схемы надо подходить очень осторожно и продумано. Думаю, что к схеме мы еще вернемся, когда усвоим теоретический материал и перейдем к практике непосредственно на ваших компах (посредством применения виртуальных машин, но об этом позже).

Раздел конфигурации. В этом разделе находится описание логической структуры размещения доменов и топологии репликации. Под топологией репликации следует понимать – путь прохождения данных репликации по сети.  Информация из раздела конфигурации, общие для всех доменов леса, и реплицируются на все домены леса. Если проще то об этом разделе можно сказать так - описывают топологию каталога и содержат список всех доменов, деревьев, лесов, а также расположение контроллеров домена и глобальных каталогов (GC).

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

Помимо этих разделов на контроллерах домена под  Windows Server 2003 размещается еще один каталог нового типа – прикладной.

Прикладной каталог (application directory partition). В этом разделе Active Directory приложения и службы которые взаимодействуют с Active Directory, хранят прикладные данные, среди которых могут фигурировать любые объекты за исключением так называемых «участников системы безопасности» (пользователей, групп и компьютеров, о них поговорим в других темах). В целях сокращения трафика репликации возможна явная пересылка данных этого каталога не явно указанный администратором контроллер домена в рамках не только родного домена, но и леса.  То есть прикладной каталог создается службами и приложениями, но так же может быть создан и самим администратором сети (об этом позже).

Как работает репликация.

Как было отмечено выше «раздел схемы» и «раздел конфигурации» всегда одинаковы  для всего леса. В отличие от них «раздел домена»  может  различается от домена к домену и поэтому хранится на контроллерах родного домена. Реплика между контроллерами домена, внутри одного домена является полной. Что под этой фразой стоит понимать? А то, что реплицируются все атрибуты объектов в отличие от частичной (неполной) реплики, в которой реплицируются только самые важные (часто используемые) атрибуты объекта.

Вообще запомните реплика - это копия раздела каталога. 

Так же напомню, что если контроллер домена является сервером глобального каталога, то на нем хранятся:

• Полная реплика того домена членом который является данный контроллер.
• Частичная реплика из других доменов в лесу.  

Этой частичной репликой  глобальный каталог (GC)  обменивается только между глобальными каталогами леса.

Теперь хочу отметить одну важную особенность репликации в Active Directory.  Репликация происходит  не хаотично, а в соответствии с  определенной топологией. Именно благодаря топологии определяется последовательность передачи изменений  протекающих в Active Directory между контроллерами доменов.

 Что следует понимать под термином «топология репликации» в Active Directory?

Под этим следует понимать набор соединений или объекты подключений  (connection objects)  используемых контроллерам домена для обмена данными (репликация)  в целях синхронизации (приведению к одинаковости) общих разделов каталогов Active Directory в масштабах леса.   

Ответственен за создание топологии,  такой встроенный процесс в Active Directory, который называется Knowledge Consistence Checker.  Как видите название мудреное.  О каких знаниях идет речь?  Процесс  KCC  (служба проверки однородности знаний) выполняется через определенный промежуток времени (каждые 15 минут)  и, проверяя доступность контроллеров доменов (может какой-то контроллер крякнулся или недоступен по другой причине, например сеть глючит),  создает связи между ними. Таким образом, речь идет о тех знаниях, известных каждому контроллеру и хранящихся на этих контролерах. То есть знания,  это та информация, которая хранится на контроллерах домена.  И именно КСС (служба проверки однородности знаний) заботится о том, чтобы на каждом контроллере домена хранилась идентичная информация, т. е. он обеспечивает однородность знаний (информации, данных) контроллеров.

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

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

Правила обновления в Active Directory.

 Первое правило.  Режим «получил — сохранил — передал». Поясню его суть на примере: изменения, происшедшие на контроллере домена в Антарктике, не будут сразу переданы на все контроллеры домена в Москве. В соответствии с топологией репликации они будут приняты тем контроллером в Антарктике (а у нас допустим в Антарктике штуки 5 контроллеров домена), через  который проводится репликация с Москвой (сервер-плацдарм). На нем они будут храниться до открытия окна репликации, а потом переданы на московский  сервер-плацдарм (bridgehead servers)  и уж только с него тиражируются по московским  контроллерам. Такое поведение существенно освобождает каналы связи (меньше трафик передачи).

 Второе правило.  Механизм «вытягивания» информации: узнав, что на каком-то из партнеров по репликации произошли изменения, контроллер домена обращается к нему,  и скачивает измененную информацию к себе. Под этим  подразумевается, что при изменении информации на одном из партнеров по репликации он рассылает изменения по остальным партнерам. При этом его не интересует, готов ли партнер к приему и нужны ли ему эти данные.  Получение новой информации  возлагается непосредственно на самом партнере, которому была выслана оповещение об изменении.   Так названый механизм «проталкивания» в репликации Active Directory не применяется. То есть репликация в Active Directory построена на принципе «вытягивания»  информации. Контроллер домена, получивший оповещение  об изменениях реплики у партнера, сам обращается к партнеру по репликации и скачивает эти изменения (механизм «вытягивания»),  а не ждет, что бы ему эти изменения были посланы (механизм «проталкивания»).

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

Как происходят обновления в Active Directory.

Надо отметить, что в Active Directory предусмотрены два механизма репликации данных: внутрисайтовая (intrasite – происходит в границах сайта) и межсайтовая (intersait – происходит между сайтами). Как уже говорилось раньше (смотри здесь), сайт – это набор подсетей IP, связанных между собой высокоскоростными линиями. Связь между сайтами осуществляется по более медленным линиям, часто это WAN-линии. Системный администратор может сам определить подсети и прописать их (если это необходимо)  в Active Directory, в противном случае, AD сама определяет, что все контроллеры вашего домена являются частью единого сайта, создающегося по умолчанию, Default-First-Site (первый сайт по умолчанию). Об этом мы будем говорить позже, и вы увидите, как практически это делается.

Представим, что на одном из контроллеров домена произошли изменения (допустим, ввели нового пользователя).  Обозначим этот момент как Т_0, (смотрите рисунок 1).

Рисунок 1. На рисунке через DC обозначены контроллеры домена.

Контроллер выдерживает после этого «паузу после изменения» и в момент Т_1, сообщает об изменении своему первому партнеру по репликации внутри сайта, затем, выдержав «паузу оповещения», в момент Т₂, оповещает второго партнера. Спустя очередную «паузу оповещения» информируется третий партнер и т. д., пока все партнеры по репликации не будут оповещены. Получив оповещение, партнеры запрашивают изменения сами, "вытягивают" необходимую информацию. Пауза в оповещении позволяет предотвратить одновременное обращение всех контроллеров к своему партнеру.

Длительность «паузы после изменения»  по умолчанию — 5 минут, «паузы оповещения» — 30 секунд. Еще раз подчеркну, что описанный процесс относится только к внутрисайтовой репликации. Межсайтовая репликация выполняется по расписанию.

 Продолжение следует.