Проектирование топологии сайта

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

Сайты и проектирование Active Directory

В Active Directory сайты представляют собой определенные организационные объекты и используются для управления сетевым трафиком. Это осуществляется тремя способами.

• Трафик репликации между сайтами сжат, поэтому репликация между сайтами использует полосу пропускания сети в меньшей степени, чем репликация в пределах сайта. Выполнение репликации происходит в соответствии с расписанием для гарантии того, что в это время сеть занята меньшим количеством других запросов.
• Трафик, связанный с входами клиентов в систему, останется в пределах сайта, если доступен локальный контроллер домена.
• Приложения, учитывающие наличие службы Active Directory, подобные распределенной файловой системе (DFS - Distributed File System), можно добавить к сети для ограничения трафика, связанного с доступом клиентов к местному сайту.

Инфраструктура организации сети и проектирование сайта

Поскольку проектирование сайта сильно зависит от организационной инфраструктуры сети, первый шаг в создании проекта состоит в документировании этой инфраструктуры. Документирование должно включать:

• схемы топологии глобальной (WAN) и локальной сети (LAN), детализирующие сеть корпорации, в которых содержится информация о полной пропускной способности и доступной пропускной способности между всеми офисами компании;
• список всех офисов компании, в которых компьютеры связаны через высокоскоростные сетевые соединения. Определение высокоскоростного подключения меняется в зависимости от таких факторов, как количество пользователей в офисах компании, общее количество объектов в домене и доменов в лесу. Кроме того, нужно определить, какая часть из полной полосы пропускания сети доступна для репликации. В большинстве случаев сетевые подключения в пределах сайта должны иметь скорость доступной полосы пропускания 512 Кб/с. В крупной компании в качестве минимальной скорости сетевого подключения в пределах сайта устанавливается скорость в 10 Мб/с;
• для каждого офиса компании уточните количество пользователей, компьютеров, серверов и локальных подсетей IP.

Создание модели сайта

Как только информация о сети компании собрана, можно приступать к проектированию сайта. Для начала исследуйте каждый офис компании, в котором компьютеры связаны через высокоскоростные сетевые подключения. Сколько пользователей находится в каждом месте? Достаточно их для того, чтобы там требовался контроллер домена? Каковы сетевые соединения от этого офиса до других офисов компании?

Каждый сайт должен иметь контроллер домена, а большинство из них и GC-сервер. Если вы решаете, создавать ли сайт для офиса компании с несколькими пользователями и медленным сетевым соединением, то на самом деле решается вопрос о том, нужен ли здесь контроллер домена. Для этого определите, какой вариант приведет к наименьшему количеству сетевого трафика. Что создаст большее количество трафика: входы клиентов на контроллер домена из других офисов компании или трафик репликации между контроллерами домена? Для тяжелого трафика нужно рассмотреть другие факторы. Если вы не поместите контроллер домена в данное место, то следует рассмотреть возможность прерывания работы пользователей в случае отказа сетевого подключения, потому что пользователи не смогут войти в домен. Если вы все равно развертываете Windows Server 2003 в данном месте, то не может ли он быть также и контроллером домена сайта?

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

После определения количества сайтов для Active Directory создается проект каждого сайта. Каждый сайт в Active Directory связан с одной или более подсетями IP, поэтому нужно определить, какие подсети будут включены в каждый сайт. Если вы решите не развертывать контроллер домена в каком-нибудь офисе компании, нужно определить, к какому сайту будет принадлежать этот офис, и добавить эту подсеть IP к соответствующему сайту. В этом случае клиенты, находящиеся в удаленном офисе, соединятся с ближайшими контроллерами домена.

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

Определение стоимости каждой из связей сайта усложнится, если имеется несколько возможных маршрутов между офисами компании. В этом случае нужно назначить затраты для связей сайта так, чтобы для репликации Active Directory использовался оптимальный маршрут. Один из способов определения стоимости каждой связи сайта состоит в создании таблицы, сопоставляющей сетевую пропускную способность связи со стоимостью связи. Пример показан в таблице 5-1.

Табл. 5-1. Сопоставление сетевой пропускной способности со стоимостью связи сайта

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

Управлять репликациями Active Directory можно также при помощи отключения мостов (site link bridging) между связями сайта. В большинстве случаев мосты связей сайта выключать не нужно, потому что при наличии мостов все связи сайта становятся транзитивными, т.е. если сайт A имеет связь с сайтом B, а сайт B имеет связь с сайтом C, то сайт A может реплицироваться напрямую с сайтом C. В большинстве случаев такое поведение желательно. Однако существуют исключения, когда необходимо отключить возможность наведения мостов между связями сайта. Например, компания имеет несколько центральных сайтов (hub sites) во всем мире и несколько небольших офисов, соединяющихся с центральными сайтами через медленные или средние сетевые подключения (см. рис. 5-12). Если центральные сайты связаны высокоскоростными соединениями, то автоматическое наведение мостов между связями сайта приемлемо. Однако, если сетевые подключения между центральными сайтами недостаточно быстры или большая часть полосы пропускания используется для других приложений, вы, возможно, не захотите иметь транзитивные подключения.

