При этом ход рассуждений примерно такой: «Да, нам действительно нужны все разрекламированные свойства новой операционной системы, в конце концов, мы непременно перейдем к работе с AD, но реализация AD как первый этап развертывания Windows 2000 представляется нам слишком уж решительным шагом. Лучше мы пока привыкнем к работе с компьютерами и серверами Windows 2000, а уж потом развернем AD. Что мы теряем-то?»

А вот что. Во-первых, большинство наиболее значимых свойств Windows 2000 Server требует наличия AD, и это наводит на мысль, что полностью отказаться от AD нельзя. Но это к слову, для тех, кто решил повременить с развертыванием AD, поскольку даже простая установка серверов Windows 2000 - пусть и без AD - имеет свои неоспоримые преимущества.

Есть одна причина для того, чтобы в самом деле развернуть операционную систему Windows 2000 на серверах - членах домена без установки AD, и она, вероятно, многих удивит. Хотя Windows 2000 задумана в том числе и как средство избавления от службы WINS, тем не менее служба имен Internet для Windows пребудет с нами еще долгое время. Функционирование WINS не требует наличия AD. Если в дальнейшем AD будет развернута, то и тогда администраторам сетей беспокоиться нечего. Комичность ситуации состоит в том, что именно решение проблемы WINS стало одной из первых выдающихся побед сетей, где работают серверы Windows 2000.

До выхода в свет пакета исправлений Service Pack 4 (SP4) для NT 4.0 удалять устаревшие записи из базы данных WINS было непросто. Для Windows 2000 аналогичная задача решается непосредственно через интерфейс пользователя без особого труда. Многим администраторам время от времени требуется ASCII-представление содержимого базы данных WINS, например для написания файлов сценариев или же просто для получения распечатки базы данных WINS. Но в среде NT 4.0 разработчики не предлагают простых и надежных механизмов для формирования дампа базы данных WINS. Зато операционная система Windows 2000 обеспечена не только удобным GUI-интерфейсом для выполнения задач администрирования, но также и утилитой командной строки Netsh, которая представляет целый ряд возможностей как для работы с WINS, так и для администрирования DHCP, RAS, маршрутизации. (Ниже я продемонстрирую функции «родной» утилиты DHCP - Dnscmd.)

В среде NT 4.0 работа службы WINS часто прерывалась из-за разрушения базы данных. Специалисты Microsoft рекомендовали администраторам сетей стараться сводить к минимуму суммарное число WINS-серверов: чем большее число серверов обеспечивало поддержку WINS, тем сложнее становилось выполнять репликацию базы данных, а иногда при репликации база данных WINS оказывалась поврежденной. Не так для Windows 2000: да, вероятность разрушения базы данных по-прежнему остается, но она становится гораздо ниже из-за того, что служба WINS в Windows 2000 имеет встроенные механизмы для перекрестного контроля целостности с базами данных других серверов.

Служба WINS - это только один из примеров использования возможностей Windows 2000 без необходимости развертывания AD. Менеджер DHCP - другой пример такого рода, его работа в среде Windows 2000 тоже заметно усовершенствована. Утилита Netsh упрощает составление сценариев для применения DHCP и позволяет администраторам исполнять свои обязанности удаленно, используя низкоскоростное соединение с помощью telnet-сервера, установленного на станции Windows 2000.

Хотя службы DNS тесно интегрированы в структуру AD и AD не в состоянии работать без установки сервера DNS, последний может функционировать и без AD. Как уже отмечалось, разработчики Microsoft для работы с сервером DNS включили в дистрибутив Windows 2000 мощную утилиту командной строки - Dnscmd. Нужно лишь иметь в виду, что программа установки Windows 2000 Setup не инсталлирует эту утилиту на жесткий диск автоматически. Разыскать программу Dnscmd можно на компакт-диске Windows 2000 Server в каталоге support oolssupport.cab (в тексте справки по ошибке указано, что программа Dnscmd находится в другом каталоге - supportenterprise eskit). Утилита Dnscmd позволяет администраторам системы создавать и модифицировать записи о ресурсах, получать дамп записей, реконфигурировать сервер, а также решать почти в полном объеме тот же перечень задач, который выполняется с консоли Microsoft Management Console (MMC). Иначе говоря, администратор в состоянии управлять DNS на расстоянии - пусть даже по медленному соединению.

Я настоятельно рекомендую тщательно разобраться в инфраструктуре DNS сети до того, как начнется развертывание AD. Некоторая специфика, предъявляемая к построению DNS со стороны AD, вероятнее всего, заставит модернизировать серверы DNS. Может быть, придется даже заново переустановить их, или добавить к уже имеющимся новые серверы DNS - для поддержки AD.

