Cточки зрения технологии служба каталогов Active Directory (AD) – наиболее интересный компонент операционной системы Windows 2000. Несмотря на это, пользователи уделяют куда меньше внимания вопросам построения узлов AD, по сравнению с другими элементами системы, такими, как структура доменов Windows 2000 или глобальный каталог (Global Catalog, GC). Хотя объем задач, возникающих в связи с внедрением Windows 2000, и без того очень велик, все же стоит поближе познакомиться с узлами AD, так как они способны заметно повлиять на процесс работы Windows 2000 в корпоративной сети. Освоив использование узлов Active Directory для управления репликациями в сетях Windows 2000, я убедился, что они действительно заслуживают пристального внимания.

Разработчики Microsoft реализовали в Windows 2000 механизм узлов Active Directory, чтобы решить проблемы, присущие Windows NT 4.0. Физическая топология сети крупного предприятия представляет собой отдельные островки каналов высокоскоростной связи (офисные LAN), окруженные «океаном» низкоскоростных каналов связи (каналы WAN, связывающие эти островки). При этом NT 4.0 не умеет распознавать физическую топологию сети, на которой базируется, и не в состоянии непосредственно регулировать загрузку каналов WAN. Windows NT 4.0 при выполнении репликаций использует только понятия доменов и контроллеров доменов. Клиентские станции NT 4.0 (при помощи WINS) выбирают контроллер домена для регистрации в системе в зависимости от того, к какому домену принадлежат.

Если домен включает в себя несколько каналов WAN, то некоторые клиенты будут регистрироваться на удаленных контроллерах. В такой ситуации будут возникать задержки или ошибки при регистрации в сети и доступе к ресурсам. Указанные проблемы можно решить при помощи утилит, например Setprfdc. Тем не менее сама логическая природа доменов NT часто вступает в противоречие с физической природой топологии сети. Механизм узлов Active Directory был разработан для того, чтобы операционная система могла понимать топологию сети, выделять высокоскоростные «островки» и более разумно управлять сетевым трафиком.

Согласно документации Microsoft под узлом AD следует понимать подсеть и IP, использующую каналы связи с хорошей пропускной способностью. Как правило, узлы включают в себя компьютеры, подключенные к качественным каналам связи, хотя это и не обязательно. Существует ряд факторов (таких, как пропускная способность канала WAN и время задержки), влияющих на качество связи, и понятие качественных каналов связи может толковаться в разных организациях по-разному. Поэтому невозможно дать четкое определение границ узлов, которое можно было бы использовать в каждом конкретном случае.

В этой статье везде, где используются термины «компьютер» и «сервер», речь идет о системе Windows 2000. Серверы NT 4.0 не поддерживают узлы Active Directory и никогда не будут их поддерживать. При этом на компьютерах с Windows 9x можно реализовать поддержку узлов AD при помощи клиента Directory Services (DS), входящего в комплект поставки Windows 2000.

Думаю, нужно пояснить, в чем состоит отличие узлов от доменов. Оно заключается в том, что узлы определяются физической структурой сети, в то время как домены – логической (территориальной или организационной) структурой предприятия. Узел может включать в себя несколько доменов, образуя структуру, достаточно сложную для управления. В свою очередь домен может располагаться на нескольких узлах.

Узлы выполняют три основные функции. Во-первых, в них более четко, нежели в доменах, осуществляется процесс репликации данных Active Directory. Во-вторых, узлы играют важную роль в процессе выбора контроллера домена, используемого для регистрации в сети тех клиентов, которые поддерживают Active Directory. И, наконец, узлы позволяют локализовать доступ к ресурсам для клиент-серверных приложений, поддерживающих AD (например, Windows 2000 Dfs).

Правильное проектирование узлов AD позволяет более тонко управлять процессом репликации данных, чем при использовании одних лишь доменов. Репликация данных без сжатия между контроллерами доменов внутри одного узла (а, значит, и всей сети, если не было создано ни одного узла, кроме исходного) происходит каждые пять минут. При этом администраторы не имеют возможности изменить график репликаций между контроллерами домена внутри узла. Служба Active Directory исходит из того, что в пределах одного узла между контроллерами доменов имеются достаточно надежные каналы связи. Поэтому она дает обеспечению малого времени ожидания более высокий приоритет по сравнению с загрузкой сети.

