Страницы: 1 2 3 4 5 6 7 .. 16

Глава 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. Кольца репликации в сложном сайте

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

Рис. 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). Всякий раз, когда атрибут модифицируется, эта модификация помечается отметкой об изменении. Затем отметка об изменении посылается вместе с модификацией, когда модификация копируется на другие контроллеры домена. Отметка об изменениях используется для того, чтобы определить, какое изменение будет принято в случае конфликта репликации. Отметка об изменениях состоит из трех компонентов.

• Номер версии. Он используется для отслеживания количества изменений, которые были сделаны к атрибуту объекта. Когда объект создается, номер версии у всех атрибутов устанавливается на 1, даже если поле атрибута оставлено пустым. Когда происходит назначение «пустого» атрибута, значение номера версии остается равным 1. Однако когда атрибут обновляется после начального изменения, номер версии каждый раз увеличивается на единицу.
• Время последней записи. Оно используется для отслеживания времени, когда произошла последняя модификация атрибута. Значение времени регистрируется на том сервере, где атрибут был модифицирован, и копируется вместе с объектом на другие контроллеры домена.
• Исходный сервер (Originating server). Этот компонент представляет собой GUID сервера, на котором была применена последняя исходная модификация атрибута.

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

1. Номер версии. Всегда принимается изменение с самым высоким номером версии. Если изменение на одном контроллере домена имеет номер версии 3, а изменение на другом контроллере домена - номер версии 4, будет всегда приниматься изменение с номером версии 4.
2. Время последней записи. Если номера версий идентичны, то будет принято изменение с самым недавним временем последней записи.
3. GXJID сервера. Если номера версий и времена последней записи идентичны, то используется GUID базы данных сервера для определения того, какое изменение должно быть принято. Будет принято изменение, прибывающее с сервера, имеющего более высокий GUID. Идентификаторы GUID назначаются при добавлении контроллера домена к домену, a GUID назначается произвольно.

Практический опыт. Конфликты репликации
Некоторые сетевые администраторы, похоже, очень озабочены возможностью возникновения конфликтов репликации и потенциальной потерей или перезаписью данных. В большинстве компаний вероятность их возникновения невелика. Во-первых, конфликты репликации касаются отдельных атрибутов. (Если номер телефона пользователя изменяется на одном контроллере домена в то же самое время, когда адрес пользователя изменяется на другом контроллере домена, никакой конфликт не возникает.) Во-вторых, большинство компаний имеют централизованный отдел, где делаются все изменения к учетным записям пользователя, так что вероятность того, что два человека сделают различные изменения к одному и тому же атрибуту одновременно, очень мала. Если администрирование учетных записей пользователя делегировано на уровень отдела, то каждый отдел делает изменения только к учетным записям пользователя своего отдела. Таким образом, в большинстве компаний, использующих структурированный способ работы с объектами Active Directory, конфликты репликации происходят очень редко.
Служба Active Directory способна разрешать конфликты, которые создаются, когда один и тот же атрибут объекта изменяется одновременно на двух контроллерах домена. Имеются два других типа конфликтов, которые могут возникать.

• Добавление или изменение объекта на одном контроллере домена в то же самое время, когда контейнерный объект этого объекта удаляется на другом контроллере домена. Рассмотрим пример, в котором на одном контроллере домена был добавлен новый пользователь к организационной единице (OU) Accounting (Бухгалтерия). В это же время на другом контроллере домена другой администратор удаляет OU Accounting. В этом случае объект, который был добавлен к удаленному контейнеру, будет перемещен в контейнер Active Directory с именем LostAndFound.
• Добавление объектов с одним и тем же относительным отличительным именем (relative distinguished name) в один и тот же контейнер. Такой конфликт возникает, когда администратор на одном контроллере домена создает пользовательский объект с относительным отличительным именем BDiaz в OU Accounting, в то же самое время на другом контроллере домена пользователь, имеющий такое же относительное отличительное имя, перемещается в ту же самую OU или создается в той же самой OU. В этом случае для определения того, какой объект будет сохранен, а какой переименован, в модели разрешения конфликтов будет использоваться GUID, назначенный модифицируемому каталогу. Объект, имеющий более высокий GUID, будет сохранен, а объект с более низким GUID переименован на BDiaz#CNF:userGUID, где значок номера (#) является символом дублирования. Если второй пользовательский объект потребуется, то его можно будет переименовать.

