Понятие «монитор виртуальных машин» (МВМ) возникло в конце 60-х как программный уровень абстракции, разделявший аппаратную платформу на несколько виртуальных машин [1]. Каждая из этих виртуальных машин (ВМ) была настолько похожа на базовую физическую машину, что существующее программное обеспечение могло выполняться на ней в неизменном виде. В то время вычислительные задачи общего характера решались на дорогих мэйнфреймах, и пользователи высоко оценили способность МВМ распределять дефицитные ресурсы среди нескольких приложений. Тогда МВМ процветали как в промышленности, так и в академической науке.

В 80-90-е годы существенно снизилась стоимость компьютерного оборудования и появились многозадачные ОС, что уменьшило ценность МВМ в глазах пользователей. Мэйнфреймы уступили место мини-компьютерам, на смену которым пришли ПК, и нужда в МВМ отпала. В результате из компьютерной архитектуры попросту исчезли аппаратные средства для их эффективной реализации. К концу 80-х в науке и на производстве МВМ воспринимались не иначе как исторический курьез.

Сегодня МВМ — снова в центре внимания. Венчурные фирмы сражаются за право финансировать молодые компании, имеющие свои ВМ-технологии. Корпорации Intel, AMD, Sun Microsystems и IBM создают стратегии виртуализации для развивающихся рынков с миллиардными доходами. В научных лабораториях и университетах для решения проблем мобильности, обеспечения безопасности и управляемости развиваются подходы, основанные на виртуальных машинах. Что же произошло между отставкой МВМ и их возрождением?

В 90-е годы исследователи из Стэнфордского университета начали изучать возможность применения ВМ для преодоления ограничений оборудования и операционных систем. На сей раз проблемы возникли у компьютеров с массовой параллельной обработкой (Massively Parallel Processing, MPP), которые плохо поддавались программированию и не могли выполнять имеющиеся ОС. Исследователи обнаружили, что с помощью виртуальных машин можно сделать эту неуклюжую архитектуру достаточно похожей на существующие платформы, чтобы использовать преимущества готовых ОС. Из этого проекта вышли люди и идеи, ставшие золотым фондом компании VMware, первого поставщика МВМ для компьютеров массового применения.

ПРИЧИНЫ ВОЗРОЖДЕНИЯ

Как ни странно, развитие современных ОС и снижение стоимости оборудования (то есть две причины отставки МВМ в 80-е годы) привели к появлению проблем, которые исследователи надеялись решить с помощью МВМ. Дешевизна оборудования способствовала быстрому распространению компьютеров, но они часто бывали недогруженными, требовали дополнительных площадей и усилий по обслуживанию. А следствиями роста функциональных возможностей ОС стали их неустойчивость и уязвимость.

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

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

РАЗДЕЛЕНИЕ ОБОРУДОВАНИЯ И ПО

Как показано на рис. 1, МВМ отделяет программное обеспечение от оборудования и формирует промежуточный уровень между ПО, выполняемым ВМ (вверху), и аппаратными средствами (внизу). Этот уровень позволяет МВМ полностью контролировать использование аппаратных ресурсов гостевыми операционными системами (GuestOS), которые выполняются на ВМ.

Рис. 1. Классический МВМ — тонкий слой ПО, отделяющий ВМ от оборудования и создающий унифицированное представление базовых ресурсов, благодаря которому разные физические машины выглядят одинаково

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

Благодаря полной инкапсуляции состояния ПО на ВМ монитор МВМ может отобразить эту ВМ на любые доступные аппаратные ресурсы и даже перенести с одной физической машины на другую. Задача балансировки нагрузки в группе машин становится тривиальной, и появляются надежные способы борьбы с отказами оборудования и наращивания системы. Если нужно отключить отказавший компьютер или ввести в строй новый, МВМ способен соответствующим образом перераспределить виртуальные машины. ВМ легко тиражировать, что позволяет администраторам по мере необходимости оперативно предоставлять новые услуги.

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

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

