Tw-city.info

IT Новости
0 просмотров
Рейтинг статьи
1 звезда2 звезды3 звезды4 звезды5 звезд
Загрузка...

Репликация контроллеров домена

Управление репликацией Active Directory

Обеспечение корректной репликации в лесу Active Directory – это одна из главных задач администратора AD. В этой статье попытаемся понять базовые принципы репликации базы Active Directory и методики диагностики неисправности. Стоит отметить, что репликации — один из основополагающих принципов построения современной корпоративной сети на базе AD, так, например, мы уже говорили о репликации групповых политик в домене AD и репликации зон DNS.

Для мониторинга репликации Active Directory в корпоративной среде Microsoft рекомендует использовать продукт SCOM (либо другие продукты мониторинга с похожим функционалом). Кроме того, для мониторинга репликации AD можно использовать утилиту repadmin (repadmin /showrepl * /csv) совместно с самописными скриптами анализа вывода этой утилиты. Типичные проблемы, связанные с ошибками репликации Active Directory, — ситуации, когда объекты не появляются в одном или нескольких сайтах (например, только что созданный пользователь, группа или другой объект AD не доступны на контроллерах домена в других сайтах).

Хорошая отправная точка для поиска неисправности в механизме репликации Active Directory – анализ журнала «Directory Services» на контроллерах домена. Конкретные действия будут зависеть от того, какие ошибки будут обнаружены в журнале, однако для разрешения проблем нужно достаточно четко понимать процессы репликации Active Directory.

Одним из базовых элементов управлением трафиком репликации между контроллерами домена являются сайты Active Directory. Сайты связаны между собой особыми связями, называемыми «site link», которые определяют стоимость маршрутизации данных AD (элементы леса, домена, папка SYSVOL и т.д.) между различными сайтами. Расчет алгоритма управления и маршрутизации трафика репликации в лесу ведется службой KCC.

KCC определяет партнеров по репликации для всех контроллеров домена в лесу. Для межсайтовой репликации KCC автоматически выбирает специальные сервера-плацдармы (bridgehead server), помимо этого, администратор домена может вручную указать контролеры домена, которые будут выполнять роль сервера-плацдарма для того или иного сайта, именно эти сервера и управляют межсайтовой репликацией. Сайты и сервера bridgehead нужны для того, чтобы удобно управлять трафиком репликации Active Directory, и чтобы уменьшить объем передаваемого трафика по сети.

Межсайтовую топологию в лесу можно проанализировать при помощи команды:

данная команда отобразит список сайтов в лесу Active Directory. Для каждого из сайтов указаны 3 значения: стоимость репликации между двумя сайтами, интервал репликации в минутах, а также дополнительные настроенные параметры межсайтовой связи. Вывод этой команды может выглядеть так:

В вышеприведённом логе видно, что в домене winitpro.ru существует 3 сайта, которые называется соответственно Site(0), Site(1) иSite(2). Каждый из сайтов имеет 3 набора репликационной информации, по одной для каждого сайта в лесу. Например, настроена связь между Sites(2) (LAB-Site3) и Site(0) (LAB-Site1), параметры этой связи — 10:30:0, что означает: 10 – стоимость репликации, и интервал репликации 30 минут. Также обратите внимание, что для сайта Site(2) задан сервер-плацдарм (bridgehead) – это контроллер домена с именем testlabdc2.

Контроллеры домена, партнеры по репликации – могут быть идентифицированы при помощи графического Gui или при помощи утилит командной строки. Откройте консоль MMC «Active Directory Sites and Services», разверните узел Sites, в нем найдите интересующий ваш сайт. В этом узле будут содержатся контроллеры домена, относящиеся к этому сайту. Развернув контроллер домена и выбрав пункт NTDS Settings, вы увидите всех партнеров по репликации данного контроллера домена.

В командной строке при помощи команды nslookup можно получить список контроллеров домена, относящихся к нашему сайту (естественно для этого необходимо, чтобы все DC имели корректные записи SRV). Формат команды такой:

на выходе получаем примерно следующее:

Чтобы для определенного контролера домена отобразить всех партнеров по репликации, с датой и временем последней репликации, воспользуйтесь командой:

Стоит отметить, что служба DNS – это важный компонент службы репликации Active Directory. Контроллеры домена регистрируют свои SRV записи в DNS. Каждый контроллер домена в лесу регистрирует записи CNAME вида dsaGuid._msdcs.forestName, где dsaGuid –GUID видимый у объекта в пункте NTDS Settings в консоли «AD Sites and Services». Если в журнале Directory Services есть ошибки, связанные со службой DNS, для проверки корректных записей типа CNAME и A для контроллера домена.

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

