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

Обзор процесса репликации

AD — это база данных. По умолчанию каждый контроллер домена (DC) хранит ее копию в файле ntds.dit в локальном каталоге winnt tds. Логически база данных состоит из трех частей (трех разделов, трех контекстов именования — naming context, NC), а именно: контекста схемы (Schema NC), контекста конфигурации (Configuration NC) и контекста домена (Domain NC). Все контроллеры домена в лесу имеют один и тот же контекст схемы и конфигурации, поскольку эта информация, собственно, и описывает сам лес. Каждый DC одного и того же домена AD хранит одинаковую копию контекста домена. Если конкретный DC играет роль сервера — хранителя глобального каталога (Global Catalog, GC), то этот контроллер домена дополнительно содержит часть копий контекстов домена остальных доменов леса. В состав данной частичной копии входит описание всех объектов соответствующих доменов, но только некоторое подмножество их атрибутов.

Репликация — это механизм, который AD использует для синхронизации названных данных среди всех контроллеров в домене или в лесу. При этом AD задействует механизм проверки целостности Knowledge Consistency Checker (KCC), сайты (site), межсайтовые связи (site link) и объекты связи (connection object) при проведении репликации.

KCC является встроенным процессом, который запускается на всех контроллерах домена и создает топологию репликации леса. Сайты используются как структура для группировки хорошо связанных (в смысле близости в сети) контроллеров домена. Особенности используемой сети и построения AD определяют, можно ли считать произвольно выбранный контроллер домена хорошо связанным. Во многих компаниях принято считать, что DC, соединенные сетью со скоростью 100 Мбит/с, являются хорошо связанными. Для создания сайта AD конфигурируется с использованием подсетей IP. Если одна или несколько подсетей хорошо связаны между собой, их можно объединить в сайт. Репликация в рамках такого сайта называется внутрисайтовой репликацией (intrasite replication). Внутри сайта KCC автоматически создает объекты связи между различными DC. Объекты связи — это односторонние соединения, которые связывают между собой контроллеры домена внутри данного сайта. Каждая из таких связей — подобно полосе движения на автомагистрали — представляет собой соединение, ограниченное DC-источником и DC-приемником. Прежде чем два DC в сайте смогут реплицировать между собой данные каталога, необходимо установить два отдельных объекта связи.

Если некоторые из DC не подходят под категорию хорошо связанных, придется создать несколько сайтов. Репликация данных между различными сайтами носит название межсайтовой. Администратор AD использует оснастку Active Directory Sites and Services консоли Microsoft Management Console (MMC) для создания межсайтовых связей, которые формируют магистраль между сайтами. После того как все необходимые объекты связи установлены, KCC создает соединения между сайтами. Обычно не на всех контроллерах присутствуют одни и те же данные (например, контроллеры DC в отдельно взятом домене могут поддерживать некоторые специфичные данные). Следовательно, процессу KCC, возможно, придется устанавливать множество объектов связи, чтобы гарантировать, что каждое пространство имен любого контекста именования полностью синхронизировано (реплицировано). На Рисунке 1 приведен пример межсайтовых объектов связи. Сайт A и сайт B соединены между собой межсайтовыми связями, созданными вручную. В этом примере процесс KCC создал два односторонних соединения для репликации данных между двумя DC из одного домена.

Сервер-мост (bridgehead) — еще один компонент в топологии репликации. Тем, кому доводилось работать с Microsoft Exchange Server, этот компонент должен быть уже знаком. Для повышения эффективности репликации данных, KCC не создает индивидуальные объекты связи для передачи данных с каждого DC в одном сайте на каждый DC в другом сайте. Вместо этого KCC использует механизм store-and-forward, с промежуточным хранением, по правилам работы которого информация реплицируется между двумя серверами-мостами, по одному для каждого сайта. Для репликации информации на оставшиеся контроллеры в своем сайте сервер-мост использует уже внутрисайтовую репликацию. Подробнее об этом рассказано во врезке «Серверы Bridgehead».

Что происходит во время репликации?