Полная изоляция также важна для надежности и обеспечения безопасности. Приложения, которые раньше выполнялись на одной машине, теперь можно распределить по разным ВМ. Если одно из них в результате ошибки вызовет аварию ОС, другие приложения будут от нее изолированы и продолжат работу. Если же одному из приложений угрожает внешнее нападение, атака будет локализована в пределах «скомпрометированной» ВМ.

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

ОСОБЕННОСТИ РЕАЛИЗАЦИИ МВМ

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

При поиске таких компромиссов принимаются во внимание основные требования к МВМ — совместимость, производительность и простота. Совместимость важна потому, что главное достоинство МВМ — способность выполнять унаследованные приложения. Производительность определяет величину накладных расходов на виртуализацию — программы на ВМ должны выполняться с той же скоростью, что и на реальной машине. Простота необходима, поскольку отказ МВМ приведет к отказу всех ВМ, выполняющихся на компьютере. В частности, для надежной изоляции требуется, чтобы МВМ был свободен от ошибок, которые злоумышленники могут использовать для разрушения системы.

Виртуализация процессора

Архитектура центрального процессора поддается виртуализации, если она поддерживает прямое выполнение команд ВМ на реальной машине, позволяя МВМ полностью контролировать ЦП. При таком выполнении команды (как привилегированные — ядра ОС, так и непривилегированные — приложений) должны выполняться в непривилегированном режиме ЦП, в то время как МВМ выполняется в привилегированном режиме. Когда виртуальная машина пытается выполнить привилегированную команду, ЦП перехватывает ее и отсылает МВМ, который эмулирует ее выполнение в зависимости от состояния ВМ.

Хороший пример — обработка в МВМ команды на запрет прерываний. Гостевой операционной системе небезопасно разрешать ее выполнение, так как МВМ не сможет восстановить контроль над ЦП. Вместо этого МВМ перехватывает команду на запрет прерываний и отмечает, что для данной ВМ прерывания запрещены. Затем МВМ откладывает доставку прерываний виртуальной машине, пока та снова их не разрешит.

Следовательно, ключевое требование к архитектуре — наличие механизма перехвата, позволяющего МВМ непосредственно использовать центральный процессор для выполнения ВМ. Располагая таким механизмом, МВМ посредством прямого выполнения может создать для ПО ВМ иллюзию нормальной физической машины.

Проблемы. К сожалению, большинство современных архитектур, в том числе популярная x86, не рассчитаны на виртуализацию. Например, операционные системы x86 используют команду POPF («Извлечь из стека регистр флагов процессора») для установки и сброса флага запрета прерываний. Эта команда не перехватывается при выполнении в непривилегированном режиме. Причем изменения флага прерываний просто игнорируются, так что методы прямого выполнения не будут работать для кода привилегированного режима, в котором применяется данная команда.

Другая проблема архитектуры x86 состоит в том, что непривилегированные команды позволяют узнать привилегии ЦП. Программа, выполняющаяся на виртуальной машине, может прочесть регистр сегмента кода, чтобы определить текущий уровень привилегий процессора. Поддающийся виртуализации процессор перехватил бы эту команду, и монитор МВМ смог бы подправить то, что увидит программа, дабы отразить уровень привилегий виртуальной машины. Однако x86 не перехватывает эту команду, и при прямом выполнении программа увидит в регистре сегмента кода неверный уровень привилегий.

Методы. Реализовать МВМ на не поддающихся виртуализации процессорах позволяют несколько методов. Самыми распространенными из них являются методы паравиртуализации [2] и прямого выполнения в комбинации с быстрой трансляцией двоичного кода.

При паравиртуализации разработчик МВМ переопределяет интерфейс виртуальной машины, заменяя непригодное для виртуализации подмножество исходной системы команды более удобными и эффективными эквивалентами. Хотя ОС нужно портировать для выполнения на таких ВМ, большинство обычных приложений могут выполняться в неизменном виде.

