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

🕛 19.01.2009, 20:38

В проектирование сайта входит определение мест размещения серверов, на которых выполняется система 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 по адресу http://www.microsoft.com/windows2000/ techinfо/planning/activedirectory/branchofficе/default.asp. Хотя это руководство подготовлено для 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 постоянно обновляется самой современной глобальной информацией. В результате хозяин инфраструктуры не обнаружит никакой устаревшей информации и, таким образом, никогда не обновит перекрестную междоменную информацию. * Если организация имеет центральный офис, где располагается большинство пользователей, всех хозяев операций следует помещать в этот сайт.

Резюме

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