Как сделать репликацию между контроллерами домена

Добавил пользователь Алексей Ф.
Обновлено: 04.10.2024

Наконец-то собрался переписать свои заметки по теме из черновика в тетрадке в электронный формат. Изложить постарался максимально кратко и ёмко.

1. Основные сведения

Все данные Active Directory хранятся в специализированной базе данных на движке ESENT. Физически она представляет собой файл NTDS.DIT. Все изменения в AD производятся на конкретном контроллере домена и вносятся в его NTDS.DIT и лишь потом эти изменения передаются на остальные контроллеры домена.

Логически база данных состоит из четырёх разделов:

Schema — содержит описания объектов и их атрибутов, которые могут быть созданы в AD. Меняется редко — при процедуре расширения схемы, которая производится, например, при установке MS Exchange или при апгрейде ОС контроллеров домена. Расширение схемы необратимо, его нельзя откатить никак, кроме способа восстановления всех DC, успевших реплицировать данные, из бэкапа. Репликацию данного раздела может инициировать только контроллер домена, имеющий роль Schema master. Реплицируется на все контроллеры леса.

Configuration — содержит сведения о конфигурации AD (сколько доменов, сайтов, сайтлинков и т.д.). Инициатором репликации может выступать любой DC. Реплицируется на все контроллеры леса.

Domain — содержит учётные записи (пользователей, группы, компьютеры, принтеры…). Инициатором выступает любой DC. Реплицируется на все контроллеры домена.

Следует иметь ввиду, что связи, созданные вручную, сервисом KCC не управляются, то есть восстанавливать им замену, в случае недоступности одного из партнёров по репликации, сервис не будет.

Можно не ждать 15 минут, и инициировать создание связей силами KCC принудительно:

repadmin /kcc — принудительное создание связи для

repadmin /kccsite — принудительное создание связей для всех DC в сайте

repadmin /kcc * — запустить процесс на всех контроллерах доменов в лесу.
2. Механизмы репликации

На каждом контроллере домена ведётся учёт количества изменений с помощью счётчика highestCommittedUSN. Создание/изменение объекта включает в себя создание/изменение нескольких атрибутов, каждое из которых увеличивает highestCommittedUSN на 1. Каждый атрибут, помимо прочих, имеет параметры:

Посмотреть атрибуты и значения их параметров объекта можно командой repadmin /showmeta. Например:

В случае конфликтов:

сравнивается параметр Ver конфликтного атрибута. Чей выше, тот и прав.
если Ver равны, сравнивается время изменения. Чьё позже, тот и прав.
если и время равно, то прав будет контроллер домена с большим GUID.
В случае, если на двух контроллерах одновременно создали учётную запись с одинаковым именем, более ранняя будет переименована (старое имя+GUID контроллера)
В случае, если на одном контроллере в какой-то OU создаётся объекта, а на другом в это же время удаляется OU, объект, в ходе репликации, будет перенесён в служебный контейнер «Lost and Found«

Репликация всегда происходит в режиме Pull (вытягивание), поскольку каждый контроллер единолично отвечает за целостность своей базы данных.

Принудительный запуск репликации:

repadmin /syncall — синхронизация указанного сервера со всеми партнёрами по репликации.
2.1 Внутрисайтовая репликация

Через 15 секунд после внесения изменений, контроллер домена оповещает своих партнёров о необходимости репликации. Если партнёров несколько, то каждому следующему оповещение отправляется с 3-секундной задержкой.

repadmin /notifyopt — настройка таймингов оповещений.

Изменение пароля пользователя и блокировка учётной записи инициируют репликацию без 15-секундной задержки.

Кроме того, репликация происходит по расписанию каждый час. На случай, если во время инициирования репликации по изменению, целевой контроллер был недоступен или был занят дефрагментацией базы.
2.2 Межсайтовая репликация

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

За репликацию между сайтами отвечают не все подряд контроллеры доменов, а в каждом сайте выбирается специально обученный — Bridgehead (сервер плацдармов). То есть именно он занимается репликацией изменений данного сайта с аналогичным bridgehead’ом другого сайта. Как и в случае с репликационными связями между контроллерами доменов, за выбор сервера-плацдарма отвечает служба KCC. Точно также эта служба не работает с назначенными вручную Bridgehead’ами и если таковой выйдет из строя, репликация скорее всего будет невозможна (если не был также вручную назначен ещё один-несколько).

