Миграция’2000. Часть 2

Николай Прокофьев

Перевод ведущего контроллера домена под управление Windows 2000

   Шаг первый, он же шаг назад

   Шаг второй, или Грудью на амбразуру

   Шаг третий, или Прыжок на месте

   Шаг четвертый, или «В команде мальчиков замена»

Перевод системных сервисов домена под управление Windows 2000

Новые возможности по управлению серверами Windows 2000

Перевод ведущего контроллера домена под управление Windows 2000

Отличительной особенностью процесса миграции (и одновременно потенциальным источником проблем) является необходимость обновлять прежде всего головной контроллер домена. Однако это на первый взгляд очевидное требование при более пристальном рассмотрении не может не вызывать опасений, поскольку в случае некорректно проведенного обновления можно потерять массив учетных записей пользователей. В случае если в сети имеется около 20-30 учетных записей, это не катастрофа, а всего лишь досадная неприятность. Максимум, чем придется пожертвовать, так это парой часов на повторное их создание. Другое дело, если количество учетных записей превышает 100. Именно по этой причине первой очередной задачей становится исследование возможностей возвращения домена в его первоначальное состояние, независимо от успеха установки Windows 2000.

Шаг первый, он же шаг назад

Прежде всего исключим все продвинутые способы восстановления, связанные с использованием стриммеров и прочих внешних носителей. Естественно, самым простым делом было бы полное копирование жесткого диска контроллера домена на внешний носитель для последующего его восстановления в случае проблем с новой операционной системой. Однако такое решение предполагает наличие стриммера (или другого внешнего носителя) большой емкости, а также специализированного программного обеспечения. Искренне веря, что элегантность решению придает не количество используемого передового аппаратного и программного обеспечения, а минимизация необходимых для его осуществления ресурсов, мы приступили к поискам такого решения. В результате непродолжительных экспериментов оно было найдено. Как и полагается приемлемому решению, оно не было однозначным, а целиком и полностью определялось рекомендациями компании Microsoft и здравым смыслом при первоначальной установке и конфигурировании домена NT 4.0. В литературе рекомендуется устанавливать для контроллера домена отдельную машину (PDC-1), не несущую дополнительную нагрузку (file sharing, сервер приложений и др.). Исключение могут составлять «системные» сервисы NT, такие как WINS-, DNS- и DHCP-серверы. В этом случае для инициализации процесса миграции требуется одна рабочая станция (PDC-2) в минимальной конфигурации, необходимой для работы операционной системы MS Windows NT 4.0 Server. На нее устанавливается операционная система NT 4.0 Server (конфигурация Backup Domain Controller BDC). Далее на нее переносятся все «системные» сервисы, необходимые для работы домена в целом, после чего осуществляется продвижение PDC-2 до статуса Primary Domain Controller (PDC). И наконец, завершающим этапом является физическое отключение PDC-2 от сети путем отключения сетевого кабеля. В итоге мы получаем PDC домена, ведущий обособленный образ жизни, и домен, неожиданно оказавшийся без головного контроллера. Инициировав процесс перевыбора PDC в домене, мы возвращаем полномочия PDC исходному серверу PDC-1. В результате мы имеем одновременно два головных контроллера нашего домена. Следующим шагом должна стать установка ОС Windows 2000 на сервер PDC-1. Если же по какой-либо причине она будет выполнена некорректно, мы в любой момент можем отключить PDC-1 и подключить PDC-2, вернув таким образом полную работоспособность нашему домену. Более сложным является ситуация, когда на PDC возлагаются дополнительные задачи, исключающие возможность его отключения от сети. В этом случае рабочая станция должна соответствовать требованиям ОС Windows 2000. Кроме того, процесс миграции тогда будет осуществляться несколько иным способом: новая операционная система будет устанавливаться на новый сервер (по нашей терминологии на PDC-2), причем ни один сервер не будет отключаться от сети. Если происходит сбой при установке Windows 2000 или возникают какие-либо иные проблемы, PDC-2 просто выключается, а контроллер домена PDC-1 вновь возвращается в статус ведущего посредством инициирования процесса promote to PDC.

Шаг второй, или Грудью на амбразуру