Когда создано несколько узлов AD, появляется возможность управления и настройки репликации данных несколькими способами. Можно определить, как часто и в какое время следует производить репликацию между узлами (минимальный интервал равен 15 мин). Служба Active Directory не производит сжатия данных при их репликации внутри одного узла, однако при репликации информации между узлами сжатие данных происходит автоматически. В результате сетевой трафик составляет от 10 до 40% от первоначального значения. Кроме того, можно установить линии связи между узлами, направляя репликации по заданным виртуальным маршрутам. Также можно назначить приоритеты при выборе каналов для передачи репликаций, установив «стоимость» каждого из маршрутов.

Создание узлов AD. Чтобы создать узел Active Directory, необходимо: сформировать объект «узел» (Site), добавить в него подсеть (Subnet) и переместить существующие серверы, а затем настроить репликацию между узлами, используя линии связи (Site Link) для соединения данного узла с другими узлами AD. Рисунок 1 иллюстрирует процесс создания узлов AD. В данном примере компания, расположенная в штате Texas, имеет офисы в городах Dallas, Forth Worth и Austin. Dallas является «концентратором» каналов WAN в два других офиса; места расположения офисов и компьютеры в них представляют собой узлы AD. Каждый из узлов включает в себя несколько подсетей IP, построенных по топологии Ethernet LAN (т. е. узлы состоят из высокопроизводительных подсетей IP). В компании используется только один домен; при этом в каждом узле имеется несколько контроллеров домена.

Для создания объекта «узел» следует в консоли управления Microsoft Management Console (MMC) запустить модуль Active Directory Sites and Services (его можно найти в меню Start и далее Administrative Tools). Затем нужно щелкнуть правой кнопкой мыши на контейнере Sites и выбрать New Site. В открывшемся диалоговом окне New Object – Site, показанном на Экране 1, указывается имя узла (в имени нельзя использовать пробелы). Рекомендуется придерживаться соглашений об именах, принятых для DNS, так как имена узлов размещаются в DNS в записях типа SRV. Далее следует выбрать объект «линия связи», которую будет использовать данный узел (другими словами, это путь, соединяющий данный узел с другими), и нажать OK. Появится сообщение о том, что для завершения процедуры формирования узла необходимо:

Прежде чем добавлять подсети в узел, необходимо добавить их в базу службы Active Directory, в контейнер Subnets. Для этого в Active Directory Sites and Services следует щелкнуть правой кнопкой мыши на контейнере Subnets и выбрать New Subnet. Для каждой из определяемых подсетей указывается адрес подсети и маска, задающая ее размер (см. Экран 2). Установив эти параметры для узла, нажимаем OK.

Теперь следует перенести серверы в соответствующие узлы AD. Правой кнопкой мыши нужно щелкнуть на имени сервера и затем выбрать move. В открывшемся диалоговом окне Move Server указывается узел назначения, как показано на Экране 3. Перезагружать серверы после их перемещения не требуется. Если в дальнейшем при установке новых серверов их IP-адреса будут соответствовать подсетям узла, то эти серверы автоматически зарегистрируются в соответствующем узле в момент включения в домен. Если же IP-адреса новых серверов не будут соответствовать ни одной из подсетей данного узла, то эти серверы попадут в создаваемый по умолчанию первым узел AD с именем Default-First-Site-Name.

Формирование отдельных узлов AD вместо размещения всех компьютеров в одном узле Default-First-Site-Name является первым этапом процесса управления репликациями. Во-первых, это обеспечивает возможность взаимодействия клиентских станций, поддерживающих Active Directory, с контроллером домена в том же офисе (если, конечно, данный контроллер находится в режиме готовности). Благодаря этому, весь трафик, связанный с регистрацией в сети, сосредотачивается внутри каждого из узлов. Кроме того, репликации данных между разными офисами происходят с увеличенным интервалом (вместо пяти минут по умолчанию – три часа), при этом осуществляется сжатие реплицируемой информации.

Предположим, что рассматриваемая в примере компания столкнулась с проблемами, связанными с пропускной способностью сети. Их решение потребует более детальной настройки конфигурации узлов. Допустим, сетевой трафик, вызываемый репликациями данных Active Directory между городами Dallas и Fort Worth, всегда высок. Следовательно, потребуется минимизировать его влияние на ограниченную пропускную способность канала WAN между этими двумя узлами. Кроме того, сетевой трафик Dallas – Austin, вызываемый репликациями данных AD, остается высоким в течение дня, но снижается ночью, так как в семь часов вечера офис закрывается. Для минимизации связанного с репликациями трафика в Windows 2000 можно использовать различные особенности узлов AD. Однако для того, чтобы научиться это делать, следует сначала разобраться с понятием «линии связи между узлами» (site link).

Настройка линий связи. Линии связи представляют собой виртуальные каналы (virtual circuit, VC), используемые в Windows 2000 для репликации данных между узлами. Как правило, линии связи управляют репликацией между двумя узлами AD. При создании этих линий в качестве транспорта можно использовать протоколы SMTP и RPC поверх TCP/IP (такой протокол отображается как IP). Протокол IP используют 95% связей узлов AD. Протокол SMTP обычно применяется в качестве транспорта в тех случаях, когда передача информации осуществляется по очень ненадежным каналам связи либо через брандмауэр, не пропускающий трафик RPC по портам 137 и 139. В отличие от реальных телекоммуникационных каналов, линии связи между узлами AD могут соединять более двух узлов. Поэтому их удобно применять, когда требуется, чтобы все узлы, использующие одну и ту же линию связи, имели одинаковые настройки параметров репликации данных. На Экране 1 показан пример линии связи DEFAULTIPSITELINK, используемой по умолчанию для IP-соединений и применяемой как общая связь между узлами. Все узлы AD будут передавать данные по этой связи, так как никаких других создано не было.

Чтобы сконфигурировать связи, нужно в приложении AD Sites and Services щелкнуть мышью на знаке «плюс», который относится к контейнеру Inter-Site Transports (либо дважды кликнуть на этом контейнере), после чего открываются контейнеры IP и SNMP. Затем следует щелкнуть правой кнопкой мыши на контейнере IP и выбрать New Site Link. Появится диалоговое окно New Object-Site Link, показанное на Экране 4. Затем нужно создать линию связи типа «точка-точка» между узлами Dallas – Fort Worth. В список узлов, использующих эту связь, можно также добавить Austin и Default-First-Site-Name. Хотя добавлять узел Default-First-Site-Name не обязательно, так как каждый новый узел по умолчанию уже применяет связь DEFAULTIPSITELINK. Если подключить все узлы AD к созданной связи, не меняя при этом приоритеты связей и график использования, то новая связь будет работать как DEFAULTIPSITELINK. В конце следует задать имя линии связи между узлами. Оно должно явно идентифицировать узлы, применяющие данную связь, так, чтобы работоспособность связей можно было легко отслеживать в процессе администрирования.

Настройка репликаций. После создания линии связи между узлами можно проводить настройку репликаций данных, обеспечивая их соответствие местным условиям работы. Чтобы выполнить настройку репликаций для рассматриваемой компании, нужно щелкнуть правой кнопкой мыши на объекте Site Link между узлами Dallas–Fort Worth, который находится в контейнере IP контейнера Inter-Site Transports. Далее следует отредактировать свойства этого объекта в диалоговом окне Properties. Данное диалоговое окно выглядит так же, как окно, используемое при создании линии связи, но позволяет дополнительно устанавливать приоритет связи (параметр cost), интервалы между репликациями и график репликаций.

На Экране 5 показано диалоговое окно Properties для связи Dallas–Fort Worth. Интервал репликаций между узлами Dallas и Fort Worth здесь уменьшен с трех часов (по умолчанию) до одного часа. В результате репликации происходят чаще, но занимают более короткое время для передачи необходимой информации по сети предприятия. Чтобы ограничить сетевой трафик Dallas–Austin в дневные часы, связь Dallas–Austin сконфигурирована таким образом, что проведение репликаций с семи часов утра до семи часов вечера запрещено. Это показано на Экране 6. Кроме того, интервал репликаций уменьшен со 180 до 30 мин так, чтобы все изменения, происшедшие на других узлах до семи часов утра, были незамедлительно реплицированы на узел Austin. На Рисунке 2 показан окончательный вариант конфигурации узлов и линий связи для компании в штате Texas.