repadmin /bridgeheads — посмотреть текущие серверы плацдармов.

Стоит также упомянуть тут такое явление, как Site Link Bridging — связь между Site1 и Site3 через сеть Site2, но минуя контроллеры домена, расположенные в Site2. То есть используя только маршрутизируемую сеть. Это при условии, что между Site1 и Site3 прямой связи нет, а контроллеры домена в Site2 по какой-то причине оказались недоступны.

Такой бриджинг настраивается также автоматически пресловутой службой KCC. Можно отключить (галочка в свойствах протокола-транспорта в оснастке Active Directory Sites and Services). К сожалению, автоматизация включается/отключается только полностью для всех сайтов. Однако, можно создать вручную только для нужных, предварительно отключив автоматику.

Если контроллеры домена в промежуточном сайте вновь вернулись в работу, то и автоматические и созданные вручную мосты перестают использоваться и репликация идёт своим естественным путём.

На картинке вначале статьи можно увидеть два таких моста — от DC3 к DC2 и от DC8 к DC1.
3. Диагностика репликации

Подробно расписывать процедуры диагностики я не буду — понимая механизмы работы DNS и репликации, зная нужные инструменты, базовые действия проделать труда не составит.

В качестве отправной точки для диагностики, неплохой идеей будет использовать анализ логов Directory Services на проблемном контроллере домена.

Также поможет dcdiag /test:connectivity, а ещё nslookup, как средство проверки правильной работы DNS.

Ну и конечно repadmin. Часть его ключей описана выше, ещё часть можно увидеть в справке (repadmin /?), а кое-что — в расширенной справке (repadmin /? /experthelp).

Цель лекции: Дать представление о процессе репликации в Active Directory .

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

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

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

Модель репликации Active Directory

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

В отличие от модели репликации с единственным хозяином, которая используется в системе Microsoft Windows NT, Active Directory применяет модель репликации с несколькими хозяевами. В Windows NT основной контроллер домена (Primary Domain Controller , PDC ) является единственным контроллером домена, который может принимать изменения информации домена . После того как изменение сделано, оно реплицируется на все резервные контроллеры домена ( Backup Domain Controllers, BDC ). Недостатком модели репликации с единственным хозяином является то, что она не масштабируется для большой распределенной среды. Поскольку изменения (например, пароля пользователя) могут выполняться только на контроллере PDC , это может стать узким местом, если делаются сразу тысячи изменений. Контроллер PDC находится только в одном месте компании, и любые изменения информации домена , расположенного в удаленном месте, должны быть сделаны на этом контроллере PDC . Другая проблема заключается в том, что контроллер PDC является единственной точкой отказа. Если он недоступен, никаких изменений информации каталога сделать нельзя до тех пор, пока он не вернется в интерактивный режим или пока другой BDC - контроллер не будет назначен на роль контроллера PDC .

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

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

В AD реализован весьма эффективный фоновый процесс, известный как проверка согласованности знаний Knowledge Consistency Checker (KCC). Этот процесс обеспечивает потребление информации, предоставляемой администраторами службе AD в форме подсетей, сайтов, связей сайтов, а также мостов связей сайтов с целью определения оптимальной общей топологии соединений между контроллерами доменов. Данные соединения представлены объектами соединений, которые автоматически добавляются и удаляются процессом KCC по мере необходимости. Между сайтами, связями сайтов, а также мостами связей сайтов, с одной стороны, и компонентами сетевой топологии — с другой, обычно устанавливается жесткое соответствие; в результате формируется схема, именуемая топологией сайтов. Образец топологии сайтов представлен на рисунке 1.

Рисунок 1. Пример топологии сайта

Компоненты топологии сайтов

Топология сайтов состоит из сайтов, связей сайтов и мостов связей сайтов.

Сайты. Сайты представляют собой ключевой компонент конфигурации AD, используемый как в процессе репликации, так и клиентами, а также приложениями. Клиенты и приложения используют сведения о сайтах для поиска контроллера домена или иного ресурса, ближе прочих расположенного к ним в логической схеме сети. Чтобы иметь возможность ассоциироваться с нужным сайтом, клиенты должны располагать точной информацией о подсети, полученной по каналам AD. Информация о подсети определяется в терминах, хранимых в каталоге объектов подсетей IP (IPv4 и/или IPv6), которые, в свою очередь, ассоциированы с сайтами.

