Репликация Active Directory. Часть 2

Продолжение разговора об репликации Active Directory. Первая часть доступна по ссылке.

Репликация Active Directory: Разговор на «Ты» (Продолжение)

Adjustable_Wrenches_3C

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

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

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

 

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

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

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

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

2. Репликация изменений внутри сайта (например одного офиса) осуществляется согласно схеме уведомлений с расписанием, описанной в первой части статьи. Репликация же между контроллерами, находящимися в разных сайтах (например в разных филиалах) происходит только по расписанию. Хотя при желании систему уведомлений для межсайтовой репликации можно включить, воспользовавшись repadmin-ом.

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

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

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

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

image

Рис. 13 Схема сайтов и их связей.

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

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

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

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

1. Межсайтовая репликация идет по самому «дешевому» маршруту.

2. Если между двумя сайтами есть несколько маршрутов и они одинаковы по стоимости, то будет выбран тот маршрут, который использует меньше «прыжков» или «SiteLink-ов»

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

image

Рис. 14 Схема сайтов и их связей со стоимостью.

Зная это можно точно сказать, что при репликации с контроллеров домена Москвы в Сальск информация будет реплицирована используя Связь 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, которая вернет вам, имя контроллера, аутентифицировавшего клиента: LOGONSERVER=\B1, однако в Windows 2000 и XP эта переменная далеко не всегда оперативно обновляется. Поэтому можно воспользоваться еще одной командой:

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

В случае если контроллер, который был выбран рабочей станцией в качестве Logon Server-а окажется недоступен, примерно через 15 минут это будет обнаружено и будет выбран другой доступный контроллер домена. Этот процесс называется DC Locator и имеет первостепенное значение в части отказоустойчивости работы AD. Так же этот процесс можно запустить принудительно командой nltest /DSGETDC:<имя домена> /force.

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

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

image

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

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

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

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

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

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

image

Рис. 16. Идеология Site Link Bridge

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

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

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

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

image

image

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

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

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

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

image

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

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

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

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

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

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

HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesNTDSParameters

Registry value: TCP/IP Port

Value type: REG_DWORD

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

HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesNetlogonParameters

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 используется ключ:

HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesNtFrsParameters

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, то «DFS Replication» этот функционал нужно активировать дополнительно утилитой 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 KB реплицируется частично, т.е только блоки размером 64KB с изменениями.

При передачи данных DFS-R эффективно сжимает их алгоритмом схожим с ZIP.

• Масштабируемое решение. Размер папки SYSVOL может достигать нескольких терабайт.

• Новая графическая оснастка “Управление DFS” для более удобного администрирования.

• Улучшенная поддержка Read Only Domain Controllers.

• Наличие встроенных средств мониторинга и утилиты для развертывания.

• Технология, требующая минимального контроля и администрирования со стороны системного администратора.

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

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

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

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

2. Указываем статический порт «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 (графическая). С выходом Windows Server 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 с его репликационными партнерами в сайте Active Directory.

repadmin /replsummary

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

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

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

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

repadmin /showsig dc2

Набор ключей, которые имеет repadmin несколько шире, чем представлено в стандартной справке и часть их спрятана. Получить доступ к полной версии можно через repadmin /? /experthelp.

image

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

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

repadmin /options DC1 +DISABLE_OUTBOUND_REPL +DISABLE_INBOUND_REPL

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

Заключение

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

Илья Рудь

Константин Леонтьев

Оринигал статьи взят с ресурса itband.ru

5 1 голос
Рейтинг статьи
Подписаться
Уведомить о
guest

0 комментариев
Межтекстовые Отзывы
Посмотреть все комментарии