Взаимодействие клиент – контроллер домена. Использование узлов AD оказывает влияние на процедуру выбора клиентскими станциями, поддерживающими Active Directory, контроллеров домена для регистрации в сети. Механизм узлов AD поддерживается операционными системами Windows 2000 Professional и Windows 9x с установленным клиентом DS. В Windows NT 4.0 контроллер выбирается из того домена, в который входит клиентская станция. При этом сервер WINS выдает список контроллеров домена, которые можно использовать для регистрации, однако нет никакой гарантии, что клиентом будет выбран ближайший по расположению в сети контроллер. Например, если один и тот же домен располагается на восточном побережье США и в Европе, то сервер во Франкфурте (Германия) может быть выбран для регистрации пользователей из Нью-Йорка. В результате пока установленный безопасный канал системы (secure channel) на сервере в Нью-Йорке не будет сброшен, всем запросам клиентов придется дважды пересекать океан, чтобы получить доступ к нью-йоркскому ресурсу. Некоторые утилиты (например, Setprfdc) позволяют вручную выбирать контроллер домена. Но при правильном проектировании узлов в Windows 2000 необходимость в использовании подобных утилит (для постоянного мониторинга с целью устранения возникающих проблем) отпадает.

При работе с Windows 2000 клиенты, использующие сервер DNS, который поддерживает записи SRV (RFC 2052) и динамическое обновление информации (RFC 2136), будут пытаться в первую очередь установить соединение с контроллером домена, расположенным в том же узле, что и клиент. Только в том случае, если в своем узле найти контроллер не удается и для этого узла не определены резервные контроллеры из других узлов, то клиент начинает поиск по всему домену, как это делается в NT 4.0.

В нашем примере регистрация пользователей будет происходить в пределах их локальных сетей, независимо от сетевого трафика и производительности контроллеров домена. Клиенты из города Dallas всегда будут регистрироваться на контроллере домена, расположенном в узле Dallas. Пользователи из города Austin никогда не смогут случайно задействовать сильно загруженный канал Dallas–Austin. Процесс выбора контроллера домена клиентом Windows 2000 достаточно сложен, поэтому я отложу рассмотрение всех его деталей до следующей статьи. Более подробно процесс выбора контроллера домена описан в материалах Microsoft Windows 2000 Advanced Server Help Files по адресу: http://www.microsoft.com/windows2000/downloads/ otherdownloads/helpfiles/adserver.asp?lang=en.

Механизм узлов AD также используется поддерживающими AD приложениями, при осуществлении доступа к ресурсам. Это можно продемонстрировать на примере службы Dfs, которая поддерживает узлы AD. Используя Dfs, администраторы могут создавать логические структуры каталогов с простыми для запоминания именами. Эти имена отображаются на реальные UNC-имена (т. е. имена типа: \серверкаталог), соответствующие каталогам на серверах в сети. Функция службы Dfs, называемая replica sets, позволяет отобразить один логический каталог на несколько физически различных UNC-адресов, содержащих идентичные данные. Если среди серверов, на которые указывают эти UNC-имена, имеются серверы Windows 2000, зарегистрированные в том же самом узле, что и запрашивающий доступ к ресурсу клиент, то клиент скорее всего выберет для доступа к данным сервер, расположенный в том же узле.

Предположим, что пользователь из узла Austin хочет скопировать некое программное обеспечение с сетевого каталога с именем \bigtexsoftware. Это имя представляет собой логическое имя системы Dfs, отображаемое на серверы в узлах Fort Worth, Dallas и Austin. Пользователь из города Austin, обращаясь к \bigtexsoftware, установит сеанс связи с сервером aus01, указав реальное UNC-имя \aus01software. Это показано на Рисунке 3. Данный пример демонстрирует, как поддерживающий AD клиент может, используя механизм узлов AD и приложение типа клиент-сервер, осуществлять доступ к ресурсу по вычисляемому специальным образом UNC-имени. Операционная система Windows 2000 направляет клиента к серверу приложений, расположенному в том же узле, где находится этот клиент.

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