ПЛАНИРОВАНИЕ AD

Это подчеркивается в бесчисленном множестве статей, официальных документов и даже книг. Служба AD существенно расширяет набор средств управления сетевой инфраструктурой, но одновременно и повышает сложность системы, так что не следует расценивать ее только как эволюционное развитие модели доменов NT 4.0. В то же время служба AD позволяет делегировать административные полномочия и управлять настольными системами с помощью групповых политик, поэтому к ней нельзя относиться как к простому расширению доменной архитектуры Windows NT 4.0. В данной статье рассматриваются технические вопросы и основные моменты планирования развертывания AD - от организации пространства имен до проектирования топологии репликации.

Логическое пространство имен

Приступая к планированию инфраструктуры AD, необходимо продумать структуру пространства имен, другими словами, определить способ организации сетевых ресурсов в каталоге AD. В Windows NT 4.0 существует всего несколько способов организации пространства имен, так что выбор сделать несложно - домены позволяют задействовать всего два уровня иерархии, внутри домена не существует разграничения полномочий, а NetBIOS не поддерживает иерархическое именование. Концепция AD базируется на иерархической спецификации X.500 и службе именования DNS, поэтому вопрос о выборе способа организации пространства имен на самом деле существенно шире. Пространство имен AD использует три основных структурных уровня: домены, деревья доменов и леса.

Домены

Так же, как и в NT 4.0, домен в AD является границей общей области безопасности. Домен AD использует общую политику защиты и те же самые локальные и глобальные группы домена. Кроме того, домен служит границей репликации: AD допускает репликацию объектов домена только на контроллеры данного домена.

Деревья доменов

В Windows 2000 введен дополнительный уровень иерархии, дерево доменов. Дерево доменов - иерархия доменов, которые являются частью общего пространства имен DNS. Например, домен mycompany.com верхнего уровня может содержать два дочерних домена: east.mycompany.com и west.mycompany.com. Эти три домена образуют дерево доменов AD. В Mycompany. com можно также создать вспомогательный домен yourcompany.com и построить отдельное дерево доменов с пространством имен DNS yourcompany.com.

Леса

Лес доменов - это еще одно нововведение AD. Лес представляет собой одно или несколько деревьев доменов, использующих общую схему и общую границу защиты Kerberos. Каждый лес может иметь только одну схему, которая определяет объекты и свойства AD. В пределах леса действуют транзитивные доверительные отношения Kerberos, объединяющие все домены. По отношению к «чужим» доменам лес может устанавливать доверительные отношения подобно тому, как строятся доверительные отношения между доменами в NT 4.0. Так что если в корпоративной сети создано несколько лесов, то для организации совместного использования ресурсов необходимо определить нетранзитивные доверительные отношения между этими лесами, как это делалось в NT 4.0. В настоящее время возможности объединить два леса не существует.

На Рисунке 1 показано соотношение доверительных отношений между доменами, деревьями доменов и лесами в AD. Обращаю внимание читателей на двунаправленное транзитивное доверительное отношение Kerberos между деревьями mycompany.com и yourcompany.com. Особенность AD состоит в том, что между всеми доменами в пределах одного леса устанавливаются транзитивные доверительные отношения.

При проектировании логического пространства имен необходимо решить, сколько требуется доменов, деревьев доменов и лесов и как их именовать. Если имеется развернутая инфраструктура NT 4.0, можно либо воспроизвести в AD существующую доменную структуру, либо расширить ее в новом пространстве имен. Благодаря заложенной в AD возможности делегирования административных полномочий через организационные единицы (OU), Windows 2000 позволяет сократить число используемых доменов, по сравнению с NT 4.0. При этом необходимость создания новых доменов определяется в большей степени потребностью репликации объектов и соображениями безопасности, нежели необходимостью делегирования административных полномочий.

При проектировании пространства имен следует учитывать не только существующую модель доменов NT 4.0. Определяя количество доменов и планируя структуру деревьев доменов и лесов, следует также рассматривать политические, организационные, географические и технические факторы.

Организационно-политические факторы

Должно ли пространство имен отражать и сохранять существующие политические границы организации? Ведь сокращение количества доменов, помимо всего прочего, требует определенных дипломатических способностей и навыков. После принудительного объединения самостоятельных доменов (и структурных единиц) в один домен ситуация может стать просто взрывоопасной. Недооценка политических (в рамках организации) последствий изменения сетевой структуры может дорого обойтись.

Проект пространства имен должен достаточно абстрактно представлять организационную структуру предприятия или корпорации, чтобы в случае «перестройки» структура AD не потребовала коренной переработки. Например, желательно, чтобы объединение региональных подразделений не требовало перемещения организационных единиц (OU) и пользователей между доменами. Лучше, если для этого потребуется только включить пользователей в другую группу. Необходимо учитывать, что в Windows 2000 затруднительно (точнее, практически невозможно) переименовать домен и абсолютно невозможно переименовать корневой домен леса. Поэтому, если проектируемое пространство имен жестко привязано к организационно-административной структуре корпорации, лучше пересмотреть выбранный подход.

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

Географические факторы

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

Технические факторы

Разработчики Microsoft проделали огромную работу по реализации полноценной службы каталогов в Windows 2000, но некоторые технические проблемы заставляют выбирать то или иное направление развития пространства имен. Некоторые из этих проблем будут рассматриваться в статье более подробно. Реализованная в Windows 2000 модель каталога AD имеет существенные ограничения, которые необходимо учитывать при проектировании пространства имен.

Особенности Windows 2000 также могут оказать существенное влияние на разрабатываемый проект. Так, пространство имен может отражать выбранный способ применения объектов групповых политик (Group Policy Object, GPO). По крайней мере, перед завершением проектирования пространства имен полезно ознакомиться с функциями GPO, чтобы понять, какое влияние они могут оказать на проект.

Сколько потребуется доменов и лесов?

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

При планировании многоуровневой доменной структуры корень леса (первый домен, являющийся контейнером инфраструктуры) рекомендуется оставить пустым, свободным от рядовых пользователей. Этот домен играет особую роль в иерархии доменов: здесь «прописаны» группы Enterprise Admins и Schema Admins (администраторы предприятия и администраторы схемы), в которые следует включать только некоторых администраторов сети.

Когда пользователь одного домена обращается к ресурсам в другом домене, это вызывает пересечение границ доверительных отношений (даже в Windows 2000), что приводит к снижению эффективности. Поэтому в многодоменной схеме, которая подразумевает частое обращение к механизму доверительных отношений, следует ожидать некоторого замедления времени реакции, особенно если объекты GPO созданы в одном домене, а доступ к ним осуществляется из других доменов. Чтобы потери эффективности были минимальными, можно создавать между часто общающимися доменами «обходные» доверительные отношения - это позволит сократить число доменов, через которые проходит обработка обращения к ресурсам.

В Windows 2000 домены сохраняют функцию границ безопасности. Поэтому для каждого домена необходимо явно определить политику безопасности (например, порядок блокировки учетной записи, минимальную длину пароля). Не следует думать, что политика безопасности, заданная для одного домена, автоматически распространяется на все остальные.

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

Сколько лесов следует создавать в сети предприятия? Как правило, в рамках рабочей инфраструктуры предприятиям необходим только один лес AD. Еще один лес можно создать для тестирования и разработки или испытания изменений, которые планируется произвести в AD. Несложно понять, почему лес должен быть всего один. В настоящий момент Windows 2000 не имеет простых и удобных средств интеграции множественных лесов в единую инфраструктуру. Лес AD Windows 2000 использует общую схему, общий глобальный каталог (GC, Global Catalog) и общую схему доверительных отношений Kerberos. Каждый следующий лес будет представлять собой совершенно самостоятельную, изолированную среду. Для обмена информацией между различными лесами придется устанавливать явные нетранзитивные доверительные отношения в стиле Windows NT 4.0.

Измерение контроллеров домена

После того как вопрос логической организации пространства имен решен, следует выяснить, как реально осуществить проект. Эта задача не так уж проста, поскольку при реализации на физическом уровне требуется разрешить множество вопросов, от необходимой аппаратной конфигурации контроллеров домена до выбора топологии узлов для репликации AD. При этом следует принять во внимание текущие ограничения AD. В конце концов, необходимо выбрать реализацию службы DNS. Степень готовности сервера DNS влияет на выполнение репликации AD и время отклика системы при аутентификации пользователей.

Решая вопрос о характеристиках контроллеров домена AD, необходимо определить, что значит «большой». Если нужно объединить в один домен AD десять доменов NT 4.0, содержащих 100 000 учетных записей пользователей, то окажется, что каждый контроллер домена AD должен быть более мощным и обладать большим объемом дискового пространства, чем используемые контроллеры доменов NT 4.0. Вопрос в том, насколько более мощными должны быть новые серверы? Компания Microsoft предоставляет инструментарий для быстрого расчета требований контроллера домена (более подробную информацию можно найти во врезке «Active Directory Sizer»).

Каждый объект AD требует некоторого дискового пространства на контроллере домена. Главная база данных AD - файл ntds.dit - размещается на каждом контроллере домена. Чем больше используется объектов и атрибутов объектов, тем больше будет размер базы данных AD. Каталог AD предоставляет более широкие возможности масштабирования, чем NT 4.0, но при этом база данных AD требует намного больше места, чем NT 4.0 SAM. Каталог AD содержит больше типов объектов (например, тома, групповые политики), а, кроме того, объекты AD имеют более широкий набор атрибутов (учетные записи пользователей могут содержать телефоны, адреса и адреса электронной почты). Так, при модернизации имеющегося домена NT 4.0, содержащего примерно 3000 учетных записей пользователей и компьютеров, а также несколько сот групп пользователей, размер полученного файла ntds.dit составил приблизительно

38 Мбайт. С помощью инструментария AD Sizer было установлено, что при модернизации домена NT 4.0 с 20 000 пользователей и расширенным набором атрибутов (включая использование Microsoft Exchange 2000 Server), размер файла базы данных AD ntds.dit составит 500 Мбайт. Размер базы ntds.dit для большого домена со сложной структурой может составить несколько гигабайт.

В Таблице 1 приведены типичные размеры различных объектов AD. Учетная запись пользователя с минимальном набором атрибутов занимает 3,7 Кбайт. Если для создания учетных записей пользователей и компьютеров применяется подключаемый модуль (snap-in) AD Users and Computers консоли управления Microsoft Management Console (MMC), то набор атрибутов будет минимальным, но обычно требуется расширенный набор атрибутов, особенно если планируется использовать Exchange 2000.

На размер каталога AD оказывают влияние и другие, менее очевидные факторы. Так, например, каждая запись элемента управления доступом (access control entry, ACE) в списке ACL объекта AD занимает примерно 70 байт. Принимая во внимание реализованную в AD модель наследования, используемую при применении защиты, сделанное в ACL изменение может автоматически добавлять новые записи ACE к тысячам объектов каталога. Поэтому при делегировании прав на управление объектами в инфраструктуре AD нужно соблюдать особую осторожность. По возможности, следует назначать права для групп, а не для отдельных пользователей. Этот подход сокращает число записей ACE, необходимых для объектов и атрибутов.

Узлы и связи

Проектирование топологии узлов (site) - возможно, наиболее ответственный этап планирования AD. Прежде всего, необходимо ознакомиться с используемыми в AD концепциями узлов и связей узлов, именованием контекстов, глобальным каталогом GC и объектами подключения. Узлы представляют собой объекты AD, определяющие способ копирования данных AD в сети. Узлы связаны с создаваемыми объектами «подсеть» (subnet objects), которые в свою очередь соответствуют подсетям TCP/IP в физической сети.

Узлы определяют, когда и как часто должна происходить репликация данных между контроллерами домена. Репликация между контроллерами домена в пределах узла (т. е. intrasite) происходит в соответствии с установленным графиком, по умолчанию копирование выполняется каждые 5 мин. Контроллеры домена, расположенные в разных узлах, выполняют репликацию в соответствии с заданным расписанием, но не чаще, чем один раз в 15 мин.

Помимо функции группировки контроллеров домена для планирования репликации данных AD, узлы помогают рабочим станциям и серверам находить ресурсы, которые расположены наиболее близко в сети. Например, при процедуре аутентификации в домене AD рабочая станция сначала проверяет собственный IP-адрес и маску подсети, чтобы определить свою подсеть. Зная свою подсеть и узел (через запрос к AD), рабочая станция посылает запрос службе DNS, чтобы найти контроллер домена в своем узле.

Рисунок 2. Связь узлов.

Узлы соединяются между собой связями - каналами, формирующими группы узлов. На Рисунке 2 изображена схема компании, имеющей четыре региональных центра дистрибуции. В каждом центре рабочие станции и контроллеры доменов объединены скоростной локальной сетью. Каждый из центров соединен с другими центрами линиями T-1. Каждый центр представляет собой узел. В данном случае администратор AD соединил все узлы между собой, поскольку соединения между узлами имеют одинаковую пропускную способность. При описании связей узлов можно указать расписание в рамках каждой связи и стоимость обмена. Расписание определяет частоту и время репликации данных между узлами, стоимость представляет произвольное значение, которое устанавливает приоритет подключения между узлами.

Все узлы, соединенные связями, выполняют репликацию по единому расписанию. Один и тот же узел может быть включен в разные связки, и в этом случае начинает играть роль стоимость связи. В примере с центрами дистрибуции можно добавить дополнительную связь по коммутируемой линии для дублирования выделенного канала T-1 на случай сбоя. Для этой связи устанавливается стоимость выше, чем для более скоростных соединений. Это позволяет AD выбирать более дешевый путь репликации в том случае, если все нормально, и переключаться на модемную линию при неисправности канала T-1.

