Топология репликации Active Directory

В AD реализован весьма эффективный фоновый процесс, известный как проверка согласованности знаний Knowledge Consistency Checker (KCC). Этот процесс обеспечивает потребление информации, предоставляемой администраторами службе AD в форме подсетей, сайтов, связей сайтов, а также мостов связей сайтов с целью определения оптимальной общей топологии соединений между контроллерами доменов. Данные соединения представлены объектами соединений, которые автоматически добавляются и удаляются процессом KCC по мере необходимости. Между сайтами, связями сайтов, а также мостами связей сайтов, с одной стороны, и компонентами сетевой топологии — с другой, обычно устанавливается жесткое соответствие; в результате формируется схема, именуемая топологией сайтов. Образец топологии сайтов представлен на рисунке 1.

Рисунок 1. Пример топологии сайта

Компоненты топологии сайтов

Топология сайтов состоит из сайтов, связей сайтов и мостов связей сайтов.

Сайты. Сайты представляют собой ключевой компонент конфигурации AD, используемый как в процессе репликации, так и клиентами, а также приложениями. Клиенты и приложения используют сведения о сайтах для поиска контроллера домена или иного ресурса, ближе прочих расположенного к ним в логической схеме сети. Чтобы иметь возможность ассоциироваться с нужным сайтом, клиенты должны располагать точной информацией о подсети, полученной по каналам AD. Информация о подсети определяется в терминах, хранимых в каталоге объектов подсетей IP (IPv4 и/или IPv6), которые, в свою очередь, ассоциированы с сайтами.

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

В состав сайта обычно входит группа подсетей, связанных между собой высоконадежными и скоростными каналами передачи данных и содержащих один или несколько контроллеров доменов. Понятие «высоконадежные каналы связи» может толковаться в весьма широких пределах, но я считаю, что за основу можно взять минимальную пропускную способность канала в 10 Мбит/c. Обычно (хотя и не всегда) сайты непосредственно соответствуют физическому расположению внутри сети; физическое расположение включает контроллеры доменов, как показано на рисунке 2. На ум приходит известная «страшилка» про исходный сайт, расположенный в новом лесу AD, а именно про сайт Default-First-Site-Name. Вопреки широко распространенному представлению, администраторы могут без всяких опасений удалять или переименовывать этот объект «сайт» по своему усмотрению. Нет никаких оснований ни сохранять данный объект в виде пустого сайта, если вы им не пользуетесь, ни воздерживаться от его переименования, если вы полагаете, что ему больше подходит другое название.

Рисунок 2. Пример топологии сайта с активированной функцией «автоматическое обслуживание сайта»

На рисунке 1 представлена некая компания с офисами в Сент-Луисе и в Детройте, но контроллеры доменов ее сети размещаются в Чикаго. Единственный сайт создан для Чикаго, однако подсети, функционирующие в Сент-Луисе и в Детройте, ассоциированы с сайтом в Чикаго (в дополнение к подсети для Чикаго).

Как правило, сайты создаются только на тех рабочих площадках, где имеется контроллер домена, однако надо иметь в виду, что информацию о сайтах используют некоторые приложения — такие как распределенная файловая система DFS и диспетчер конфигураций Microsoft System Center Configuration Manager (SCCM). К примеру, если в том или ином офисе вашей компании, не располагающем контроллером домена, установлен сервер SCCM, вам, вероятно, нужно будет создать в этом офисе сайт. Если же тот или иной сайт не содержит контроллера домена, служба AD с помощью процесса «автоматическое обслуживание сайта» (automatic site coverage) определяет, к каким контроллерам домена следует обращаться клиентам данного сайта.

На рисунке 2 представлена организация с офисами в Сиэтле, Лос-Анджелесе и в Сан-Диего. Контроллеры домена размещаются в Сиэтле, однако сервер SCCM имеется также и в Сан-Диего. Чтобы гарантировать обращение клиентов из Сан-Диего к своему локальному серверу SCCM, администраторы создают сайт для Сан-Диего и ассоциируют с этим сайтом подсеть для Сан-Диего. Далее создается второй сайт для Сиэтла; он содержит контроллеры домена Сиэтла, а также подсети для Сиэтла и Лос-Анджелеса.

Связи сайтов. Мы рассмотрели тему сайтов и объектов «подсеть», которые определяют, какие клиенты должны ассоциироваться с данным сайтом; но мы не коснулись вопроса о том, каким образом сайты соединяются в системе AD. AD объединяет сайты с помощью связей сайтов. Связи сайтов часто соответствуют топологии распределенной сети. Эти связи соединяют два или большее число сайтов. Они задают маршруты, по которым может осуществляться репликация, а также влияют на выбор клиентами самых близких контроллеров доменов или других серверов. Вы можете создавать связи, объединяющие более двух сайтов, но надо иметь в виду, что связями сайтов обычно проще управлять, если имеешь дело с двухточечными связями (то есть со связями сайтов, соединяющими между собой только два сайта).

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

