количество просмотров: 18229

дата публикации: 15:04:2007

Глава 4. Репликация Active Directory и сайты
Каждая компания, реализующая службу каталога Active Directory Microsoft Windows Server 2003, развертывает несколько контроллеров домена. Они могут располагаться в одном центре обработки данных в главном офисе компании и связываться высокоскоростными сетевыми соединениями. Они могут быть распределены по всему миру и использовать для связи глобальные сети (WAN). Некоторые компании имеют единственный домен в лесу, другие компании - много доменов в нескольких доменных деревьях в общем лесу.
Независимо от того, сколько контроллеров домена имеет компания и где они расположены, контроллеры домена должны реплицировать информацию друг у друга. Если они не будут делать этого, каталоги на контроллерах станут противоречивыми. Например, если на одном контроллере домена будет создан пользователь и эта информация не скопируется на все другие контроллеры домена, то этот пользователь сможет входить только на один контроллер домена.
Служба Active Directory использует модель репликации с несколькими хозяевами, в которой изменения в каталоге могут быть сделаны на любом контроллере домена и скопированы на другие контроллеры. В данной главе описывается процесс репликации в Active Directory. Глава рассказывает о том, как работает репликация, как создается топология репликации, и как контроллеры домена копируют информацию друг у друга.
Модель репликации Active Directory
В главе 2 говорилось о том, что Active Directory состоит из нескольких логических разделов. Репликация информации между контроллерами домена с репликами всех разделов осуществляется одинаково для всех разделов. Когда изменяется атрибут в разделе конфигурации каталога, он реплицируется так же, как и в случае изменения атрибута любого другого раздела. Единственное отличие состоит в списке контроллеров домена, которые получат копию реплицируемого изменения. Репликация между контроллерами домена в одном и том же сайте обрабатывается иначе, чем между контроллерами домена различных сайтов, но основная модель не изменяется. В этом разделе описывается модель репликации, которая используется в Active Directory.
В отличие от модели репликации с единственным хозяином, которая используется в системе Microsoft Windows NT, Active Directory использует модель репликации с несколькими хозяевами. В Windows NT основной контроллер домена (PDC — Primary Domain Controller) является единственным контроллером домена, который может принимать изменения информации домена. После того как изменение сделано, оно реплицируется на все резервные контроллеры домена (BDC — Backup Domain Controllers). Недостатком модели репликации с единственным хозяином является то, что она не масштабируется для большой распределенной среды. Поскольку изменения (например, пароля пользователя) могут выполняться только на контроллере PDC, это может стать узким местом, если делаются сразу тысячи изменений. Контроллер PDC находится только в одном месте компании, и любые изменения информации домена, расположенного в удаленном месте, должны быть сделаны на этом контроллере PDC. Другая проблема заключается в том, что контроллер PDC является единственной точкой отказа. Если он недоступен, никаких изменений информации каталога сделать нельзя до тех пор, пока он не вернется в интерактивный режим или пока другой BDC-контроллер не будет назначен на роль контроллера PDC.
В Active Directory изменения информации домена могут быть сделаны на любом контроллере домена, т.е. каждый контроллер домена имеет перезаписываемую копию каталога, а контроллера PDC не существует. Как только изменение было сделано, оно копируется на все другие контроллеры домена. Такая модель репликации с несколькими хозяевами направлена на повышение надежности и масштабируемости, ведь изменения в каталоге можно делать на любом контроллере домена независимо от того, где он расположен. Поскольку все контроллеры домена обеспечивают одни и те же службы, отказ одного их них не является критичным для всей системы.
Примечание. В главе 2 говорилось о том, что в Active Directory имеются определенные роли хозяев операций, которые могут выполняться только одним контроллером домена. Эти роли представляют собой критическую точку отказа системы, но их можно легко передавать на другой контроллер домена.
Модель репликации, используемая в Active Directory, представляет модель с нежестким согласованием, обладающую сходимостью. Репликация не является жестко согласованной, так как контроллеры домена, содержащие реплику раздела, не всегда имеют идентичную информацию. Например, если новый пользователь создан на одном из контроллеров домена, другие контроллеры домена не получат эту информацию до следующего цикла репликации. Процесс репликации всегда сходится, т.е. если система поддерживается в стационарном состоянии, без внесения новых изменений к каталогу в течение некоторого времени, то все
контроллеры домена достигнут единообразного состояния и будут иметь идентичную информацию.
При репликации используется также процесс хранения и ретрансляции (store and forward). Это означает, что контроллер домена может получать изменение к каталогу, а затем отправлять его на другие контроллеры домена. Это выгодно в тех случаях, когда несколько контроллеров домена, находящихся в разных офисах компании, соединены медленными WAN-соединениями. Изменение к каталогу может реплицироваться с контроллера домена одного из сайтов на единственный контроллер домена второго сайта. Контроллер домена, который получает обновление, может затем переправить изменения на другие контроллеры домена во втором сайте. Контроллер домена, на котором были сделаны изменения каталога, не должен копировать изменения непосредственно на все контроллеры домена, как это имеет место в модели репликации с единственным хозяином.
Улучшение репликации Active Directory Windows Server 2003
Модель репликации Active Directory Windows Server 2003, по существу, совпадает с той, которая используется в системе Microsoft Windows 2000, но имеет ряд существенных улучшений.

