Разговор на «ты». Репликация Active Directory. Часть 2

	ИЛЬЯ РУДЬ, сертифицированный тренер Microsoft, специализируется на технологии Active Directory, один из основателей ресурса itband.ru
	КОНСТАНТИН ЛЕОНТЬЕВ, архитектор подразделения консалтинга Microsoft Services в России, занимается технологиями Core Infrastructure. Обладатель высшей сертификации Microsoft Certified Architect и Microsoft Certified Master по специализации Windows Server 2008 Directory

Разговор на «ты»
Репликация Active Directory. Часть 2

Продолжаем разговор о репликации, начатый в первой части статьи. Усложним задачу и внесем территориальное разделение сегментов вашей сети

Межсайтовая репликация

И вот ваша фирма обзавелась несколькими филиалами, каждый из которых имеет свое территориальное местоположение. Естественно, эти офисы выделены в отдельные подсети, которые соединены WAN-каналами, и произведена настройка маршрутизации. Как быть в такой ситуации? Можно оставить все контроллеры в одном офисе, и тогда клиентам не останется ничего, кроме общения с контроллерами доменов по WAN-каналам. Конечно, данный трафик можно шифровать, используя IPsec, но как быть в случае падения WAN-канала? Ведь при недоступности контроллера домена клиенты не смогут войти в сеть и начать работу в домене.

Примечание: надо заметить, что трафик Kerberos шифровать не обязательно, т.к. он уже имеет защиту от man-in-the-middle. Что касается RPC, то он более уязвим, но только в ситуации «по умолчанию», когда разрешено незащищенное RPC-взаимодействие. Однако можно включить жесткое требование в групповой политике домена для шифрования и подписывания RPC и SMB.

Вывод напрашивается сам собой: установить в каждом филиале по контроллеру домена.

Просто раскидав по офисам контроллеры домена, проблемы не решить. Необходимо обеспечить выполнение двух условий:

• Каждый клиент при аутентификации должен обращаться к ближайшему контроллеру домена для получения билетов Kerberos. При этом и групповые политики также должны применяться с ближайшего контроллера (эти взаимодействия называются трафиком регистрации компьютеров и пользователей).
• Репликация изменений внутри сайта (например, одного офиса) осуществляется согласно схеме уведомлений с расписанием, описанной в первой части статьи [1]. Репликация же между контроллерами, находящимися в разных сайтах (например, в разных филиалах), происходит только по расписанию. Хотя при желании систему уведомлений для межсайтовой репликации можно включить, воспользовавшись утилитой repadmin.

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

Создание сайта производится через оснастку «Active Direcory – cайты и службы». Если до этого сайты не конфигурировались, то все контроллеры домена будут принадлежать к сайту с именем Default-First-Site-Namе.

При создании нового сайта вы обязаны указать, какой SiteLink будет использоваться для соединения. SiteLink или «Связь сайтов» – это логическая цепочка, связывающая два и более сайтов; если будет проще для восприятия, можно ассоциировать ее с физическим каналом, соединяющим сайты. Для чего же нужна эта цепочка? Ее задача – управлять межсайтовой репликацией. Одна «Связь сайтов» уже создана по умолчанию, в ней задано использование IP-протокола для репликации с запуском ее раз в 180 минут.

Как только сайтов становится больше двух, может возникнуть потребность в создании новых SiteLink-ов. Рассмотрим жизненную ситуацию. Ваша фирма имеет два офиса, главный находится в Москве, он соединен каналом с ростовским офисом. Открывается еще один филиал в г. Сальск, и этот филиал имеет медленный, загруженный и нестабильный канал с ростовским участком. Перед вами стоит задача: обеспечить выполнение двух вышеназванных пунктов и вдобавок гибко настроить репликацию между сайтами. Вы решили, что новые данные из Москвы в Ростов-на-Дону должны реплицироваться ежечасно, а вот из Ростова в Сальск репликация должна проходить только в ночное время, дабы не нагружать и без того проблемный канал (см. рис. 1).

Рисунок 1. Схема сайтов и их связей