Репликация удалений объектов
Репликация удалений объектов обрабатывается в Active Directory иначе, чем другие модификации каталога. Когда удаляется учетная записи пользователя, она не уничтожается немедленно. Вместо этого создается объект-памятник (tombstone). Объект-памятник является исходным объектом, у которого атрибут isDeletedустановлен на true(истина), а большинство атрибутов объекта удалено. Сохранены только несколько атрибутов, типа GUID, SID, USN и отличительного имени, которые требуются для идентификации этого объекта.
Объект-памятник затем копируется на другие контроллеры домена в домене. По мере того как каждый контроллер домена получает модификацию, модификации, которые были сделаны на исходном контроллере домена, применяются на всех остальных контроллерах. Объекты-памятники остаются в базе данных домена в течение определенного периода времени, называемого временем жизни объекта-памятника (tombstone lifetime). В конце времени жизни объекта-памятника, установленного по умолчанию на 60 дней, каждый контроллер домена удаляет его из своей копии базы
данных. Процесс удаления объектов-памятников из базы данных называется сборкой мусора (garbage collection). По умолчанию интервал времени, через который производится сборка мусора, для леса установлен на 12 часов. Каждые 12 часов выполняется процесс сборки мусора, и удаляются все объекты-памятники, время жизни которых истекло.
В главе 1 говорилось о том, что служба Active Directory Windows Server 2003 обеспечивает поддержку неактивных объектов в Active Directory. Неактивный объект (lingering object) — это объект, который не был удален из контроллера домена, потому что контроллер находился в автономном режиме или был не способен к репликации в течение всего времени жизни объекта-памятника. Для удаления неактивных объектов используется инструмент Repadmin.
Совет. Время жизни объекта-памятника и интервал сборки мусора может быть изменен с помощью ADSI Edit или Ldp.exe. Эти свойства сконфигурированы в объекте CN=Directory Service,CN=Windows NT,CN=Services,CN = Configuration, DC=ForestRootDomain. Атрибуты garbageCollPeriod и tombstoneLifetime определяют эти параметры настройки. В большинстве случаев эти значения менять не требуется.
Конфигурирование репликации между сайтами
Причина создания нескольких сайтов в Active Directory заключается в необходимости управлять трафиком репликации между несколькими офисами компании, особенно между теми, которые соединены низкоскоростными WAN-соединениями. Конфигурация сайта для вашей компании будет оказывать существенное воздействие на трафик репликации, идущий по сети.
Дополнительная информация. Сформулировать четкий критерий того, когда следует создавать дополнительный сайт, трудно из-за большого количества переменных, которые должны быть включены в этот критерий. В главе 5 приводится подробная информация о создании дополнительных сайтов. В этой главе далее рассмотрены другие вопросы построения Active Directory, которые нужно учитывать при проектировании топологии сайта.
Как сказано в главе 2, сайт в Active Directory — это место, в котором все контроллеры домена связаны друг с другом высокоскоростными соединениями. Одна из задач установки сети Active Directory состоит в определении того, где следует провести границы сайта, а затем соединить сайты вместе.
Создание дополнительных сайтов
Когда устанавливается Active Directory, создается единственный сайт с именем Default-First-Site-Name(в дальнейшем сайт можно переименовать). Если не создается дополнительных сайтов, то все последующие контроллеры домена будут добавляться к этому сайту по мере их установки. Однако если ваша компания расположена в нескольких местах с ограниченной пропускной способностью между ними, то вы наверняка захотите создать дополнительные сайты. Дополнительные сайты создаются с помощью инструмента администрирования Active Directory Sites And Services (Сайты и службы Active Directory). Чтобы создать новый сайт, щелкните правой кнопкой мыши на контейнере Sites (Сайты), затем выберите New Site (Новый сайт). В списке Link Name (Имя связи) вы должны выбрать ту связь сайта, которая будет использоваться для соединения этого сайта с другими сайтами. Каждый сайт связан с одной или более подсетями IP в Active Directory. Создайте дополнительные подсети в контейнере Subnets (Подсети) в инструменте Active Directory Sites And Services и свяжите подсети с новым сайтом. Каждый сайт должен иметь, по крайней мере, один контроллер домена и GC-сервер. Чтобы переместить существующий контроллер домена в сайт, вы можете щелкнуть правой кнопкой мыши на объекте контроллера домена в его текущем контейнере Servers (Серверы) и выбрать Move (Переместить). Затем вам будет предложен выбор сайта, в который вы хотите переместить контроллер домена. Если вы устанавливаете новый контроллер домена, то он будет автоматически расположен в том сайте, в котором подсеть IP соответствует IP-адресу контроллера домена. Возможно создание сайта без контроллеров домена, но этого делать не следует.
Связи сайта
Соединения Active Directory, которые связывают сайты вместе, называются связями сайта (Site Links). При инсталляции Active Directory создается единственная связь сайта с именем DEFAULTIPSITELINK. Если вы не создадите никаких дополнительных связей сайта прежде, чем создадите дополнительные сайты, то каждый сайт включается в эту заданную по умолчанию связь сайта. Если WAN-связи между офисами вашей компании одинаковы по пропускной способности и стоимости, вы можете просто принять это заданное по умолчанию поведение. Если все сайты соединены одной связью, трафик репликации между ними будет иметь одинаковые свойства. При изменениях в связи сайта конфигурация репликации для всех сайтов будет изменена. Если вы хотите иметь возможность по-разному управлять репликацией между сайтами, вы должны создать дополнительные связи сайта и назначить им соответствующие сайты.
Создание связей сайта не заменяет работу ISTG. При этом происходит лишь создание возможностей для работы ISTG. Как только связь сайта установлена, ISTG будет использовать ее для создания необходимых объектов связи, предназначенных для репликации всех разделов Active Directory между всеми сайтами.
Ниже приведены опции конфигурации для всех связей сайта.