Команда repadmin имеет специальный параметр /replsummary, который позволяет быстро проверить состояние репликации на конкретном контроллере домена (указывается его имя) или на всех контроллерах (опция wildcard).

В том случае, если ошибки репликации отсутствуют, в выводе этой команды будет видно, что ошибок – 0.:

В том случае, если ошибки все-таки будут, при помощи утилиты Repadmin можно получить более полную информацию. Каждый контроллер домена имеет собственный уникальный USN (Update Sequence Number), который инкрементируется каждый раз при успешном изменении обновлении объекта Active Directory. При инициализации репликации, партнеру передается USN, который сравнивается с USN, полученным в результате последней успешной репликации с данным партнером, тем самым определяя сколько изменений произошло в базе AD со времени последней репликации.

При помощи ключа /showutdvec, можно получить список текущих значений USN, хранящихся на указанном DC.

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

Тестирование репликации Active Directory при помощи утилиты repadmin можно осуществить несколькими способами:

  • replmon /replicate (позволяет запустить репликацию определенного раздела на указанный контроллер домена)
  • replmon /replsingleobj (репликация конкретного объекта между двумя DC)
  • replmon /syncall (синхронизация указанного контроллера домена со всем партнерами по репликации)

При наличии проблем с механизмом репликации Active Directory, нужно знать и уметь пользоваться утилитами repadmin, nslookup, dcdiag, крайне полезен при анализе журнал событий Directory Services. В особо сложный и нестандартных ситуациях может помочь база знаний Microsoft KB, в которой описаны типовые проблемы и методики их решения. Поиск по базе KB обычно осуществляется по идентификаторам ошибок (Event ID), полученным из указанного журнала..

Репликация в Active Directory

Планирование стратегии репликации

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

В Windows Server 2003 используется модель репликации с несколькими хозяевами, при которой на всех контроллерах домена хранятся равноправные копии БД Active Directory . Когда создается, удаляется или переносится объект либо изменяются его атрибуты на любом контроллере домена, эти изменения реплицируются на остальные контроллеры домена.

Внутрисайтовая (между контроллерами домена одного сайта) и межсайтовая репликация (между контроллерами домена, относящимися к разным сайтам) выполняется по -разному [ 3 ] , [ 4 ] .

Репликация внутри сайта

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

Читать еще:  Альбомный формат word

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

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

Репликация между сайтами

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

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

При межсайтовой репликации все данные передаются в сжатом виде. Причина в том, что трафик, вероятно, передается по более медленным WAN-каналам (см. рис. 10.1) в сравнении с соединениями локальной сети, используемыми при внутрисайтовой репликации.

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

Виды реплицируемой информации

Хранимая в каталоге информация делится на три категории, которые называются разделами каталога. Раздел каталога служит объектом репликации. В каждом каталоге содержится следующая информация [ 4 ] :

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

Схема и конфигурация реплицируются на все контроллеры домена в дереве или лесе.

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

Контроллер домена хранит и реплицирует [ 4 ] :

  • информацию о схеме дерева доменов или леса;
  • информацию о конфигурации всех доменов в дереве или лесе;
  • все объекты и их свойства для своего домена. Эти данные реплицируются на все дополнительные контроллеры в домене, часть всех свойств объектов домена реплицируется в глобальный каталог для организации поиска информации.

Глобальный каталог хранит и реплицирует:

  • информацию о схеме в лесе;
  • информацию о конфигурации всех доменов в лесе;
  • часть свойств всех объектов каталога в лесе (реплицируется только между серверами глобального каталога );
  • все объекты каталога и все их свойства для того домена, в котором расположен глобальный каталог.

Протоколы репликации

Удаленные вызовы процедур выполняются при отправке сообщений репликации внутри сайта и между сайтами. Протокол RPC используется по умолчанию при всех операциях репликации Active Directory, поскольку является отраслевым стандартом и совместим с большинством типов сетей [ 3 ] .

Обмен данными из каталога производится с помощью разных сетевых протоколов, таких как IP или SMTP [ 4 ] :

Диагностика репликации домена

Утилита Repadmin

REPADMIN /SHOWREPL
показывает состояние репликации для контроллера домена

REPADMIN /REPLSUMMARY
сводка репликации для всех DC леса

REPADMIN /SYNCALL
Запускает репликацию между DC и партнерами по репликации

