Генерация топологии репликации

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

Проверка целостности сведений (Knowledge Consistency Checker)

КСС (Knowledge Consistency Checker) — это процесс, который выполняется на каждом контроллере домена. Он ответствен за создание топологии репликации в пределах сайта и между сайтами. Как только к лесу Active Directory добавляется второй контроллер домена, служба КСС начинает создавать топологию репликации, которая является и эффективной, и терпимой к ошибкам. По мере добавления к сайту других контроллеров домена или новых сайтов КСС использует информацию о серверах, сайтах, связях сайта и расписаниях для создания оптимальной топологии репликации. Служба КСС динамически анализирует изменения или отказы, возникающие в пределах топологии репликации. Если один из контроллеров домена временно находится в автономном режиме, то КСС пересматривает топологию репликации, чтобы обойти неработающий контроллер домена. По умолчанию КСС каждого контроллера домена повторно вычисляет топологию репликации каждые 15 минут. Имеется возможность в любое время повторно вычислить топологию репликации с помощью инструмента администрирования Active Directory Sites And Services (Сайты и службы Active Directory). Найдя сервер, на котором вы хотите проверить топологию репликации, и щелкнув правой кнопкой мыши на NTDS Settings (Параметры настройки NTDS) в контейнере сервера, выберите опцию All Tasks (Все задачи), затем выберите Check Replication Topology (Проверить топологию репликации).

Объекты связи

При создании топологии репликации служба КСС создает ряд объектов связи (connection object), которые хранятся в разделе конфигурации каталога Active Directory. Объекты связи являются прямыми логическими соединениями между контроллерами домена, которые используются для репликации информации каталога. Как уже говорилось, КСС создает топологию репликации, которая является эффективной и терпимой к ошибкам. КСС строит столько объектов связи, сколько для этого требуется.

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

Примечание. С помощью инструмента Replication Monitor (Монитор репликации) вы можете создать push («толкающую») репликацию для раздела каталога. Нормальный процесс репликации всегда является pull-операцией. (Смотрите детали, касающиеся установки и использования монитора репликации в разделе «Мониторинг и поиск неисправностей при репликации» далее в этой главе.)

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

Вы можете изменить заданные по умолчанию объекты связи двумя способами: изменяя некоторые параметры настройки на объектах связи, созданных КСС, и добавляя новые объекты связи.

Изменение объекта связи, созданного КСС

Вы можете изменять график и контроллер-отправитель для объекта связи в пределах сайта, а также транспортный протокол для межсайтовых объектов связи. По умолчанию контроллеры домена в пределах сайта каждый час проверяют всех своих партнеров по репликации, чтобы удостовериться, что обновления не были пропущены. Этот график можно изменить так, чтобы никогда не делать проверку, проверять каждые полчаса или каждые 15 минут. (Интерфейс связи показан на рисунке 4-1.)

Когда вы производите изменения объекта связи, его имя <automatically generated> (автоматически сгенерированный) заменяется на глобальный уникальный идентификатор объекта (GUID). После изменения объекта вы можете его переименовать.

Рис. 4-1. Конфигурирование существующего объекта связи

Создание нового объекта связи

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

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

Топология репликации внутри сайта

Существует два варианта конфигурирования репликации между контроллерами домена в Active Directory. В первом варианте используется модель остовного дерева (spanning tree), когда создается топология репликации только с одним направлением репликации между контроллерами домена. Каждый контроллер домена, на котором размещается раздел каталога, будет иметь только одного партнера по репликации, передающего данные для этого раздела. Это гарантия того, что никогда не возникнут связи, по которым информация будет пересылаться на определенный контроллер домена более чем одним путем. Контроллеры домена никогда не получат одно и то же обновление дважды, потому что оно прибывает только из одного источника. Основной недостаток использования алгоритма spanning tree состоит в отсутствии избыточности. Если на одном из контроллеров домена произойдет сбой, то может потребоваться некоторое время на повторное вычисление пути репликации в обход неисправного контроллера.

Второй вариант создания топологии репликации должен включать избыточные связи. Основными целями разработки топологии репликации Active Directory являются работоспособность и устойчивость к отказам. Если отдельный контроллер домена недоступен для репликации, репликации Active Directory не должна оканчиваться неудачей. Недостаток использования избыточных связей состоит в том, что контроллер домена может получать одно и то же обновление несколько раз, потому что каждый контроллер домена имеет несколько партнеров по репликации. Чтобы избежать многократных модификаций одной и той же информации, при репликации Active Directory используется демпфирование распространения.

