Планирование и развертывание серверов глобального каталога (Global Catalog, GC) — дело нелегкое, всегда есть опасность ошибиться с выбором расположения сервера GC при внесении изменений в Active Directory (AD), например, при добавлении нового домена или установке Microsoft Exchange 2000 Server. Хотя Microsoft Knowledge Base, Microsoft Windows Server 2003 Resource Kit и Microsoft Windows 2000 Server Resource Kit содержат ценную информацию о GC, обычно это разрозненные сведения. Рассмотрим несколько простых руководящих принципов размещения сервера GC при различных обстоятельствах и проясним некоторые вопросы, чтобы не возникало путаницы при внесении изменений в AD.

В глобальных каталогах хранятся все объекты леса, но только часть атрибутов этих объектов. GC содержит часто запрашиваемые атрибуты, которые называются частичным набором атрибутов. Серверы GC делают доступной информацию об этих атрибутах через протокол Lightweight Directory Access Protocol (LDAP) и используют репликацию для отправки частичных данных каждого домена на все другие GC. Запросы к GC обладают одним преимуществом перед запросами к контроллерам доменов (DC): контроллеры доменов хранят информацию только о собственных доменах, в то время как GC содержат информацию обо всех доменах леса.

Изменение частичного набора атрибутов

Следующая процедура позволяет определять, какие атрибуты должен включать GC. Для ее осуществления потребуется оснастка Microsoft Management Console (MMC) Schema, которую необходимо предварительно зарегистрировать. Для этого следует ввести в командной строке

regsvr32 schmmgmt.dll

После успешной регистрации появится соответствующее сообщение.

Существует еще одно требование, которое надлежит выполнить, прежде чем можно будет вносить изменения в схему: в реестре DC, выполняющего роль Flexible Single-Master Operation (FSMO), следует создать новый параметр. Как обычно, нужно соблюдать осторожность при внесении изменений в реестр. Следует создать параметр Schema Update Allowed (типа REG_DWORD) со значением 1 в разделе HKEY_LOCAL_MACHINESYSTEMCurrentControlSet ServicesNTDSParameters. Изменение вступает в действие незамедлительно, без перезагрузки. Завершив изменение схемы, эту возможность на DC нужно отключить, изменив значение параметра на 0.

Далее необходимо открыть на компьютере MMC и выбрать в меню Console пункт Add/Remove Snap-in, затем открыть оснастку Schema. Если регистрация выполнялась не на DC, который используется в качестве Schema Master, следует щелкнуть правой кнопкой Active Directory Schema, выбрать Change Domain Controller, ввести имя исполнителя роли Schema Master и щелкнуть OK. Затем в правой панели требуется выбрать нужный атрибут и дважды щелкнуть по нему, чтобы перейти к свойствам. На вкладке General, показанной на экране 1, следует установить или снять флажок Replicate this attribute to the Global Catalog. Эта ячейка будет недоступна, если используемая учетная запись не является членом группы Schema Administrators. По умолчанию в эту группу входит только учетная запись Administrator корневого домена. На всякий случай группу Schema Administrators желательно сохранять пустой и добавлять в нее пользователей, только когда необходимо внести в схему изменения.

Никогда не следует менять настройки по умолчанию без веских на то оснований. Добавление еще одного атрибута в частичный набор атрибутов может заметно повлиять на репликацию в сети вследствие так называемой полной синхронизации содержимого GC. Реакцией каждого GC на добавление атрибута является выполнение репликации с полным обновлением содержащейся в нем доступной только для чтения информации о других доменах леса. Чем больше доменов имеет лес, тем значительнее будут последствия. Лучше вообще не вносить никаких изменений в частичный набор атрибутов в производственной среде без настройки расписания. Если лес однодоменный, о последствиях полной синхронизации GC можно не беспокоиться, поскольку GC не содержат информации о других доменах и, следовательно, не производят репликацию дополнительной информации. Не стоит лишний раз удалять атрибуты из GC — это может повлиять на эффективность системы.

Специалисты Microsoft рекомендуют для внесения в схему изменений использовать сценарии. Это позволяет избежать ненужных изменений и тщательно протестировать все модификации в лабораторных условиях. Чтобы улучшить репликацию частичного набора атрибутов, разработчики Microsoft изменили протокол репликации в Windows 2003, и полная синхронизация GC больше не выполняется. Windows 2003 реплицирует только добавленные атрибуты.

Экран 1. Репликация атрибутов на GC

Включение GC