Для более глубокого анализа можно задействовать команду:
REPADMIN *
(звездочка вместо использования имени DC).

Утилита FRSDiag

Диагностика с помощью утилиты FRSdiag.exe: в центре загрузки Microsoft есть утилиты «Windows 2003 support tools». Среди этих утилит (а возможно и отдельно от них) есть утилита «File Replication Service Diagnostics Tool» — FRSdiag.exe. Скачайте утилиту и запустите ее. Никаких настроек менять не надо, достаточно нажать «GO». Утилита произведет диагностику и выдаст массу информации.

Восстановление репликации между контроллерами домена

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

  1. провести диагностику с помощью утилиты FRSdiag.exe;
  2. удалить объекты, которые различаются на контроллерах домена. Обычно это устаревшие и уже давно удаленные объекты;
  3. разрешить репликацию с серверами, которых давно не было в сети;
  4. произвести репликацию, убедиться, что она успешная, и снова запретить репликацию с серверами, которых давно не было в сети.

1. Диагностика с помощью утилиты FRSdiag.exe

Скачайте утилиту и запустите ее. Никаких настроек менять не надо, достаточно нажать «GO». Утилита произведет диагностику и выдаст массу информации. Если там будут следующие строки, переходите к следующим пунктам:

  • «Error 2042 It has been too long since this machine last replicated with the named source machine. The time between replications with this source has exceeded the tombstone lifetime.»
  • «Use the «repadmin /removelingeringobjects» tool to remove inconsistent deleted objects and then resume replication.»

2. Удаление объектов, которые различаются на контроллерах домена

для этого служит команда:
Repadmin /removelingeringobjects
Не торопитесь ее выполнять! Там масса других параметров.
Описание здесь:
http://support.microsoft.com/kb/870695/en-us
НО! там тоже описано далеко не все! Вот более точная инструкция:
http://blogs.technet.com/b/glennl/archive/2007/07/26/clean-that-active-directory-forest-of-lingering-objects.aspx Что необходимо сделать: сначала надо «очистить» один из контроллеров домена, а потом будем использовать его в качестве эталона. Для этого сначала проводим инспекцию (что надо удалить). С этой целью используется опция /advisory_mode:

repadmin /removelingeringobjects Destination_domain_controller Source_domain_controller_GUID Directory_partition /advisory_mode
где:
Destination_domain_controller — имя контроллера, который будем «чистить».
Source_domain_controller_GUID — идентификатор контроллера, который будет использоваться в качестве «образца» для чистки.
Directory_partition — это разделы Active Directory (их можно посмотреть с помощью adsiedit.msc).

Узнать идентификатор контроллера несложно, есть 2 метода:

  1. At a command prompt, type repadmin /showrepl /v name of the authoritative server, and then press ENTER. The object GUID of the domain controller is listed in the DC object GUID field.
  2. Use the Active Directory Sites and Services tool to locate the object GUID of the source domain controller. To do this, follow these steps:
    1. Click Start, point to Administrative Tools, and then click Active Directory Sites and Services.
    2. Expand Sites, expand the site where your authoritative domain controller is located, expand Servers, and then expand the domain controller.
    3. Right-click NTDS Settings, and then click Properties.
    4. View the value in the DNS Alias box. The GUID that appears in front of _msdcs.forest_root_name.com is the object GUID of the domain controller. The Repadmin tool only requires the GUID. Do not include the _msdcs.forest_root_domain_name.com component in the Repadmin syntax.
Читать еще:  Как сделать контроллер домена

Разделы Active Directory — как написано в инструкции:
?Domain directory partition (dc=domain_DN)
?Configuration directory partition (cn=Configuration,dc=forest_root_DN)
?Application directory partition or partitions
(cn=Application_directory_partition_name,dc=domain_DN)
(cn=Application_directory_partition_name,dc=forest_root_DN)
?Schema directory partition (cn=Schema, cn=Configuration,dc=,dc=forest_root_DN)