На рисунке 1 представлена некая компания с офисами в Сент-Луисе и в Детройте, но контроллеры доменов ее сети размещаются в Чикаго. Единственный сайт создан для Чикаго, однако подсети, функционирующие в Сент-Луисе и в Детройте, ассоциированы с сайтом в Чикаго (в дополнение к подсети для Чикаго).

На рисунке 2 представлена организация с офисами в Сиэтле, Лос-Анджелесе и в Сан-Диего. Контроллеры домена размещаются в Сиэтле, однако сервер SCCM имеется также и в Сан-Диего. Чтобы гарантировать обращение клиентов из Сан-Диего к своему локальному серверу SCCM, администраторы создают сайт для Сан-Диего и ассоциируют с этим сайтом подсеть для Сан-Диего. Далее создается второй сайт для Сиэтла; он содержит контроллеры домена Сиэтла, а также подсети для Сиэтла и Лос-Анджелеса.

На рисунке 3 представлен пример, в котором стоимость на связь сайтов не имеет значения. В этом примере задано три сайта AD: в Нью-Йорке, в Бостоне и в Атланте. Каналы распределенной сети существуют между Нью-Йорком и Бостоном, а также между Нью-Йорком и Атлантой. На базе этих сведений были созданы связи сайтов, повторяющие топологию распределенной сети. Поскольку к каждому сайту имеется лишь один путь, стоимость связи сайтов не имеет значения.

Рисунок 4. Связи сайтов со сведениями по затратам

Откройте оснастку ADSIEdit (выберите Start, Run, ADSIEdit.msc).
Перейдите к разделу \Configuration\Sites\Inter-Site Transports\IP.
Правой кнопкой мыши щелкните на связи сайтов, которую намереваетесь редактировать, и выберите пункт Properties.
Дважды щелкните на атрибуте Options.
К отображенному значению добавьте единицу. Если задано значение null, установите его равным 1.

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

Итак, мы рассмотрели ряд примеров, а напоследок я предложу вам две рекомендации по использованию связей сайтов. Речь пойдет об именовании связей сайтов, а также о том, какую связь применять по умолчанию. Обратите внимание на следующий удобный способ именования связи с использованием двух объединяемых ею сайтов (скажем, Нью-Йорк — Бостон). Теперь поменяем сайты местами (получится Бостон — Нью-Йорк) и введем это имя в поле Description. В результате в оснастке Active Directory Sites and Services консоли Microsoft Management Console (MMC) мы можем осуществлять сортировку по любому из двух столбцов в зависимости от того, каким образом нам нужно представить данные. При создании нового леса AD формируется первоначальная связь сайтов с именем DEFAULTIPSITELINK. Вы можете переименовать или удалить эту связь сайтов, если такое действие будет иметь смысл, то есть поступить так же, как в случае с первоначальным сайтом, создаваемым по умолчанию.

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

По умолчанию в AD установлена настройка Bridge All Site Links (BASL). В этом случае контроллер домена на сайте Бостона (см. рисунок 3) может напрямую осуществлять репликацию с контроллером домена сайта в Атланте, минуя все контроллеры домена в Нью-Йорке, даже если связи, соединяющей сайты Бостона и Атланты, не существует. Если описанная выше прямая репликация в вашей сети невозможна, вам придется отключить настройку BASL. После этого вы сможете определять наборы полностью маршрутизируемых связей сайтов с помощью мостов связей сайтов.

Рисунок 5. Мосты связей сайтов

Формирование соединений для репликации

После того как вы определите топологию связей в службе AD, этой службе нужно будет проделать определенную работу, чтобы определить, какие именно контроллеры домена будут принимать участие в процессе взаимной репликации. Эти расчеты осуществляет в фоновом режиме процесс KCC. Рассчитываются две различные топологии, которые затем объединяются во всеобъемлющую топологию репликации. Первая топология предназначена для внутрисайтовой репликации. Внутрисайтовая репликация — это репликация между контроллерами домена, расположенными внутри одного и того же сайта AD. В случае внутрисайтовой репликации процессу KCC нет нужды беспокоиться о таких обстоятельствах, как связи сайтов и мосты связей сайтов; ведь предполагается, что все контроллеры домена объединены надежными и высокопроизводительными каналами связи. Исходя из этих соображений процесс KCC рассчитывает топологию, главное требование к которой состоит в следующем: ни один контроллер домена на данном сайте не должен располагаться на расстоянии более чем трех переходов от любого другого контроллера домена на этом же сайте. Таким образом обеспечивается выполнение условия, в соответствии с которым контроллеры домена могут сходиться и их содержимое — синхронизироваться в течение приблизительно одной минуты (в лесах Windows 2000 этот показатель составлял некогда порядка 15 минут).

