Хотя обычно бывает, что чем проще, тем лучше, иногда может потребоваться более тонкое планирование инфраструктуры Active Directory.
Брайен М. Пози
При изучении используемых на практике конфигураций Active Directory меня всегда удивляла одна вещь: хотя, конечно, встречались исключения, в большинстве случаев организации придерживались самых простых подходов, какие только могли себе позволить.
Это, в какой-то степени, не удивительно и напоминает мне об университетском профессоре, который часто повторял, что нам следует жить по принципу KISS - "Keep It Simple, Stupid" ("не усложняй, дурачок!"). Пожалуй, нигде более точно не следуют этому принципу, чем в мире ИТ.
Любой опытный ИТ-профессионал знает, что делая все проще, он уменьшает риск возникновения проблем. Кроме того, это значительно упрощает устранение неполадок, если что-то пойдет не так. Я буду первым, кто согласится, что простота обеспечивает кое-какие преимущества, но когда речь идет об инфраструктуре Active Directory, может оказаться, что лучше воспользоваться более тонкой структурой.
В применении стандартной топологии Active Directory нет абсолютно ничего плохого. Поэтому Microsoft и сделала стандартную топологию используемой по умолчанию. Однако немного более сложные архитектуры, возможно, лучше подойдут крупным организациям, нуждающимся в разделении управленческих функций.
Пользовательские домены
В большинстве используемых на практике конфигураций Active Directory структура доменов воспроизводит географическую структуру организации. Например, если у организации три офиса, у нее, скорее всего, будет три домена. Конечно, это не значит, что все организации используют такую архитектуру, но это наиболее распространенный тип структуры Active Directory. Хотя географические топологии Active Directory популярны и действительно эффективны, возможно, имеет смысл рассмотреть кое-какие альтернативные структуры доменов.
Как вы, несомненно, знаете, Active Directory - на самом деле, не более чем тщательно продуманная база данных. База данных Active Directory заполнена объектами различными типов. Каждому объекту соответствуют один или более атрибутов. В некоторых организациях структура доменов основана на определенных типах объектов Active Directory. Один из ярких примеров такого рода классификации - пользовательские домены.
Пользовательский домен - это домен Active Directory, предназначенный исключительно для управления учетными записями пользователей. Чтобы вы получили представление, чем это может быть полезно, рассмотрим одну компанию, в которой я работал. В ней имелось несколько тысяч пользователей, и всегда была высокая текучесть кадров. Поэтому в организации работало два человека, чьими обязанностями были создание и удаление учетных записей пользователей, а также предоставление им доступа к ресурсам.
Пользовательские домены доказали свою полезность в такого рода ситуациях. Такой тип структуры домена дает пользователям, осуществляющим управление учетными записями, полный административный контроль над учетными записями пользователей. Однако он не предоставляет доступ к любым другим объектам или функциям Active Directory.
Имеются и другие способы обеспечить такой тип изоляции в соответствии с административными обязанностями. Тем не менее, структура с пользовательским доменом способна помочь организации стать более организованной. По крайней мере, она позволит сделать отдельные домены менее громоздкими. Кроме того, она дает ощущение физической изоляции при администрировании. Некоторым организациям это подходит лучше, чем логическая изоляция при администрировании, когда объекты различных типов располагаются в общем домене.
Ресурсные домены
Ресурсные домены аналогичны пользовательским доменам. Они одноцелевые по своей природе и служат для обеспечения большей безопасности и для того, чтобы сделать структуру Active Directory более логичной или более управляемой. Имеются применяемые на практике конфигурации Active Directory, в которых все настольные компьютеры сгруппированы в выделенный ресурсный домен. Встречаются и другие ресурсные домены, содержащие другие типы ресурсов. Например, одна организация поместила все серверы, на которых выполнялось ее основное бизнес-приложение, в выделенный ресурсный домен.
Пожалуй, ресурсные домены наиболее полезны, когда они рассматриваются как домены для управления. Например, я создал выделенный лес Active Directory, предназначенный для использования исключительно в качестве домена управления моими Hyper-V-серверами. Я выбрал такой вариант по двум причинам.
Первая причина - управление. System Center Operations Manager 2012 (и несколько других продуктов, предназначенных для управления) способны управлять только серверами, которые входят в домены Active Directory. Я не хотел присоединять свои Hyper-V-серверы к основному домену, поскольку все контроллеры домена (domain controllers, DC) для основного домена были виртуализованы. Я не хотел рисковать тем, что мой Hyper-V-сервер будет невозможно зайти лишь из-за того, что виртуальный DC стал недоступен. Добавление Hyper-V-серверов в выделенный лес Active Directory, предназначенный для управления, решило эту проблему.
Второй причиной, по которой я решил создать для своих Hyper-V-серверов выделенный ресурсный домен, стало желание воспользоваться кое-какими новыми функциями, появившимися в Hyper-V версии 3.0. Одна из наиболее увлекательных для меня функций Hyper-V 3.0 - возможность реплицировать виртуальную машину (virtual machine, VM) с одного хост-сервера на другой.
Такой тип репликации не обязательно должен использоваться в кластерном решении для восстановления после сбоя, скорее он подойдет для решения по аварийному восстановлению, которое будет переносить актуальную копию VM на другой хост-сервер. Если что-то случится с дисковым массивом или основным Hyper-V-хостом, у вас будет еще одна копия VM, на которую можно будет перейти. Однако чтобы эта функция работала, и хост-сервер, и реплика должны пройти аутентификацию.
Самый простой способ обеспечить такую аутентификацию - добавить оба сервера в общий домен и использовать Kerberos. Поэтому создание выделенного ресурсного домена для Hyper-V-серверов совершенно оправданно. Это особенно верно, если принять во внимание другие функции Hyper-V, также требующие членства в домене.
Кстати, ресурсные и пользовательские домены не являются взаимоисключающими. В некоторых организациях сочетают пользовательские домены и ресурсные домены в общем лесу Active Directory. Оба типа доменов имеют свои сильные стороны, и при необходимости ими обоими можно воспользоваться.
Географическая топология
Подавляющее большинство конфигураций Active Directory, применяемых на практике, основаны на географической структуре. Например, организация с пятью филиалами может использовать пять отдельных доменов: для каждого филиала поддерживается свой домен, содержащий все его физические компьютеры. С технической точки зрения в таком типе топологии Active Directory нет ничего плохого, но следует продумать некоторые моменты.
Во-первых, всегда важно не путать структуру доменов со структурой сайтов. Структура сайтов Active Directory всегда воспроизводит географическую топологию организации. Для каждого канала глобальной сети (wide area network, WAN), соединяющего филиалы, в Active Directory должна быть соответствующая связь между сайтами. Кроме того, компьютеры, расположенные в одном физическом офисе, должны находиться в одном общем сайте Active Directory. В идеале в каждом местоположении следует использовать выделенную подсеть, поскольку одна подсеть не может охватывать несколько сайтов Active Directory.
Причина, по которой структура сайтов Active Directory настолько важна, - то, что структура сайтов напрямую влияет на объем трафика репликации Active Directory, передаваемого по WAN-каналам. Например, представьте организацию с несколькими филиалами, у которой Active Directory настроена на использование одного домена. С технической точки зрения, в таком подходе нет ничего неправильного, но он может оказаться неэффективным.
В таких случаях обновления Active Directory потенциально могут произойти на любом DC, разрешающем запись, в любом месте организации. Когда происходит такое обновление, этот DC должен сделать изменения доступными другим DC.
Поскольку в организации не используется подходящая структура сайтов, невозможно передать по WAN-каналу общее обновление для нескольких DC. Например, если в филиале имеется пять DC, то обновление Active Directory потенциально может передаваться по WAN-каналу пять раз - по одному для каждого DC.
Один DC в каждом сайте Active Directory функционирует как сервер-плацдарм (bridgehead server). Задача сервера-плацдарма - принимать обновления Active Directory по WAN-каналу. Затем эти обновления распространяются на другие DC сайта. Значит, обновления Active Directory будут отправляться в каждый филиал по разу, независимо от того, сколько DC имеется в филиале.
Что будет, если организация использует отдельный домен для каждого филиала? Если у каждого филиала свой выделенный лес Active Directory, не нужно беспокоиться об определении сайтов Active Directory. С другой стороны, если каждый домен - член общего леса, несомненно, следует реализовать соответствующую структуру сайтов Active Directory, которая позволит держать под контролем трафик репликации Active Directory на уровне леса.
Имеется много разных способов определить топологию доменов Active Directory. В конечном счете, следует выбрать топологию, которая наиболее разумна с точки зрения физической топологии организации и ее сетевой инфраструктуры. Это может быть модель с единственным доменом или многодоменная модель, основанная на географическом расположении, пользователях или даже ресурсах.