Итак, пример. У нас есть 3 контроллера домена: DC1, DC2, DC3, домен mydom.com. Сначала мы «почистим» DC1, используя в качестве образцов DC2 и DC3, а потом «почистим» DC2 и DC3, используя в качестве образца DC1: сначала берем «образец» для DC1 с DC2:
repadmin /removelingeringobjects DC1 ff4d1971-a0ed-4915-a297-b25041a10c74 DC=MYDOM,DC=COM /advisory_mode
repadmin /removelingeringobjects DC1 ff4d1971-a0ed-4915-a297-b25041a10c74 CN=Configuration,DC=MYDOM,DC=COM /advisory_mode
repadmin /removelingeringobjects DC1 ff4d1971-a0ed-4915-a297-b25041a10c74 CN=Schema,CN=Configuration,DC=MYDOM,DC=COM /advisory_mode
repadmin /removelingeringobjects DC1 ff4d1971-a0ed-4915-a297-b25041a10c74 CN=Schema,CN=Configuration,DC=MYDOM,DC=COM /advisory_mode
repadmin /removelingeringobjects DC1 ff4d1971-a0ed-4915-a297-b25041a10c74 DC=ForestDNSZones,DC=MYDOM,DC=COM /advisory_mode
repadmin /removelingeringobjects DC1 ff4d1971-a0ed-4915-a297-b25041a10c74 DC=DomainDNSZones,DC=MYDOM,DC=COM /advisory_mode

потом залезаем в логи (Directory Service, источник NTDS Replication) и смотрим:

«Active Directory has completed the verification . Source domain controller: .
Number of objects examined and verified:
0
. «

Если количество объектов не 0, смотрим что это за объекты, и если все ок, грохаем (то же самое, но без advisory_mode):
repadmin /removelingeringobjects DC1 224d1971-a0ed-4915-a297-b25041a10c74 DC=MYDOM,DC=COM
repadmin /removelingeringobjects DC1 224d1971-a0ed-4915-a297-b25041a10c74 CN=Configuration,DC=MYDOM,DC=COM
repadmin /removelingeringobjects DC1 224d1971-a0ed-4915-a297-b25041a10c74 CN=Schema,CN=Configuration,DC=MYDOM,DC=COM
repadmin /removelingeringobjects DC1 224d1971-a0ed-4915-a297-b25041a10c74 CN=Schema,CN=Configuration,DC=MYDOM,DC=COM
repadmin /removelingeringobjects DC1 224d1971-a0ed-4915-a297-b25041a10c74 DC=ForestDNSZones,DC=MYDOM,DC=COM
repadmin /removelingeringobjects DC1 224d1971-a0ed-4915-a297-b25041a10c74 DC=DomainDNSZones,DC=MYDOM,DC=COM

теперь берем «образец» для DC1 с DC3:
repadmin /removelingeringobjects DC1 3303F24A-14FC-44A3-A120-C810E1017053 DC=MYDOM,DC=COM /advisory_mode
repadmin /removelingeringobjects DC1 3303F24A-14FC-44A3-A120-C810E1017053 CN=Configuration,DC=MYDOM,DC=COM /advisory_mode
repadmin /removelingeringobjects DC1 3303F24A-14FC-44A3-A120-C810E1017053 CN=Schema,CN=Configuration,DC=MYDOM,DC=COM /advisory_mode
repadmin /removelingeringobjects DC1 3303F24A-14FC-44A3-A120-C810E1017053 CN=Schema,CN=Configuration,DC=MYDOM,DC=COM /advisory_mode
repadmin /removelingeringobjects DC1 3303F24A-14FC-44A3-A120-C810E1017053 DC=ForestDNSZones,DC=MYDOM,DC=COM /advisory_mode
repadmin /removelingeringobjects DC1 3303F24A-14FC-44A3-A120-C810E1017053 DC=DomainDNSZones,DC=MYDOM,DC=COM /advisory_mode

точно так же проверяем и выполняем те же команды, но уже без advisory_mode.

DC1 «очищен». Теперь так же «чистим» DC2 и DC3, но уже в качестве «образца» выступает DC1.
Для этого логинимся на DC2 (а потом на DC3) и выполняем:
Сначала с advisory_mode:
repadmin /removelingeringobjects DC2 114d1971-a0ed-4915-a297-b25041a10c74 DC=MYDOM,DC=COM /advisory_mode
repadmin /removelingeringobjects DC2 114d1971-a0ed-4915-a297-b25041a10c74 CN=Configuration,DC=MYDOM,DC=COM /advisory_mode
repadmin /removelingeringobjects DC2 114d1971-a0ed-4915-a297-b25041a10c74 CN=Schema,CN=Configuration,DC=MYDOM,DC=COM /advisory_mode
repadmin /removelingeringobjects DC2 114d1971-a0ed-4915-a297-b25041a10c74 CN=Schema,CN=Configuration,DC=MYDOM,DC=COM /advisory_mode
repadmin /removelingeringobjects DC2 114d1971-a0ed-4915-a297-b25041a10c74 DC=ForestDNSZones,DC=MYDOM,DC=COM /advisory_mode
repadmin /removelingeringobjects DC2 114d1971-a0ed-4915-a297-b25041a10c74 DC=DomainDNSZones,DC=MYDOM,DC=COM /advisory_mode