• Стоимость (Cost) - это назначенное администратором значение, которое определяет относительную стоимость связи сайта. Стоимость обычно отражает скорость сетевой передачи и расходы, связанные с ее использованием. Стоимость становится важным параметром, если в организации имеются избыточные связи сайта, т.е. более одного пути для репликации между двумя сайтами. Во всех случаях в качестве пути репликации выбирается маршрут самой низкой стоимости.
• График репликации (Replication schedule) — определяет, в какое время в течение дня связь сайта доступна для репликации. Заданный по умолчанию график репликации разрешает репликации в течение 24 часов в день. Однако если пропускная способность пути к сайту ограничена, репликация может происходить только в нерабочие часы.
• Интервал репликации (Replication interval) - определяет интервалы времени, через которые серверы-плацдармы проверяют появление модификаций каталога на серверах-плацдармах других сайтов. По умолчанию интервал репликации для связей сайта установлен на 180 минут. Интервал репликации применяется только в соответствии с графиком репликации. Если график репликации сконфигурирован так, чтобы позволять репликации с 22:00 до 5:00 по умолчанию, то серверы-плацдармы проверяют модификации через каждые 3 часа в этом промежутке времени.
• Транспортные протоколы репликации (Replication transports). Для передачи репликации связь сайта может использовать или RPC по IP, или SMTP. Дополнительную информацию смотрите в разделе «Протоколы транспортировки репликации» далее в этой главе. Эти опции обеспечивают существенную гибкость в конфигурировании репликации между сайтами. Однако существуют также некоторые ошибки, которых следует избегать. Чтобы понять, как эти опции работают вместе, рассмотрите сеть компании, показанную на рисунке 4-11.

В Active Directory Windows Server 2003 все связи сайта считаются транзитивными (transitive) по умолчанию. Как показано на рисунке 4-11, Sitel имеет связи с сайтами Site2 и Site4, a Site2 имеет связь с сайтами Site3 и Site5. Из-за транзитивной природы связей сайта это означает, что Sitel может также реплицировать информацию напрямую с сайтами Site3 и Site5.
Стоимость связей сайта определяет путь, по которому будет происходить трафик репликации по сети. Когда КСС создает топологию маршрутизации, он использует накопленную информацию о стоимости всех связей сайта для вычисления оптимальной маршрутизации. В примере, показанном на рисунке 4-11, есть два возможных маршрута между сайтами Sitel и Site5: первый маршрут — через Site2, второй маршрут — через Site4. Стоимость передачи через Site2 - 300 (100 + 200), стоимость передачи через Site4 — 700 (500 + 200). Это означает, что весь трафик репликации будет направляться через Site 2, если это подключение функционирует.