Контексты именования

Одним из основных элементов AD являются контексты именования (их иногда еще называют разделами - partitions). Контексты представляют собой пути, используемые Windows 2000 для репликации различных типов информации между контроллерами домена в лесу. Для каждого домена в лесу Windows 2000 реплицирует контекст именования домена на все контроллеры в пределах данного домена.

Windows 2000 реплицирует контекст именования «схема» (т. е. схему AD) и контекст именования «конфигурация» (т. е. узел и информацию о конфигурации подсетей, а также другие метаданные репликации) на все контроллеры домена в лесу. Глобальный каталог (GC) является частичной копией всех объектов в лесу, поэтому он реплицируется на контроллеры домена, которые определены как серверы GC. Контексты именования «схема» и «конфигурация» содержат информацию, которая для большинства предприятий изменяется, как правило, нечасто, поэтому они не затрагивают топологию узла так сильно, как контексты именования домена и GC.

AD использует два протокола репликаций. Стандартный протокол RPC поддерживает репликацию трех контекстов именования и GC, при этом допускается компрессия данных при репликации между узлами. Стандартный протокол SMTP используется только для репликации между узлами контекстов именования схемы и конфигурации, а также GC. Протокол SMTP полезен для соединений медленных, ненадежных или же недоступных большую часть дня. При использовании для репликации протокола SMTP трафик, по сравнению с протоколом RPC, возрастает в два раза. Для определения связей узлов и используемых протоколов применяется подключаемый модуль AD Sites and Services консоли MMC.

Объекты подключения

После того как топология узла определена, Windows 2000 создает соединения репликации. AD содержит службу KCC - Knowledge Consistency Checker, которая выполняется на всех контроллерах домена и создает объекты «соединение» между всеми контроллерами домена в лесу. Объекты «соединение» управляют трафиком репликации между контроллерами домена. KCC строит эти объекты внутри узла таким образом, чтобы путь между двумя контроллерами домена не занимал более трех переходов (hop). На Рисунке 3 показано окно подключаемого модуля AD Sites and Services, в правой панели которого отображено соединение, автоматически созданное KCC для сервера SERVERA узла BRANCH.

Рисунок 3. Сгенерированный KCC объект «соединение».

Объекты «соединение» представляют собой однонаправленные пути. Каждый из контроллеров домена будет иметь собственные соединения, связывающие этот контроллер с другими контроллерами доменов. Если в домене имеется значительное количество контроллеров, между которыми осуществляется репликация, возможна ситуация, когда пара доменов не соединена двунаправленными связями. Сервер, инициирующий событие репликации в рамках узла, уведомляет сервер, с которым он связан объектом «соединение», что произошли изменения. После этого получающий сервер «вытягивает» данные с инициировавшего репликацию сервера.

KCC также строит объекты «соединение» для репликации между узлами. При создании узла KCC выбирает сервер, который будет выполнять роль моста (bridgehead) при сообщениях между созданным узлом и удаленными узлами. Этот сервер обмена использует свои объекты «соединение» для репликации на удаленные узлы в соответствии с графиком, который администратор задает в объектах связи с узлами. В случае сбоя данного сервера его обязанности принимает на себя другой сервер узла.

Проектирование топологии узла

При проектировании топологии узла AD необходимо учитывать, как компания будет использовать AD, и понимать, как различные особенности инфраструктуры Windows 2000 влияют на трафик репликации. Для оценки использования AD следует в первую очередь изучить, как применяются существующие домены NT 4.0. Например, следует отметить среднее количество создаваемых учетных записей пользователей, частоту смены паролей, среднее число пользователей в локальных группах, частоту входов пользователей в систему. Все эти характеристики должны учитываться при проектировании топологии узла.

Имеющиеся в Windows 2000 инструментальные средства позволяют оценить сетевой трафик, возникающий при смене пароля или добавлении нового пользователя (эти данные можно получить с помощью AD Sizer или Microsoft Windows 2000 Resource Kit). Но только администратор сети может знать, с какой частотой происходит ввод новых пользователей и какой установлен срок действия паролей. Репликация AD может выполняться на уровне атрибутов (т. е. при смене пользователем пароля меняется только атрибут пароля, а не весь объект «пользователь»). AD содержит значительно больше атрибутов, чем SAM NT 4.0, так что в зависимости от способа применения объектов она может генерировать трафик больший или меньший, чем SAM.

