Книги, научные публикации
Pages: | 1 | ... | 3 | 4 | 5 | 6 | 7 | ... | 15 | Distributed Systems Guide Microsoft 2000 Server Microsoft Press Распределенные системы Книга 1 2000 Server Москва 2001 Я fl I (I Г К I P УДК 004 ББК 32.973.26-018,2 М59 Microsoft ...
-- [ Страница 5 ] --ГЛАВА 5 служб в Directory Примечание Атрибуты и из классов объек тив Directory содержат список классов объектов, способных содержать эк земпляры объектов данного класса, то есть типы в которых можно создать этот объект. У классов атрибут нельзя: только добавлять, но не удалять значения атрибута possSuperiors. Например, можно создать объект класса service ConnectionPoint как до черний объект класса Computer, Container или Organization-Unit. Подробнее об ат рибутах и Ч в главе 4 Active Directory.
Инфраструктура каталога для публикации служб Объекты Active Directory согласно иерархии. иерархия Active Directory содержит необходимую для установки и запуска 2000 и самой службы каталогов. структура содержит контей неры, специально для поддержки публикации служб.
На рис. 5-1 структура Active Directory по умолчанию.
Configuration System Services Sites RPCservices Рис. 5-1. Структура Active Directory по умолчанию для публикации служб Иерархия домена содержит все объекты данного домена (например, и принтеры) и па все контроллеры этого Иерархия содержит все объекты, относящиеся ко всему лесу доме нов, и реплицируется па каждый контроллер домена этого Папки Services Sites - прямые потомки раздела Точки подключения Объект класса (точка подключения) один или сколько в сети службы. В схеме Active определе но множество объектов, которых можно использовать при публикации служб. Все объекты, ресурсы и способные принимать подключе ния, производными от класса connectionPoint. Его показана на рис. 5-2.
Далее приведены примеры объектов (способных принимать соединения) производных от класса connectionPoint.
Print Queue и Volume Ч этих классов стандартные точки используемые службами и файловыми службами соответственно.
216 ЧАСТЬ 1 Служба Active Directory Service RPC Entry Service Print Queue Connection Point Service Administration Point Рис. 5-2. Иерархия класса RPC Entry Windows 2000 поддерживает два сетевых API-интерфейса, обеспечи вающих независимый от транспорта обмен информацией: Microsoft Windows Sockets и RPC. Интерфейс RPC предоставляет механизм вызова функций в процес сах, в том числе на компьютерах в сети. RPC поддерживает модель по токов, службу сопоставления (mapping) конечных точек (сокетов, каналов или портов) и взаимодействует со службой имен. В настоящее время для публикации в Active Directory служб средствами API-интерфейса RPC Name применяются объекты класса и других классов объек тов RPC.
Service Instance для публикации в Active Directory служб Windows Sockets, пуб ликующих сведения о себе средствами API-интерфейсов и регистра ции (registration and resolution, применяются объекты класса Service Connection Point объекты этого класса используют службы, не поддер существующие уровни абстрагирования, такие, как RPC Name Service или и поэтому нуждающиеся в явной публикации в Active Directory.
использующая точку подключения Service-Connection-Point, должна обес печивать уровень скрывающий от клиентских све дения о размещении службы. Этот уровень абстрагирования реализуется в виде DLL-библиотеки или как составная часть клиентского приложения. Уровень абст в Active Directory объект подключения, пред ставляющий запрошенную клиентским приложением службу, и использует содер жащиеся в нем сведения о привязке для подключения приложения к службе.
Клиентское приложение запрашивает в Active Directory объекты - точки подклю которые представляют ему службы. Клиент выбирает один или несколько найденных и использует получаемую из объектов информацию о привязках для подключения к службе. В случае с RpcNs и RnR запрос выполня ется уровнем запрос объектов класса осу самостоятельно.
ГЛАВА 5 Публикация служб в Active Directory Примечание Службы па основе СОМ не объекты семейства классов Point для оповещения о себе, а в хранилище классов (class store) Windows 2000. Это хранилище сведений обо всех приложениях, и API, применяемых для и назначения приложений, на ката логе.
Подробнее о классов и службах на основе СОМ Ч на Web Resources по адресу res kit/web ссылка MSDN, Выбор места публикации Принимая о службы в Active учтите следую щие рекомендации:
Х служба должна публиковать о себе в разделе домена, но не в конфигурации;
Х служба должна относящиеся к ней объекты в том же домене, где положен на котором она выполняется. Необходимо, чтобы места было удобно для администрирования службы и поддержки ее объек тов. Мы рекомендуем располагать объекты служб в объекте компьютера, на ко тором они установлены.
Если клиент обладает доступом к компьютеру, на котором выполняется также должна быть доступна и реплика домена, данный компьютер.
Примечание в редких случаях клиент может определить компьютер, на ко тором выполняется служба. Обычно клиент находит службу по значению keywords, который, как правило, содержит к поставщику и при ложению. Для этого служба, публикующая информацию, обязана публиковать и ат рибут keywords.
Подробнее об атрибуте keywords на странице Resources по адресу ссылка Microsoft Platform SDK.
Таким образом, вполне достаточно опубликовать о службе в домене, содержащем компьютер, на котором эта служба Публикация сведе ний о службе в разделе конфигурации не доступ к службе и ее использо а создает трафик репликации. Не рекомендуется публико вать информацию о службе в разделе конфигурации, чтобы не снижать тельность системы.
Для поиска объектов клиенты каталог. Если клиент выполняет по иск не в своем домене, а во всем лесе, то ему потребуется глобальный каталог. Но в любом случае для клиента несущественно, где расположен объект-служба.
му от клиента никак не зависит место публикации объекта-службы. Более того, главное, что надо учесть при публикации, Ч удобство администрирования В иерархии доменов Active Directory относящиеся к службам объекты размещать трех ЧАСТЬ 1 Служба каталогов Active Directory Х в объекте компьютер (Computer);
Х в объекте Х в папке System (или в одном из его дочерних контейнеров).
Примечание В Active Directory (как и во многих других службах каталогов) любой объект можно сделать действительным родителем, преобразовав в Это позволяет создавать интуитивно структуру каталога. Например, относящиеся к отдельному компьютеру, отображаются в каталоге как сто дочерние Ч это место, где их будет искать администратор, Объект-компьютер Публикуя службы, установленные на компьютере, создавайте объекты служб как дочерние объекты, соответствующего ему объекта компьютер.
Для упрощения установки многие службы создают свои объекты в стандартном хотя большинство служб перемещать созданные объекты. Объект компьютер, на котором служба, удобное и понятное место для таких объектов, поскольку при перемещении этого объекта новое ме сто Active Directory автоматически перемещает вместе с ним и все объекты-служ бы. Кроме того, объект-компьютер удаляется или присоединяется к другому объекты-службы также удаляются. Таким образом, снижается вероятность появления потерянных (orphaned) объектов-служб. Процесс, выполняющийся на компьютере Ч члене домена, всегда может найти объект-компьютер в каталоге.
Примечание Действительные объекты компьютер существуют в каталоге лишь для компьютеров-членов домена.
Иерархия контейнеров Active Directory позволяет создавать иерархию контейнеров, соответствующую по требностям Вашей организации. Для таких иерархий применяется класс Ч контейнер общего назначения, который нужен для груп пирования большинства классов объектов для удобства администрирования, в том числе и объектов-компьютеров. Для удобства администрирования иногда требует ся сгруппировать относящиеся к службам объекты. Active Directory за давать разрешения для объектов в контейнере или поддереве в одном списке (access control list, ACL). B Windows 2000 применяется модель разрешений, позволяющая весьма точно управлять доступом к объектам в каталоге и административные полномочия другим пользователям.
Все стандартные классы объектов, относящихся к службам, Ч дочер ние объекты класса organizationalUnit, поэтому службе не свои объекты в фиксированном месте каталога.
Пример кода, который создает объект-службу, сохраняет его атрибут и обнаруживает созданный объект-службу по этому атрибуту Ч на Web-стра нице Web Resources ссылка ГЛАВА 5 Публикация служб в Active Directory Контейнеры Users и Computers Windows NT до 2000 учетные групп и помещаются в контейнеры Users и Computers. Объекты пользователи и объекты-группы хранятся в контейнере Users, а объекты-компью теры - в контейнере Computers. NT и (такие как которые создают записи пользователей, групп и а также применяют служебные программы, автоматически мянутые объекты в соответствующих Не перемещайте относящиеся к службе объекты в эти напрямую и создавайте в них Впрочем, службы публикуют объек ты независимо от того, где последний размещен Ч в или в другом месте. Создавайте объекты точек к службам в контей нере компьютера, на котором установлена служба.
Контейнер System Контейнер System содержит сведения, используемые для поддержки текущей ра боты домена, в том числе о стандартной локальной об изменившихся файлов, о сетевых конференциях и для то чек подключения к RPC и Windows (Winsock). По умолчанию System скрыт, что делает его удобным для хранения объектов, нужных ад министраторам, а не пользователям.
Службы, оповещающие о средствами API-интерфейсов Winsock или RpcNs, все необходимые объекты в контейнерах WinsockServices автоматически. Никогда не- создавайте явно объекты в этих и не перемещайте объекты в них.
Службы, создающие объекты служб в контейнере System, должны сле дующие действия:
Х подконтейнер в контейнере, хранящем объекты данного класса и ющемся прямым потомком контейнера System, и дать ему четко щее на его к службе;
Х опубликовать к объекты в контейнере System.
приложение Microsoft Net Meeting публикует объекты сетевых конференций контейнере Meetings. При объектов нескольких приложений-служб одного поставщика для каждой службы создавать отдельный контейнер в контейнере - непосредственном потомке контейнера System, имя этого Служба, слабо связанная с компьютером, например пуб ликуется в контейнера System.
Публикация служб в Active Directory При публикации служб придерживайтесь следующих рекомендаций:
Х при установке служб создавайте объекты Ч точки подключения таким чтобы пользователю с достаточными привилегиями удавалось без особых про блем опубликованную службу с помощью этой точки подключения;
Х настройте службу так, чтобы она могла во время работы щие объекты точек подключения.
220 ЧАСТЬ 1 Служба каталогов Active Directory Независимо от способа публикации учтите ограничения доступа к каталогу Ч как в установки служб, так и при работе. API интерфейсы RpcNs и создают точки подключения в контейнерах RpcScrvices и соответственно, расположенных в контейнере System каждого домена. Объекты класса следует создавать как дочерние па котором установлена служба.
Чтобы создать объект, процесс обладать на создание потомка соответствующего класса и где новый объект. Для удале ния объекта процесс должен разрешением на удаление потомка этого клас са и контейнера, в котором размещается объект, а также иметь разрешение на уда ление самого объекта. Обновление точки подключения возможно только при нали чии у процесса разрешения на запись свойств объекта.
Иногда при установке службы выясняется, что этих разрешений у учетной записи или службы нет. В этом случае установку выполняет администратор или другое полномочное лицо. При установке публикуемой службы предоставьте самой службе доступ на параметров точки подключения во время вы полнения, независимо от того, под какой учетной записью она Это позволит ей управлять точкой подключения даже при олицетворении учетной за писи с минимальными привилегиями.
Подробнее о публикации служб Ч на Web Resources по адресу ссылка MSDN.
Класс Service Connection Point (SCP) это базовый класс объектов, используемый для публикации и поиска служб. SCP предназначен для публикации клиентских привязок. Свойства этого класса позволяют службе публиковать информацию, не обходимую клиенту для привязки к экземпляру службы. Клиенты службы должны уметь интерпретировать и применять атрибуты порядок использования этих атрибутов в Active Directory не определен. Службы, которым опуб ликовать дополнительную информацию о себе, могут расширить путем со здания подклассов (subclassing) класса SCP и назначения им легко узнаваемых имен.
Подробнее о схемы -- в главе 4 Схема Active Программа установки (или процедура создания службы в процессе установки дру гого приложения) создает службу и при необходимости Ч учетную запись и точку подключения службы. В начале своей работы служба проверяет, содержит ли объект Ч точка подключения Ч корректные сведения о привязке.
В сети иногда представлено несколько экземпляров службы с разными возможнос тями. Например, на нескольких серверах баз данных может храниться совершенно разная информация, хотя все серверы относятся к службе одного типа или к одно му классу Кроме того, службы поддерживают репликацию. Реплицируемая служба состоит из нескольких экземпляров с возможностями. Клиент вправе подклю к любому такой службы, при этом вид и состав полученных им услуг никак не зависит от экземпляра. в Active Directory все контролле ры одного домена содержат идентичные данные и предоставляют одинаковые служ бы. При создании точки подключения службы следует обеспечить пользователям возможность поиска службы. При нескольких экземпляров службы поза ботьтесь о поддерживаемом клиентом поиска и о том, чтобы клиент мог выбрать экземпляр службы с требуемыми возможностями.
ГЛАВА 5 Публикация служб Active Directory Атрибуты класса Атрибуты класса serviceConnectionPoint службе публиковать всю для привязки к службы. Многозначный атрибут этого класса содержит строковые значения (ключевые слова), по зволяющие приложениям находить объекты точек подключения для кон кретного типа службы. Этот атрибут индексируется и реплицируется на сервер гло бального каталога. Служба, публикующая объект класса service Connection Point, добав ляет ключевые слова как отдельные значения атрибута keywords.
Подробнее о ключевых словах и о публикации объектов точек подключения служб - на Web-странице Web Resources по адресу ссылка Публикация средствами API-интерфейса RpcNs Для публикации сведений о себе в определенном имен службы RPC обращаются к функциям интерфейса RpcNs (RPC Name Service). Функции интерфейса RpcNs в Windows 2000 публикуют записи RPC в Active Directory.
Службы создают привязки RPC и публикуют их в Active Direc tory как обладающие атрибутами записи RPC Server. К атрибутам относятся известные клиентам уникальный идентификатор и Клиенты возможность выполнять поиск серверов RPC, предоставляющих желаемый импортировать привязку и подключаться к серверу.
Подробнее об интерфейсе RPC Name Service и Active Directory Ч в разделе Служба Name Service Б Windows 2000 и с Active далее в этой главе.
Публикация средствами API-интерфейса Службы Windows Sockets используют API-интерфейса RnR (Win dows Sockets Registration and Resolution) для публикации и поиска служб. Публи кация средствами RnR в этапа. Сначала устанавливается класс службы, связывающий с именем службы. Класс может содержать относящи еся к службе сведения. Затем службы публикуют сведения о себе как экземпляры класса клиенты получают возможность RnR искать в Active Directory экземпляры служб данного класса и выбирать эк для привязки. Ставшие ненужными классы удаляются.
Поиск и просмотр сведений о службе в Active Directory Services Ч это прямой потомок контейнера Если относя щиеся к службам объекты Ч прямые потомки класса serviceConnectionPoint, поиск опубликованных служб выполняется средствами (Active Directory Interface). Для этого найдите объекты, атрибут или кото рых serviceConnectionPoint. Атрибут keywords содержит к щику и приложению GUID. Для поиска по категории используйте атрибут ob jectCategory, а не ObjectClass.
Если относящиеся к службам объекты экземпляры класса, производного serviceConnectionPoint, то при поиске средствами ADSI следует искать ат рибут object которых равен serviceConnectionPoint, a соответствует Вашей точке подключения.
222 ЧАСТЬ 1 Служба каталогов Active Directory Примечание Атрибут a Ч Поэтому объект рекомендуется искать по категории, так как поиск по индексированным ат рибутам быстрее.
Для клиенту атрибута и, атрибутов и Служба Name Service в Windows и интеграция с Active Directory Для поиска (exported) серверов RPC клиентские процессы ис пользуют функции API-интерфейса службы RPC Name Service. Сервер RPC экс портирует сведения о себе средствами Для к RPC-серверу клиенту необходима привязка, предоставляющая интерфейс нужной ему версии и обладающая необходимым набором протоколов. Для поиска совмес тимых клиент использует функции интерфейса RpcNs. Служба RPC Name Service предоставляет привязки, необходимые для удаленного вы зова процедур и взаимодействия с Хотя функции интерфейса RpcNs и списки ACL, Active Directory эти списки поддерживает и разрешает сопоставлять их записям RPC Name Service.
Реализация RPC Name Service для Windows 2000 поддерживает списки ACL в Active Directory и предотвращает неавторизованный экспорт. Кроме того, служба управляет полномочиями клиентов на импорт на основе списков механизмы списков ACL используют передаваемые вне обычного потока данных между На потоков позволяют поток байт между процессами. Пе редаваемые таким способом называются вложенными (inline).
иногда на любом из концов канала требуется передать данные друго му приложению, не нарушая обычных правил передачи вложенных данных. Для этого используется пересылка внешних данные - передаются получателю на тот же что и но с более высоким приоритетом.
очевидно: вложенные данные передаются отправителем непосредственно получателю, которому не приходится ожидать завершения входящего потока. Да лее перечислены некоторые методы списков ACL, позволяющие процес сам передавать данные:
Х при установке домена создается контейнер По умол чанию все записи службы RPC Name Service, созданные в контейнере RpcServices, наследуют списки данного контейнера. Присвоение стандарт списка управления доступом данному контейнеру гарантирует ко всем записям службы RPC Name Service в домене;
Х оснастка Active Directory Users and Computers (Active Directory Ч пользовате ли и компьютеры) позволяет настраивать списки любых объектов Directory;
Х компонент RPC Locator (Локатор RPC) олицетворяет дочерний процесс [то есть использует его безопасности (security identifier, при об ращении к службе каталогов для обеспечения проверки списка ACL. Экспорти рованные доступны локально, но не на постоянной основе. Они ГЛАВА 5 Публикация служб в Active Directory мы только при совместимого с Windows NT мер при широковещании, рассмотренном в следующем В процессе поиска службой Server в доступе по при чине управления доступом обрабатываются как отсутствие соответствую щей Работа службы Windows 2000 Name Service Все записи создаются как объекты Active Directory. В каждом Windows существует контейнер службы Name Service (Служба имен с составным именем:
На рис. 5-3 роль службы RPC Name в Windows при сервера, клиентского компьютера и Active Directory.
5.
локатор Процесс RPC-сервера клиентскому - 2. Локатор в Rpcss создает 1 ' постоянную экспортирует запись каталоге Active Directory д Сервер Клиент Пространство Active Directory 4. Клиентский локатор, не контроллера домена имя компьютера в кэше, Windows выполняет поиск в каталоге и Рис. 5-3. Роль службы RPC Name Service в Windows Широковещание Не обнаружив запись в кэше, локатор выполняет поиск в Directory.
Потерпев неудачу, локатор RPC применяет широковещание, используемое в Win dows NT 4.0, все узлы в сети о своем существовании. Широковещание же важно для обеспечения взаимодействия между Windows 2000 и Windows NT 4.0, поскольку компьютеры Windows NT 4.0 не к Active Directory, их мож но обнаружить лишь посредством широковещания. Если сервер работает под Windows 2000, а контроллер домена, с которым этот сер вер взаимодействует, под управлением Windows NT данные об мом сервере RPC не сохраняются в Active Directory.
Таким образом, широковещание необходимо для нормальной работы. В среде Windows 2000 основного режима со всеми контроллерами работающими 224 ЧАСТЬ 1 Служба каталогов Active Directory иод управлением Windows 2000, неразумно рассылать ния при каждой неудачной попытке поиска, поэтому здесь широкове щательного метода следует отключить.
Чтобы локатор RPC поддерживал Windows NT 4.0, найдите в контейнере RpcServices атрибут Flags и значение 1. Поддержка метода по умолчанию.
Примечание под управлением Windows 2000 не инициируют широко вещательный поиск, если поддержка локатора Active Directory включена, а широ ковещание Настройка на стороне клиента Если в домене есть компьютеры под управлением Windows NT 3.51 или более по здней версии, следует выполнить настройку поиска средствами RPC Name Service.
Порядок поиска в Windows 2000 определяется средствами оснастки Active Directory Users and (Active Directory Ч пользователи и компьютеры). Кроме того, ради совместимости с Windows NT 4.0 для широковещательного поиска использу ется протокол NetBIOS.
Активизация поиска средствами службы RPC Name Service в оснастке Active Directory Users and Computers Откройте оснастку Active Directory Users and Computers (Active Ч поль зователи и компьютеры) и отметьте в View (Вид) команду Advanced Features функции), если она не была отмечена ранее. Раскройте узел System, щелкните контейнер RpcServices правой кнопкой мыши и выберите в кон текстном меню команду Properties (Свойства). В открывшемся окне свойств RpcServices на вкладке General (Общие) установите флажок Enable RPC Name Service lookups for 2000 computers (Разрешить службе имен RPC вы полнение поиска для 2000 компьютеров). Но умолчанию служба RPC выполняет поиск для компьютеров под управлением Windows NT 4.0 и более ранних версий.
Использование RPC и NetBIOS При работе почтовых ящиков локатора RPC применяется протокол NetBIOS. Ло катор RPC использует их для а их соответствую отклики для уведомления в рамках домена. Данная функция реализована лишь для совместимости с Windows NT 4.0. Windows 2000 по умолчанию поддер живает NetBIOS поверх TCP/IP. можно для отдельных ком пьютеров или при настройке (Dynamic Host Configuration Protocol).
Примечание Подробнее об отключении NetBIOS поверх TCP/IP Ч в книге TCP/IP. Ресурсы Microsoft 2000 2001).
Безопасность служб Служба выполняется в одном из двух контекстов безопасности:
Х в записи Х в учетной записи домена Windows 2000 (эта запись ГЛАВА 5 Публикация Active Directory Контекст в котором выполняется служба, влияет на ее права доступа к компьютеру и сети.
Служба может выполняться в учетной записи LocalSystem или учетной службы. - стандартная учетная запись без которую разрешается использовать лишь системным На компьютерах под управлением Windows NT 4.0 и более ранних версий служба, выполняющаяся в контексте LocalSystem, контекст безопасности диспет чера Service Control Manager (Диспетчер служебных программ). Такая служба не связана с какой-либо учетной записью зарегистрированного в системе пользовате ля, и у нее нет реквизитов для подлинности (имя домена, имя и пароль пользователя), Она обладает доступом к ресурсам сети, таким, как общие папки и каналы, поскольку у нее нет необходимых реквизитов и она под ключается но нулевому сеансу.
На компьютерах под Windows 2000 служба, выполняющаяся в контек сте LocalSystem, для доступа к ресурсам сети реквизиты компьютера и обладает полным доступом к локальным ресурсам системы. Служба, выполняюща яся в контексте LocalSystem па контроллере обладает полным доступом к ресурсам каталога, поскольку на контроллере домена хранится реплика каталога, а LocalSystem обладает доступом ко всем локальным ресурсам.
В общем случае в любой системе служба должна выполняться отдельной учет ной записью (независимо от ее роли), в том числе на контроллерах домена. При установке службы следует создать учетную и списки управле ния доступом, предоставив этой учетной записи необходимые права.
Не запускайте службу в контексте LocalSystem на В против ном случае служба получит слишком обширные полномочия в отношении Active Directory, так как LocalSystem на контроллере домена обладает доступом к каталогу. В случаев нельзя разрешать выполнение приложений в дан ном так как это создает серьезную угрозу сохранности и информации каталога.
Учетная запись LocalSystem и учетная запись службы Контекст LocalSystem на службы, работающие с Directory. Если служба запущена под учетной записью LocalSystem на компьюте ре члене (например, на рядовом сервере под Windows Server или компьютере под управлением Windows 2000 Professional), при доступе к ресурсам домена (например, к Active Directory) она выполняется в контексте учет ной записи компьютера. Обычно учетные записи компьютеров имеют очень привилегий и не относятся к каким-либо группам. Добавлять записи ма шин в группы не рекомендуется, поскольку при переходе компьютера из одного домена в другой они удаляются и создаются заново. конфигурация списка ACL для компьютера в Active Directory предоставляет учетным записям компьютеров минимальные права. Поэтому службы, выполняющиеся под учетной записью LocalSystem, обладают чрезвычайно ограниченным доступом к Directory.
Служба с доменной учетной записью и паролем получает все преимущества дартной доменной учетной записи. Ее разрешается добавлять в различные и при перемещении компьютера в другой домен она не 226 ЧАСТЬ 1 Служба каталогов Active Directory ужо с учетными к группам позволяет им до ступ к определенным областям Active Directory в зависимости от прав той или иной группы. Впрочем, работа службы в контексте записи службы имеет некоторые 1. нормальной работы службы создать за пись этой службы. Программа установки службы, создающая эту запись, дол жна запускаться пользователем, создавать записи в службе каталогов.
2. Пароли учетных записей служб хранятся на компьютере, где установлена служ После смены пароля служба сможет пока Вы не обновите пароль.
Внимание! Если служба под учетной LocalSystem, мо протестировать службу на рядовом сервере и убедиться, что она обладает доста точными правами, чтобы считывать и записывать данные из/в Active Directory. He следует проверять работу службы только на контроллере домена. что служба, выполняющаяся под учетной записью LocalSystem на контроллере домена, обладает полным доступам к Directory;
рядовые серверы работают в кон тексте учетной компьютера, права которой более ограничены.
Взаимная проверка проверка (mutual Ч это функция безопасно сти, при использовании которой до начала обмена между приложениями клиента и сервера процесс подтверждает свою подлинность серверу, а сер вер Ч клиенту. Поддержка взаимной проверки (аутентификации) обеспечивается интерфейсом SSP1 (security support provider interface) и реализует ся непосредственно через функции и службы интерфейса SSPI, а также средствами RPC и Взаимную аутентификацию поддерживают далеко не доступные интерфейсу SSPI и даже не все службы под Windows 2000, должно запросить аутентификацию, а вспомогательное при ложение безопасности - корректно ее выполнить.
Взаимная проверка подлинности чтобы каких либо функций па уровне приложения и сервер обязаны друг другу свою Аутентичность может доверенной третьей стороной с использованием общих секретных ключей, как в протоколе v5, или других криптографических средств, как, например, в инфраструктуре откры тых ключей. Каждая из сторон идентифицируется по имени безопаснос ти (principal name).
Имя участника безопасности Главное правило аутентификации таково: ни одна из сторон должна доверять другой, пока будет подтверждена ее подлинность. На практике это оз начает, что сервер должен уметь определять личность не опрашивая а клиент обязан выполнять эту же операцию в отношении сервера. Это исключает нарушение безопасности посредством простого ГЛАВА 5 Публикация Active Directory Взаимная проверка подлинности и протокол Kerberos Клиенты используют локальный контекст либо выполнения в контексте, ранее (например, в сеансе либо явно предоставляя реквизиты используемому Сервер не принимает соединения от подлинность которых не подтвержде на. Клиент проверяет подлинность сервера, составляя имя службы (service principal name, SPN) на основе сведений о сервере, которые ему уже известны или которые он получает из других доверенных источников (за исключением еще проверенного Затем клиент представляет SPN системе безопасности, за прашивая у сервера аутентификацию по данному имени. Клиент разрывает связь с:
сервером, который не в состоянии пройти проверку подлинности по данному SPN.
Примечание Если учетная запись службы не в том лесе, размещает ся учетная запись клиента, при взаимной аутентификации произойдет сбой, по скольку протоколу Kerberos не удастся найти учетную запись службы.
Необходимо, чтобы и служба, и клиент выполнялись на компьютерах под управле нием Windows 2000, иначе взаимная аутентификация с Kerberos поскольку предыдущие версии Windows не поддерживают про токол.
В основное имя службы входит DNS-имя узла, на котором выполняется служба;
не поддерживаются - Вам придется использовать служб только в форме DNS.
Основное имя службы Это имя связано с участниками безопасности (пользователями или группами), в контексте которых выполняется служба. Оно позволяет выполнять взаимную между клиентским и службой. SPN строится на ос нове известной клиенту информации о службе, либо клиент получает необходимые сведения от третьей например из Active Directory. SPN связа но с записью, причем одна учетная запись может обладать Подробнее о регистрации основных имен служб в Active при службы - на Web-странице Web по адресу ссылка Синтаксис основного имени службы Синтаксис основного имени службы выглядит следующим образом:
где:
Х Ч тип службы, например для службы World Wide Web или для протокола Lightweight Directory Access Х Ч имя службы. В зависимости от типа службы это имя или IP-адрес узла, на котором служба;
Х порта, используемого службой на (если он личается от стандартного номера порта для данного типа службы);
228 ЧАСТЬ 1 Служба каталогов Active Directory Х Ч имя службы. Это может быть узла службы или домена. того, в качестве имени используют составное имя объекта класса Service Connection Point или RPC Service.
Если и совпадают (что характерно для служб на узлах), SPN разрешается сократить до двух элементов:
<тип Если отличается от стандартного номера порта для службы дан ного типа, его следует указывать соответствующий стандартному номеру порта для данного _ указывать не требуется. Такой формат совместим с API-интерфейсом GSS (Generic Security Services).
Подробнее о GSS и SSPI Ч в главе Проверка Создание имени службы Основное имя службы создает клиент;
это DNS-имя домена, DNS-имя узла или составное имя объекта класса из семейства Service Connection Point, любом спо собе аутентификации применяется одно При проверке средства ми Kerberos клиент запрашивает билет сеанса для SPN;
при проверке подлинности на основе сертификатов сверяются SPN и поле сертификата сервера.
в DNS служба на узле Служба па узле - это служба, идентифицируемая по имени узла, на котором она выполняется. Формат имени таких служб таков:
Если служба использует стандартный порт для значения типа служ бы, SPN можно до Службы, опубликованные в Active Directory Формат основного имени служб, опубликованных в Active Directory, таков:
где:
Х искомый тип службы, например print;
Х - составное имя указанного в типа службы в формате, определенном в документе RFC например Х Ч DNS-имя узла, на котором выполняется экземпляр службы Х Ч имя домена, содержащего учетную запись, под которой выпол няется указанная в служба. Формируется из элемента 5 Публикация служб в Active Directory Например, служба печати для группы в 26 Reskit использующая нестандартный порт узла имеет следующее основное имя:
Подробнее об основных именах служб па Web-странице Web Resources по ссылка MSDN, Дополнительные материалы Подробнее о создании служб для публикации в Active Directory Ч на це Web Resources по адресу ссылка Microsoft Platform SDK.
Репликация Active Directory Active Directory - распределенная служба каталогов в Microsoft Windows 2000.
Объекты в каталоге между контроллерами домена в лесу, и все кон троллеры домена допускают прямое обновление. Репликация Ч это при котором изменения, па одном контроллере передаются на все другие контроллеры в целом домене или лесе. поддержания целостности ных отслеживаются изменения на каждом домена и систематически другие контроллеры. Механизм репликации Active Directory ется на автоматически формируемой топологии подключений, что позволяет опти мально использовать сетевые подключения и освободить от вы полнения таких задач В этой главе Модель репликации Active Directory Обновления Active Directory Топология репликации См. также Х о планировании сайтов, топологии сайтов и размещении контролле ров домена Ч в книге Windows 2000 Server Deployment (Microsoft 2000).
Х о базе данных и хранилище объектов Active Directory Ч в Хранение данных в Active Х Подробнее о дереве каталогов Ч в главе 1 структура Active Directory.
Х об неполадок репликации в Active Directory - в главе Выявление и устранение неполадок, а также восстановление Active Х о репликации Active Directory и восстановлении до мена - в главе 9 и восстановление в Active ГЛАВА 6 Репликация Active Directory Модель репликации Active Directory В древовидной структуре каталога Active Directory объекты леса Windows 2000. Дерево каталога разбито на разделы таким образом, чтобы их мож но было распределить между контроллерами разных доменов в одном лесе. В моде ли репликации Active Directory описан порядок распространения и контроля вы полнения на контроллерах домена. Каждый контроллер домена в лесе хранит копию определенной части каталога. Отдельные сегменты каталога ются разделами (directory partition). Копия содержимого одного раздела каталога на определенном контроллере домена репликой (replica). В ходе репликации реплики одинаковых разделов каталога синхронизируются на всех кон троллерах.
Реплики раздела каталога Существует два вида реплик разделов каталога Ч полная (master replica) и частич (partial replica), В полной реплике содержатся все атрибуты всех объектов каталога, при этом они доступны не только для чтения, но и для записи (то есть это изменяемая реплика). Каждый контроллер домена храпит по крайней мене три полных изме няемых реплики раздела каталога:
Х раздела схемы (Schema), которая содержит определения всех классов и атрибу тов. Раздел схемы един для всего леса;
Х раздела конфигурации (Configuration), которая содержит о гурации (и другую информацию) всего Раздел конфигурации един для всего леса;
Х реплику раздела домена (Domain), которая содержит все объекты, относящиеся только к домену. Раздел домена един и уникален для каждого в лесе.
реплика раздела хранится на всех контроллерах этого домена (и нигде более);
полные реплики разделов и схемы размещаются на всех контроллерах домена леса (и нигде более).
Частичная реплика содержит определенное подмножество атрибутов для каждого объекта раздела каталога и доступна только для чтения. Частичные реплики хра нятся только на серверах каталога (Global Catalog). Атрибут содержит ся в частичной реплике тогда и только тогда, когда у соответствующего объекта класса значение атрибута равно Таким образом, на каждом контроллере домена в единой базе хранятся ко пии объектов, относящихся только к данному домену, а также копии объектов схе мы и относящихся ко всем доменам в лесе. В базе данных лера домена, выполняющего роль сервера глобального каталога, также хранятся ча стичные реплики объектов раздела каталога из других доменов. Это позволяет вы полнять объектов единовременно во всем каталоге, не сы от контроллера к контроллеру.
232 ЧАСТЬ 1 Служба каталогов Active Directory Следует иметь в виду различие между деревом каталогов (лес 2000) и физической базой данных на контроллере домена. Каталог содер жит все объекты леса, а база данных каталога па каждом отдельном контроллере домена в лесе содержит реплики объектов только данного домена, а также реплики конфигурации и схемы всего леса.
Подробнее о разделах каталогов и о серверах глобального каталогаЧ в главе данных в Active Directory. Подробнее о поиске в каталоге Ч в главе решение имен в Active Directory.
Преимущества репликационной модели перечислены основные достоинства модели репликации Active Directory.
Х Active Directory безошибочно реплицирует изменения на требуемый объект и различает удаленные объекты и новые объекты с тем же именем (distinguished name). Это вызвано тем, что процесс репликации основан на гло бально уникальных идентификаторах (globally unique identifier, объек тов каталогов, а не на их именах.
Х Модель репликации минимизирует конфликты при обновлениях и поддержи вает обнаружение и устранение конфликтов на уровне атрибутов. Для обновле ния передаются только атрибуты, значения которых изменились, а не весь объект.
Х Объем данных, передаваемых через глобальные сети (wide area network, WAN), сведен к минимуму благодаря поддержке репликации типа хранить и replication) и сжатия данных, реплицируемых между сайтами. серверах хранится только подмножество объектов, состоящее из объектов, ко всему лесу, и отно сящихся только к домену, в котором сервер. Серверы глобального каталога хранят сведения обо всех объектах леса, тем не менее они содержат не а только определенное атрибутов таких объектов.
Х Топология репликации (в том числе выбор гибка и позволяет наи лучшим образом использовать самые разнообразные сетевые топологии. Сайты представляют собой линтеллектуальную базу автоматической генерации топо логии репликации, позволяя клиентам выполнять выбор контрол лера домена.
Х конфигурация остается гибкой, потому что сайты не связаны со структурой каталога.
Х Увеличено быстродействие медленных подключений, благодаря минимизации полных циклов репликации.
Х Минимальна зависимость от других служб, например службы синхронизации времени Windows Компоненты модели репликации Репликация реализуется посредством механизмов.
Х Свободное согласование с несколькими хозяевами со обеспечива ющее целостность данных.
ГЛАВА 6 Репликация Active Directory Х Согласование с хозяевами consistency) что раздел каталога состоит из множества изменяемых реплик, которые синхро низируются (согласуются) на всех контроллерах домена в одном лесе.
тема репликации изменения, выполненные на одном троллере домена, на все остальные контроллеры в лесс, хранящие полную реплику соответствующего раздела каталога.
Х согласование (loose consistency) означает, что в любой момент вре мени реплики не обязательно согласованы друг с ведь коррективы могут вноситься постоянно.
Х что, если разрешить системе дос тичь устойчивого состояния, в котором не выполняются новые а все предыдущие полностью реплицированы, все реплики будут содержать один и тот же набор значений, Х Механизм сохранить и переслать дальше подразумевает, что изменения не напрямую с одного контроллера домена на все остальные кон троллеры, Ч обновление напрямую только на некоторое жество контроллеров домена. Задача дальнейшего распространения обновления возлагается на это подмножество контроллеров домена и так далее, пока изме нение не реплицируется на все контроллеры.
Х Репликация по (pull подразумевает, что контроллеры домена самостоятельно обновления у партнеров по репликации. Контрол лер домена, выполнивший изменение, не распространяет его по собственной инициативе.
Х Репликация, на (state-based replication), когда вместо все го журнала изменений в репликах разделов каталога хранятся данные реплика ции па уровне отдельных объектов и атрибутов.
Репликация с несколькими хозяевами В Active Directory для синхронизации каталога применяется репли кация с несколькими В противоположность этой модели в схеме хозя ин (master-slave) все выполняются в основной реп лике каталога и затем в подчиненные реплики. Эта система годна для каталогов с малым числом реплик и для сред, где возможно ванное выполнение всех изменений. Но она не годится для крупных и распреде ленных организаций. В Active Directory нет выделенного контроллера Ч все внутри домена равнозначны. Изменения разрешается выполнять на любом из них, в отличие от с одним хозяином, где измене ния должны выполняться только на одном сервере и где главный сервер реплици рует изменяемую на все другие каталогов в домене.
В механизме репликации с хозяевами контроллер домена не обязан передавать изменения на все остальные контроллеры. Вместо этого в под держивается устойчивый набор определяющий порядок обновлений между контроллерами домена, чтобы сеть не была перегружена трафи ком в результате чего возможна задержка репликации, что весьма не удобно Набор подключений, посредством которых контроллеры домена реплицируют изменения на называется топологией реплика ции (replication topology).
234 ЧАСТЬ 1 Служба каталогов Active Directory с несколькими хозяевами обеспечивает высокую доступность при опе рациях записи в объекты каталога, так как изменяемые реплики хранятся на нескольких серверах. Каждый контроллер домена вправе выполнять обновления независимо, не обращаясь к другим контроллерами домена. Любые конфликты при обновлении объектов каталога система разрешает автоматически. Если не изменять объекты каталога, то при продолжении репликации все копии объекта в конечном итоге станут одинаковыми.
Способ хранения информации в службе каталогов самым непосредственным обра зом влияет на производительность и масштабируемость службы. Службы катало гов обрабатывают больше запросов, чем обновлений: типичное соотношение запро сов к обновлениям Ч Создавая несколько копий каталога и поддерживая их в согласованном состоянии, служба каталогов возможность обрабатывать больше запросов в единицу времени.
Далее перечислены преимущества репликации с несколькими хозяевами по срав нению с репликацией с одним Х при выходе контроллера домена из строя обновление каталога живается оставшимися контроллерами. При репликации с одним хозяином от ключение или неполадка главного контроллера домена делает невозможным обновление каталога. Например, если срок действия Вашего па роля истек, а сервер, на котором хранится информация о пароле, вышел из строя, Вы не сможете сменить а и войти в домен.
Х серверы, которым разрешено выполнять в каталоге (в Windows это контроллеры домена), распределяются в сети и физически располагаются во многих разных местах.
Репликация типа сохранить и переслать дальше Репликация типа сохранить и (store and forward replication) для сокращения связи по медленным Обновление реплицируется сначала в близлежащие реплики, а оттуда Ч далее.
Такая устраняет необходимость все изменения напрямую сервера-источника на остальные серверы, поддерживающие реплики соответству ющего раздела каталога. Принявший сервер пересылает изменение на близлежащие серверы. Один из таких серверов переправляет изменения далее на удаленный который в свою очередь их на близлежащие к нему сер веры. типа сохранить и переслать существенно сокращает трафик репликации по WAN-сетям.
Система в состоянии создавать топологию автоматически, что упрощает админист рирование всех подключений между контроллерами домена. Управление цией выполняется косвенно -- путем определения упрощенной сетевой модели в каталоге. Она оперирует такими понятиями, как сайты, связи сайтов и мосты связей сайтов. На основе этой модели Active Directory создаст реп подключения. При сбоях Active Directory изменяет схему подключе ний, чтобы репликация успешно продолжалась. вручную создавать подключения для репликации: они сосуществуют с автоматически сгенерированны ми. Поэтому при создании нового подключения Вам не придется отказываться от удобного автоматического управления остальными подключениями.
ГЛАВА 6 Репликация Active Directory Репликация по запросу В Active Directory применяется репликация по (pull replication), при рой (destination replica) запрашивает у реплики-ис точника (source replica). В запросе определена информация о потребностях серве ра-приемника, основанная на его сведениях об изменениях, уже полученных от сер вера-источника и от контроллеров домена. Получая информацию от сер сервер-приемник на ее свои данные. Впослед ствии не запрашивает у сервера-источника уже полученные и при мененные обновления.
Альтернативный способ обновления Ч извещающая (push при которой сервер-источник по собственной инициативе пересылает информацию серверу-приемнику для обновления. репликация способна создавать проблемы, так как серверу-источнику трудно представить, в какой информации сервер-приемник. Не что приемник уже получил данные.
Отправляя данные, источник не в состоянии узнать, применены ли они на прием нике. Система может потерять сервер-источник предполагает, что обновления должны применяться всегда.
Репликация на основе сведений о состоянии В Active Directory управление механизмом репликации выполняется на основе све дений о состоянии: каждый хозяин в системе с несколькими хозяевами применяет к своей реплике при их получении и не ведет журнал (СУБД, используемая Active Directory, ведет журнал транзакций, но журнал является частью самой СУБД, а не системы репликации.) В типичной журнальной системе репликации каждый хозяин ведет журнал генерируемых им обновлений. В такой системе цель каждого хозяина в том, чтобы передать свой журнал другим и применить зарегистрированные в журнале ко всем осталь ным репликам.
Репликация Active Directory базируется не на системе журналов, вместе с репликой-источником, а на текущем реплики, то есть на текущих атрибутов всех объектов. К состоянию относится информация, исполь зуемая для разрешения конфликтов и предотвращения пересылки полной реплики в каждом цикле репликации. Каждой операции записи (originating write) контроллер домена присваивает порядковый номер. реплики хранят информа цию о своей свежести по к остальным репликам, и значения в ката логе отмечаются порядковыми номерами исходных записей обновления. На основе этих сведений сервер-источник репликации отбирает изменения состояния, репликации.
В репликации на основе состояния применяется единый механизм для (incremental) и полной (full) а база данных обновляется реже, так как повторные или конфликтные обновления атрибутов все равно разрешаются в одно состояние, Вообще говоря, все объекты реплики раздела Active Directory хранятся в упорядоченном по дате последней модификации. Фактически журнал но очень грубый, и его размер ничтожен по сравнению с размером самой ки. Обычный запрос на репликацию выполняется путем всего несколь 236 ЧАСТЬ 1 Служба каталогов Active Directory последних в этом списке, так как серверу-приемнику известно, какая часть списка источника репликации уже обработана.
Режим работы репликации Репликация и внесения определенных изме нений в отдельную реплику можно с утверждать, что эти обновле распространятся на все другие реплики.
Чтобы понимать, как работает репликация в Active Directory, очень важно следующие положения:
Х объект доступен и подлежит репликации, как только он записан (или Запись в отдельные объекты (то есть либо выполняется полностью, либо не выполняется вообще), и частичные запись или изменение объектов не Х объекты не обязательно реплицируются в том порядке, в котором они обновля ются;
Х в цикле обновления пересылаются все доступные изменения из реплики-источ ника в реплику-приемник, том числе происходящие во время ре пликации;
Х репликация выполняется в стиле сохранить и передать и охватывает весь набор взаимосвязанных реплик;
Х разрешение конфликтов с хозяевами очень надежно;
этот действует, даже если нарушится синхронизация часов или они пойдут в обрат ную сторону;
Х граф подключений репликации всегда является деревом (spanning tree) (которое, по не содержит избыточных связей и петель) этот граф может содержать (и обычно содержит) циклы. Избыточные подклю чения уменьшают репликации, особенно в случае отказов. Механизм распространения (propagation dampening mechanism) позволяет устранит избыточную Х репликация внутри сайта инициируется механизмом уведомления об изменени ях в ответ на после короткой длительность которой решается настраивать. Наличие обусловлено тем, что выпол няется сразу обновлений;
Х репликация между сайтами обычно выполняется по заранее определенному рас писанию об изменениях между сайтами при этом не требуется);
Х система устойчива к пиковым и временным неполадкам;
Х стабильность заножена в конструкцию системы репликации. Каждое от источника делает данные приемника более свежими.
Восстановление после отказа требует совсем немного работы:
Х репликация типа сохранить и передать эффективно исполь зовать WAN-каналы связи: каждое передается по дорогостоящему каналу только раз и в сжатом виде;
Х топология репликации управляется а имеющиеся 6 Репликация Active Directory Б Exchange Server версии 5.5 сайты и применяются ко по-другому, чем в Windows 2000. В таблице существенные раз личия между в Exchange Server и в Active Directory, Работать с Active Directory, как с каталогом и неэффективно.
Таблица Различия между службами каталогов в Windows и в Exchange Server 5. Служба каталогов Windows 2000 Служба каталогов Exchange Server Полные Каждый объект службы каталогов управляется в без обращения к отдельном сайте, что определяется по составно другим полным репликам му имени этого объекта. В рамках такого сайта обновления выполняются по механизму с несколькими хозяевами основана на основана на составных именах, по объектов. При чтобы избежать проблем, служба Exchange переименовании объекта Server не переименовывает объекты не в результате чего нет и ошибок репликации При репликации передаются только Для репликации изменений требуется атрибуты весь объект Поддерживает сжатие Поддерживает сжатие данных, реплицируемых между по между сайтами, только по транспорту SMTP транспортам RPC или SMTP Поддерживает серверы, на которых На каждом сервере каталогов хранится полная хранится только подмножество реплика каталога. (Схема в службе Exchange объектов всего каталога, а также Server для каждого сайта и не серверы глобального каталога, вовне.) содержащие реплики всех каталога Обладает гибкой топологией Топология между сайтами ограниче кации (в том числе позволяет на деревом, которое не может содер жать связей. Репликация информа видуально задавать транспорты ции между сайтами выполняется только по подключений) электронной почте Сведения о сайтах применяются при Существующие сайты применятся при создании топологии репликации и при нии топологии репликации, но сайты также выборе реплики являются элементами деления каталога на клиентами. Однако сайты не разделы к разделам каталога Обновления Active Directory Репликация обновлений запускается при обновлении пользователем (приложени ем или службой) объектов на контроллере домена. При изменении объектов запус кается таймер, собираются изменения за определенный период времени, после чего механизм репликации уведомляет об изменениях смежные контроллеры домена в топологии репликации в пределах сайта, а также в других сайтах, если активизиро вано уведомление между сайтами. Получив уведомление, изменения у контроллера-источника. Репликация между сайтами обычно выполняется домена изменения у кон троллеров домена в других сайтах согласно расписанию.
238 ЧАСТЬ 1 Служба каталогов Active Directory Исходные обновления: инициирование изменений Сервер каталогов LDAP четыре типа запросов на обновление:
Х добавление объекта в каталог;
Х изменение удаление или изменение) атрибутов объектов в каталоге:
Х перемещение путем изменения его составного имени или родителя объекта;
Х удаление объекта из каталога.
Каждый запрос обрабатывается сервером каталогов LDAP как отдельная атомар ная транзакция. Запрос записи либо полностью, либо отклоняется и не оказывает никакого влияния па каталог. Выполненный и запрос на изменение называется исходным (originating update).
Исходное обновление инициируется и фиксируется в одной репли Коррективы даже для запросов на изменение, затрагивающих не сколько атрибутов отдельного объекта. В таком случае при сбое хотя бы одного атрибута вся операция и объект не изменяется.
Обновление, выполненное на одном контроллере домена и реплицированное на другой контроллер, называется обновлением (replicated update).
Система репликации четко различает эти два вида обновлений.
В исходном обновлении учитываются все ограничения схемы (допустимые типы ро дительских объектов для обязательные и атрибуты для объек та, синтаксис атрибута), действующий на контроллере во время обновления.
Отслеживание обновлений В некоторых службах каталогов для какие подлежат распространению, применяются метки времени (timestamps). В таких важ на времени на всех серверах каталогов. Но точная синхронизация в большой сети практически неосуществима: при любом нарушении связи показания часов разойдутся. времени между всеми ко пиями каталогов способна повлечь потери данных или нарушение их целостности.
В механизме репликации Active Directory метки не применяются при рас изменений. В этом случае используются порядковые номера ний (update sequence numbers, присваиваемые локальным счетчиком кон троллера домена. Счетчики USN работают на локальном уровне, поэтому легко обеспечить их надежность и лобратный отсчет номеров Сложность в том, что сравнивать номера на разных контроллерах домена бес смысленно. Это ограничение учтено при создании системы репликации.
В некоторых службах каталогов метки времени Ч основной критерий выбора при конфликтов. Обычно в каталог вносится более поздняя запись. Опять-таки, если часы неточны, это проблематично. Пред положим, что при тестировании поведения системы в 2000 году* часы установле ны вперед на 31 декабря г. и что в ходе теста обновлен атрибут некоего объек та. После завершения тестирования устанавливается текущее время и дата. Если служба каталогов считает приоритетной старшую запись, тестовое обновление не удастся изменить вплоть до По-видимому, этот раздел написан до 2000 года, поэтому в данном абзаце кущее следует как дату до года. Ч Прим.
ГЛАВА 6 Репликация Active Directory В Active Directory метки времени не используются как основной опреде ления записи при разрешении конфликтов. Вместо этого за основу бе рется число изменений, а метка времени рассматривается в качестве вспомогатель ной величины. Если атрибут обновлен по одному разу на контроллере А и на кон троллере В, в каталог вносится более обновление. Но если атрибут обнов лен дважды на контроллере А и только один на В, применяется контроллера А, независимо от метки времени выполнен ного на контроллере В Ч даже если часы на контроллере В в тот момент переведе ны далеко вперед. В Active Directory часов предотвращает перезапись значения.
Репликация изменений с учетом USN Текущий Ч это хранимый каждым контроллером домена Active Directory 64 разрядный счетчик. В начале каждой транзакции или контроллер увеличивает значение своего счетчика и ляет это новое с запросом на обновление. Этот USN сохраняется в двух (для репликативной записи) или трех (для исходной записи) местах обновляемого объекта.
Х обновления сохраняется вместе с каждым атрибутом, измененным в этом цикле как USN (local USN) этого атрибута (для исход ных и обновлений). Узнать локальный можно средствами служебной программы командной строки Для этого введите в дной строке:
В столбце отображен порядковый номер обновления. (Для исполь зования Repadmin установите средства поддержки Active Directory из папки с компакт-диска Windows 2000 Server. Для этого дважды щелкни те значок Setup в этой Подробнее об установке и использовании программ и их справочной системы Ч в файле в напке об использовании Repadmin Ч в справочной системе Microsoft Support Tools.) Х Максимальный локальный номер USN из всех атрибутов объекта сохраняется как атрибут этого объекта (для исходной и репликативной записи).
Для получения сведений об этом атрибуте служебная программа Ldp или Edit. Ч программа с графическим интерфейсом, применяе мая для подключения к любому каталогу и выполнения в нем поиска, и удаления объектов. ADST Edit - это оснастка для управления объектами Active Directory, в том числе просмотра и рования атрибутов. (Для получения доступа к Ldp и ADSI Edit, установите средства поддержки Active Directory. об использовании Ldp и ADS Edit в справочной системе Microsoft Windows 2000 Support Tools.) Х При создании исходной записи обновления сохраняется в каждом обнов ляемом атрибуте как его USN (originating USN). В отличие от ного и исходный вместе с самим атрибу том. команду repadmin Вы сможете просмотреть исход в столбце Org. USN.
240 ЧАСТЬ 1 Служба Active Directory Примечание Атрибут usnChanged индексирован, что позволяет без тру да нумеровать объекты в порядке времени записи их атрибутов.
Для определения текущего USN контроллера применяется программа или Edit. Эти средства считывают в атрибут объекта контроллера (Подробнее об этом в главе 2 данных в Active USN Наивысший USN ( Ч это поддерживаемое контроллером приемником для контроля за получением изменений определенного объекта от конкретного Контроллер-источник использует это значение для отбора объектов, подлежащих репликации на приемник.
Когда сервер-приемник запрашивает изменения в разделе каталога у источника, пос ледний пересылает изменения в порядке увеличения значения атрибута usnChanged, Полученное от источника значение usnChanged приемник в самом объекте не хра но следит за значением usnChanged самых копий объекта, успешно полученных от контроллера-источника. Такой называется наивысшим USN источника по к разделу каталога и При приемник отправляет значение наивысшего источни ку, и тот на основании этих сведений отбирает объекты, которые следует реплици ровать на приемник. В итоге все со значением usnChanged, меньшим или равным значению наивысшего не реплицируются, поскольку их обновления контроллер-приемник уже получил.
Отбор на основе наивысшего позволяет снизить нагрузку на процессор и объем дискового ввода-вывода.
Чтобы узнать значение наивысшего выполните команду:
/verbose Наивысшие USN располагаются в строках, начинающихся с до сочета ния Вектор данных vector) это которое контрол лер-приемник поддерживает для отслеживания обновлений, полученных от остальных контроллеров-источников. Контроллер-источник использует это чение для отбора на контроллер-приемник.
Когда контроллер-приемник запрашивает изменения для раздела каталога, он пре доставляет контроллеру-источнику свой вектор На это го значения, контроллер-источник обладает ли приемник самым свежим значением (или набором значений) атрибута, и при необходимости пересылает об новления. Если на источнике нет никаких атрибутов соответствующего объекта, он вообще не возвращает никакой информации об этом объекте.
Вектор обновления данных может содержать обо всех контроллерах доме на, на которых хранится полная раздела каталога. Если запись обновле ния данных, соответствующая контроллеру-источнику X, содержит значение на контроллере-приемнике уже обязательно все обновления опреде ГЛАВА б Репликация Active Directory ленного раздела каталога, выполненных на X и имеющих чение исходного меньшее или равное п.
Вектор обновления данных и наивысший USN Ч это вспомогательные механизмы отбора совместно позволяющие сократить задержку реп ликации. Наивысший предотвращает отправку контроллером-источником лишних объектов на а вектор обновления данных позволяет контроллеру-источнику отбросить лишние атрибуты (или целые объекты) на ос сведений об между источниками исходных и це левым приемником.
Контроллер домена поддерживает значения наивысших определенного разде ла каталога только для контроллеров, у которых а пись вектора обновления данных Ч для контроллеров, которые когда-либо являлись источником исходного обновления, то есть фактически для всех контрол леров, полные реплики данного раздела каталога.
Чтобы получить сведения о векторе выполните команду:
Подробнее об использовании служебной программы Repadmin Ч в справочной си стеме 2000 Support Tools.
Разрешение конфликтов на основе меток Предположим, что атрибут некоего объекта на контроллере X. Далее, до репликации данного изменения же атрибут того же объекта на кон троллере Y. Задача Active Directory - обеспечить, чтобы после репликации все реп лики содержали одинаковое значение обновленного атрибута.
Согласование достигается путем прикрепления уникальной метки (stamp) к дому реплицированному одно- или многозначному атрибуту в момент исходного его обновления. Эти метки реплицируются вместе с самим атрибутом. Реплициру емое заменяет текущее (включая метку), только если его метка чем метка текущего значения.
Метка состоит из трех компонентов:
Х версии (version) Ч ее значение па единицу при каждой исход ной записи. У атрибута, который прежде не изменялся, номер версии равен единице;
Х времени записи (originating time) Ч с точностью до секунды согласно системным часам выполнившего запись контроллера Х (originating DSA) Ч контроллера домена, выполнившего исходную запись.
Чтобы получить сведения о всех трех составляющих метки, выполните команду:
repadmin В столбце указывается версия, в столбце Ч время а в столбце Originating DSA (в виде а не При сравнении меток наибольшим приоритетом затем Ч время и самый низкий приоритет у DSA-источника. Таким образом, при нии версий сравнивается время записи оно почти наверняка совпадает, что и 242 ЧАСТЬ 1 Служба каталогов Active решает дилемму. В том чрезвычайно редком случае, когда один и тот же атрибут обновлен на двух домена в одно и то же время - секунда в о выборе принимается на основе Две разных первичных записи атрибута объекта не обладать метками, так как создании исходной записи но мер версии на соответствующем (Обратите что время записи не при определении уникальности.) При репликации номер версии не может снижаться, так как значения с меньшими версиями уничтожают ся механизмом разрешения конфликтов.
программы Ч в справочной си стеме Windows 2000 Support Tools.
Исходное добавление Запрос Add создает новый с уникальным атрибутом Всем значе реплицируемых атрибутов присваивается версия 1.
Запрос на создание объекта отклоняется немедленно, если указанный в нем роди тельский объект не существует или если исходный контроллер не содержит полной реплики раздела каталога, в котором размещен родительский объект.
Исходное изменение Все запросы Modify сводятся к запросам текущего значения атрибута но вым. В частности, запрос на изменение может требовать:
Х удалить атрибута из объекта. Удаление следует рассматривать как замену зна чения атрибута на NULL. Это значение не занимает память, но несет метку, как и любое значение атрибута;
Х добавить значение к текущему набору значений атрибута. (Это наиболее часто используется при работе с многозначными атрибутами.) Этот запрос эквивален тен запросу на замену: текущие значения заменяются значениями плюс добавленное значение.
При выполнении запроса на изменение сравнивается новое значение каждого ат рибута в запросе с существующим значением в объекте. Если значения запрос на атрибута игнорируется. Если выполнение запроса не меняет никаких атрибутов, игнорируется весь запрос, В противном случае изменяется версия метки каждого реплицируемого значения атрибута номер версии существующего значения (для атрибутов, которые никог да не номер версии Ч нуль) увеличивается на единицу. Старые зна чения меток заменяются новыми.
Исходное перемещение Запрос Move Ч это на самом деле особый на изменение отдельного атрибу та Операция аналогична только что описанному запросу на исходное из менение.
Исходное удаление Запрос Delete Ч это особый запрос па изменение, который следующие действия:
ГЛАВА 6 Репликация Active Directory 1. присваивает атрибуту 2. объект как (tombstone), есть из каталога;
3. изменяет составное имя на значение, которое в обычных обстоя тельствах неприменимо (не может присвоено 4. удаляет все атрибуты, которые не требуются Active Directory. У захороненного объекта остаются только несколько ключевых атрибутов:
и 5. перемещает объект в контейнер Objects Ч скрытый кон тейнер в разделе каталога.
об удалении объектов реплицируется репликации захороненных объектов. Захороненный объект невидим при обычном Ч для его об надо задействовать специальный элемент управления LDAP с иденти фикатором Ссылки, ранее указывавшие па удаленный теперь указывают на объект. Поэтому при такой ссылки воз вращается составное имя объекта, а составное имя объекта до его удаления.
Процесс захороненных объектов Хотя захороненные объекты считаются удаленными, они место в каждой раздела каталога. Поэтому в счете сами захороненные объекты удалять, дабы пресечь неконтролируемое разрастание базы данных катало га. Для этого предусмотрен сбора мусора.
Частоту и состав удаляемых объектов регулируют два параметра объекта Windows т период сбора мусора (garbage collection interval) задает частоту проверки чия и удаления захороненных объектов. по умолчанию Ч 60 дней, а наименьшее допустимое значение Ч 2 дня;
Х время жизни объекта (tombstone lifetime) определяет время в ча сах, когда объект существует в каталоге в виде захороненного, пока его не унич тожит процесс сбора Сбор мусора независимо на каждом контроллере домена. В процес се сбора мусора окончательно удаляются все захороненные объекты, время жиз которых истекло.
объекта должно быть существенно больше наибольшей репликации. В противном случае захороненный объект будет уничтожен до завершения репликации но все реплики. Реплика, не получившая захороненный объект, никогда не сможет удалить его и согласоваться с остальными репликами.
Влияние времени жизни захороненного объекта на восстановление из архива Восстановление из копии создает реплику раздела каталога, не подвер гавшейся репликации с момента архивирования. Если между архивированием и восстановлением прошло больше времени, чем время жизни захороненных объек объекты, удаленные в это время, не имеют аналогов. Новая лика раздела каталога никогда не узнает об этих удалениях. Поэтому с 244 ЧАСТЬ 1 Служба каталогов Active Directory резервной копии, возраст которой превышает время жизни захороненного объекта, невозможно.
Подробнее о захороненных объектах и - в главе 2 Хранение дан ных в Active Подробнее о Active Directory из резервной копии Ч в главе 9 Архивирование и восстановление данных в Active Отслеживание репликации и изменения Приведенные далее диаграммы иллюстрируют репликативных данных объекта и его атрибутов на пути от исходного до репликации.
На рис. 6-1 изображены подлежащие репликации данные объекта при его создании на контроллере нового Объект: Локальный Номер USN Свойство USN версии James Smith 4711 1 10:49. 4711 10:49. 4711 1
Репликация сведений о пользователе 4711 USN: Объект: 1746 Объект: Номер Значение Время записи USN USN James Smith 1746 1 1999-09-10 10:49. 6Be8W5q- 1746 1 1999-09-10 10:49.03
пароля USN: Объект;
1746 Локальный Номер Свойство Значение Время записи Исходный 1746 1 1999-09-10 2002 2 1746 I
измененного DC1 DC 5039 5040 Объект: Номер Свойство Время Исходный USN USN СП James 1999-09-10 10:49. 5040 2 1999-09-10 11:53.29 JSmith 1746 1 1999-09-10 10:49. jSmith@reskit.com 1 1999-09-10 10:49. Рис. 6-4. Данные репликации на DC1 после репликации изменения пароля 246 ЧАСТЬ 1 Служба каталогов Active Directory Демпфирование распространения изменений Между парой может существовать несколько путей реплика ции. Это обеспечивает отказоустойчивость и способствует сокращению задержки репликации. У Вас может сложиться впечатление, что при определенных условиях одно изменение способно одновременно пересылаться по всем возможным путям или, того хуже, бесконечно по замкнутому кругу подключений между контроллерами. Служба Active Directory предотвращает возникновение та ких ситуаций с помощью описанного вектора обновления данных.
Вот типичный пример процесса репликации.
1. А обновляет атрибут пароля, присваивая исходному атрибута значение 3.
2. Контроллер-приемник В запрашивает изменения у контроллера-источника А и пересылает ему свои наивысший и вектор обновления данных.
3. На основе полученного наивысшего USN контроллер-источник А находит объект с измененным атрибутом пароля и действует следующим образом:
Х выясняет значение атрибута пароля (в данном случае это сам контроллер А);
Х изучив вектор обновления предоставленный контроллером В, руживает, что контроллер В обладает изменениями, произошедшими на контроллере А, с исходным меньшим или равным 2;
Х выясняет, что значение атрибута пароля равно 3;
Х поскольку 3 чем 2, контроллер А отправляет измененный атрибут пароля на контроллер В.
Чтобы проиллюстрировать демпфирование распространения, предположим, что контроллер В ранее уже получил обновление пароля от контроллера С, который в свою очередь получил его от контроллера А. В этом случае запись в обнов ления данных контроллера В для контроллера А содержала бы значение рав ное 3, а не 2. Поэтому, контроллер А не отправит измененный пароль на контроллер В.
Политика разрешения конфликтов в среде с несколькими хозяевами Как описано в Разрешение конфликтов на основе ранее в этой гла ве, Directory разрешает конфликты значений атрибутов, сравнивая их вер сии. Однако рассогласование значений атрибутов Ч не единственный тип возмож ных конфликтов.
Семантика каталогов LDAP обусловливает четыре вида возможных конфликтов при в среде с несколькими хозяевами. Два из них Ч на самом деле лишь разновидности одного и того же поэтому мы сократим перечень конф ликтных ситуаций до трех.
Х Конфликт значений атрибута возникает, когда одному атрибуту одновременно присваиваются значения на разных контроллерах Х Конфликты добавления или перемещения в пределах удаленного родительс кого объекта и удаления контейнерных объектов возникает, когда на одном контроллере последовательно операции добавления и ГЛАВА б Репликация Active Directory с целью сделать объект потомком объекта Р, а па другом контроллере объект Р удаляется.
Х Конфликт имен потомков одного родителя возникает, когда лере последовательно применяются операции добавления и перемещения с це лью сделать объект потомком объекта Р, присвоив относительное имя Cl.rdn = R, а в это время на другом домена выполняется такая же последовательность операций, но с дочерним объектом идентич ное относительное имя = Эти в любом каталоге LDAP с несколькими хозяевами.
В Directory общий подход к решению этих конфликтов глобальная уникальная (для каждого объекта или метка исходному об новлению, чтобы упорядочить все операции (Add, Modify, Move и При конфликта упорядочение меток позволяет согласовать каталог. Вот как этот подход применяется для перечисленных конф ликтов.
Х Конфликт значений атрибута. Пусть V Ч из множества с большей меткой, тогда после конфликта, значение на всех контроллерах домена станут одинаковыми и V.
Примечание Конфликты разрешаются на уровне всей совокупности атрибутов, даже для многозначных атрибутов. После разрешения конфликта ос тается из значений, а не некая их Х Конфликты добавления или перемещения в пределах удаленного родитель ского объекта и удаления контейнерных объектов. После разрешения конф ликта объект Р удаляется из всех реплик, а потомки размешаются в специ альном в разделе конфигурации. В разрешении кон фликтов данного типа метки не используются.
Х Конфликт имен потомков одного родителя. Пусть С Ч объект из атрибут относительного составного имеет меньшую метку.
После разрешения конфликта система на всех контроллерах домена значение Ч для С и гарантировано непротиворечиво любому назначенному значению. Например, если относительное имя объекта С перед конфликта - ABC, то после разрешения конф ликта оно получит значение где * Ч зарезервированный сим вол, CNF Ч константа, указывающая на конфликта, a Ч ото бражаемое атрибута Топология репликации Топология репликации Ч это набор подключений, используемых контроллерами домена для синхронизации общих реплик разделов каталога. Топология реплика ции создается на информации в Active Directory.
Служба проверки согласованности знаний Consistency Checker, KCC) это который выполняется на всех контроллерах домена и здает топологию в лесе. По умолчанию КСС активизируется с интер валом 15 минут и определяет маршруты репликации между контроллерами домена 248 ЧАСТЬ 1 Служба Active Directory на основе наилучших доступных автоматически создает под ключения репликации между в одном сайте. Если в сети несколько сайтов, вручную создаются только связи сайтов Ч после этого КСС так же автоматически создает подключения между сайтами.
Основные понятия топологии Хотя репликация синхронизирует информацию Active Directory для всего леса кон троллеров, в любой момент времени процесс репликации между дву мя контроллерами домена. Под топологии репликации подразумевается определение пар партнеров в пределах сайта. При этом ется, что каждый контроллер получать обновления от остальных домена в лесе, аналогичные реплики. Если контроллеры доменов в лесе в нескольких сайтах, некоторые из подключений меж ду компьютерами пересекают границы сайтов, и поэтому требуется также создать топологию репликации.
топология состоит из нескольких базовых топологий: по од ной для каждого набора реплицируемых разделов каталога. Следует объединить одного домена, хранящие раздел этого домена, кроме того, все кон троллеры домена должны разделы схемы и конфигурации. Для раз делов схемы и конфигурации создается отдельная топология. Однако в тех случая, когда для этих разделов каталога между контроллерами домена иден тичны, достаточно одного если два контроллера домена хранят одинаковый раздел каталога.
Маршруты репликации следующих наборов разделов каталога объединяются для получения общей топологии:
Х конфигурации и схемы в пределах сайта;
Х каждого раздела каталога домена в пределах сайта;
Х хранимых в глобальном каталоге частичных (только для чтения) реплик разде лов в пределах сайта;
Х конфигурации и схемы между сайтами;
Х каждого каталога домена между сайтами;
Х хранимых в глобальном каталоге частичных реплик разделов сайтами.
Компоненты, к топологии Active Directory использует раздела конфигурации для создания и топологии репликации. Несколько объектов конфигурации определя ют компоненты, которые для репликации:
Х сайты и относящиеся к ним контроллеры Х подключения, определяющие маршруты внутрисайтовой репликации между контроллерами домена;
Х подключения репликации между сайтами;
Х транспорты, используемые для взаимодействия между сайтами.
КСС эти и другие объекты и их свойства для создания подключений, с помощью которых пересылаются обновления каталога и осуществляется управле ГЛАВА б Репликация Active Directory и для одного или нескольких контроллеров партнеров ного сервера, у которых он запрашивает изменения. Контроллеры домена, репли цирующие собой, партнерами репликации partners). При каждом запуске службы (по Ч каждые 15 минут) при состав партнеров автоматически изменяется. Эта операция вы полняется на основе о доступности и взаимном расположении контрол леров домена.
Далее компоненты, применяемые службой КСС для управления Подключения создает позволяющие контроллерам домена обмениваться данными репликации. - односторонний от одного домена (источника) к другому контроллеру домена (прием нику). По возможности КСС повторно использует существующие и удаляет пользуемые подключения, а также создает новые если ни одно существующих не отвечает текущим Серверы каждый контроллер домена представлен объектом У сер вера есть дочерний объект (NTDS Settings), храпящий входящие подключения;
то есть объекты-подключения для сервера определяют подключения от источников к объекту-серверу.
Сайты это подмножества контроллеров домена, объединенных надежной, быст рой и сравнительно дешевой связью. репликация на основе уведомлений: когда на контроллере домена происходят изменения, он уве домляет о них своих партнеров по репликации. После этого партнеры ют и запускают Поскольку скорость или стоимость репли кации в данном случае репликация в пределах сайта по требованию, а не по Примечание Поскольку при неполадках сети некоторые уведомления помимо уведомления об изменениях, репликация в пределах сайта по умолчанию выполняется Репликация между сайтами выполняется по расписанию, которое на запуск репликации в наиболее выгодное время с точки зрения сетевого трафика и стоимости. Сайт Ч это фактически набор одной или нескольких Примечание Если соединение между двумя сайтами установить режиме невозможно (например, если с сайтом осуществляется только по модему), взаимная репликация обычно инициируется на основе изменений, а не по (Подробнее о взаимной Ч в разделе Взаимная кация далее в этой главе.) Ч в сетях TCP/IP относятся к сайтам в зависимости от их расположения в подсети или подсетей. В группируются ры, расположенные вблизи друга в сети. о подсети используется в процессе поиска контроллера домена в том же сайте, к которому относится ком пьютер. Эта также применяется при репликации Active Directory маршрутов между контроллерами домена. о подсетях в книге Сети TCP/IP. Ресурсы 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, сбросив флажок Bridge all site links мост для всех связей сайтов) на вкладке General (Общие) в окне свойств объекта транспорта IP или SMTP. В этом случае все связи сайтов IP рассматриваются как нетранзитивные, и Вы вправе скон фигурировать мосты связей сайтов. Мост связей сайтов Ч это раздель ной сети: все связи в пределах моста но они не выходят пределы моста.
Иерархия объектов-сайтов в Active Directory Active and Services (Active Directory Ч сайты и службы) Ч админист ративная консоль, применяемая для просмотра иерархии КСС объек тов и управления ею для настройки топологии репликации. Иерархия отображается в структуре контейнера Sites Ч Configuration. Составное имя контейнера Sites Ч Configuration объект наивысшего уровня в разделе конфигурации, а контейнер Sites Ч в иерархии объектов, для и выполне ния репликации Active Directory. Далее перечислены объекты во внутренней иерар хии Sites.
Х Sites содержит каждый из которых представляет отдельный сайт в лесе. Кроме объектов в этом контейнере есть Subnets, содержащий определения подсетей в форме объектов Каждый объект подсети атрибутом связывающим с объектом сайта.
ГЛАВА 6 Репликация Active Directory Х содержат но два объекта:
Х объект NTDS Site Settings, хранящий свойства каталога, общие для всех кон троллеров домена в в том числе расписание реплика ции;
Х контейнер Servers, хранящий объекты-серверы контроллеров в Х Объекты-серверы каждый из них содержит объект NTDS Settings.
Х Объект NTDS Settings представляет экземпляр Directory на этом ре. (Когда служба Active Directory удаляется с сервера, ее объект NTDS удаляется из Active Directory, но ее объект-сервер остается.) Для го объекта-сервера объект NTDS Settings содержит отдельные чения, представляющие с других контроллеров домена в лесе, доступные в настоящее время для получения данным контрол лером домена.
Х Объекты-подключения каждый из них представляет однонаправленное согла шение о между парой контроллеров где контроллер-прием ник - объект-сервер, являющийся родительским объектом NTDS Settings, хра пящим подключение. Объекты-подключения автоматически создаются КСС.
также создавать вручную.
На рис. 6-5 изображен раскрытый Sites. Для сервера выбран объект NTDS Settings, а объекты-подключения отображены в правой панели, В столбце From Server отображаются имена контроллеров домена, от которых выб ранный принимает данные репликации (имена его текущих партнеров по Рис. 6-5. Иерархия объектов в контейнере Sites Подробнее о создании и управлении в контейнере Sites Ч в системе Microsoft Windows Server.
252 ЧАСТЬ 1 Служба каталогов Active Directory Сайты и репликация Сайт (site) Ч это с высоким качеством доступа, который обычно соответствует качеству связи в Такие связи предполагают широкую недорогую полосу пропускания, обеспечивающую воспроизводимую и надежную ра боту сети между любыми компьютерами в сайте. Это не что все серверы сайта обязательно расположены в одном сетевом сегменте или что число переходов между любыми парами серверов Скорее это такая связь, при наличии которой все равно, какие серверы задействованы при большого чества данных между ними. Если это так, следует создать отдельный сайт.
Эффективность репликации инициируется Высокая скорость и на локальной сети позволяют передавать данные по запросу. Механизм реп ликации при выполнении изменения в определенной реплике. Он ожидает определенное время (по умолчанию 5 минут) и затем уведомляет первого партнера по репликации. Каждый последующий партнер уве домляется после заданной задержки (по умолчанию Ч 30 секунд).
Топология внутри сайта формируется с использованием минимально возможного количества подключений. Стандартная топология репликации в сайте Ч двунаправ кольцо с дополнительными подключениями, необходимыми для сохранения количества переходов между партнерами по репликации равным трем или В результате стандартная задержка распространения сайта в худшем случае максимальному количеству переходов между источником и контрол лером-приемником (3 перехода) умноженному на задержку на каждом контролле ре в пути (5 минут), то есть 15 минут для трех переходов, репликации между сайтами составляется так, чтобы обеспечить воз можность управлять затратами репликации и предотвращать кана лов связи трафиком репликации. Существует факторов, на ско рость в том числе Ч характер физических соединений и их стоимость.
Active Directory поддерживает подключения сайтов по каналам разной емкости: от коммутируемых линий до линий На основании производительности канала свя зи назначается стоимость связей между сайтами, а механизм репликации на основе стоимостных показателей выбирает самый маршрут для трафика Х ни о сетей в Microsoft Windows 2000 Server Deployment Press, 2000).
Разработка сайта с учетом репликации В сайт объединяют IP-подсети, обладающие высокой емкостью, объединенные в ЛВС или быстрыми маршрутизаторами.
Отдельный домен может охватывать несколько сайтов, а сайт Ч содер жать несколько доменов. Архитектура домена не должна зависеть от структуры сай тов: сайты первичны, но не оказывают исключительного влияния на процесс ка ближайшего контроллера домена и инфраструктуру репликации. Универсально го правила, когда размещать подсети в нет: важно пони мать, как служба Active Directory использует о сайтах.
ГЛАВА 6 Active Directory Х Когда клиент соединение с контроллером (например, при входе в систему), сайты найти контроллер с хорошей Быстрые уменьшают и снижают нагрузку на сеть.
Х Когда служба КСС конфигурирует подключения репликации между контролле рами, она больше подключений между контроллерами в одном сайте, чем между контроллерами в сайтах. В результате снижается задержка реп в сайта и нагрузка на канал связи между сайтами.
Х репликации, пересылаемые между домена внутри передаются несжатыми, что снижает нагрузку па процессоры контроллеров до мена. При репликации между контроллерами домена в сайтах данные сжимаются, что снижает нагрузку на канал связи.
Х Репликация между контроллерами домена внутри сайта инициируется лениями, что уменьшает задержку репликации в пределах сайта, а репликация между сайтами выполняется по расписанию, чтобы меньше канал связи между сайтами.
Сайты никак не с пространством имен Active Directory, используемом раз делами каталога домена. Имена объектов каталога не связаны с сайтами, в которых они хранятся.
Примечание В каталогов Exchange Server сайты с пространством имен.
Иерархия в контейнере Sites отражает имена объектов внутри раздела конфигура ции, где имена сайтов отображаются в соответствии с их именами Б иерархии контейнера конфигурации.
о сайтов и топологии сайтов для Active Directory Ч в книге Microsoft Windows 2000 Server Deployment Planning Guide (Microsoft 2000).
Сопоставление подсетей сайтам В процессе планирования в сайты объединяются подсети, обеспечивающие хоро шую связь для репликации. Для этого консоли Active Directory and Services создаются подсети, затем Ч сайты, и после этого подсети ются сайтам. Для сайта требуется создать ему объект в Active Directory, а затем определить набор относящихся к данному сайту подсетей.
Компьютер относится к сайту, если его объекту-подсети в Active Directory. В стандартном заданных поэтому компь ютер в лесе может относиться к IP-подсети, не относящейся ни к одному сайту. В частных сетях Вы вправе задать адреса, Агентством по вы делению имел и параметров протоколов (Internet Assigned 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 о сети и сайтов Active в книге Microsoft Windows Server Deployment Guide Press, 2000).
Когда следует создавать новый сайт Если сегменты связаны медленными рекомендуется два сай та и контроллеры домена в сайтах в соответствии с определенными об щими правилами:
Х в каждом сайте развертывают по крайней мере один глобальный каталог;
Х серверы DNS на сайтов.
Первый контроллер домепа в лесе автоматически становится сервером глобально го каталога. Для в дополнительных серверов каталога в консоли Active Directory Sites and Services Directory Ч сайты и службы) следует установить флажок Global Catalog (Глобальный каталог) на свойств объекта Settings соответствующего сервера. Наличие сервера гло бального каталога в каждом сайте повышает поиска, при поиске в глобальном каталоге сайта не пересекается. Кроме того, сервер глобального каталога необходим для входа в домен: при нарушении между сайтами вход в систему Примечание Если сервер каталога в ближайшем сайте недоступен, вой ти в сеть разрешается через сервер каталога в удаленном сайте. Если глобальные каталоги недоступны, вход в систему на основе ин формации из кэша.
Доступность самым образом влияет на доступность Active Поиск домена выполняется с DNS, средства также применяются контроллерами для поиска друг друга. В общем случае реко мендуется создать по крайней мере один сервер в каждом сайте.
При создании сайтов и в них серверов нужно сформировать подклю чения между сайтами и эти связи с учетом характеристики сети, то есть частоты по данному каналу связи, Подробнее о планировании сайтов и о контроллерах серверах DNS и раз мещении сервера глобального каталога - в книге Microsoft Windows 2000 Server Deployment Planning Guide (Microsoft Press, 2000). Подробнее о глобаль ного каталога в главе 1 Логическая структура Directory.
Сайт по умолчанию В процессе установки Directory на первом контроллере домена в сайте, объект Default-First-Site-Name. Первый контроллер до мена обязательно устанавливается в этот сайт. Последующие контроллеры ливаются либо в сайт первого (если его этому сайту), либо в один из уже существующих сайтов. После первого кон домена имя Default-First-Site-Name разрешается Если в Active Directory другие сайты и IP-адрес устанавливаемого но вого контроллера домена соответствует существующей подсети в определенном сай ГЛАВА б Active Directory тс, новый контроллер размещается в сайте. В противном случае он ется в сайте контроллера.
о способах новых контроллеров домена в сайтах Ч в гла ве 2 данных в Active Подключения серверов и сайтов выполняется между контроллерами домена в одном сайте и между сер верами-плацдармами в разных сайтах. Подключения сайта все гда автоматически создаются КСС (либо хотя обычно этого не требует ся). Если в сети несколько сайтов, между ними надо связи. При наличии между сайтами служба КСС также создает подключения двумя серве Ч но одному в каждом сайте для каждого домена, которого в этом сайте есть контроллеры. Если сайт много доменов и у каждого до мена есть контроллеры в разных сайтах, в сайте будет несколько мов, поскольку контроллеры в одном домене должны соединяться только с серве рами того же КСС выбирает автоматически. Если Бы чтобы одни и те же серверы всегда как мы, назначьте их Транспортные протоколы определяют, как данные репликации переда ются по сетевым носителям, а транспорты определяет сетевая среда.
установке Active Directory на компьютере с Windows 2000 Server представляющий контроллер домена. Он отличается от объек та-компьютера, представляющего компьютер как участника безопасности. Эти объекты хранятся в разных разделах каталога: объект-компьютер кон троллер домена в разделе а объект-сервер - в разделе конфигурации.
Объект сервера содержит ссылку на соответствующий ему объект-компьютер, Объекты Ч потомки объектов-сайтов. Родительский сайт сервера содержать подсеть сервера. Если домена или сопоставление подсетей сайтам изменятся после установки Active Directory па сервере, чески сайта контроллером домена не обновляются - Вам придется в сайт вручную.
контроллера в другой следует пред связь сайтов. между сайтами по SMTP, чрезвычайно важно сначала кон троллер домена в поддерживающем протокол поверх IP.
Примечание При влияющих на репликацию, эти зли реплицируются на основе старых параметров настройки репликации, они целевых где вступят Б силу. между сайтами не происходит, пока:
Х где-то в каталоге не создана связь сайтов;
Х это изменение не на систему в сайте, ответственную за создание топологии о Ч деле создание межсайтовой далее в этой главе);
Х служба КСС в системе не сработала и не создала 256 ЧАСТЬ 1 Служба Active Directory Х новые подключения не на сервер-плацдарм;
Х служба КСС на сервере-плацдарме сработала и не в под с партнерами по репликации;
я на сервере-плацдарме не выполнена репликация.
Подключения серверов Служба КСС создаст подключения для всех контроллеров домена, у которых есть объект-сервер контейнере Sites. Эти объекты-подключения оп ределяют одностороннюю связь с текущей системой со стороны другой системы.
Ч потомок объекта Settings на контроллере-приемни ке репликации;
он ссылается на контроллер-источник репликации в атрибуте то есть представляет входящую половину В объекте-под ключении указано расписание и транспорт репликации.
Объекты-подключения создаются двумя способами:
Х средствами КСС;
Х вручную администратором каталога средствами консоли Active Directory Sites and Services (Active Directory Ч сайты и службы), Edit или с помощью Подключение однонаправлено;
подключение репликации пред ставляется как два объекта подключения под двумя разными объектами NTDS Settings.
Владение объектами Автоматически созданные КСС подключения КСС. Аналогично, если создает повое подключение или изменяет существующее, то владельцем подключения становится администратор. Служба КСС меняет и удаляет подключения, которых не является. Цель создания или нения объекта-подключения в том, чтобы сохранить объект в виде, каким он со здан. Владение защищает от изменения со стороны КСС.
Примечание Владение подключением не влияет на доступ к объекту;
оно лишь за прещает КСС или удалять объект.
Владение определяется атрибута options объекта-подключения. Если (а точнее результат применения операции ИЛИ к этому и единице) равно подключением владеет КСС. админист ратор созданное службой КСС подключение, значение options изменит ся. У вновь созданных администратором объектов значение атри бута options 0.
Передать созданным КСС администратор может средствами консоли Active Directory Sites and Services (Active Directory сайты и службы). Когда изменения будут реплицированы, значение атрибута options изме нится, информируя, что КСС больше владеет объектом. о создании объекта-подключения Ч в справочной системе Microsoft Windows 2000 Server, ГЛАВА 6 Репликация Active Directory Примечание Если КСС автоматически создает то, как правило, вруч ную их не требуется. КСС переконфигурирует ния, когда условия изменяются. подключения при использо вании КСС иногда увеличивает трафик за счет добавления ных подключений к оптимальному созданному КСС. Если имеются подклю чения, созданные вручную, служба КСС использует их везде, где Расписание подключений Для каждого объекта-подключения КСС автоматически задает расписание в ходе настройки оптимального маршрута репликации. подключения опреде ляет частоту периодической репликации. Минимальный интервал подключения 15 минут. По умолчанию для репликации в пределах сайта интер вал в расписании Ч 1 час. Этот параметр можно изменить в объекте Site Settings. Средства консоли Active Directory Sites and Services (Active Directory сайты и службы) позволяют Вам задать расписание без раз в час (по умолчанию), дважды в час или четыре раза в час.
Средства Active Directory Sites and Services позволяют пери одичность с дискретностью 15 минут на протяжении часов (от 1 до 24 часов) в течение педели. Средствами Edit или сценария Вы можете управлять репликацией более точно.
Создавая новое подключение, служба КСС ему в NTDS Site Settings. Стандартное расписание для объекта Site можно настроить вручную.
Ручное переопределение действует только для объектов, вручную. Если Вы пытаетесь обновить расписание для КСС, при своем запуске КСС восстановит расписание.
КСС назначает подключения между сайтами па основании связи сайтов, которое частоту активности этой связи. По умолчанию репликация между сайтами происходит каждые 3 часа. Этот параметр можно настроив связи сайтов.
В пределах сайта инициируется изменениями: если происходит обнов ление каталога, репликация автоматически (контроллер домена уведом ляет об своих партнеров по репликации) через заданный интервал (по умол чанию 5 минут). Если отсутствуют течение времени, указанного в расписании объекта-подключения, репликация инициируется (контроллер домена запрашивает изменения у партнеров по по (по умолча нию Ч Расписание важно при межсайтовой где - механизм за репликации. Поскольку минимальный чения 15 минут, не удастся настроить репликацию между сайтами чаще, чем каж дые 15 минут.
Связь между репликами разделов каталога Репликация между репликами раздела каталога, для чего между сер верами создаются подключения, для репликации общих 258 ЧАСТЬ 1 Служба каталогов Active Directory лов каталога у каждой пары серверов. контроллера домена в одном лесе всегда обладают по крайней мере двумя общими каталога: конфигурации и схе мы. У контроллеров одного есть еще один общий раздел Ч домена. У кон троллеров Ч серверов каталога одного леса Ч общие частичные реп лики разделов всех доменов леса, если же они находятся в одном домене, у них так же общий полный домена.
Существующее подключение двух контроллеров домена используется для репли кации всех общих разделов каталога для этих двух серверов. КСС никогда не здает несколько подключений, два одинаковых контроллера в одном Связи сайтов В системе с двумя и более сайтами следует создать связи, по кото рым будет выполняться репликация. В Active Directory объект связи сайтов определяет набор сайтов, которые взаимодействуют друг с другом по опре деленному протоколу по подключениям с одинаковой стоимостью. Связи сайтов используются службой КСС для создания топологии репликации. Обычно этим связям присваивают имена соединяемых ими сайтов. Например, если у Вас есть сайты с именами New и назовите их NY-London, сайтов также определяют стоимость от которой зависит возможность использования удаленных сайтов как источников информации репликации. Кроме того, связи сайтов определяют расписание репликации и парамет ры, влияющие на способ репликации.
По умолчанию связи сайтов, у которых есть сайты, для IP соединены мостами, позволяющими КСС обрабатывать набор связей сайтов как один маршрут.
Серверы-плацдармы Плацдарм - это точка входа или подключения в/из сайта. Серверы, у которых есть объекты подключений между сайтами, дармами (bridgehead Любой сервер, у которого есть объект подключения с сервером-источником в другом Любой сервер, действующий как источник для подключения с другим является источником-плацдармом. КСС генерирует подключения и заставляет контроллеры домена, хранящие подключения между сайтами, выполнять в топологии роль плац дармов.
Если требуется ограничить выбор серверов-плацдармов для (то есть ограничить контроллеры домена, на которых КСС разрешено создать подключения между сай тами), выберите один или несколько контроллеров домена в сайте, которые КСС все гда должна рассматривать как основные (лпредпочтительные) Эти серверы используются исключительно для репликации накопивших ся в Выбирая основные следует иметь в виду, что;
Х Вы ограничиваете способность службы КСС обращаться к другому плацдарму, когда назначенный сервер отключается;
Х Вы должны назначить один для каждой пары пол ный в Вашем лесс, что может оказаться невозможным в ной организации.
ГЛАВА б Репликация Active Directory Транспорты репликации репликации поддерживают протоколы обмена (wire protocols) для пе редачи Windows 2000 три типа транспортов для реплика ции Active Directory:
Х быстрая поверх IP для ката логов внутри сайта);
Х синхронная медленная связь типа точка поверх для реп ликации всех разделов каталогов между сайтами);
Х асинхронная поверх IP для только разделов каталогов между сайтами).
Применение транспортов регулируется определенными правилами:
Х для репликации внутри сайта используются транспортные протоколы а поверх Х для репликации применяются два транспортных протокола: IP (RPC поверх IP) и Simple Mail Transfer Protocol (SMTP поверх IP);
Х репликация между сайтами но SMTP поддерживается только для контроллеров доменов. домена выполняют репликацию по про токолу поверх IP. Поэтому репликация между сайтами по SMTP под держивается только для и а также репликации глобального что означает, что домены могут располагаться в несколь ких сайтах, только если между сайтами удастся но синхронному механизму RPC типа точка Ч точка.
Контейнер Transports позволяет сопоставлять связи сайтов транспорту, используемой связью. Объект связи сайтов создается в контейнере IP (который связь сайтов транспорту поверх либо в (который сопоставляет связь сайтов транспорту SMTP).
и асинхронная связь В механизме репликации Active Directory связь подразумевает, что сле отправки ожидает, пока контроллер-источник не получит запрос, сформирует и не отправит ответ;
в это приемник не тается запросить изменения у любых других контроллеров домена. Поэтому в лю бой момент времени у контроллера домена имеется не более одного > текущего репликация подразумевает, что контроллер-приемник не ждет и единовременно несколько асинхронных ожидающих зап росов. Таким образом, синхронная быстрый ответ, а асинх ронная Ч не обязательно.
Транспорт для репликации внутри сайта репликация внутри сайта по синхронному транспорту по верх IP. Главное при репликации внутри сайта Ч быстрая, без сжатия События репликации чаше происходят внутри сайта, чем между сай тами, и при быстром неразумно тратить ресурсы на сжатие.
260 ЧАСТЬ 1 Служба каталогов Active Directory Примечание Данные репликации, между сайтами, Но умолчанию при репликации на основе RPC применяется динамическая привяз ка При соединении с точкой ходе репликации Active Directory обращается к распределителю конечной точки RPC на сер вере через стандартный порт 135). Сервер опрашивает локатор RPC через этот чтобы определить какой порт назначен для репликации Active Directory на сервере. Этот выполняется независимо от того, назначен ли порт дина мически умолчанию) клиенту не нужно какой порт использовать для репликации Active Directory.
Примечание Конечная точка содержит протокол, локальный адрес и адрес порта.
Active регистрирует конечную точку при запуске, и она использует либо ди либо указанный порт. Для настройки порта для сред с марш рутизацией или с фильтрацией по порту параметр реестра TCP/IP Port в разделе Services\ Этот параметр для Active Directory регистрации определенного порта на конечной точки. Разреша ется назначать помер любого действительного порта TCP/IP Настройка параметра TCP/IP Port Б перейдите в раздел 2. Дважды щелкните значок параметра TCP/IP Port и назначьте номер 3. Закройте редактор системного реестра.
Внимание! Не модифицируйте реестр самостоятельно (с помощью редактора реес тра) Ч делайте это лишь в крайнем случае, когда другого выхода нет. В отличие от инструментов управления редактор реестра обходит стандартные средства защиты, призванные не допускать ввода конфликтующих значений параметров, а также спо собных снизить быстродействие системы или разрушить ее. Не исключено, что по следствия прямого редактирования реестра окажутся не такими, как Вы ожидали, и, возможно, Вам придется Windows 2000. Для и Windows 2000 рекомендуется использовать Control Panel (Панель управления) или Microsoft (Консоль управления Microsoft), Перед изменением реестра советуем делать копию. Подробнее о редакти ровании реестра в справочной системе редактора реестра. Подробнее о реестре Ч в техническом руководстве Technical Reference Windows Professional Resource Kit (файл Транспорт для репликации между сайтами Windows 2000 поддерживает два транспорта репликации между сай тами:
Х поверх TCP/IP (в пользовательском интерфейсе средств администриро вания отображается просто как IP) - обеспечивает синхронную репликацию между всеми разделами каталога по механизму точка точка;
ГЛАВА б Active Directory Х SMTP поверх IP (в интерфейсе средств администрирова ния отображается как SMTP) Ч предназначен для низкоскоростной асинхрон ной репликации разделов схемы, конфигурации и глобального каталога, но домена, Когда сайты соединены (или через Интернет), не всегда (а иногда просто выполнять репликацию каталога по транспорту RPC. Иногда единственный способ связи между двумя сайтами - элек тронная Для таких конфигураций следует выпол нять асинхронных тина сохранить и на SMTP.
Репликация SMTP заменяет транспорт RPC передачей почтовых сообщений. При синтаксис сообщения Ч тот же, что и для репликации на RPC. При реп ликации на основе SMTP об не передаются, а информация о расписании в объекте связи сайтов используется следующим образом:
Х репликация SMTP игнорирует переключатели Replication Available (Реплика ция доступна) и Replication Not Available (Репликация недоступна) в расписа нии связи сайтов в консоли Active Directory Sites and Services;
Х репликация SMTP использует интервал репликации, чтобы указать, как часто запрашивает изменения. Интервал every... minutes (Репли цировать каждые... задается в интервалах на вкладке General (Общие) окна свойств связи сайтов в консоли Active Directory Sites and Services.
В совокупности параметры формируют расписание репликации для объекта-под ключения. За маршрутизацию сообщения между серверами SMTP отвечает базо вая система передачи сообщений SMTP Служба Intersite Messaging позволяет добавлять (лнадстраивать) в архитек туру ISM другие транспорты. предоставляет услуги для КСС в форме запроса доступных путей репликации. ISM может сообщения от серверов которые не выделены для работы с приложениями электронной почты, как, Server.
Сравнение репликации SMTP и RPC С точки зрения механизма репликации Directory далее ха рактеристики относятся как к SMTP, так и к RPC:
Х при между сайтами сжимаются;
Х объем изменений, возвращамых Directory в ответ на запрос, ограничен и размером пакетов репликации. Размер пакетов репликации настра ивается (подробнее об Ч в разделе пакетов репликации далее в этой главе);
Х в Active Directory только один запрос изменений для данного каталога к партнеру по Х данные ответа передаются в одном или нескольких кадрах в зави симости от общего количества или новых Х алгоритм передачи порций по TCP одинаков для SMTP и RPC;
Х любой сбой передать данных вызывает повтор всей передачи;
Х если пропускная способность связи ограничена, применяются одинаковые раметры повторной передачи TCP RPC намного больше, чем TCP).
262 ЧАСТЬ 1 Служба каталогов Active Directory SMTP не используется для разделов Windows синхронную типа Ч точка асинх SMTP-репликации сайтами, что обеспечивает определенную гиб кость, доменам размешаться в нескольких сайтах. RPC использо вать между хорошо связанными сайтами, потому что он вызывает меньшую задер жку. SMTP лучше применять для репликации, где применение RPC поверх IP невозможно. SMTP используют компании, опорная сеть которых осно вана не на TCP/IP, например сеть В системе репликации Active Directory оба транспорта для реализа ции механизма Ч ответ. Active Directory генерирует запросы на ния и ответы на них. В RPC им запросы и ответы RPC. A SMTP базируется на постоянных TCP-соединениях для доставки почтовых потоков всем направлениям. Таким в RPC ответы па запросы почти мгновенны, и поддерживается более одного активного RPC-под с репликой раздела каталога. Транспорт SMTP поддерживает намного более длинные задержки между запросом и ответом. В итоге допускается несколь ко активных входящих с репликой раздела каталога, если ко нечно эти запросы различным или раз делам Преимущества репликации по SMTP Хотя репликация по SMTP обычно чем RPC, в некоторых условиях воз можна или предпочтительна именно SMTP-репликация.
Х синхронна, а SMTP-репликация - асинхронна. В условиях пропускной способности иногда невыгодно дожидаться полного завершения одной транзакции, пока не начнется следующая. В SMTP несколь ко транзакций могут обрабатываться одновременно, в то время как при репликации нередки длительные Х В WAN удается обеспечить защиту, мониторинг и управление трафика SMTP.
Х Там, где нельзя реализовать сквозную интерактивную связь по (например, А связывается с В, В Ч с С, по А никогда не связывается напрямую с С), можно наладить почту для связи А с В, В г С, С с В и В с А.
Размер пакетов репликации По умолчанию размеры пакета вычисляются на основе размера памяти, при усло вии, что ее объем не больше 1 Гб и не меньше 100 Эти размеры пакетов разре шается изменив соответствующие параметры реестра.
Чтобы скорректировать размер с данными репликации Active Directory, следует изменить или добавить параметры с данных в следу ющем разделе реестра:
Указанные параметры максимальное количество объектов в пакете и размер пакетов.
Х Для Х Replicator intra site packet size (objects) (Количество объектов в пакете реп больше или равно 1;
ГЛАВА 6 Репликация Active Directory Х Replicator intra site packet size (bytes) (Количество байт в пакете реплика ции) или равно Х Для между сайтами:
Х Replicator inter site packet size (objects) больше или равно 1;
Х Replicator inter site packet size (bytes) или равно 10 кб.
Х Для SMTP-репликации между сайтами:
Х inter site packet size (objects) ) больше или равно 1;
Х Replicator inter site packet size (bytes) больше или 10 кб.
Если указанные реестра не система ограничивает размер пакета следующим образом:
Х размер пакета в байтах равен сотой части ОЗУ, но не менее 1 Мб и не более 10 Мб;
Х число объектов в пакете Ч одна миллионная размера ОЗУ, но менее 100 объек тов и не более 1 Есть одно исключение: значение параметра Replicator async inter site packet (bytes) (Количество байт в пакете асинхронной репликации) всегда равно 1 Мб.
Многие почтовые системы ограничивают объем почтовых сообщений (обычно до 2 1 Мб), хотя большинство почтовых систем на базе Windows способны обра батывать большие почтовые сообщения размером до 10 Мб.
Внимание! Не модифицируйте реестр самостоятельно (с помощью редактора реес тра) Ч делайте это лишь в крайнем когда другого выхода нет. В отличие от инструментов управления редактор реестра обходит стандартные средства защиты, призванные не допускать конфликтующих значений параметров, а также системы или разрушить ее. Не исключено, что по следствия прямого редактирования окажутся не такими, как Вы и, возможно, Вам придется переустанавливать Windows 2000. и кон фигурирования Windows 2000 использовать Control Panel (Панель или Microsoft Management Console (Консоль управления Microsoft).
Перед изменением реестра советуем делать резервную копию. Подробнее о редакти ровании параметров реестра - в системе редактора реестра. Подробнее о реестре Ч в техническом руководстве Technical Reference Microsoft Windows Professional Resource Kit (файл Управление между сайтами Хотя внутри сайтов оптимизирована для LAN и практически не требу ет управления, Вы вправе контролировать, когда как происходит между сайтами. Если Вы хотите достичь эффективности при мини мальной стоимости, следует ряд основанных на структуре сете вой среды, физическом и деловых строит топологию репликации между сайтами автоматически, но при этом она учи тывает заданные параметры связей.
Когда несколько сайтов участвуют в топологии репликации контроллеров домена в одном лесе, по умолчанию репликации между сайтами яв ляется деревом с минимальной стоимостью репликации.
264 ЧАСТЬ 1 Служба каталогов Active Directory это административно оценки маршрутов репликации. Репликация между сайтами выполняется синхронно RPC поверх IP или асинхрон но по SMTP поверх IP, Примечание Алгоритм связующего (Spanning Tree Algorithm, STA) ется для устранения маршрутов и, значит, снижения нагрузки на до рогостоящие WAN-каналы Планирование репликации между Репликация внутри сайтов, как не нуждается в планировании, поскольку выполняется автоматически. В среде с множеством сайтов Вам следует выполнить определенные операции по планированию репликации.
1. Определите сайты, объединенные сетями, и создайте связи между ними с минимальными стоимостями.
2. Выделите сайты, связанные транспортом с примерно равной стоимостью, и со между ними связи стоимости Ч например, межсетевые связи (удаленные сайты, связанные по телекоммуникационным каналам), связи по протоколу Frame Relay (система точка точка на базе частного канала), связи по региональным сетям (medium area network, MAN) с пропуск ной способностью 3. Выделите оставшиеся WAN-связи.
4. Создайте для каждой пары по WAN.
5. Создайте расписание, отвечающее пользователей, Не задавайте высокую репликации. Связи сайтов должны иметь общие временные окна, доступные для обмена данными.
Подробнее о планировании сайтов и топологии сайтов в Active Directory Ч в книге 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, который содержит объекты связей сайтов синхронной репликации по механизму поверх IP;
Х контейнер SMTP, который содержит объекты связи сайтов асинхронной репли кации типа SMTP поверх ГЛАВА 6 Репликация Active Directory При конфигурировании объектов-подключений репликации служба учитывает параметры объектов сайтов, создать наилучшее ключение. В один из параметров межсайтовой связи Ч стоимость под ключения. КСС выбирает удаленный сайт с самой низкой стоимостью подключе ния.
Для транспорта IP обычно связь сайтов только два сайта и ет фактической связи WAN. Связь по соединяющая больше двух сайтов, может соответствовать опорной сети ATM, которая соединяет, например, более двух групп зданий большом университетском городке или несколько столичных офисов, объединенных IP-маршрутизаторами и выделенными линиями, Разрешается связывать сайты друг с другом любым количеством объектов связей сайтов. сайт в каталоге должен обладать по крайней мере одной иначе репликация с контроллерами домена в других сайтах окажет ся и каталог потеряет свою целостность. если в лесе боль гае одного сайта, необходимо сконфигурировать по крайней мере одну связь между ними.
На рис. 6-6 два сайта с одной связью. В обоих сайтах есть контроллеры одного домена. При формировании топологии КСС создает в сайте объекты-подключения между серверами-плацдармами, и репликация конфигурации связи сайтов.
Домен Reskit.com 1.Х Связь Milan Рис. 6-6. Два сайта, одной связью На рис. 6-7 изображены три сайта, объединенные двумя связями. По связи сайтов поэтому репликации могут передаваться от сайта через сайт к сайту Milan. Поскольку в этом сценарии сайт Seattle содержит полную реплику домена reskit.com, нет необходимости в прямой репликации между сайтами Milan и Atlanta: репликация между ними идет сайт Seattle.
266 ЧАСТЬ 1 Служба каталогов Active Directory Домен Reskit.com Подключения сайтов Сайт Atlanta Сайт Seattle Сайт Milan Рис. 6-7. Три сайта, объединенных двумя связями Конфигурация связи сайтов В консоли Active Directory Sites and Services на вкладке General (Общие) страниц свойств связи сайтов параметров связей, используемых для топологией репликации:
Х список двух или более сайтов, объединяемых топологией;
Х расписание доступности связи для репликации. Например, связь мого доступа можно настроить на работу только в нерабочее время, когда теле фонные тарифы низки;
игнорируется SMTP-связями сайтов: почта ется и пересылается согласно настройкам почтовой инфраструктуры.
Х стоимость Ч один числовой характеризующий затраты на под по данной связи. Чем выше стоимость, тем дороже обмен сообщения ми. Например, у сайтов, связанных или модемным соедине связи сайтов дорогие, а у сайтов, связанные по опорной сети, - дешевые.
Там, между двумя сайтами существует несколько маршрутов или применя ются разные транспорты, комбинация маршрута и транспорта с стоимостью;
Х период в минутах, определяющий частоту репликации (но умолчанию Ч каж дые минут или 3 часа;
Ч 15 минут).
Параметры связи сайтов управлять топологией и расписа нием репликации:
Х на топологию репликации влияет стоимость связей сайтов. Как правило, для сайтов по сети следует задавать стоимость 1, а для связей по ГЛАВА 6 Репликация Active Directory подключениям с филиалами - Такие стоимости га что филиал будет выполнять репликацию с контроллером в сайте, относящемся к опорной сети, а не напрямую со вторым филиалом. Сто имости связей не влияют на частоту репликации;
Х интервал задается в минутах для каждой связи сайтов;
Х регулируется ее расписанием. В случаев следу ет применять стандартное расписание (постоянный доступ), но в пиковое рабо чее время можно блокировать трафик репликации для с некоторыми филиалами. запрет дает приоритет трафику, но увеличива ет задержку репликации.
Влияние стоимостных показателей При настройке связей сайтов учитывается, что КСС отдает приоритет с более низкой стоимостью. Стоимость канала фак тор, который нужно учитывать определении границ сайтов. Рекомендуется со гласовать затраты для всех сайтов. Стоимость зависит не только от полной пропускной способности канала, но и от доступности, ожидания и от сто имости самой связи.
Например, канал постоянной связи со скоростью 128 кбит/с обычно стоит дешев ле, чем канал модемной линии с той скоростью. Дело в том, что связь по вызывает репликации из-за времени на уста новку и разрыв соединения. Кроме того, в этом примере, постоянная связь обычно оплачивается по помесячной ставке, а линии ISDN зависит от объема данных. Поскольку компания оплачивает постоянную связь разовым авансовым платежом, администратор вправе ей более низкую стоимость, чем линии TSDN в этом примере создают тельные расходы к уже постоянной линии.
В таблице 6-2 перечислены скорости для разных типов сетей эти значения Вам будут полезны при стоимости, Таблица 6-2. Скорости сетей для оценки стоимости связей сайтов Тип сети Быстродействие 56 кбит/с Медленная 64 кбит/с (типичная D Европе) ISDN 64 кбит/с или 128 кбит/с Frame Relay обычно от 56 кбит/с до 1,5 Мбит/с Т1 Мбит/с ТЗ 45 Мбит/с Переменная скорость, обычно в диапазоне Gigabit Ethernet До настройки стоимости следует определить модель существующей На стоимости и других факторов (доступность, задержка репликации) создает ся согласованный набор стоимостей для всего леса. При назначении определенной стоимости, она должна иметь одинаковый смысл во где В таблице 6-3 показан пример распределения стоимостей в для сети, где высо стоит немного.
268 ЧАСТЬ 1 каталогов Active Directory Таблица 6-3. Пример схемы стоимостей для леса в высокоскоростной сети Тип сети подключенная к сети Связь со 56 кбит/с Филиал 1 связь 5 Параметр Cost (Стоимость) для указывает относительное зна чение для стоимости подключения между всеми входящими в связь сайтами. По умолчанию межсайтовой связи (transitive).
если Вы создаете объект IP-связи сайтов XYZ, которая соединяет сайты X, Y и Z со стоимостью 5, Вы указываете, что сообщение IP между все ми парами сайтов (X-Y, Y-Z, Z-X, со стоимостью 5.
Примечание По умолчанию все сайтов то есть все связи для определенного транспорта принадлежат одному мосту связей сайтов для этого о мостах - в разделе Мосты связей сайтов далее в этой главе.) Если Ваша IP-сеть полностью связна, Вы можете отключить тран зитивность межсайтовой связи для транспорта IP. В этом случае все IP-связи сай тов будут рассматриваться как нетранзитивные, и Вы сможете конфигурировать мосты определяет самые пути между всеми сайтами для каждого раздела каталога. Далее КСС сравнивает пути каждого приемника и вычисляет связу ющее дерево с самыми низким стоимостей.
Подробнее о связности IP-сетей - в Windows 2000 Server Deployment Planning Guide (Microsoft 2000).
Для каждого объекта межсайтовой связи, задается значение репликации, определяющее, как часто этой связи выполняется по расписанию.
Например, если по расписанию репликация задана с 02:00 до 04:00 часов и репликации 30 минут, может до четырех раз.
Стандартный 180 минут или 3 часа. Создавая подключение между домена в разных сайтах, КСС определяет период реплика ции подключения как максимальный период по самому дешевому пути объектов сайтов с одного конца в другой.
Расписание репликации Если для репликации между сайтами применяется транспорт RPC, разрешается определить расписание репликации. Связям сайтов соответствует опи сывающее интервалы времени, в репликация разрешена. Если репликация выполняется через несколько связей сайтов, необходимо минимум одно общее вре окно (то есть перекрытие по времени), иначе репликация невозможна. На пример, если одна связь сайтов с 18:00 до 24:00 часов, а вторая Ч с 17:00 до 20:00 часов, интервал -- пересечение этих интервалов, то есть с до 20:00 часов.
ГЛАВА 6 Репликация Active Directory Путь Путь, которым репликация между сайтами, вычисляется на мации, хранимой в объектах связей сайтов. Изменения связи вступают в силу после:
Х репликации изменений связи сайтов в каждую генерирующую топологию сис тему по старой Х вызова КСС на генерирующих топологию системах.
Поскольку путь подключений выражается через набор связей атрибуты (параметры) объектов связей сайтов в пути образом:
Х стоимости суммируются;
Х репликации равен наибольшему из интервалов в пути;
Х логические параметры с применение булевой операции жения И.
Примечание Под логическими параметрами подразумеваются значения атрибута options объекта связи сайтов. Значение этого атрибута определяет такие особеннос ти поведения связи сайтов, как взаимная репликация и уведомление об изменени ях между сайтами. (Подробнее об этом Ч в разделах репликация и об изменениях далее в этой главе.) Таким образом, расписание связи Ч это пересечение всех расписа ний Если расписания перекрывается, путь не используется.
Конфигурация связи сайтов и задержки Расписание определяет интервалы времени, когда связь сайтов доступна, а период репликации Ч частоту репликации в этих интервалах. В совокупности эти факто ры определяют задержку репликации. Для сайтов, где максимальный период реп ликации в пределах сайта Ч минут, в худшем случае задержка всей репликации от контроллера-источника до в отдаленном сайте равна сумме периодов репликации, заданных для подключений между сайтом-источни ком и сайтом-приемником, плюс минут для каждого сайта в пути (включая сайт источник и В этом случае предполагается, что между сайтами ис пользуется транспорт RPC и что необходимые подключения доступны.
Взаимодействие расписания и периода репликации Если для выполнения репликации во всех сайтах требуется несколько связей сай тов, периоды репликации на каждой связи в совокупности влияют на полную дли ну соединения между сайтами. Кроме репликация выполняется только во вре мя пересечения расписаний сайтов.
Предположим, что сайты А и В объединены связью АВ, а сайты В и С Ч связью ВС.
В таком случае контроллер домена в сайте А обменивается данными с контроллером домена в сайте С только с частотой, максимальным пе риодом, заданным для связей АВ и ВС. В таблице 6-4 параметры определяющие частоту и время репликации между контроллерами домена в А, В и С.
270 ЧАСТЬ 1 Служба каталогов Active Directory Таблица 6-4. Периоды репликации и параметры расписания для двух связей Связь сайтов репликации АВ 30 минут С 12:00 до 04:00 часов минут С 01:00 до 05:00 часов В соответствии с параметрами, в таблице 6-4, контроллер домена в домене А может репликацию с;
контроллером домена в сайте В согласно расписанию и периоду связи АВ (раз в с 12:00 до 04:00 часов). Однако в отсутствие связи АС контроллер домена в сайте может реплицировать с контрол лером домена R сайте С раз час (что этих двух периодов с 01:00 до 04:00 часов (когда расписания этих двух связей пересекаются).
расписания Время в параметре Schedule для связи сайтов указывается в часах.
Например, репликацию выполнять с 00:00 до 01:00 часов, с 01:00 до 02: часов и т. д. Однако каждый блок фактическом расписании подключения 15 минут. в расписании с до 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 часами. Если репликация длится больше двух часов, вторая синх ронизация так как в очереди уже есть событие.
Примечание В очередь репликации размещаются и другие события, и вре мя начала репликации Ч приблизительно. Два события репликации для одного дела каталога и одного транспорта очередь не ставятся, Подробнее о создании и настройке связей сайтов в справочной Windows 2000 Server.
Конфигурация основного сервера-плацдарма При выборе следует иметь в виду, что он должен обрабатывать больший трафик репликации, чем другие серверы. При устранении неполадок иног да очень помогает того, какой контроллер является плацдармом.
После ручного в качестве ма для сайта служба КСС только этот сервер. Если в сайте несколько ГЛАВА 6 Репликация Active контроллеров домена сконфигурировано как основные служ ба в конечном счете один из них, руководствуясь при этом другими параметрами.
Pages: | 1 | ... | 3 | 4 | 5 | 6 | 7 | ... | 15 | Книги, научные публикации