В оснастке AD Sites and Services нужно раскрыть Sites. Выбрав узел, следует открыть его и выбрать DC. Далее требуется щелкнуть правой кнопкой NTDS Settings, после чего на странице свойств General будет отображаться параметр, который позволяет включить (флажок установлен) и отключить (флажок снят) использование данного контроллера домена в качестве GC. Просто установка флажка в этой ячейке не означает, что GC стал доступен и готов к работе, — еще должна быть выполнена репликация. Системный журнал Directory Services будет содержать запись с ID 1119, когда репликация завершится и GC будет готов к работе с запросами.

Поиск GC

Определить, какие контроллеры доменов в настоящий момент сконфигурированы в качестве GC, можно несколькими способами, используя инструменты графического интерфейса, командной строки и сценарии. В дополнение к оснастке Sites and Services можно задействовать Repadmin, инструмент командной строки из папки Support Tools на компакт-диске Windows 2000. Чтобы запустить Repadmin, следует ввести команду

C:>repadmin /showreps domain_controller

где domain_controller — это имя DC, о котором нужно узнать, является ли он GC. Если контроллер домена является GC, сообщение, выведенное после выполнения команды, будет содержать текст DSA Options: IS_GC.

Чтобы получить список всех GC леса, проще всего использовать инструмент Dsquery из папки %systemroot%system32. Чтобы запустить Dsquery, нужно ввести:

C:>dsquery server -forest -isgc

Выполнять Dsquery можно только на платформах Windows 2003 и Windows XP. Если Dsquery в распоряжении администратора нет, можно воспользоваться Active Directory Replication Monitor (replmon.exe). Запустив приложение, следует выбрать любой DC в списке Monitored Servers в левой панели. Возможно, сначала понадобится добавить DC. Необходимо щелкнуть правой кнопкой на DC и выбрать Show Global Catalog Servers in Enterprise, как показано на экране 2. В диалоговом окне Show Global Catalog Servers, изображенном на экране 3, следует выбрать DC и нажать OK. Новое окно, отображающее все GC, будет содержать вариант для записи результатов в текстовый файл. Нужно посмотреть, на каком порту GC ожидает запросы LDAP. GC использует порт 3268/TCP для входящих запросов LDAP и порт 3269/TCP — для подключений LDAP Secure Sockets Layer (SSL).

Совмещение Infrastructure Master с GC

Необходимо позаботиться о том, чтобы контроллер домена, выполняющий роль Infrastructure Master, не был сконфигурирован как GC. Чтобы определить, какие DC выполняют системные роли в конкретном домене, я предпочитаю использовать Netdom, инструмент командной строки, который хранится в папке Support Tools на компакт-диске Windows 2000. Чтобы запустить Netdom, следует воспользоваться командой

C:>netdom query FSMO

Контроллер домена Infrastructure Master сервером GC лучше не назначать. Infrastructure Master поддерживает ссылки объектов собственного домена на объекты в других доменах. Типичный пример — членство в группах. Группа в домене A может содержать членов домена B. Если один из членов группы в домене B переименован, новая информация (т. е. отличительное имя — DN) должна быть каким-то образом переправлена на контроллеры доменов в домен B, чтобы они точно отображали информацию о членстве в группах. Infrastructure Master содержит записи, называемые фантомами (phantoms), в базе данных, представляющей объекты из других доменов. Infrastructure Master периодически обращается к ближайшему GC, чтобы определить, не произошли ли какие-нибудь изменения в объектах, для которых он хранит фантомные записи. Если Infrastructure Master обнаруживает изменения, он удаляет старый фантом и создает новую запись. Затем Infrastructure Master реплицирует обновление на другие DC в домене. Не следует включать роль Infrastructure Master на сервере GC, потому что GC уже имеют информацию об объектах в других доменах и, следовательно, такие контроллеры не будут создавать необходимые фантомные записи. Другими словами, Infrastructure Master не сможет выполнять свою роль.

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

GC как Domain Naming Master

Сервер, выполняющий роль мастера именования домена — Domain Naming Master — вносит изменения в пространство доменных имен леса, например, при добавлении или удалении домена. Когда создается новый домен, Domain Naming Master должен обеспечить единственность имени, т. е. гарантировать, что никакой другой домен (или доменный объект) не имеет такого же имени. Он делает это, проверяя локальный (наиболее близкий) сервер GC. Если GC не является локальным, изменение выполнено не будет. Чтобы избежать подобного конфликта, следует располагать сервер с ролью Schema Master поблизости от Domain Naming Master.

Экран 3. Выбор сервера GC

Каждому сайту — свой GC

