В процессе подготовки к развертыванию службы AD в масштабах компании уже на первых этапах становится ясно, что проектирование крупных, оснащенных надежными каналами связи офисов, где сосредоточена основная масса служащих, — это еще не главная трудность. Куда сложнее проектировать инфраструктуру для периферийных, вспомогательных офисов, где, как правило, размещается от 10 до 100 служащих, в распоряжении которых — «тихоходный» канал связи региональной сети. А ведь часто бывает, что самый короткий путь от компании до ее клиентов пролегает именно через эти филиалы. Так как же реализовать в подобных офисах службы Windows Server наиболее экономичным способом? Возможно, читателям, размышляющим о том, в каких удаленных офисах филиалов компании лучше всего разместить сайты, а также контроллеры доменов (Domain Controller, DC) и серверы глобальных каталогов (Global Catalog, GC), приведенные ниже рекомендации пригодятся.

Существует только одно средство для сохранения душевного равновесия в процессе проектирования AD в удаленном офисе: нужно строго следовать принципам проектирования. Вооружившись тщательно продуманным набором принципов, вы привнесете в процесс проектирования необходимую логику и сделаете его воспроизводимым. Кроме того, вы будете располагать убедительными аргументами при выяснении отношений с менеджером локального офиса, который потребует объяснений, почему вы решили устанавливать контроллер домена не в его офисе, а где-то в другом месте. Удаленным офисом филиала компании или малым офисом мы далее будем называть офис, соединенный с другими подразделениями организации каналом глобальной сети с пропускной способностью менее 11 Мбит/с, обеспечивающей работу не более 400 пользователей и разделенной на небольшое число подсетей.

Изучите характеристики сети

Перед тем как приступить к вычерчиванию кружков на схеме с офисами компании, необходимо провести некоторую подготовительную работу. Microsoft определяет сайт, или сайт AD, как набор объединенных скоростными каналами связи подсетей TCP/IP. Обычно проектирование сайтов начинается после выбора структуры лесов и доменов. Но первый принцип проектирования для удаленных офисов гласит: топология сайта определяется не столько доменами, которые будут доступны в данном офисе, сколько инфраструктурой физической сети. Поэтому требуется ознакомиться с топологией локальной и глобальной сетей компании и как следует в ней разобраться. Следует выяснить, какова пропускная способность каналов распределенной сети, насколько эта сеть надежна, каковы уровни запаздывания и загрузки. Узнайте, предусмотрен ли в структуре глобальной сети механизм аварийных переключений, и если да, то как он функционирует. Возможно, такой подход кому-то напоминает подготовку к установке службы DNS в системе Windows 2000 Server. И это действительно так. И при подготовке к установке DNS в среде Windows 2000 Server, и в процессе сбора информации о глобальной сети нужно обязательно проконсультироваться с инженерами, обслуживающими сеть.

Кроме того, потребуется список всех IP-подсетей компании. Введение этих подсетей в оснастку Active Directory Sites and Services консоли MMC — занятие довольно утомительное, но после того как будут спроектированы и созданы сайты, кому-то придется выполнять эту работу. Кроме того, кто-то должен будет включиться в процесс изменения работающей подсети, чтобы иметь возможность обновлять подсети с помощью данной оснастки, если будут вноситься изменения в конфигурацию IP-подсетей главной сети. Ибо в противном случае целые группы компьютеров могут «выпасть» из топологии сайта, и тогда для десятков или даже для сотен пользователей время регистрации и время отклика существенно возрастет.

Где уместно и где не следует создавать сайты и устанавливать контроллеры доменов?

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

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

Определив, в каких удаленных офисах можно обеспечить возможность ограничения физического доступа к контроллеру домена посторонних лиц, можно перейти к следующему этапу — анализу трафика. Изучив сетевой трафик, генерируемый при различных вариантах взаимодействия между серверами и клиентами, вы выясните, какие доменные службы требуются соответствующим офисам. Контроллеры доменов идентифицируют клиентские компьютеры, учетные записи пользователей и автономных серверов, чем обеспечивается возможность их регистрации в соответствующем домене. Кроме того, на контроллерах доменов могут размещаться глобальные каталоги, к которым направляют свои запросы как клиенты, так и серверы, и общедоступные ресурсы Netlogon для размещения сценариев регистрации пользователей. Наконец, они могут выполнять функции серверов баз данных для приложений, использующих данные из AD. Объем этих услуг является важным фактором для принятия решения о том, следует ли организовывать в удаленном офисе отдельный сайт и устанавливать там контроллер домена либо глобальный каталог.