В системе AD фактор стоимости принимается в расчет только в тех случаях, когда любые два сайта связаны несколькими маршрутами. Если маршрут только один, стоимость не имеет значения, ибо вам так или иначе придется использовать эту связь сайтов. Стоимость не имеет особого значения и в том случае, если использование предпочтительного маршрута связано с меньшими издержками, чем использование других маршрутов. Но если вам все-таки необходимо сопоставить стоимости, связанные с применением связи сайтов, помните, что существует несколько стратегических подходов к решению этой задачи. Первый подход предполагает использование значений, пропорциональных быстродействию канала связи распределенной сети. Если вы пойдете по этому пути, воспользуйтесь таблицей, размещенной по адресу briandesmond.com/blog/active-directory-site-links-naming-costing; она послужит хорошим подспорьем. Другой часто применяемый подход — задействовать статические значения для различных типов соединений. Так, стоимость на соединения между центрами обработки данных составляет 100 единиц, между центрами обработки данных и отдельными сайтами — 200 единиц, а на соединения между отдельными сайтами — 300 единиц.

На рисунке 3 представлен пример, в котором стоимость на связь сайтов не имеет значения. В этом примере задано три сайта AD: в Нью-Йорке, в Бостоне и в Атланте. Каналы распределенной сети существуют между Нью-Йорком и Бостоном, а также между Нью-Йорком и Атлантой. На базе этих сведений были созданы связи сайтов, повторяющие топологию распределенной сети. Поскольку к каждому сайту имеется лишь один путь, стоимость связи сайтов не имеет значения.

Рисунок 3. Стоимость на связи сайтов не учитывается

На рисунке 4 показан пример, в котором стоимость связи сайтов имеет значение. В данном случае все три сайта объединены по каналам распределенной сети. На базе этих данных были созданы связи сайтов, объединяющие все три сайта в топологии «каждый к каждому». Издержки были установлены таким образом, чтобы связи Хьюстон — Даллас и Хьюстон — Остин были более предпочтительными, чем связь Даллас — Остин.

Рисунок 4. Связи сайтов со сведениями по затратам

Наряду со свойством «стоимость» связи сайтов обладают свойствами «частота» и «график». Значение свойства «частота» не требует пространных пояснений. Оно определяет, как часто AD инициирует нормальную репликацию через данную связь сайтов. Указанное значение может быть установлено в широком диапазоне от минимального (15 минут) до максимального (1 неделя). Если же вам нужно, чтобы репликации выполнялись чаще, чем раз в 15 минут, можете активировать для данной связи сайтов функцию «извещение об обновлении» (change notification), выполнив следующие действия.

1. Откройте оснастку ADSIEdit (выберите Start, Run, ADSIEdit.msc).
2. Перейдите к разделу \Configura­tion\Sites\Inter-Site Transports\IP.
3. Правой кнопкой мыши щелкните на связи сайтов, которую намереваетесь редактировать, и выберите пункт Properties.
4. Дважды щелкните на атрибуте Options.
5. К отображенному значению добавьте единицу. Если задано значение null, установите его равным 1.

В результате будет запущена функция change notification, которая даст службе AD команду выполнить внутрисайтовую репликацию через данную связь сайтов; после этого синхронизация будет выполняться практически в реальном времени. Как правило, это изменение вносится для связей сайтов, соединяющих центры обработки данных.

Наконец, свойство «график» определяет, когда (то есть в течение какого времени) может начаться репликация Windows. По умолчанию график дает возможность начинать репликацию в любое время; но может возникнуть ситуация, когда использование каналов распределенной сети в некоторые периоды времени будет считаться нежелательным — скажем, вследствие их загруженности или по другим причинам. Главное значение данных в графике репликации состоит в том, что график определяет, когда именно может начаться репликация. И если репликация началась в запланированном «окне», ее нельзя будет остановить до самого завершения.

Итак, мы рассмотрели ряд примеров, а напоследок я предложу вам две рекомендации по использованию связей сайтов. Речь пойдет об именовании связей сайтов, а также о том, какую связь применять по умолчанию. Обратите внимание на следующий удобный способ именования связи с использованием двух объединяемых ею сайтов (скажем, Нью-Йорк — Бостон). Теперь поменяем сайты местами (получится Бостон — Нью-Йорк) и введем это имя в поле Description. В результате в оснастке Active Directory Sites and Services консоли Microsoft Management Console (MMC) мы можем осуществлять сортировку по любому из двух столбцов в зависимости от того, каким образом нам нужно представить данные. При создании нового леса AD формируется первоначальная связь сайтов с именем DEFAULTIPSITELINK. Вы можете переименовать или удалить эту связь сайтов, если такое действие будет иметь смысл, то есть поступить так же, как в случае с первоначальным сайтом, создаваемым по умолчанию.