На рисунке 5-12 сетевое подключение между центральными сайтами-концентраторами A и B может иметь ограниченную доступную пропускную способность. Если заданная по умолчанию функция наведения мостов между связями сайта не изменена, то сервер-плацдарм центрального сайта A будет реплицироваться с сервером-плацдармом сайта B и с серверами-плацдармами других сайтов, связанных с центральным сайтом B. Это значит, что один и тот же трафик репликации может пересылаться по сетевым подключениям пять раз. Чтобы изменить это, нужно отключить возможность наведения мостов между связями сайта, а затем создать мосты связей сайта вручную. Чтобы отключить наведение мостов между связями сайта, откройте инструмент администрирования Active Directory Sites And Services (Сайты и службы Active Directory) и найдите IP-свойства объекта в контейнере Inter-Site Transports (Передача между сайтами). На вкладке General (Общее) окна IP-Properties (Свойства IP) очистите опцию Bridge All Site Links (Мосты между всеми связями сайта). Затем вы можете создать мосты связей сайта для всех связей, соединяющих центральные сайты с меньшими сайтами. Как только это будет выполнено, весь трафик репликации от сайта A направится к центральному сайту B, а затем будет распределен ко всем сайтам, связанным с сайтом B.

Рис. 5-12. Конфигурирование наведения мостов между связями сайта

Предостережение
Сбрасывая опцию Bridge All Site Links, вы выключаете транзитивность связей сайта, т.е. все связи сайтов в организации больше не являются транзитивными. Если после этого понадобятся мосты между связями сайта, их необходимо будет сконфигурировать вручную. Используйте эту опцию осторожно!

Проектирование размещения серверов

В проектирование сайта входит определение мест размещения серверов, на которых выполняется система Windows Server 2003, необходимых для обеспечения нужных служб каталога. В большинстве случаев, как только вы завершите проектирование сайта, разместить серверы несложно.

Размещение DNS-серверов

Как вы уже знаете, служба DNS - это критическая служба для Active Directory Windows Server 2003. Без DNS клиенты не смогут находить контроллеры домена Active Directory, а контроллеры домена не смогут находить друг друга для репликации. DNS должна быть развернута в каждом офисе вашей организации, исключая только очень маленькие офисы с несколькими пользователями.

Служба DNS Windows Server 2003 обеспечивает несколько вариантов развертывания. Вы можете помещать DNS-серверы в офисе там, где нет контроллера домена. Например, контроллер домена нежелательно располагать в маленьком офисе с медленным сетевым подключением к центральному офису из-за большого трафика репликации, направленного на контроллер домена. Однако DNS-сервер в этот офис поместить можно, так как он может быть сконфигурирован так, чтобы трафик репликации был очень мал или вообще отсутствовал. Если вы сконфигурируете DNS-сервер как сервер, предназначенный только для кэширования, он будет оптимизировать поиски клиента, но не создаст трафика зонной передачи. Можно сконфигурировать DNS-сервер с сокращенными зонами для доменов Active Directory. Поскольку сокращенные зоны содержат только несколько записей, к удаленному офису будет направляться очень небольшой трафик репликации.

Практический опыт. Проектирование сайтов для филиалов

Специальным образом проектируется сайт для компании, которая имеет несколько сотен маленьких офисов с контроллерами домена в каждом из них. Это усложняет проектирование и развертывание Active Directory во многих отношениях. Каждый дополнительный сайт увеличивает время, которое требуется службе проверки целостности сведений (КСС) на вычисление топологии репликации. Во время работы служба КСС может занимать 100 процентов времени процессора сервера. С большим количеством сайтов контроллер домена, являющийся ISTG (генератор межсайтовой топологии) в центральном офисе, может занять все время процессора и, тем не менее, никогда не завершить вычисление. Если подключение сайта сконфигурировано с графиком, разрешающим репликацию только в течение 6 часов каждую ночь, вы можете обнаружить, что требуется развернуть несколько серверов-плацдармов для еженощного выполнения репликации ко всем удаленным местам. Усложняется даже установка контроллеров домена для каждого сайта. Если сетевое подключение очень медленное, и вы просто устанавливаете контроллер домена в сайт, а затем заполняете каталог путем репликации, начальная репликация для большого каталога может занимать часы.

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

Несмотря на это, планирование и развертывание сайтов Active Directory в компании с сотнями сайтов все еще является сложным случаем. Если вы имеете дело с таким типом среды, то лучшим ресурсом для вас является Active Directory Branch Office Planning Guide (Руководство планирования Active Directory для филиалов), имеющееся на сайте Microsoft. Хотя это руководство подготовлено для Windows 2000, многие из концепций применимы к Windows Server 2003.

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

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

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

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

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

Размещение серверов глобального каталога