Как только к организации добавляются контроллеры домена с репликами определенного раздела Active Directory, KCC автоматически начинает создавать топологию репликации. Эта топология образует кольцо репликации. На рисунке 4-2 показан пример простой сетевой структуры с тремя контроллерами в одном домене и единственном сайте.

Рис. 4-2. Простое кольцо репликации

КСС создает кольцо репликации (см. рис. 4-2), в котором каждый контроллер домена сконфигурирован с двумя входящими связями репликации. Если одна из связей недоступна, то обновление может передаваться по другой связи. Кроме того, каждый контроллер домена сконфигурирован как контроллер-источник для двух других контроллеров домена. Это создает избыточное кольцо для каждого контроллера домена.

По мере увеличения количества контроллеров домена с репликой определенного раздела становится важным второй принцип создания связей. Служба КСС всегда создает топологию репликации, в которой каждый контроллер домена в сайте удален от любого другого контроллера домена не более чем на три ретрансляции (hop). Когда количество контроллеров домена в сайте становится больше семи, создаются дополнительные объекты связи для уменьшения потенциального числа ретрансляций до трех или меньшего количества. Например, сайт на рисунке 4-3 имеет девять контроллеров домена. Он будет иметь топологию репликации, включающую, по крайней мере, одну дополнительную связь.

Рис. 4-3. Кольцо репликации, включающее более семи контроллеров домена

Кольца репликации основываются на разделах каталога. Это означает, что КСС вычисляет кольцо репликации для каждого раздела каталога. Например, организация имеет несколько доменов в единственном сайте и раздел приложений каталога, который копируется на несколько контроллеров домена в сайте. В этом случае конфигурация могла быть задана так, как показано на рисунке 4-4. В предложенном сценарии (см. рис. 4-4) возможно создание колец репликации, представленных в табл. 4-1.

Табл. 4-1. Кольца репликации в сложном сайте

Дополнительную информацию смотрите в примечании ниже.

Рис. 4-4. Кольца репликации, созданные для каждого раздела каталога

Примечание.Разделы приложений каталога DNS (ForestDnsZones и DomainDnsZones) также включены в топологию репликации. Чтобы не усложнять сценарий, эти разделы на рисунке 4-4 не обозначены и не приводятся в связанной с ним таблице. В главе 3 говорилось о том, что эти разделы обрабатываются так же, как другие доменные разделы каталога. По этой же причине на рисунке 4-4 не показана топология репликации глобального каталога GC. Процесс создания кольца репликации GC немного отличается от репликации других разделов и будет описан далее.

Разделы репликации и топологию можно просмотреть с помощью инструмента Replication Monitor (Монитор репликации). Монитор репликации — это одно из инструментальных средств поддержки, которые помещены на компакт-диск Windows Server 2003. Чтобы установить инструментальные средства поддержки, запустите файл Suptools.msi из каталога Support\Tools компакт-диска Windows Server 2003. Чтобы запустить монитор репликации, в окне Run (Выполнить) напечатайте replmon. На рисунке 4-5 показана конфигурация четырех серверов в лесу, отображаемая с помощью монитора репликации.

Рис. 4-5. Использование монитора репликации для просмотра раздела репликации

Кольцо репликации - это логическая концепция, фактическая топология репликации, реализованная с помощью объектов связи. В то время как для каждого раздела каталога создается отдельное кольцо репликации, КСС не создает дополнительные объекты связи для каждого кольца репликации. Вместо этого КСС, насколько возможно, повторно использует одни и те же объекты связи для многих колец репликации. В примере на рисунке 4-5 DC1.Contoso.com имеет объект связи с DC4.Fabrikam.com.

Один из способов просмотра свойства объекта связи состоит в использовании монитора репликации. Чтобы рассмотреть свойства входящих связей сервера, добавьте сервер к контролируемому списку серверов. Затем щелкните правой кнопкой мыши на имени сервера и выберите Show Replication Topologies (Показать топологию репликации). Щелкните на View (Вид), далее — на Connection Objects Only (Только объекты связи), а затем щелкните правой кнопкой мыши на сервере и выберите Properties (Свойства). Вкладка Inbound Replication Connections (Входящие связи репликации) показывает все входящие связи для контроллера домена, а также разделы, реплицируемые через каждую связь. Как показано на рисунке 4-6, этот объект связи используется для реплицирования глобального каталога (показан как раздел Fabrikam.com), раздела схемы каталога и раздела конфигурации каталога. Всякий раз, когда это возможно, КСС создает объект связи, пригодный для реплицирования нескольких разделов каталога.