Эффективные топологии

Служба AD прекрасно справляется с задачей расчета топологий репликации внутри сайта AD; но, чтобы организовать репликацию, выходящую за границы одного сайта, администраторы должны вводить в систему дополнительную информацию, чтобы эта служба могла указать наилучший маршрут. Указанная информация предоставляется в форме сайтов, связей сайтов, а также мостов связей сайтов, которые в общем случае точно отражают топологию РВС данной организации. Располагая означенными данными, процесс KCC и генератор ISTG могут создавать для соответствующего леса эффективные топологии репликации.

Repadmin — это cmd-приложение для диагностики проблем с репликацией AD. С помощью Repadmin можно легко просмотреть топологию репликации для каждого контроллера домена и использовать эти знания, чтобы вручную изменить ее и инициировать репликацию между контроллерами. С помощью Repadmin можно легко проверить метаданные репликации и векторы релевантности (up-to-dateness (UTDVEC)).

Repadmin.exe является встроенной функцией в среде Windows Server, начиная с версии 2008. Она поставляется с ролью AD Directory Services, а также может быть настроена в клиентских ОС, таких как Windows 10 с RSAT.

Список команд

Бесплатное тестирование
Лицензия Windows Server в подарок
ЦОД в Амстердаме

Repadmin.exe имеет множество команд, давайте остановимся на самых популярных:

/syncall - используется для синхронизации определенного DC с другими
/prp - если у вас есть политика репликации паролей (PRP), эта команда помогает управлять ею
/queue - показывает текущую очередь репликации
/replicate - эта команда помогает выполнить репликацию с одного DC на другой
/replsingleobj - эта команда удобна, если вам нужно реплицировать только один определенный объект между доменными контроллерами
/replsummary - показывает отчет о текущем состоянии репликации и доступности AD
/showattr - используется, когда вам нужно просмотреть атрибуты объекта
/showbackup - этот параметр отображает время последнего резервного копирования
/showrepl - если вам нужно знать текущее состояние репликации, используйте этот параметр.

Как просмотреть общее состояние репликации

Для того чтобы смотреть состояние репликации у вас она должна быть настроена, как минимум, между двумя доменными контроллерами. Начнем с общего состояния репликации, запустите cmd.exe (start->run->cmd.exe) и введите следующую команду:

В результате вы увидите все сбои репликации, которые существуют в вашей среде AD.

Как принудительно выполнить репликацию

Предположим, у вас есть сбои в репликации, и вам нужно принудительно выполнить репликацию после устранения сбоя в сети. В командной строке (cmd.exe) с админскими правами на любом DC запустите:

repadmin.exe /syncall /Aped

В дополнение к команде /syncall у нас есть несколько флагов, которые позволят синхронизировать все разделы (/A), использовать push-уведомления для того, чтобы админ мог прервать выполнение команды на каждом этапе (/p), через все сайты Active Directory (/e) используя имена хостов (/d).

Как управлять входящей и исходящей репликацией

Вы можете отключить входящую и/или исходящую репликацию с возможностью повторного включения позже. Для этого выполните следующие команды в командной строке, запущенной под администратором (cmd.exe):

repadmin.exe /options DC01 +DISABLE_INBOUND_REPL

Отключает входящую репликацию на контроллере домена DC01

repadmin.exe /options DC01 +DISABLE_OUTBOUND_REPL

Отключает исходящую репликацию на контроллере домена DC01

repadmin.exe /options DC01 -DISABLE_INBOUND_REPL

Включает входящую репликацию на контроллере домена DC01

repadmin.exe /options DC01 -DISABLE_OUTBOUND_REPL

Включает исходящую репликацию на контроллере домена DC01.

Например, опция отключения исходящей репликации — это хороший способ выполнить обновление схемы без необходимости перестраивать весь лес Active Directory.

Читайте также: