Сегодня более 25% крупных предприятий уже внедрили у себя серверные виртуализационные решения, а еще 10% предприятий ведут пилотные проекты в этом направлении. Наряду с этим основные ИТ-компании интенсивно работают над решениями для виртуализации настольных систем, которые скоро найдут практическое применение. Очевидно, что «виртуализация» прикладного и системного ПО кардинально изменит подходы и методы обеспечения ИТ-безопасности, принципы лицензирования ПО и методы администрирования.
Виртуализация серверов, применяемая сегодня, позволяет кардинально снизить затраты на оборудование, одновременно обеспечить более высокий уровень защиты и резервирования критических функций, а главное — дает возможность масштабировать и переносить настроенные и проверенные решения между физическими серверами за время, недостижимое без использования виртуализационных технологий. Виртуализация настольной системы для пользователей будет еще заметней и, например, позволит компаниям отказаться от централизованных закупок компьютеров для персонала, сведя ИТ-менеджмент рабочих мест к выдаче грантов определенного объема служащим для покупки собственного компьютера с заданными параметрами по совместимости и производительности, а также раздаче виртуализированных образов ОС с предустановленным и настроенным рабочим ПО. С точки зрения пользователя виртуализация изменит не только и не сколько само ПО или оборудование, а методику и культуру использования ПО, подходы к вопросам безопасности и установке «несанкционированного ПО».
Аппаратная поддержка виртуализации
Реализация ВПО в архитектуре x86 изначально не была предусмотрена разработчиками, поэтому часть команд, которые могут выполнять обычные универсальные ОС, не должны быть разрешены для исполнения внутри ВМ. Простым способом решения этой проблемы была бы возможность получать так называемые прерывания или исключения при попытке выполнения этих команд внутри ВМ, с тем чтобы обрабатывать их внутри ВПО. Но сложность в том, что простого способа вызвать это исключение для некоторого класса команд не существует — они отработают внутри ВПО, но дадут при этом не тот результат, который ожидался. Причем, иногда выполнение такой небезопасной команды может вызвать сбой в основной ОС или зависание всего компьютера. Например, в архитектуре Intel Pentium таких команд 26 и перед их выполнением в коде ядра гостевой ОС необходимо принять специальные меры, приводящие к существенным накладным расходам по производительности.
Компании Intel и AMD около двух лет назад объявили о создании аппаратной поддержки для решения типовых задач МВМ. Основная цель введения аппаратной поддержки — борьба за облегчение создания новых версий виртуализационного ПО и уменьшение падения производительности при применении технологий виртуализации.
INTEL VT
Суть решения VT (Vitrualization Technology) заключается во введении нового режима VMX функционирования процессора, специально предназначенного для поддержки виртуализации (рис. 1). В этом режиме программный код может работать или как VMX-root, или как VMX-nonroot — обычно МВМ работает как VMX-root, а код гостевой ОС как VMX-nonroot. Переключения от VMX-root к VMX-nonroot коду называются входом в ВМ (VM entry), а обратные переключения — выходом из ВМ (VM exit). Сами переключения в терминологии Intel называются VMX-переходами (VMX transitions).
Поведение процессора для VMX-nonroot кода изменено таким образом, чтобы осуществить работу ВПО. Вместо того, чтобы исполнять некоторые инструкции, включая новую VMCALL, в коде VMX-nonroot будет осуществляться выход из ВМ и передача управления МВМ. Эти переходы остаются невидимыми для гостевого VMX-nonroot кода, ограничивая его прямой доступ к физическому оборудованию и позволяя МВМ полностью контролировать ресурсы физического компьютера или предоставлять доступ к ним из гостевых ОС.
Поскольку VMX-режим для VMX-nonroot кода вносит ограничения даже для уровня привилегий 0 (ядро ОС), гостевая ОС и ее ПО без каких либо модификаций могут функционировать в ВМ именно так, как рассчитывали разработчики ОС при ее проектировании.
Порядок выполнения программы в среде VT следующий. Командой VMXON процессор переводится в VMX-режим. МВМ может передавать управление только из гостевых ОС в каждый момент времени с помощью команд VMLAUNCH и VMRESUME (входы в ВМ). МВМ снова получает управление при выходах из ВМ. В ситуации выхода из ВМ управление будет передано на заранее установленную точку в коде МВМ. МВМ определяет причину выхода из ВМ, производит соответствующие действия и может передать управление гостевой ОС опять через входы в ВМ. В какой-то момент времени МВМ может решить покинуть режим VMX, выполнив команду VMXOFF.
AMDV
В мае 2005 года компания AMD представила свои технологии поддержки виртуализации Pacifica и Pacifica2, которые позже были переименованы в AMD CPU virtualization technology (AMDV). Архитектура AMDV похожа на VT и предоставляет те же функциональные возможности, однако предусматривает также ряд дополнительных функций, отсутствующих у Intel VT.
Два наиболее важных отличия AMDV: Tagged TLB (TTLB) и Device exclusion vector (DEV). При переключении между МВМ и ВМ в процессорах буферы ассоциативного преобразования адресов TLB (Translation Look-aside Buffer) в процессоре для технологии VT очищаются, а у AMD элементы этих буферов, содержащих ссылки между виртуальными и реальными адресами страниц памяти, размещаются в тэги, что позволяет принимать индивидуальные решения по их использованию или очистке. Соответственно скорость переключения МВМ — ВМ в AMDV может быть существенно выше, хотя программная реализация кэширования для VT также может дать аналогичный результат. С другой стороны, TLB в AMD=процессорах запоминают трансляции вложенных таблиц страниц (NPTables), позволяя получать физический адрес памяти по виртуальному адресу в пространстве гостевого ПО без дополнительного этапа трансляции виртуального адреса в МВМ-пространстве в физический.
Другое важное отличие технологии DEV — интенсивное использование встроенного в AMD-процессоры контроллера памяти. По сути это аналог VT-d, который описывает, каким физическим устройствам разрешен доступ к каким страницам памяти ВМ и фактически осуществляет привязку устройств к ВМ. Это позволяет ВМ корректно работать через DMA без необходимости контроля со стороны МВМ.
Программная виртуализация
Первые подходы к виртуализации, например эмуляция компьютеров, были реализованы более 30 лет назад в IBM OS/370, а некоторые получили развитие гораздо позже, но все они выстроены вокруг простой концепции. ПО верхнего уровня получает от ПО нижнего уровня (в случае драйвера), или от электронного оборудования ответы на какие-либо запросы. Если имитировать ответы ПО нижнего уровня, или от устройств, то ПО верхнего уровня не способно различить ситуацию, когда ответы приходят от имитатора (далее эмулятор), а когда от настоящего устройства. Соответственно, подходы к виртуализации различаются в том, на каком уровне иерархии ПО вставляется эмулятор, набором вызовов, поддерживаемых эмулятором, и, как способ упрощения работы эмулятора, какие модификации вносятся в виртуализируемое ПО.
Эмуляция оборудования
Данная технология предусматривает полную эмуляцию оборудования на уровне программного обеспечения обычно путем создания процесса уровня пользователя, внутри которого и осуществляется собственно эмуляция. Примеры реализаций такой технологии: VMWare Workstation, Plex86, Parallels и MS Virtual PC. Обычно эта технология позволяет эмулировать аппаратуру платформы того же типа, на которой запущена основная операционная система. Перехват нежелательных команд может осуществляться, например, методом бинарной трансляции кода. С помощью этой технологии можно запускать большинство современных ОС внутри эмулятора поверх основной операционной системы.
Данный подход имеет существенные накладные расходы, которые зависят от числа эмулируемых устройств и от степени похожести устройств на физические. Технология плохо масштабируется — нет возможности эффективно совместно использовать все доступные аппаратные ресурсы, а оперативная память физической машины фактически должна быть жестко разделена для того, чтобы предоставить каждой запущенной виртуальной свою собственную неразделяемую память, плюс существенная доля памяти должна быть зарезервирована для накладных расходов самой системы виртуализации. Фактически на обычных серверах невозможно запустить более 10-15 виртуальных машин. Другой особенностью является жесткое разделение дискового пространства между ВМ — обычно файловая система для виртуальной машины расположена внутри файла основной ОС (или раздела диска) и уникальна для каждого экземпляра ВМ.
Паравиртуализация
Альтернативой бинарной трансляции нежелательных команд может быть переделка ядра гостевой ОС, заменяющая эти команды на вызовы ВПО. Этот подход осуществим, если доступен гостевой вариант системы, либо, если есть исходные тексты ОС и они могут быть модифицированы согласно лицензии, как в случае с ОС Linux. Такой подход был использован в системе Xen, которая не скрывает себя от виртуализируемой ОС, а до версии 3.0, использующей Intel VT и AMDV, Xen требовал гостевую версию ОС. Еще одна существенная особенность Xen заключается в подходе к работе с внешними устройствами. Для решения этой задачи используется одна из гостевых ОС, обладающих соответствующими драйверами и полномочиями по доступу к оборудованию. В остальных гостевых ОС драйверы оборудования редуцированы до специальных «передающих» заглушек-фронтендов, которые вызывают МВМ, а тот передает эти запросы гостевой ОС с настоящими драйверами.
Виртуализация высокого уровня
Для процессов ОС, предоставляющих сервисы пользователям, наличие «виртуального оборудования», абсолютно безразлично — для них важно, чтобы были сохранены те способы коммуникации, которые они применяют для связи с ОС, а вызовы отрабатывались наиболее удобным и эффективным образом. С другой стороны, если ресурсы физического компьютера и объекты ядра ОС разделить на подмножества по определенным правилам, то возможно построить виртуальную среду (ВС) исполнения — «высокоуровневую виртуализацию», которая обеспечивает каждой ВС свое собственное уникальное изолированное окружение: файлы и системные ресурсы, сервисы, системные способы связи с внешним миром и т.д. Серверное приложение, работающее в ВС будем называть виртуальным приватным сервером (ВПС).
По сравнению с полной виртуализацией и паравиртуализацией высокоуровневая виртуализация дает больше выгод: гибкое управление памятью и файловым пространством, низкие затраты на переключение между ВС, возможность мгновенного получения всех ресурсов компьютера. Имеется ряд ограничений на использование ВС, например, технология Virtuozzo компании SWsoft подразумевает, что каждый процесс, запущенный на виртуальной машине использует одно и то же ядро (не говоря об одной и той же ОС) и из ВС нельзя менять существенные корневые компоненты или версию ядра для одной гостевой ОС. Однако можно применять различные версии ПО, если они работают с одним и тем же ядром, модулями и существенными библиотеками в случае Linux, или исполняемых файлов ядра для Windows. Других существенных ограничений, в общем-то, нет (за исключением прямого доступа к оборудованию, который опять-таки ограничен изнутри BC по соображениям безопасности). Есть еще некоторые ограничения, присущие той или другой реализации, например, в ВС в любой момент обычно возможен прямой административный доступ к файлам из основной ОС, тогда как в типовых реализациях он возможен только по сети, если это сделал администратор соответствующей виртуальной машины и, наоборот, в VM имеется возможность сделать «снимок» состояния системы для дальнейшего возвращения к этому состоянию (snapshot), а в ВПС это делается иначе, на уровне группы процессов, а не всего ядра.
Использование Intel VT и AMDV выгод в производительности для ВПО, построенных на принципах высокоуровневой виртуализации, не сулит, однако, вполне может быть использовано для повышения уровня защищенности и надежности. В целом следует отметить что эти технологии виртуализации дополняют друг друга и могут быть эффективно совместно использованы в современных центрах данных предприятий.
Андрей Николаев (gentoorion@mail.ru) — зав. лабораторией отдела вычислительной техники МФТИ, Александр Тормасов (tor@crec.mipt.ru) — заместитель заведующего кафедрой Computer Science МФТИ, (Москва).
Терминология
Виртуализационное программное обеспечение (ВПО) — программный комплекс, обеспечивающий запуск и функционирование одной или нескольких модифицированных или немодифицированных копий гостевых операционных систем (ОС) таким образом, что каждая гостевая ОС функционирует как штатно установленная на физическом компьютере, может пользоваться напрямую или опосредованно его устройствами, может быть остановлена и сохранена в произвольный момент своего цикла работы, перезапущена, клонирована на текущем компьютере и/или перенесена на другой физический компьютер, обладающий тем же комплексом ВПО.
Виртуальная машина (ВМ) — полный «виртуальный мир», в котором ВПО инкапсулирует гостевую ОС, предоставляя ей комплект «виртуального оборудования». ВМ становится объектом, с которым оперирует ВПО.
Монитор виртуальных машин (МВМ, гипервизор или VMM, Virtual Machine Monitor) — часть ВПО, обеспечивающая контроль за различными аспектами функционирования ВМ-объектов. Здесь имеются некоторые вариации в обозначениях. Обычно МВМ существует «параллельно» с основной операционной системой, имеет практически одинаковые с ней полномочия и не использует специальных планировщиков процессора и других ресурсов, тогда как гипервизор обычно имеет выделенные только для него возможности по контролю за оборудованием и распределению некоторых ресурсов, и даже основная система осуществляет свои функции посредством использования возможностей гипервизора, а не прямым обращением к аппаратуре (хотя и здесь существуют свои исключения).
Виртуальная среда (ВС) — «виртуальный мир», в котором ВПО инкапсулирует гостевую ОС и предоставляет ей комплект «виртуальных сервисов ОС». Отличается от ВМ тем, что виртуализация проводится на более высоком уровне — для прикладных и системных программ. Все копии гостевых ОС, установленных на машине, разделяют одно ядро основной ОС.