Чтобы вносить изменения в объекты каталога DC, службы Active Directory должны иметь возможность определять, какие именно объекты изменились, и следует ли реплицировать произведенные изменения партнерам данного DC по репликации. Для отслеживания произошедших в каталоге изменений AD использует порядковые номера обновлений (update sequence number, USN). Номера USN представляют собой 64-разрядные счетчики, которые AD назначает для каждого DC индивидуально. Когда AD, пользователи, администраторы или приложения изменяют некоторые атрибуты, DC увеличивает текущее значение USN данного атрибута на единицу и присваивает обновленному объекту новое значение в качестве его локального USN.

В рамках репликационной топологии AD партнеры-участники используют значение high-watermark value (HWL) для проведения наиболее актуальных изменений, исходящих от различных DC-источников. Когда какой-либо DC-приемник собирается запросить изменения от DC-источника, он посылает свое значение HWL DC-источнику в качестве точки отсчета. В результате DC-источник перешлет лишь те изменения объектов каталога, HWL которых выше, нежели HWL приемника. В свою очередь, это снижает трафик репликации.

Чтобы свести к минимуму объем реплицируемых данных, можно задействовать еще один механизм — вектор обновления — up-to-dateness vector (UDV). Он непосредственно связан с HWL. Но если HWL привязан к объектам, то UDV занимается атрибутами. Во всем остальном работа этих механизмов одинакова. Во время обмена реплицируемыми данными DC-получатель посылает свой вектор UDV DC-отправителю. На основе значения вектора DC-отправитель устанавливает, насколько актуально значение конкретного атрибута на DC-получателе. Если значение вектора соответствует самому последнему изменению, DC-отправитель отфильтровывает это значение из потока репликации.

Шесть полезных инструментов

После развертывания AD следует обзавестись набором утилит, которые могут помочь в случае возникновения нештатной ситуации. Microsoft Windows 2000 Server Resource Kit предлагает множество соответствующих программ, и примерно 50 из них хранится в каталоге support ools на компакт-диске с Windows 2000. Сбои в репликации могут быть самыми неожиданными, поэтому надо быть готовым к применению различных утилит.

Event Viewer. Стандартная программа просмотра событий Windows запускается через Start, Programs, Administrative Tools. Event Viewer в первую очередь сигнализирует об отклонениях в работе системы. Если AD развернута, на станциях DC появляется новый журнал под названием Directory Services. Чтобы последние по времени инциденты в процессе репликации не прошли незамеченными, необходим мониторинг журналов Directory Services. Можно, конечно, поочередно подключаться к разным DC и просматривать журнал событий, но Event Viewer за один раз покажет администратору только один журнал. Для получения отчета о результатах репликации со всех контроллеров домена я рекомендую воспользоваться утилитой Replication Monitor.

Replication Monitor. Replmon.exe — графическая утилита, входит в состав Windows 2000 Support Tools и используется для получения сводной информации о репликации в рамках всей организации. Эти данные помогут установить, прошла ли репликация, когда именно это произошло, между какими DC возникал соответствующий трафик и многое другое.

Replmon позволяет собрать со всех станций DC все события, относящиеся к выполнению репликации. Чтобы запустить Replmon, нужно щелкнуть Start, Run и набрать:

Replmon

Утилита открывает окно, в которое следует вручную добавить серверы, требующие мониторинга. Есть простой способ быстро добавить все нужные серверы — создать .ini-файл с указанием списка контроллеров домена, по одному в строке. Затем в меню Replmon нужно щелкнуть File, Open Script, найти созданный .ini-файл и нажать Open.

Экран 1. Использование монитора репликаций Replmon.

В результате в окне Replmon появятся все заданные серверы DC и хранящиеся на них контексты именования. На Экране 1 я вручную добавил сервер testdc01. Снизу testdc01 видны три контекста именования, хранящиеся на данном DC. Список задач, которые можно выполнить с помощью Replmon, открывается в контекстном меню сервера — достаточно просто щелкнуть на его имени правой кнопкой мыши. Необходимо внимательно изучить каждую из этих задач и уметь ориентироваться в собираемой информации для успешного решения проблем, связанных с репликацией.

Одной из наиболее ценных особенностей Replmon является способность утилиты быстро находить в журналах Directory Services записи, относящиеся к ошибкам репликации. Для этого в меню Replmon нужно открыть Action, Domain, Search Domain Controllers for Replication Errors, затем щелкнуть Run Search. Replmon предложит ввести имя домена, для которого будет выполняться операция поиска. Следует указать DNS-имя домена и щелкнуть ОК. Утилита пошлет запрос всем контроллерам домена и соберет записи об ошибках репликации с указанием DC, на котором возникла ошибка, затронутого раздела каталога или NC, вовлеченного DC-партнера по репликации, кода ошибки и ее причины. Replmon опрашивает каждый DC индивидуально.

