Обновление спящих виртуальных машин

Ненавидите ли вы применение исправлений? Я – да. Внесение исправлений всегда казалось неблагодарной работой, причем усугублял ситуацию тот пренеприятный факт, что в этой операции нет никакой бизнес-ценности. Ну, точнее в этом нет никакой другой ценности для бизнеса кроме знания, что, вероятно, удалось избежать какой-то неизвестной проблемы в будущем.

Нет, внесение исправлений давно стало тягомотной рутиной айтишников. Будучи основной причиной торчания на работе до позднего вечера или даже ночи, а также в свободное время, и звонков типа: «Прости, милая, я не приеду домой на обед», исправление и управление процессом исправления стали деятельностью, которую мы все так любим ругать.

Тем не менее сейчас ситуация с управлением исправлениями уже не столь плоха, как это было раньше. До недавнего времени, чтобы четко отслеживать исправления, приходилось поддерживать огромные «портянки» электронных таблиц, связывая каждое исправление с его MS- и q-номерами, критичностью с точки зрения Microsoft и собственными корпоративными приоритетами. Отслеживание правильного порядка применения исправлений занимало каждый месяц не менее половины дня.

Ситуация сильно поменялась с выпуском службы Windows Server Update Services (WSUS). Этот простой, но изумительно экономящий время инструмент взял на себя большую часть ручной работы по внесению исправлений. Добавив к WSUS специальный сценарий, можно добиться применения к компьютеру исправлений немедленно, не дожидаясь следующего запланированного цикла. (У меня все еще есть этот сценарий. Зайдите на сайт concentratedtech.com, если он вам нужен.)

У WSUS есть одно ограничение – автоматизированные механизмы исправлений работают, только когда обновляемые серверы или рабочие компьютеры включены. Компьютеры, отключаемые по каким-либо причинам, были недосягаемы для WSUS. Требовалось следить, чтобы цикл применения исправлений происходил немедленно на следующее утро после включения компьютера, или появлялась дополнительная работа для администраторов, которые должны были обнаруживать и включать компьютеры заранее ночью перед этим.

Теперь-то мы знаем, что это ограничение WSUS не так уж страшно. Если пользователи оставляют свои компьютеры выключенными во время вечернего цикла исправления, они увидят на следующее утро после включения компьютера всплывающее уведомление, и начнется установка исправлений. Сегодня серверы обычно включены постоянно. Это означает, что они всегда и доступны для получения команд от WSUS.

Ситуация меняется

Такая красивая и удобная статическая картина снова меняется, когда центры данных переходят к виртуализации. Виртуализованные серверы, скорее всего, останутся включенными постоянно. Но виртуальные серверы не появляются ниоткуда – в подавляющем большинстве они создаются путем клонирования шаблонного сервера.

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

Шаблон сервера обычно существует в виде VHD-файла где-нибудь на общем файловом ресурсе. Будучи выключенным этот файл безобиден, как какой-нибудь не открытый большой файл Word или электронная таблица Excel. При включении этот файл становится полнофункциональным сервером, который может обрабатывать рабочие задачи… или задачи современного вредоносного ПО и другие небезопасные программы.

Короче говоря, если на «спящие» шаблоны не установить исправления, они могут стать источником вспышки заражения новым вредоносным ПО – только из-за того, что их просто включили.

Уже теплее? Отлично! Потому как это главная «фишка» утилиты Microsoft Offline Virtual Machine Servicing Tool, существующей в настоящее время в версии 2.1. Эта бесплатная утилита устанавливает набор средств автоматизации, предназначенных для поддержания «спящих» шаблонов виртуальных машин в актуальном состоянии по стандартам WSUS.

Рис. 1  Три основных компонента обслуживания отключенных виртуальных машин.

Чтобы понять, как это работает, обратитесь к рис. 1, где показано, как сервер с System Center Virtual Machine Manager (VMM) взаимодействует с одной из общих папок с библиотеками, хостом Hyper-V и локальным сервером управления обновлениями программного обеспечения. В качестве последнего может выступать WSUS- или SCCM-сервер (System Center Configuration Manager) – в любом случае процессы практически идентичны.

Утилита Offline VM Servicing Tool управляет развертыванием обновлений виртуальных машин в библиотеке VMM, используя то, что называется заданиями обслуживания. Это, в сущности, задания, обрабатываемые планировщиком Windows, которые запускаются в заданное время.

Задание обслуживания начинает с «пробуждения» виртуальной машины из ее «шаблонного» местоположения. Процесс пробуждения состоит из развертывания виртуальной машины на хосте Hyper-V и ее включения. После включения внутренний Агент обновления Windows (WUA) виртуальной машины принуждается к началу цикла обновления программного обеспечения.

Конфигурация WUA на виртуальных машинах задается так же, как обычно определяется на всех офисных компьютерах, например через применение групповой политики или путем ручной настройки конфигурации на самой виртуальной машине. Чтобы этот процесс работал, надо задать все стандартные параметры WSUS, такие как местоположение службы обновления, WSUS-группы компьютеров, а также любые другие параметры, предусмотренные вашей политикой безопасности.

Успешно обновив виртуальную машину, задание обслуживания выключает ее и возвращает в библиотеку. Этот автоматизированный процесс гарантирует, что на всех виртуальны машинах – как и на всех остальных компонентах инфраструктуры – устанавливаются все необходимые исправления. Утилита Offline VM Servicing Tool не добавляет никаких собственных конфигурационных параметров управления обновлением, а полагается на уже имеющиеся параметры WSUS или SCCM.

Вообще говоря, установка утилиты Offline VM Servicing Tool требует выполнения нескольких операций, которые не совсем очевидны для тех, кто не читал документацию. Даже в версии 2.1 эта утилита кажется сыроватой. Для ее установки надо загрузить консоль с веб-узла Microsoft. Для запуска необходимо загрузить и скопировать двоичные файлы PSExec — both psexec.exe и pdh.dll — в папку корзины средства, которая находится по адресу C:\Program Files\Microsoft Offline Virtual Machine Servicing Tool\bin. Утилите также нужно, чтобы политика выполнения Windows PowerShell была сконфигурирована как RemoteSigned.

Рис. 2  Консоль утилиты Offline VM Servicing Tool.

Будучи установленной, консоль (рис. 2) содержит только раздел Virtual Machine Groups – группы виртуальных машин, в которых можно определить, когда и на какие машины должны устанавливаться исправления. Есть также раздел Servicing Jobs, содержащий параметры задач обслуживания, ответственных за обновление. Утилита работает только с виртуальными машинами, содержащимися в вашей библиотеке VMM. Это означает, что утилита не работает с выключенными виртуальными машинами, которые уже развернуты на хосте Hyper-V.

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

Утилита Microsoft Offline Virtual Machine Servicing Tool не может служить единственным решением всех ваших задач по обновлению выключенных виртуальных машин, но ее невысокая цена и ограниченные возможности пригодятся в ситуациях, когда требуется только обновлять несколько бездействующих виртуальных машин. Осознав сложность выполнения этой задачи вручную, а также возможные неприятности из-за пропущенного исправления, вы поймете, насколько важно контролировать эти бездействующие, но потенциально опасные виртуальные машины.