Документы о рабочей средеСетевая загрузка Windows

Уэс Миллер (Wes Miller)

Содержание

Как работает PXE
Служба RIS в подробностях
Служба развертывания Windows (WDS) — начало
Другие игроки
Заключение

В течение следующих нескольких месяцев я планирую описать службу развертывания Windows (WDS), которая доступна для Windows Server 2003 и встроена в Windows Server 2008. Служба развертывания Windows может стать очень важной частью вашей инфраструктуры развертывания, поэтому в нашем обсуждении я хочу добиться хорошего знакомства с основами ее работы. Эта

первая статья будет посвящена глубокому анализу протокола удаленной загрузки (PXE; произносится «пикси»), истории службы удаленной установки (RIS) и другим технологиям, которые связаны с удаленной загрузкой и используются корпорацией Майкрософт.

Когда в 2001 году меня перевели в группу разработки базовых возможностей ОС Windows, то одной из доставшихся мне в наследство технологий была RIS (и я был несколько напуган тем, насколько она была сложной и зависимой от оборудования и BIOS). Однако сложилось так, что вместе с Windows® PE RIS стала одной их тех технологий, которые мне, как руководителю программы, понравились больше всего.

Я помню, как впервые устанавливал Windows 3.0 — с набора трехдюймовых дискет. Со временем установка стала проще благодаря распространению загрузочных компакт-дисков (на которых выпускались некоторые версии Windows 98). Но одна вещь всегда оставалась неизменной: для установки требовался какой-то локальный носитель, так же, как и локальный жесткий диск.

С годами пользователи все чаще начали требовать возможности сетевой загрузки Windows — то есть загрузки только по сети на компьютер, не имеющий жесткого диска. Хотя некоторые ранние версии Windows и могли это делать, в Windows NT® такой возможности не было никогда. И хотя текущие версии Windows Server® 2003 и Windows Server 2008 могут загружаться через инициатор iSCSI, этот процесс отличается от настоящей сетевой загрузки тем, что он не полностью локален, а все время зависит от удаленного устройства, используемого как загрузочный диск.

Подготовка клиентских компьютеров

• Оценка процесса подготовки клиента RIS
• Планирование улучшения сетевой безопасности при помощи подготовленных клиентов
• Подготовка клиентских компьютеров
• Удаленная установка операционной системы

Начиная с Windows 2000 Microsoft приступил к разработке технологии, которая с течением времени стала называться службой удаленной установки RIS и которая должна была реализовать установку по сети. Цель службы RIS была достаточно проста: перенести образ операционной системы на локальный диск нужного компьютера с помощью протокола PXE.

Как работает PXE

На рис. 1 изображена последовательность загрузки с помощью PXE. PXE — это довольно простой протокол, разработанный Intel и другими поставщиками оборудования как часть инициативы Wired for Management («сеть для управления»). Протокол произошел от протокола DHCP, который в свою очередь был разработан на основе протокола BootP и обычно реализуется в сетевых платах. Проще говоря, происходит следующее:

Рис 1: Последовательность загрузки с помощью PXE(щелкните изображение, чтобы увеличить его)

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

Второй этап Если в последовательности загрузки PXE находится впереди жестких дисков, флэш-накопителей и компакт-дисков или ни одно из этих устройств не установлено, то с сетевой платы загружается универсальный интерфейс сетевых драйверов (UNDI). В сетевую плату встроены очень маленький драйвер сетевого устройства и реализация протокола TFTP. (В некоторых версиях BIOS пользователь должен нажать клавишу F12, чтобы использовать протокол PXE. Это нестандартное поведение, и я очень рад, что его можно выключить).

Третий этап Система начинает широковещательную трансляцию по протоколу UDP, пытаясь найти сервер DHCP. Фактически это и есть первый этап последовательности загрузки с помощью протокола PXE, который называется «обнаружение» (Discover). Заметьте, что используется протокол UDP — а значит, если вы еще этого не сделали, то стоит потратить некоторое время на настройку маршрутизаторов и коммутаторов, чтобы разрешить обмен данными по протоколу PXE.

Четвертый этап Если сервер DHCP принял трансляцию, он отвечает выдачей IP-адреса. Этот этап называется «предложение» (Offer). Важно помнить, что протокол PXE — протокол без сведений о состоянии, и объем уникальных данных о состоянии системы, который доступен клиенту, довольно ограничен (MAC-адрес и, если он доступен, идентификатор GUID системы System Management BIOS, известный также как SMBIOS GUID).