По методу паравиртуализации построен МВМ Disco [3] для не поддающейся виртуализации архитектуры MIPS. Разработчики Disco поменяли местоположение флага прерываний MIPS, чтобы он находился не в привилегированном регистре процессора, а в специально отведенном месте памяти ВМ. Они заменили команду MIPS, аналогичную команде x86 POPF, и команду чтения регистра сегмента кода, которая стала обращаться к данному месту в памяти. Подмена устранила «накладные расходы» на виртуализацию, такие как перехват привилегированных команд, что привело к повышению производительности. Затем разработчики модифицировали версию ОС Irix, чтобы использовать в своих интересах эту паравиртуализованную версию архитектуры MIPS.

Самый большой недостаток паравиртуализации — несовместимость. Любая операционная система, предназначенная для выполнения под управлением паравиртуализованного монитора МВМ, должна быть портирована в эту архитектуру, для чего нужно договариваться о сотрудничестве с поставщиками ОС. Кроме того, нельзя использовать унаследованные операционные системы, а существующие машины не удается легко заменить виртуальными. Оборудование x86, характеризуемое превосходной обратной совместимостью, выпускалось в течение ряда лет, и множество унаследованных программ все еще находятся в эксплуатации. Все это означает, что отказаться от совместимости не так-то просто. Несмотря на такие недостатки, в академических научно-исследовательских проектах предпочтение отдается паравиртуализации, поскольку построение МВМ с полной совместимостью и высокой производительностью — серьезная техническая проблема.

Чтобы добиться высокой производительности и совместимости при виртуализации архитектуры x86, компания VMware разработала новый метод виртуализации, который объединяет традиционное прямое выполнение с быстрой трансляцией двоичного кода «на лету». В большинстве современных ОС режимы работы процессора при выполнении обычных прикладных программ легко поддаются виртуализации, а следовательно, их можно виртуализовать посредством прямого выполнения. Непригодные для виртуализации привилегированные режимы может выполнять транслятор двоичного кода, исправляя «неудобные» команды x86. В результате получается высокопроизводительная виртуальная машина, которая полностью соответствует оборудованию и поддерживает полную совместимость ПО.

Существуют примеры трансляторов двоичного кода [4], преобразующих команды для одного процессора в команды для другого. Транслятор двоичного кода VMware намного проще, поскольку исходная и целевая системы команд почти идентичны. Основной метод реализации МВМ состоит в том, чтобы выполнять привилегированный код (код ядра) под контролем транслятора двоичного кода. Транслятор преобразует блок привилегированного кода, заменяя проблематичные команды, что позволяет выполнять этот блок непосредственно на центральном процессоре. Преобразованный блок сохраняется в кэш-памяти трассировки, чтобы не обрабатывать его заново при повторном выполнении.

Преобразованный код очень похож на результаты паравиртуализации. Обычные команды выполняются в неизменном виде, а команды, нуждающиеся в специальной обработке (такие, как POPF и команды чтения регистров сегмента кода), транслятор заменяет последовательностями команд, которые подобны требующимся для выполнения на паравиртуализованной виртуальной машине. Однако есть важное различие: вместо того, чтобы изменять исходный код операционной системы или приложений, транслятор двоичного кода изменяет код при его выполнении в первый раз.

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

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

Перспективы. Недавно Intel и AMD сообщили о новых технологиях Vanderpool и Pacifica, направленных на аппаратную поддержку мониторов МВМ в ЦП x86. Вместо модернизации существующих режимов выполнения Intel и AMD вводят новый режим работы процессора, который позволяет МВМ беспрепятственно использовать прямое выполнение кода виртуальных машин. Для повышения производительности в этом режиме сокращается как количество перехватов, необходимых для реализации виртуальных машин, так и время на перехват одной команды.