В доменах, работающих в собственном режиме, GC играют важную роль в процессе регистрации пользователя. Центр распределения ключей (Key Distribution Center, KDC) на контроллере домена, выполняющем аутентификацию, связывается с GC, чтобы классифицировать пользователя по принадлежности к универсальным группам, и добавляет к пользовательскому маркеру записи SID универсальных групп, членом которых является пользователь. Если клиент не может связаться с GC и получить эту информацию об универсальных группах, вход в систему будет невозможен. Процесс регистрации не нужен в доменах со смешанным режимом, поскольку универсальные группы функционируют только в собственном режиме Windows 2000. В Windows 2003 не требуется, чтобы GC был доступен в процессе регистрации; это обусловлено тем, что в новой версии реализовано кэширование членства в универсальных группах. Кэш заполняется при первой регистрации, а при последующих регистрациях используется кэшированная информация. Контроллеры доменов периодически обновляют кэш через ближайшие GC.

Меня часто спрашивают, должен ли каждый домен иметь собственный GC. Поскольку все GC леса содержат одинаковую информацию независимо от домена, ответ, очевидно, — нет. Однако каждый узел AD должен иметь по крайней мере один GC. Информация о расположении GC хранится в записях DNS SRV. В результате клиентские программы, работающие в пределах сайта, предпочитают связываться с ближайшими GC, т. е. с GC в том же сайте, а не в других. Если в пределах сайта не доступен ни один GC, запросы будут адресоваться к GC в других сайтах, с которыми установлена связь по медленной линии, что, конечно, нежелательно.

Может быть, имеет смысл все DC сконфигурировать как GC? Преимущество этого подхода состоит в максимальной избыточности GC, а также в том, что вопрос о назначении роли Infrastructure Master решается очень просто. Недостатком является ухудшение производительности и сети, и DC вследствие возросшего трафика репликации. Очевидно, что издержки производительности возрастают с ростом числа доменов, DC и GC. Необходимо стремиться к тому, чтобы поддерживать баланс между достижением хорошего уровня избыточности и сокращением издержек. В однодоменной среде следует сконфигурировать все DC как GC, поскольку это не повлечет за собой никаких дополнительных затрат.

Мне могут возразить, что в однодоменной среде GC вообще не нужны, поскольку контроллеры доменов уже содержат всю информацию, относящуюся к объектам леса. Дело действительно может обстоять таким образом, но я рекомендую все же иметь GC, поскольку некоторые службы обращаются именно к ним. Exchange 2000 — пример такого приложения. А еще GC необходим при регистрации пользователей (по крайней мере в AD Windows 2000) независимо от того, сколько имеется доменов.

GC и Exchange 2000

Я хочу подчеркнуть, что и клиент Exchange 2000, и клиент Microsoft Outlook активно используют GC. Exchange 2000 обращается к GC за информацией о пользователях, контактах и списках рассылки (DL), а также за важными конфигурационными данными. Без доступа к GC большинство операций Exchange 2000 выполняться не будет. Клиенту Outlook нужен доступ к GC для выполнения поиска по глобальному списку адресов (Global Address List, GAL).

Я настоятельно рекомендую иметь по крайней мере один доступный GC на каждом узле AD, на котором расположен сервер Exchange 2000. Еще одна общая рекомендация — устанавливать дополнительный GC на каждые четыре сервера Exchange. В принципе, чтобы иметь сеть с надежной передачей сообщений, я рекомендую, если позволяют средства и сеть может справиться с дополнительной репликацией данных, развернуть несколько дополнительных GC.

Заметки на полях

Хотя при размещении GC следует руководствоваться довольно жесткими правилами, в конечном итоге можно проявить гибкость при развертывании серверов GC. Нужно помнить, что каждая среда AD уникальна и что решение, которое работает в одной организации, может быть совсем непригодно в другой.

Слишком большое рвение при развертывании GC имеет определенные недостатки, такие как всплески нагрузок на сеть и интенсивная работа DC, но и скупость в этом отношении не принесет ничего хорошего. Желательно обеспечить небольшой избыток GC и помнить о том, что, даже если вы ошибетесь с количеством GC, можно свободно включить или отключить роль GC на сервере по ходу дела.

Наконец, последнее и самое важное замечание. Размещение GC не является одноразовой акцией. По мере расширения леса необходимо регулярно пересматривать свои решения о размещении GC. Мониторинг контроллеров доменов и инфраструктурных ресурсов сети должен помочь в этом..

Тони Мюррей-Смит (tony@activedir.org) — специалист по службам каталогов и почтовым системам, поддерживает сайт ActiveDir.org. Имеет сертификаты MVP и MCSE