Главная Windows, Без рубрики, Новое Репликация 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_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters

    Registry value: TCP/IP Port

    Value type: REG_DWORD

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

    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters

    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_MACHINE\SYSTEM\CurrentControlSet\Services\NtFrs\Parameters

    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. Подробней о процессе миграции можно прочитать в статье http://itband.ru/2009/05/sysvol-dfs/ .

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

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

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

    2. Указываем статический порт «dfsrdiag StaticRPC /port:nnnnn /Member:dc.itband.ru».

    Информация о порте репликации будет храниться в XML-файле по следующему пути %SYSTEMDRIVE%\System Volume Information\DFSR\Config\DfsrMachineConfig.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. И пусть не в каждой организации вам понадобится знание вышеперечисленного, но для реализации крупных решений эти нюансы в голове должны быть проработаны.

    Илья Рудь

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

    http://kleontiv.spaces.live.com/

    Статья опубликована в журнале “Системный администратор” от 03.2010

Комментарии

  1. неужели я единственный кто ничего из статьи не понял?
    завтра на свежую голову попробую перечитать

  2. Все доступно и понятно, хотя и с большим количеством очепяток 🙂

  3. Прям с большим? ) Скажите где, я подправлю )

  4. Илья, хорошая статья. 🙂

  5. Илья, скажите, а есть в планах еще статьи про репликацию AD? Дабы рассмотреть вопросы, оставщиеся за кадром?

  6. по репликации вроде все понятно, но:
    сейчас как раз занимаюсь организацией подобной схемы (несколько филиалов в разных городах)
    есть какие-либо рекомендации по организации связи между сайтами?
    я использую vpn-туннели в ISA Server – так при такой организации связи у меня постоянно валятся ошибки “ошибка удаленного вызова процедуры.”

  7. В планах есть, но времени на планы нет (

  8. Было бы здорово в заключение цикла статей включить траблшутинг и best-practices. Шесть лет назад для меня это было очень важно, как и многим нынешним новоиспеченным админам, впервые столкнувшимся с внутри- и межсайтовой репликацией 🙂

  9. Большое спасибо за статью! Четко и конкретно.
    Отдельное спасибо за упоминание o DFSRMIG и “скрытых” ключах repadmin.

    Есть 1 вопрос о наличии нескольких подсетей внутри 1 сайта.
    Задам его на примере:
    К сайту А отнесли 2 подсети: 192.168.0.0/24 и 192.168.1.0/24.
    Внутри сайта 2 контроллера домена: 192.168.0.2 и 192.168.1.2.
    К какому DC будет обращаться рабочая станция с IP-адресом 192.168.1.15.
    По какому алгоритму будет выбираться DC и будет ли вообще иметь значение подсеть в данном случае?

    Заранее спасибо за ответ.

    И еще маленькое дополнение, о котором не было упомянуто. Может кому-то окажется полезным.
    Read only DC не могут быть bridgehead-серверами.
    Этот факт стоит учитывать при планировании структуры сайтов, если Вы собираетесь использовать назначение bridgehead-серверов вручную.

  10. 2Александра Истратова
    Поиск ближайшего контроллера домена, происходит следующим образом:
    Во первых, в реестре у клиента хранится его последний сайт:

    HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesNetlogonParameters

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

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

    Read only DC не могут быть bridgehead-серверами.
    Совершенно логично, что не могут быть.

  11. // К какому DC будет обращаться рабочая станция с IP-адресом 192.168.1.15.

    По умолчанию – к произвольному из своего сайта (если домашний сайт ей известен). Но это поведение можно изменить, например, задействовав “netmask ordering”: http://support.microsoft.com/kb/842197.

  12. 2Баканов Денис и Дмитрий Пономарев

    спасибо большое!.. все понятно
    за ссылку про упорядочение с сетевой маской спасибо отдельное -)

  13. Коллеги!

    1) Что по вашему (кроме troubleshooting-а и best practices) вы хотели бы видеть в продолжении статьи?
    2) Касательно VPN каналов и задержек – видать у вас действительно каналы весьма слабые. Есть возможность увеличить тайм-ауты вызовов RPC при репликации (http://support.microsoft.com/kb/830746), но уверяю вас, что это не лучший способ решить вашу проблему.
    3) Выбор контроллера в процессе DC Locator многостадийный и может случиться так, что процесс логина пользователя будет обслужен не одним контроллером а несколькими. То что обсуждалось по поводу Network Mask Ordering это только первая часть процесса DC Locator – поиск контроллера домена в DNS (nslookup /DNSgetdc:), есть еще и другие NetLogon ping, Netlogon site discovery (nslookup /DSgetdc:), получение билетов Kerberos, получение SYSVOL DFS Referral и наконец фильтрация, скачивание и применение групповых политик. Вообще эта тема (AD Client Interactions) достойна отдельного цикла статей.

  14. Константин, откровенно говоря, вторая часть статьи получилось хуже первой (имхо). Создается впечатление, будто она писалась второпях – не хватает системности, структурированности и, извините, полно ошибок в великом и могучем.
    Было бы очень здорово, если бы в статьях было побольше:
    1) примеров из практики (личного опыта, опыта коллег) решения не совсем стандартных задач, возможно не совсем стандартными методами;
    2) описания малоизвестных (или недокументированных, если есть))) возможностей;
    3) указания на недостатки/недоработки тех или иных технологий или решений.

  15. >>я использую vpn-туннели в ISA Server — так при такой организации связи у >>меня постоянно валятся ошибки «ошибка удаленного вызова процедуры.

    Если у Вас в разных сайтах стоят Домен Контроллеры на 2003 и на 2008 Windows, то ошибка, возможно, возникает по вине RPC фильтра, включенного в ISA. Имеет смысл попробовать его отключить (Конфигурация- надстройки- фильтры приложений- RPC фильтр). Потом в правиле, созданном автоматически, имеет смысл проверить стоит ли галка, что то типо “Требовать строгого соответствия RPC” (это, вроде, в настройках протокола RPC для правила).

    Потом, опять таки, какой протокол используется? Мы используем pptp. Вроде меньше проблем, чем с темже IPsec.

    Просто мне неоднократно приходилось с этим бороться.. Когда сидишь в какой-нибудь деревне и ждешь, когда пройдет реплика 🙂

  16. “При подключение, когда компьютер пытается залогинится, то он запрашивает контроллеры домена из этого сайта.”
    А когда контроллеры его “старого” (взятого с реестра) сайта не доступны, или у компьютера нет “старого” сайта, то, насколько я помню, компьютер спрашивает первый попавшийся контроллер домена любого сайта, верно?

  17. Андрей Шимкин, нет не так. Но вопрос – отличный! Это зависит от настроек DNS и если включен Net Mask Ordering, то “ближайший” с точки зрения IP-адресации. Однако он может быть не из “ближайшего” сайта с т.з. стоимости сайт-линков.

    Кроме того есть настройки, задающие Site Coverage, это позволяет явно задать контроллеры домена из любых других сайтов, которые могут обслуживать клиентов. Управляя настройками регистрации DNS: Site Coverage и Priority вы можете создать гибкую и отказоустойчивую топологию, при этом с абсолютно детерминированным процессом выбора контроллеров домена в случае единичных отказов контроллеров в сайтах и при минимально возможном количестве контроллеров во всех сайтах (обычно хватает одного).

  18. Ну и наконец, следует помнить, что есть ДВА типа SRV-записей о контроллерах домена в DNS – это site-specific и global. Есть настройки которые позволяют сообщить контроллерам, какие из этих двух категорий записей будет регистрировать в DNS контроллер. Это тоже необходимо для обеспечения детерминированного процесса DC Locator.

  19. Спасибо за пояснения и столь полезный линк про Net Mask Ordering.
    Ждем “AD Client Interactions” 🙂

  20. Ребята, респект и уважуха!!!
    Не первый год работаю с AD и по поводу межсайтовой репликации у меня всегда возникали вопросы.

    Хочу выразить отдельную благодарность за пример с Токио, Москва, Белград у меня очень похожая топологи на предприятии 🙂

    Огромнейшее спасибо.

  21. artem_, я могу добавить по поводу Site Link Bridging… Если отключать BASL (Bridge All Site Links) как показано на рис. 17, то будут проблемы с работой DFS-N. Для того, чтобы избежать этого у repadmin есть специальная настройка (опиция) repadmin /siteoptions +W2K3_BRIDGES_REQUIRED. Эта опция сайтов позволяет не отключая BASL и не ломая логику работы DFS – запертить или разрешить использовать сайт как мост для создания линков репликации.

  22. Мне как соавтору, нравятся обе части. Да, пожалуй концовку второй можно было бы получше сделать, но как обычно время самый дефицитный ресурс отсутствовал. Но все же, пусть это не скромно, получилось хорошо.

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

    Спасибо за отзывы, они всегда ценны.

    P.S Коллеги, тем кому мешают ошибки, я как обычно, могу предложить два варианта: а) Покупать журнал СА (там за этим следят корректоры) б) Поучаствовать в жизни сайта и вычитать статьи перед выкладкой.

    Второй вариант лучше 🙂

  23. Спасибо, Константин. Очень полезная фича.

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

    Еще раз спасибо.

  24. artem_, не совсем так… Опция +W2K3_BRIDGES_REQUIRED указывается для сайта (а не сайтлинков, как это делается в случае Bridge) и по своей сути говорит, что данный сайт не поддерживает через свою сеть “сквозную” (или если хотите транзитивную) маршрутизацию и как следствие все его линки с другими сайтами не могут формировать Бриджи даже при включенном BASL. На мой взгляд это более логичный и правильный способ управлениея топологией репликации. Однако он менее нагляден по сравнению с GUI интерфейсом по созданию Site Link Bridge.

  25. Огромнейшее Вам спасибо, Константин. Это полезная фича.

  26. > 3) Выбор контроллера в процессе DC Locator многостадийный и может случиться так, что процесс логина пользователя будет обслужен не одним контроллером а несколькими. То что обсуждалось по поводу Network Mask Ordering это только первая часть процесса DC Locator — поиск контроллера домена в DNS (nslookup /DNSgetdc:), есть еще и другие NetLogon ping, Netlogon site discovery (nslookup /DSgetdc:), получение билетов Kerberos, получение SYSVOL DFS Referral и наконец фильтрация, скачивание и применение групповых политик. Вообще эта тема (AD Client Interactions) достойна отдельного цикла статей.

    Константин, здесь, наверное, имели ввиду всё-таки команды nltest /DNSgetdc: и nltest /DSgetdc:? Торопились, наверное. 😉 Спасибо за очень полезные комментарии.

  27. Да, Anatoly Ivanitchev, вы верно заметили про nslookup/nltest. Более того, приятно, что вы задумались и выяснили/уточнили о чем идет речь. 🙂

  28. Приветствую!
    Если родительский домен является центром зведы в репликации с дочерними(около 80-ти), мостов нет, лес в режиме Win2003. Как лучше поступить с назначением Bridgehead server, назначит один сервер или назначить несколько, все? Есть в памяти противоречивые советы из разных источников… Раньше думал что будут проблемы если одновременно репликация возможна с одного сервера на несколько серверов другого домена.

  29. Dread, более подробно мы с Ильей опишем (я надеюсь) настройки репликации и другие детали построения такой топологии в одной из следующих статей из цикла AD.

  30. Я не понимаю как на физическом уровне происходит репликация через мост сайтовых связей (site link bridge), в случае недоступности промежуточного контроллера домена и отсутствии полной маршрутизации.
    Пример: домен А с подстетью 192.168.0.0/24, домен Б с подсетью 192.168.1.0/24 и домен В с подсетью 192.168.2.0/24. У домена А есть маршрут до сети содержащей Б, у домена Б есть маршруты до сетей А и В, а у домена В есть маршрут до сети Б. Создание мостов для связей сайтов включено, либо же мост создан вручную, расписания репликации АБ и БВ пересекаются. Но на весь период репликации контроллер Б выключен или недоступен, но сами соединения между сетями в рабочем состоянии. Как в этом случае произойдёт соединение А и В через мост? Или же под недоступностью контроллера домена Б подразумевается, что он просто занят в этот период и не может произвести собственную репликацию?

  31. >Как в этом случае произойдёт соединение А и В через мост?

    Происходит перестроение репликационных линков между контроллерами. И появляются те которые связывают контроллеры сайтов А и В.

  32. >Происходит перестроение репликационных линков между контроллерами. И появляются те которые связывают контроллеры сайтов А и В.

    То есть всё же необходимым условием работы моста является наличие маршрутизации между сайтами А и В?

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

  34. Bridging Site Links Manually
    If your IP network is composed of IP segments that are not fully routed, you can disable Bridge all site links for the IP transport. In this case, all IP site links are considered nontransitive, and you can create and configure site link bridge objects to model the actual routing behavior of your network. A site link bridge has the effect of providing routing for a disjoint network (networks that are separate and unaware of each other). When you add site links to a site link bridge, all site links within the bridge can route transitively.

    Я вот этот раздел невнимательно прочитал! Мосты должны следовать модели реальной маршрутизации сети. То есть всё же если маршрутизации между А и В нет, то создавать мост (по крайней мере синхронный, насчёт асинхронного ещё не уяснил) нельзя. Теперь я правильно понимаю?

  35. Да, вы правильно поняли, без этого толку не будет.

  36. Спасибо огромное! Статья супер! не хотите ли осветить использование сайта без домена, к примеру для ДФС…

  37. Илья, что делать? Ситуация такая, есть два контроллера lg-dc01.lg.dom.com и lg-dc02.lg.dom.com
    в сайте(сайтов много это наш, AD сделан c пустым родительским корневым доменом dom.com и кучей дочерних-один из них наш ). Также на каждом DNS и WINS . Ось на контроллерах –windows 2003 sp2. Далее буду для краткости называть контроллеры dc01 и dc02. Dc02-маломощный сервер, роль на нем одна –infrastructure master. Dc01-мощный –на нем все остальные роли плюс глобальный каталог. Сегодня заметил, что не проходит репликация между двумя этими контроллерами-если на dc01 делаешь изменения-они не реплицируются на dc02. А вот наоборот репликация идет
    Вручную пробовал запустить-толку нет. Не реплицируется только раздел domain, вся остальная репликация проходит
    c:>repadmin /replicate dom-dc02.lg.dom.com dom-dc01.lg.dom.com dc=dom,dc=com
    DsReplicaSync() failed with status 1818 (0x71a):
    Удаленный вызов процедуры был отменен. Что делать-то . Похерить проблемный контроллер(три дня такая картина) или можно как-то починить?

  38. Я бы начал с удаления репликационных связей между этими контроллерами руками и запуском repadmin /kcc dc1 и repadmin /kcc dc2 на каждом.

    Потом поставил бы replmon и форсировал бы репликацию между этими контроллерами, посмотрел бы на результат.

  39. подробные выводы команд dcdiag /v /c и repadmin /showrepl с обоих контроллеров
    http://social.technet.microsoft.com/Forums/ru-ru/windowsserverru/thread/0f05801f-c7be-4b6b-94e9-d25595e83697

  40. Илья,спасибо и еще два слова, please
    repadmin /kcc dc1 и repadmin /kcc dc2
    восстановит порушенные связи? Рушить в том числе и направление(dc02->dc01), где репликация идет нормально. Или только dc01->dc02?
    Как с помощью replmon форсировать -выбираем раздел->synchronize with this replication partner?
    Как вообще, из опыта-шансы есть? Или ставить еще один контроллер-забирать роль infrastructure master и затем->clear metadata?

  41. 1. Да, восстановит.

    2. Да, рушить.

    3. Да. Шансы есть, я бы лучше починил.

  42. Илья, спасибо огромное. Я у Вас был на одном курсе и шанс выпадет-на Ad приеду обязательно! Я с таким(проблемы с репликацией на локальном сайте) раньше не сталкивался. А сколько времени у меня есть-я так понимаю, для 2003 -60 дней (шутка). Не работает три дня, из дома трогать не хочу, а на работе завтра вечером только можно -столько проживет. Пишет уже 600 изменений не среплицировалось.

  43. итак, удалил репликационных связей между этими контроллерами руками
    запустил repadmin /kcc lg-dc01.lg.dom.com и repadmin /kcc lg-dc02.lg.dom.com -обе комманды на обоих контроллерах короче говоря связи пересоздались, но репликация так и работает в одну сторону
    Ошибки :”Error replica syns failed_удаленный вызов процедуры был отменен”

  44. Давайте в режиме почты попробуем решить irud () specialist ru

  45. Илья, на почту Вам письмо отправил, спасибо

  46. отправил повторно
    a-a.ageev@ya.ru

  47. support.microsoft.com/kb/830746
    Увы и ах Николай-не помогло

  48. Спасибо Илье и Николаю!
    Увеличил время репликации, удалил связи, repadmin /kcc ,replmon-ом толкнул репликацию. Завтра поставлю новый KD, а чахлый -выведу из обращения

  49. Статья гуд! Распечатал) Спасибо!

  50. Было бы интересно почитать о “..задачи и сценарии SMTP-репликации, объемы трафика репликации для разных типов объектов, влияние на репликацию таких вещей как захоронение и восстановление объектов, ну и конечно USN rollback.” Может кто поделится ссылочкой?

  51. Доброго времени суток, мне бы хотелось уточнить как поступить в моей ситуации по тому что своего опыта очень мало, у меня в организации 6 доменов (с разными пользователями если это имеет значение) они связаны мультисервисной сетью с шириной канала в 10 мб, между ними есть односторонние доверительные отношения (главный домен имеет права в подчиненных) и так вопрос можно ли реализовать межсайтовую репликацию в моей организации и можно ли это реализовать при помощи этой инструкции?
    Заранее Спасибо.

  52. Судя по всему у вас используется 6 лесов AD с довериями – по одному на “офис”. К данной ситуации межсайтовая репликация отношения особого не имеет, т.е. объекты не реплицируются между лесами.
    Таким образом, межсайтовую репликацию следует анализировать в рамках каждого леса отдельно.

  53. Вопрос по правилам

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

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

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

    А что будет в ситуации когда есть 2 маршрута:
    1й: 3 перехода с ценой 100
    2й: 2 перехода с ценой 500

    Насколько помню, приоритет имеет наименьшее число переходов, вне зависимости от цены.

    ?

  54. Будет использоваться 1й вариант. Логика написанна в статье. Вы помните неправильно.

  55. СУПЕР!!!

  56. Большое спасибо, выручили статьей )

  57. Вопрос по созданным вручную мостам. Воспроизвел пример с Москвой, Белградом и Токио. Так вот, мост сработает (построится новая связь) только тогда, когда Белград будет недоступен и для Москвы, и для Токио. Есть ли возможность влиять на это поведение (при отключенном BASL, разумеется)? То есть строить мост между Москвой и Токио уже тогда, когда центральный сайт (Белград) недоступен, скажем, только для Москвы.

  58. Прочитал первую и вторую часть , отличные статьи .
    Спасибо за ваш труд.

  59. […] прочитать данную статью. Очень хорошо Илья описал сайты и их взаимодействие. […]

  60. Ошибка в статье. Там где “установить мост для всех связей сайтов” на рисунке перевод этой опции “Bridge all site link” должен быть, а не “site link bridge”. В свою очередь “site link bridge” используется, когда сеть не полностью маршрутизируется.

  61. Илья добрый день!

    Уже всю голову сломал, может сталкивался с такой ошибкой репликации между сайтами AD –

    (1783) The stub received bad data. (это вывод команды repadmin /replsummary)

    Репликация раньше работала но “сломалась” ни с того ни с чего.

    Заранее спасибо)