При проектировании сети удаленного офиса важно уделять внимание минимизации трафика в региональной сети. Если пользователи, проходя аутентификацию в других офисах, генерируют больше трафика, чем его было бы в случае, когда расположенный в данном офисе контроллер домена участвовал бы в тиражировании данных на другие контроллеры, следует поставить галочку в колонке «Установить контроллер домена». По данным, приведенным во второй главе «Structural Planning for Branch Office Environments» руководства Active Directory Branch Office Deployment Guide (http://www.microsoft.com/windows2000/techinfo/ planning/activedirectory/branchoffice/default.asp), при выполнении процедуры аутентификации во время регистрации достаточно наличия десяти пользователей для того, чтобы полученный трафик превзошел по интенсивности трафик тиражирования.

Рассмотрим на примере вопрос, какие требования предъявляются к малому или среднему удаленному офису в отношении выполнения процедур аутентификации и обработки запросов и как они влияют на проектирование удаленных офисов. Пусть фирма Bigtex.net имеет филиал в г. Дриппинг-Спрингс (графство Тексас-Хилл). Офис связан со штаб-квартирой корпорации, расположенной в Форт-Уорт, каналом глобальной сети с пропускной способностью 512 Кбит/с. Компания имеет один домен и 200 служащих, 150 из которых работают в Форт-Уорт. В удаленном офисе филиала компании имеются файловый и принт-серверы. Они обслуживают 50 сотрудников, предлагающих товары потенциальным клиентам с выездом на место.

Если в офисе, расположенном в Дриппинг-Спрингс, не установить контроллер домена и данный филиал будет входить в состав другого сайта, все процедуры аутентификации должны будут выполняться по каналам связи региональной сети. А что если установить контроллер, который будет осуществлять тиражирование данных? Как это отразится на объеме трафика? Всего в компании 200 служащих, так что объем AD-трафика, проходящего по каналам региональной сети в рамках процедуры тиражирования, невелик. Результаты анализа трафика говорят в пользу установки контроллера домена в офисе в Дриппинг-Спрингс.

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

И в самом деле, размещение контроллера домена в удаленном офисе имеет массу преимуществ. Трафик тиражирования — явление более статичное и более предсказуемое, нежели трафик аутентификации: последний изменяется в зависимости от времени суток и числа пользователей в удаленном офисе. Между тем некоторым сетевым приложениям, выполняемым внутри сайта или за его пределами, необходим быстрый доступ к глобальному каталогу. Например, системе Exchange 2000 Server нужен быстрый доступ к глобальному каталогу для просмотра почтовых адресов. Без наличия в офисе контроллера домена клиенты не смогут регистрироваться в сети и обращаться к ресурсам — даже к локальным — в тех случаях, когда каналы связи с региональной сетью выходят из строя (такую возможность нужно обязательно учитывать, если эти каналы ненадежны). Ну а если установка контроллеров доменов в удаленных офисах дает так много преимуществ, зачем вообще от нее отказываться?

Одну причину я уже упомянул, это физическая защищенность оборудования. Другая важная причина — высокие затраты. Как правило, малых офисов в компаниях намного больше, чем крупных. Если некая компания имеет три основных офиса с двумя контроллерами доменов в каждом и 30 разбросанных по всей стране «полевых» офисов для сотрудников отдела сбыта, после установки контроллеров доменов в каждом «полевом» офисе общее количество контроллеров возрастет с 6 до 36, а значит, стоимость аппаратных компонентов AD-инфраструктуры увеличится на 600%. А ведь рост затрат на оборудование влечет за собой соответствующее увеличение расходов на поддержку и контракты.

Еще одна причина — трудности управления. Если увеличить число сайтов, то число линий связи между сайтами и прежде всего — подсетей, которые придется обслуживать, возрастет с 3 до 33, а это, знаете ли, рост на целых 1100%. Количество одних только контроллеров доменов, физическую защиту которых предстоит обеспечивать, возрастает в шесть раз. И как вы будете управляться со всеми этими контроллерами? Как известно, для того чтобы иметь административный доступ к контроллеру домена, сотрудник должен иметь права администратора во всем домене. Готовы ли вы предоставить одному или двум сотрудникам каждого регионального офиса права управления всем доменом? Будем надеяться, что нет. Тогда, может быть, вы собираетесь управлять контроллерами доменов дистанционно? А что вы будете делать, если что-то случится с сетевой платой одного из контроллеров?

Приведенные аргументы явно свидетельствуют о предпочтительности подхода, предусматривающего отказ от сложных решений (я называю его KISS — Keep It Simple, Stupid) и подтверждают правильность «максимы минимума», которая гласит: если ты можешь что-то сделать, это еще не значит, что должен. AD — это мощная служба, функционирование которой определяется тысячами индивидуальных настроек. Если нет веской причины для усложнения топологии сайта и нет желания отслеживать последствия внесения таких изменений, лучше оставить все как есть.

Рисунок 1. Решение о необходимости наличия DC в филиале

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

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

Когда устанавливать глобальный каталог

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

Первая функция — хранение универсальных групп — затрагивает интересы всех пользователей, регистрирующихся в данном домене. Когда пользователь регистрируется в системе, служба Netlogon создает маркер доступа, который, помимо прочего, содержит данные о членстве пользователя в различных группах. Поскольку информация об универсальных группах имеется лишь в глобальном каталоге, Netlogon обращается к этому каталогу; такое обращение представляет собой часть процесса регистрации, обеспечивающей получение данных о членстве пользователя в универсальных группах. По умолчанию, если пользователь не имеет доступа к серверу глобального каталога, он не сможет зарегистрироваться в системе. Это ограничение можно обойти, внеся изменения в реестр Windows 2000 (что является нарушением требований безопасности) или воспользовавшись реализованной в системе Windows 2003 функцией кэширования информации об универсальных группах. При первой регистрации пользователя на сайте с активизированной функцией кэширования установленные на данном узле контроллеры доменов Windows 2003 будут кэшировать его данные о членстве в универсальных группах и затем периодически обновлять эти данные с помощью глобальных каталогов на другом узле.

Вторая функция — предоставление эталонных данных AD в масштабах всего леса — при определении места размещения сервера глобального каталога имеет несопоставимо большее значение. Самыми активными пользователями глобального каталога являются приложения для передачи сообщений (Exchange 2000 и более поздние версии на сервере, Microsoft Outlook — на клиенте). В системах Windows 2003 и Windows 2000 адреса электронной почты хранятся как атрибуты объектов пользователей в AD, а серверы Exchange 2000 и более поздних версий, а также клиенты Outlook обращаются к глобальному каталогу для трансляции имен в почтовые адреса; ответ на вопрос, какая платформа чаще выполняет процедуры просмотра, зависит от версии клиента Outlook. Когда дело доходит до обмена сообщениями, кэширование данных об универсальных группах не помогает: пользователи электронной почты не просматривают данные об универсальных группах; им требуются атрибуты «почтовый адрес», хранящиеся в глобальном каталоге. Если в удаленном офисе с установленным контроллером домена имеются пользователи Exchange 2000 или более поздних версий, я настоятельно рекомендую продумать вопрос о превращении этого контроллера в сервер глобального каталога. В противном случае пользователям придется вести поиск адресов электронной почты по каналам региональной сети. Если в офисе имеется сервер Exchange 2000 или более поздней версии, в соответствующем сайте нужно устанавливать по меньшей мере один сервер глобального каталога. Я бы даже поставил вопрос более радикально: если во всех сайтах предприятия размещены серверы Exchange 2000 или более поздней версии, следует возложить функции серверов глобального каталога на все контроллеры домена.

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

Еще один фактор, влияющий на решение администраторов по размещению глобальных каталогов, — это число и размеры универсальных групп. Универсальные группы «приписаны» к глобальным каталогам, поэтому Windows тиражирует все изменения на серверах глобальных каталогов по всему лесу. В системе Windows 2000 сведения об универсальных группах хранятся в виде единых атрибутов со множеством значений, так что при внесении каких-либо изменений в состав универсальной группы Windows 2000 тиражирует все касающиеся этой группы данные. И значит, если в сети имеются большие или активные универсальные группы (скажем, группы, выступающие в роли списков рассылки Exchange 2000), именно глобальный каталог будет самым крупным компонентом, тиражируемым в процессе репликации AD. В системе Windows 2003 реализовано другое решение: тиражируются только сведения об изменении состава группы, а не все данные о группе.

Дополнительные соображения

Как было сказано выше, если в филиале нет контроллера домена, вероятно, там не следует организовывать сайт. Я употребил слово «вероятно», поскольку здесь есть одно исключение. Если было развернуто приложение, функционирование которого предполагает взаимодействие с сайтом (например, DFS), то, возможно, понадобится создать сайты в филиалах, не имеющих контроллеров доменов. Дело в том, что использующие такие приложения клиенты первым делом обращаются к хост-серверу в своем сайте. Допустим, в нескольких филиалах, входящих в состав более крупного сайта AD, вы развернули DFS (скажем, для установки программных средств). Клиенты Windows приступят к поиску сервера DFS, и дело, возможно, закончится тем, что они попытаются подключиться к серверу, расположенному на другом конце канала распределенной сети с пропускной способностью 256 Кбит/с, тогда как в том же удаленном офисе существует свой сервер DFS. Для решения проблемы достаточно создать сайт в каждом филиале. Все локальные серверы DFS станут в таком случае частями нового сайта соответствующего офиса, локальные пользователи, желающие получить доступ к DFS, будут прежде всего выбирать «свой» сервер, а благодаря функции поиска сайтов в AD аутентификацию пользователей соответствующего филиала будут выполнять близлежащие контроллеры доменов, не принадлежащие данному узлу. Но не следует забывать о том, что для использования этой функции необходимо зарегистрировать IP-подсети на одном из сайтов. Клиенты незарегистрированных подсетей в конечном итоге оказываются в сайте, имя которого Default-First-Site-Name и который, вполне возможно, не имеет собственного контроллера домена. Тогда клиентам придется искать контроллер по всему домену, и не исключено, что они обратятся не к тому контроллеру домена, который находится ближе.

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

Изменения в системе Windows 2003

Благодаря нескольким новым функциям, реализованным в Windows 2003, развертывание и управление удаленными офисами филиалов существенно упрощается. Средство Dcpromo позволяет администратору повышать статус сервера promote с помощью носителей, так что теперь процесс создания нового контроллера домена не предполагает обязательной передачи объемной базы данных AD и глобального каталога по не обладающим высокой пропускной способностью каналам глобальной сети. Необходимо скопировать сильно сжатую резервную копию данных о состоянии системы другого контроллера домена Windows 2003, распаковать ее во временном каталоге, в окне командной строки ввести

dcpromo /adv

и восстановить состояние системы из временного каталога. Более подробная информация о повышении статуса сервера с помощью носителей содержится в статье «Dcpromo в Windows 2003», опубликованной в Windows & .NET Magazine/RE, № 7 за 2003 год.

Функция Remote Desktop, обеспечивающая работу службы терминалов в системе Windows 2003, позволяет подключаться к консоли системы (session 0) с ключом /c, после чего администратор получает возможность увидеть все то, что он увидел бы, находясь непосредственно перед сервером. Ну, а если в сети имеется множество сайтов, вам будет интересно узнать, что в системе Windows 2003 проблема обслуживания большого числа сайтов решена более изящно, нежели в Windows 2000. Такие средства Windows 2003, как Intersite Topology Generator (ISTG) и Knowledge Consistency Checker (KCC), позволяют развертывать самые крупные удаленные офисы без каких-либо ограничений со стороны службы AD.

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

Статью о развертывании удаленных офисов нельзя считать завершенной, если в ней не упоминаются руководства по этой теме для сетей на базе Windows 2000 и Windows 2003. Уже упоминавшееся руководство «Active Directory Branch Office Deployment Guide» представляет собой оригинальное и подробное пособие по развертыванию удаленных офисов в среде Windows 2000. Так же называется и черновая версия пособия для Windows 2003, копия которой у меня имеется. Кроме того, я настоятельно рекомендую читателям ознакомиться с комплектом Microsoft Windows Server 2003 Deployment Kit (http://www.microsoft.com/windowsserver2003/ techinfo/reskit/deploykit.mspx). Сделайте это, даже если вы не планируете в ближайшем будущем устанавливать систему Windows 2003. Этот трактат (объемом в 4000 страниц) базируется на опыте, полученном специалистами Microsoft за три года работы с Windows 2000. Особое внимание советую уделить такому компоненту комплекта по развертыванию, как книга «Designing and Deploying Directory and Security Services». Конечно, развертывание удаленных офисов может оказаться гораздо более сложным делом, чем развертывание крупных офисов, но, руководствуясь изложенными в этой статье рекомендациями, а также двумя упомянутыми ресурсами Microsoft, можно стать настоящим экспертом.

Шон Дьюби — редактор журнала Windows & .NET Magazine, старший системный инженер компании Intel, специализирующийся на проектировании корпоративных сетей на базе Windows 2000. С ним можно связаться по электронной почте по адресу: spdeuby@winnetmag.com