Теперь, после приготовления и расчистки путей отхода, мы можем приступать к обновлению контроллера домена. Эта процедура при наличии реального опыта работы с NT 4.0 и Windows 2000 Professional не представляет собой ничего сверхсложного, однако свои «узкие места» здесь имеются.

Прежде всего напомним, что Windows 2000, а точнее служба Active Directory, теснейшим образом связана со службой Domain Name Service (DNS), прекрасно знакомой каждому работающему в сети Internet: именно она осуществляет трансляцию имен ресурсов (вида www.ru) в IP-адреса (вида 127.0.0.1). Применение этой службы в рамках домена позволяет достичь единообразия в именовании ресурсов внутренней и внешней сетей к вящему комфорту пользователей. Следовательно, для работы обновленного домена необходим внутренний DNS-сервер. Но вот тут-то и обнаруживается жесткая связка строгих требований, каждое последующее из которых зависит от предыдущего. В первую очередь для DNS-сервера нужен статический IP-адрес. Под термином «статический» понимается IP-адрес, назначенный сетевому интерфейсу вручную, то есть без использования DHCP-сервера. Поскольку большинство внутренних сетей используют «мнимую» IP-адресацию, этот адрес будет выглядеть как 100.100.100.1. Следовательно, при установке операционной системы Windows 2000 на контроллер домена необходимо в явной форме указать этот адрес в качестве локального IP-адреса. На всякий случай уточняем, что этот адрес должен входить в подсеть IP-адресов, выдаваемых рабочим станциям, так как в противном случае они не смогут с ним работать. Кроме того, в настройки сервера DHCP необходимо добавить адрес этого DNS-сервера, поскольку без него пользователи не смогут работать с Active Directory.

Следующим «узким местом» является система адресации Active Directory. Основная проблема заключается в использовании аналогичной схемы адресации во внутренней и во внешней сети. Это означает, что если мы будем использовать доменное имя mycompany. ru, то при попытке обратиться на WWW-страничку www.mycompany.ru по нашему запросу будет проводиться поиск сервера «www» из нашего локального домена. Указанная особенность хорошо известна еще по серверу имен Microsoft DNS Server из состава Windows NT 4.0, где она проявлялась во всей красе при ручном изменении одной из зон, реплицированных с головного DNS-сервера. Для тех, кто никогда не сталкивался с этой проблемой, объясним: в случае ручного изменения одной из адресных записей зоны содержимое всей зоны сбрасывается, а сохраняется только добавленная запись. В результате получается, что если мы добавим в зону .COM реально не существующее доменное имя www.not-present-domain-name.com, то все остальные адреса из этой зоны не будут корректно интерпретироваться. Поэтому представляется разумным давать внутренним станциям явно не существующее доменное имя, например mysuperpupercompany.ru.

На этом мы заканчиваем описание «узких мест» процедуры обновления головного контроллера домена и переходим к следующему этапу обновления домена, а именно к настройке резервных контроллеров домена. Здесь существует некий дополнительный аспект, рассмотрению которого мы посвятим следующий раздел.

Шаг третий, или Прыжок на месте

Рано или поздно каждый системный специалист сталкивается с проблемой обновления существующего программного обеспечения, чему неизменно уделяется много внимания в специализированных конференциях. Кроме того, после выхода первой статьи цикла (КомпьютерПресс № 3’2001) почтовый ящик автора этих строк просто переполнен сообщениями, посвященными этой проблеме. Затем мы попробуем сформулировать свое личное отношение к проблеме обновления используемого программного обеспечения, основанное исключительно на нашем собственном опыте, информации из достоверных источников и индивидуальных предпочтений.

Понятно, что указанная проблема является одной из важнейших. Выход новых версий программ раз за разом вынуждает нас обновлять программную начинку своих «железных ящиков». Вообще-то, это здорово, поскольку каждая последующая версия имеет больше возможностей, нежели предыдущая. При этом неважно, о каком программном продукте идет речь: это может быть и текстовый редактор, и компилятор, и операционная система… Различия в новых версиях продукта касаются не только интерфейсной части, но и ядра программы и версий используемых динамических библиотек. При этом автоматическая поддержка нисходящей схемы совместимости библиотек (каждая последующая поддерживает все функции предыдущей) позволяет запускать MS Word 6.0 под операционной системой Windows 2000. Но горе тому, кто попробует запустить Office 2000 под управлением Windows 3.1! Кроме того, новые версии прикладного программного обеспечения могут иметь завышенные требования как к минимальной аппаратной конфигурации, так и к минимальной допустимой версии операционной системы. Как правило, процедуры обновления предусматривают возможность так называемого «отката», возврата к предыдущей версии программного обеспечения. Исключение составляют операционные системы, восстановление которых возможно только кардинальными способами. Возврат — это, конечно, дело хорошее, если бы не одно существенное «НО»: вся информация по откату хранится не где-нибудь, а на вашем локальном диске. И уж поверьте, что возможность возврата к предыдущей версии щедро оплачивается за счет вашего дискового пространства.