Мосты связей сайтов. Без сомнения, последний компонент топологии сайтов AD используется реже, чем прочие. Этот компонент известен как мост связей сайтов. Мосты связей сайтов применяются в сетях, не являющихся полностью маршрутизируемыми. Если сеть полностью маршрутизируемая, клиент (или сервер), расположенный в любой части сети, может подключиться к клиенту (или серверу) в любой другой части этой же сети (за исключением тех случаев, когда такая операция блокируется брандмауэрами). Типичная ситуация с не полностью маршрутизируемой сетью возникает, когда в компании имеется несколько региональных офисов и из одного такого офиса нет возможности через сеть связаться с другим. Или такая ситуация: сайты из одного региона не могут связаться с сайтами из другого региона.

По умолчанию в AD установлена настройка Bridge All Site Links (BASL). В этом случае контроллер домена на сайте Бостона (см. рисунок 3) может напрямую осуществлять репликацию с контроллером домена сайта в Атланте, минуя все контроллеры домена в Нью-Йорке, даже если связи, соединяющей сайты Бостона и Атланты, не существует. Если описанная выше прямая репликация в вашей сети невозможна, вам придется отключить настройку BASL. После этого вы сможете определять наборы полностью маршрутизируемых связей сайтов с помощью мостов связей сайтов.

В соответствии со схемой, отображенной на рисунке 5, единственный возможный путь, соединяющий сеть в Северной Америке с Европой, пролегает от серверов в Денвере к серверам в Лондоне. Внутри каждого региона существует возможность связи с использованием каналов распределенной сети по принципу «каждый с каждым». Чтобы представить такую схему в AD, необходимо создать два моста связей сайтов — один для Северной Америки и один для Европы. Североамериканский мост включает связи сайтов Денвер — Феникс и Денвер — Майами, тогда как европейский мост охватывает связи сайтов Лондон — Париж и Лондон — Мюнхен.

Рисунок 5. Мосты связей сайтов

Формирование соединений для репликации

После того как вы определите топологию связей в службе AD, этой службе нужно будет проделать определенную работу, чтобы определить, какие именно контроллеры домена будут принимать участие в процессе взаимной репликации. Эти расчеты осуществляет в фоновом режиме процесс KCC. Рассчитываются две различные топологии, которые затем объединяются во всеобъемлющую топологию репликации. Первая топология предназначена для внутрисайтовой репликации. Внутрисайтовая репликация — это репликация между контроллерами домена, расположенными внутри одного и того же сайта AD. В случае внутрисайтовой репликации процессу KCC нет нужды беспокоиться о таких обстоятельствах, как связи сайтов и мосты связей сайтов; ведь предполагается, что все контроллеры домена объединены надежными и высокопроизводительными каналами связи. Исходя из этих соображений процесс KCC рассчитывает топологию, главное требование к которой состоит в следующем: ни один контроллер домена на данном сайте не должен располагаться на расстоянии более чем трех переходов от любого другого контроллера домена на этом же сайте. Таким образом обеспечивается выполнение условия, в соответствии с которым контроллеры домена могут сходиться и их содержимое — синхронизироваться в течение приблизительно одной минуты (в лесах Windows 2000 этот показатель составлял некогда порядка 15 минут).

Топологии межсайтовой репликации рассчитываются с учетом информации о топологии сайта, включенной в AD. Расчет топологий межсайтовой репликации выполняется с помощью генератора межсайтовой топологии Inter-Site Topology Generator (ISTG). ISTG — компонент процесса KCC, выполняемый на одном контроллере домена каждого сайта AD; на этот компонент возложена задача по созданию объектов «соединение» для репликации по связям сайтов.

Эффективные топологии

Служба AD прекрасно справляется с задачей расчета топологий репликации внутри сайта AD; но, чтобы организовать репликацию, выходящую за границы одного сайта, администраторы должны вводить в систему дополнительную информацию, чтобы эта служба могла указать наилучший маршрут. Указанная информация предоставляется в форме сайтов, связей сайтов, а также мостов связей сайтов, которые в общем случае точно отражают топологию РВС данной организации. Располагая означенными данными, процесс KCC и генератор ISTG могут создавать для соответствующего леса эффективные топологии репликации.

Брайан Десмонд (brian@briandesmond.com) — старший консультант компании Moran Technology Consulting (Чикаго). Имеет сертификат Directory Services MVP. Автор книги «Active Directory», ведет блог www.briandesmond.com