Рис. 4-11. Конфигурация связи сайта
Когда трафик репликации проходит по нескольким связям сайта, графики связей сайта и интервалы репликации объединяются для определения эффективного окна репликации и интервала. Например, эффективная репликация между сайтами Site1 и Site3 будет происходить только с 24:00 до 4:00 (это время перекрытия графиков) каждые 60 минут (интервал репликации для связи Site2-Site3).
Примечание. Если графики связей сайта не перекрываются, то между несколькими сайтами репликация все-таки возможна. Например, если связь Sitel-Site2 доступна с 2:00 до 6:00, а связь Site2-Site3 доступна от 22:00 до 1:00, изменения каталога от сайта Sitel к сайту Site3 смогут передаваться. Изменения будут посланы от сайта Sitel к Site2, а затем от сайта Site2 к сайту Site3. Однако в этом случае время ожидания репликации составило бы почти целый день, потому что изменения, реплицированные на Site2 в 2:00, не будут реплицироваться на Site3 до 22:00.
Мосты связей сайта
В некоторых случаях вы можете отменить транзитивный характер связей сайта и вручную сконфигурировать мосты связей сайта (site link bridges). При конфигурировании мостов связей сайта вы определяете, какие из связей сайта должны рассматриваться как транзитивные, а какие - нет. Отмена транзитивного характера связей сайта может быть полезной, когда у вас нет полностью трассированной сети, т.е. не все сегменты сети доступны (на-
пример, если для подключения к одной из частей сети вы используете модемную связь, или связь осуществляется по запросам согласно графику). Мосты связей сайта могут также использоваться для конфигурирования репликации в ситуациях, когда компания имеет несколько сайтов, связанных с высокоскоростной базовой сетью, и несколько меньших сайтов, которые соединяются с каждым крупным центром через медленные соединения. В этих случаях мосты связей сайта можно использовать для более эффективного управления потоком трафика репликации.
Дополнительная информация. В главе 5 приводится подробная информация о том, когда и как следует использовать мосты связей сайта.
При создании моста связей вы должны определить, какая связь сайта является частью моста. Любые связи сайта, которые вы добавляете к мосту связей сайта, рассматриваются по отношению друг к другу как транзитивные; связи сайта, не включенные в мост связей сайта, транзитивными не являются. В примере, рассмотренном выше, мост связей сайта можно создать для связей, соединяющих Site1, Site2, Site4 и Site5. Тогда все эти связи сайтов считались бы транзитивными, что означает, что сервер-плацдарм сайта Sitel мог бы напрямую обмениваться репликами с сервером-плацдармом сайта Site5. Но так как связь от сайта Site2 к сайту Site3 не включена в мост связей, она не является транзитивной. Трафик репликации от сайта Site3 направляется к сайту Site2, а оттуда к другим сайтам.
Чтобы выключить транзитивные связи сайта, очистите опцию Bridge All Site Links (Все сетевые связи объединены в мост) на вкладке General (Общие) окна IP-Properties (Свойства IP). Объект IP расположен в контейнере Inter-Site Transports (Средства передачи между сайтами) в инструменте администрирования Active Directory Sites And Services. Будьте осторожны, выполняя это действие, поскольку теперь вы должны будете сконфигурировать мосты связей сайта для всех сайтов, если захотите установить транзитивные связи сайта.
Транспортные протоколы репликации
Active Directory Windows Server 2003 может использовать один из трех различных методов транспортировки репликации.

• Использование RPC по IP при внутрисайтовой репликации. Все подключения репликации в пределах сайта должны использовать подключение RPC no IP. Это подключение является синхронным, т.е. контроллер домена может в каждый момент времени обмениваться репликой только с одним партнером по репликации. RPC-подключение использует динамическое назначение портов (dynamic port mapping). Первое RPC-подключение выполняется через порт преобразователя конечного узла RPC (RPC endpoint mapper port) (IP порт 135). Это подключение применяется для определения порта, который использует контроллер-адресат для репликации.

Совет. Если вы реплицируете информацию каталога через брандмауэр или используете маршрутизаторы с включенной функцией фильтрации портов, вы можете определить номер порта, используемый контроллерами домена для репликации. Чтобы сделать это, создайте ключ системного реестра со значением типа DWORD и укажите любой допустимый номер порта: HKEY_LO-CAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\ Parameters\TCP/IP Port.