Когда эти технологии станут доступными, у процессоров x86 появится возможность реализовать мониторы МВМ исключительно с прямым выполнением — по крайней мере, для операционных сред, не использующих эти новые режимы. Если аппаратная поддержка будет столь же хороша, как в старинных мэйнфреймах IBM, можно будет упростить виртуализацию и еще больше снизить «накладные расходы». Адекватная аппаратная поддержка даже без паравиртуализации позволяет снизить дополнительные расходы до уровня, на котором преимущества полной совместимости виртуальной машины перевесят любой выигрыш в производительности, достигаемый за счет отказа от совместимости.

Виртуализация памяти

Традиционный метод виртуализации памяти состоит в том, что МВМ поддерживает «теневую» копию структуры данных для управления памятью виртуальной машины. Эта структура, называемая «теневой таблицей страниц», позволяет МВМ точно знать, какие страницы физической памяти доступны виртуальной машине.

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

Подобно подсистемам виртуальной памяти в традиционных ОС, МВМ может подкачивать страницы памяти ВМ с диска, так что выделенная ей память может превышать объем физической памяти. Поскольку МВМ способна расходовать машинную память практически без ограничений, для работы ВМ требуется меньше аппаратных ресурсов. МВМ может динамически контролировать, сколько памяти получает каждая виртуальная машина в соответствии со своими нуждами.

Проблемы. Подсистема виртуальной памяти МВМ постоянно контролирует, сколько памяти выделено ВМ, и должна периодически забирать часть этой памяти, выгружая некоторые страницы ВМ на диск. Однако ОС на ВМ (GuestOS) «лучше знает», какие страницы следует выгружать. Например, GuestOS способна определить, что создавший страницу процесс завершил работу и страница больше не нужна. МВМ, который работает на аппаратном уровне, «не знает» о этом и может продолжать подкачку страницы, расточительно расходуя ресурсы.

Для решения этой проблемы сервер VMware ESX Server [5] использует подход, напоминающий паравиртуализацию. Суть его заключается в том, что МВМ взаимодействует с выполняющимся внутри GuestOS надувным процессом (balloon process). Когда МВМ хочет отобрать память у виртуальной машины, он просит надувной процесс затребовать больше памяти (собственно, «раздувает» его). GuestOS выбирает свободные страницы для надувного процесса, которые тот отдает монитору МВМ для перераспределения. Кроме того, повышенная нагрузка на память, вызванная «раздуванием» надувного процесса, вынуждает GuestOS к интеллектуальной выгрузке памяти на виртуальный диск.

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

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

Как и в обычной схеме совместного использования страниц по принципу «тиражирование при изменении», МВМ выделяет каждой виртуальной машине индивидуальную копию, если одна из них изменяет содержание общей страницы. Представление о масштабах экономии дает следующий пример. На компьютере x86 могут выполняться до 30 виртуальных машин под управлением Microsoft Windows 2000, но сохранение в памяти компьютера лишь одной копии ядра Windows существенно сокращает нагрузку на физическую память.

Перспективы. Операционные системы часто вносят изменения в свои таблицы страниц, поэтому поддержание их теневых копий в актуальном состоянии программным путем ведет к нежелательным дополнительным расходам. Теневые таблицы страниц с аппаратным управлением давно присутствуют в архитектуре виртуализации мэйнфреймов и стали бы плодотворным направлением для ускорения виртуализации процессоров x86.

Управление ресурсами — многообещающая область для будущих исследований. В ней предстоит еще многое сделать для организации совместной работы МВМ и гостевых ОС. Кроме того, исследователи должны рассмотреть управление ресурсами на уровне центра данных, и мы ожидаем, что в следующем десятилетии в этом отношении будут достигнуты значительные успехи.

Виртуализация ввода/вывода

