Наконец-то собрался переписать свои заметки по теме из черновика в тетрадке в электронный формат. Изложить постарался максимально кратко и ёмко.
- Основные сведения
- Механизмы репликации
- 2.1 Внутрисайтовая репликация
- 2.2 Межсайтовая репликация
- Диагностика репликации
1. Основные сведения
Все данные Active Directory хранятся в специализированной базе данных на движке ESENT. Физически она представляет собой файл NTDS.DIT. Все изменения в AD производятся на конкретном контроллере домена и вносятся в его NTDS.DIT и лишь потом эти изменения передаются на остальные контроллеры домена.
Логически база данных состоит из четырёх разделов:
Schema — содержит описания объектов и их атрибутов, которые могут быть созданы в AD. Меняется редко — при процедуре расширения схемы, которая производится, например, при установке MS Exchange или при апгрейде ОС контроллеров домена. Расширение схемы необратимо, его нельзя откатить никак, кроме способа восстановления всех DC, успевших реплицировать данные, из бэкапа. Репликацию данного раздела может инициировать только контроллер домена, имеющий роль Schema master. Реплицируется на все контроллеры леса.
Configuration — содержит сведения о конфигурации AD (сколько доменов, сайтов, сайтлинков и т.д.). Инициатором репликации может выступать любой DC. Реплицируется на все контроллеры леса.
Domain — содержит учётные записи (пользователей, группы, компьютеры, принтеры…). Инициатором выступает любой DC. Реплицируется на все контроллеры домена.
Application — раздел для хранения данных какими-то приложениями, не относящимися к AD непосредственно. В частности, если вы выбрали в настройках DNS-зоны «интегрированная в AD», то она хранится здесь. Репликация зависит от настройки.
Репликация между контроллерами происходит не абы как и не по принципу «каждый с каждым», а на основе репликационных связей. За их создание отвечает сервис KCC (Knowledge Consistency Checker). Он стартует на каждом контроллере домена раз в 15 минут и добавляет или удаляет необходимые связи. Так что нет ничего страшного, если сразу после установки нового DC в сети, он ещё не числится ничьим партнёром репликации. Посмотреть и настроить связи можно в оснастке Active Directory Sites and Services.
Связи создаются сервисом KCC на основании правила «трёх прыжков» — то есть, чтобы от одного контроллера домена до любого другого было не более трёх переходов или двух посредников.
Следует иметь ввиду, что связи, созданные вручную, сервисом KCC не управляются, то есть восстанавливать им замену, в случае недоступности одного из партнёров по репликации, сервис не будет.
Можно не ждать 15 минут, и инициировать создание связей силами KCC принудительно:
repadmin /kcc <имя сервера> — принудительное создание связи для <имя сервера>
repadmin /kccsite <имя сайта> — принудительное создание связей для всех DC в сайте <имя сайта>
repadmin /kcc * — запустить процесс на всех контроллерах доменов в лесу.
2. Механизмы репликации
На каждом контроллере домена ведётся учёт количества изменений с помощью счётчика highestCommittedUSN. Создание/изменение объекта включает в себя создание/изменение нескольких атрибутов, каждое из которых увеличивает highestCommittedUSN на 1. Каждый атрибут, помимо прочих, имеет параметры:
Org.USN — значение счётчика highestCommittedUSN автора изменений (контроллера домена, на котором они производились) на момент изменения.
Loc.USN — значение счётчика highestCommittedUSN текущего контроллера домена (принимающего изменённые данные в ходе репликации).
Посмотреть атрибуты и значения их параметров объекта можно командой repadmin /showmeta. Например:
repadmin /showmeta «CN=User1,OU=TestOU,DC=contoso,DC=com»
В ходе репликации, контроллер домена кэширует значения highestCommittedUSN своих партнёров. При следующем сеансе он сравнивает закэшированное значение с текущим. Если новое значение больше предыдущего, целевой контроллер принимает решение стянуть изменения. Для этого исходный контроллер делает выборку объектов и атрибутов, у которыех Loc.USN больше, чем последний highestCommittedUSN.
В случае конфликтов:
- сравнивается параметр Ver конфликтного атрибута. Чей выше, тот и прав.
- если Ver равны, сравнивается время изменения. Чьё позже, тот и прав.
- если и время равно, то прав будет контроллер домена с большим GUID.
- В случае, если на двух контроллерах одновременно создали учётную запись с одинаковым именем, более ранняя будет переименована (старое имя+GUID контроллера)
- В случае, если на одном контроллере в какой-то OU создаётся объекта, а на другом в это же время удаляется OU, объект, в ходе репликации, будет перенесён в служебный контейнер «Lost and Found«
Репликация всегда происходит в режиме Pull (вытягивание), поскольку каждый контроллер единолично отвечает за целостность своей базы данных.
Принудительный запуск репликации:
repadmin /replicate <serverTo> <serverFrom> <раздел AD в формате RDN>
repadmin /syncall <server> — синхронизация указанного сервера со всеми партнёрами по репликации.
2.1 Внутрисайтовая репликация
Через 15 секунд после внесения изменений, контроллер домена оповещает своих партнёров о необходимости репликации. Если партнёров несколько, то каждому следующему оповещение отправляется с 3-секундной задержкой.
repadmin /notifyopt — настройка таймингов оповещений.
Изменение пароля пользователя и блокировка учётной записи инициируют репликацию без 15-секундной задержки.
Кроме того, репликация происходит по расписанию каждый час. На случай, если во время инициирования репликации по изменению, целевой контроллер был недоступен или был занят дефрагментацией базы.
2.2 Межсайтовая репликация
Для репликации между сайтами создаются связи сайтов (Site Link), в которых задаётся расписание («окно» в течение которого возможна репликация и периодичность), используемый протокол (SMTP или IP) и стоимость (Cost). По умолчанию создана DEFAULTIPSITELINK с использованием IP и репликацией раз в 180 минут. Посмотреть связи или создать новые можно в оснастке Active Directory Sites and Services.
Стоимости связей учитываются при выборе пути репликации — если от одного сайта до другого можно добраться разными путями, выбран будет тот, стоимость которого будет меньше. Если стоимости равны, выбирается путь с меньшим количеством прыжков. Если и они равны, выбирается просто по имени сайта (сравнение строк).
За репликацию между сайтами отвечают не все подряд контроллеры доменов, а в каждом сайте выбирается специально обученный — 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).
Очень неплохо описаны некоторые команды тут:http://winitpro.ru/index.php/2011/07/01/upravlenie-replikaciej-active-directory/
Self Engineering 