Внутренняя и внешняя репликация между сайтами

🕛 19.01.2009, 20:25

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