Тридцать лет назад архитектура подсистем ввода/вывода мэйнфреймов IBM строилась на базе каналов, и доступ к устройствам ввода/вывода осуществлялся через отдельный канальный процессор. Используя такой процессор, МВМ может с успехом «возложить ответственность» за доступ к устройствам ввода/вывода непосредственно на виртуальную машину. В результате удастся существенно снизить «накладные расходы» на виртуализацию ввода/вывода. Программа на виртуальной машине могла бы выполнять операции чтения и записи непосредственно на устройстве, не прибегая к перехвату команд и их обработке на мониторе МВМ. Этот подход прекрасно себя зарекомендовал для устройств ввода/вывода того времени, таких как текстовые терминалы, дисковые накопители, устройства чтения перфокарт и карточные перфораторы.

Проблемы. Богатство и разнообразие устройств в современных компьютерных средах делает виртуализацию ввода/вывода намного более сложной. Вычислительные среды на базе процессоров x86 поддерживают множество разнообразных устройств ввода/вывода, изготовленных различными производителями и имеющих разные программные интерфейсы. Следовательно, создание подсистемы ввода/вывода для МВМ, которая будет общаться со всеми этими устройствами, потребует огромных усилий. К тому же некоторые из современных устройств, например графическая подсистема ПК или сетевой интерфейс сервера, предъявляют чрезвычайно высокие требования к производительности. Это делает снижение накладных расходов важной предпосылкой для широкого распространения виртуализации.

Экспорт стандартного интерфейса устройства означает, что уровень виртуализации должен взаимодействовать с устройствами ввода/вывода компьютера. Чтобы обеспечить это взаимодействие, продукт VMware Workstation использует вложенную архитектуру [6], показанную на рис. 2. В ней уровень виртуализации задействует для доступа к устройствам ввода/вывода драйверы устройств базовой ОС (HostOS) Windows или Linux. Поскольку большинство устройств ввода/вывода имеют драйверы для этих операционных систем, уровень виртуализации может поддерживать любое такое устройство.

Рис. 2. Вложенная архитектура VMware использует оборудование совместно с базовой операционной системой

Когда GuestOS дает команду на чтение или запись блока на виртуальный диск, уровень виртуализации преобразует эту команду в вызов системной процедуры, которая выполняет файловые операции чтения/записи в файловой системе HostOS. Аналогичным путем подсистема ввода/вывода МВМ отображает картинку с видеокарты виртуальной машины в окне HostOS, что позволяет последней управлять видеоустройствами ВМ.

Вложенная архитектура имеет три важных достоинства. Во-первых, МВМ устанавливается как обычное приложение для HostOS, а не на «голом железе», как в традиционных схемах виртуализации. Во-вторых, вложенная архитектура полностью «впитывает» разнообразие устройств ввода/вывода на рынке ПК x86. В-третьих, МВМ может использовать планирование, управление ресурсами и другие услуги, предлагаемые HostOS.

Когда компания VMware начала разрабатывать продукты для рынка серверов x86, проявились недостатки вложенной архитектуры. При виртуализации устройств ввода/вывода такая архитектура сильно снижает их производительность. Каждый запрос ввода/вывода должен передать управление операционной системе HostOS, а затем пройти через все уровни ПО HostOS, чтобы добраться до устройства. В серверной среде с высокопроизводительными сетевыми и дисковыми подсистемами «накладные расходы» были неприемлемо высоки. Кроме того, современные ОС Windows и Linux не поддерживают управление ресурсами для обеспечения изоляции работы и гарантированного обслуживания виртуальных машин, что необходимо в большинстве серверных сред.

При разработке сервера ESX Server [5] был принят более традиционный подход к реализации МВМ, выполняющегося непосредственно на оборудовании, без базовой ОС. В дополнение к развитым средствам планирования и управления ресурсами ESX Server имеет оптимизированную подсистему ввода/вывода для сетевых и запоминающих устройств. Для непосредственного общения с устройствами ядро ESX Server может использовать драйверы из ядра Linux, что позволяет значительно снизить «накладные расходы» на виртуализацию устройств ввода/вывода. Vmware может использовать этот подход, поскольку лишь немногие сетевые и запоминающие устройства сертифицированы для применения на серверах x86 ведущих поставщиков. Ограниченность номенклатуры поддерживаемых устройств делает приемлемым прямое управление вводом/выводом.

