Книги, научные публикации
Pages: | 1 | ... | 4 | 5 | 6 | 7 | 8 | ... | 18 | Distributed Systems Guide Microsoft Windows 2000 Server Microsoft Press Распределенные системы Книга 1 Microsof Windows 2000 ...
-- [ Страница 6 ] --Не запускайте службу в контексте LocalSystem на контроллере домена. В против ном случае служба получит слишком обширные полномочия в отношении Active Directory, так как LocalSystem на контроллере домена обладает полным доступом к каталогу. В большинстве случаев нельзя разрешать выполнение приложений в дан ном контексте, так как это создает серьезную угрозу сохранности и пелостност i информации каталога.
Учетная запись LocalSystem и учетная запись службы Контекст LocalSystem накладывает ограничения на службы, работающие с Active Directory. Если служба запущена под учетной записью LocalSystem на компьюте ре члене домена (например, на рядовом сервере под управлением Windows Server или компьютере под управлением Windows 2000 Professional), при доступе к ресурсам домена (например, к Active Directory) она выполняется в контексте учет ной записи компьютера. Обычно учетные записи компьютеров имеют очень мало привилегий и не относятся к каким-либо группам. Добавлять учетные записи ма шин в группы не рекомендуется, поскольку при переходе компьютера из одного домена в другой они удаляются и создаются заново. Стандартная конфигурация списка ACL для компьютера в Active Directory предоставляет учетным записям компьютеров минимальные права. Поэтому службы, выполняющиеся под учетной записью LocalSystem, обладают чрезвычайно ограниченным доступом к Active Directory.
Служба с доменной учетной записью и паролем получает все преимущества стан дартной доменной учетной записи. Ее разрешается добавлять в различные группы, и при перемещении компьютера в другой домен она не удаляется. Присоединение Служба каталогов Active Directory 226 ЧАСТЬ с л ужо с доменными учетными записями к группам позволяет предоставить им до ступ к заранее определенным областям Active Directory в зависимости от прав той или иной группы. Впрочем, работа службы в контексте учетной записи службы имеет некоторые недостатки.
1. Для нормальной работы службы следует предварительно создать учетную за пись этой службы. Программа установки службы, создающая эту запись, дол жна запускаться пользователем, полномочным создавать учетные записи в службе каталогов.
2. Пароли учетных записей служб хранятся на компьютере, где установлена служ ба. После смены пароля служба не сможет запуститься, пока Вы не обновите пароль.
Внимание! Если служба выполняется под учетной записью LocalSystem, необходи мо протестировать службу на рядовом сервере и убедиться, что она обладает доста точными правами, чтобы считывать и записывать данные из/в Active Directory. He следует проверять работу службы только на контроллере домена. Помните, что служба, выполняющаяся под учетной записью LocalSystem на контроллере домена, обладает полным доступам к Active Directory;
рядовые же серверы работают в кон тексте учетной записи компьютера, права которой более ограничены.
Взаимная проверка подлинности Взаимная проверка подлинности (mutual authentication) Ч это функция безопасно сти, при использовании которой до начала обмена данными между приложениями клиента и сервера процесс клиента подтверждает свою подлинность серверу, а сер вер Ч клиенту. Поддержка взаимной проверки подлинности (аутентификации) обеспечивается интерфейсом SSP1 (security support provider interface) и реализует ся непосредственно через функции и службы интерфейса SSPI, а также средствами RPC и СОМ+.
Взаимную аутентификацию поддерживают далеко не все доступные интерфейсу SSPI приложении безопасности и даже не все службы под управлением Windows 2000, Приложение должно запросить взаимную аутентификацию, а вспомогательное при ложение безопасности - корректно ее выполнить.
Взаимная проверка подлинности подразумевает, чтобы перед выполнением каких либо функций па уровне приложения клиент и сервер обязаны подтвердить друг другу свою подлинность. Аутентичность может подтверждаться доверенной третьей стороной с использованием общих секретных ключей, как в протоколе Kerheros v5, или других криптографических средств, как, например, в инфраструктуре откры тых ключей. Каждая из сторон идентифицируется по имени участника безопаснос ти (principal name).
Имя участника безопасности Главное правило взаимной аутентификации таково: ни одна из сторон не должна доверять другой, пока не будет подтверждена ее подлинность. На практике это оз начает, что сервер должен уметь определять личность клиента, не опрашивая его, а клиент обязан выполнять эту же операцию в отношении сервера. Это исключает нарушение безопасности посредством простого олицетворения.
Публикация службе Active Directory ГЛАВА Взаимная проверка подлинности и протокол Kerberos Клиенты используют локальный контекст безопасности либо путем выполнения в контексте, заданном ранее (например, в сеансе другого пользователя), либо явно предоставляя реквизиты используемому поставщику безопасности. Сервер просто не принимает соединения от пользователей, подлинность которых не подтвержде на. Клиент проверяет подлинность сервера, составляя основное имя службы (service principal name, SPN) на основе сведений о сервере, которые ему уже известны или которые он получает из других доверенных источников (за исключением еще не проверенного сервера). Затем клиент представляет SPN системе безопасности, за прашивая у сервера аутентификацию по данному имени. Клиент разрывает связь с:
сервером, который не в состоянии пройти проверку подлинности по данному SPN.
Примечание Если учетная запись службы находится не в том лесе, где размещает ся учетная запись клиента, при взаимной аутентификации произойдет сбой, по скольку протоколу Kerberos не удастся найти учетную запись службы.
Необходимо, чтобы и служба, и клиент выполнялись на компьютерах под управле нием Windows 2000, иначе взаимная аутентификация с применением Kerberos не возможна, поскольку предыдущие версии Windows не поддерживают данный про токол.
В основное имя службы входит DNS-имя узла, на котором выполняется служба;
NetBIOS-имена не поддерживаются - Вам придется использовать имена служб только в форме DNS.
Основное имя службы Это имя связано с участниками безопасности (пользователями или группами), в контексте которых выполняется служба. Оно позволяет выполнять взаимную аутентификацию между клиентским приложением и службой. SPN строится на ос нове известной клиенту информации о службе, либо клиент получает необходимые сведения от доверенной третьей стороны, например из Active Directory. SPN связа но с учетной записью, причем одна учетная запись может обладать несколькими SPN."
Подробнее о регистрации основных имен служб в Active Directory при установке службы - на Web-странице Web Resources по адресу windows2000/resldt/webresources, ссылка MSDN.
Синтаксис основного имени службы Синтаксис основного имени службы выглядит следующим образом:
<тип_службы>/<имя_экз&млляра>:<номер_порта>/<иня_службы> где:
Х <тип_службы> Ч тип службы, например www для службы World Wide Web или Idap для протокола Lightweight Directory Access Protocol;
Х <имя_экземпляра> Ч имя экземпляра службы. В зависимости от типа службы это имя или IP-адрес узла, на котором выполняется служба;
Х <номер_порта> номер порта, используемого службой на узле (если он от личается от стандартного номера порта для данного типа службы);
Служба каталогов Active Directory 228 ЧАСТЬ Х <имя_службы> Ч имя службы. Это может быть DNS-имя узла реплицируемой службы или домена. Кроме- того, в качестве имени используют составное имя объекта класса Service Connection Point или RPC Service.
Если <имя_службы> и <имя_экземпляра> совпадают (что характерно для служб на узлах), SPN разрешается сократить до двух элементов:
<тип службы>/<имя экземпляра) Если <номер_ nopma> отличается от стандартного номера порта для службы дан ного типа, его следует указывать явно:
<тип_службы>/<имя_экземпляра>: <номер_порта> Номер_порта, соответствующий стандартному номеру порта для данного
Подробнее о GSS и SSPI Ч в главе 11 Проверка подлинности.
Создание основного имени службы Основное имя службы создает клиент;
это DNS-имя домена, DNS-имя узла или составное имя объекта класса из семейства Service Connection Point, При любом спо собе аутентификации применяется одно SPN. При проверке подлинности средства ми Kerberos клиент запрашивает билет сеанса для SPN;
при проверке подлинности на основе сертификатов сверяются SPN и поле SubjectName сертификата сервера.
Зарегистрированная в DNS служба на узле Служба па узле (host-dased) - это служба, идентифицируемая по имени узла, на котором она выполняется. Формат основного имени таких служб таков:
<тип_службы>/<имяДэкземпляра>: <номер_порта_службы> Если же служба использует стандартный порт для указанного значения типа служ бы, SPN можно сократить до <тип_службь/>/<иня_экэвмпляра> Службы, опубликованные в Active Directory Формат основного имени служб, опубликованных в Active Directory, таков:
<тил_службы>/<имя_уэла>'.<номер_порта>/<составное_имя>, где:
Х <тип_службы> искомый тип службы, например print;
Х <составное_имя> - составное имя экземпляра указанного в <тип_службы> типа службы в формате, определенном в документе RFC 1779, например cn=bldg26,dc=ntdom,dc=reskit,dc=com;
Х <имя_узла> Ч DNS-имя узла, на котором выполняется экземпляр службы <со ставное_имя>\ Х <имя_домена> Ч имя домена, содержащего учетную запись, под которой выпол няется указанная в <составное_имя> служба. Формируется из компонентов dc= элемента <составное имя>.
ГЛАВА 5 Публикация служб в Active Directory Например, служба печати для группы NTDOM в здании 26 в домене Reskit (cn=bldg26,dc=ntdom,dc=reskit,dc=com), использующая нестандартный порт узла prtl.ntdom.reskit.com, имеет следующее основное имя:
prlnt/prt1.ntdom.reskit.com:1234/cn=bldg26,dc=ntdom,dc=reskit,dc=com.
Подробнее об основных именах служб - па Web-странице Web Resources по адресу ссылка MSDN, Дополнительные материалы Подробнее о создании служб для публикации в Active Directory Ч на Web-страни це Web Resources по адресу webresources, ссылка Microsoft Platform SDK.
ГЛАВА Репликация Active Directory Active Directory - распределенная служба каталогов в Microsoft Windows 2000.
Объекты в каталоге распределены между контроллерами домена в лесу, и все кон троллеры домена допускают прямое обновление. Репликация Ч это процесс, при котором изменения, выполненные па одном контроллере домена, передаются на все другие контроллеры в целом домене или лесе. Для поддержания целостности дан ных отслеживаются изменения на каждом контроллере домена и систематически обновляются другие контроллеры. Механизм репликации Active Directory базиру ется на автоматически формируемой топологии подключений, что позволяет опти мально использовать сетевые подключения и освободить администраторов от вы полнения таких задач вручную.
В этой главе Модель репликации Active Directory Обновления Active Directory Топология репликации См. также Х Подробнее о планировании сайтов, топологии сайтов и размещении контролле ров домена Ч в книге Microsoft Windows 2000 Server Deployment Planning Guide (Microsoft Press, 2000).
Х Подробнее о базе данных и хранилище объектов Active Directory Ч в главе Хранение данных в Active Directory.
Х Подробнее о дереве каталогов Ч в главе 1 -Логическая структура Active Directory.
Х Подробнее об устранении неполадок репликации в Active Directory - в главе Выявление и устранение неполадок, а также восстановление Active Directory.
Х Подробнее о репликации Active Directory и восстановлении контроллеров до мена - в главе 9 Архивирование и восстановление данных в Active Directory.
Репликация Active Directory ГЛАВА Модель репликации Active Directory В древовидной структуре каталога Active Directory представлены все объекты леса Windows 2000. Дерево каталога разбито на разделы таким образом, чтобы их мож но было распределить между контроллерами разных доменов в одном лесе. В моде ли репликации Active Directory описан порядок распространения и контроля вы полнения обновлений на контроллерах домена. Каждый контроллер домена в лесе хранит копию определенной части каталога. Отдельные сегменты каталога называ ются разделами каталога (directory partition). Копия содержимого одного раздела каталога на определенном контроллере домена называется репликой (replica). В ходе репликации реплики одинаковых разделов каталога синхронизируются на всех кон троллерах.
Реплики раздела каталога Существует два вида реплик разделов каталога Ч полная (master replica) и частич ная (partial replica), В полной реплике содержатся все атрибуты всех объектов раздела каталога, при этом они доступны не только для чтения, но и для записи (то есть это изменяемая реплика). Каждый контроллер домена храпит по крайней мене три полных изме няемых реплики раздела каталога:
Х раздела схемы (Schema), которая содержит определения всех классов и атрибу тов. Раздел схемы един для всего леса;
Х раздела конфигурации (Configuration), которая содержит информацию о конфи гурации репликации (и другую информацию) всего леса. Раздел конфигурации един для всего леса;
Х реплику раздела домена (Domain), которая содержит все объекты, относящиеся только к данному домену. Раздел домена един и уникален для каждого домена в лесе.
Полная реплика раздела домена хранится на всех контроллерах этого домена (и нигде более);
полные реплики разделов конфигурации и схемы размещаются на всех контроллерах домена леса (и нигде более).
Частичная реплика содержит определенное подмножество атрибутов для каждого объекта раздела каталога и доступна только для чтения. Частичные реплики хра нятся только на серверах глобального каталога (Global Catalog). Атрибут содержит ся в частичной реплике тогда и только тогда, когда у соответствующего объекта класса attributeSchema значение атрибута isMemberOfPartialAttributeSet равно TRUE.
Таким образом, на каждом контроллере домена в единой базе данных хранятся ко пии объектов, относящихся только к данному домену, а также копии объектов схе мы и конфигурации, относящихся ко всем доменам в лесе. В базе данных контрол лера домена, выполняющего роль сервера глобального каталога, также хранятся ча стичные реплики объектов раздела каталога из других доменов. Это позволяет вы полнять поиск объектов единовременно во всем каталоге, не перенаправляя запро сы от контроллера к контроллеру.
9 Зак. 402. Служба каталогов Active Directory 232 ЧАСТЬ Внимание! Следует иметь в виду различие между деревом каталогов (лес Windows 2000) и физической базой данных на контроллере домена. Каталог содер жит все объекты леса, а база данных каталога па каждом отдельном контроллере домена в лесе содержит реплики объектов только данного домена, а также реплики конфигурации и схемы всего леса.
Подробнее о разделах каталогов и о серверах глобального каталогаЧ в главе 2 Хра нение данных в Active Directory. Подробнее о поиске в каталоге Ч в главе 3 Раз решение имен в Active Directory.
Преимущества репликационной модели Далее перечислены основные достоинства модели репликации Active Directory.
Х Active Directory безошибочно реплицирует изменения на требуемый объект и различает удаленные объекты и новые объекты с тем же составным именем (distinguished name). Это вызвано тем, что процесс репликации основан на гло бально уникальных идентификаторах (globally unique identifier, GUID) объек тов каталогов, а не на их именах.
Х Модель репликации минимизирует конфликты при обновлениях и поддержи вает обнаружение и устранение конфликтов на уровне атрибутов. Для обновле ния передаются только атрибуты, значения которых изменились, а не весь объект.
Х Объем данных, передаваемых через глобальные вычислительные сети (wide area network, WAN), сведен к минимуму благодаря поддержке репликации типа со хранить и переслать дальше (store-and-forward replication) и сжатия данных, реплицируемых между сайтами. На серверах хранится только подмножество объектов, состоящее из объектов, относящихся ко всему лесу, и объектов, отно сящихся только к домену, в котором расположен сервер. Серверы глобального каталога хранят сведения обо всех объектах леса, тем не менее они содержат не вес, а только определенное подмножество атрибутов таких объектов.
Х Топология репликации (в том числе выбор транспорта) гибка и позволяет наи лучшим образом использовать самые разнообразные сетевые топологии. Сайты представляют собой линтеллектуальную базу автоматической генерации топо логии репликации, позволяя клиентам выполнять разумный выбор контрол лера домена.
Х Системная конфигурация остается гибкой, потому что сайты не связаны со структурой разделов каталога.
Х Увеличено быстродействие медленных подключений, благодаря минимизации полных циклов репликации.
Х Минимальна зависимость от других служб, например службы синхронизации времени Windows (W32Time).
Компоненты модели репликации Репликация реализуется посредством нескольких механизмов.
Х Свободное согласование с несколькими хозяевами со сходимостью, обеспечива ющее целостность данных.
Репликация Active Directory ГЛАВА Х Согласование с несколькими хозяевами (multimaster consistency) означает, что раздел каталога состоит из множества изменяемых реплик, которые синхро низируются (согласуются) на всех контроллерах домена в одном лесе. Сис тема репликации распространяет изменения, выполненные на одном кон троллере домена, на все остальные контроллеры в лесс, хранящие полную реплику соответствующего раздела каталога.
Х Свободное согласование (loose consistency) означает, что в любой момент вре мени реплики не обязательно согласованы друг с другом, ведь коррективы могут вноситься постоянно.
Х Сходимость (convergence) подразумевает, что, если разрешить системе дос тичь устойчивого состояния, в котором не выполняются новые обновления, а все предыдущие полностью реплицированы, все реплики будут содержать один и тот же набор значений, Х Механизм сохранить и переслать дальше подразумевает, что изменения не пересылаются напрямую с одного контроллера домена на все остальные кон троллеры, Ч обновление напрямую пересылается только на некоторое подмно жество контроллеров домена. Задача дальнейшего распространения обновления возлагается на это подмножество контроллеров домена и так далее, пока изме нение не реплицируется на все контроллеры.
Х Репликация по запросу (pull replication) подразумевает, что контроллеры домена самостоятельно запрашивают обновления у партнеров по репликации. Контрол лер домена, выполнивший изменение, не распространяет его по собственной инициативе.
Х Репликация, основанная на состоянии (state-based replication), когда вместо все го журнала изменений в репликах разделов каталога хранятся данные реплика ции па уровне отдельных объектов и атрибутов.
Репликация с несколькими хозяевами В Active Directory для синхронизации информации каталога применяется репли кация с несколькими хозяевами, В противоположность этой модели в схеме хозя ин - подчиненный (master-slave) все обновления выполняются в основной реп лике каталога и затем реплицируются в подчиненные реплики. Эта система при годна для каталогов с малым числом реплик и для сред, где возможно централизо ванное выполнение всех изменений. Но она не годится для крупных и распреде ленных организаций. В Active Directory нет выделенного главного контроллера домена Ч все контроллеры внутри домена равнозначны. Изменения разрешается выполнять на любом из них, в отличие от системы с одним хозяином, где измене ния должны выполняться только на одном сервере и где главный сервер реплици рует изменяемую информацию на все другие серверы каталогов в домене.
В механизме репликации с несколькими хозяевами контроллер домена не обязан передавать изменения на все остальные контроллеры. Вместо этого в системе под держивается устойчивый набор подключений, определяющий порядок репликации обновлений между контроллерами домена, чтобы сеть не была перегружена трафи ком репликации, в результате чего возможна задержка репликации, что весьма не удобно пользователям. Набор подключений, посредством которых контроллеры домена реплицируют изменения на предприятии, называется топологией реплика ции (replication topology).
234 ЧАСТЬ 1 Служба каталогов Active Directory Обновление с несколькими хозяевами обеспечивает высокую доступность при опе рациях записи в объекты каталога, так как изменяемые реплики объектов хранятся на нескольких серверах. Каждый контроллер домена вправе выполнять обновления независимо, не обращаясь к другим контроллерами домена. Любые конфликты при обновлении объектов каталога система разрешает автоматически. Если не изменять объекты каталога, то при продолжении репликации все копии объекта в конечном итоге станут одинаковыми.
Способ хранения информации в службе каталогов самым непосредственным обра зом влияет на производительность и масштабируемость службы. Службы катало гов обрабатывают больше запросов, чем обновлений: типичное соотношение запро сов к обновлениям Ч 99:1. Создавая несколько копий каталога и поддерживая их в согласованном состоянии, служба каталогов получает возможность обрабатывать больше запросов в единицу времени.
Далее перечислены преимущества репликации с несколькими хозяевами по срав нению с репликацией с одним хозяином:
Х при выходе одного контроллера домена из строя обновление каталога поддер живается оставшимися контроллерами. При репликации с одним хозяином от ключение или неполадка главного контроллера домена делает невозможным последующее обновление каталога. Например, если срок действия Вашего па роля истек, а сервер, на котором хранится информация о пароле, вышел из строя, Вы не сможете сменить пароль, а следовательно, и войти в домен.
Х серверы, которым разрешено выполнять изменения в каталоге (в Windows это контроллеры домена), распределяются в сети и физически располагаются во многих разных местах.
Репликация типа сохранить и переслать дальше Репликация типа сохранить и переслать дальше (store and forward replication) применяется для сокращения времени связи по медленным WAN-подключениям.
Обновление реплицируется сначала в близлежащие реплики, а оттуда Ч далее.
Такая репликация устраняет необходимость пересылать все изменения напрямую с сервера-источника на остальные серверы, поддерживающие реплики соответству ющего раздела каталога. Принявший изменения сервер пересылает изменение на близлежащие серверы. Один из таких серверов переправляет изменения далее на удаленный сервер, который в свою очередь передает их на близлежащие к нему сер веры. Репликация типа сохранить и переслать дальше существенно сокращает трафик репликации по WAN-сетям.
Система в состоянии создавать топологию автоматически, что упрощает админист рирование всех подключений между контроллерами домена. Управление реплика цией выполняется косвенно -- путем определения упрощенной сетевой модели в каталоге. Она оперирует такими понятиями, как сайты, связи сайтов и мосты связей сайтов. На основе этой модели Active Directory автоматически создаст реп ликационпые подключения. При сбоях Active Directory изменяет схему подключе ний, чтобы репликация успешно продолжалась. Разрешается вручную создавать подключения для репликации: они сосуществуют с автоматически сгенерированны ми. Поэтому при создании нового подключения Вам не придется отказываться от удобного автоматического управления остальными подключениями.
Репликация Active Directory ГЛАВА Репликация по запросу В Active Directory применяется репликация по запросу (pull replication), при кото рой реплика-приемник (destination replica) запрашивает информации) у реплики-ис точника (source replica). В запросе определена информация о потребностях серве ра-приемника, основанная на его сведениях об изменениях, уже полученных от сер вера-источника и от остальных контроллеров домена. Получая информацию от сер вера-источника, сервер-приемник на ее основании обновляет свои данные. Впослед ствии сервер-приемник не запрашивает у сервера-источника уже полученные и при мененные обновления.
Альтернативный способ обновления Ч извещающая репликация (push replication), при которой сервер-источник по собственной инициативе пересылает информацию серверу-приемнику для обновления. Извещающая репликация способна создавать проблемы, так как серверу-источнику трудно представить, в какой информации нуждается сервер-приемник. Не исключено, что приемник уже получил эти данные.
Отправляя данные, источник не в состоянии узнать, применены ли они на прием нике. Система может потерять устойчивость, если сервер-источник предполагает, что обновления должны применяться всегда.
Репликация на основе сведений о состоянии В Active Directory управление механизмом репликации выполняется на основе све дений о состоянии: каждый хозяин в системе с несколькими хозяевами применяет обновления к своей реплике при их получении и не ведет журнал изменений.
(СУБД, используемая Active Directory, ведет журнал транзакций, но этот журнал является частью самой СУБД, а не системы репликации.) В типичной журнальной системе репликации каждый хозяин ведет журнал генерируемых им обновлений. В такой системе цель каждого хозяина в том, чтобы передать свой журнал другим хозяевам и применить зарегистрированные в журнале изменения ко всем осталь ным репликам.
Репликация Active Directory базируется не на системе журналов, хранимых вместе с репликой-источником, а на текущем состоянии реплики, то есть на текущих значениях атрибутов всех объектов. К состоянию относится информация, исполь зуемая для разрешения конфликтов и предотвращения пересылки полной реплики в каждом цикле репликации. Каждой исходной операции записи (originating write) контроллер домена присваивает порядковый номер. Вес реплики хранят информа цию о своей свежести по отношению к остальным репликам, и значения в ката логе отмечаются порядковыми номерами исходных записей обновления. На основе этих сведений сервер-источник репликации отбирает изменения состояния, подлг жащие репликации.
В репликации на основе состояния применяется единый механизм для добавочной (incremental) и полной (full) синхронизации, а база данных обновляется реже, так как повторные или конфликтные обновления атрибутов все равно разрешаются в одно состояние, Вообще говоря, все объекты реплики раздела Active Directory хранятся в списке, упорядоченном по дате последней модификации. Фактически это журнал сортироь ки, но очень грубый, и его размер ничтожен по сравнению с размером самой реши. ки. Обычный запрос на репликацию выполняется путем проверки всего несколь 236 ЧАСТЬ 1 Служба каталогов Active Directory ких последних объектов в этом списке, так как серверу-приемнику известно, какая часть списка соответствующего источника репликации уже обработана.
Режим работы репликации Репликация непротиворечива и предсказуема. После внесения определенных изме нений в отдельную реплику можно с уверенностью утверждать, что эти обновле ния распространятся на все другие реплики.
Чтобы понимать, как работает репликация в Active Directory, очень важно знать следующие положения:
Х объект доступен и подлежит репликации, как только он записан (или изменен).
Запись в отдельные объекты латомарна*- (то есть либо выполняется полностью, либо не выполняется вообще), и частичные запись или изменение объектов не разрешены:;
Х объекты не обязательно реплицируются в том порядке, в котором они обновля ются;
Х в цикле обновления пересылаются все доступные изменения из реплики-источ ника в реплику-приемник, в том числе изменения, происходящие во время ре пликации;
Х репликация выполняется в стиле сохранить и передать дальше и охватывает весь набор взаимосвязанных реплик;
Х разрешение конфликтов с несколькими хозяевами очень надежно;
этот механизм действует, даже если нарушится синхронизация часов или они пойдут в обрат ную сторону;
Х граф подключений репликации не всегда является связующим деревом (spanning tree) (которое, по определению, не содержит избыточных связей и петель) этот граф может содержать (и обычно содержит) циклы. Избыточные подклю чения уменьшают задержки репликации, особенно в случае отказов. Механизм демпфирования распространения (propagation dampening mechanism) позволяет устранит избыточную репликацию;
Х репликация внутри сайта инициируется механизмом уведомления об изменени ях в ответ на обновление после короткой задержки, длительность которой раз решается настраивать. Наличие задержки обусловлено тем, что обычно выпол няется сразу несколько обновлений;
Х репликация между сайтами обычно выполняется по заранее определенному рас писанию (уведомление об изменениях между сайтами при этом не требуется);
Х система устойчива к пиковым нагрузкам и временным неполадкам;
Х стабильность заножена в конструкцию системы репликации. Каждое обновление, полученное от источника репликации, делает данные приемника более свежими.
Восстановление после отказа требует совсем немного дополнительной работы:
Х репликация типа сохранить и передать дальше?- позволяет эффективно исполь зовать WAN-каналы связи: каждое обновление передается по дорогостоящему каналу только раз и в сжатом виде;
Х топология репликации управляется автоматически, а имеющиеся подключения оптимизируются.
Репликация Active Directory ГЛАВА Б Microsoft Exchange Server версии 5.5 сайты и репликация применяются несколь ко по-другому, чем в Windows 2000. В таблице 6-1 перечислены существенные раз личия между репликацией в Exchange Server и в Active Directory, Работать с Active Directory, как с каталогом Exchange, неразумно и неэффективно.
Таблица 6-1. Различия между службами каталогов в Windows и в Exchange Server 5. Служба каталогов Windows 2000 Служба каталогов Exchange Server 5. Полные реплики обновляются Каждый объект службы каталогов управляется в отдельном сайте, что определяется по составно независимо, без обращения к му имени этого объекта. В рамках такого сайта другим полным репликам обновления выполняются по механизму с несколькими хозяевами Репликация основана на составных именах, по Репликация основана на GUID этом;
', чтобы избежать проблем, служба Exchange идентификаторах объектов. При Server не переименовывает объекты переименовании объекта его GUID не меняется, в результате чего нет и ошибок репликации Для репликации изменений требуется передать При репликации передаются только весь объект измененные атрибуты Поддерживает сжатие данных, реплицируемых Поддерживает сжатие данных, реплицируемых между сайтами по между сайтами, только по транспорту SMTP транспортам RPC или SMTP На каждом сервере каталогов хранится полная Поддерживает серверы, на которых реплика каталога. (Схема в службе Exchange хранится только подмножество Server индивидуальна для каждого сайта и не объектов всего каталога, а также серверы глобального каталога, реплицируется вовне.) содержащие частичные реплики всех объектов каталога Топология репликации между сайтами ограниче Обладает гибкой топологией репли на связующим деревом, которое не может содер кации (в том числе позволяет инди жать избыточных связей. Репликация информа видуально задавать транспорты ции между сайтами выполняется только по подключений) электронной почте Сведения о сайтах применяются при генерирова Существующие сайты применятся при нии топологии репликации, но сайты также создании топологии репликации и при являются элементами деления каталога на линтеллектуальном выборе реплики разделы клиентами. Однако сайты не привязаны к разделам каталога Обновления Active Directory Репликация обновлений запускается при обновлении пользователем (приложени ем или службой) объектов на контроллере домена. При изменении объектов запус кается таймер, собираются изменения за определенный период времени, после чего механизм репликации уведомляет об изменениях смежные контроллеры домена в топологии репликации в пределах сайта, а также в других сайтах, если активизиро вано уведомление между сайтами. Получив уведомление, контроллер-приемник запрашивает изменения у контроллера-источника. Репликация между сайтами обычно выполняется регулярно: контроллер домена запрашивает изменения у кон троллеров домена в других сайтах согласно заданному расписанию.
Служба каталогов Active Directory 238 ЧАСТЬ Исходные обновления: инициирование изменений Сервер каталогов LDAP поддерживает четыре типа запросов на обновление:
Х добавление объекта в каталог;
Х изменение (добавление, удаление или изменение) атрибутов объектов в каталоге:
Х перемещение объекта путем изменения его составного имени или родителя объекта;
Х удаление объекта из каталога.
Каждый запрос обрабатывается сервером каталогов LDAP как отдельная атомар ная транзакция. Запрос записи либо выполняется полностью, либо отклоняется и вообще не оказывает никакого влияния па каталог. Выполненный и зафиксирован ный запрос на изменение называется исходным обновлением (originating update).
Исходное обновление инициируется и фиксируется в одной определенной репли ке. Коррективы латомарны даже для запросов на изменение, затрагивающих не сколько атрибутов отдельного объекта. В таком случае при сбое обновления хотя бы одного атрибута вся операция отклоняется, и объект не изменяется.
Обновление, выполненное на одном контроллере домена и реплицированное на другой контроллер, называется репликативным обновлением (replicated update).
Система репликации четко различает эти два вида обновлений.
В исходном обновлении учитываются все ограничения схемы (допустимые типы ро дительских объектов для объекта, обязательные и необязательные атрибуты для объек та, синтаксис атрибута), действующий на контроллере домена во время обновления.
Отслеживание обновлений В некоторых службах каталогов для определения того, какие изменения подлежат распространению, применяются метки времени (timestamps). В таких системах важ на синхронизация времени на всех серверах каталогов. Но точная синхронизация в большой сети практически неосуществима: при любом нарушении связи показания часов разойдутся. Неудовлетворительная синхронизация времени между всеми ко пиями каталогов способна повлечь потери данных или нарушение их целостности.
В механизме репликации Active Directory метки времени не применяются при рас пространении изменений. В этом случае используются порядковые номера обновле ний (update sequence numbers, USN), присваиваемые локальным счетчиком кон троллера домена. Счетчики USN работают на локальном уровне, поэтому легко обеспечить их надежность и предотвратить лобратный отсчет номеров обновлений.
Сложность в том, что сравнивать номера USN на разных контроллерах домена бес смысленно. Это ограничение учтено при создании системы репликации.
В некоторых службах каталогов метки времени Ч основной критерий выбора по бедившего обновления при разрешении конфликтов. Обычно в каталог вносится более поздняя запись. Опять-таки, если часы неточны, это проблематично. Пред положим, что при тестировании поведения системы в 2000 году* часы установле ны вперед на 31 декабря 9999 г. и что в ходе теста обновлен атрибут некоего объек та. После завершения тестирования устанавливается текущее время и дата. Если служба каталогов считает приоритетной старшую запись, тестовое обновление не удастся изменить вплоть до 2000 года.
Х По-видимому, этот раздел был написан до 2000 года, поэтому в данном абзаце выражение те кущее вримяв следует трактовать как дату до ;
>тогт> года. Ч Прим. перев.
Репликация Active Directory ГЛАВА В Active Directory метки времени не используются как основной механизм опреде ления приоритета записи при разрешении конфликтов. Вместо этого за основу бе рется число изменений, а метка времени рассматривается в качестве вспомогатель ной величины. Если атрибут обновлен по одному разу на контроллере А и на кон троллере В, в каталог вносится более позднее обновление. Но если атрибут обнов лен дважды на контроллере А и только один раз на контроллере В, применяется обновление контроллера А, независимо от метки времени корректива, выполнен ного на контроллере В Ч даже если часы на контроллере В в тот момент переведе ны далеко вперед. В Active Directory перевод часов не предотвращает перезапись значения.
Репликация изменений с учетом USN Текущий USN Ч это хранимый каждым контроллером домена Active Directory 64 разрядный счетчик. В начале каждой транзакции обновления (исходного или реп ликативного) контроллер увеличивает значение своего счетчика USK и сопостав ляет это новое значение с запросом на обновление. Этот USN сохраняется в двух (для репликативной записи) или трех (для исходной записи) местах обновляемого объекта.
Х USN обновления сохраняется вместе с каждым атрибутом, измененным в этом цикле обновления как локальный USN (local USN) этого атрибута (для исход ных и репликативных обновлений). Узнать локальный USN можно средствами служебной программы командной строки Repadmin. Для этого введите в коман дной строке:
repadmin /shownteta <составное_имя_объекта> В столбце Loc.USN отображен порядковый номер обновления. (Для исполь зования Repadmin установите средства поддержки Active Directory из папки Support\Tools с компакт-диска Windows 2000 Server. Для этого дважды щелкни те значок Setup в этой панке. Подробнее об установке и использовании этих программ и их справочной системы Ч в файле Sreadrne.doc в напке Support\Tools;
об использовании Repadmin Ч в справочной системе Microsoft Windows Support Tools.) Х Максимальный локальный номер USN из всех атрибутов объекта сохраняется как атрибут usnChanged этого объекта (для исходной и репликативной записи).
Для получения сведений об этом атрибуте применяется служебная программа Ldp или ADSI Edit. Ldp Ч программа с графическим интерфейсом, применяе мая для подключения к любому LDAP-совместимому каталогу и выполнения в нем поиска, изменения и удаления объектов. ADST Edit - это оснастка ММС для управления объектами Active Directory, в том числе просмотра и редакти рования атрибутов. (Для получения доступа к Ldp и ADSI Edit, установите средства поддержки Active Directory. Подробнее об использовании Ldp и ADS Edit в справочной системе Microsoft Windows 2000 Support Tools.) Х При создании исходной записи USN обновления сохраняется в каждом обнов ляемом атрибуте как его исходный USN (originating USN). В отличие от локаль ного USN и usnChanged, исходный USN реплицируется вместе с самим атрибу том. Выполнив команду repadmin /showmeta, Вы сможете просмотреть исход ный USN в столбце Org. USN.
Служба каталогов Active Directory 240 ЧАСТЬ Примечание Атрибут usnChanged индексирован, что позволяет без особого тру да нумеровать объекты в порядке времени записи их атрибутов.
Для определения текущего USN контроллера применяется программа Ldp или ADSI Edit. Эти средства считывают в LDAP атрибут highestCommittedUsn объекта rootDSE контроллера домена. (Подробнее об этом в главе 2 Хранение данных в Active Directory.) Наивысший USN Наивысший USN ( high-watermark) Ч это значение, поддерживаемое контроллером приемником для контроля за получением последних изменений определенного объекта от конкретного контроллера-источника. Контроллер-источник использует это значение для отбора объектов, подлежащих репликации на приемник.
Когда сервер-приемник запрашивает изменения в разделе каталога у источника, пос ледний пересылает изменения в порядке увеличения значения атрибута usnChanged, Полученное от источника значение usnChanged приемник в самом объекте не хра нит, но следит за значением usnChanged самых свежих* копий объекта, успешно полученных от контроллера-источника. Такой LJSN называется наивысшим USN источника по отношению к разделу каталога и контроллеру-источнику.
При запросе изменений приемник отправляет значение наивысшего USK источни ку, и тот на основании этих сведений отбирает объекты, которые следует реплици ровать на приемник. В итоге все объект])! со значением usnChanged, меньшим или равным значению наивысшего USN. не реплицируются, поскольку их обновления контроллер-приемник уже получил.
Отбор на основе наивысшего USN позволяет снизить нагрузку на процессор и объем дискового ввода-вывода.
Чтобы узнать значение наивысшего USN, выполните команду:
repadmin /showreps /verbose Наивысшие USN располагаются в строках, начинающихся с USNs> до сочета ния /О U.
Вектор обновления данных Вектор обновления данных (up-to-dateness vector) это значение, которое контрол лер-приемник поддерживает для отслеживания исходных обновлений, полученных от остальных контроллеров-источников. Контроллер-источник использует это зна чение для отбора атрибутов, пересылаемых на контроллер-приемник.
Когда контроллер-приемник запрашивает изменения для раздела каталога, он пре доставляет контроллеру-источнику свой вектор обновления данных. На основе это го значения, контроллер-источник решает, обладает ли приемник самым свежим значением (или набором значений) атрибута, и при необходимости пересылает об новления. Если на источнике нет никаких атрибутов соответствующего объекта, он вообще не возвращает никакой информации об этом объекте.
Вектор обновления данных может содержать записи обо всех контроллерах доме на, на которых хранится полная реплика раздела каталога. Если запись обновле ния данных, соответствующая контроллеру-источнику X, содержит значение USN, равное п, на контроллере-приемнике уже обязательно есть все обновления опреде ГЛАВА б Репликация Active Directory ленного раздела каталога, выполненных на контроллере домена X и имеющих зна чение исходного USN меньшее или равное п.
Вектор обновления данных и наивысший USN Ч это вспомогательные механизмы отбора реплицируемых объектов, совместно позволяющие сократить задержку реп ликации. Наивысший USN предотвращает отправку контроллером-источником лишних объектов на контроллер-приемник, а вектор обновления данных позволяет контроллеру-источнику отбросить лишние атрибуты (или целые объекты) на ос новании сведений об отношениях между источниками исходных обновлений и це левым приемником.
Контроллер домена поддерживает значения наивысших USN определенного разде ла каталога только для тех контроллеров, у которых запрашивает изменения, а за пись вектора обновления данных Ч для всех контроллеров, которые когда-либо являлись источником исходного обновления, то есть фактически для всех контрол леров, хранящих полные реплики данного раздела каталога.
Чтобы получить сведения о векторе обновления данных, выполните команду:
repadmin /showvector Подробнее об использовании служебной программы Repadmin Ч в справочной си стеме Windows 2000 Support Tools.
Разрешение конфликтов на основе меток Предположим, что атрибут некоего объекта изменен на контроллере X. Далее, до репликации данного изменения этот же атрибут того же объекта изменяется на кон троллере Y. Задача Active Directory - обеспечить, чтобы после репликации все реп лики содержали одинаковое значение обновленного атрибута.
Согласование достигается путем прикрепления уникальной метки (stamp) к каж дому реплицированному одно- или многозначному атрибуту в момент исходного его обновления. Эти метки реплицируются вместе с самим атрибутом. Реплициру емое значение заменяет текущее (включая метку), только если его метка больше, чем метка текущего значения.
Метка состоит из трех компонентов:
Х версии (version) Ч ее значение увеличивающаяся па единицу при каждой исход ной записи. У атрибута, который никогда прежде не изменялся, номер версии равен единице;
Х времени неходкой записи (originating time) Ч с точностью до секунды согласно системным часам выполнившего запись контроллера домена:
Х DSА-источника (originating DSA) Ч GUID контроллера домена, выполнившего исходную запись.
Чтобы получить сведения о всех трех составляющих метки, выполните команду:
repadmin /showmeta В столбце Ver указывается версия, в столбце Org. Time/Date Ч время записи, а в столбце Originating DSA DSA-источник (в виде сайт\сервер, а не GUID).
При сравнении меток наибольшим приоритетом пользуется версия, затем Ч время записи и самый низкий приоритет у DSA-источника. Таким образом, при совпаде нии версий сравнивается время записи оно почти наверняка не совпадает, что и Служба каталогов Active Directory 242 ЧАСТЬ решает дилемму. В том чрезвычайно редком случае, когда один и тот же атрибут обновлен на двух различных контроллерах домена в одно и то же время - секунда в секунду, решение о выборе принимается на основе значения DSА-источника, Две разных первичных записи определенного атрибута объекта не могут обладать одинаковыми метками, так как при создании исходной записи увеличивается но мер версии на соответствующем DSA-источнике. (Обратите внимание, что время записи не используется при определении уникальности.) При репликации номер версии не может снижаться, так как значения с меньшими версиями уничтожают ся механизмом разрешения конфликтов.
Подробнее об использовании служебной программы Repadmin Ч в справочной си стеме Microsoft Windows 2000 Support Tools.
Исходное добавление Запрос Add создает новый объект с уникальным атрибутом objectGuid. Всем значе ниям реплицируемых атрибутов присваивается версия 1.
Запрос на создание объекта отклоняется немедленно, если указанный в нем роди тельский объект не существует или если исходный контроллер домена не содержит полной реплики раздела каталога, в котором размещен родительский объект.
Исходное изменение Все запросы Modify сводятся к запросам замены текущего значения атрибута но вым. В частности, запрос на изменение может требовать:
Х удалить атрибута из объекта. Удаление следует рассматривать как замену зна чения атрибута на NULL. Это значение не занимает память, но несет метку, как и любое значение атрибута;
Х добавить значение к текущему набору значений атрибута. (Это наиболее часто используется при работе с многозначными атрибутами.) Этот запрос эквивален тен запросу на замену: текущие значения заменяются текущими значениями плюс добавленное значение.
При выполнении запроса на изменение сравнивается новое значение каждого ат рибута в запросе с существующим значением в объекте. Если значения совпадают, запрос на изменение атрибута игнорируется. Если выполнение запроса не меняет никаких атрибутов, игнорируется весь запрос, В противном случае изменяется версия метки каждого реплицируемого значения атрибута номер версии существующего значения (для атрибутов, которые никог да не записывались номер версии Ч нуль) увеличивается на единицу. Старые зна чения меток заменяются новыми.
Исходное перемещение Запрос Move Ч это на самом деле особый запрос на изменение отдельного атрибу та 'Ч пате. Операция аналогична только что описанному запросу на исходное из менение.
Исходное удаление Запрос Delete Ч это особый запрос па изменение, который выполняет следующие действия:
Репликация Active Directory ГЛАВА 6 1. присваивает атрибуту isDeleted значение TRUE;
2. помечает объект как захороненный (tombstone), то есть объект, удаленный из каталога;
3. изменяет относительное составное имя на значение, которое в обычных обстоя тельствах неприменимо (не может быть присвоено приложением LDAP);
4. удаляет все атрибуты, которые не требуются Active Directory. У захороненного объекта остаются только несколько ключевых атрибутов: objectGuid, objectSid, distinguishedName, nTSecurity Descriptor и usnCkanged;
5. перемещает захороненный объект в контейнер Deleted Objects Ч скрытый кон тейнер в разделе каталога.
Сведения об удалении объектов реплицируется путем репликации захороненных объектов. Захороненный объект невидим при обычном LDAP-поиске Ч для его об наружения надо задействовать специальный элемент управления LDAP с иденти фикатором 1.2.840.113556.1.4.417. Ссылки, ранее указывавшие па удаленный объект, теперь указывают на захороненный объект. Поэтому при чтении такой ссылки воз вращается составное имя захороненного объекта, а не составное имя объекта до его удаления.
Процесс сбора мусора: удаление захороненных объектов Хотя захороненные объекты считаются удаленными, они занимают место в каждой реплике раздела каталога. Поэтому в конечном счете сами захороненные объекты нужно удалять, дабы пресечь неконтролируемое разрастание базы данных катало га. Для этого предусмотрен механизм сбора мусора.
Частоту сбора мусора?- и состав удаляемых захороненных объектов регулируют два параметра объекта cn=Directory Service, cn= Windows NT,cn=Service,cn= период сбора мусора (garbage collection interval) задает частоту проверки нали т чия и удаления захороненных объектов. Его значение по умолчанию Ч 60 дней, а наименьшее допустимое значение Ч 2 дня;
Х время жизни захороненного объекта (tombstone lifetime) определяет время в ча сах, когда объект существует в каталоге в виде захороненного, пока его не унич тожит процесс сбора мусора.
Сбор мусора выполняется независимо на каждом контроллере домена. В процес се сбора мусора окончательно удаляются все захороненные объекты, время жиз ни которых истекло.
Время жизни захороненного объекта должно быть существенно больше наибольшей латентности репликации. В противном случае захороненный объект будет уничтожен до завершения репликации но все реплики. Реплика, не получившая захороненный объект, никогда не сможет удалить его и согласоваться с остальными репликами.
Влияние времени жизни захороненного объекта на восстановление из архива Восстановление из резервной копии создает реплику раздела каталога, не подвер гавшейся репликации с момента архивирования. Если между архивированием и восстановлением прошло больше времени, чем время жизни захороненных объек тов, объекты, удаленные в это время, не имеют захороненных аналогов. Новая реи лика раздела каталога никогда не узнает об этих удалениях. Поэтому восстанови с Служба каталогов Active Directory 244 ЧАСТЬ ние из резервной копии, возраст которой превышает время жизни захороненного объекта, невозможно.
Подробнее о захороненных объектах и сборе мусора - в главе 2 Хранение дан ных в Active Directory. Подробнее о восстановлении Active Directory из резервной копии Ч в главе 9 Архивирование и восстановление данных в Active Directory.
Отслеживание создания, репликации и изменения объектов Приведенные далее диаграммы иллюстрируют изменение репликативных данных объекта и его атрибутов на пути от исходного изменения до репликации.
На рис. 6-1 изображены подлежащие репликации данные объекта пользователь* при его создании на контроллере DC1.
Добавление нового пользователя LJSN: 4710ЧЩ^ USN: Объект: usnCtiangeu. Объект. usnCreated'. Локальный Номер Исходный USN Значение DSA-источник Свойство Время записи USN версии 1 ^ 4711 1999-09-10 10:49.03
Репликация сведений о пользователе ост оса USN: 4711 USN: 1745-ЩЧ - USN: Объект: usnCfisnged: Объект: usnCreated, Номер Локальный Время записи Значение Свойство 05А-!лсточник Исходный USN версии USN СП 1746 1999-09-10 10:49.03
Изменение пароля пользователя USN: USN' Объект;
usnCreated: 1746 Объект: usnChanged: Номер Локальный Свойство Значение Время записи DSA-источнис Исходный USW версии USfJ Jarres Srnilh 1999-09-10 10:49.03
^\ Репликация измененного пароля пользователя DC1 DC USN: 5039 * USN: 5040 USN: Объект: usnChanged: Объект: usnCrealed: Номер Локальный Значение Свойство Время записи DSA-источник Исходный USN версии USN 1999-09-10 10:49.03
Служба каталогов Active Directory 246 ЧАСТЬ Демпфирование распространения изменений Между парой контроллеров домена может существовать несколько путей реплика ции. Это обеспечивает отказоустойчивость и способствует сокращению задержки репликации. У Вас может сложиться впечатление, что при определенных условиях одно изменение способно одновременно пересылаться по всем возможным путям или, того хуже, бесконечно путешествовать по замкнутому кругу подключений между контроллерами. Служба Active Directory предотвращает возникновение та ких ситуаций с помощью описанного выше вектора обновления данных.
Вот типичный пример процесса репликации.
1. Контроллер А обновляет атрибут пароля, присваивая исходному USN атрибута значение 3.
2. Контроллер-приемник В запрашивает изменения у контроллера-источника А и пересылает ему свои наивысший LISN и вектор обновления данных.
3. На основе полученного наивысшего USN контроллер-источник А находит объект с измененным атрибутом пароля и действует следующим образом:
Х выясняет значение DSA-источника атрибута пароля (в данном случае это сам контроллер А);
Х изучив вектор обновления данных, предоставленный контроллером В, обна руживает, что контроллер В уже обладает изменениями, произошедшими на контроллере А, с исходным USN, меньшим или равным 2;
Х выясняет, что значение исходного USN атрибута пароля равно 3;
Х поскольку 3 больше, чем 2, контроллер А отправляет измененный атрибут пароля на контроллер В.
Чтобы проиллюстрировать демпфирование распространения, предположим, что контроллер В ранее уже получил обновление пароля от контроллера С, который в свою очередь получил его от контроллера А. В этом случае запись в векторе обнов ления данных контроллера В для контроллера А содержала бы значение IJSN, рав ное 3, а не 2. Поэтому, контроллер А не отправит измененный пароль на контроллер В.
Политика разрешения конфликтов в среде с несколькими хозяевами Как описано в разделе Разрешение конфликтов на основе меток ранее в этой гла ве, Active Directory разрешает конфликты значений атрибутов, сравнивая их вер сии. Однако рассогласование значений атрибутов Ч не единственный тип возмож ных конфликтов.
Семантика каталогов LDAP обусловливает четыре вида возможных конфликтов при репликации в среде с несколькими хозяевами. Два из них Ч на самом деле лишь разновидности одного и того же конфликта, поэтому мы сократим перечень конф ликтных ситуаций до трех.
Х Конфликт значений атрибута возникает, когда одному атрибуту одновременно присваиваются значения на разных контроллерах домена.
Х Конфликты добавления или перемещения в пределах удаленного родительс кого объекта и удаления контейнерных объектов возникает, когда на одном контроллере последовательно применяются операции добавления и перемете ГЛАВА б Репликация Active Directory ния с целью сделать определенный объект потомком объекта Р, а па другом контроллере объект Р удаляется.
Х Конфликт имен потомков одного родителя возникает, когда на одном контрол лере последовательно применяются операции добавления и перемещения с це лью сделать объект С1 потомком объекта Р, присвоив С1 относительное имя Cl.rdn = R, а в это время на другом контроллере домена выполняется такая же последовательность операций, но с дочерним объектом С2, имеющим идентич ное относительное имя C2.rdn = R.
Эти конфликты возможны в любом каталоге LDAP с несколькими хозяевами.
В Active Directory общий подход к решению этих конфликтов таков: назначается глобальная уникальная (для каждого объекта или атрибута) метка исходному об новлению, чтобы упорядочить все операции обновления (Add, Modify, Move и Delete). При возникновении конфликта упорядочение меток позволяет согласовать каталог. Вот как этот подход применяется для разрешения перечисленных конф ликтов.
Х Конфликт значений атрибута. Пусть V Ч значение из множества {VI, V2] с большей меткой, тогда после разрешения конфликта, значение атрибута на всех контроллерах домена станут одинаковыми и равными V.
Примечание Конфликты разрешаются на уровне всей совокупности значений атрибутов, даже для многозначных атрибутов. После разрешения конфликта ос тается один из наборов значений, а не некая их комбинация.
Х Конфликты добавления или перемещения в пределах удаленного родитель ского объекта и удаления контейнерных объектов. После разрешения конф ликта объект Р удаляется из всех реплик, а его потомки размешаются в специ альном контейнере LostAndFound в разделе конфигурации. В разрешении кон фликтов данного типа метки не используются.
Х Конфликт имен потомков одного родителя. Пусть С Ч объект из множества {Cl, C2}, чей атрибут относительного составного имени имеет меньшую метку.
После разрешения конфликта система назначает на всех контроллерах домена значение C.rdn Ч уникальное для С и гарантировано непротиворечиво любому назначенному клиентом значению. Например, если относительное составное имя объекта С перед разрешением конфликта - ABC, то после разрешения конф ликта оно получит значение ABC*CNF:
Топология репликации Топология репликации Ч это набор подключений, используемых контроллерами домена для синхронизации общих реплик разделов каталога. Топология реплика ции создается на основе информации в Active Directory.
Служба проверки согласованности знаний (Knowledge Consistency Checker, KCC) это встроенный процесс, который выполняется на всех контроллерах домена и со здает топологию репликации в лесе. По умолчанию КСС активизируется с интер валом 15 минут и определяет маршруты репликации между контроллерами домена ЧАСТЬ 1 Служба каталогов Active Directory на основе наилучших доступных подключений. КСС автоматически создает под ключения репликации между контроллерами домена в одном сайте. Если в сети несколько сайтов, вручную создаются только связи сайтов Ч после этого КСС так же автоматически создает подключения между сайтами.
Основные понятия топологии Хотя репликация синхронизирует информацию Active Directory для всего леса кон троллеров, в любой момент времени процесс репликации выполняется между дву мя контроллерами домена. Под созданием топологии репликации подразумевается определение пар партнеров репликации в пределах сайта. При этом подразумева ется, что каждый контроллер домена должен получать обновления от остальных контроллеров домена в лесе, хранящих аналогичные реплики. Если контроллеры доменов в лесе расположены в нескольких сайтах, некоторые из подключений меж ду компьютерами пересекают границы сайтов, и поэтому требуется также создать топологию межсайтовой репликации.
Полная топология фактически состоит из нескольких базовых топологий: по од ной для каждого набора реплицируемых разделов каталога. Следует объединить контроллеры одного домена, хранящие раздел этого домена, кроме того, все кон троллеры домена должны реплицировать разделы схемы и конфигурации. Для раз делов схемы и конфигурации создается отдельная топология. Однако в тех случая, когда подключения для этих разделов каталога между контроллерами домена иден тичны, достаточно одного подключения. Например, если два контроллера домена хранят одинаковый раздел каталога.
Маршруты репликации следующих наборов разделов каталога объединяются для получения общей топологии:
Х конфигурации и схемы в пределах сайта;
Х каждого раздела каталога домена в пределах сайта;
Х хранимых в глобальном каталоге частичных (только для чтения) реплик разде лов в пределах сайта;
Х конфигурации и схемы между сайтами;
Х каждого раздела каталога домена между сайтами;
Х хранимых в глобальном каталоге частичных реплик разделов между сайтами.
Компоненты, относящиеся к топологии Active Directory использует информацию раздела конфигурации для создания и применения топологии репликации. Несколько объектов конфигурации определя ют компоненты, которые требуются для репликации:
Х сайты и относящиеся к ним контроллеры домена;
Х подключения, определяющие маршруты внутрисайтовой репликации между контроллерами домена;
Х подключения репликации между сайтами;
Х транспорты, используемые для взаимодействия между сайтами.
КСС использует эти и другие объекты и их свойства для создания подключений, с помощью которых пересылаются обновления каталога и осуществляется управле Репликация Active Directory ГЛАВА б ние ими, и для определения одного или нескольких контроллеров партнеров дан ного сервера, у которых он запрашивает изменения. Контроллеры домена, репли цирующие данные между собой, ртазываются партнерами репликации (replication partners). При каждом запуске службы КСС (по умолчанию Ч каждые 15 минут) при необходимости состав партнеров автоматически изменяется. Эта операция вы полняется на основе сведений о доступности и взаимном расположении контрол леров домена.
Далее перечислены компоненты, применяемые службой КСС для управления реп ликацией.
Подключения КСС создает подключения, позволяющие контроллерам домена обмениваться данными репликации. Подключение - это односторонний маршрут от одного контроллера домена (источника) к другому контроллеру домена (прием нику). По возможности КСС повторно использует существующие и удаляет неис пользуемые подключения, а также создает новые подключения, если ни одно из существующих не отвечает текущим потребностям.
Серверы каждый контроллер домена представлен объектом сервером. У сер вера есть дочерний объект (NTDS Settings), храпящий входящие подключения;
то есть объекты-подключения для сервера определяют подключения от контроллеров источников к объекту-серверу.
Сайты это подмножества контроллеров домена, объединенных надежной, быст рой и сравнительно дешевой связью. Впутрисайтовая репликация выполняется на основе уведомлений: когда на контроллере домена происходят изменения, он уве домляет о них своих партнеров по репликации. После этого партнеры запрашива ют изменения и запускают репликацию. Поскольку скорость или стоимость репли кации в данном случае несущественны, репликация в пределах сайта выполняется по требованию, а не по расписанию.
Примечание Поскольку при неполадках сети некоторые уведомления теряются, помимо уведомления об изменениях, репликация в пределах сайта по умолчанию выполняется ежечасно.
Репликация между сайтами выполняется по расписанию, которое настраивается на запуск репликации в наиболее выгодное время с точки зрения сетевого трафика и стоимости. Сайт Ч это фактически набор одной или нескольких IP-подсетей.
Примечание Если соединение между двумя сайтами установить в двустороннем режиме невозможно (например, если соединение с сайтом осуществляется только по модему), взаимная репликация обычно инициируется на основе изменений, а не по расписанию. (Подробнее о взаимной репликации Ч в разделе Взаимная репли кация далее в этой главе.) Подсети Ч компьютеры в сетях TCP/IP относятся к сайтам в зависимости от их расположения в подсети или наборе подсетей. В подсети группируются компьюте ры, расположенные вблизи друг друга в сети. Информация о подсети используется в процессе поиска контроллера домена в том же сайте, к которому относится ком пьютер. Эта информация также применяется при репликации Active Directory д л я определения оптимальных маршрутов между контроллерами домена. Подробнее о подсетях в книге Сети TCP/IP. Ресурсы Microsoft Windows 2000 Server (Рус ская редакция, 2001).
250 ЧАСТЬ 1 Служба каталогов Active Directory Связи сайтов Ч для репликации между двумя сайтами требуется установить связь.
Мсжсайтовые связи не создаются автоматически Ч администраторы создают их вруч ную средствами консоли Active Directory Sites and Services (Active Directory сай ты и службы). Без межсайтовой связи КСС не в состоянии автоматически создать подключения между компьютерами разных сайтов, и репликация между сайтами невозможна. Каждая межсайтовая связь содержит расписание, определяющее, ког да выполняется репликация между сайтами. Средства Active Directory Sites and Services обеспечивают включение каждого сайта по крайней мере в одну связь сай тов. Эта связь может содержать больше двух сайтов, в этом случае все эти сайты должны быть связаны каналами связи одинаковой емкости.
Серверы-плацдармы для взаимодействия через связи сайтов служба КСС авто матически назначает в каждом сайте один сервер-плацдарм (bridgehead server). Он и только он отвечает за репликацию между сайтами. Все остальные операции реп ликации выполняются внутри сайта. При настройке межсайтовых связей разреша ется назначать серверы-плацдармы. Это позволяет администратору воспользовать ся наиболее выгодными условиями подключения между сайтами. Механизм серве ров-плацдармов гарантирует, что максимальные потоки данных репликации пере сылаются внутри, а не между сайтами.
Мосты связей сайтов Ч когда более двух сайтов связано для репликации и исполь зуют один и тот же транспорт, все связи сайтов по умолчанию объединяются в мо сты одинаковой стоимости (при этом у связей должны быть общие сайты). Связи, объединенные в мосты, Ч траизитивиы (transitive). To есть все связи сайтов для определенного транспорта неявно принадлежат единственному межсайтовому мос ту для этого транспорта. Так в случае полностью связной IP-сети (fully routed) (где все сайты связаны друг с другом по протоколу IP) не нужно конфигурировать ни какие мосты связей сайтов. Если сеть IP связна лишь частично, Вы вправе отклю чить транзитивность связи для транспорта IP, сбросив флажок Bridge all site links (Установить мост для всех связей сайтов) на вкладке General (Общие) в окне свойств объекта межсайтового транспорта IP или SMTP. В этом случае все связи сайтов IP рассматриваются как нетранзитивные, и Вы вправе самостоятельно скон фигурировать мосты связей сайтов. Мост связей сайтов Ч это эквивалент раздель ной сети: все связи в пределах моста транзитивны, но они не выходят за пределы моста.
Иерархия контейнеров объектов-сайтов в Active Directory Active Directory Sites and Services (Active Directory Ч сайты и службы) Ч админист ративная консоль, применяемая для просмотра иерархии используемых КСС объек тов и управления ею для настройки топологии репликации. Иерархия отображается в структуре контейнера Sites Ч потомка контейнера Configuration. Составное имя контейнера Sites Ч cn=Sites,cn=Configuration,dc=<л,лfl_KO/7Keeo?o_5oJMea_.'7ecG>.
Контейнер Configuration объект наивысшего уровня в разделе конфигурации, а контейнер Sites Ч в иерархии объектов, используемых для управления и выполне ния репликации Active Directory. Далее перечислены объекты во внутренней иерар хии контейнера Sites.
Х Контейнер Sites содержит объекты, каждый из которых представляет отдельный сайт в лесе. Кроме объектов сайт, в этом контейнере есть подкоптейнер Subnets, содержащий определения подсетей в форме объектов подсеть. Каждый объект подсети обладает атрибутом siteObject, связывающим его с объектом сайта.
Репликация Active Directory ГЛАВА 6 Х Объекты-сайты содержат но два дочерних объекта:
объект NTDS Site Settings, хранящий свойства каталога, общие для всех кон Х троллеров домена в сайте, в том числе расписание внутрисайтовой реплика ции;
контейнер Servers, хранящий объекты-серверы всех контроллеров доменов Х в сайте.
Х Объекты-серверы каждый из них содержит объект NTDS Settings.
Объект NTDS Settings представляет экземпляр Active Directory на этом серве Х ре. (Когда служба Active Directory удаляется с сервера, ее объект NTDS Settings удаляется из Active Directory, но ее объект-сервер остается.) Для определенно го объекта-сервера объект NTDS Settings содержит отдельные объекты-подклю чения, представляющие входящие подключения с других контроллеров домена в лесе, доступные в настоящее время для получения изменений данным контрол лером домена.
Х Объекты-подключения каждый из них представляет однонаправленное согла шение о репликации между парой контроллеров домена, где контроллер-прием ник - объект-сервер, являющийся родительским объектом NTDS Settings, хра пящим подключение. Объекты-подключения автоматически создаются КСС. Их также разрешается создавать вручную.
На рис. 6-5 изображен раскрытый контейнер Sites. Для сервера выбран объект NTDS Settings, а связанные объекты-подключения отображены в правой панели, В столбце From Server отображаются имена контроллеров домена, от которых выб ранный контроллер принимает данные репликации (имена его текущих партнеров по репликации).
SefaJt First-Sts-Namft First-Site-Name Dzlsj First-Site-Name Ji Рис. 6-5. Иерархия объектов в контейнере Sites Подробнее о создании и управлении объектами в контейнере Sites Ч в справочной системе Microsoft Windows 2000 Server.
252 ЧАСТЬ 1 Служба каталогов Active Directory Сайты и репликация Сайт (site) Ч это область сети с однородным высоким качеством доступа, который обычно соответствует качеству связи в LAN. Такие связи предполагают широкую недорогую полосу пропускания, обеспечивающую воспроизводимую и надежную ра боту сети между любыми компьютерами в сайте. Это не означает, что все серверы сайта обязательно расположены в одном сетевом сегменте или что число переходов между любыми парами серверов одинаковы. Скорее это такая связь, при наличии которой все равно, какие серверы задействованы при копировании большого коли чества данных между ними. Если это не так, следует создать отдельный сайт.
Эффективность репликации Ваутрисайтовая репликация инициируется изменениями. Высокая скорость и на дежность локальной сети позволяют передавать данные по запросу. Механизм реп ликации инициируется при выполнении изменения в определенной реплике. Он ожидает определенное (настраиваемое) время (по умолчанию 5 минут) и затем уведомляет первого партнера по репликации. Каждый последующий партнер уве домляется после заданной задержки (по умолчанию Ч 30 секунд).
Топология внутри сайта формируется с использованием минимально возможного количества подключений. Стандартная топология репликации в сайте Ч двунаправ ленное кольцо с дополнительными подключениями, необходимыми для сохранения количества переходов между партнерами по репликации равным трем или меньше.
В результате стандартная задержка распространения внутри сайта в худшем случае соответствует максимальному количеству переходов между источником и контрол лером-приемником (3 перехода) умноженному на задержку на каждом контролле ре домена в пути (5 минут), то есть 15 минут для трех переходов, Расписание репликации между сайтами составляется так, чтобы обеспечить воз можность управлять затратами репликации и предотвращать переполнение кана лов связи трафиком репликации. Существует много факторов, влияющих на ско рость репликации, в том числе Ч характер физических соединений и их стоимость.
Active Directory поддерживает подключения сайтов по каналам разной емкости: от коммутируемых линий до линий ТЗ. На основании производительности канала свя зи назначается стоимость связей между сайтами, а механизм репликации на основе стоимостных показателей выбирает самый дешевый маршрут для трафика репли Х ai ни Подробнее о планировании сетей в книге Microsoft Windows 2000 Server Deployment Planning Guide (Microsoft Press, 2000).
Разработка сайта с учетом репликации В сайт объединяют IP-подсети, обладающие высокой емкостью, объединенные в ЛВС или связанные быстрыми маршрутизаторами.
Отдельный домен может охватывать несколько сайтов, а отдельный сайт Ч содер жать несколько доменов. Архитектура домена не должна зависеть от структуры сай тов: сайты первичны, но не оказывают исключительного влияния на процесс поис ка ближайшего контроллера домена и инфраструктуру репликации. Универсально го правила, когда следует размещать две подсети в одном сайте, нет: важно пони мать, как служба Active Directory использует информацию о сайтах.
Репликация Active Directory ГЛАВА 6 Х Когда клиент запрашивает соединение с контроллером домена (например, при входе в систему), сайты позволяют найти контроллер домена с хорошей связью.
Быстрые подключения уменьшают задержки и снижают нагрузку на сеть.
Х Когда служба КСС конфигурирует подключения репликации между контролле рами, она создает больше подключений между контроллерами в одном сайте, чем между контроллерами в разных сайтах. В результате снижается задержка реп ликации в пределах сайта и нагрузка на канал связи между сайтами.
Х Данные репликации, пересылаемые между контроллерами домена внутри сайта, передаются несжатыми, что снижает нагрузку па процессоры контроллеров до мена. При репликации между контроллерами домена в разных сайтах данные сжимаются, что снижает нагрузку на канал межсайтовой связи.
Х Репликация между контроллерами домена внутри сайта инициируется обнов лениями, что уменьшает задержку репликации в пределах сайта, а репликация между разными сайтами выполняется по расписанию, чтобы меньше загружать канал связи между сайтами.
Сайты никак не связаны с пространством имен Active Directory, используемом раз делами каталога домена. Имена объектов каталога не связаны с сайтами, в которых они хранятся.
Примечание В службе каталогов Exchange Server сайты связаны с пространством имен.
Иерархия в контейнере Sites отражает имена объектов внутри раздела конфигура ции, где имена сайтов отображаются в соответствии с их составными именами Б иерархии контейнера конфигурации.
Подробнее о планировании сайтов и топологии сайтов для Active Directory Ч в книге Microsoft Windows 2000 Server Deployment Planning Guide (Microsoft Press, 2000).
Сопоставление подсетей сайтам В процессе планирования в сайты объединяются подсети, обеспечивающие хоро шую связь для репликации. Для этого средствами консоли Active Directory Sites and Services создаются подсети, затем Ч сайты, и после этого подсети сопоставля ются сайтам. Для создания сайта требуется создать соответствующий ему объект в Active Directory, а затем определить набор относящихся к данному сайту подсетей.
Компьютер относится к сайту, если его ТР-адрес сопоставлен объекту-подсети в Active Directory. В стандартном каталоге пет заданных объектов-подсетей, поэтому компь ютер в лесе может относиться к IP-подсети, не относящейся ни к одному сайту. В частных сетях Вы вправе задать сетевые адреса, предоставленные Агентством по вы делению имел и уникальных параметров протоколов Интернета (Internet Assigned Numbers Authority, IANA). По определению этот диапазон охватывает все подсети организации. Впрочем, при наличии нескольких адресов класса В или С необходимо создать несколько объектов-подсетей, соответствующих одному и тому же сайту по умолчанию. В этой ситуации рекомендуется использовать следующие подсети:
Х подсеть 128.0.0.0/2, которая охватывает все адреса класса В;
Х подсеть 192.0.0.0/3, которая охватывает все адреса класса С.
254 ЧАСТЬ 1 Служба каталогов Active Directory Подробнее о подсетях и масках подсетей Ч в книге Сети TCP/IP. Ресурсы Microsoft Windows 2000 Server (Русская Редакция, 2001). Подробнее о создании подсетей и назначении масок подсетей - в справочной системе Microsoft Windows 2000 Server;
о проектировании сети и сайтов Active Directory - в книге Microsoft Windows Server Deployment Planning Guide (Microsoft Press, 2000).
Когда следует создавать новый сайт Если сегменты сети связаны медленными каналами, рекомендуется создать два сай та и разместить контроллеры домена в сайтах в соответствии с определенными об щими правилами:
Х в каждом сайте развертывают по крайней мере один глобальный каталог;
Х серверы DNS развертывают на уровне сайтов.
Первый контроллер домепа в лесе автоматически становится сервером глобально го каталога. Для создания в дополнительных сайтах серверов глобального каталога в консоли Active Directory Sites and Services (Active Directory Ч сайты и службы) следует установить флажок Global Catalog (Глобальный каталог) на странице свойств объекта XTDS Settings соответствующего сервера. Наличие сервера гло бального каталога в каждом сайте повышает эффективность поиска, поскольку при поиске в глобальном каталоге граница сайта не пересекается. Кроме того, сервер глобального каталога необходим для входа в домен: при нарушении соединения между сайтами вход в систему невозможен, Примечание Если сервер глобального каталога в ближайшем сайте недоступен, вой ти в сеть разрешается через сервер глобального каталога в удаленном сайте. Если все глобальные каталоги недоступны, вход в систему выполняется на основе ин формации из кэша.
Доступность DNS самым непосредственным образом влияет на доступность Active Directory, Поиск контроллера домена выполняется с помощью DNS, средства DNS также применяются контроллерами для поиска друг друга. В общем случае реко мендуется создать по крайней мере один сервер DNS в каждом сайте.
При создании сайтов и размещении в них серверов нужно сформировать подклю чения между сайтами и сконфигурировать эти связи с учетом характеристики сети, то есть частоты репликации по данному каналу связи, Подробнее о планировании сайтов и о контроллерах домена, серверах DNS и раз мещении сервера глобального каталога - в книге Microsoft Windows 2000 Server Deployment Planning Guide (Microsoft Press, 2000). Подробнее о серверах глобаль ного каталога в главе 1 Логическая структура Active Directory.
Сайт по умолчанию В процессе установки Active Directory на первом контроллере домена в сайте, в контейнере Sites создается объект Default-First-Site-Name. Первый контроллер до мена обязательно устанавливается в этот сайт. Последующие контроллеры устанав ливаются либо в сайт первого контроллера (если его IP-адрес сопоставлен этому сайту), либо в один из уже существующих сайтов. После установки первого кон троллера домена имя Default-First-Site-Name разрешается изменить.
Если в Active Directory определены другие сайты и IP-адрес устанавливаемого но вого контроллера домена соответствует существующей подсети в определенном сай Репликация Active Directory ГЛАВА б тс, новый контроллер размещается в этом сайте. В противном случае он размеща ется в сайте первого контроллера.
Подробнее о способах размещения новых контроллеров домена в сайтах Ч в гла ве 2 Хранение данных в Active Directory.
Подключения серверов и сайтов Репликация выполняется между контроллерами домена в одном сайте и между сер верами-плацдармами в разных сайтах. Подключения репликации внутри сайта все гда автоматически создаются КСС (либо вручную, хотя обычно этого не требует ся). Если в сети несколько сайтов, между ними надо создать связи. При наличии связи между сайтами служба КСС также создает подключения между двумя серве рами-плацдармами Ч но одному в каждом сайте для каждого домена, у которого в этом сайте есть контроллеры. Если сайт содержит много доменов и у каждого до мена есть контроллеры в разных сайтах, в сайте будет несколько серверов-плацдар мов, поскольку контроллеры в одном домене должны соединяться только с серве рами того же домена. КСС выбирает серверы-плацдармы автоматически. Если Бы хотите, чтобы одни и те же серверы всегда использовались как серверы-плацдар мы, назначьте их вручную.
Транспортные протоколы репликации определяют, как данные репликации переда ются по сетевым носителям, а доступные транспорты определяет сетевая среда.
Объекты-серверы При установке Active Directory на компьютере с Windows 2000 Server создается объект-сервер, представляющий этот контроллер домена. Он отличается от объек та-компьютера, представляющего компьютер как участника безопасности. Эти объекты хранятся в разных разделах каталога: объект-компьютер представляет кон троллер домена в разделе домена, а объект-сервер - в разделе конфигурации.
Объект сервера содержит ссылку на соответствующий ему объект-компьютер, Объекты сервер Ч потомки объектов-сайтов. Родительский сайт сервера должен содержать подсеть сервера. Если IP-адрес контроллера домена или сопоставление подсетей сайтам изменятся после установки Active Directory па сервере, автомати чески границы сайта контроллером домена не обновляются - Вам придется перг местить контроллер в новый сайт вручную.
Перед перемещением контроллера домена в другой сайт следует обязательно пред варительно создать связь сайтов. Ксли репликация между сайтами выполняется по протоколу SMTP, чрезвычайно важно сначала правильно сконфигурировать кон троллер домена в сайте, поддерживающем протокол RPC поверх IP.
Примечание При изменениях конфигурации, влияющих на репликацию, эти и зли нения реплицируются на основе старых параметров настройки репликации, пока они не достигнут целевых систем, где вступят Б силу. Репликация между сайтами не происходит, пока:
Х где-то в каталоге не создана связь сайтов;
Х это изменение не реплицировано на систему в сайте, ответственную за создание межсайтовой топологии (подробнее о создании межсайтовой топологии Ч в раз деле Автоматическое создание межсайтовой топологии далее в этой главе);
Х служба КСС в утой системе не сработала и не создала новые подключения;
Служба каталогов Active Directory 256 ЧАСТЬ Х новые подключения не реплицированы на сервер-плацдарм;
Х служба КСС на сервере-плацдарме не сработала и не преобразовала сняли в под ключения с партнерами по репликации;
я на сервере-плацдарме не выполнена репликация.
Подключения серверов Служба КСС создаст подключения для всех контроллеров домена, у которых есть соответствующий объект-сервер в контейнере Sites. Эти объекты-подключения оп ределяют одностороннюю связь с текущей системой со стороны другой системы.
Объект-подключение Ч потомок объекта NTDS Settings на контроллере-приемни ке репликации;
он ссылается на контроллер-источник репликации в атрибуте fromSeruer, то есть представляет входящую половину подключения. В объекте-под ключении указано расписание и транспорт репликации.
Объекты-подключения создаются двумя способами:
Х автоматически средствами КСС;
Х вручную администратором каталога средствами консоли Active Directory Sites and Services (Active Directory Ч сайты и службы), ADSI Edit или с помощью сценариев.
Подключение - однонаправлено;
двунаправленное подключение репликации пред ставляется как два объекта подключения под двумя разными объектами NTDS Settings.
Владение объектами подключения Автоматически созданные КСС подключения принадлежат КСС. Аналогично, если администратор создает повое подключение или изменяет существующее, то владельцем подключения становится администратор. Служба КСС не меняет и не удаляет подключения, владельцем которых не является. Цель создания или изме нения объекта-подключения в том, чтобы сохранить объект в виде, каким он со здан. Владение защищает объект от изменения со стороны КСС.
Примечание Владение подключением не влияет на доступ к объекту;
оно лишь за прещает КСС изменять или удалять объект.
Владение определяется значением атрибута options объекта-подключения. Если это значение (а точнее результат применения операции поразрядное ИЛИ к этому значению и единице) равно 1, подключением владеет КСС. Если админист ратор изменит созданное службой КСС подключение, значение options изменит ся. У вновь созданных администратором объектов подключения, значение атри бута options равно 0.
Передать владение созданным КСС объектом-подключением администратор может средствами консоли Active Directory Sites and Services (Active Directory сайты и службы). Когда изменения будут реплицированы, значение атрибута options изме нится, информируя, что КСС больше не владеет объектом. Подробнее о создании объекта-подключения Ч в справочной системе Microsoft Windows 2000 Server, Репликация Active Directory ГЛАВА 6 Примечание Если КСС автоматически создает подключения, то, как правило, вруч ную создавать их не требуется. КСС автоматически переконфигурирует подключе ния, когда условия изменяются. Добавление подключения вручную при использо вании КСС иногда увеличивает трафик репликации за счет добавления избыточ ных подключений к оптимальному набору, созданному КСС. Если имеются подклю чения, созданные вручную, служба КСС использует их везде, где возможно.
Расписание подключений Для каждого объекта-подключения КСС автоматически задает расписание в ходе настройки оптимального маршрута репликации. Расписание подключения опреде ляет частоту периодической репликации. Минимальный интервал в расписании подключения 15 минут. По умолчанию для репликации в пределах сайта интер вал в расписании Ч 1 час. Этот параметр можно изменить в объекте KTDS Site Settings. Средства консоли Active Directory Sites and Services (Active Directory сайты и службы) позволяют Вам задать расписание без репликации, раз в час (по умолчанию), дважды в час или четыре раза в час.
Примечание Средства Active Directory Sites and Services позволяют задавать пери одичность репликации с дискретностью 15 минут на протяжении определенных часов (от 1 до 24 часов) в течение педели. Средствами ADSI Edit или сценария Вы можете управлять репликацией более точно.
Создавая новое подключение, служба КСС назначает ему расписание, указанное в объекте NTDS Site Settings. Стандартное расписание для объекта NTDS Site Settings можно настроить вручную.
Примечание Ручное переопределение действует только для объектов, созданных вручную. Если Вы пытаетесь обновить расписание для объекта, принадлежащего КСС, при следующем своем запуске КСС восстановит прежнее расписание.
КСС назначает расписание подключения между сайтами па основании расписания связи сайтов, которое определяет частоту активности этой связи. По умолчанию репликация между сайтами происходит каждые 3 часа. Этот параметр можно изме нить, настроив соответствующий(е) объскт(ы) связи сайтов.
В пределах сайта репликация инициируется изменениями: если происходит обнов ление каталога, репликация начинается автоматически (контроллер домена уведом ляет об этом своих партнеров по репликации) через заданный интервал (по умол чанию 5 минут). Если изменения отсутствуют в течение времени, указанного в расписании объекта-подключения, репликация инициируется (контроллер домена запрашивает изменения у партнеров по репликации) по расписанию (по умолча нию Ч ежечасно).
Расписание важно при межсайтовой репликации, где оно - главный механизм за пуска репликации. Поскольку минимальный интервал расписания объекта-подклю чения 15 минут, не удастся настроить репликацию между сайтами чаще, чем каж дые 15 минут.
Связь между репликами разделов каталога Репликация выполняется между репликами раздела каталога, для чего между сер верами создаются подключения, применяемые для репликации всех общих раздс Служба каталогов Active Directory 258 ЧАСТЬ лов каталога у каждой пары серверов. Дна контроллера домена в одном лесе всегда обладают по крайней мере двумя общими разделами каталога: конфигурации и схе мы. У контроллеров одного домена есть еще один общий раздел Ч домена. У кон троллеров Ч серверов глобального каталога одного леса Ч общие частичные реп лики разделов всех доменов леса, если же они находятся в одном домене, у них так же общий полный раздел домена.
Существующее подключение двух контроллеров домена используется для репли кации всех общих разделов каталога для этих двух серверов. КСС никогда не CQ здает несколько подключений, связывающих два одинаковых контроллера домена в одном направлении.
Связи сайтов В системе с двумя и более сайтами следует создать межсайтовые связи, по кото рым будет выполняться межсайтовая репликация. В Active Directory объект связи сайтов определяет набор сайтов, которые взаимодействуют друг с другом по опре деленному протоколу по подключениям с одинаковой стоимостью. Связи сайтов используются службой КСС для создания топологии репликации. Обычно этим связям присваивают имена соединяемых ими сайтов. Например, если у Вас есть сайты с именами New York и London, назовите их связь NY-London, Связи сайтов также определяют стоимость связи, от которой зависит возможность использования удаленных сайтов как источников информации репликации. Кроме того, связи сайтов определяют расписание периодической репликации и парамет ры, влияющие на способ репликации.
По умолчанию связи сайтов, у которых есть общие сайты, для одинакового IP транспорта соединены мостами, позволяющими КСС обрабатывать набор связей сайтов как один маршрут.
Серверы-плацдармы Плацдарм - это точка входа или выхода подключения в/из сайта. Серверы, у которых есть объекты подключений между сайтами, называются серверами-плац дармами (bridgehead servers). Любой сервер, у которого есть объект подключения с сервером-источником в другом сайте, считается приемником-плацдармом. Любой сервер, действующий как источник для подключения с другим сайтом, является источником-плацдармом. КСС генерирует подключения и заставляет контроллеры домена, хранящие подключения между сайтами, выполнять в топологии роль плац дармов.
Если требуется ограничить выбор серверов-плацдармов для КСС (то есть ограничить контроллеры домена, на которых КСС разрешено создать подключения между сай тами), выберите один или несколько контроллеров домена в сайте, которые КСС все гда должна рассматривать как основные (лпредпочтительные) серверы-плацдармы.
Эти серверы используются исключительно для репликации изменений, накопивших ся в сайте. Выбирая основные серверы-плацдармы, следует иметь в виду, что;
Х Вы ограничиваете способность службы КСС обращаться к другому серверу плацдарму, когда назначенный сервер отключается;
Х Вы должны назначить один сервер-плацдарм для каждой пары домен пол ный раздел каталога в Вашем лесс, что может оказаться невозможным в круп ной организации.
ГЛАВА б Репликация Active Directory Транспорты репликации Транспорты репликации поддерживают протоколы обмена (wire protocols) для пе редачи данных. Windows 2000 предусматривает три типа транспортов для реплика ции информации Active Directory:
Х надежная быстрая связь (лRPC поверх IP для репликации всех разделов ката логов внутри сайта);
Х синхронная медленная связь типа точка точка (лRPC поверх IP для реп ликации всех разделов каталогов между сайтами);
Х почтовая асинхронная связь (лSMTP поверх IP для репликации только не-до менпых разделов каталогов между сайтами).
Применение транспортов репликации регулируется определенными правилами:
Х для репликации внутри сайта используются транспортные протоколы т г-н а RPC поверх IP;
Х для межсайтовой репликации применяются два транспортных протокола: IP (RPC поверх IP) и Simple Mail Transfer Protocol (SMTP поверх IP);
Х репликация между сайтами но SMTP поддерживается только для контроллеров разных доменов. Контроллеры одного домена выполняют репликацию по про токолу RPC поверх IP. Поэтому репликация между сайтами по SMTP под держивается только для разделов схемы и конфигурации, а также репликации глобального каталога, что означает, что домены могут располагаться в несколь ких сайтах, только если между сайтами удастся соединиться но синхронному механизму RPC типа точка Ч точка.
Контейнер Inter-Site Transports позволяет сопоставлять связи сайтов транспорту, используемой связью. Объект связи сайтов создается в контейнере IP (который сопоставляет связь сайтов транспорту RPC поверх IP) либо в контейнере SMTP (который сопоставляет связь сайтов транспорту SMTP).
Синхронная и асинхронная связь В механизме репликации Active Directory синхронная связь подразумевает, что по сле отправки запроса контроллер-приемник ожидает, пока контроллер-источник не получит запрос, не сформирует и не отправит ответ;
в это время приемник не пы тается запросить изменения у любых других контроллеров домена. Поэтому в лю бой момент времени у контроллера домена имеется не более одного синхронист > текущего запроса, Асинхронная репликация подразумевает, что контроллер-приемник не ждет отгзети и способен единовременно инициировать несколько асинхронных ожидающих зап росов. Таким образом, синхронная передача подразумевает быстрый ответ, а асинх ронная Ч не обязательно.
Транспорт для репликации внутри сайта Вся репликация внутри сайта выполняется по синхронному транспорту RPC по верх IP. Главное при репликации внутри сайта Ч быстрая, без сжатия поставка обновлений. События репликации чаше происходят внутри сайта, чем между сай тами, и при быстром соединении неразумно тратить ресурсы на сжатие.
260 ЧАСТЬ 1 Служба каталогов Active Directory Примечание Данные репликации, передаваемые между сайтами, сжимаются.
Но умолчанию при репликации на основе RPC применяется динамическая привяз ка портов. При соединении с конечной точкой RPC в ходе репликации Active Directory RFC-клиент обращается к распределителю конечной точки RPC на сер вере через стандартный порт (порт 135). Сервер опрашивает локатор RPC через этот порт, чтобы определить какой порт назначен для репликации Active Directory на сервере. Этот запрос выполняется независимо от того, назначен ли порт дина мически (значение но умолчанию) или фиксирован. Поэтому клиенту не нужно знать, какой порт использовать для репликации Active Directory.
Примечание Конечная точка содержит протокол, локальный адрес и адрес порта.
Active Directory регистрирует конечную точку при запуске, и она использует либо ди намически назначенный, либо указанный порт. Для настройки порта для сред с марш рутизацией или с фильтрацией по порту используется параметр реестра TCP/IP Port в разделе HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\ Services\ NTDS\Parameters. Этот параметр применяется для конфигурации Active Directory для регистрации определенного порта на распределителе конечной точки. Разреша ется назначать помер любого действительного порта TCP/IP > Настройка параметра TCP/IP Port 1. Б редакторе системного реестра, перейдите в раздел HKEY_LOCAL_MACHI NE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters.
2. Дважды щелкните значок параметра TCP/IP Port и назначьте действительный номер порта.
3. Закройте редактор системного реестра.
Внимание! Не модифицируйте реестр самостоятельно (с помощью редактора реес тра) Ч делайте это лишь в крайнем случае, когда другого выхода нет. В отличие от инструментов управления редактор реестра обходит стандартные средства защиты, призванные не допускать ввода конфликтующих значений параметров, а также спо собных снизить быстродействие системы или разрушить ее. Не исключено, что по следствия прямого редактирования реестра окажутся не такими, как Вы ожидали, и, возможно, Вам придется переустанавливать Windows 2000. Для настройки и кон фигурирояания Windows 2000 рекомендуется использовать Control Panel (Панель управления) или Microsoft Management Console (Консоль управления Microsoft), Перед изменением реестра советуем делать резервную копию. Подробнее о редакти ровании параметров реестра в справочной системе редактора реестра. Подробнее о реестре Ч в техническом руководстве Technical Reference Microsoft Windows Professional Resource Kit (файл Regentry.chm).
Транспорт для репликации между сайтами Windows 2000 поддерживает два стандартных транспорта репликации между сай тами:
Х RPC поверх TCP/IP (в пользовательском интерфейсе средств администриро вания отображается просто как IP) - обеспечивает низкоскоростиую синхронную репликацию между всеми разделами каталога по механизму точка точка;
Репликация Active Directory ГЛАВА б Х SMTP поверх IP (в пользовательском интерфейсе средств администрирова ния отображается как SMTP) Ч предназначен для низкоскоростной асинхрон ной репликации разделов схемы, конфигурации и глобального каталога, но не разделов домена, Когда сайты соединены WAN-связью (или через Интернет), не всегда рационально (а иногда просто невозможно) выполнять синхронную репликацию каталога по транспорту RPC. Иногда единственный способ связи между двумя сайтами - элек тронная почта. Для поддержки таких конфигураций репликацию следует выпол нять с применением асинхронных транспортов тина сохранить и переслать, на пример SMTP.
Репликация SMTP заменяет транспорт RPC передачей почтовых сообщений. При этом синтаксис сообщения Ч тот же, что и для репликации на основе RPC. При реп ликации на основе SMTP уведомления об изменениях не передаются, а информация о расписании в объекте связи сайтов используется следующим образом:
Х репликация SMTP игнорирует переключатели Replication Available (Реплика ция доступна) и Replication Not Available (Репликация недоступна) в расписа нии связи сайтов в консоли Active Directory Sites and Services;
Х репликация SMTP использует интервал репликации, чтобы указать, как часто сервер запрашивает изменения. Интервал (Replicate every... minutes (Репли цировать каждые... мин)] задается в почасовых интервалах на вкладке General (Общие) окна свойств связи сайтов в консоли Active Directory Sites and Services.
В совокупности параметры формируют расписание репликации для объекта-под ключения. За маршрутизацию сообщения между серверами SMTP отвечает базо вая система передачи сообщений SMTP Служба Intersite Messaging (ISM) позволяет добавлять (лнадстраивать) в архитек туру ISM другие транспорты. ISM предоставляет услуги для КСС в форме запроса доступных путей репликации. ISM может передавать сообщения от серверов SMTP, которые не выделены для работы с приложениями электронной почты, как, напри мер. Exchange Server.
Сравнение репликации по SMTP и RPC С точки зрения механизма репликации Active Directory перечисленные далее ха рактеристики относятся как к SMTP, так и к RPC:
Х при репликации между сайтами данные сжимаются;
Х объем изменений, возвращамых Active Directory в ответ на запрос, ограничен и определяется размером пакетов репликации. Размер пакетов репликации настра ивается (подробнее об этом Ч в разделе Размер пакетов репликации далее в этой главе);
Х в Active Directory разрешается только один ожидающий запрос изменений для данного раздела каталога к конкретному партнеру по репликации;
Х данные ответа (изменения) передаются в одном или нескольких кадрах в зави симости от общего количества измененных или новых значений;
Х алгоритм передачи порций данных по TCP одинаков для SMTP и RPC;
Х любой сбой передать порцию данных вызывает повтор всей передачи;
Х если пропускная способность связи ограничена, применяются одинаковые па раметры повторной передачи TCP (таймаут RPC намного больше, чем TCP).
Служба каталогов Active Directory 262 ЧАСТЬ Поскольку SMTP не используется для репликации разделов домена, Windows 200Q поддерживает синхронную RPC-репликацию типа точка Ч точка помимо асинх ронной SMTP-репликации между сайтами, что обеспечивает определенную гиб кость, позволяя доменам размешаться в нескольких сайтах. RPC лучше;
использо вать между хорошо связанными сайтами, потому что он вызывает меньшую задер жку. SMTP лучше применять для мсжсайтовой репликации, где применение RPC поверх IP невозможно. SMTP используют компании, опорная сеть которых осно вана не на TCP/IP, например сеть Х.400.
В системе репликации Active Directory применяются оба транспорта для реализа ции механизма запрос Ч ответ. Active Directory генерирует запросы на измене ния и ответы на них. В RPC им сопоставляются запросы и ответы RPC. A SMTP базируется на постоянных TCP-соединениях для доставки почтовых потоков по всем направлениям. Таким образом, в транспорте RPC ответы па запросы почти мгновенны, и поддерживается не более одного активного входящего RPC-под ключения с репликой раздела каталога. Транспорт SMTP поддерживает намного более длинные задержки между запросом и ответом. В итоге допускается несколь ко активных входящих SMTP-подключений с репликой раздела каталога, если ко нечно вес эти запросы направлены различным контроллерам-источникам или раз делам каталога.
Преимущества межеайтовой репликации по SMTP Хотя репликация по SMTP обычно медленнее, чем RPC, в некоторых условиях воз можна или предпочтительна именно SMTP-репликация.
Х RP С-репликация синхронна, а SMTP-репликация - асинхронна. В условиях ограниченной пропускной способности иногда невыгодно дожидаться полного завершения одной транзакции, пока не начнется следующая. В SMTP несколь ко транзакций могут обрабатываться одновременно, в то время как при RPC репликации нередки длительные таймауты.
Х В среде WAN удается обеспечить защиту, мониторинг и управление трафика SMTP.
Х Там, где нельзя реализовать сквозную интерактивную связь по IP (например, А связывается с В, В Ч с С, по А никогда не связывается напрямую с С), можно наладить почту для связи А с В, В г С, С с В и В с А.
Размер пакетов репликации По умолчанию размеры пакета вычисляются на основе размера памяти, при усло вии, что ее объем не больше 1 Гб и не меньше 100 Мб. Эти размеры пакетов разре шается переопределить, изменив соответствующие параметры реестра.
Чтобы скорректировать размер пакетов с данными репликации Active Directory, следует изменить или добавить параметры с типом данных REG_DWORD в следу ющем разделе реестра: HKEY_LOCAL_MACHINE\System\CurrentControlSet\ Services\NTDS\Parameters. Указанные далее параметры определяют максимальное количество объектов в пакете и максимальный размер пакетов.
Х Для внутрисайтовой RPC-репликации:
Х Replicator intra site packet size (objects) (Количество объектов в пакете реп ликации) больше или равно 1;
Репликация Active Directory ГЛАВА Х Replicator intra site packet size (bytes) (Количество байт в пакете реплика ции) больше или равно 10 кб.
Х Для RPC-репликации между сайтами:
Х Replicator inter site packet size (objects) больше или равно 1;
Х Replicator inter site packet size (bytes) больше или равно 10 кб.
Х Для SMTP-репликации между сайтами:
Х Replicator inter site packet size (objects) ) больше или равно 1;
Х Replicator inter site packet size (bytes) больше или равно 10 кб.
Если указанные параметры реестра не определены, система ограничивает размер пакета следующим образом:
Х размер пакета в байтах равен сотой части ОЗУ, но не менее 1 Мб и не более 10 Мб;
Х число объектов в пакете Ч одна миллионная размера ОЗУ, но не менее 100 объек тов и не более 1 000 объектов.
Есть одно исключение: значение параметра Replicator async inter site packet size (bytes) (Количество байт в пакете асинхронной репликации) всегда равно 1 Мб.
Многие почтовые системы ограничивают объем почтовых сообщений (обычно до 2 1 Мб), хотя большинство почтовых систем на базе Windows способны обра батывать большие почтовые сообщения размером до 10 Мб.
Внимание! Не модифицируйте реестр самостоятельно (с помощью редактора реес тра) Ч делайте это лишь в крайнем случае, когда другого выхода нет. В отличие от инструментов управления редактор реестра обходит стандартные средства защиты, призванные не допускать ввода конфликтующих значений параметров, а также спи собных снизить быстродействие системы или разрушить ее. Не исключено, что по следствия прямого редактирования реестра окажутся не такими, как Вы ожидали, и, возможно, Вам придется переустанавливать Windows 2000. Для-настройки и кон фигурирования Windows 2000 рекомендуется использовать Control Panel (Панель управления) или Microsoft Management Console (Консоль управления Microsoft).
Перед изменением реестра советуем делать резервную копию. Подробнее о редакти ровании параметров реестра - в справочной системе редактора реестра. Подробнее о реестре Ч в техническом руководстве Technical Reference Microsoft Windows Professional Resource Kit (файл Regentry.chm).
Управление репликацией между сайтами Хотя репликапия внутри сайтов оптимизирована для LAN и практически не требу ет управления, Вы вправе контролировать, когда и" как происходит репликация между сайтами. Если Вы хотите достичь максимальной эффективности при мини мальной стоимости, следует принять ряд решений, основанных на структуре сете вой среды, физическом расположении и деловых потребностях организации. КСС строит топологию репликации между сайтами автоматически, но при этом она учи тывает заданные параметры межсайтовых связей.
Когда несколько сайтов участвуют в топологии репликации контроллеров домена в одном лесе, создаваемая по умолчанию топология репликации между сайтами яв ляется связующим деревом с минимальной стоимостью репликации. Стоимость ЮЗак 40: Служба каталогов Active Directory 264 ЧАСТЬ это административно назначенные оценки маршрутов репликации. Репликация между сайтами выполняется синхронно средствами RPC поверх IP или асинхрон но по SMTP поверх IP, Примечание Алгоритм связующего дерева (Spanning Tree Algorithm, STA) применя ется для устранения избыточных маршрутов и, значит, снижения нагрузки на до рогостоящие WAN-каналы связи.
Планирование репликации между сайтами Репликация внутри сайтов, как правило, не нуждается в планировании, поскольку выполняется полностью автоматически. В среде с множеством сайтов Вам следует выполнить определенные операции по планированию репликации.
1. Определите сайты, надежно объединенные опорными сетями, и создайте меж еайтовые связи между ними с минимальными стоимостями.
2. Выделите сайты, связанные транспортом с примерно равной стоимостью, и со здайте между ними связи средней стоимости Ч например, межсетевые связи (удаленные сайты, связанные по телекоммуникационным каналам), связи по протоколу Frame Relay (система точка точка на базе частного виртуального канала), связи по региональным сетям (medium area network, MAN) с пропуск ной способностью Т1.
3. Выделите оставшиеся WAN-связи.
4. Создайте связи для каждой пары сайтов, соединенных по WAN.
5. Создайте расписание, отвечающее потребностям пользователей, Не задавайте высокую частоту репликации. Связи сайтов должны иметь общие временные окна, доступные для обмена данными.
Подробнее о планировании сайтов и топологии сайтов в Active Directory Ч в книге Microsoft Windows 2000 Server Deployment Planning Guide (Microsoft Press, 2000).
Управление связями сайтов Объекты-подключения автоматически создаются службой КСС для репликации внутри и между сайтами. Однако для этого необходимо вручную создать связь меж ду всеми парами сайтов. Эти связи, реализуемые как объекты связей сайтов в Active Directory, определяют транспортный протокол и расписание, требуемые для реп ликации между двумя сайтами. Связи сайтов создаются средствами консоли Active Directory Sites and Services, а на их основании в процессе создания топологии меж сайтовой репликации служба КСС создает подключения.
Объекты связей между сайтами создаются в одном из двух транспортных кон тейнеров Ч прямых потомков контейнера Inter-Site Transports средствами Active Directory Sites and Services. Создаваемая связь в том или ином контейнере сопос тавляется с одним из транспортов репликации. Контейнер Inter-Site Transports Ч потомок контейнера Sites и в свою очередь содержит дочерние контейнеры:
Х контейнер IP, который содержит объекты связей сайтов синхронной репликации по механизму RPC поверх IP;
Х контейнер SMTP, который содержит объекты связи сайтов асинхронной репли кации типа SMTP поверх IP.
Репликация Active Directory ГЛАВА При конфигурировании объектов-подключений межсайтовой репликации служба КСС учитывает параметры объектов связи сайтов, чтобы создать наилучшее под ключение. В частности, один из параметров межсайтовой связи Ч стоимость под ключения. КСС выбирает удаленный сайт с самой низкой стоимостью подключе ния.
Для транспорта IP обычно связь сайтов соединяет только два сайта и соответству ет фактической связи WAN. Связь по IP, соединяющая больше двух сайтов, может соответствовать опорной сети ATM, которая соединяет, например, более двух групп зданий в' большом университетском городке или несколько столичных офисов, объединенных IP-маршрутизаторами и выделенными линиями, Разрешается связывать сайты друг с другом любым количеством объектов связей сайтов. Каждый сайт в многобайтовом каталоге должен обладать по крайней мере одной связью, иначе репликация с контроллерами домена в других сайтах окажет ся невозможной, и каталог потеряет свою целостность. Поэтому, если в лесе боль гае одного сайта, необходимо сконфигурировать по крайней мере одну связь между ними.
На рис. 6-6 показаны два сайта с одной связью. В обоих сайтах есть контроллеры одного домена. При формировании топологии репликации КСС создает в сайте объекты-подключения между серверами-плацдармами, и репликация выполняется согласно конфигурации связи сайтов.
Домен Reskit.com Подключения Контроллер Server 1 Servers.Х Связь сайтов Сайт Seattle Сайт Milan Рис. 6-6. Два сайта, объединенных одной связью На рис. 6-7 изображены три сайта, объединенные двумя связями. По умолчанию связи сайтов транзитивны, поэтому сообщения репликации могут передаваться от сайта Atlanta через сайт Seattle к сайту Milan. Поскольку в этом сценарии сайт Seattle содержит полную реплику домена reskit.com, нет необходимости в прямой репликации между сайтами Milan и Atlanta: репликация между ними идет через сайт Seattle.
Служба каталогов Active Directory 266 ЧАСТЬ Домен Reskit.com Подключения [-Подключения Контроллер Server ХСвя.зь сайтов Сайт Seattle Сайт Atlanta Контроллер..
Server 3 '!;
Сайт Milan Рис. 6-7. Три сайта, объединенных двумя связями Конфигурация связи сайтов В консоли Active Directory Sites and Services на вкладке General (Общие) страниц свойств связи сайтов расположены несколько параметров конфигурации связей, используемых для управления топологией репликации:
Х список двух или более сайтов, объединяемых топологией;
Х расписание доступности связи для репликации. Например, связь коммутируе мого доступа можно настроить на работу только в нерабочее время, когда теле фонные тарифы низки;
Примечание Расписание игнорируется SMTP-связями сайтов: почта накаплива ется и пересылается согласно настройкам почтовой инфраструктуры.
Х стоимость Ч один числовой коэффициент, характеризующий затраты на под ключение по данной связи. Чем выше стоимость, тем дороже обмен сообщения ми. Например, у сайтов, связанных пизкоскоростным или модемным соедине нием, связи сайтов дорогие, а у сайтов, связанные по опорной сети, - дешевые.
Там, где между двумя сайтами существует несколько маршрутов или применя ются разные транспорты, используются комбинация маршрута и транспорта с наименьшей стоимостью;
Х период в минутах, определяющий частоту репликации (но умолчанию Ч каж дые 180 минут или 3 часа;
минимум Ч 15 минут).
Параметры связи сайтов позволяю-]' независимо управлять топологией и расписа нием репликации:
Х на топологию репликации влияет стоимость связей сайтов. Как правило, для снязей сайтов по опорной сети следует задавать стоимость 1, а для связей по Репликация Active Directory ГЛАВА 6 медленным подключениям с филиалами - 100. Такие параметры стоимости га рантируют, что филиал будет выполнять репликацию с контроллером домена в сайте, относящемся к опорной сети, а не напрямую со вторым филиалом. Сто имости связей не влияют на частоту репликации;
Х интервал репликации задается в минутах для каждой связи сайтов;
Х доступность связи регулируется ее расписанием. В большинстве случаев следу ет применять стандартное расписание (постоянный доступ), но в пиковое рабо чее время можно блокировать трафик репликации для связей с некоторыми филиалами. Временный запрет дает приоритет другому трафику, но увеличива ет задержку репликации.
Влияние стоимостных показателей При настройке стоимости связей сайтов учитывается, что КСС отдает приоритет подключениям с более низкой стоимостью. Стоимость канала связи важный фак тор, который нужно учитывать при определении границ сайтов. Рекомендуется со гласовать затраты для всех сайтов. Стоимость обычно зависит не только от полной пропускной способности канала, но и от доступности, времени ожидания и от сто имости самой связи.
Например, канал постоянной связи со скоростью 128 кбит/с обычно стоит дешев ле, чем канал двусторонней модемной линии TSDK с той же скоростью. Дело в том, что связь по ISDN вызывает задержку репликации из-за потерь времени на уста новку и разрыв соединения. Кроме того, в этом примере, постоянная связь обычно оплачивается по фиксированной помесячной ставке, а оплата линии ISDN зависит от объема переданных данных. Поскольку компания оплачивает постоянную связь разовым авансовым платежом, администратор вправе назначить ей более низкую стоимость, чем линии ISDN. Соединения TSDN в этом примере создают дополни тельные расходы к уже оплаченной постоянной линии.
В таблице 6-2 перечислены скорости для разных типов сетей эти значения Вам будут полезны при опенке стоимости, Таблица 6-2. Скорости сетей для оценки стоимости связей сайтов Тип сети Быстродействие Очень \тедлеш1ая 56 кбит/с Медленная 64 кбит/с (типичная D Европе) ISDN 64 кбит/с или 128 кбит/с Frame Relay Переменная скорость, обычно от 56 кбит/с до 1,5 Мбит/с Т1 1,5 Мбит/с ТЗ 45 Мбит/с ATM Переменная скорость, обычно в диапазоне 155-622 Мбит/с Gigabit Ethernet 1 Гбит/с До настройки стоимости следует определить модель существующей WAN-сети. На основе стоимости и других факторов (доступность, задержка репликации) создает ся согласованный набор стоимостей для всего леса. При назначении определенной стоимости, она должна иметь одинаковый смысл во всех связях, где назначена. В таблице 6-3 показан пример распределения стоимостей в лесе для сети, где высо кая скорость стоит немного.
Служба каталогов Active Directory 268 ЧАСТЬ Таблица 6-3. Пример схемы стоимостей для леса в высокоскоростной сети Тип сети Стоимость Т1, подключенная к опорной сети Связь со скоростью 56 кбит/с Филиал 1 Международная связь 5 Параметр Cost (Стоимость) для межсайтовой связи указывает относительное зна чение для стоимости подключения между всеми входящими в связь сайтами. По умолчанию параметры межсайтовой связи траизитивиы (transitive). Например, если Вы создаете объект IP-связи сайтов XYZ, которая соединяет сайты X, Y и Z со стоимостью 5, Вы указываете, что сообщение IP может пересылаться между все ми парами сайтов (X-Y, X-Z, Y-X, Y-Z, Z-X, Z-Y) со стоимостью 5.
Примечание По умолчанию все связи сайтов транзитивны, то есть все связи для определенного транспорта неявно принадлежат одному мосту связей сайтов для этого транспорта. (Подробнее о мостах - в разделе Мосты связей сайтов далее в этой главе.) Если Ваша IP-сеть не полностью связна, Вы можете отключить тран зитивность межсайтовой связи для транспорта IP. В этом случае все IP-связи сай тов будут рассматриваться как нетранзитивные, и Вы сможете конфигурировать мосты вручную.
КСС определяет самые дешевые пути между всеми сайтами для каждого раздела каталога. Далее КСС сравнивает пути к/от каждого приемника и вычисляет связу ющее дерево с самыми низким показателем стоимостей.
Подробнее о связности IP-сетей - в книге Microsoft Windows 2000 Server Deployment Planning Guide (Microsoft Press, 2000).
Период репликации Для каждого объекта межсайтовой связи, задается значение периода репликации, определяющее, как часто по этой связи выполняется репликация по расписанию.
Например, если по расписанию репликация задана с 02:00 до 04:00 часов и период репликации 30 минут, репликация может выполниться до четырех раз.
Стандартный период репликации -- 180 минут или 3 часа. Создавая подключение между контроллерами домена в разных сайтах, КСС определяет период реплика ции подключения как максимальный период по самому дешевому пути объектов связей сайтов с одного конца подключения в другой.
Расписание репликации Если для репликации между сайтами применяется транспорт RPC, разрешается определить расписание репликации. Связям сайтов соответствует расписание, опи сывающее интервалы времени, в которых репликация разрешена. Если репликация выполняется через несколько связей сайтов, необходимо минимум одно общее вре менное окно (то есть перекрытие по времени), иначе репликация невозможна. На пример, если одна связь сайтов активна с 18:00 до 24:00 часов, а вторая Ч с 17:00 до 20:00 часов, реальный интервал -- пересечение этих интервалов, то есть с 18:00 до 20:00 часов.
Репликация Active Directory ГЛАВА Путь репликации Путь, которым репликация проходит между сайтами, вычисляется на основе инфор мации, хранимой в объектах связей сайтов. Изменения параметров связи сайтов вступают в силу после:
Х репликации изменений связи сайтов в каждую генерирующую топологию сис тему по старой топологии;
Х вызова КСС на генерирующих топологию системах.
Поскольку путь подключений трашитивно выражается через набор связей сайтов, атрибуты (параметры) объектов связей сайтов лобъединяются в пути следующим образом:
Х стоимости суммируются;
Х период репликации равен наибольшему из интервалов в пути;
Х логические параметры перемножаются с применение булевой операции умтю жения И.
Примечание Под логическими параметрами подразумеваются значения атрибута options объекта связи сайтов. Значение этого атрибута определяет такие особеннос ти поведения связи сайтов, как взаимная репликация и уведомление об изменени ях между сайтами. (Подробнее об этом Ч в разделах Взаимная репликация и Уведомление об изменениях далее в этой главе.) Таким образом, расписание межсайтовой связи Ч это пересечение всех расписа ний подпутей. Если расписания не перекрывается, путь не используется.
Конфигурация связи сайтов и задержки репликации Расписание определяет интервалы времени, когда связь сайтов доступна, а период репликации Ч частоту репликации в этих интервалах. В совокупности эти факто ры определяют задержку репликации. Для сайтов, где максимальный период реп ликации в пределах сайта Ч 15 минут, в худшем случае задержка всей репликации от контроллера-источника до контроллера-приемника в отдаленном сайте равна сумме периодов репликации, заданных для подключений между сайтом-источни ком и сайтом-приемником, плюс 15 минут для каждого сайта в пути (включая сайт источник и сайт-приемник). В этом случае предполагается, что между сайтами ис пользуется транспорт RPC и что необходимые физические подключения доступны.
Взаимодействие расписания и периода репликации Если для выполнения репликации во всех сайтах требуется несколько связей сай тов, периоды репликации на каждой связи в совокупности влияют на полную дли ну соединения между сайтами. Кроме того, репликация выполняется только во вре мя пересечения расписаний связей сайтов.
Предположим, что сайты А и В объединены связью АВ, а сайты В и С Ч связью ВС.
В таком случае контроллер домена в сайте А обменивается данными репликации с контроллером домена в сайте С только с частотой, допустимой максимальным пе риодом, заданным для связей АВ и ВС. В таблице 6-4 приведены параметры свя:ш, определяющие частоту и время репликации между контроллерами домена в сайтах А, В и С.
Служба каталогов Active Directory 270 ЧАСТЬ Таблица 6-4. Периоды репликации и параметры расписания для двух межсайтовых связей Связь сайтов Период репликации Расписание АВ 30 минут С 12:00 до 04:00 часов С 01:00 до 05:00 часов ВС 60 минут В соответствии с параметрами, указанными в таблице 6-4, контроллер домена в домене А может выполнять репликацию с;
контроллером домена в сайте В согласно расписанию и периоду связи АВ (раз в полчаса с 12:00 до 04:00 часов). Однако в отсутствие связи АС контроллер домена в сайте может реплицировать с контрол лером домена R сайте С раз в час (что больше этих двух периодов репликации) с 01:00 до 04:00 часов (когда расписания этих двух связей пересекаются).
Настройка расписания Время в параметре Schedule (Расписание) для связи сайтов указывается в часах.
Например, репликацию можно выполнять с 00:00 до 01:00 часов, с 01:00 до 02: часов и т. д. Однако каждый блок и фактическом расписании подключения 15 минут. Поэтому в расписании с 01:00 до 02:00 часов репликация будет обяза тельно поставлена в очередь в интервале между 01:00 и 01:14:59.
Примечание Синхронная входящая репликация RPC выполняется последовательно, поэтому, если сервер занят репликацией раздела каталога из источника, репликация из другого источника не начнется до завершения первой синхронизации. Данные полученные по SMTP обрабатываются последовательно в порядке прибытия.
А точнее, событие репликации ставится в очередь в момент t + п, где t --- период репликации, применяемый в расписании, а п Ч псевдослучайное число между 1 и 15 минутами включительно. Например, если связь сайтов указывает, что реплика ция возможна между 02:00 и 07:00 часами (включительно), а период репликации Ч 2 часа (120 минут), t Ч 02:00, 04:00 и 06:00 часа. Событие репликации ставится в очередь между 02:00 и 02:14:59 часами и другое событие репликации ставится в очередь между 04:00 и 04:14:59 часами. Если первое событие репликации, постав ленное в очередь, завершено, следующая репликация ставится в очередь между 06:00 и 06:14:59 часами. Если репликация длится больше двух часов, вторая синх ронизация игнорируется, так как в очереди уже есть событие.
Примечание В очередь репликации размещаются и другие события, и поэтому вре мя начала репликации Ч приблизительно. Два события репликации для одного раз дела каталога и одного транспорта и очередь не ставятся, Подробнее о создании и настройке связей сайтов в справочной системе Microsoft Windows 2000 Server.
Конфигурация основного сервера-плацдарма При выборе сервера-плацдарма следует иметь в виду, что он должен обрабатывать больший трафик репликации, чем другие серверы. При устранении неполадок иног да очень помогает знание того, какой контроллер является плацдармом.
После ручного конфигурирования контроллера домена в качестве сервера-плацдар ма для сайта служба КСС использует только этот сервер. Если в сайте несколько Репликация Active Directory ГЛАВА контроллеров домена сконфигурировано как основные серверы-плацдармы, служ ба КСС в конечном счете выбирает один из них, руководствуясь при этом другими параметрами.
В определенных условиях доступности транспортов, необходимости репликации разделов каталога и доступности серверов глобального каталога требуется несколь ко серверов-плацдармов, чтобы реплицировать полные копии данных с одного сай та на другой, Предположим, есть два сайта Ч А и В, в каждом из которых имеется контроллер каждого из двух доменов Ч X и Y. В этом случае единственный способ репликации между этими двумя сайтами соответствующих разделов домена - назначить кон троллеры доменов X и Y серверами-плацдармами в каждом сайте. Поэтому, если в определенном сайте имеется один контроллер конкретного домена, он должен быть сервером-плацдармом в своем сайте, потому что он может выполнять репликацию данных домена только с контроллером своего собственного домена. Кроме того, у него должна быть возможность соединиться с серверами-плацдармами в других сай тах, который тоже хранят аналогичный раздел домена, Если требуется, чтобы служба КСС рассматривала определенные контроллеры до мена как основные серверы-плацдармы, сконфигурируйте соответствующим обра зом свойства объекта-сервера в Active Directory Sites and Services. Для этого от кройте страницу свойств выбранного сервера и добавьте транспорты, для которых выбранный контроллер является основным плацдармом (IP для механизма RPC поверх IP или SMTP для SMTP поверх IP). Если Вы выберете больше одного сервера определенного раздела для конкретного транспорта, служба КСС произ вольно выберет один из них. Подробнее о выборе основного сервера-плацдарма в справочной системе Microsoft Windows 2000 Server.
Отказ сервера-плацдарма Выход из строя сервера-плацдарма в состоянии нарушить репликацию между дву мя сайтами. В этом случае КСС обычно автоматически выбирает другой сервер плацдарм.
Отказ серверов-плацдармов, назначенных службой КСС Если Вы не укажете основные серверы-плацдармы, КСС выберет их автоматичес ки. Если в дальнейшем сервер-плацдарм откажет (то есть между моментами сбоя и последней успешной репликации больше 2 часов), КСС выберет другой сервер плацдарм. Если ни один из возможных серверов-плацдармов не доступен, КСС ре гистрирует в журнале соответствующее событие, Отказ основных серверов-плацдармов Если основные серверы-плацдармы указаны явно и ни один из них не доступен, КСС не выбирает альтернативные серверы-плацдармы автоматически. В этом слу чае КСС регистрирует сообщение об ошибке, информирующие, что основные сер веры-плацдармы указаны, но пи один из них не доступен.
Замена отказавшего основного сервера-плацдарма Если требуется, чтобы КСС обращалась при сбое к другим контроллерам домена, когда доступных основных серверов-плацдармов пет, Вы должны выполнить на кон троллере домена в каждом сайте одну из перечисленных далее операций;
Служба каталогов Active Directory 272 ЧАСТЬ Х добавьте новые контроллеры домена - основные серверы-плац дар мы для соот ветствующих разделов каталога, сайта и транспорта (если в сайте несколько до менов, добавьте основной сервер-плацдарм для соответствующего домена);
Х удалите все назначения основных плацдармов, сделанные для соответствующих сайта и транспортаЧ это позволит КСС выбрать новые плацдармы автомати чески.
Внимание! КСС создает только входящие подключения. Сервер-плацдарм не в со стоянии создать исходящее подключение с другим сервером-плацдармом. Поэтому, если отлаженного пути репликации к другому сайту нет, изменения статуса основ ного сервера-плацдарма надо выполнять па контроллере домена в каждом затрону том сайте, чтобы создать в каждом из них входящие подключения.
Если единственный основной сервер-плацдарм, доступный для определенных раз дела каталога и транспорта, вышел из строя и Вы хотите поручить эту роль новому серверу-плацдарму, необходимо добавить новый сервер-плацдарм дважды: один раз на контроллере домена в сайте отказавшего сервера-плацдарма и еще раз Ч на кон троллере домена в сайте на другом конце затронутой связи сайтов. Эту процедуру иногда приходится выполнять двум администраторам, если сайты расположены далеко друг от друга.
Примечание Если есть доступные основные серверы-плацдармы и требуется доба вить в сайт другой основной сервер-плацдарм, не обязательно добавлять его в обо их сайтах, потому что это изменение реплицируется в другой сайту через доступ ные в настоящее время серверы-плацдармы.
Если Вы удаляете все основные серверы-плацдармы и хотите, чтобы служба КСС выбирала их автоматически, удалите- их для всех разделов домена и всех транспор тов на контроллере домена в каждом затронутом сайте.
На рис. 6-8 показаны подключения между серверами-плацдармами в двух сайтах.
Сервер-плацдарм в сайте А Ч основной.
Pages: | 1 | ... | 4 | 5 | 6 | 7 | 8 | ... | 18 | Книги, научные публикации