Предупреждение конфликтов при изменении членства в группах
Одним из преимуществ Active Directory является реализованная в этой системе модель репликации данных. Если в Windows NT существует только один доступный для чтения/записи контроллер домена (PDC), который поддерживается несколькими доступными только для чтения контроллерами BDC, то в Active Directory каждый из контроллеров домена работает в режиме чтение/запись. Благодаря сложной системе репликации данных, применяемой в AD, каждый контроллер домена получает информацию обо всех изменениях, происходящих на других контроллерах. Передача реплицируемой информации по медленным каналам WAN осуществляется с предварительным сжатием в соотношении 10:1, а администраторы могут планировать время выполнения репликаций.
При изменении какого-либо атрибута учетной записи пользователя в NT 4.0 операционная система реплицирует всю информацию об этом пользователе. Система Active Directory в подобном случае реплицирует только измененный атрибут. Однако данные о членстве в группах хранятся в AD как один атрибут. Этот атрибут представляет собой полный список входящих в группу пользователей и машин (да, в Active Directory в состав групп могут входить и учетные записи машин). Загвоздка состоит в том, что в базе данных AD существует ограничение на максимальный размер атрибута. Система Active Directory не может использовать атрибуты, содержащие информацию о членстве в группе, и включающие в себя более 5000 идентификаторов SID. (Правда это ограничение не распространяется на встроенную группу Domain Users, которая может содержать более 5000 членов).
В связи с тем, что информация о членах группы хранится в виде одного атрибута, используемая в Active Directory модель репликации данных порождает еще одну потенциальную проблему: конфликты при изменении членства в группах. Отказ от использовавшейся ранее модели с одним ведущим узлом позволяет реализовать следующий сценарий. Предположим, что имеется два контроллера одного домена, находящиеся в городах СантЛуис и Оттава. Группа FaxServerOperators содержит имена пользователей, которые могут управлять программным обеспечением факс-сервера. Теперь предположим, что Лаура, администратор в Оттаве, добавляет себя в группу FaxServerOperators, а Стив, администратор в городе СантЛуис, приблизительно в то же время добавляет в эту группу свои данные.
Оба эти действия изменяют атрибут Members, относящийся к записи, описывающей объект FaxServerOperators. Изменения, сделанные Лаурой и Стивом, реплицируются локально и по всей сети и, в конце концов, сталкиваются. В Active Directory существует специальный алгоритм для разрешения подобных конфликтов, но, как правило, победителем выходит тот, чье изменение было сделано позже.
Если членство в группах меняется не слишком часто, то не стоит сильно беспокоиться о возможности столкновения таких изменений. Но чтобы гарантировать отсутствие конфликтов между выполняемыми модификациями в группах, можно, образно говоря, вернуться во времена NT 4.0. Для этого нужно выбрать один из контроллеров домена в качестве своеобразного центра обмена информацией. При этом все администраторы должны настроить утилиту администрирования Active Directory Users and Computers на данный контроллер. (Для этого следует запустить приложение Active Directory Users and Computers, щелкнуть правой кнопкой мыши на иконке домена, выбрать опцию Connect to Domain Controller и затем ввести имя того контроллера, с которым необходимо работать).
Изменение данных на контроллерах домена, расположенных вблизи клиента
Один совет для администраторов географически разнесенных доменов: не стоит полагать, что система репликации AD достаточно быстро отреагирует на внесенные изменения и обеспечит нормальную работу пользователей. Давайте вернемся к нашему примеру с городами СантЛуис и Оттава. Но пусть теперь Стив будет обычным пользователем без административных привилегий, а Лаура – администратором. Стиву требуется изменить его учетную запись в AD, например, в связи с переходом в другой отдел или в связи с изменением номера телефона. Стив связывается с Лаурой, и она делает необходимые изменения в его записи. Как скоро Стив увидит эти изменения?
Контроллеры домена имеются как в СантЛуисе, так и в Оттаве. Когда Стив запрашивает в Active Directory информацию о своей учетной записи, он, вероятно, посылает запрос контроллеру домена в СантЛуисе. Но когда Лаура производит изменения в AD, она, скорее всего, работает с контроллером в Оттаве. Если Лаура и Стив находятся в одном узле Active Directory, то все контроллеры этого узла получат информацию о внесенных изменениях за достаточно короткий отрезок времени: реплицирование информации между контроллерами домена внутри одного узла выполняется в течение 15 минут. Но скорость выполнения репликаций по каналам WAN зависит от настроек системы репликаций AD. Более частое обновление информации позволяет ускорить процесс распространения изменений учетной записи, но при этом возрастает загрузка каналов связи WAN. Если компания, где работают Лаура и Стив, экономит на использовании каналов связи при выполнении репликаций, то контроллеры домена, расположенные вблизи компьютера Стива, могут очень долго не получать сделанных изменений. Лаура может сократить эту задержку, если в момент внесения изменений настроит программу Active Directory Users and Computers на контроллер домена, находящийся поблизости от Стива. Выполняя модификацию информации на контроллерах домена не в Оттаве, а в городе СантЛуис, Лаура сможет гарантировать, что ближайшие к Стиву контроллеры быстро получат данные об изменении его учетной записи. Но в этом случае взаимодействие с контроллером домена будет происходить не по высокоскоростным каналам LAN , а по каналам WAN.
А теперь предположим, что Стив попросит Лауру поменять ему пароль, и она сделает это, при том, что ее компьютер подключен к контроллеру домена в Оттаве. Должен ли в этом случае Стив дожидаться, когда пароль будет реплицирован в СантЛуис? Нет, не должен. Пароли в Windows 2000 обрабатываются несколько иначе. Если Стив попытается зарегистрироваться на контроллере в СантЛуисе, прежде чем этот контроллер получит новый пароль, попытка регистрации будет отклонена. Но перед тем как выдать сообщение об отказе в регистрации данный контроллер домена свяжется с контроллером – мастером операций, имитирующим основной контроллер домена (PDC).
Что это такое? Несмотря на то, что Active Directory – распределенная, децентрализованная система, некоторые ее функции требуют централизации. Одна из таких функций – выполнение роли контроллера PDC. В доменах AD, где используются серверы NT (смешанный режим функционирования), резервным контроллерам BDC NT 4.0 для реплицирования данных необходим сервер PDC. Эту роль выполняет сервер - имитатор PDC, являющийся контроллером домена Windows 2000.
Если серверы NT в домене AD отсутствуют (стандартный режим), как в нашем примере, то мастер операций - имитатор PDC - не выполняет функции основного контроллера домена NT. Но и в этом случае у него есть работа: он должен сделать так, чтобы изменения паролей имели мгновенный эффект по всему домену. Ясно, что для завершения некоторых репликаций данных AD требуется длительное время, что может послужить причиной возникновения проблем. Так, Стив, возможно, просто не дождется, когда закончится реплицирование его пароля. Поэтому в системе Active Directory один из доменов контроллера и назначается сервером имитатором PDC. Как только контроллер домена получает новый пароль, он сразу же реплицирует его на этот контроллер. Если попытка Стива зарегистрироваться на локальном контроллере оказывается неудачной, то этот контроллер тут же пытается выполнить регистрацию на сервере- имитаторе PDC, даже если доступ к нему осуществляется по каналам WAN. Сервер PDC-имитатор всегда хранит самую последнюю версию пароля и позволит Стиву из СантЛуиса успешно зарегистрироваться в системе.
Использование серверов Global Catalog в лесах с одним доменом
Одно из преимуществ лесов Active Directory состоит в том, что даже если такой лес включает в себя несколько доменов, администратор всегда может предоставить доступ пользователям из одного домена к компьютерам, расположенным в другом домене. В результате любой пользователь из любого домена может легко зарегистрироваться на компьютере, принадлежащем другому домену. Но каким образом этот компьютер узнает, к какому домену относится данный пользователь? Без этой информации он не сможет найти контроллер домена, чтобы провести аутентификацию пользователя.
Для решения этой задачи обычно используется глобальный каталог (GC – Global Catalog) – конторллер домена с базой данных, содержащей краткий набор информации обо всех доменах леса. Допустим, пользователь регистрируется под именем mary@acme.com, и его учетная запись находится в домене Windows 2000 с именем southeast.sales.holdingcompany.com. Пользователь входит в систему с компьютера Windows 2000, вводя имя mary@acme.com. Этот компьютер запрашивает сервер GC: «В каком домене можно провести аутентификацию пользователя mary@acme.com?» Сервер GC отвечает: «В домене southeast.sales.holdingcompany.com.».
Задача планирования Active Directory включает в себя определение необходимого количества серверов GC для обеспечения быстрого выполнения регистрации пользователей в системе, а также задание местоположения этих серверов. Можно сделать каждый контроллер домена сервером GC. Но в таком случае постоянное обновление информации на этих серверах приведет к замедлению работы сети и самих серверов. Поэтому следует искать компромисс между временем отклика сети и количеством серверов GC.
Глобальный каталог является важным элементом при регистрации пользователей в лесах, состоящих из множества доменов. Но если лес включает в себя только один домен, то использование глобального каталога в этом случае кажется совершенно ненужным. Не так ли? И да, и нет. Хотя для лесов с одним доменом серверы GC и не требуются, существуют некоторые серверные приложения, которые обращаются к серверу GC вне зависимости от числа доменов в лесу. Поэтому, при наличии таких приложений, видимо, следует установить некоторое количество серверов GC.
С точки зрения производительности превращение контроллера домена в сервер GC обходится дорого только в многодоменных лесах, но не в лесах с одним доменом. Установка сервера GC для одного домена выполняется легко и быстро. Поэтому, если в лесу всего один домен, то можно все контроллеры этого домена сделать серверами GC.
Тщательно выбирайте имена
Есть вещи, которые никогда не изменяются. Так, после создания домена его нельзя переименовать. Чтобы обойти это ограничение, можно создать новый домен с новым именем и, используя программу миграции, скопировать в него учетные записи пользователей и компьютеров. Однако такая процедура достаточно сложна.
Также нельзя переименовать контроллер домена, во всяком случае, сделать это, не приложив больших усилий. До тех пор пока компьютер является контроллером домена, изменить его имя невозможно. Но Windows 2000 позволяет изменять роль компьютера и превращать контроллер домена в обычный сервер (member server) и обратно. Поэтому можно, используя программу Dcpromo (мастер установки AD), преобразовать контроллер домена в обычный сервер, переименовать его, а затем снова преобразовать в контроллер домена. Таким образом, для переименования контроллера домена требуется выполнить некоторый объем работ. Поэтому назначение имен в домене необходимо тщательно продумать.
Марк Минаси - редактор Windows NT Magazine, имеет сертификат MCSE; является автором книги «Mastering Windows NT Server 4.0» (издательство Sybex). С ним можно связаться по адресу: mark@minasi.com.