• Частичная репликация атрибутов, имеющих несколько значений. В системе Windows 2000 атрибут являлся самой маленькой единицей репликации. В некоторых случаях изменение одного из нескольких значений в атрибуте может создавать существенный трафик репликации. Типичный пример такой ситуации связан с универсальным членством группы. Поскольку полный список членства для универсальной группы является одним атрибутом, то добавление одного пользователя к универсальной группе приводит к значительной репликации, особенно когда группа уже содержит несколько тысяч членов. В Active Directory Windows Server 2003 атрибуты, имеющие несколько значений, подобные членству группы, могут быть обновлены путем репликации только модифицированного значения атрибута.
• Поддержка групп, содержащих более 5000 членов. В системе Windows 2000 группы не могут содержать более 5000 членов из-за того, что репликации модификаций выполняется на уровне атрибутов. Практический предел передачи изменений в базу данных каталога в одной транзакции составляет 5000 значений. Этот предел определяет максимальное количество обновлений, которые могут реплицироваться в процессе одной репликации. В Active Directory Windows Server 2003 поддержка модификаций только одного значения для объектов, имеющих несколько значений, снимает эти ограничения.

Примечание. Описанные выше преимущества доступны только в том случае, если домен работает на функциональном или на временном (interim) функциональном уровне Windows Server 2003. Функциональный уровень Windows Server 2003 доступен только тогда, когда на всех контроллерах домена в лесу выполняется Windows Server 2003. Временный функциональный уровень Windows Server 2003 доступен в том случае, когда лес содержит контроллеры домена, на которых выполняются Windows Server 2003 и Windows NT. Для получения дополнительной информации о функциональных уровнях см. гл. 7.

• Возможность отключать сжатие при репликации между сайтами. По умолчанию весь трафик репликации между сайтами сжимается как для Active Directory Windows 2000, так и для Active Directory Windows Server 2003. Это дает дополнительную нагрузку на процессор контроллера домена. Однако при наличии достаточной пропускной способности между сайтами сжатие в Active Directory Windows Server 2003 можно отключать.
• Возможность уведомлений для репликации между сайтами. По умолчанию репликация между сайтами производится по графику с заданной частотой, сконфигурированной на связях сайта. В Active Directory Windows Server 2003 имеется опция, позволяющая включать уведомления для репликации между сайтами. Если уведомления включены, то сервер-плацдарм (bridgehead server) того сайта, где произошло изменение, уведомляет об этом сервер-плацдарм сайта адресата, и изменения передаются по связям сайта. Нотификация может значительно уменьшать время ожидания репликаций между сайтами, но при этом значительно увеличивается сетевой трафик.

Примечание. Чтобы отключить сжатие или включить процедуру уведомлений для репликации между сайтами, используется инструмент ADSI Edit для модификации атрибута Options (Опции) объекта-соединения сайта (site link object) или объекта-связи (connection object). Чтобы выключить сжатие, установите значение атрибута Options (Опции) равным четырем; чтобы включить уведомления, установите это значение равным единице.