GC-серверы нужны пользователям для входа на домены, которые работают на основном (native) функциональном уровне Windows 2000, или когда пользователи делают поиск информации каталога в Active Directory. Если домен работает на основном функциональном уровне Windows 2000, нужно поместить GC-сервер в каждый сайт. В идеале все это должно быть сбалансировано трафиком репликации, который создается в результате помещения GC-сервера в каждом сайте. Если у вас очень крупное предприятие с несколькими большими доменами, GC-тра-фик репликации будет значительным. Общее правило состоит в том, что-бы размещать GC-сервер в каждом сайте и несколько GC-серверов в больших сайтах.

Одно из улучшений Active Directory Windows Server 2003 состоит в том, что эта система поддерживает входы в систему домена без доступа к GC-серверу за счет кэширования универсального группового членства. Когда эта функция включена, контроллеры домена могут кэшировать универсальное групповое членство пользователей в домене. Когда пользователь входит на сайт в первый раз, универсальное членство группы пользователя должно быть найдено в GC-сервере. После первого входа в систему контроллер домена будет кэшировать универсальное групповое членство пользователя неопределенно долго. Кэш на контроллере домена модифицируется каждые 8 часов в результате контакта с назначенным GC сервером. Чтобы включить функцию универсального группового членства, откройте инструмент администрирования Active Directory Sites And Services (Сайты и службы Active Directory) и разверните объект того сайта, на котором вы хотите включить эту установку. Щелкните правой кнопкой мыши на объекте NTDS Site Settings (NTDS параметры сайта) и выберите Properties (Свойства) (см. рис. 5-13). На вкладке Site Settings (Параметры установки сайта) выберите опцию Enable Universal Group Membership Caching (Разрешить кэширование универсального группового членства) и в раскрывающемся списке Refresh Cache From (Обновить кэш из) выберите сайт, в котором расположен самый близкий GC-сервер.

Рис. 5-13. Конфигурирование кэширования универсального группового членства

Совет
Развертывание Exchange Server 2000 создает большую нагрузку на GC-серверах. Exchange Server 2000 не имеет своей собственной службы каталога, так что он зависит от GC. Когда клиент просматривает GAL, он видит всех получателей почты, перечисленных в GC. Когда Exchange Server 2000 надо найти адрес пользователя, чтобы доставить электронную почту, он делает запрос каталогу GC. Если вы развертываете Exchange Server 2000, вы должны расположить GC в каждом месте, где выполняется Exchange Server 2000, и увеличить общее количество GC серверов.

Размещение серверов хозяев операций

Наиболее важным хозяином операций для ежедневной работы является эмулятор основного контроллера домена (PDC). Этот сервер особенно важен, если домен работает на смешанном функциональном уровне Windows 2000 или на временном функциональном уровне Windows Server 2003, потому что все резервные контроллеры домена (BDC) с системой Windows NT4 полагаются на эмулятор PDC для синхронизации каталога. Кроме того, если ваша организация включает много клиентов низкого уровня без установленной службы Directory Services Client (Клиента услуг каталога), эти клиенты должны подключаться к эмулятору PDC, чтобы изменить свои пароли. Даже в основном режиме эмулятор PDC получает приоритетные обновления изменений пароля пользователя. Поэтому очень важно, где он расположен. Эмулятор PDC должен быть расположен в центральном офисе, где максимальное количество клиентов соединяется с сервером.

Размещение другого хозяина операций не так критично. Принимая решение о том, где располагать хозяина операций, используйте следующие рекомендации.

• По возможности хозяин схемы, хозяин именования домена и хозяин относительных идентификаторов (RID) должны быть расположены в сайте, имеющем другой контроллер домена в качестве прямого партнера по репликации. Причина связана с восстановлением системы в случае отказа. Если один из этих серверов перестанет работать, вам, возможно, придется захватить роль хозяина операций и передать ее другому контроллеру домена. Эту роль желательно передать на такой контроллер домена, который полностью реплицируется с первоначальным хозяином операций. С наибольшей степенью вероятности это произойдет в том случае, если два контроллера домена будут находиться в одном и том же сайте и будут сконфигурированы как прямые партнеры по репликации.
• Хозяин RID должен быть доступен для всех контроллеров домена через подключение по удаленному запросу процедуры (RPC). Когда контроллеру домена потребуется больше идентификаторов RID, он будет использовать RPC подключение, чтобы запросить их у хозяина RID.
• Хозяин инфраструктуры не должен располагаться на GC-сервере, если у вас более одного домена. Роль хозяина инфраструктуры состоит в обновлении ссылок на отображаемые имена пользователей между доменами. Например, если учетная запись пользователя переименована, и пользователь является членом универсальной группы, хозяин инфраструктуры обновляет имя пользователя. Если хозяин инфраструктуры расположен на GC-сервере, он не будет функционировать, потому что GC постоянно обновляется самой современной глобальной информацией. В результате хозяин инфраструктуры не обнаружит никакой устаревшей информации и, таким образом, никогда не обновит перекрестную междоменную информацию.
• Если организация имеет центральный офис, где располагается большинство пользователей, всех хозяев операций следует помещать в этот сайт.