Дополнительный вклад в оптимизацию производительности продуктов VMware вносит возможность экспорта специальных оптимизированных виртуальных устройств ввода/вывода, не соответствующих реальным устройствам. Как и при паравиртуализации ЦП, при таком подходе необходимо, чтобы в среде GuestOS использовались специальные драйверы устройств. В результате получается более благоприятный для виртуализации интерфейс с устройствами ввода/вывода, обеспечиваются меньшие «накладные расходы» на передачу команд от GuestOS и повышенная производительность.

Перспективы. Отраслевые тенденции развития подсистем ввода/вывода указывают на все более активную аппаратную поддержку их виртуализации. Дискретные устройства ввода/вывода (вроде стандартного контроллера клавиатуры ПК x86 или контроллера дисков IDE, история которых восходит к оригинальным IBM PC) уступают место устройствам с интерфейсами USB и SCSI. Подобно каналам ввода/вывода в мэйнфреймах IBM, эти интерфейсы сильно упрощают виртуализацию и снижают «накладные расходы».

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

Для устройств ввода/вывода, осуществляющих прямой доступ к памяти, потребуется переадресация. Это позволит отображать адреса памяти, назначенные драйвером устройства на ВМ, на области физической памяти, которые определяются теневыми таблицами страниц. Для поддержания изоляции устройство должно обращаться только к памяти, принадлежащей ВМ, — независимо от того, как его запрограммирует драйвер на ВМ.

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

ЧТО ВПЕРЕДИ?

Экспертиза современных продуктов и недавние исследования раскрывают некоторые интересные возможности будущего развития МВМ и требования, которые они предъявят к технологиям виртуализации.

Виртуальные центры данных

Администраторы центра данных смогут с единой консоли быстро вводить в действие ВМ и управлять тысячами виртуальных машин, выполняющихся на сотнях физических серверов. Вместо того чтобы конфигурировать отдельные компьютеры, администраторы будут создавать по имеющимся шаблонам новые экземпляры виртуальных серверов и отображать их на физические ресурсы в соответствии с политиками администрирования. Уйдет в прошлое взгляд на компьютер как на средство предоставления конкретных услуг. Администраторы будут рассматривать компьютеры просто как часть пула универсальных аппаратных ресурсов (примером тому может служить виртуальный центр VMware VirtualCenter).

Отображение виртуальных машин на аппаратные ресурсы будет очень динамичным. Возможности миграции работающих ВМ (подобные тем, которые обеспечивает технология VMotion компании Vmware) позволят ВМ быстро перемещаться между физическими машинами в соответствии с потребностями центра данных. МВМ сможет справляться с такими традиционными проблемами, как отказ оборудования, за счет простого перемещения ВМ с отказавшего компьютера на исправный. Возможность перемещения работающих ВМ облегчит решение аппаратных проблем, таких как планирование профилактического обслуживания, окончание срока действия лизингового договора и модернизация оборудования: администраторы станут устранять эти проблемы без перерывов в работе.

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

За порогом машинного зала

По мере распространения ВМ на настольные ПК, все важнее становится их роль в компьютерном мире. ВМ станут основой мощной унифицированной модели реструктуризации управления настольными компьютерами [7]. Преимущества МВМ, продемонстрированные в машинном зале, относятся и к настольным компьютерам; они помогают решать проблемы управления, характерные для организаций с большим парком настольных и портативных ПК.

Решение проблем на уровне МВМ положительно сказывается на всех программах, выполняющихся на ВМ, независимо от их возраста (унаследованная или новейшая) и поставщиков. Независимость от ОС избавляет от необходимости покупать и обслуживать избыточную инфраструктуру. Например, из нескольких версий ПО службы поддержки или резервного копирования останется лишь одна — та, которая работает на уровне МВМ.