Пятый этап Клиент, получив пакет данных с IP-адресом, требует дополнительной информации — адреса сервера PXE. Происходит следующая широковещательная передача, при которой, в частности, передаются данные, полученные в первом ответе от сервера DHCP. Клиент говорит серверу DHCP: «Мне нужна дополнительная информация — в частности, данные о местонахождении программы сетевой загрузки (NBP) ». Этот этап называется «запрос» (Request).

Шестой шаг В ответе сервера протокола PXE содержится адрес его самого и данные о расположении NBP — очень маленькой исполняемой программы загрузки, размер которой не должен превышать 32 килобайта. Этот шаг называется «подтверждение» (Acknowledge). Возможно, вы уже заметили аббревиатуру DORA (Discover, Offer, Request, Acknowledge), – хороший способ запомнить последовательность шагов.

Обратите внимание, что если у вас установлены сервер DHCP и служба WDS корпорации Microsoft (или похожий набор средств от другого поставщика), то этап запроса отсутствует, а пакет данных, отправляемый сервером DHCP на этапе предложения уже содержит сведения о расположении сервера PXE и программы NBP (таким образом, исключаются два этапа и экономится немного времени).

Седьмой этапКак было указано выше, у клиента есть небольшой стек протокола TFTP, с помощью которого и загружается программа NBP с сетевого ресурса, указанного сервером PXE. TFTP — это устаревший, очень небольшой протокол без сведений о состоянии. Он был выбран не за свою безопасность или производительность, и в результате многие администраторы маршрутизаторов запрещают его по умолчанию. Тем не менее, для работы PXE он должен быть включен.

Во многих реализациях протокола PXE (в том числе в службе RIS) добавлена возможность попросить пользователя в этот момент нажать для продолжения клавишу F12, но обычно администратор сервера PXE может отключить эту возможность. Когда в следующем месяце мы подробнее изучим службу WDS, я обращу ваше внимание на те усовершенствования, которые корпорация Майкрософт внесла в TFTPD (демон протокола) для увеличения его производительности в рамках службы WDS Windows Server 2008.

Восьмой этап NBP инициализирован. В случае использования службы RIS эта программа запускает загрузчик Windows, который начинает процесс развертывания. Протокол PXE (по крайней мере собственно протокол уровня загрузки) в процессе больше не участвует.

Важно помнить, что PXE (в составе службы RIS, WDS или другой инфраструктуры) плохо работает на медленных сетевых каналах (он может передавать значительные объемы данных) или на каналах с большими задержками, например спутниковых (в таких случаях обмен данными идет очень плохо и может вообще оборваться).

Вы могли обратить внимание в процессе загрузки PXE на то, что когда клиент отправляет запрос, нет ничего, что могло бы спросить: «Вы действительно моя мама?». Количество информации о состоянии, доступное серверу PXE, слушком мало, чтобы так или иначе об этом знать. Обычно возникает конфликт, который выигрывает сервер, первым отвечающий на запрос клиента. Пара приемов может помочь уменьшить эту проблему.

• Выровняйте скорости ответа серверов PXE. Задержки сети и мощность сервера влияют на время ответа сервера. В корпорации Майкрософт серверы, которыми пользуется отдел ИТ, настолько хороши, что даже если сервер PXE находится прямо в офисе, серверы корпорации иногда выигрывают. В этом случае просто настройте свой местный сервер PXE работать с вашими подготовленными клиентами с нулевым временем ожидания.
• Подготовьте клиенты. При работе с сервером PXE очень важно добиться того, чтобы ваш сервер PXE отвечал раньше серверов отдела ИТ предприятия. Путем предварительной подготовки клиентов вы даете возможность службе Active Directory® сообщить службам WDS или RIS: «да, действительно, я ваша мама». Использование идентификатора GUID SMBIOS в качестве уникального идентификатора системы в Active Directory крайне предпочтительно — однако если идентификатора GUID SMBIOS не реализован в системе (обычно потому, что используется относительно старое оборудование), вы можете (и вам придется) воспользоваться идентификатором GUID, основанном на MAC-адресе. Для получения дополнительных сведений см. статьи, приведенные на боковой панели «Подготовка клиентов».
• Не позволяйте обмену данных по протоколу PXE проходить через коммутаторы или маршрутизаторы; поставьте с каждой стороны по серверу PXE. Такое решение, правда, дорого реализовать и дорого сопровождать (на каждом сервере должен поддерживаться свой собственный образ).