Действия администратора в такой ситуации довольно просты: первым делом он создает сами сайты; эта процедура предельно проста и требует ввода только имени сайта и используемой связи. Настоятельно рекомендуется при этом сразу назначить на вновь созданные сайты соответствующие им IP-подсети. Первоначально для связи сайтов можно использовать созданную автоматически при инсталляции службы каталогов связь DEFAULTIPSITELINK.

После этого администратор создает две «Связи сайтов»: одну – для стыковки сайтов Москва-Ростов, вторую – для Ростов-Сальск. После создания необходимо сконфигурировать расписание открытия окна репликации, доступ к настройкам которого легко получить в свойствах нужной связи.

Получив нужную структуру сайтов, следует задать, какие контроллеры в каком сайте должны обслуживать клиентов; сделать это можно обычным перетаскиванием объектов контроллеров домена между папками Servers в разных сайтах. Однако более правильным и рекомендуемым компанией Microsoft способом распределения между сайтами считается инсталляция контроллера домена с таким IP-адресом, который попадает в заданную вами подсеть, принадлежащую нужному вам сайту. Внимательные администраторы заметили, что при создании связей кроме расписания задается их стоимость. Это неспроста: возможны ситуации, когда сайты связаны сразу с несколькими другими и возникает ситуация, когда у репликационного трафика есть несколько возможных путей. Именно тогда и начинают учитываться стоимости: чем меньше стоимость связи, тем приоритетней путь для репликации (см. рис. 2).

Рисунок 2. Схема сайтов и их связей со стоимостью

Правил несколько:

• Межсайтовая репликация идет по самому «дешевому» маршруту.
• Если между двумя сайтами есть несколько маршрутов и они одинаковы по стоимости, то будет выбран тот маршрут, который использует меньше «прыжков» или SiteLink-ов.
• Если и стоимость, и количество прыжков одинаковы, будут учитываться названия сайтов, где приоритет получат пути через сайты, имена которых начинаются с первых букв алфавита.

Зная это, можно точно сказать, что при репликации с контроллеров домена Москвы в Сальск информация будет реплицирована, используя Связь 3, так как при одинаковой цене (100 = 50 + 50) этот вариант предполагает единственный прыжок.

Пока мы не ответили на один очень важный вопрос: как клиент Москвы поймет, что ему нужно обращаться в первую очередь к контроллерам B1, B2 или B3? И только если они недоступны, пытаться аутентифицироваться на каком-либо другом контроллере. В той же оснастке в папке Subnets администратором создаются объекты «подсеть», которые впоследствии закрепляются за нужным сайтом. То есть если вы создали сайт «Ростов-на-Дону» и закрепили за ним подсеть 192.168.5.0/24, все клиенты, имеющие IP-адрес в данной подсети, будут считать себя членами данного сайта. За одним сайтом может быть закреплено сразу несколько подсетей. Более того, если получится так, что у сайта «А» подсеть будет, скажем, 192.168.0.0/16, а у сайта «Б» подсеть будет 192.168.1.0/24, то для рабочей станции или сервера, скажем, с IP-адресом 192.168.1.15 будет выбран сайт «Б». Отсюда вывод, что выбор сайта при совпадении назначенных подсетей с разными масками производится в пользу сайта с наиболее «узкой маской» подсети. То есть с маской с большим числом единиц в двоичной нотации.

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

set logonserver

которая вернет вам имя контроллера, аутентифицировавшего клиента:

Однако в Windows2000 и XP эта переменная далеко не всегда оперативно обновляется. Поэтому можно воспользоваться еще одной командой:

nltest /DSGETDC:<имя домена>/KDC /GC

В случае если контроллер, который был выбран рабочей станцией в качестве LogonServer-а, окажется недоступен, примерно через 15 минут это будет обнаружено и будет выбран другой доступный контроллер домена. Этот процесс называется DCLocator и имеет первостепенное значение в части отказоустойчивости работы AD. Также этот процесс можно запустить принудительно командой:

nltest /DSGETDC:<имя домена>/force