• Улучшенная генерация топологии между сайтами. В системе Windows 2000 размер организации имел ограничение в 100 сайтов в лесу. Это ограничение связано со временем, которое требуется службе КСС (Knowledge Consistency Checker — модуль проверки целостности сведений), для того чтобы вычислить топологию маршрутизации для такого количества сайтов. Это ограничение в Active Directory Windows Server 2003 снято.

Внутренняя и внешняя репликация между сайтами
Одна из главных причин создания дополнительных сайтов в Active Directory состоит в том, чтобы иметь возможность управления трафиком репликации. Поскольку предполагается, что все контроллеры домена в пределах сайта связаны высокоскоростными соединениями, то репликация между ними оптимизируется для получения максимальной скорости и уменьшения времени ожидания. Однако если трафик репликации пересекает низкоскоростное соединение, то сохранение пропускной способности сети становится серьезной проблемой. Создание нескольких сайтов позволяет сохранять пропускную способность сети.
Совет. Если вы работали с Microsoft Exchange Server 5.5 или более ранней версией, различия процессов репликации внутри и между сайтами вам знакомы. Служба Active Directory использует многие принципы управления репликацией в Exchange Server 5.5.
Репликация внутри сайта
Основная цель репликации внутри сайта состоит в уменьшении времени ожидания репликации, т.е. все контроллеры домена сайта должны обновляться настолько быстро, насколько это возможно. Трафик внутренней репликации характеризуется следующим.

• Репликация происходит сразу после того, как произошло изменение информации Active Directory. По умолчанию контроллер домена ожидает 15 с после того, как изменение было сделано, а затем начинает копировать это изменение на другие контроллеры домена в сайте. После завершения репликации с одним партнером контроллер домена ожидает 3 с, а затем начинает репликацию с другим партнером. Ожидание в 15 с необходимо для увеличения эффективности репликации в случае, если к информации раздела будут сделаны дополнительные изменения. Продолжительность периода ожидания может быть изменена через системный реестр Windows 2000 или Windows Server 2003 (обратитесь к соответствующим разделам в комплекте ресурсов Resource Kits за подробностями). На функциональном уровне Windows Server 2003 это значение можно изменить для каждого раздела каталога, используя инструмент ADSI Edit.
• Трафик репликации не сжат. Поскольку все компьютеры в пределах сайта связаны высокоскоростными соединениями, данные посылаются без сжатия. Сжатие данных репликации добавляет дополнительную нагрузку на сервер контроллера домена. При отсутствии трафика репликации производительность сервера сохраняется за счет использования сети.
• Процесс репликации инициируется в соответствии с уведомлением, пришедшим от контроллера-отправителя. После изменения в базе данных компьютер-отправитель обновлений уведомляет контроллер домена адресата о том, что произошло обновление. Контроллер домена адресата забирает изменения с помощью процедуры удаленного вызова (RPC). После окончания репликации контроллер-отправитель уведомляет другой контроллер домена адресата, который также забирает изменения. Этот процесс продолжается до тех пор, пока все партнеры по репликации не будут обновлены.
• Трафик репликации посылается нескольким партнерам в течение каждого цикла репликации. После любого изменения каталога контроллер домена будет копировать информацию всем прямым партнерам по репликации; это могут быть все контроллеры домена в сайте или только некоторые из них.
• Изменить трафик репликации в пределах сайта нетрудно. Можно сконфигурировать объекты-связи вручную через инструмент администрирования Active Directory Sites And Services (Сайты и службы Active Directory), изменить некоторые значения (например, начальное уведомление партнера по репликации) через системный реестр (обратитесь к соответствующим разделам документа Resource Kits за подробностями) или через объект Partition(Раздел), если ваш лес работает на функциональном уровне Windows Server 2003. Но в большинстве случаев этого делать не придется.

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