Подлинность серверов службы RIS (а теперь и WDS), как и серверов DHCP корпорации Майкрософт, должна быть проверена в том экземпляре Active Directory, к которому они принадлежат. Цель этой проверки состоит в том, чтобы уменьшить проблемы, которые могут быть вызваны незаконными серверами PXE (например, «широковещательными бурями PXE»), посредством информирования служб Active Directory обо всех таких серверах.

Правда, эта защита работает только против тех серверов, о которых известно службе Active Directory. Если вы установили свой домен или сервер PXE не от корпорации Microsoft, такая защита работать не будет.

Однажды в корпорации Microsoft один чрезмерно усердный сотрудник настроил полностью автоматизированное развертывание серверов PXE, не поддерживающих службу RIS. Его реализация работала так: все содержимое жесткого диска полностью стиралось, а на это место записывался новый образ. Если бы развертывание было ограничено изолированной лабораторией, не подключенной к сети, то все было бы нормально — но, к сожалению, это было не так, и закончилось все стиранием диска одного из директоров корпорации Майкрософт, у которого загрузка с помощью протокола PXE стояла впереди загрузки с жесткого диска.

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

Пусть эта история поможет не забывать о необходимости изоляции серверов PXE, если предполагается применение полностью автоматизированного развертывания, или как минимум о требовании нажатия клавиши F12.

Служба RIS в подробностях

Я начал работать со службой RIS после того, как начала продаваться система Windows 2000. Нехватка времени тяжело сказалась на службе RIS в составе Windows 2000 — тестирование, производительность и другие ограничения привели к тому, что в Windows Server 2000 служба RIS использовалась для профессионального развертывания только системы Windows 2000 Professional. Серверные же продукты, к сожалению, не могли разворачиваться через службу RIS. Windows 2000 была доступна только для компьютеров x86, что оказалось хорошей средой для тестирования службы RIS, поскольку в ней был только один продукт только для одной архитектуры. В службе RIS имелись (и были необходимыми условиями) полная интеграция со службой Active Directory, хорошо интегрированной с сервером DHCP корпорации Майкрософт, и собственный демон TFTPD.

Cлужба RIS использовала NBP для продолжения загрузки через TFTP и передачи на сторону клиента достаточного числа компонент ядра Windows, чтобы начать процесс установки. (В определенный момент времени, когда Windows переключается с TFTPD на подключение к серверу, основанное на протоколе SMB, работает буквально та же ветвь кода, которая осуществляет установку Windows 2000 или Windows XP с дискет). Когда инициализируется исходный режим Windows, установщик Windows запускает мастер выбора операционной системы службы RIS.

Экраны мастера выбора ОС — это до некоторой степени настраиваемые страницы, похожие на HTML 2.0. Их содержимое сильно ограничено: на них не может быть изображений и даже символов не из кодировки ANSI (что усложняет развертывание некоторых языковых стандартов Windows).

Конечный результат работы службы RIS — это файл txtsetup.sif, расположенный на сервере службы RIS. Когда мастер выбора OС завершает работу, происходит «теплая» перезагрузка клиента, однако расположение сервера RIS и файла txtsetup.sif запоминается и восстанавливается после перезагрузки. По сути, файл txtsetup.sif такой же, как и unattend.txt, за исключением нескольких дополнительных полей, помогающих службе RIS выполнить процесс установки.

Служба RIS может предоставить похожую на традиционную автоматическую установку (RISetup), а также содержит инфраструктуру клонирования, похожую на Sysprep (RIPrep), с которой она даже имеет общий программный код. Но и RIPrep может передать свой образ на сервер RIS.

Однако у службы RIS есть некоторые ставшие очевидными фундаментальные ограничения. Во-первых, это отсутствие поддержки развертывания серверов. Некоторые вредоносные программы, такие как Code Red и Sasser, в сочетании с осложнениями работы отделов ИТ, наступившими после трагедии 11 сентября 2001 года, привели к тому, что мы срочно разработали решение для существующих серверов RIS на базе Windows 2000, осуществляющее развертывание Windows Server. В нем использовалось кое-что из того, что планировалось включить в состав Windows Server 2003, но что так и не было официально выпущено.

Дополнительные сведения о технологиях, связанных с PXE

• Описание взаимодействия по протоколу PXE между клиентом PXE и серверами DHCP и RIS
• Планирование развертывания операционной системы, запускаемого с помощью PXE
• Архитектура PXE
• Службы удаленной установки
• Удаленная установка операционной системы
• Поэтапное руководство по удаленной установке OC
• Поставщик PXE WDS
• Что такое службы удаленной установки?
• Автоматизированные службы развертывания Windows Server 2003.