С обновлением операционных систем ситуация обстоит гораздо хуже. Представьте себе, что компания Microsoft выпустила новую операционную систему Windows 10001 и нам жизненно необходимо поставить ее на свой компьютер. Естественно, на нем уже установлено колоссальное количество прикладных программ — начиная от средств разработки, продолжая офисными приложениями и заканчивая набором любимых игр. Как правило, именно последние наиболее нетерпимо относятся к изменениям в используемой операционной системе. В результате у нас есть два пути: либо установить новую операционную систему поверх уже существующей (в этом случае существует шанс, что не потребуется заново переустанавливать прикладное программное обеспечение), либо, не пожалев времени (от 1 рабочего дня до 1-2 рабочих недель — в зависимости от специфики деятельности), полностью заново установить операционную систему, включая процедуру форматирования системного диска. Не претендуя на истину в последней инстанции и опираясь исключительно на собственный опыт, можно было бы привести целый ряд примеров, когда обновление операционной системы приводило к необходимости переустановки рабочего программного обеспечения. В этом случае все положительные стороны обновления исчезают и на первый план выходят такие недостатки, как увеличенные требования к объемам жесткого диска и необходимость чистки реестра операционной системы. На сервере ситуация тоже обстоит не лучше, кроме того она усугубляется повышенными требованиями к надежности его функционирования, а перспектива обновления операционной системы выглядят совсем непривлекательно. Однако именно это нам и навязывает компания Microsoft, предполагая установку новой операционной системы Windows 2000 поверх предыдущей инсталляции НТ 4.0 (если мы хотим унаследовать массив учетных записей домена НТ 4.0). Поскольку удаление массива учетных совершенно исключено, придется каким-то образом обходить это требование.

Шаг четвертый, или «В команде мальчиков замена»

Суммируя все вышеизложенное, мы имеем задачу: произвести на каждом из контроллеров домена «чистую» установку серверной операционной системы Windows 2000 Server (Advanced server) с сохранением массива учетных записей пользователей домена NT 4.0. Согласно рекомендациям Microsoft, это представляется невозможным, поскольку установку серверной операционной системы предполагается производить поверх предыдущей версии. О какой чистоте установки здесь можно говорить? Однако выход существует. Для того чтобы его найти, обратимся к концепции организации доменов Windows NT/2000. Основную работу по авторизации пользователей выполняет головной контроллер домена (PDC), на котором и хранится основная база пользователей. В дополнение к головному контроллеру в домене используется ряд резервных контроллеров домена (BDC), находящихся в режиме готовности к перехвату функций головного контроллера, в случае если по какой-либо причине он перестанет работать. Эта схема позволяет обеспечить достаточно высокую отказоустойчивость сети в целом. И именно эта особенность позволит нам выполнить чистую установку серверной операционной системы на контроллеры доменов с сохранением старой базы учетных записей. Сама по себе эта операция не представляет собой ничего необычного: мы просто устанавливаем Windows 2000 Server (Advanced Server) на другой сервер и передаем ему полномочия головного контроллера домена. (Обратите внимание: после появления в сети головного контроллера домена под управлением Windows 2000 уже невозможно передать функции PDC на резервный контроллер домена под управлением NT 4.0! Это возможно только после физического отключения головного контроллера домена, что может привести к утрате пользовательской информации и сделать недоступной структуру данных, организованную с помощью технологии Active Directory.) После этого «обновленный» контроллер домена подвергается процедуре чистой установки с форматированием жесткого диска. В результате мы получаем сохраненную базу учетных записей пользователей — с одной стороны и установленные «с чистого листа» серверные операционные системы — с другой. Как говорится в популярной рекламе: и волки сыты, и бабки целы. На этой оптимистической ноте мы заканчиваем рассказ об обновлении контроллеров домена и переходим к не менее интересной проблеме обновления системных сервисов домена, таких как сервис динамического распределения IP-адресов (DHCP) и сервисы разрешения доменных имен (WINS, DNS, DDNS).