• Репликация инициируется согласно графику, а не тогда, когда сделаны изменения. Чтобы управлять репликацией между сайтами, нужно сконфигурировать канал связи, соединяющий эти сайты. Одной из опций является время, когда будут происходить репликации. Другая опция устанавливает интервал, показывающий то, как часто будут происходить репликации в течение намеченного времени. Если пропускная способность сети, соединяющей офисы компании, ограничена, репликации может быть намечена на нерабочие часы.
• Трафик репликации сжимается приблизительно на 10 - 15 процентов от первоначального размера, если он составляет свыше 32 Кб. Чтобы сохранить пропускную способность сети, серверы-плацдармы каждого сайта сжимают трафик за счет дополнительного использования процессора.
• Для предупреждения контроллеров домена другого сайта об изменениях каталога уведомления не используются. Вместо этого время репликации определяется по расписанию.
• Подключения, которые выполняют репликацию между сайтами, могут использовать протокол интернета (IP) или протокол электронной почты (SMTP). Протокол, который используется при подключении, определяется пропускной способностью и надежностью сети, которая связывает разные офисы компании.
• Трафик репликации посылается не партнерам по репликации, а через серверы-плацдармы. Изменения каталога сайта реплицируются на единственный сервер-плацдарм (один на каждый раздел каталога) этого сайта, а затем — на сервер-плацдарм другого сайта. Далее изменения реплицируются с сервера-плацдарма второго сайта на все контроллеры домена этого сайта.
• Вы можете легко изменять поток репликации между сайтами, изменяя практически каждый компонент репликации.

Планирование. Ключевым моментом в проектировании Active Directory является планирование количества сайтов и их месторасположения, конфигурирование подключений между сайтами, которые должны оптимизировать пропускную способность сети при уменьшении времени ожидания репликации. Опции конфигурирования подключений между сайтами обсуждаются далее в этой главе, а проблемы, связанные с проектированием структуры сайта, — в главе 5.
Время ожидания репликации
Репликация в Active Directory Windows Server 2003 реализована таким образом, что копирование на другие контроллеры домена изменений, сделанных на одном из контроллеров, может занимать некоторое время. Эта временная задержка называется временем ожидания репликации (replication latency). В большинстве случаев время ожидания репликации легко вычислить, особенно в пределах сайта. Как уже говорилось, любое изменение, сделанное в базе данных каталога на одном из контроллеров домена, будет копироваться партнерам по репликации приблизительно через 15 с. Контроллер домена адресата задержит это изменение на 15 с, а затем передаст его своим партнерам по репликации. Время ожидания репликации в пределах сайта приблизительно равно 15-ти секундам, умноженным на количество ретрансляций, которые потребуются, прежде чем информация достигнет всех контроллеров домена. Топология репликации в пределах сайта никогда не требует более трех ретрансляций, так что максимальное время ожидания репликации в пределах сайта составляет примерно 45 с.
Определить время ожидания репликации между сайтами несколько труднее. Прежде всего, вы должны вычислить время ожидания репликации в пределах исходного сайта. Это то время, которое потребуется для копирования изменений, сделанных на контроллере домена сайта-
источника, на сервер-плацдарм того же сайта. Как только информация достигнет сервера-плацдарма сайта-источника, время, которое потребуется информации для попадания на сайт адресата, определяется расписанием связи этого сайта и интервалом между репликациями. По умолчанию репликации выполняются каждые 3 часа в течение дня. Если это значение не изменено, то эти 3 часа можно добавить ко времени ожидания репликации. Когда информация достигает сервера-плацдарма на сайте адресата, то к общему времени ожидания нужно добавить еще и время ожидания репликации внутри сайта для сайта адресата. В некоторых случаях полученное время ожидания может быть достаточно велико. Чтобы уменьшить его, необходимо сократить интервал репликаций между сайтами до 15 минут (минимальное значение).
Управление временем ожидания репликаций предполагает балансирование между потребностью в коротком времени ожидания и ограничением пропускной способности сети. Если требуется очень короткое время ожидания, все контроллеры домена должны быть помещены в один и тот же сайт, в этом случае оно будет равняться примерно 45 с для всех контроллеров домена. Однако если офисы вашей компании соединены WAN-связями с ограниченной пропускной способностью, вам потребуется несколько сайтов, и время ожидания репликаций увеличится.
Срочная репликация
Иногда время ожидания репликации может оказаться слишком большим, например, когда в каталоге меняется атрибут, связанный с защитой. Для этих ситуаций Active Directory использует срочную репликацию (urgent replication), при которой контроллер домена передает изменения своим партнерам по репликации немедленно. Любой контроллер домена, получивший срочное обновление, отправит изменение немедленно. Таким образом, все контроллеры домена в сайте обновят информацию в течение нескольких секунд. Срочные репликации могут быть вызваны следующими типами изменений.