Виртуальные машины сильно изменят отношение к компьютерам. Если простые пользователи сумеют легко создавать, копировать и совместно использовать ВМ, то модели их применения будут значительно отличаться от привычных, сложившихся в условиях вычислительной среды с ограниченной доступностью аппаратных средств. А разработчики ПО смогут применять такие продукты, как VMware Workstation, чтобы легко установить компьютерную сеть для тестирования или создать собственный набор испытательных машин для каждой цели.

Повышенная мобильность ВМ значительно изменит способы их применения. Такие проекты, как Collective [7] и Internet Suspend/Resume [8], демонстрируют возможность перемещения всей вычислительной среды пользователя по локальной и территориальнораспределенной сети. Доступность высокоемких недорогих сменных носителей, таких как жесткие диски USB, означает, что потребитель может захватить свою вычислительную среду с собой, куда бы он ни направлялся.

Динамический характер компьютерной среды на базе ВМ потребует и более динамичной топологии сети. Виртуальные коммутаторы, виртуальные брандмауэры и оверлейные сети станут неотъемлемой частью будущего, в котором логическая вычислительная среда отделится от своего физического местоположения.

Повышение уровня безопасности

МВМ имеют мощный потенциал для реструктуризации существующих программных систем в целях повышения уровня защиты, а также облегчают развитие новых подходов к построению безопасных систем. Сегодняшние ОС не обеспечивают надежной изоляции, оставляя машину почти беззащитной. Перемещение механизмов защиты за пределы ВМ (чтобы они выполнялись параллельно с ОС, но были изолированы от нее) позволяет сохранить их функциональные возможности и повысить устойчивость к нападениям. Два примера прототипов таких систем — Livewire [9], в которой МВМ используется для обнаружения вторжений на ВМ, и ReVirt [10], которая на уровне МВМ анализирует возможный ущерб от хакерского нападения. Эти системы не только повышают «сопротивляемость» нападениям, поскольку действуют вне ВМ, но и контролируют внутреннюю среду ВМ на уровне оборудования.

Размещение средств безопасности за пределами ВМ — привлекательный способ изоляции сети. Доступ к сети предоставляется ВМ после проверки, гарантирующей, что она, с одной стороны, не представляет угрозы, а с другой — неуязвима для нападения. Управление доступом к сети на уровне ВМ превращает виртуальную машину в мощный инструмент борьбы с распространением злонамеренного кода.

Виртуальные машины прекрасно приспособлены для использования в качестве стандартных блоков для построения систем с высоким уровнем защиты. Например, в архитектуре проекта NetTop американского Агентства национальной безопасности МВМ компании VMware используется для разделения нескольких компьютерных сред, каждая из которых имеет доступ к отдельным сетям с различными категориями защиты. Подобные приложения доказывают необходимость продолжения исследований и разработок специализированных МВМ с высоким уровнем защиты.

Мониторы МВМ особенно интересны в плане управления многочисленными группами программ с различными уровнями безопасности. Благодаря отделению ПО от оборудования ВМ обеспечивают максимальную гибкость при поиске компромисса между производительностью, обратной совместимостью и степенью защиты. Изоляция программного комплекса в целом упрощает его защиту. В сегодняшних ОС почти невозможно судить о безопасности отдельного приложения, поскольку процессы плохо изолированы от друг друга. Таким образом, безопасность приложения зависит от безопасности всех остальных приложений на машине.