Перевод системных сервисов домена под управление Windows 2000

Перенастройка системных сервисов является вторым по важности и совершенно неизбежным моментом при нелегком переходе под управление операционной системы Windows 2000. Под системными сервисами в дальнейшем мы будем понимать сервисы, необходимые для нормальной работы как отдельных рабочих станций, так и домена в целом. Соответственно в эту категорию попадают сервис динамического распределения IP-адресов и сервисы разрешения доменных имен. Кроме того, дальнейшие рассуждения касаются монопротокольной IP-сети (Intranet), у которой только отдельные рабочие станции могут иметь поддержку дополнительных сетевых протоколов. В этом случае возникает необходимость разрешения имен рабочих станций. Для этого используются два сервиса: Windows Internet Name Server (WINS, собственная разработка Microsoft) и Domain Name Service (DNS, используется для разрешения имен Internet). У каждого из этих сервисов имеются свои достоинства и недостатки. Например, WINS позволяет динамически переформировывать таблицу NetBIOS-имен на основе сиюминутной информации, без вмешательства оператора. DNS, напротив, требует ручного внесения изменений в таблицу имен в случае каких-либо изменений, что исключает возможность его использования вместе с сервисом динамического распределения IP-адресов (DHCP). Для многоадаптерных систем (к таковым можно отнести серверы безопасности, proxy-серверы и почтовые серверы, имеющие, как правило, по отдельному адаптеру на внешнюю и внутреннюю сети) использование WINS вызывает известные проблемы, поскольку при возникновении необходимости в их перезагрузке зачастую приходится вручную очищать таблицу имен WINS. Это вызвано тем, что после перезагрузки возникает конфликт сетевых имен (на мультиадаптерной системе возникало сообщение о существовании в сети компьютера с таким именем), что исключает возможность работы данного сервера в сети. По вышеуказанным причинам в доменах НТ 4.0 эти сервисы применяются параллельно: WINS разрешает имена рабочих станций внутренней сети, а DNS отвечает за разрешение статических адресов внутренней сети (как правило, отведенные под серверы) и сети Internet. С выходом операционной системы Windows 2000 ситуация изменилась: в новой версии DHCP-сервер имеет возможность создавать и изменять DNS-записи, что позволяет отказаться от использования сервиса WINS в сетях Windows 2000. Таким образом, мы получаем единую централизованную систему распознавания имен, дающую возможность гибкого управления и конфигурирования как клиентских рабочих мест, так и серверов. При этом рабочие станции и серверы получают псевдоинтернетовские имена вида %ComputerName%. %Windows2000domainName%.

Новые возможности по управлению серверами Windows 2000

В заключение хотелось бы сказать о давно ожидаемом новшестве, позволяющем существенно облегчить управление серверами Windows 2000 и доменом в целом. Этим новшеством стало появление в стандартной поставке сервиса удаленного управления (Terminal service). Аналогичные продукты от третьих производителей (pcAnywhere и т.д.) уже давно завоевали и любовь сетевых специалистов, и признание хакеров. С его помощью можно получить доступ к серверу с любой рабочей станции и управлять им так же, как собственной рабочей станцией. Таким образом полностью создается эффект присутствия на сервере, сколь бы удаленным он ни был. В результате уже нет необходимости локально устанавливать средства управления и контроля доменом. Значение данного средства управления трудно переоценить, особенно если учесть, что администраторы, как правило, сидят отдельно от серверов и вынуждены заходить в систему локально для таких рутинных операций, как проверка жестких дисков серверов и выполнение профилактических процедур. В целях установления клиентского программного обеспечения необходимо всего лишь создать на сервере в интерактивном режиме дистрибутивный пакет (занимает 3 дискеты) и установить его на рабочую станцию. Как говориться, минимум усилий при максимуме отдачи.

В следующей статье цикла мы рассмотрим обновление сервера электронной почты Microsoft Exchange и сервера Microsoft SQL.

КомпьютерПресс 6'2001