Site link bridge что это
Иллюстрированный самоучитель по Microsoft Windows 2003
Соединения сайтов. Расписание репликации.
Топология репликации формируется при помощи специального класса объектов – соединений (connections). Соединение представляет собой однонаправленное соглашение между двумя контроллерами домена о передаче изменений. С каждым соединением ассоциируется объект в разделе конфигурации каталога. Атрибуты объекта, ассоциированного с соединением, определяют передающего партнера по репликации, а также расписание репликации и используемый при этом транспорт. Все соединения автоматически генерируются системным сервисом Knowledge Consistency Checker, KCC, который проверяет существующую топологию и доступность имеющихся соединений и при необходимости вносит соответствующие коррективы.
Контроллеры домена, расположенные в различных сайтах и взаимодействующие между собой в процессе репликации, называются мостовыми серверами (bridgehead server). В каждом сайте один из контроллеров домена берет на себя обязанности по управлению входящими соединениями для всех мостовых серверов сайта. Этот контроллер домена называется генератором топологии между сайтами (Inter-Site Topology Generator, ISTG). Если контроллер домена, выполняющий функции ISTG, становится недоступен (например, выходит из строя), эта функция автоматически возлагается на другой контроллер домена.
В случае репликации между сайтами используется термин связь сайтов (site link), который описывает соединения двух и более узлов, способных обмениваться информацией при помощи единого транспорта. Связь узлов используется для задания стоимости соединения (cost), расписания репликации и транспорта. Механизм стоимостей позволяет оценить связь сайтов с точки зрения доступности коммуникационных линий и их пропускной способности. Если имеется несколько связей сайтов, для репликации будет выбрана та, что обладает меньшим значением стоимости.
Несколько связей сайтов, использующих единый транспорт, образуют связующий мост между узлами (site link bridge). Использование связующих мостов между сайтами полезно в больших сетях, поскольку избавляет от необходимости описывать все возможные комбинации соединений между каждым из сайтов.
Расписание репликации
Процесс репликации изменений каталога может быть инициирован одним из двух способов:
Создание проекта моста связей сайтов
Область применения: Windows Server 2022, Windows Server 2019, Windows Server 2016, Windows Server 2012 R2, Windows Server 2012
Мост связи сайтов соединяет две или более связи сайтов и обеспечивает транзитивность связи между сайтами. Каждая связь сайтов в мосте должна содержать сайт, общий с другой связью сайта в Bridge. В средстве проверки согласованности знаний (KCC) сведения о каждой связи сайтов используются для расчета стоимости репликации между сайтами в одной связи сайтов и между сайтами в других связях сайта. Без общего сайта между связями сайтов KCC также не может устанавливать прямые подключения между контроллерами домена на сайтах, подключенных одним и тем же мостом связей сайтов.
По умолчанию все связи сайтов являются транзитивными. Рекомендуется обеспечить возможность включения транзитивность, не меняя значение по умолчанию моста все связи сайтов (включено по умолчанию). Тем не менее необходимо отключить мост для всех связей сайтов и завершить структуру моста связей сайтов, если:
Дополнительные сведения об использовании оснастки «Active Directory сайтов и служб» для отключения параметра моста все связи сайтов см. в статье Включение или отключение мостов связей сайтов.
Управление потоком репликации AD DS
Два сценария, в которых требуется создать мост связей сайтов для управления ходом репликации, включают управление отработкой отказа репликации и управление репликацией через брандмауэр.
Управление отработкой отказа репликации
Если в Организации есть топология сети типа «звезда», то, как правило, не нужно, чтобы вспомогательные сайты создали подключения репликации к другим вспомогательным сайтам, если все контроллеры домена на сайте концентратора завершаются сбоем. В таких случаях необходимо отключить мост для всех связей сайтов и создать мосты связей сайтов, чтобы создать подключения репликации между вспомогательным сайтом и другим концентратором, который является всего одним или двумя узлами из вспомогательного сайта.
Управление репликацией через брандмауэр
Если двум контроллерам домена, представляющим один и тот же домен на двух разных сайтах, разрешено взаимодействовать друг с другом только через брандмауэр, можно отключить мост для всех связей сайтов и создать мосты связей сайтов для сайтов на той же стороне брандмауэра. Поэтому, если сеть разделена брандмауэрами, рекомендуется отключить транзитивность связей сайтов и создать мосты связей сайтов для сети на одной стороне брандмауэра. Сведения об управлении репликацией с помощью брандмауэров см. в статье Active Directory в сетях, сегментированных брандмауэрами.
Creating a Site Link Bridge Design
Applies to: Windows Server 2022, Windows Server 2019, Windows Server 2016, Windows Server 2012 R2, Windows Server 2012
A site link bridge connects two or more site links and enables transitivity between site links. Each site link in a bridge must have a site in common with another site link in the bridge. The Knowledge Consistency Checker (KCC) uses the information on each site link to compute the cost of replication between sites in one site link and sites in the other site links of the bridge. Without the presence of a common site between site links, the KCC also cannot establish direct connections between domain controllers in the sites that are connected by the same site link bridge.
By default, all site links are transitive. We recommend that you keep transitivity enabled by not changing the default value of Bridge all site links (enabled by default). However, you will need to disable Bridge all site links and complete a site link bridge design if:
For more information about how to use the Active Directory Sites and Services snap-in to disable the Bridge all site links setting, see the article Enable or disable site link bridges.
Controlling AD DS replication flow
Two scenarios in which you need a site link bridge design to control replication flow include controlling replication failover and controlling replication through a firewall.
Controlling replication failover
If your organization has a hub-and-spoke network topology, you generally do not want the satellite sites to create replication connections to other satellite sites if all domain controllers in the hub site fail. In such scenarios, you must disable Bridge all site links and create site link bridges so that replication connections are created between the satellite site and another hub site that is just one or two hops away from the satellite site.
Controlling replication through a firewall
If two domain controllers representing the same domain in two different sites are specifically allowed to communicate with each other only through a firewall, you can disable Bridge all site links and create site link bridges for sites on the same side of the firewall. Therefore, if your network is separated by firewalls, we recommend that you disable transitivity of site links and create site link bridges for the network on one side of the firewall. For information about managing replication through firewalls, see the article Active Directory in Networks Segmented by Firewalls.
Репликация Active Directory. Часть 2
Продолжение разговора об репликации Active Directory. Первая часть доступна по ссылке.
Репликация Active Directory: Разговор на «Ты» (Продолжение)
Продолжаем разговор о репликации, начатый ссылке. Усложним задачу и внесем территориальное разделение сегментов вашей сети.
И вот ваша фирма обзавелась несколькими филиалами, каждый из которых имеет свое территориальное местоположение. Естественно эти офисы выделены в отдельные подсети, которые соединены WAN каналами и произведена настройка маршрутизации. Как быть в такой ситуации? Можно оставить все контроллеры в одном офисе и тогда клиентам не останется ничего кроме общения с контроллерами доменов по WAN-каналам. Конечно, данный трафик можно шифровать, используя IPsec, но как быть в случае падения WAN канала. Ведь при недоступности контроллера домена клиенты не смогут войти в сеть и начать работу в домене.
Примечание: Надо заметить, что трафик Kerberos шифровать не обязательно, т.к. он уже имеет защиту от man-in-the-middle, что касается RPC то он более уязвим, но только в ситуации «по умолчанию», когда разрешено незащищенное RPC взаимодействие. Однако можно включить жесткое требование в групповой политике домена для шифрования и подписывания RPC и SMB.
Вывод напрашивается сам собой – установить в каждом филиале по контроллеру домена.
Просто раскидав по офисам контроллеры домена проблемы не решить. Необходимо обеспечить выполнения двух задач:
1. Каждый клиент при аутентификации должен обращаться к ближайшему контроллеру домена для получения билетов Kerberos. При этом и групповые политики также должны применяться с ближайшего контроллера (эти взаимодействия называются трафиком регистрации компьютеров и пользователей).
2. Репликация изменений внутри сайта (например одного офиса) осуществляется согласно схеме уведомлений с расписанием, описанной в первой части статьи. Репликация же между контроллерами, находящимися в разных сайтах (например в разных филиалах) происходит только по расписанию. Хотя при желании систему уведомлений для межсайтовой репликации можно включить, воспользовавшись repadmin-ом.
Чтобы эти задачи выполнялись эффективно необходимо сконфигурировать сайты, которые по сути являются логической группировкой клиентов и контроллеров, связанных скоростными соединениями.
Создание сайта производится через оснастку «Active Direcory Сайты и службы». Если до этого сайты не конфигурировались, то все контроллеры домена будут принадлежать к сайту с именем «Default-First-Site-Namе».
Как только сайтов становится больше двух может возникнуть потребность в создании новых SiteLink-ов. Рассмотри жизненную ситуацию. Ваша фирма имеет два офиса, главный находится в Москве, он соединен каналом с Ростовским офисом. Открывается еще один филиалл в г. Сальск и этот филиал имеет медленный, загруженный и нестабильный канал с Ростовским участком. Перед вами стоит задача, обеспечить выполнение двух вышеназванных пунктов и вдобавок гибко настроить репликацию между сайтами. Вы решили, что новые данные из москвы в Ростов-на-Дону должны реплицироваться ежечасно, а вот из Ростова в Сальск репликация должна проходить только в ночное время, дабы не нагружать и без того проблемный канал.
Рис. 13 Схема сайтов и их связей.
Действия администратора в такой ситуации довольно просты, первым делом он создает сами сайты, эта процедура предельно проста и требует ввода только имени сайта и используемой связи. Настоятельно рекомендуется при этом сразу назначить на вновь созданные сайты соответствующие им IP-подсети. Первоначально для связи сайтов можно использовать созданную автоматически при инсталляции службы каталогов связь «DEFAULTIPSITELINK».
После этого администратор создает две «Связи сайтов», одну для стыковки сайтов Москва и Ростов, вторую для Ростов-Сальск. После создания необходимо сконфигурировать расписание открытия окна репликации, доступ к настройкам которого легко получить в свойствах нужной связи.
Получив нужную структуру сайтов, следует задать какие контроллеры в каком сайте должны обсуживать клиентов, сделать это можно обычным перетаскиванием объектов контроллеров домена между папками «Servers» в разных сайтах. Однако более правильным и рекомендуемым компанией Microsoft способом распределения между сайтами считается инсталляция контроллера домена с таким IP-адресом, который попадает в заданную вами подсеть, принадлежащую нужному вам сайту. Внимательные администраторы заметили, что при создании Связей кроме расписания задается их стоимость. Это неспроста, возможны ситуации когда сайты связанны сразу с несколькими другими и возникает ситуация когда у репликационного трафика есть несколько возможных путей. Именно тогда и начинают учитываться стоимости, чем меньше стоимость связи, тем приоритетней путь для репликации.
1. Межсайтовая репликация идет по самому «дешевому» маршруту.
2. Если между двумя сайтами есть несколько маршрутов и они одинаковы по стоимости, то будет выбран тот маршрут, который использует меньше «прыжков» или «SiteLink-ов»
3. Если и стоимость, и количество прыжков одинаково, будут учитываться названия сайтов, где приоритет получат пути через сайты, имена которых начинаются с первых букв алфавита.
Рис. 14 Схема сайтов и их связей со стоимостью.
Зная это можно точно сказать, что при репликации с контроллеров домена Москвы в Сальск информация будет реплицирована используя Связь 3, так как при одинаковой цене (100=50+50) этот вариант предполагает единственный прыжок.
Чтобы убедиться в том, что клиенты начали обращаться к «правильному» контроллеру домена, можно использовать команду 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, то его и нужно добавить на выбранном сервере.
Рис. 15 Ручное указание Bridgehead сервера.
Посмотреть, кто является текущим сервером плацдармом можно через: repadmin /bridgeheads
Важно отметить, что при ручном указании сервера Bridgehead для сайта он будет один выполнять эту функцию. Если же сервер Bridgehead не задан и выбор делает KCC автоматически то для Windows Server 2003 KCC осуществляет балансировку количества линков репликации между несколькими контроллерами в сайте. Кроме того, такую балансировку можно выполнить и в ручном режиме утилитой adlb.exe.
Поговорим о межсайтовых мостах.
Посмотрим на рисунок 16. На нем изображена схема сети, состоящей из 3-х сайтов, каждый из которых находится в своей подсети и своем городе. Связи сайтов настроены так, что Белград имеет SiteLink соединяющий его с Москвой и SiteLink, соединяющий его с Токио. Москва и Токио между собой напрямую не связаны.
Рис. 16. Идеология Site Link Bridge
А теперь давайте попробуем ответить на вопрос: Каким путем будут реплицироваться изменения с контроллера домена А1 на контроллер домена С1, Те, кто внимательно читали статью скажут, что контроллер домена А1 передаст изменения серверу плацдарму в своем сайте. Тот в свою очередь согласно расписанию «Связи» передаст их на сервер плацдарм сайта Белград. И только потом плацдарм Белграда опять же по расписанию передаст их на Токийский плацдарм. И уже с него они будут реплицированы на контроллер С1. Те, кто так скажут, будут правы.
Что же произойдет, если Белградские контроллеры станут недоступны или просто этот сегмент сети окажется отключен? Остановится ли репликация между сайтами Москва и Токио?
По умолчанию Active Directory пытается решить данную проблему. Она (AD DS) видит, что Москва связана с Белградом, Белград с Токио, а сайт Белграда пропал с радаров и репликация остановилась. Видит и допускает, что мы имеем полностью маршрутизируемую сеть. А если сеть полностью маршрутизируемая, то почему не передать напрямую? (с контроллера А1 на С1 сразу)
Такая транзитивность называется «Site Link Bridging». Служба KCC начинает создавать репликационные связи между контроллерами из несвязанных SiteLink-ми сайтов и реплицировать данные напрямую. Естественно, если вы не имеете полностью маршрутизируемой сети, то такая дефолтная логика вас не устроит. Поэтому вам может потребоваться отключить автоматический «Site Link Bridging». Делается это довольно просто и уже после отключения логика репликации будет идти по классической схеме. А при падении канала с центральным сайтом, в моем случае Белград, репликация между сайтами попросту остановится.
Рис. 17 Включение и отключение функции автоматического “Site Link Bridging” (опция Установить мост для всех связей сайтов )
Важно отметить и то, что с появление связи с центральным Белградским сайтом служба KCC заново пересчитает топологию репликации, и все лишние репликационные связи между контроллерами будут удалены.
В сети, где сеть не полностью маршрутизируемая автоматическое создание мостов (Site Link Bridging) следует отключать. Но как быть, если сеть довольно крупная и в ней присутствуют как группы сегментов с полной маршрутизацией, так и с частичной. Отключение Site Link Bridging лишит нас резервного механизма репликации для всех сегментов сети.
Специально для таких целей существует функции создания мостов межу конкретными сайтами, осуществляется она также через оснастку «Active Directory Сайты и Службы»
Рис. 18 Создание моста между сайтами.
Создавай мост, вы можете быть уверены, что контроллеры в сайтах сайт-линки которых соединены мостом в штатном режиме будет реплицировать изменения согласно топологии межсайтовой репликации (используя контроллеры доменов в других сайтах как посредников). И только если передать данные по этой логике не получится (обратите внимание, что для передачи данных через мост необходимо несколько сбойных попыток репликации) будут созданы прямые репликационные связи и начнут передаваться данные.
По-умолчанию при репликации контроллеры домена устанавливают соденение по 135/tcp, 135/udp портам (так называемый RPC endpoint mapper), после чего согласовывают порты, которые будут использоваться при репликации данных. Тут то и появляется проблема, диапазон портов, которые могут быть задействованы очень велик 1024-65535/tcp. Открытие этих портов полностью нивелирует файрвол, превращая его в головку швейцарского сыра.
Поэтому перед администратором может встать задача четкой фиксации портов, используемых при репликации, а делается это через правку реестра на контроллерах домена.
Для жесткой привязки порта репликации Active Directory используется ключ:
Registry value: TCP/IP Port
Value type: REG_DWORD
Еще один очень полезный ключ для фиксации RPC-трафика регистрации пользователей и компьютеров в процессе NetLogon-а и DC Locator-а: (трафика от клиентов к контроллерам домена при установлении SChannel и при поиске «родных» сайтов)
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 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.
• Наличие встроенных средств мониторинга и утилиты для развертывания.
• Технология, требующая минимального контроля и администрирования со стороны системного администратора.
Если вы идете в ногу с прогресом и ваша папка 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.
Рис. 16. Не реплицированное изменение.
Несмотря на предупреждение о том, что данные команды должны использоваться только под присмотром premier support microsoft некоторые из них стоит взять на вооружение.
repadmin /options DC1 +DISABLE_OUTBOUND_REPL +DISABLE_INBOUND_REPL
Эта команда отключает входящую и исходящую репликацию на контроллере DC1, очень удобное средство, в случае если необходимо срочно остановить распространение изменений. Обратно включение производится аналогично только перед параметром необходимо установить минус. (-DISABLE_INBOUND_REPL)
Информация полученная после вдумчивого прочтения двух частей данной статьи должна сформировать понимание у специалиста идеологии репликации и построения многосайтовых систем. Но все же очень много осталось за кадром. А именно: задачи и сценарии SMTP-репликации, объемы трафика репликации для разных типов объектов, влияние на репликацию таких вещей как захоронение и восстановление объектов, ну и конечно USN rollback. И пусть не в каждой организации вам понадобится знание вышеперечисленного, но для реализации крупных решений эти нюансы в голове должны быть проработаны.
Илья Рудь
Константин Леонтьев