• Использование RPC no IP при межсайтовой репликации. Это RPC-подключение отличается от межсайтового подключения только тем, что по умолчанию весь трафик, передаваемый между сайтами, сжат.

Примечание. Если вы рассмотрите два типа подключений RPC по IP в инструменте администрирования Active Directory Sites And Services, то заметите, что они по-разному идентифицированы в интерфейсе. RPC no IP в пределах сайта называется RPC, a RPC no IP между сайтами называется IP.

• Использование SMTP при межсайтовой репликации. SMTP может оказаться хорошим выбором в методике репликации, если вы не имеете постоянной и быстрой связи между офисами компании. SMTP использует асинхронное подключение, т.е. контроллер домена может выполнять репликации с несколькими серверами одновременно. Однако использование SMTP имеет некоторые ограничения. Во-первых, SMTP может использоваться только для репликации информации между контроллерами домена, расположенными в различных доменах. С помощью протокола SMTP можно реплицировать только раздел конфигурации каталога, раздел схемы каталога и раздел GC. Во вторых, репликация по протоколу SMTP требует, чтобы компонент SMTP в информационных службах интернета (IIS) был установлен на всех контроллерах домена, которые будут использовать SMTP для репликации. Третье ограничение состоит в том, в организации необходимо установить Microsoft Certificate Authority (MCA) (Полномочие на выдачу сертификатов). Сертификаты от МСА используются для цифровых подписей к сообщениям SMTP, которые посылаются между контроллерами домена.

Конфигурирование серверов-плацдармов
Как уже говорилось выше, репликация между сайтами выполняется через серверы-плацдармы. По умолчанию генератор межсайтовой топологии (ISTG - Inter-Site Topology Generator) автоматически идентифицирует сервер-плацдарм при вычислении топологии репликации между сайтами. Чтобы узнать, какие контроллеры домена используются в качестве серверов-плацдармов, можно использовать Replication Monitor
(Монитор репликации). Щелкните правой кнопкой мыши на имени сервера, который контролируется монитором репликации, и выберите Show Bridgehead Servers (Показать серверы-плацдармы). Вы можете выбрать серверы-плацдармы: только для сайта, которому принадлежит данный сервер, или для всего предприятия. Вы можете также просмотреть серверы-плацдармы через инструмент Repadmin. Откройте окно с командной строкой и напечатайте repadmin /bridgeheads.
В некоторых случаях необходимо управлять тем, какие контроллеры домена будут использоваться в качестве серверов-плацдармов. Работа сервера-плацдарма может добавлять существенную нагрузку на контроллер домена, если имеется много изменений информации каталога и установлено частое проведение репликации. Для конфигурирования серверов-плацдармов нужно получить доступ к объектам в инструменте администрирования Active Directory Sites And Services, щелкнуть правой кнопкой мыши на имени сервера, а затем выбрать Properties (Свойства) (см. рис. 4-12). Вы получите доступ к опции конфигурирования сервера как привилегированного (preferred) сервера-плацдарма для передачи данных по SMTP или по IP.