В межсайтовой репликации есть одна особенность, связанная с наличием сервера-плацдарма (Bridgehead Server), в задачу которого входит обеспечение межсайтовой репликации, т.е. если контроллер домена B3 создаст новый объект в базе, то он должен его реплицировать на сервер-плацдарм сайта Москва, а тот, в свою очередь, реплицирует на плацдарм ростовского сайта, где последующее распространение будет идти по стандартной внутрисайтовой схеме.

Bridgehead-сервера для каждого сайта выбирается автоматически с помощью службы KCC, но при желании администратор может самостоятельно задать один или более Bridgehead-ов для сайта. Данная манипуляция производится в свойствах нужного сервера оснастки «Active Direcory – сайты и службы», где указывается, для каких протоколов данный сервер будет плацдармом. Поскольку в большинстве ситуаций это протокол IP, то его и нужно добавить на выбранном сервере (см. рис. 3).

Рисунок 3. Ручное указание Bridgehead-сервера

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

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

repadmin /bridgeheads

Важно отметить, что при ручном указании сервера Bridgehead для сайта он будет один выполнять эту функцию. Если же сервер Bridgehead не задан и выбор делает KCC автоматически, то для Windows Server 2003 KCC осуществляет балансировку количества линков репликации между несколькими контроллерами в сайте. Кроме того, такую балансировку можно выполнить и в ручном режиме утилитой adlb.exe.

Поговорим о межсайтовых мостах

Посмотрим на рис. 4. На нем изображена схема сети, состоящей из трех сайтов, каждый из которых находится в своей подсети и своем городе. Связи сайтов настроены так, что Белград имеет SiteLink, соединяющий его с Москвой, и SiteLink, соединяющий его с Токио. Москва и Токио между собой напрямую не связаны.

Рисунок 4. Идеология Site Link Bridge

А теперь давайте попробуем ответить на вопрос: Каким путем будут реплицироваться изменения с контроллера домена А1 на контроллер домена С1? Те, кто внимательно читали статью, скажут, что контроллер домена А1 передаст изменения серверу-плацдарму в своем сайте. Тот, в свою очередь, согласно расписанию «Связи» передаст их на сервер-плацдарм сайта Белград. И только потом плацдарм Белграда, опять же по расписанию, передаст их на токийский плацдарм. И уже с него они будут реплицированы на контроллер С1. Те, кто так скажут, будут правы.

Что же произойдет, если белградские контроллеры станут недоступны или просто этот сегмент сети окажется отключен? Остановится ли репликация между сайтами Москва и Токио?

По умолчанию Active Directory пытается решить данную проблему. Она (ADDS) видит, что Москва связана с Белградом, Белград с Токио, а сайт Белграда пропал с радаров, и репликация остановилась. Видит и допускает, что мы имеем полностью маршрутизируемую сеть. А если сеть полностью маршрутизируемая, то почему не передать напрямую (с контроллера А1 на С1 сразу)?

Такая транзитивность называется Site Link Bridging. Служба KCC начинает создавать репликационные связи между контроллерами из несвязанных SiteLink-ми сайтов и реплицировать данные напрямую. Естественно, если вы не имеете полностью маршрутизируемой сети, то такая дефолтная логика вас не устроит. Поэтому вам может потребоваться отключить автоматический Site Link Bridging. Делается это довольно просто, и уже после отключения логика репликации будет идти по классической схеме. А при падении канала с центральным сайтом, в моем случае – Белград, репликация между сайтами попросту остановится.

Рисунок 5. Включение и отключение функции автоматического Site Link Bridging (опция «Установить мост для всех связей сайтов»)

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

Там, где сеть не полностью маршрутизируемая, автоматическое создание мостов (Site Link Bridging) следует отключать. Но как быть, если сеть довольно крупная и в ней присутствуют как группы сегментов с полной маршрутизацией, так и с частичной. Отключение Site Link Bridging лишит нас резервного механизма репликации для всех сегментов сети.

Специально для таких целей существует функция создания мостов между конкретными сайтами, осуществляется она также через оснастку «Active Directory – сайты и службы» (см. рис. 6).

Рисунок 6. Создание моста между сайтами

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

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