Многие администраторы сетей планируют строить лес AD в зарегистрированном домене DNS - еще одна причина для того, чтобы реализовать DNS до начала работ по инсталляции AD. Устанавливая в первую очередь DNS-сервер домена, администратор сети тем самым гарантирует, что его сервер не потеряется во Всемирной паутине. А если DNS-сервер на базе Windows 2000 успешно справляется с задачей разрешения имен в рамках домена, значит, службы AD, которые будут установлены не сегодня-завтра, смогут воспользоваться услугами сервера DNS. Нет никакой необходимости для поддержки AD использовать сервер DNS именно на базе Windows 2000, но, вероятно, администраторы сетей захотят воспользоваться преимуществами интегрированной системы безопасности, обеспечиваемой реализацией DNS в операционной системе Windows 2000.

В Windows 2000 реализованы некоторые возможности, относящиеся к области маршрутизации, использование которых не требует наличия AD. Функция Internet Connection Sharing (ICS) - неотъемлемая часть всех версий Windows 2000 (Server, Professional), Windows Me, а также Windows 98SE. Она дает администратору возможность использовать фактически любой вид Internet-соединения - по обычной телефонной линии, с применением цифровой абонентской линии (Digital Subscriber Line, DSL), по модему, - и при этом предоставлять это соединение в общий доступ с нескольких локальных станций. С небольшими накладными расходами на обеспечение управления маршрутизацией операционная система Windows 2000 реализует задачи трансляции адресов Network Address Translation (NAT), т. е. маршрутизатора, который также прекрасно работает без AD (для управления маршрутизатором NAT используется команда Netsh).

Есть еще одно приложение, которое вполне обходится без AD, - Microsoft IIS 5.0 (на одном и на том же оборудовании IIS 5.0 показывает удвоение производительности по сравнению с IIS 4.0). Я пользуюсь IIS 5.0 вот уже скоро год, но не только из-за высокой скорости новой версии. Мне нравится, как в новой версии IIS реализована поддержка записей заголовка хоста для виртуального Web-сайта. Работая время от времени Web-мастером, я тем не менее ничего не знал о записях заголовка хоста (хотя IIS 4.0 также поддерживает их обработку), пока с помощью мастера Web Site Creation Wizard, входящего в состав IIS 5.0, не раскрыл их содержимое. Для новичков в деле Web-технологий, к коим я себя причисляю, очень приятно наконец-то получить внятное объяснение, что же такое записи заголовка хоста, как с ними обращаться и почему они требуют к себе особого внимания.

Я запустил два Web-сайта на одной и той же машине. Один из них, сайт www.minasi.com - это мой основной сайт, который сообщает обо мне остальным пользователям Internet. Другой сайт, www.softwareconspiracy.com, предназначен для лиц, не принадлежащих к моему профессиональному окружению. Оба сайта развернуты на одной и той же станции и имеют одинаковый IP-адрес. Вопрос - как сообщить приложению IIS, что одним посетителям нужно отсылать содержимое www.minasi.com, тогда как другие должны получать информацию от сайта www.softwareconspiracy.com? Когда я пользовался версией IIS 4.0 - еще до того, как прояснилась картина с записями заголовка хоста, - мне приходилось назначать два IP-адреса для Web-сервера. Один адрес принадлежал www.minasi.com, а другой - www.softwareconspiracy.com.

«Да так ли важна эта разница?» - спросят меня читатели. Как сказать. Например, организация, предоставляющая Web-хостинг, может не иметь в своем распоряжении достаточного количества IP-адресов для удовлетворения нужд крошечных персональных Web-сайтов. Или другая причина: что если требуется запустить более одного Web-сайта на своем персональном компьютере, используя DSL-соединение? Большинство DSL-провайдеров не предоставляют в таких случаях второй IP-адрес, так что моя технология на базе IIS 4.0 не годится. Используя IIS 5.0, при обращении браузера к моему Web-серверу, последний задаст браузеру вопрос: «С кем общаться?» Если браузер ответит: «www.softwareconspiracy.com», то IIS передаст во внешний мир содержимое именно этого Web-сайта. В случае ответа «www.minasi.com» IIS предоставит клиенту содержимое сайта общего назначения. Одно замечание: некоторые старые браузеры не поддерживают обработку записей заголовка хоста, поэтому IIS будет переадресовывать запросы таких браузеров к Web-сайту по умолчанию, не обращая внимания на пожелания клиентов. Но подобных браузеров осталось совсем немного.

ОБ АВТОРЕ

Марк Минаси - редактор Windows NT Magazine, MCSE, и автор книги «Mastering Windows NT Server 4.0» (издательство Sybex). С ним можно связаться по адресу: mark@minasi.com.

Поделитесь материалом с коллегами и друзьями