• Изменение политики блокировки учетных записей для домена.
• Изменение политики паролей домена.
• Перемещение роли хозяина относительного идентификатора (RID) на новый контроллер домена.
• Изменение безопасности локальных средств защиты (LSA - Local Security Authority), например, когда изменяется пароль компьютера контроллера домена.

По умолчанию срочные обновления применяются только к внутренней репликации и не применяются к репликации между сайтами. Политика применения срочных обновлений может быть изменена путем разрешения уведомлений для репликации между сайтами.
Пользовательские изменения пароля реплицируются по другой модели. Когда пользователь изменяет пароль на контроллере домена, это
изменение немедленно копируется прямо в PDC-эмулятор. Эта репликация пересекает границы сайта и не использует серверы-плацдармы сайтов. Вместо этого контроллер домена, на котором было сделано изменение, для обновления пароля использует RPC-подключение к PDC-эму-лятору. Затем PDC-эмулятор обновляет все другие контроллеры домена через нормальный процесс репликации. Если пользователь попытается войти на контроллер домена, который еще не получил новый пароль, контроллер домена, прежде чем отклонить вход в систему, проверит PDC-эмулятор, на предмет наличия обновлений, касающихся изменения пароля этого пользователя.
Генерация топологии репликации
Ключевым моментом репликации в 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.)
Когда вы производите изменения объекта связи, его имя <automaticallygenerated> (автоматически сгенерированный) заменяется на глобальный уникальный идентификатор объекта (GUID). После изменения объекта вы можете его переименовать.

Рис. 4-1. Конфигурирование существующего объекта связи
Создание нового объекта связи
Вы можете также создать совершенно новый объект связи, установив тем самым определенную топологию репликации. При создании объекта связи вы задаете, с какого контроллера домена будут браться обновления. Вы можете изменить любой параметр настройки в соглашении о связях.
Служба КСС не будет удалять или изменять связи, которые были изменены или созданы вручную. КСС будет использовать созданные вручную объекты связи так, как использовал бы любую другую связь. КСС может реконфигурировать объекты связи в сайте, чтобы скомпенсировать объекты связи, созданные вручную.
Топология репликации внутри сайта
Существует два варианта конфигурирования репликации между контроллерами домена в Active Directory. В первом варианте используется модель остовного дерева (spanning tree), когда создается топология репликации только с одним направлением репликации между контроллерами домена. Каждый контроллер домена, на котором размещается раздел каталога, будет иметь только одного партнера по репликации, передающего данные для этого раздела. Это гарантия того, что никогда не возникнут связи, по которым информация будет пересылаться на определенный контроллер домена более чем одним путем. Контроллеры домена никогда не получат одно и то же обновление дважды, потому что оно прибывает только из одного источника. Основной недостаток использования алгоритма spanningtreeсостоит в отсутствии избыточности. Если на одном из контроллеров домена произойдет сбой, то может потребоваться некоторое время на повторное вычисление пути репликации в обход неисправного контроллера.
Второй вариант создания топологии репликации должен включать избыточные связи. Основными целями разработки топологии репликации 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. Кольца репликации в сложном сайте

Раздел каталога

Партнеры по репликации

Раздел конфигурации каталога, раздел схемы каталога

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

Раздел каталога домена Contoso.com

DCl.Contoso.com, DC2.Contoso.com, DC3.Contoso.com, DC4.Contoso.com.

Раздел каталога домена Fabrikam.com

DC5.Fabrikam.com, DC6.Fabrikam.com.

Глобальный каталог (GC)

DCl.Contoso.com, DC4.Contoso.com, DC5.Fabrikam.com.

Раздел приложений каталога AppPartitionl

DC2.Contoso.com, DC6. Fabrikam.com.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 DCl.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 приведен пример компании, имеющей два домена с одним контроллером домена в каждом; оба домена расположены в одном и том же сайте. Домен DCl.Contoso.com сконфигурирован как сервер глобального каталога. GC-сервер является также единственным контроллером домена для домена Contoso.com, поэтому он извлекает GC-информацию для Contoso.com из своей собственной базы данных домена. Контроллер домена в домене Fabrikam.com имеет единственную копию раздела каталога этого домена, поэтому DCl.Contoso.com собирает GC-информацию для домена Fabrikam.com из DC2.Fabrikam.com. Для извлечения информации из домена Fabrikam.com создан объект связи, направленный от DC2.Fabrikam.com к DCl.Contoso.com. В дальнейшем эта связь может использоваться для репликации GC-информации в DCl.Contoso.com.