Во вторых, служба RIS не могла полностью автоматизировать работу мастера выбора ОС, что было позже исправлено добавлением в Windows Server 2003 элемента <META ACTION="AUTOENTER">. Наконец, мастер не может нормально работать с символами, не входящими в кодировку ANSI — важный недостаток, на который указали несколько заказчиков за пределами США.

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

При выпуске Windows Server 2003 была официально добавлена поддержка архитектуры Intel Itanium и всех серверных вариантов Windows 2000 и Windows Server 2003. Следующим шагом вперед было начало поддержки архитектуры x64 в Windows Server 2003.

Был также существенно переделан демон TFTPD, входящий в состав службы RIS, в результате чего возросла его производительность. Windows Server 2003 поддерживает одновременную загрузку до 75 клиентов; верхняя граница здесь обусловлена заполнением канала SMB сетевым трафиком клиентов.

Служба развертывания Windows (WDS) — начало

Когда мы начали работать над службой RIS для «Longhorn» (кодовое имя системы, которая впоследствии стала называться Windows Server 2008), стало очевидным, что нам нужно сделать шаг назад. Как я упоминал в предыдущей статье, мы уже сделали ставки на основанную на образах (WIM) установку из Windows PE. В результате основополагающим принципом, по которому работает служба WDS, стало развертывание, основанное на образах из загружаемого по протоколу PXE экземпляра Windows PE.

Мы также знали, что Windows Server 2003 будет распространенной платформой развертывания для Windows Vista® и что нам понадобится дополнительное решение для работы службы WDS на нижнем уровне. В результате служба WDS стала работоспособной к моменту выпуска Windows Server 2003 SP1 и была встроена в Windows Server 2003 SP2.

Поскольку эта служба может работать в режиме сервера RIS (режим прежних версий), как гибридный сервер (смешанный режим) и как сервер службы WDS (собственный режим), служба WDS позволяет гарантированно перейти к стилю развертывания, основанному на WDS. Я слышал, как заказчики спрашивают о том, можно ли установить RIS на Windows Server 2003 SP2. Да, можно — установите службу и запустите ее в режиме прежних версий. На рис. 2 показаны поддерживаемые операционные системы.

Рис. 2 Платформы, развертывание на которые поддерживается

Поставка службы WDS в составе Windows Server 2003 SP1 и SP2 была направлена на то, чтобы начать переход на WDS. Как я отмечал выше, ключевыми свойствами WDS, появившимися в Windows Server 2008, являются исправленный демон TFTPD, поддержка загрузки расширяемого интерфейса микропрограмм (EFI), и, конечно же, использование многоадресной рассылки при развертывании.

Другие игроки

Службы автоматического развертывания (ADS) были разработаны другой рабочей группой внутри корпорации Microsoft. Их главной целью была быстрая подготовка серверов. В ADS используются посекторное создание образов, свой собственный загрузочный агент (меньший, чем Windows PE, но полнофункциональный), собственный демон TFTPD и очень развитая система многоадресной рассылки. Встроенная в ADS функциональность до определенной степени доступна в System Center Configuration Manager (SCCM), хотя их возможности совпадают не полностью.

В Windows XP Embedded встроена полная загрузка по протоколу PXE через свой собственный демон TFTPD на диск в ОЗУ, однако отсутствует возможность удаленного развертывания таким способом. Эта технология разработана для того, чтобы поддерживать загрузку большого количества систем с одного образа диска с помощью PXE.

Заключение

Такова история, изложенная вкратце. Для получения дополнительных сведений ознакомьтесь с панелью «Дополнительные сведения о технологиях, связанных с PXE». В следующем месяце мы в деталях разберем основы работы WDS, затем выйдет статья о расширенной функциональности WDS (многоадресные рассылки и другое) и, наконец, об использовании WDS без использования WDS — то есть переход от взаимодействия с существующими средствами WDS к разработке собственных методов развертывания.

Уэс Миллер (Wes Miller) — старший технический руководитель продуктов в CoreTrace (www.CoreTrace.com) в Остине, штат Техас. Ранее Уэс работал в компании Winternals Software, а также в корпорации Майкрософт в должности руководителя программы. Связаться с Уэсом Миллером можно по адресу technet@getwired.com.

© 2005 Корпорация Майкрософт и CMP Media LLC. Все права защищены; запрещено частичное или полное воспроизведение без специального разрешения.