*1

_____

*1 Окончание тематического обзора. Начало см. PC Week/RE, N 26/2006, с. 18.    

Александр Тормасов,

Андрей Николаев

В последнее время мы наблюдаем живой интерес участников рынка к виртуализационным технологиям. Недавнее объявление о том, что аппаратная поддержка виртуализации в ближайшем будущем станет ключевым направлением деятельности таких компаний, как Intel и AMD, заставляет обратить пристальное внимание на актуальные задачи, существующие наработки и реализованные решения в этой области. Уже сейчас без преувеличения можно сказать, что шаг в "виртуализацию" будет как минимум настолько же значимым и всеобъемлющим, как и шаг, сделанный в конце 80-х - начале 90-х, когда в архитектуре x86 появился защищенный режим исполнения приложений. Возможно, последствия здесь будут столь же далеко идущими, как и после появления персональных компьютеров, существенно изменивших практически всю отрасль.

Задачи и проблемы виртуализационного ПО

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

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

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

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

_____

*1 На рубеже 80-90-х в семействе платформ на базе архитектуры процессоров Intel x86 защищенный режим превратился из вспомогательной технологии для ПО, работающего в реальном режиме, в основополагающую для новейших в ту пору операционных систем - Windows 3, Windows 95, Linux и различных ветвей UNIX. Однако, с точки зрения пользователя, сейчас изменений будет даже больше; они, наверное, будут сравнимы с теми изменениями, что произошли при переходе от мэйнфреймов, установленных в вычислительных центрах, к ПК. Теперь пользователь может для выполнения любой операции применять выделенную им на своем компьютере виртуальную машину.

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

Виртуализация в архитектуре Intel x86

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

Но проблема заключается в том, что простого способа вызвать это исключение для некоторого класса команд нет. Они отработают внутри ВПО, дав при этом не тот результат, которого ожидали разработчики, не предвидевшие, что ОС может оказаться "в гостях". Причем иногда выполнение подобной небезопасной команды может вызвать сбой в основной ОС или даже зависание всей компьютерной системы. Например, в архитектуре Intel Pentium имеется 26 таких инструкций, и перед их выполнением в коде ядра ОС необходимо либо принять специальные меры, обеспечивающие безопасность операции с точки зрения связки "гостевая система - основная система", либо вообще заблокировать их исполнение. В любом случае все эти меры приведут к значительным накладным расходам по производительности, если сравнивать гостевую ОС, запущенную под ВПО, и установленную как обычно.

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

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

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

Решение от Intel: Vitrualization Technology - Vanderpool