Рис. 4-7. Пример простой репликации глобального каталога
На рисунке 4-8 показан более сложный пример создания GC и его репликации. В этом случае сконфигурирован объект связи, направленный от контроллера домена каждого домена на каждый GC-сервер. DCl.Contoso.com имеет входящий объект связи от контроллеров DC2.Contoso.com, DC4.Fabrikam.com и DC6.NWTraders.com. Этот объект связи используется для создания глобального каталога на DCl.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, контроллеры DCl.Contoso.com и DC6.Fabrikam.com являются также GC-серверами. Это означает, что они станут серверами-плацдармами при репликации GC-информации между сайтами. Поскольку раздел схемы и раздел конфигурации каталога являются общими для всех контроллеров домена, то для репликации этих разделов может использоваться один из существующих объектов связи.
Примечание. Приведенное обсуждение топологии репликации основано на заданном по умолчанию поведении для контроллеров домена Active Directory. Администраторы могут изменять это поведение, особенно для репликации между сайтами. Эти вопросы будут обсуждаться далее в этой главе.

Рис. 4-9. Межсайтовые объекты связи
Процесс репликации
Выше обсуждались детали создания топологии репликации в Active Directory. В данном разделе рассмотрим репликацию с другой точки зрения. Обратим внимание на то, как на самом деле передается модифицированная информация между двумя контроллерами домена, как контроллеры домена узнают о том, какую информацию они должны копировать партнерам по репликации, настроенным службой КСС.
Типы обновлений
Существуют два типа обновлений информации Active Directory, касающейся определенного контроллера домена. Первый тип обновлений - исходное обновление (originating update). Исходное обновление выполняется при добавлении, изменении или удалении объекта на контроллере домена. Второй тип обновлений - реплицируемое обновление (replicated update). Репликация выполняется тогда, когда изменение, сделанное на одном контроллере домена, копируется на другой контроллер домена. По определению исходное обновление, касающееся любого конкретного изменения, только одно, оно выполняется на том контроллере домена, где было сделано. Затем исходное обновление копируется на все контроллеры домена, которые имеют реплику раздела Active Directory, затронутого обновлением.
Исходные обновления Active Directory происходят в следующих случаях:

• к Active Directory добавлен новый объект;
• из Active Directory удален существующий объект;
• атрибуты существующего объекта изменены. Эта модификация может включать добавление нового значения атрибуту, удаление значения атрибута или изменение существующего значения;
• объект Active Directory перемещен в новый родительский контейнер. Если изменяется имя родительского контейнера, то каждый объект контейнера перемещается в переименованный контейнер.