А потом то же самое без advisory_mode.

И то же самое повторяем для DC3: логинимся на него, запускаем эти команды с advisory_mode, смотрим логи, а потом запускаем без advisory_mode.

3. Разрешить/запретить репликацию с серверами, которых давно не было в сети

Для этого есть 2 ключа в реестре. Их необходимо выставить на каждом из контроллеров домена, чтобы между ними проходила репликация. После успешной синхронизации/репликации и (желательно неоднократной) проверки того, что все работает, указанные ключи проще всего удалить.

Содержимое REG файла:

После запуска разрешена синхронизация между контроллерами домена. Чтобы проверить, что контроллеры синхронизираются, необходимо на одном из них открыть: «Active Directory Sites and Services» -> Sites -> Default-First-Site-Name -> Servers Теперь по очереди открываем КАЖДЫЙ контроллер домена, у него — NTDS Settings, после чего кликаем правой кнопкой на имени контроллера домена (внутри NTDS Settings) и выбираем Replicate Now. Все должно синхронизироваться.

Теперь удаляем ключи из реестра (на всех контроллерах домена!):

Information Security Squad

stay tune stay secure

🇾🇹 Инструмент Repadminl: проверка состояния репликации Active Directory

Чтобы поддерживать домен Active Directory в исправном состоянии, следует периодически проверять репликацию между контроллерами домена с помощью инструментов repadmin и dcdiag (мы рассмотрели использование утилиты dcdiag в предыдущем руководстве.

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

Действительно, в небольших доменах AD с несколькими контроллерами домена (2-5) проблем с репликацией обычно почти нет, но в больших инфраструктурах из десятков и сотен контроллеров домена администратору домена часто приходится вмешиваться в процесс репликации и исправлять ошибки.

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

Утилита repadmin в Windows Server 2003 была включена в пакет средств поддержки, который необходимо было загрузить и установить вручную.

В Windows Server 2008 R2 и более поздних версиях средство repadmin автоматически устанавливается на контроллере домена при установке роли ADDS (доменные службы Active Directory).

Вы можете установить repadmin на настольные версии Windows (Wndows 10 / 8.1 / 7).

Для этого установите RSAT и включите опцию AD DS и AD LDS Tools.

Чтобы использовать repadmin, откройте командную строку от имени администратора.

Вы можете перечислить полный синтаксис команды, набрав:

Как видите, команда имеет довольно много опций.

Давайте попробуем изучить некоторые полезные примеры использования repadmin.

Чтобы быстро проверить работоспособность репликации между контроллерами домена, обычно используется следующая команда:

Как видите, в домене AD есть только 2 контроллера домена, между которыми в настоящее время нет ошибок репликации.

Каждый сервер действует как исходный DSA и целевой DSA.

Чтобы проверить оставшееся количество объектов каталога AD в очереди репликации, выполните:

Используя команду Repadmin / Showrepl, вы можете отобразить состояние репликации для текущего DC.

Она отображает время последней попытки репликации разделов Active Directory.

Если вы считаете, что какой-то контроллер домена не получает обновления репликации, выполните для него эту команду.

Совет. Для отображения подробной информации в любой команде используйте параметр /verbose.

Базовую доступность каталога LDAP на конкретном контроллере домена можно проверить с помощью команды:

Вы можете принудительно выполнить репликацию указанного контроллера домена со всеми партнерами по репликации DC, используя команду:

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

Чтобы начать репликацию всех разделов Active Directory по всему лесу, выполните команду:

При использовании этой команды также возможна высокая нагрузка на каналы связи.

Команда Repadmin / kcc указывает KCC (Knowledge Consistency Checker) на указанном контроллере домена немедленно пересчитать топологию входящей репликации (она запускается автоматически каждые 15 минут).

Команда Repadmin / replicate позволяет вам реплицировать определенный раздел каталога с исходного DC на целевой. Например:

Self Engineering

Путь саморазвития ИТ инженера

Сетевые сервисы Windows 2012 — репликация Active Directory

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

  1. Основные сведения
  2. Механизмы репликации
    • 2.1 Внутрисайтовая репликация
    • 2.2 Межсайтовая репликация
  3. Диагностика репликации

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 /syncall — синхронизация указанного сервера со всеми партнёрами по репликации.
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).

Ссылка на основную публикацию
Adblock
detector