Программное обеспечение виртуальные машины лекция
Виртуальные машины
Виртуальная машина – это программа, которая эмулирует реальный (физический) компьютер со всеми его компонентами (жёсткий диск, привод,BIOS, сетевые адаптеры и т.д.). На такой виртуальный компьютер можно установить, например, операционную систему, драйверы, программы и т.д. Таким образом, Вы можете запустить на своем реальном компьютере еще несколько виртуальных компьютеров с такой же или другой операционной системой. Вы можете без проблем осуществить обмен данными между вашим реальным и виртуальным компьютером.
Почему необходимо применять средства виртуализации
Средства виртуализации позволяют решать самые разные задачи, в том числе возникающие перед специалистами по тестированию и обеспечению качества разрабатываемых программных приложений.
Кроме того, применение виртуальных машин (вместо физических) дает компаниям-разработчикам ряд существенных преимуществ.
Во-первых, с помощью виртуальных машин можно выполнять сравнительное тестирование разрабатываемых программных приложений на разных машинах с разными аппаратными конфигурациями. Например, управлять размером дискового пространства или оперативной памяти, ограничивать доступ к конкретным сетевым ресурсам. При этом материальные затраты на приобретение, обслуживание и обновление компьютерного «железа» фактически исключаются.
С другой стороны, сразу несколько тестировщиков могут получить в распоряжение уже заранее подготовленную тестовую машину с установленной ОС и настроенной программной средой (включая, например, локальныйSQL-сервер для построения и обслуживания баз данных, которые используются в работе тестируемого ПО).
Кроме того, виртуальные машины предоставляют удобные возможности по созданию конкретного специфического окружения, необходимого для исследования разрабатываемого ПО. Можно свободно варьировать специфичные региональные настройки и настраивать локализацию пользователей. И при этом исследователь может легко экспериментировать с настройками среды, без влияния на конфигурацию и работоспособность собственной физической машины.
Например, можно создать такую же среду, какая настроена и на стороне конечного пользователя (клиента), для имитации его работы с приложением. Допустим, Вы разрабатываете приложение в России, а клиент будет использовать его в другой стране. Зачастую это оказывает влияние на поведение приложения, значит, просто необходимо принимать во внимание все «национальные особенности».
Технологии виртуализации сейчас применяются во многих сферах ИТ как в производственной среде, так и энтузиастами и домашними пользователями для самых разных задач. Несколько одновременно запущенных виртуальных систем на одной физической машине существенно повышают гибкость ИТ-инфраструктуры и увеличивают эффективность использования аппаратных ресурсов. Тестирование программного обеспечения – один из самых распространенных вариантов использования для платформ виртуализации. Неудивительно, ведь виртуальные машины обладают множеством полезных свойств, благодаря которым значительно сокращается время разработки и тестирования и повышается эффективность этих процессов.
В классической модели разработки программного обеспечения программистам и инженерам по качеству ПО большую часть времени приходилось испытывать программный продукт на одной платформе на протяжении практически всего времени разработки и лишь в конце проводить его тестирование в различных ОС и пользовательских средах (так называемое тестирование конфигураций, Configurations Testing). К тому же, в распоряжении сотрудников отделов тестирования и разработчиков находилось не так много физических компьютеров, а на одной машине, в одной операционной системе нельзя, например, поставить одновременно несколько версий одного программного продукта, с которым должна взаимодействовать разрабатываемая программа. Вследствие этого, в программном обеспечении, особенно небольших команд разработчиков, часто встречались ошибки, связанные с особенностями пользовательских конфигураций, поскольку времени и ресурсов на полноценное конфигурационное тестирование не хватало. Кроме того, инженерам по качеству приходилось тратить много времени на развертывание комплекса программных продуктов на тестовых стендах и настройку их работы в сетевой инфраструктуре.
Безусловно, одной из самых серьезных проблем при разработке ПО является тот факт, что на ранних этапах разработки и сборки программного продукта разработчики, в процессе своей работы, могут причинить непоправимый вред системе (например, различные драйвера устройств). Поэтому приходится планировать восстановление операционных систем и их настроек после сбоев из резервных копий и тратить значительное время на их восстановление.
Надо отметить еще одну проблему, которая довольно часто встречается при разработке программного обеспечения и заставляет потратить значительное время на ее решение. Всем программистам, имеющим опыт взаимодействия с командами тестирования, известна следующая ситуация: в системе багтрекинга тестировщик фиксирует дефект, который программисту никак не удается повторить. После того, как программист ставит статус проблемы как решенный, тестировщик зовет его к своей машине и наглядно демонстрирует ошибку. В этой ситуации доходит до того, что программисту приходится установить на машину тестировщика множество отладчиков и прочей ненужной ерунды и «отлавливать» дефект, полностью останавливая работу тестировщика. Если к этому прибавить время на удаление тестировщиком программистских утилит, получаются серьезные потери времени команды.
В заключение перечисления списка проблем, возникающих в процессе разработки и тестирования, нужно привести еще одну. Зачастую складывается такая ситуация, когда требуется проверка сборки программного продукта «на дым» (так называемое дымовое тестирование, Smoke Testing), что означает быстрый прогон наиболее важных тестов. Но что если мы разрабатываем приложение, для которого требуются различные версии Internet Explorer? В этом случае будет тратиться много времени на загрузку подходящей системы, где установлена требуемая версия.
Суммируя описанные ситуации, обобщим проблемы, которые часто встречаются в процессе разработки и тестирования программных продуктов:
Если подсчитать, сколько времени и ресурсов тратится на решение этих проблем, то получится весьма и весьма внушительная цифра, которая, будучи выраженной в денежном эквиваленте, составляет довольно большую часть бюджета проекта.
Технологии виртуализации, грамотно примененные в процессе разработки и тестирования, могут существенно снизить трудозатраты и значительно повысить эффективность процесса, что положительно скажется на качестве выпущенного программного продукта. Как конкретно виртуализация позволяет это сделать:
Все перечисленные решения нужно рассматривать в ракурсе того факта, что виртуальная машина (с установленным в ней программным обеспечением) представляет собой весьма гибкий объект, который может быть как быстро развернут на клиентских машинах из централизованного хранилища шаблонов пользовательских конфигураций, так и максимально гибко настроен в отношении параметров гостевой системы и ее окружения. Легкая переносимость на другое оборудование и независимость от аппаратной платформы – ключевое достоинство виртуальных машин.
Инструменты виртуальных машин для тестирования и разработки
Внедряя виртуальную инфраструктуру для целей разработки и тестирования ПО, необходимо, прежде всего, выбрать наиболее подходящую, надежную и эффективную платформу виртуализации, удовлетворяющую всем требованиям к процессу разработки в организации. Есть два наиболее распространенных пути использования виртуальных машин для тестирования программных продуктов:
Неуправляемое развертывание виртуальных машин на клиентских машинах или серверах тестирования, при котором либо сами тестировщики создают необходимые им конфигурации, либо копируют шаблоны виртуальных систем на свои компьютеры из центральной библиотеки виртуальных шаблонов (файлового сервера). Преимущество данного подхода – дешевизна решения, можно воспользоваться одной из многих бесплатных систем виртуализации (VMware Server, Virtual PC, VirtualBox и другие). Основные недостатки – стихийное развертывание виртуальных машин порождает конфликты в сетевой инфраструктуре, отсутствие контроля над использованием лицензий на операционные системы и прикладное ПО, невозможность интеграции в существующую ИТ-среду организации.
Управляемое развертывание достоинствам данного подхода надо отнести возможность разрешения конфликтов между виртуальными и физическими системами в сети, контроль использования лицензий, возможность мониторинга использования виртуальной инфраструктуры и создания общего пространства между различными участниками процесса разработки и тестирования, интеграция в реальную ИТ-инфраструктуру предприятия. Основной недостаток данного подхода – высокая стоимость решений. Примеры продуктов, обеспечивающих управляемое развертывание виртуальных машин: VMware LabManager, VMLogix LabManager, Microsoft System Center Virtual Machine Manager.
Инструменты для разработки и тестирования при неуправляемом развертывании
Платформы виртуализации, коих на рынке сейчас большое количество, развиваются стремительными темпами и предоставляют пользователям все больший набор инструментов для повышения эффективности процесса разработки и тестирования. Для решения каждой из перечисленных проблем платформы виртуализации различных вендоров имеют свои средства, позволяющие пользователям эффективно тестировать программные продукты в виртуальных машинах:
Создание множества пользовательских конфигураций. При наличии большого объема свободного дискового пространства на машине тестировщика с помощью платформы виртуализации можно создать неограниченное число виртуальных систем, каждая из которых может быть загружена по требованию, без остановки рабочей деятельности работника в хостовой системе. Виртуальные машины могут также применяться на специализированных серверах тестирования на основе платформ VMware ESX Server, XenEnterprise или Virtual Iron. При этом могут быть назначены определенные права пользователям виртуальных систем, а также ограничены физические ресурсы сервера, которые могут быть использованы конкретным пользователем. На файловом сервере с виртуальными шаблонами могут храниться предустановленные виртуальные машины, которые развертываются на сервера тестирования или рабочие станции. В этом случае нужно учитывать особенности использования виртуальных машин в соответствии с лицензией. В большинстве случаев каждая виртуальная машина требует отдельной лицензии, однако есть и исключения, например, лицензия Windows Server 2003 Datacenter Edition позволяет запускать неограниченное число виртуальных экземпляров ОС.
Если настроенное тестовое окружение уже развернуто на физической машине, его можно мигрировать на виртуальную с помощью продуктов вендоров платформ виртуализации и сторонних разработчиков. К таким решениям относятся продукты PlateSpin PowerConvert, VMware Converter, Microsoft Migration Toolkit.
Создание многомашинных конфигураций на одном физическом сервере.
Платформы виртуализации, ориентированные на тестирование ПО (VMware Workstation, Virtual PC, VirtualBox, Xen), позволяют создавать целые виртуальные инфраструктуры с различными типами сетевого взаимодействия в пределах одного физического хоста. Например, можно создать несколько «блоков» из виртуальных серверов (сервер баз данных, сервер приложений, окружение клиента), настроить сетевые адаптеры виртуальных машин (у одной машины их может быть несколько, в VMware Workstation – до десяти) и запустить тестируемую связку серверов. При этом платформы виртуализации позволяют подключать сетевые адаптеры виртуальных машин к различным сегментам виртуальной сети.
После того, как тестовая виртуальная инфраструктура будет создана, можно настроить параметры каналов связи между виртуальными машинами.
Нужно отметить, что виртуальные сети не на всех платформах виртуализации являются портируемыми и иногда требуется их повторная настройка при перенесении виртуальных машин на другое оборудование:
Резервное копирование виртуальных машин при тестировании.
Если тестировщики используют виртуальные машины на своих рабочих станциях, то они могут создавать их резервные копии путем копирования папки с файлами виртуальной машины. В случае краха системы, сохраненную копию не надо восстанавливать – она уже полностью готова к работе. К тому же, многие платформы виртуализации позволяют создавать несколько снимков состояния виртуальной машины, откат к каждому из которых может быть произведен за несколько минут.
Если тестирование производится на выделенных серверах тестирования, то для создания резервных копий виртуальных машин могут применяться специализированные решения вендоров платформ виртуализации, такие как vRanger Pro компании Vizioncore, VMware Consolidated Backup (VCB) или еще не выпущенное решение Microsoft Data Protection Manager для Virtual Server 2005 R2, которые позволяют создавать резервные копии виртуальных машин без их остановки.
Демонстрация дефектов разработчикам.
При нахождении дефекта тестировщик может просто сохранить состояние системы, в котором проявляется ошибка, в снапшоте и продолжить тестирование системы. При необходимости демонстрации дефекта, виртуальная машина может быть передана разработчику, который сможет работать с ней, не боясь повредить окружение тестировщика. Кроме того, на платформе VMware Workstation виртуальные машины могут действовать как VNC-серверы, без необходимости установки дополнительного ПО для удаленного доступа к рабочему столу.
Гибкая настройка аппаратной среды.
Зачастую при тестировании программного обеспечения требуется большая гибкость в отношении настройки аппаратных компонентов. Например, при стрессовом тестировании (Stress Testing) требуется проверка работы программного продукта в экстремальных или ограниченных условиях (нехватка дискового пространства, обрыв сетевого соединения). В этом случае, с помощью платформы виртуализации виртуальной машине можно добавить новые виртуальные устройства или ограничить выделяемые ей ресурсы.
При этом, если мы добавляем виртуальный диск в гостевой системе, можно создать его как динамически расширяемый, что позволяет экономить свободное место на диске, а также создать так называемые Undo-диски, изменения которых действуют только во время работы с виртуальной машиной и при завершении сеанса могут быть отменены, что очень удобно для тестирования.
Что касается контроля ресурсов, многие платформы виртуализации позволяют ограничивать ресурсы виртуальной машины или пула ресурсов виртуальных машин, что позволяет моделировать реальные условия пользовательских окружений.
Современные платформы виртуализации поддерживают стандарт USB 2.0, большое количество виртуальных сетевых адаптеров в виртуальной машине, эмуляцию SCSI-дисков, а также представление различного числа процессоров в гостевой системе посредством виртуального SMP (Symmetric Multi Processing):
Инструменты для разработки и тестирования при неуправляемом развертывании
В данный момент, наиболее популярными решениями для управляемого развертывания виртуальной тестовой инфраструктуры являются продукты VMware LabManager (для платформы ESX Server) и VMLogix LabManager (для платформ Microsoft, VMware и XenSource).
Тестовые лаборатории VMware LabManager
Компания VMware предлагает крупным компаниям использовать виртуальную тестовую инфраструктуру на основе решения LabManager (бывшая разработка поглощенной компании Akimbi), которое позволяет максимально быстро развертывать виртуальные машины на серверах тестирования и контролировать использование виртуальных систем, при этом процесс выглядит так, будто пользователь работает с физическим компьютером. Модель работы виртуальной лаборатории представлена на Рис. 11.6:
Помимо всех перечисленных достоинств систем управления виртуальными лабораториями, VMware LabManager предоставляет интеграцию с популярными средствами тестирования Borland SilkCentral Test Manager и HP Quality Center, имеет возможности для развертывания шаблонов в несколько кликов мыши, поддерживает протокол LDAP, легко интегрируется с другими решениями для виртуальной инфраструктуры VMware и имеет возможности для автоматизации операций посредством собственного API (Application Program Interface). Основной недостаток этого продукта – возможность обслуживания виртуальных серверов только на платформах VMware.
Тестовые лаборатории VMLogix LabManager
В отличие от решения компании VMware, продукт VMLogix LabManager поддерживает платформы виртуализации различных вендоров. В качестве основы виртуальной тестовой лаборатории можно использовать платформы Microsoft (Virtual Server), Xen (XenEnterprise) и VMware (ESX Server и Server). Кроме того, LabManager компании VMLogix поддерживает обслуживание физических серверов организации. Архитектура решения VMLogix LabManager представлена на Рис. 11.7.:
LabManager предоставляет пользователям портал самообслуживания, с помощью которого пользователи могут развертывать виртуальные машины из централизованной библиотеки шаблонов и ISO-образов операционных систем, а также имеет возможности управления лицензиями, настройки зон назначаемых IP-адресов и возможности аудита безопасности виртуальной тестовой инфраструктуры. Кроме того, VMLogix LabManager также имеет средства автоматизации операций посредством программного интерфейса API, возможности по развертыванию и обслуживанию многомашинных конфигураций и функции для демонстрации проблемных ситуаций путем предоставления общего доступа к снимкам состояния виртуальных машин.
Заключение
Модель организации процесса разработки и тестирования с помощью виртуальных машин позволяет существенно снизить затраты на развертывание тестовых пользовательских окружений и конфигурацию тестовых сред. По статистике, при тестировании программных продуктов на физических серверах и рабочих станциях, на эти задачи уходит до 50 процентов времени команды тестирования. Виртуальные машины на платформах различных вендоров позволяют сократить это время в несколько раз, до 5% от общих затрат на тестирование. Повышенная гибкость виртуальных систем и их независимость от оборудования позволяют работать с ними, как с некими блоками, из которых строится виртуальная тестовая инфраструктура компании. Возможность предоставления общего доступа к найденным дефектам участникам команды разработки и пользователям продукта позволяет существенно ускорить поиск и исправление ошибок. Во многих компаниях уже стало стандартом де-факто тестирование с помощью виртуальных машин.
Технологии виртуализации
Одной из наиболее существенных технологических новаций, лежащих в основе облачных вычислений, являются технологии виртуализации.
Виртуализация – предоставление набора вычислительных ресурсов или их логического объединения, абстрагированное от аппаратной реализации, и обеспечивающее при этом логическую изоляцию вычислительных процессов, выполняемых на одном физическом ресурсе.
Основные понятия технологии виртуализации
Виртуальная машина – изолированный программный контейнер, который работает с собственной ОС и приложениями, подобно физическому компьютеру. Виртуальная машина действует так же, как физический компьютер, и содержит собственные виртуальные ОЗУ, жесткий диск и сетевой адаптер.
Виртуальная машина представляет собой программный контейнер, связывающий, или «инкапсулирующий» полный комплект виртуальных аппаратных ресурсов, а также ОС и все ее приложения в программном пакете.
Основными особенностями виртуальных машин являются: совместимость (виртуальные машины совместимы со всеми стандартными компьютерами, виртуальная машина работает под управлением собственной гостевой оперативной системы и выполняет собственные приложения); изолированность (виртуальные машины полностью изолированы друг от друга, как если бы они были физическими компьютерами); инкапсуляция (виртуальные машины полностью инкапсулируют вычислительную среду).
Виртуальные машины полностью независимы от базового физического оборудования, на котором они работают.
Хостовая операционная система – это операционная система, установленная на реальное оборудование. В рамках этой операционной системы устанавливается программное обеспечение виртуализации как обычное приложение.
Эмулятор виртуальной машины – это программное обеспечение, устанавливаемое на хостовую операционную систему и состоящее из монитора виртуальных машин и графической оболочки.
Монитор виртуальных машин представляет собой программу, обеспечивающую все взаимодействия между виртуальным и реальным оборудованием, поддерживающую работу одной или нескольких созданных виртуальных машин и установленных гостевых операционных систем. Графическая оболочка обеспечивает взаимодействие пользователя с приложением виртуальной машины, позволяя настраивать создаваемые виртуальные машины под свои нужды и управлять ее работой.
Гостевая операционная система – это операционная система, устанавливаемая на созданную виртуальную машину. В качестве гостевых операционных систем можно использовать Window, Linux и др.
При использовании технологии виртуализации получают иерархическую структуру взаимодействия виртуальных ЭВМ и реальной аппаратуры. На нижнем слое этой иерархии находится реальное оборудование, управление которым распределяется между хостовой операционной системой и эмулятором виртуальных машин.
Хостовая операционная система и эмулятор распределяют между собой ресурсы реальной ЭВМ и составляют второй уровень иерархии. Хостовая операционная система занимается управлением работающих на ней приложений и распределением между ними ресурсов реальной ЭВМ.
Эмулятор виртуальных машин управляет виртуальными машинами с установленными на них гостевыми операционными системами, распределяя между ними ресурсы реальной ЭВМ так, чтобы у пользователей создавалось впечатление работы на реальном оборудовании
Частично, распределение ресурсов между виртуальными машинами можно настроить на этапе конфигурации виртуальных машин, указав объем оперативной памяти, размер жесткого диска, количество виртуальных процессоров, виртуализируемые каналы связи и другие параметры.
Гостевые операционные системы управляют работой своих приложений в рамках выделенных эмулятором ресурсов.
Рассматривая технологию виртуализации, необходимо изучить эмулятор виртуальных машин, а именно монитор виртуальных машин, являющийся базовой частью технологии виртуализации.
Все существующие мониторы виртуальных машин можно разделить на четыре вида, использующие: аппаратную, аппаратно-программную, программную и доменную виртуализации. Это разделение – условно, поскольку большинство мониторов виртуальных машин используют, как программную, так и аппаратную виртуализацию, так как программная виртуализация – требовательна к ресурсам, а аппаратная виртуализация ограничивается узким кругом оборудования, поддерживающей какой-либо вид мониторов виртуальных машин.
Доменная виртуализация основывается на логическом распределении ресурсов на отдельные части (домены). В основном она используется в мэйнфреймах. Этот тип виртуализации появился первым и использовался для распределения ресурсов больших ЭВМ между отдельными пользователями.
Мониторы виртуальных машин, использующие технологию аппаратно-программной виртуализации, часть инструкций выполняют, непосредственно, на самом процессоре, а часть – эмулируют.
Существуют три типа программной эмуляции инструкций: полная эмуляция инструкций, выборочная эмуляция инструкций, эмуляция API.
При использовании полной эмуляции инструкции интерпретируются и преобразуются в инструкции, воспринимаемые реальным процессором. В этом случае появляется возможность создавать виртуальные машины, имитирующие работу аппаратуры, не совместимой по архитектуре с реальной ЭВМ. Например, можно запускать виртуальную машину, имитирующую работу процессора с RISC-архитектурой, на реальной ЭВМ с процессором CISC-архитектуры. Это возможно за счет того, что эмуляция ведется на уровне базовых арифметико-логических инструкций, присутствующих, практически, в любом процессоре.
Интерпретация каждой инструкции приводит к значительному расходу ресурсов реальной ЭВМ и снижает быстродействие приложений, работающих в гостевой операционной системе. Современные серверы и персональные ЭВМ обладают все большей производительностью. Поэтому виртуализация, с использованием интерпретации инструкций, приобретает популярность. Представителями данного класса виртуальных машин являются: Microsoft Virtual PC, Bochs, Simics и др.
Такие виртуальные машины являются незаменимыми при отладке и разработке программного обеспечения, написанного на языках низкого уровня, и при эмуляции ЭВМ со специфической архитектурой на стандартизированные персональные компьютеры и серверы.
Не все инструкции необходимо интерпретировать. Часть инструкций виртуальной машины можно выполнять без изменений на реальном процессоре. Монитор виртуальных машин, проанализировав код, может инструкции виртуальной машины, совпавшие с инструкциями реального процессора, без изменений отправить для выполнения на реальном процессоре, а остальные инструкции интерпретировать.
Появляются дополнительные расходы на анализ инструкций. Поскольку в программах часто встречаются циклы, интерпретация которых может производиться однократно, и наиболее простые инструкции, способные без изменения выполняться на процессоре составляют большую часть программ, то производительность виртуальной машины увеличивается в несколько раз, по сравнению с полной эмуляцией инструкций.
К виртуальным машинам этого типа относятся, например: VMware Workstation, VMware Server, Serenity Virtual Station и др.
В третьем случае, эмулируются API гостевой операционной системы. API (Application Programming Interface) – это интерфейс прикладного программирования.
Все работающие программы взаимодействуют с оборудованием при помощи интерфейса API. Поэтому можно перехватить обращение программ, работающих под управлением гостевой операционной системы, к API, преобразовать его к виду, принятому в хостовой операционной системе, и ретранслировать полученный результат к API хостовой операционной системы.
Результат выполнения запроса хостовой операционной системой преобразуется к виду, воспринимаемому гостевой операционной системой, и передается программе, выдавшей запрос.
Если гостевая и хостовая операционные системы совместимы по своим API, то преобразовывать обращения не нужно, достаточно только перенаправлять их.
Однако у такой системы виртуализации есть недостатки:
Однако использование эмуляции API позволяет избежать значительных потерь производительности.
В качестве примера виртуальных машин, использующих эмуляцию API, можно привести такие продукты, как:
Безопасность в виртуальных облаках
Виртуализация – это переход от технологии, лежащей в основе консолидации серверов и центров обработки данных, к основным компонентам для создания гибкой предоставляемой по требованию инфраструктуры. При реализации виртуализации в любой среде возникает много задач, которые надо решить.
Рассмотрим вопросы, связанные с безопасностью, которые необходимо решить, когда речь идет об использовании виртуализации для облачных вычислений.
Один из рисков – риск компрометации гипервизора виртуальных машин. Если гипервизор ненадежен, то он станет первой целью злоумышленников. Если не устранить эту опасность, то в облаке атака может привести к масштабным разрушениям. Это требует дополнительного уровня изоляции сети и усиленной системы мониторинга безопасности.
Для анализа этой опасности попытаемся для начала понять природу гипервизора. Консультант по безопасности и одного из основателей компании Nemertes Research Group Inc. Андреаса Антонопулоса (Andreas Antonopoulos) считает, что «Гипервизоры – узкоспециализированные устройства. Обычный гипервизор меньше и более специализирован, чем операционная система общего назначения, и меньше открыт для атак, так как у него меньше или вообще нет открытых во вне сетевых портов. Гипервизор нечасто меняется и не выполняет приложения сторонних разработчиков. У гостевой ОС, которая может стать жертвой атак, нет прямого доступа к гипервизору. Гипервизор прозрачен для сетевого трафика, если не считать входящий и исходящий трафик выделенного интерфейса управления гипервизором. На настоящий момент не задокументировано ни одной атаки на гипервизоры, что говорит о низкой вероятности таких атак. Поэтому хотя масштаб разрушений в случае компрометации гипервизора может быть огромным (компрометация всех гостевых систем), вероятность такого события низка, потому что уязвимость гипервизора и вероятность атаки очень низкие».
Другой риск для безопасности в области виртуализации заключается в том, как выделяются и освобождаются такие ресурсы, как локальные хранилища, относящиеся к виртуальным машинам. В процессе развертывания и работы виртуальной машины данные записываются в физическую память. Если память не освобождается перед передачей ее следующей виртуальной машине, то существует возможность компрометации данных.
Поэтому необходимо контролировать использование ресурсов хранения и памяти при работе в общедоступном облаке. Необходимо очищать данные, аккуратно работать с конфиденциальными данными и уделять внимание управлению доступом и привилегиями, проверять очистку ресурса после его освобождения.
Еще один риск, связанный с виртуализацией, заключается в возможности незамеченных сетевых атак между виртуальными машинами, расположенными на одном физическом сервере.
Существует несколько способов решения этой проблемы. Во-первых, пользователь виртуальной машины может включить в ОС фильтрацию трафика или локальный брандмауэр.
По существу механизм виртуализации сети должен предоставлять виртуальной машине соответствующий сетевой интерфейс. Этот интерфейс может представлять мультиплексный канал, в котором коммутация и маршрутизация выполняется оборудованием сетевой связи.
Большинство полнофункциональных гипервизоров содержит виртуальные коммутаторы и брандмауэры, которые располагаются между физическими интерфейсами сервера и виртуальными интерфейсами виртуальных машин. Всей этой системой надо управлять, отслеживая изменения в месторасположении виртуальных машин и возможных путях коммуникации между ними.
Еще один теоретически возможный метод ограничения трафика между виртуальными машинами – сегрегация машины путем объединения их в классы, которые изолируются друг от друга. В процессе жизненного цикла виртуальной машины всегда должен быть известен ее владелец. На физических серверах возможно совместное размещение только тех машин, которые отвечают требованиям к совместному размещению на сервере.
При таком подходе может использоваться одна из форм маркировки, подобно той, что применяется в многоуровневых ОС (Trusted Solaris или SE-Linux). Можно также использовать базу данных управления конфигурацией для отслеживания запросов арендаторов на изоляцию приложений.
Билл Майне (Bill Meine), архитектор ПО и специалист по облакам в компании Blackhawk Network отмечает, что во всех этих примерах проблемы возникают, когда арендатору также требуется максимальная защита компонентов приложения от отказов по стандартным причинам, например, из-за необходимости высокой доступности. Дело не в том, что такую схему нельзя заставить работать, а в стоимости всех несовместимых и недогруженных фрагментов сервера (которые нельзя продать), которую приходится учитывать в цене сервиса.
Один из практических способов управления трафиком между виртуальными машинами заключается в использовании виртуальных ЛВС для изоляции трафика виртуальных машин, принадлежащих разным клиентам. Но чтобы такой подход был эффективным, нужно распространить поддержку виртуальных ЛВС за пределы основной инфраструктуры коммутации вплоть до физических серверов, на которых располагаются гостевые системы. Такая поддержка используется практически повсеместно при использовании виртуализации.
Следующая проблема заключается в масштабировании функциональности виртуальных ЛВС за пределы существующих границ для поддержки больших по размеру облаков.