Конфигурирование репликации между сайтами
🕛 19.01.2009, 20:31
Причина создания нескольких сайтов в 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 самому назначать сервер-плацдарм, или выбрать другой привилегированный сервер-плацдарм.
Предостережение. Если привилегированный сервер-плацдарм не работает, и вы решите его переконфигурировать, то изменения нужно делать в обоих сайтах. Поскольку серверы-плацдармы не функционируют, то никакая информация не будет реплицироваться между сайтами до тех пор, пока конфигурационные изменения не будут сделаны в обоих сайтах.