Pull to refresh
78.34
Rating
Microsoft
Microsoft — мировой лидер в области ПО и ИТ-услуг

Поддержка виртуальных машин в безопасном и актуальном состоянии с помощью Microsoft Offline Virtual Machine Servicing Tool, WSUS и NAP

Microsoft corporate blog
Виртуализация становится все более распространенной технологией консолидации серверного парка. Многие организации к ее широкому применению подтолкнул кризис. По данным IDC в последнем квартале 2009 года было выпущено 350000 серверов, из которых было виртуализировано 18,2%.

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

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

Все методы, о которых я буду писать ниже, в основном относится к Windows виртуальным машинам, но частично применимы и для Linux/Unix.

Бороться с проблемой отсутствия обновлений внутри виртуальных машин можно комбинацией нескольких способов. Внедрением единой системы хранения образов развертывания виртуальных машин, например библиотеки SCVMM. В шаблонах виртуальных машин уже заранее должны быть прописаны способы автоматического обновления. Для того чтобы владелец виртуальной машины не мог отключить в ней агент обновления можно применять технологию Network Access Protection которая позволяет помещать физические и виртуальные машины в карантин если они не соответствуют политикам нашей сети. Одной из политик может быть работа в системе агента обновлений и срок последнего обновления не старше чем X дней или часов. Таким же образом можно контролировать наличие в системе антивируса, его обновления и статус и прочих необходимых нам системных процессов.

Проблему поддержания включенных виртуальных машин в обновленном состоянии эти меры решают. К сожалению, на данный момент ни WSUS, ни SCCM умеют обновлять лишь системы находящиеся во включенном состоянии. А как быть с эталонными виртуальными машинами, хранящимися в библиотеке SCVMM или машинами, находящимися на хостах Hyper-V в состоянии паузы? Обычно на сленге такие машины называются “спящими”. Они могут пребывать в таком состоянии месяцами. Все это время обновления на них не устанавливаются. В момент включения такие машины потенциально могут послужить плацдармом для атаки или распространителями эпидемии.

Для поддержания этих систем в актуальном состоянии нам как раз пригодится Microsoft Offline Virtual Machine Servicing Tool он же OVMST. Этот инструмент позволяет выполнять следующие задачи:
  • Обновлять выключенные виртуальные машины в библиотеке SCVMM.
  • Разыскивать и обновлять остановленные и спящие виртуальные машины на хостах Hyper-V.
  • Обновлять шаблоны виртуальных машин.
  • Начиная с версии 3.0 утилита Offline Virtual Machine Servicing Tool позволяет добавлять файлы обновлений в VHD файлы виртуальных жестких дисков хранящихся в библиотеке SCVMM


Чтобы понять, как работает OVSMT, давайте посмотрим на типовую архитектуру инфраструктуры необходимой для обслуживания “спящих” виртуальных машин.

OVMST_Architecture_2

Как видите в нашей инфраструктуре присутствуют библиотека и сервер SCVMM, сервер для обслуживания виртуальных машин, сервер обновлений WSUS или SССM. Стоит отметить, что все эти хосты обычно изолированы от основной сети с помощью VLAN. Доступ в основную сеть имеет только хост с SCVMM. В этом случае он является шлюзом между VLAN. Сделано это для того чтобы виртуальные машины которые мы будем обновлять не смогли подвергнуть риску основную сеть обмениваясь в ней данными в процессе установки обновлений.

OVMST_Architecture_3

Давайте пошагово посмотрим как происходит обновление виртуальных машин?

  1. Чтение данных из библиотеки SCVMM и выбор виртуальных машин, шаблонов, дисков.
  2. Поиск «спящих» виртуальных машин на хостах Hyper-V подключенных к SCVMM.
  3. Создание групп обслуживания и помещение в них виртуалных машин, шаблонов дисков собраных на первом и втором шагах.
  4. Перенос «спящих» виртуальных машин с хостов Hyper-V или развертывание их из шаблонов хранящихся в библиотеке SCVMM на хостах Hyper-V предназначенных для обновления гостевых ОС.
  5. Пробуждение или включение обновляемых машин на обслуживающем хосте Hyper-V.
  6. Принудительная проверка обновлений необходимых виртуальной машине.
  7. Применение обновлений к виртуальной машине.
  8. Проверка статуса обновлений.
  9. Выключение виртуальной машины, при необходимости подготовка к помещению ее обратно в библиотеку SCVMM с помощь sysprep.
  10. Возвращение вирт. машины на хост где она первоначально находилась или помещение ее в библиотеку откуда мы ее взяли


Итак мы разбрались в механизмах работы OVMST пошаговый алгоритм настройки этого коплекса я опишу в следующей части статьи, а пока вы можете ознакомиться с вебкастом об OVMST.
Tags:
Hubs:
Total votes 37: ↑22 and ↓15 +7
Views 8K
Comments 5
Comments Comments 5

Information

Founded
Location
США
Website
www.microsoft.com
Employees
Unknown
Registered