В 2004 г. на осеннем форуме Intel для разработчиков (Intel Developer Forum) была анонсирована Virtualization Technology (VT), известная ранее под кодовым названием Vanderpool. В апреле 2005-го появились ее общедоступные спецификации для архитектуры IA-32 (см, например, ftp://download.intel.com/technology/computing/vptech/C97063-002.pdf). Суть VT-решения заключается во введении нового режима функционирования процессора - VMX, предназначенного для поддержки виртуализации. В этом режиме команды процессора могут работать в двух новых режимах (рис. 1): VMX-root (обычный режим) и VMX-nonroot (режим исполнения виртуальной машины). По сути, эти режимы изменяют поведение некоторых команд. Переключения от VMX-root к VMX-nonroot называются входами в режим исполнения виртуальной машины (VM-entry), а обратные переключения - выходами из режима исполнения виртуальной машины (VM-exit). Сами переключения в терминологии Intel называются VMX-переходами (VMX-transition).

Рис. 1. VMX-режим позволяет исполнять код как VMX-root и как VMX-nonroot

(Ring - уровень привилегий)

Поведение процессора в режиме VMX-root почти такое же, как и вовне режима VMX, за исключением случаев, когда имеется дополнительный набор VMX-команд или ограничения на значения, загружаемые в некоторые управляющие регистры (CR0, CR4).

Поведение процессора для режима VMX-nonroot изменено таким образом, чтобы осуществить работу ВПО. Вместо того чтобы исполняться, некоторые инструкции (включая новую инструкцию вызова МВМ - VMCALL, которая уменьшает накладные расходы таких обращений), попав в CPU и пытаясь быть исполненными в режиме VMX-nonroot, будут приводить к исключению - выходу из режима исполнения ВМ и передаче управления МВМ. Эти переходы остаются невидимыми для гостевого VMX-nonroot-кода, существенно ограничивая его прямой доступ к физическому оборудованию и позволяя МВМ полностью контролировать ресурсы компьютера.

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

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

Жизненный цикл МВМ выглядит следующим образом (рис. 2). Программа командой VMXON переводит процессор в VMX-режим. Теперь МВМ может передавать управление только из гостевых ОС в каждый момент времени с помощью команд VMLAUNCH и VMRESUME (входы в ВМ). Обратно он получает управление при выходе из ВМ - в этом случае управление будет передано на заранее установленную точку в коде МВМ. Затем МВМ определяет причину выхода из ВМ, производит соответствующие действия и может снова передать управление гостевой ОС через входы в ВМ. В какой-то момент времени МВМ может решить покинуть режим VMX, для чего реализуется команда VMXOFF, глобально отключающая поддержку выполнения виртуальных машин.

Рис. 2. Жизненный цикл монитора ВМ

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

В дальнейших обнародованных планах Intel большое внимание уделяется развитию VT и связанных с ней технологий. Например, анонсирована технология VT-d, которая облегчает виртуализацию устройств ввода-вывода и повышает безопасность их работы. Используя VT-d, МВМ сможет "прикреплять" драйверы физических устройств к ВМ, что позволит гостевой ОС взаимодействовать с прикрепленным устройством посредством механизма DMA (прямого доступа устройств к памяти, минуя процессор), без передачи управления МВМ. Более подробно с VT-d можно ознакомиться в документе Intel Virtualization Technology for Directed I/O Architecture Specification (ftp://download. intel.com/technology/computing/vptech/Intel(r)_VT_for_Direct_IO.pdf).

Третье поколение VT будет включать в себя поддержку виртуализации памяти гостевых систем (технологию EPT - extended page tables). Она за счет появления нового уровня "косвенности" в адресации физической памяти облегчит проверку принадлежности адресов, выделенных гостевым машинам.

Одним из ярких примеров технологии, базирующейся на VT, может служить Intel LaGrande Technology (LT), определяющая набор необходимых модификаций платформы для поддержки создания хорошо защищенных платформ, которым можно доверять ("trusted platforms"). Везде, где используется слово "доверие", надо четко определить, кто доверяет и чему. Целью LT является создание уникально идентифицируемой контролируемой среды, устойчивой к попыткам изменения, чтобы в решениях по вопросам доверия можно было полагаться на платформу. Расширения LT касаются запуска МВМ и защиты его кода от модификаций. Более подробно об этой технологии можно прочитать в документе "LaGrande Technology Preliminary Architecture Specification" (www.intel.com/technology/ security/). Для корректной реализации LT встраивания ее поддержки потребуют абсолютно все компоненты современного компьютера (за исключением собственно модулей с наборами микросхем памяти).

Решение от AMD: Pacifica

В мае 2005 г. компания AMD также представила технологию поддержки виртуализации - Pacifica. Описывать все ее детали в данной статье не имеет смысла, так как в своей основе они похожи на VT и предоставляют те же функции. Однако стоит отметить, что у Pacifica есть и некоторые дополнительные возможности, которые отсутствуют в Intel VT. Два наиболее важных ее отличия - это Tagged TLB (TTLB) и Device exclusion vector (DEV).

Чтобы оценить их, надо разобраться в принципах трансляции виртуальных адресов в физические в случае ВМ. Для решения этой задачи к таблицам страниц МВМ добавлены Nested Page Tables (NPT), которые описывают виртуальные пространства адресов ВМ. При переключении контекстов между МВМ и ВМ в процессорах Intel VT таблицы TLB (это таблицы трансляции виртуальных адресов в физические, специфичные для архитектуры x86) очищаются, а у AMD элементы этих таблиц отмечены тегами, что позволяет принимать индивидуальные решения об использовании или очистке этих элементов. Соответственно скорость переключения МВМ - ВМ в Pacifica может быть заметно выше по сравнению с Intel VT, хотя программная реализация кэширования для последней может дать практически такой же результат. К тому же TLB в процессорах AMD запоминают трансляции вложенных таблиц страниц (NPTables), позволяя получать физический адрес памяти по виртуальному адресу в пространстве гостевого ПО без дополнительного этапа трансляции.

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

Более детально о Pacifica можно узнать из документов "Processor-Based Virtualization, AMD64 Style (http://developer.amd.com/articles.aspx?id=14&num=1) и AMD I/O Virtualization Technology (IOMMU) Specification (www.amd.com/us-en/assets/content_ type/white_papers_and_tech_docs/34434.pdf). Отметим, что еще год назад AMD анонсировала следующий этап реализации ее расширений (обычно все возможности новой технологии становятся доступными не сразу, а поэтапно).

Войны стандартов не будет?

Такая массированная поддержка технологий виртуализации ведущими игроками микропроцессорного рынка - событие безусловно знаковое и многообещающее. Но может ли возникнуть новая война стандартов - Intel против AMD? По сути, обе системы обладают примерно одинаковыми возможностями, слегка по-разному реализованными. Думается, что такой войны не будет, их реальное слияние произойдет на уровне производителей ВПО, которых очень мало (в мире известно только три коммерческих производителя ПО для виртуализации x86 - VMware, Microsoft и Parallels, и некоммерческий проект Xen - и все они одновременно поддерживают оба стандарта). Ведь для них встроить поддержку обеих, логически очень схожих технологий в свои продукты особой проблемы не составит, конечно, если не появятся какие-то искусственные ограничения. Тем более что примеры такого мирного сосуществования известны даже на более жестком рынке производителей аппаратных средств, как-то: одновременная поддержка DVD-R и DVD+R.

Виртуализационное программное обеспечение

 Полная эмуляция - VMware. Ядром технологии компании VMware является полная эмуляция оборудования на уровне ПО. Это означает, что существует некий процесс уровня пользователя основной операционной системы, внутри которого, собственно, и проходит эмуляция (рис. 3). Это полууниверсальная технология (как правило, она позволяет эмулировать аппаратуру платформы того же типа, на котором запущена основная операционная система), предназначенная для запуска большинства современных ОС внутри такого эмулятора - поверх основной операционной системы. Для перехвата нежелательных команд применяется метод бинарной трансляции кода.

Рис. 3. Архитектура VMware Workstation

В связи с выбранной технологией реализации (анализ кода перед исполнением и его динамическое преобразование) такой подход обуславливает существенные накладные расходы как с точки зрения производительности, так и в аспекте достижимого уровня масштабирования. Технология не обеспечивает эффективного совместного использования всех аппаратных ресурсов, и масштабируемость решения принципиально ограничена из-за того, что оперативная память основной машины практически должна быть жестко разделена, чтобы каждой запущенной ВМ предоставить свою собственную неразделяемую память. Кроме того, около 20% ОЗУ следует зарезервировать для обслуживания виртуальных машин (накладные расходы системы виртуализации). То есть на обычных серверах фактически нельзя запустить более 15 виртуальных машин, а реально и еще меньше. Это верно и для специальной серверной версии системы VMware ESX Server, которая обладает некоторыми возможностями по "внешнему" разделению страниц данных разных ВМ (хотя декларируемое количество виртуальных машин для ESX-системы несколько больше). Еще одной особенностью этого решения является то, что файловая система для использования виртуальной машины расположена внутри обычного файла основной ОС (или раздела диска) и является уникальной для каждого экземпляра ВМ.

С очень похожим решением - Virtual PC 2004 - в 2004 г. вышла Microsoft. Затем последовал Microsoft Virtual Server 2005. Происходит эта линейка от продукта Virtual PC for Windows компании Connectix, чей бизнес в области виртуальных платформ в середине 2003-го был перекуплен Microsoft. Однако ничего оригинального корпорация пока не предложила, Virtual PC - такое же ВПО общего назначения на базе МВМ-подхода, как и VMware Workstation, пригодное для запуска практически любой ОС.

Очевидно, что использование расширений Intel VT и AMD Pacifica для VMware является вполне логичным, естественным и дающим больший выигрыш по производительности шагом. По сути, это позволит отказаться от гостевой ОС, весьма дорогостоящей по ресурсам технологии бинарной трансляции кода ядра. Хотя следует отметить, что в настоящий момент технология VMware настолько "вылизана" с точки зрения производительности, что применение технологий аппаратной виртуализации не дает для нее какого-либо выигрыша, и VMware, в частности, не планирует использовать ее поддержку для 32-разрядных машин. В общем аппаратные технологии виртуализации облегчают создание новых программ такого рода (см., например, Xen, о нем рассказано ниже), но отнюдь не заменяют уже имеющихся.

Паравиртуализация: Xen. Как уже упоминалось выше, альтернативой бинарной трансляции нежелательных команд может быть переделка ядра гостевой ОС таким образом, чтобы заменить эти команды на вызовы МВМ. Это осуществимо, если компания - разработчик ОС предоставит гостевой вариант своей системы либо если исходные ее тексты доступны и могут быть модифицированы согласно лицензии, как в случае с Linux. Такой подход используется в паравиртуализированной системе Xen (www.cl.cam.ac.uk/ Research/SRG/netos/xen). Еще одно существенное отличие Xen от решения VMware заключается в подходе к работе с внешними устройствами.

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

Рис. 4. Архитектура Xen 2

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

Применение расширений Intel VT и AMD Pacifica приносит, пожалуй, наибольшую выгоду для паравиртуализационного подхода и продуктов, базирующихся на нем. Для Xen поддержка Intel VT означает качественный скачок. Теперь не обладающий технологией бинарной трансляции Xen может поддерживать непаравиртуализованные гостевые ОС за счет возможностей VT/Pacifica, что и реализовано в новом Xen версии 3 и выше.

 Высокоуровневая виртуализация - Virtuozzo. Однако есть и другой способ виртуализации. Ведь для пользовательских процессов ОС, которые, собственно, и предоставляют сервисы пользователям, в общем-то безразлично, присутствует при их исполнении "виртуальное оборудование" или нет. Их интересует лишь, чтобы те способы коммуникации, которые они применяют для связи с ОС, отрабатывались наиболее удобным и эффективным образом. Вот так и появляется "высокоуровневая виртуализация", которая обеспечивает для каждой среды исполнения (будем называть ее виртуальной средой - Virtual Environment, VE,) свое собственное уникальное изолированное окружение - свои файлы и другие ресурсы, в том числе и системные, свои сервисы, свои системные способы связи с внешним миром и т. д.

Иными словами, с точки зрения приложения оно запускается в собственном компьютере с основной ОС, и пользователь может делать с VE все, что обычно делает администратор машины: запускать и останавливать приложения и системные сервисы, устанавливать обновления приложений, конфигурировать сеть и сетевой экран, перезапускать VE. От оборудования среда пользователя отделена специальным "уровнем Virtuozzo" (рис. 5), вводящим понятие VE в корневую (или основную) ОС.

Рис. 5. Реализация технологии виртуального сервера VE

Кроме того, появляются дополнительные возможности, которые не так просто реализовать на физическом компьютере или внутри BM. Например, быстрая и эффективная установка приложений во множество VE, быстрая миграция (со временем недоступности сервера 1-3 с или даже вообще без остановки сервисов и прерывания сетевых сессий), динамическое управление ресурсами системы, выделяемыми конкретной VE. Технология VE находится "выше" технологии ВМ, их различие по отношению к архитектуре иллюстрирует рис. 6.

Рис. 6. Уровни реализации Virtual Machine и Virtual Environment

(на примере технологий VMware и Virtuozzo)

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

Впрочем, это не означает, что нельзя применять, скажем, разные "заплатки" на разные VE, если они не затрагивают собственно ядра или модулей в Linux либо библиотек или исполняемых файлов ядра Microsoft Windows. Других ограничений в общем-то нет (за исключением прямого доступа к оборудованию, который опять-таки ограничен изнутри VE соображениями безопасности). Есть еще некоторые ограничения, присущие той или иной реализации. Например, обычно в VE в любой момент возможен прямой административный доступ к файлам из основной ОС, тогда как в типовых ВМ-реализациях он осуществим только по сети, если это сконфигурировал администратор соответствующей ВМ; и наоборот, в ВМ есть возможность сделать "снимок" состояния системы для дальнейшего возвращения к нему (snapshot), а в VE это обычно делается по-другому.

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

Другие продукты

Среди других продуктов, уже используемых на рынке, выделяется своей потенциально высокой эффективностью система Solaris 10 с технологией Solaris Containers, представленная компанией Sun Microsystems в 2004 г. Но это средство по своей сути связано со спецификой данной ОС, поэтому оно менее универсально и получило пока меньшее распространение, чем упомянутые технологии виртуализации.

Различные подходы к виртуализации для разных задач

Обобщая приведенные материалы, можно утверждать, что, безусловно, сегодня нельзя предугадать развитие технологий виртуализации и сказать, какие продукты останутся, а какие уйдут с рынка через несколько лет. Ситуация может довольно резко измениться с выходом новых процессоров, все более полно поддерживающих виртуализацию, и новых версий ОС, прежде всего Windows (особенно если разработчики начнут учитывать и поддерживать возможность "гостевого режима"), или вследствие возникновения каких-либо лицензионных споров, затрагивающих эти технологии, между ключевыми игроками ИТ-рынка. Однако становится все более очевидно, что различные подходы к виртуализации имеют свои ниши и области применения. Так, например, высокоуровневая виртуализация удобна для поддержки высокомасштабируемых серверных решений с большим количеством приложений, работающих на однотипных ОС, тогда как полная виртуализация хороша для тестовых задач и задач отладки.

С уверенностью можно утверждать лишь одно: мы видим новый качественный скачок в развитии ИТ-рынка, который может привести к существенным изменениям.

Александр Тормасов - канд. физ.-мат. наук, заместитель заведующего кафедрой информатики МФТИ, доцент, начальник отделения НИОКР компании SWsoft, tor@crec.mipt.ru.

 

Андрей Николаев - ассистент кафедры информатики МФТИ, navy@crec.mipt.ru.

Версия для печати