Рис. 4-12. Конфигурирование привилегированного сервера-плацдарма
Преимущество конфигурирования привилегированных серверов-плацдармов состоит в гарантии того, что серверами-плацдармами будут выбраны контроллеры домена, указанные вами. Если вы захотите контролировать то, какие серверы используются в качестве серверов-плацдармов, вы должны сконфигурировать привилегированный сервер-плацдарм для каждого раздела, который нужно реплицировать в сайт. Например, если сайт содержит реплики раздела каталога домена Contoso.com, раздела каталога домена Fabrikam.com, раздела GC и раздела приложений, вы должны сконфигурировать, по крайней мере, один контроллер домена с репликой каждого из этих разделов. Если вы этого не сделаете, то ISTG зарегистрирует
событие в журнале событий, а затем выберет привилегированный сервер-плацдарм для раздела. Вы можете также сконфигурировать несколько привилегированных серверов-плацдармов, в этом случае ISTG выберет в качестве сервера-плацдарма один из указанных серверов.
Конфигурирование привилегированных серверов-плацдармов ограничивает возможности ISTG выбирать сервер-плацдарм, т.е. всегда будет выбираться сервер, который сконфигурирован как привилегированный. Если этот сервер не будет работать и другие серверы не будут назначены в качестве серверов-плацдармов для данного раздела каталога, то ISTG не будет выбирать другой сервер-плацдарм, и репликации прекратятся до тех пор, пока сервер не будет снова доступен или пока вы не переконфигурируете опцию привилегированных серверов-плацдармов. Если привилегированный сервер-плацдарм не работает, вы можете или удалить этот сервер из привилегированных и позволить ISTG самому назначать сервер-плацдарм, или выбрать другой привилегированный сервер-плацдарм.
Предостережение. Если привилегированный сервер-плацдарм не работает, и вы решите его переконфигурировать, то изменения нужно делать в обоих сайтах. Поскольку серверы-плацдармы не функционируют, то никакая информация не будет реплицироваться между сайтами до тех пор, пока конфигурационные изменения не будут сделаны в обоих сайтах.
Мониторинг и поиск неисправностей репликации
Одно из наиболее полезных инструментальных средств, предназначенных для мониторинга и поиска неисправностей репликации, — это Replication Monitor (Монитор репликации). Он устанавливается как часть файла Suptools.msi из каталога Support\Tools с компакт-диска Windows Server 2003. Чтобы запустить Replication Monitor, в командной строке напечатайте replmon. Монитор репликации открывается с пустым инструментом управления. Перед началом работы щелкните на Edit в строке меню, чтобы добавить один или более серверов к списку контролируемых серверов. Как только серверы добавлены в список, вы можете управлять почти всеми аспектами репликации Active Directory. Например, отслеживать текущее состояние репликации, последнюю успешную репликацию или любые отказы при репликации; вынуждать репликацию; вынуждать КСС к повторному вычислению топологии маршрутизации. Используя инструмент мониторинга, вы можете контролировать репликации на всех контроллерах домена вашей сети. Второй полезный инструмент мониторинга репликаций - Repadmin. Он также устанавливается с помощью файла Suptools.msi. Чтобы запустить этот инструмент, в командной строке напечатайте repadmin. Инструмент Repadmin обеспечивает такие же функциональные возможное-
ти, как и Replication Monitor, но через интерфейс командной строки. Инструмент Repadmin дополнительно позволяет изменять топологию репликации, добавляя объекты связи.
Примечание. Чтобы получить подробную информацию об использовании инструментов Replication Monitor и Repadmin, откройте Help And Support Center (Центр информации и поддержки). Далее в пункте Support Tasks (Задачи поддержки) щелкните на Tools (Сервис), а затем щелкните на Windows Support Tools (Поддержка Windows). Вам будет представлен алфавитный список всех инструментальных средств поддержки с информацией о том, когда следует использовать каждый инструмент, а также инструкции о том, как им пользоваться. Вы можете запускать инструментальные средства непосредственно из окна Help And Support Center.
Существуют два стандартных средства администрирования серверов для мониторинга и поиска неисправностей репликации. Первый инструмент -Event Viewer (Средство просмотра событий). Журнал событий Directory Service (Служба каталога) — это один из журналов регистрации событий, который добавляется ко всем контроллерам домена. Большая часть событий, связанных с репликацией каталога, записывается в него, и это первое место, которое вы должны просмотреть при возникновении сбоя при репликации. Инструмент администрирования Performance (Производительность) полезен для контроля деятельности, связанной с репликацией, которая происходит на сервере. Когда сервер назначается контроллером домена, то к списку счетчиков производительности добавляется объект NTDS Performance. Счетчики производительности можно использовать для контроля объема трафика репликации, а также другой деятельности, связанной с Active Directory.
Совет. Если вы заметите отказы в репликации Active Directory между контроллерами домена, то первое, что нужно проверить -это DNS. Без правильного функционирования инфраструктуры DNS репликация не будет работать.
Резюме
Ключевым аспектом управления службой Active Directory Windows Server 2003 является понимание того, как работает репликация. Устойчивая среда репликации необходима для поддержания новейших копий всей информации каталога на всех контроллерах домена в лесу, что необходимо для гарантии согласованного входа пользователей в систему и функционирования поиска в каталоге. В этой главе было дано описание работы репликации каталога: создание топологии репликации между контроллерами домена Active Directory в одном сайте и между контроллерами домена, расположенными в разных сайтах, описание самого процесса репликации, принципов ее оптимизации для уменьшения объема сетевого трафика.

1 2 3 4 5 6 7 .. 16