Domain Controller Diagnostics. Dcdiag.exe, утилиту командной строки, можно отыскать на компакт-диске с Windows 2000 Server. Это мощная диагностическая программа, предоставляющая в распоряжение администратора громадный объем информации о DC, на котором утилита работает. Dcdiag запускает на DC набор тестовых задач, чтобы понять, возможно ли соединение DC с другими станциями, проверить статус репликации, целостность топологии, пользовательских разрешений, функций локатора, состояние перекрестных ссылок на уровне сайта, работу служб верификации доверительных отношений, состояние File Replication Service (FRS), а также состояние всех жизненно важных для работы DC служб. Запустив утилиту Dcdiag, нужно быть готовым к тому, что придется просмотреть огромное количество данных. Я рекомендую использовать следующий синтаксис вызова:

dcdiag > <имя_файла>.txt

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

Repadmin. Repadmin.exe, утилита командной строки, также находится на компакт-диске с Windows 2000 Server и, вероятно, занимает центральное место в наборе рассматриваемых утилит. С ее помощью можно подробно узнать, что происходит во время проведения репликации, это поможет выяснить причину сбоя и восстановить работоспособность системы. Для просмотра параметров программы следует набрать в командной строке:

repadmin /?

Одно из наиболее полезных свойств утилиты — показ партнеров по репликации для указанного DC. Наберите:

repadmin /showreps
Экран 2. Результаты работы Repadmin.

На Экране 2 приведены результаты работы Repadmin на DC, с именем testdc01. Видно, что testdc01 импортирует объекты связи с сервера testdc02 в части Schema и Configuration и контексты именования домена testdomain.com. Также видно, что самые последние по времени попытки репликации происходили для каждого контекста именования 3 июня, в разное время, и что каждая попытка завершилась успешно. В нижней половине экрана показаны соседи по экспортируемым данным, которым testdc01 будет посылать уведомления, когда данные каталога будут готовы к процедуре репликации.

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

repadmin /showmeta

Например, для вывода метаданных учетной записи Administrator в домене testdomain.com следует набрать:

repadmin /showmeta 
«CN=administrator,OU=users,dc=testdomain,dc
=com» testdc01.testdomain.com

На Экране 3 показаны результаты этого запроса. В крайней справа колонке приведены атрибуты пользователя Administrator. В крайней слева — локальный USN для каждого атрибута. Обратите внимание, что атрибуты nTSecurityDe и adminCount имеют большее значение USN, чем остальные. Это говорит о том, что значения этих двух атрибутов были изменены позже, чем у всех остальных.

Экран 3. Исследование метаданных пользователя Administrator.

Group Policy Verification. Gpotool.exe, утилита командной строки из Resource Kit, поможет решить вопросы, связанные с ошибками в репликации объектов Group Policy Objects (GPO) между контроллерами домена. Подробнее об этом рассказано во врезке «Служба Windows 2000 File Replication Service».

Статистика Directory Service Agent. Dsastat.exe, утилита командной строки, находится на компакт-диске Windows 2000 Server. Она сравнивает контексты имен на контроллерах домена и сообщает о различиях. Ею удобно пользоваться, когда все, казалось бы, работает нормально, но обнаруживается, что с различных контроллеров домена каталог выглядит по-разному. Это может означать, что база данных каталога испорчена. Dsastat гарантирует высокую степень непротиворечивости данных, сравнивая статистику каталога (скажем, объектов) сервер за сервером, байт за байтом, объект за объектом в каждой возможной паре контроллеров домена.

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

Гарри Розенфельд — старший консультант Lucent Technologies в Филадельфии. Специализируется на построении корпоративных сетей на базе Windows NT/2000. С ним можно связаться по адресу: grosenfeld@lucent.com.

Серверы Bridgehead