Все исходные обновления Active Directory являются элементарными операциями. Это означает, что в процессе передачи модификация должна быть передана полностью, как целая транзакция, и никакая ее часть не передается отдельно от других частей.
Репликация изменений
После передачи исходного обновления изменение должно реплицироваться на другие контроллеры домена, которые содержат реплику этого раздела. В пределах сайта контроллер домена, на котором произошло исходное обновление, ждет 15 с перед началом копирования изменений своим прямым партнерам по репликации. Это ожидание предназначено для того, чтобы несколько модификаций к базе данных можно было реплицировать одновременно, что увеличивает эффективность репликации. Между сайтами исходное обновление будет копироваться партнерам по репликации в соответствии с графиком, сконфигурированным на связях сайта.
Для репликации изменений информации каталога контроллерам домена требуется механизм для управления потоком репликации. Для оптимизации репликации Active Directory следует пересылать только те изменения, которые должны реплицироваться между двумя контроллерами домена. Контроллеры домена должны уметь определять эти изменения, если таковые вообще имеются, а затем копировать только ту часть изменений, которая требуется. Для управления репликацией каталога в Active Directory используются порядковые номера обновлений (USN - update sequence number), значения уровня (high-watermark value), векторы новизны (up-to-dateness vectors) и отметки об изменениях (change stamps). Эти компоненты обсуждаются далее.
Порядковые номера обновлений
Когда объект базы данных модифицируется, то изменению присваивается порядковый номер обновления. Порядковые номера обновления (USN — update sequence number) являются спецификой баз данных сервера. Например, если изменению номера телефона одного из пользователей был назначен номер USN 5555, то следующее изменение базы данных, независимо от изменяемого объекта, будет иметь номер USN 5556. Один номер USN назначается для каждого совершенного изменения. Если в одной модификации
изменено несколько атрибутов (например, адрес, номер телефона и местоположение офиса), то этой модификации назначается только один USN.
Существует три способа использования USN при выполнении модификаций. Во-первых, локальное значение USN сохраняется вместе с атрибутом, который был модифицирован. Локальное значение идентифицирует USN измененного атрибута. Во-вторых, USN используется для атрибута uSNChangedобъекта. Этот атрибут хранится с каждым объектом и идентифицирует самый высокий USN для атрибутов данного объекта. Рассмотрим пример. Предположим, что был изменен номер телефона пользователя, и этому изменению был назначен USN, равный 5556. И локальный USN, и атрибут uSNChangedбудут установлены на 5556. Если следующая модификация, сделанная в каталоге на том же сервере, состоит в изменении адреса того же самого пользователя, то местный USN на атрибуте адреса и атрибут uSNChangedдля пользовательского объекта будут изменены на 5557. Однако местный USN для атрибута номера телефона останется равным 5556, потому что это USN для последней модификации этого конкретного атрибута.
Локальный USN и атрибут uSNChangedотносятся как к исходным, так и к реплицируемым обновлениям. В последнем способе USN используется как USN исходной модификации атрибута. Это значение устанавливается только для исходных модификаций, оно копируется на все другие контроллеры домена как часть репликации атрибутов. Когда на сервере изменяется номер телефона пользователя, то USN этого изменения назначается равным исходному значению USN. Когда измененный номер телефона копируется на другой контроллер домена, исходный USN посылается вместе с модификацией, и это значение не изменяется на контроллере домена адресата. Локальный USN и атрибут uSNChangedбудут изменены на контроллере домена адресата, но исходный USN не изменится до тех пор, пока сам атрибут не будет снова модифицирован. Исходный USN используется для демпфирования распространения, которое рассматривается далее в этой главе.
Значения уровней
Значения уровней (high-watermark values) используются для управления тем, какая информация реплицируется между контроллерами домена. Каждый контроллер домена поддерживает свой собственный набор уровней для каждого из своих прямых партнеров по репликации. Уровень -это последнее значение uSNChanged, которое контроллер домена получил от определенного партнера по репликации. Когда контроллер домена посылает модификацию партнеру по репликации, значение uSNChangedпосылается вместе с модификацией. Контроллер домена адресата сохраняет его как значение уровня для партнера по репликации.
Значения уровней используются во время процесса репликации. Когда один контроллер домена запрашивает обновление у другого контроллера домена, то контроллер-адресат посылает свое значение уровня контроллеру-отправителю. Контроллер-отправитель использует значение уровня контроллера-адресата для фильтрации всех потенциальных обновлений и посылает только те изменения, которые имеют более высокое значение uSNChanged.
Примечание. Значение уровня поддерживается отдельно для каждого раздела каталога на контроллере домена и для каждого прямого партнера по репликации.
Векторы новизны и демпфирование распространения
Векторы новизны (up-to-dateness vectors) также используются для управления тем, какая информация должна копироваться между контроллерами домена. Векторы новизны используются для отслеживания всех исходных модификаций, которые данный контроллер домена получил от какого-либо контроллера домена. Например, изменен номер телефона пользователя на контроллере домена DC1, и атрибуту назначен исходный USN, равный 5556. Когда этот атрибут реплицируется на контроллер DC2, исходный USN копируется с обновленным атрибутом. Кроме того, GUID контроллера DC1 реплицируется вместе с атрибутом. Когда DC2 получает это обновление, он модифицирует свой вектор новизны, показывая, что самое последнее исходное обновление, полученное от DC1, теперь равно 5556. Вектор новизны используется для ограничения трафика репликации между контроллерами домена. Когда контроллер-адресат запрашивает обновление у контроллера-отправителя, он включает в запрос свои векторы новизны. Затем компьютер-отправитель использует эту информацию для фильтрации списка всех возможных модификаций, которые он может послать контроллеру-адресату. Такой выбор важен, когда имеется более двух контроллеров домена для данного раздела каталога. Например, если к сценарию, описанному в предшествующем параграфе, добавить контроллер DC3, то изменение номера телефона, сделанное на DC1, будет копироваться и на DC2, и на DC3. Теперь DC3 и DC2 будут иметь обновленный номер телефона, они изменят свои векторы новизны, показывая, что самая последняя модификация, которую они оба получили от DC1, имела исходный USN 5556. Приблизительно через 15 с после получения этой модификации DC2 уведомит DC3, что у него есть обновленная информация. Когда DC3 будет запрашивать обновления каталога у DC2, он включит свой вектор новизны в запрос. В этом случае DC2 определит, что вектор новизны контроллера DC3 для DC1 уже имеет новейший исходный номер USN. Если модификация номера телефона была единственным изменением, сделанным к каталогу в этот временной период, то информация между контроллерами домена DC2 и DC3 реплицироваться не будет. Процесс ограничения модификаций, посылаемых во время репликации, с помощью вектора новизны называется демпфированием распространения. Как уже говорилось, служба КСС создает избыточные репли-кационные связи между контроллерами домена. Одна из проблем, связанных с этим, состоит в том, что одни и те же модификации могут посылаться контроллеру домена от нескольких партнеров по репликации. Это ведет к увеличению трафика репликации, а также потенциально приводит к ситуации, когда одна и та же модификация посылается неоднократно всем контроллерам домена. Демпфирование распространения, использующее вектор новизны, устраняет такую возможность.
Просмотр информации USN
Номера USN (update sequence number) для любого объекта можно просмотреть с помощью средств администрирования, включенных в инструментальные средства поддержки Windows Server 2003. Один из способов просмотра локального USN исходного контроллера домена, исходного USN и отметки времени (time stamp) для любого атрибута состоит в использовании инструмента командной строки Repadmin. (Полную инструкцию по установке Repadmin смотрите в разделе «Мониторинг и поиск неисправностей репликации» далее в этой главе.) Напечатайте repadmin /showmetaobjectdistinguishedname(отличительное имя объекта) в командной строке. Значения uSNCreatedи uSNChangedможно увидеть в ADSI Edit через свойства объекта. Чтобы получить доступ к информации репликации через Ldp.exe, найдите объект, щелкните правой кнопкой мыши на объекте, выберите Advanced (Расширенный), затем выберите Replication Metadata (Мета-данные репликации). Значения USN также можно присмотреть через Монитор репликации (см. рис. 4-10). Для этого добавьте сервер к списку мониторинга, а затем щелкните правой кнопкой мыши на сервере и выберите Show Attribute Meta-Data For Active Directory Object (Показать метаданные атрибута для объекта Active Directory). Введите мандат (credentials) для учетной записи с доступом к Active Directory, а затем напечатайте отличительное имя объекта. Часть USN-информации доступна также из обычных средств администрирования. Чтобы посмотреть текущие и исходные значения USN для объекта в инструменте администрирования Active Directory Users And Computers, включите Advanced Features (Расширенные функции) в меню View (Вид), а затем обратитесь к вкладке Object (Объект) в окне Properties (Свойства) объекта.
Уровень и вектор новизны используются для ограничения трафика репликации. Значение уровня представляет собой самое последнее изменение, которое контроллер домена получил от другого контроллера домена, так что контроллер-отправитель не должен снова посылать это значение. Вектор новизны содержит самые свежие обновления, которые были получены от других контроллеров домена, содержащих реплику раздела, так что контроллер-отправитель не должен посылать такие модификации каталога, которые контроллер-адресат уже получил от другого партнера по репликации.

Рис. 4-10. Просмотр мета-данных репликации с помощью Replication Monitor (Монитор репликации)
Отметки об изменениях и разрешение конфликтов
И последнее, что используется для управления репликацией между контроллерами домена, — это отметка об изменении (change stamp). Всякий раз, когда атрибут модифицируется, эта модификация помечается отметкой об изменении. Затем отметка об изменении посылается вместе с модификацией, когда модификация копируется на другие контроллеры домена. Отметка об изменениях используется для того, чтобы определить, какое изменение будет принято в случае конфликта репликации. Отметка об изменениях состоит из трех компонентов.

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