Рис. 4-6. Отдельный объект связи, использующийся для репликации нескольких разделов каталога

Репликация глобального каталога

Глобальный каталог отличается от других разделов тем, что он составлен из баз данных доменов целого леса. Каталог GC всех контроллеров домена предназначен только для чтения. Это означает, что информация в GC не может быть изменена администратором напрямую. Глобальный каталог GC представляет собой список всех атрибутов, переданных в него, атрибут isMemberOfPartialAttributesSetкоторых установлен на true (истину).

Тот факт, что GC создан из баз данных доменов, затрагивает также кольцо репликации для GC. Каждый GC-сервер должен получить GC-информацию от контроллеров домена всех доменов. На рисунке 4-7 приведен пример компании, имеющей два домена с одним контроллером домена в каждом; оба домена расположены в одном и том же сайте. Домен DC1.Contoso.com сконфигурирован как сервер глобального каталога. GC-сервер является также единственным контроллером домена для домена Contoso.com, поэтому он извлекает GC-информацию для Contoso.com из своей собственной базы данных домена. Контроллер домена в домене Fabrikam.com имеет единственную копию раздела каталога этого домена, поэтому DC1.Contoso.com собирает GC-информацию для домена Fabrikam.com из DC2.Fabrikam.com. Для извлечения информации из домена Fabrikam.com создан объект связи, направленный от DC2.Fabrikam.com к DC1.Contoso.com. В дальнейшем эта связь может использоваться для репликации GC-информации в DC1.Contoso.com.

Рис. 4-7. Пример простой репликации глобального каталога

На рисунке 4-8 показан более сложный пример создания GC и его репликации. В этом случае сконфигурирован объект связи, направленный от контроллера домена каждого домена на каждый GC-сервер. DC1.Contoso.com имеет входящий объект связи от контроллеров DC2.Contoso.com, DC4.Fabrikam.com и DC6.NWTraders.com. Этот объект связи используется для создания глобального каталога на DC1.Contoso.com. Все другие GC-серверы имеют подобный набор объектов связи. Кроме того, создано также отдельное кольцо для репликации раздела GC между всеми GC серверами.

Топология межсайтовой репликации

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

Рис. 4-8. Пример сложной GC-репликации

Подобный подход используется также при определении топологии репликации между сайтами, за исключением того, что один контроллер домена в каждом сайте ответственен за разработку топологии между сайтами. КСС одного из контроллеров домена в сайте обозначается как генератор межсайтовой топологии (ISTG - Inter-Site Topology Generator) для сайта. Имеется только один ISTG-контроллер на сайте, независимо от того, сколько доменов или других разделов каталога находится в сайте. Контроллер ISTG ответственен за вычисление идеальной топологии репликации для всего сайта. Этот процесс состоит из двух частей.

• Идентификация серверов-плацдармов (bridgehead server) для каждого раздела каталога, имеющегося в сайте. При репликации между сайтами информация всегда посылается с сервера-плацдарма одного сайта на сервер-плацдарм другого. Это означает, что по сетевой связи между сайтами информация реплицируется только однажды.
• Создание объектов связи между серверами-плацдармами для гарантии репликации между сайтами. Поскольку репликация конфигурируется между серверами-плацдармами, то в пределах сайта отсутствуют избыточные объекты связи.

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

На рисунке 4-9 показан пример топологии репликации, созданной между сайтами. В этом примере лес содержит два сайта и два домена с несколькими контроллерами домена в каждом сайте. Имеется также, по крайней мере, один GC-сервер в каждом сайте. Это означает, что каждый сайт содержит раздел каталога для каждого из доменов, раздел GC, а также разделы схемы каталога и конфигурации каталога. В каждом сайте требуется назначить по два сервера-плацдарма, потому что каждый из этих разделов должен копироваться между сайтами. Один из серверов-плацдармов в обоих сайтах должен быть контроллером домена в домене Contoso.com. Другой сервер-плацдарм обоих сайтов должен быть контроллером домена в домене Fabrikam.com. В примере, показанном на рисунке 4-9, контроллеры DC1.Contoso.com и DC6.Fabrikam.com являются также GC-серверами. Это означает, что они станут серверами-плацдармами при репликации GC-информации между сайтами. Поскольку раздел схемы и раздел конфигурации каталога являются общими для всех контроллеров домена, то для репликации этих разделов может использоваться один из существующих объектов связи.

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

Рис. 4-9. Межсайтовые объекты связи