Занятие №11. Планирование системы

Планирование системы

Говоря о планировании системы, обычно подразумевают выбор критериев используемой техники, определение нагрузочной способности, необходимых сервисов и протоколов и т. п. Вобщем планирование системы мало чем отличается от планирование предыдущей версии Windows NT, во многом методики расчета применимы и к новой версии Windows 2000.

Появление в Windows 2000 службы каталогов Active Directory существенно изменяет подход к построению сетей на базе Windows NT.

Вместо привычных одно- или двухъярусных объединений доменов предполагается строить иерархии доменов, объединять домены в деревья доменов, а деревья доменов — в леса.

Да и внутри доменов стало возможным создавать иерархичные структуры организационных единиц. Изменились и роли контроллеров доменов, механизмы их взаимодействия друг с другом и с клиентами.

Особого внимания заслуживают такие вопросы, как планирование архитектуры DNS, а также планирование структуры узлов.

Именно о них мы и поговорим, а также рассмотрим процесс установки Windows 2000, сделав при этом упор на особенностях установки первой бета-версии.

Планирование архитектуры DNS

Давайте начнем с планирования интрасети нашей организации. Учтите, что многие советы из этого раздела пригодятся Вам и при подключении сети к Интернету.

Перед началом планирования архитектуры DNS следует изучить или повторить концепцию и терминологию DNS. Лучше всего это делать по специальной литературе.

Пример организации DNS

Итак, мы приступаем к планированию интрасети. Первыми нашими шагами станут:

• разработка структуры имен доменов;

• определение количества доменов и поддоменов;

• определение нужного числа конфигурируемых зон;

• определение числа серверов;

• решение, будет ли сервис DNS интегрирован с Active Directory;

• определение количества клиентов DNS;

• планирование пространства имен.

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

Но на этом пути нас подстерегают две опасности. Первая — по мере роста зоны ею станет сложно управлять централизованно.

Для решения этой проблемы внутри зоны можно создать несколько поддоменов и делегировать им (разумеется, в разумных пределах) полномочия администрирования.

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

В большинстве же случаев лучше создавать поддомены по организационному или территориальному признаку.

В больших, охватывающих несколько узлов, сетях хороший эффект дает разбивка на несколько зон, каждая из которых управляется своей службой DNS.

При такой структуре нужен один корневой (roof) домен с одним первичным и несколькими вторичными серверами DNS.

В остальных зонах (или подзонах) также должно быть по одному первичному и по несколько вторичных серверов DNS.

В больших организациях целесообразно комбинировать территориальный и производственный принципы деления на зоны.

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

Замечание. Старайтесь создавать домены так, чтобы они соответствовали доменам DNS, зонам и поддоменам.

Другой, не менее важный, вопрос; какие имена давать доменам и хостам, какие символы допустимо в этих именах использовать?

Вообще-то, сервер DNS Microsoft позволяет использовать любые символы, включая Unicode.

Это означает, что в интрасети допустимы даже русские имена зон, доменов и хостов.

Тем не менее, не рекомендуется поддаваться такому соблазну. Лучше строго следовать стандартам: ведь неизбежно настанет день, когда Вы подключите свою сеть к Интернету. Тогда и поймете, что поступили правильно.

Выбор поддерживаемой системы, наименований DNS

Согласно стандарту RFC952, в именах допустимо использовать строчные и прописные латинские буквы (A-Z), цифры (0-9), дефис (-) и точки.

Обратите внимание на то, что использование точек допускается только в качестве разделителей в имени DNS.

Кроме того, спецификации RFC1123 дополнительно задают следующие правила:

• в качестве первого символа в имени допустимы как буквы, так и числа;

• полное имя домена может иметь длину до 63 октетов, а полностью определенное имя - до 255 символов.

Планирование количества и типов серверов имен

В каждой зоне должно быть как минимум два сервера DNS: первичный и вторичный.

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

Число серверов DNS и их расположение определяются объемом сети, связями между подсетями и требованиями безопасности.

Серверы имен могут быть первичными, вторичными или просто кэширующими.

Первичные серверы следует располагать вблизи наиболее критичных и часто используемых серверов, таких, как серверы файлов, почтовые серверы или серверы Web.

Вторичные серверы нужны для избыточности и для разгрузки первичных.

Эффективность здесь достигается ограничением числа серверов, которым разрешается забирать обновления непосредственно с первичных.

Для повышения производительности разрешения имен (особенно на низкоскоростных линиях) рекомендуются кэширующие серверы имен.

В предыдущих версиях Windows NT обязательным механизмом регистрации и разрешения имен в сети является NetBIOS.

Для динамичного отслеживания соответствия NetBIOS -имен и IP- адресов рекомендуется использовать WINS. В Windows 2000 на смену NetBIOS пришел сервер DNS, и серверы WINS больше не нужны.

Внимание! В Windows 2000 оставлена поддержка WINS для унаследованных систем.

Допускается и интеграция DNS с WINS таким же образом, как в Windows NT 4.0.

Сервер DNS в Windows NT 2000 поддерживает динамические обновления в соответствии со спецификациями RFC 2136.

Динамический сервер DNS позволяет клиентам и серверам регистрировать доменные имена и соответствующие IP-адреса без участия администратора.

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