По умолчанию при репликации контроллеры домена устанавливают соединение по 135/tcp, 135/udp портам (так называемый RPC endpoint mapper), после чего согласовывают порты, которые будут использоваться при репликации данных. Тут то и появляется проблема, диапазон портов, которые могут быть задействованы, очень велик 1024-65535/tcp. Открытие этих портов полностью нивелирует файервол, превращая его в головку швейцарского сыра.

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

Для жесткой привязки порта репликации Active Directory используется ключ:

• Registry key: HKEY_LOCAL_MACHINESYSTEMCurrent ControlSetServicesNTDSParameters;
• Registry value: TCP/IP Port;
• Value type: REG_DWORD.

Еще один очень полезный ключ для фиксации RPC-трафика регистрации пользователей и компьютеров в процессе NetLogon-а и DCLocator-а: (трафика от клиентов к контроллерам домена при установлении SChannel и при поиске «родных» сайтов):

• Registry key: HKEY_LOCAL_MACHINESYSTEMCurrent ControlSetServicesNetlogonParameters;
• Registry value: DCTcpipPort;
• Value type: REG_DWORD.

Вот здесь не стоит забывать, что групповая политика – важная часть доменной структуры Active Directory, а каждый контроллер домена хранит свою копию политик. Групповая политика состоит из двух частей: связывающего объекта GPO (в нем название политики, ее идентификатор (GUID), дата создания, дата изменения, версия), который хранится в Active Directory и реплицируется ее средствами, и собственно настроек политики, а также ее шаблонов (параметры политики, передаваемые клиентам как двоичные файлы и файлы adm, admx, adml), находящихся в папке SYSVOL.

Папка SYSVOL не реплицируется средствами AD, ее синхронизация обеспечивается технологией NtFRS или DFS-R.

Расписание межсайтовой репликации SYSVOL соответствует расписанию AD, но не допускает межсайтовой нотификации. Внутрисайтовая репликация тоже осуществляется по расписанию NTFRS/DFS-R, задаваемому в реестре. Репликация является мультимастерной, т.е. источником изменений может быть любой контроллер. Если изменения произошли на нескольких контроллерах, приоритет будет иметь изменение, сделанное последним. Более подробно репликацию NTFRS или DFS-R мы не будем рассматривать в этой статье, т.к. это совершенно другая тема.

Когда вы добавляете в ваш домен Active Directory, построенный на базе Windows Server 2003, новый контроллер Windows Server 2008, он по-прежнему использует для репликации групповой политики File Replication service (NtFRS).

Для фиксации порта NtFRS используется ключ:

• Registry key: HKEY_LOCAL_MACHINESYSTEMCurrent ControlSetServicesNtFrsParameters;
• Registry Value: RPC TCP/IP Port Assignment;
• Value type: REG_DWORD.

При создании нового домена Active Directory на базе Windows Server 2008 (режим работы домена Windows Server 2008 и новее) для репликации групповой политики используется Distributed File System (DFS) Replication. Если вы обновили ваш домен с Windows Server 2003 до уровня 2008, то этот функционал нужно активировать дополнительно утилитой DFSRMIG.exe.

Distributed File System (DFS) Replication – это сервис, реплицирующий папку SYSVOL на все контроллеры домена, работающего в функциональном режиме Windows Server 2008. Впервые DFS Replication появилась в Windows Server 2003 R2, но для репликации SYSVOL ее можно использовать только в Windows Server 2008.

Какие преимущества имеет DFS Replication?

• В Windows Server 2003 при изменении файла в SYSVOL служба FRS реплицировала весь файл целиком. При использовании DFS Replication измененный файл больше 64 Кб реплицируется частично, т.е. только блоки размером 64 Кб с изменениями.
• При передаче данных DFS-R эффективно сжимает их алгоритмом, схожим с ZIP.
• Масштабируемое решение. Размер папки SYSVOL может достигать нескольких терабайт.
• Новая графическая оснастка «Управление DFS» для более удобного администрирования.
• Улучшенная поддержка Read Only Domain Controllers.
• Наличие встроенных средств мониторинга и утилиты для развертывания.
• Технология, требующая минимального контроля и администрирования со стороны системного администратора.