Bridgehead server — это контроллер домена, который работает как основной маршрутизатор во время репликации данных Active Directory за пределами сайта и внутри него. Если в лесу имеется более одного домена, то, вероятно, bridgehead-сервер также не один. Сервер-мост будет работать только с контекстами именования, в которых задействована локальная база данных AD (т. е. контексты именования Schema NC, Configuration NC и Domain NC; последний контекст относится к домену, в состав которого входит рассматриваемый DC). Даже в том случае, когда DC выполняет функцию сервера глобального каталога (GC) и хранит частичные копии контекстов имен других доменов, DC не авторизован для работы с «чужими» доменами в качестве маршрутизатора потока репликации. Отсюда следует, что для сайта, состоящего из нескольких доменов, требуется несколько серверов-мостов для поддержания трафика репликации.

Как же обычный DC становится bridgehead-сервером? По умолчанию, программа проверки целостности, Knowledge Consistency Checker (KCC), организует выборы на роль сервера-моста. Как только KCC выстроит топологию репликации, каждый DC в каждом сайте оценивается на предмет соответствия параметрам сервера-моста. По сути KCC пытается сформировать список из минимального числа DC для репликации всех трех контекстов именования между «родным» сайтом и любым соединенным с ним сайтом. Если на роль bridgehead подходит два и более серверов, KCC сортирует их по возрастанию глобального уникального идентификатора, GUID, и выбирает сервер с наименьшим значением GUID.

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

Для назначения предпочтительных серверов можно воспользоваться оснасткой Active Directory Sites and Services Microsoft Management Console (MMC). Открыв оснастку, нужно перейти к серверу DC, который планируется задействовать в качестве предпочтительного. Затем следует открыть контекстное меню объекта DC и выбрать Properties. После этого необходимо выбрать транспортный протокол (или RPC поверх IP, или SMTP) репликации и нажать Add. Если в сети используется несколько транспортных протоколов, и администратор хочет назначить для сайта предпочтительные серверы-мосты, то для каждого протокола также надо назначить по одному серверу.

Служба Windows 2000 File Replication Service

Windows 2000 Server использует службу File Replication Service (FRS) для репликации информации, хранящейся в каталоге системного тома ((sysvol). Кроме того, FRS нужна для синхронизации наборов реплик Distributed File System (Dfs). FRS — правопреемник службы LMRepl из состава Windows NT 4.0. Рассматривая вопросы, связанные с репликацией AD, упомянуть о FRS необходимо по двум причинам.

Во-первых, поскольку общий ресурс sysvol требуется реплицировать на все контроллеры домена, у него должно быть свое место в топологии репликации. Несколько упрощая ситуацию, можно сказать, что FRS «встраивается» в топологию репликации, создаваемую программой KCC для AD. Исключением из этого правила является набор реплик Dfs, которые настраиваются через оснастку Dfs консоли MMC. Репликация объектов в AD протекает иначе, чем репликация sysvol. Одно из различий состоит в том, что данные каталога реплицируются между сайтами в сжатом виде, в то время как реплицируемые файлы на томе sysvol не сжимаются.

Во-вторых, служба FRS очень важна для групповых политик Group Policy. Объекты групповой политики Group Policy Object (GPO) имеют два компонента — контейнер, Group Policy Container (GPC), и шаблон — Group Policy Template (GPT). GPC находится в AD и содержит все параметры свойств объекта, описанного для GPO. GPT находится на томе sysvol в каталоге, имя которого соответствует глобальному идентификатору политики GUID (см. Экран А). В этом каталоге хранится информация о настройках безопасности и административных политиках-шаблонах, здесь же находятся файлы-сценарии и приложения, которые Windows 2000 публикует или декларирует через ту или иную политику.

Экран А. Внутри каталога sysvol.

Если версии GPC и GPT не синхронизированы — скажем, если они реплицировались в разное время или если одна часть GPO присутствует, а другая — нет, то Windows 2000 не станет применять данную политику. Это явный сбой, и подобные ошибки фиксируются в журнале Application с кодами 1000, 1001 с пояснением, что Windows 2000 не может распространить указанную политику из-за отсутствия необходимой части (GPT) на томе sysvol. В этом случае следует воспользоваться программой Group Policy Verification Tool (gpotool.exe) для выяснения причин сбоя. Gpotool опрашивает каждый DC и устанавливает, какие политики присутствуют на контроллере домена, какие версии им присвоены в каталоге и как они соотносятся с версиями политик на томе sysvol. О любых несоответствиях версий Gpotool информирует администратора системы.