Описанные возможности делают мониторы МВМ особенно полезными для построения заслуживающих доверия вычислительных систем, что можно продемонстрировать на примере системы Terra [11]. В ней МВМ способен подтвердить удаленным пользователям подлинность ПО, выполняющегося на ВМ, с помощью процесса аттестации. Предположим, например, что на настольном компьютере одновременно выполняются несколько ВМ. Пользователь может располагать ВМ Windows с относительно низким уровнем безопасности для Web-серфинга, ВМ на базе специально доработанной ОС Linux — для ежедневной работы с повышенным уровнем защиты, ВМ на основе высокозащищенной ОС специального назначения и специализированной почтовой программой — для работы с конфиденциальной внутренней почтой.

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

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

Распространение ПО

Для отрасли ПО повсеместное развертывание МВМ имеет важное значение. МВМ предоставляет софтверным компаниям огромные возможности распространения ВМ, несущих на себе сложные программные среды. Компания Oracle, например, распространила более 10 тыс. полнофункциональных копий своей новейшей среды управления базами данных в виде виртуальных машин. Вместо того чтобы исключительно для проверки ПО устанавливать сложную среду в полном объеме, пользователи просто загружают ВМ.

Использование ВМ в качестве механизма распространения активно практикуется для демонстрации ПО, но этот механизм способен так же хорошо работать в производственных средах. Администраторы с помощью продукта VMware ACE могут публиковать виртуальные машины и контролировать их использование. В проекте Collective всесторонне изучалась идея пакетирования приложений в виртуальные устройства. Суть этой идеи заключается в том, чтобы поставлять файловые серверы, настольные приложения и другие системы в такой форме, которая позволяет пользователям рассматривать ВМ как автономные приложения. Проблемы управления обновлениями решает специальный диспетчер устройства, освобождая потребителей от этого бремени.

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

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

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

ЛИТЕРАТУРА
  1. R.P. Goldberg. Survey of Virtual Machine Research. Computer, June 1974.
  2. A. Whitaker, M. Shaw, S. Gribble. Scale and Performance in the Denali Isolation Kernel. ACM SIGOPS Operating Systems Rev., Winter 2002, vol. 36.
  3. E. Bugnion et al. Disco: Running Commodity Operating Systems on Scalable Multiprocessors. ACM Trans. Computer Systems.1997, vol. 15, no. 4.
  4. R. Sites et al. Binary Translation. Comm. ACM. Feb. 1993.
  5. C. Waldspurger. Memory Resource Management in VMware ESX Server. ACM SIGOPS Operating Systems Rev.Winter 2002, vol. 36.
  6. J. Sugerman, G. Venkitachalam, B. Lim. Virtualizing I/O Devices on VMware Workstation?s Hosted Virtual Machine Monitor, Proc. Usenix Ann. Technical Conf., Usenix, 2002.
  7. R. Chandra et al. The Collective: A Cache-Based Systems Management Architecture. Proc. Symp. Network Systems Design and Implementation, Usenix, 2005.
  8. M. Kozuch, M. Satyanarayanan. Internet Suspend/Resume. Proc. IEEE Workshop Mobile Computing Systems and Applications. IEEE Press, 2002.
  9. T. Garfinkel and M. Rosenblum. A Virtual Machine Introspection-Based Architecture for Intrusion Detection. Proc. Network and Distributed Systems Security Symp. The Internet Society. 2003.
  10. G. Dunlap et al. ReVirt: Enabling Intrusion Analysis through Virtual-Machine Logging and Replay. ACM SIGOPS Operating Systems Rev., Winter 2002, vol. 36.
  11. T. Garfinkel et al. Terra: A Virtual-Machine-Based Platform for Trusted Computing. Proc. ACM Symp. Operating Systems Principles, ACM Press, 2003.

Мендель Розенблюм (mendel@cs.stanford.edu) — профессор информатики Стэнфордского университета, сооснователь и главный научный сотрудник компании VMware. Тэл Гарфинкель (talg@cs.stanford.edu) — аспирант Стэнфордского университета.

Mendel Rosenblum, Tal Garfinkel. Virtual Machine Monitors: Current Technology and Future Trends, IEEE Computer, May 2005. IEEE Computer Society, 2005, All rights reserved. Reprinted with permission.