Тем, кого заинтересовал процесс перехода, необходимо познакомиться с утилитой dfsrmig, которая позволяет произвести процесс миграции с FRS на DFS. Основными ключами для работы будут /GetMigrationState и /SetGlobalState. Подробней о процессе миграции можно прочитать в статье http://itband.ru/2009/05/sysvol-dfs.

Если вы идете в ногу с прогрессом и ваша папка SYSVOL реплицируется средствами DFS-R, вам также ничто не мешает статически закрепить порты, которые будут использоваться при DFS-репликации.

Делается это следующим образом:

Вводим команду:

dfsrdiag dumpmachinecfg

Если команда возвращает 0, значит, у вас используется динамическое назначение портов для DFS-репликации.

Указываем статический порт:

dfsrdiag StaticRPC /port:nnnnn /Member:dc.itband.ru

Информация о порте репликации будет храниться в XML-файле по следующему пути: %SYSTEMDRIVE%System Volume InformationDFSRConfigDfsrMachineConfig.XML.

Вдобавок к теме используемых портов остается привести ссылку на статью базы знаний Microsoft «Службы и сетевые порты в серверных системах Microsoft Windows» (http://support.microsoft.com/kb/832017). В ней указан список портов, которые могут понадобиться для работы различных сервисов Microsoft Windows и в частности Active Directory.

Утилита repadmin

Для управления репликацией существует две утилиты: repadmin (консольная) и replmon (графическая). С выходом WindowsServer 2008 продолжение развития получила только утилита repadmin, ее функционала вполне достаточно, чтобы дополнить оснастку «Active Directory – сайты и службы» и дать администраторам возможность гибко управлять репликацией.

Рассмотрим несколько примеров ее использования:

repadmin /syncall DC1 dc=itband,dc=ru
repadmin /syncall DC1 cn=configuration,dc=itband,dc=ru
repadmin /syncall DC1 cn=schema,cn=configuration,dc=itband,dc=ru

Три приведенных варианта использования repadmin запускают репликацию различных разделов каталога контроллера DC1 с его репликационными партнерами в сайте ActiveDirectory.

repadmin /replsummary

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

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

repadmin /showchanges dc1 7b2b9e16-895f-414d-a7b0-5e48f502935c dc=lab,dc=itband,dc=ru

В данном примере указан контроллер, с которым нужно произвести сравнение (DC1), и invocationID (уникальный идентификатор экземпляра базы ActiveDirectory) контроллера, с которого производится запуск. InvocationID, в свою очередь, можно узнать командой:

repadmin /showsig dc2

Набор ключей, которые имеет repadmin, несколько шире, чем представлено в стандартной справке, и часть их спрятана (см. рис. 7).

Рисунок 7. Нереплицированное изменение

Получить доступ к полной версии можно через команду:

repadmin /? /experthelp

Несмотря на предупреждение о том, что данные команды должны использоваться только под присмотром Premier Support Microsoft, некоторые из них стоит взять на вооружение.

Repadmin /options DC1 +DISABLE_OUTBOUND_REPL +DISABLE_INBOUND_REPL

Эта команда отключает входящую и исходящую репликацию на контроллере DC1, очень удобное средство в случае, если необходимо срочно остановить распространение изменений.

Обратно включение производится аналогично, только перед параметром необходимо установить минус (-DISABLE_INBOUND_REPL).

***

Информация, полученная после вдумчивого прочтения двух частей данной статьи, должна сформировать понимание у специалиста идеологии репликации и построения многосайтовых систем. Но все же очень много осталось за кадром. А именно: задачи и сценарии SMTP-репликации, объемы трафика репликации для разных типов объектов, влияние на репликацию таких вещей, как захоронение и восстановление объектов, ну и, конечно, USN rollback. И пусть не в каждой организации вам понадобится знание вышеперечисленного, но для реализации крупных решений эти нюансы в голове должны быть проработаны.

1. 1. Рудь И., Леонтьев К. Разговор на «ты». Репликация Active Directory. //Системный администратор, №1-2, 2010 г. – С. 54-59.

Комментарии могут оставлять только зарегистрированные пользователи