При проектировании топологии узла необходимо ответить на следующие вопросы.

• Где следует установить границы узла?
• Какая полоса пропускания необходима для получения малой задержки репликации AD?
• В каких точках следует установить локальные контроллеры домена, чтобы не проводить удаленную аутентификацию пользователей?

Как уже говорилось выше, узлы определяют частоту и расписание репликаций AD. Репликация внутри узла происходит с интервалом в 5 мин; репликация между узлами происходит через 15 мин или реже. Многих администраторов интересует, каково минимальное значение полосы пропускания, начиная с которого контроллеры домена следует помещать в разные узлы. Универсального правила не существует, обычно распределение контроллеров по различным узлам необходимо в тех случаях, когда служебный трафик создает в сети значительную нагрузку. В этих случаях нужно разделить узел на два и установить репликацию через более продолжительный интервал. При репликации между узлами используется компрессия данных для блоков более 32 Кбайт. Используемый алгоритм компрессии достаточно эффективен, так что трафик может сокращаться до 90%. Впрочем, степень сжатия зависит от характера передаваемых данных - пароли практически не сжимаются, так как передаются в зашифрованном виде.

Экран 4. Результаты работы AD Sizer.

Грубая оценка объема данных репликации AD в сети позволяет установить частоту репликации для связей узла. Следует помнить, что связи между узлами должны иметь примерно одинаковую пропускную способность. Так, если узлы A, B, и C соединены, то репликация будет выполняться по единому расписанию, установленному для данной связи. При установке расписания следует использовать возможность компрессии данных между узлами и минимизировать время ожидания между контроллерами домена. Можно было бы установить минимальную задержку - 15 мин, но если при этом объем данных при каждой репликации менее 32 Кбайт, то компрессия не включается. В результате может оказаться, что при частой репликации пересылаются большие объемы данных, чем если бы репликация выполнялась реже.

При выборе топологии узла помимо трафика репликации данных AD, вызываемого изменениями контекста именования домена, следует учесть и другие источники трафика. Ниже перечислены некоторые из наиболее очевидных.

Серверы GC

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

Разделяемые ресурсы SYSVOL

Разделяемые ресурсы SYSVOL реплицируются между контроллерами домена. Объекты GPO также сохраняют данные в SYSVOL. Служба репликации файлов NT (NT File Replication Service, NTFRS) выполняет копирование данных между всеми контроллерами домена. Для распространения этих изменений NTFRS использует существующую топологию узлов.

Записи зоны DNS

При использовании встроенной в AD службы DNS последняя сохраняет записи зоны в контексте именования домена, в котором работают серверы DNS. Данные в зоне DNS могут часто изменяться, например при наличии большой группы мобильных пользователей, чьи рабочие станции могут часто изменять адреса IP.

Члены групп

Объекты групп AD сохраняют сведения о своих членах в одном многозначном атрибуте. Поэтому при изменении свойств одного пользователя в списке с 500 пользователями AD целиком копирует атрибут, содержащий сведения о 500 пользователях. Разработчики Microsoft рекомендуют не включать в группы более 5000 членов, поскольку копирование полного атрибута такого размера вызывает задержки в работе сети. Если требуется создать группу, содержащую большое число пользователей, можно разбить множество пользователей на подгруппы, и уже их объединять в группу.

Наконец, следует решить, будут ли контроллеры домена находиться близко к пользователям или же они будут расположены удаленно. Вообще, если трафик для локального контроллера домена, создаваемый AD и связанными с ней службами, выше, чем трафик удаленных рабочих станций, то контроллер домена не следует располагать к удаленным станциям близко. К тому же при создании выделенного узла для удаленных пользователей и помещении контроллера домена в этом узле, скорее всего, придется разместить в нем же и сервер GC, а это немедленно потребует увеличения полосы пропускания для данного узла. (Этот аспект проектирования узлов AD уже рассматривался в статьях Ш. Дьюби «Узлы AD, Часть 1» и «Узлы AD, Часть 2», опубликованных, соответственно, в №№4(7), 5(8) Windows 2000 Magazine/RE.)

Таким образом, практическая реализация AD требует тщательного планирования и проектирования. Принимая решения о конкретных аспектах реализации проекта, необходимо учитывать реальные потребности конкретной компании и особенности инфраструктуры. При грамотном использовании вспомогательных инструментов, Resource Kit и AD Sizer, в деле проектирования AD можно обойтись без гадания на кофейной гуще. Нужно просто тщательно все взвесить, реально оценить потребности и возможности, а полученный результат удвоить - просто так, для подстраховки.

ОБ АВТОРЕ

Active Directory Sizer