что такое виртуализация и для чего она нужна

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

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

Virtualization Technology

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

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

Сегодня, область практического применения, это технологии, развиваются по трем направлениям:

Виртуализация представлений

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

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

Виртуализация устройств

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

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

Виртуализация приложений

Программа запускается в изолированной среде и никак не контактирует с «внешним миром», поэтому не конфликтует и не наносит вреда другим приложениям. Таким же способом можно запустить разные версии одной и той же программы.

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

Надо ли вам это

Зачем такая замечательная технология рядовому юзеру, что дает она и дает ли вообще? По большому счету, незачем, и поддержка виртуализации в процессоре домашнего ПК – скорее дань трендам, чем насущная необходимость.

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

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

Дело в маркетинге – за поддержку виртуализации, некоторые готовы выложить лишние деньги, не понимая толком, что такое им хотят продать.

Как включить виртуализацию

Активировать эту опцию можно в БИОСе (при условии, что она не включена изначально). Как включить: при перезагрузке компьютера нажать кнопку Del или F2 (чаще всего, на некоторых материнских платах кнопка может быть другой) и найти в меню пункт Virtualization Technology.Где именно искать – зависит от модели и версии BIOS. Следует выбрать опцию Enabled и, сохранив изменения, перезагрузить компьютер.

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

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

Я уже упоминал в этой статье эмуляторы Android. Да, это виртуальные устройства с поддержкой виртуальной же ОС, поэтому для нормальной их работы, поддержка виртуализации таки необходима. В противном случае даже простенькие приложения будут дико тормозить – впрочем, как и сам Андроид, запущенный в среде Виндовс.

Отдельного упоминания эмуляторы заслуживают потому, что в последнее время они стали очень популярны. Несмотря на то, что почти в каждой семье уже есть планшет и несколько смартфонов, в некоторые игры удобнее играть с помощью клавиатуры и мышки – например, в PUBG Mobile.

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

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

Источник

Технология виртуализации в процессоре

Содержание

Содержание

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

Зачем нужна виртуализация на домашнем компьютере

Вот простой пример: вы используете для работы и игр Windows, но при этом хотите изучить, например, Linux. Значит, нужно, чтобы эта операционная система находилась под рукой. Или занимаетесь программированием под Android или iOS. В этом случае постоянно требуется проверка разработанного приложения в родной среде.

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

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

Виртуализация в бизнесе

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

Например, ваша организация собирается поставить почтовый сервер для обработки поступающей и исходящей переписки, а еще развернуть DNS и WEB-сервер. Сколько для этого нужно серверных машин? Достаточно одной. Потому что на ней, в виртуально разделенных друг от друга «песочницах», на одном и том же железе заработают как бы три отдельных компьютера, выполняющие каждый свою задачу. Так вы разместите на одном компьютере сразу три отдельных сервера и используете всю мощность и производительность техники, окупив потраченные средства.

Разумеется, так как мощность и производительность серверных систем и пропускная способность каналов связи постоянно растет, у виртуализации появляется все больше возможностей для применения. Наглядный пример из относительно недавно запущенных и находящихся у всех на слуху — сервис GeForce Now, благодаря которому можно на слабых компьютерах запускать современные игры.

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

Основные направления развития виртуализации

В целом виртуализация как технология сейчас развивается по трем основным направлениям:

Как работает виртуализация

Мы разобрались с тем, что виртуализация — это хорошо и полезно. А что требуется для того, чтобы она заработала на вашем конкретном компьютере? Надо чтобы процессор поддерживал виртуализацию.

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

Такая технология есть у обоих крупных производителей процессоров для ПК: у Intel она называется Intel VT, у AMD — AMD –V.

Особенности Intel VT

Впервые о разработке технологии виртуализации компания Intel объявила еще в 2005 году. И с тех пор Intel VT постоянно совершенствуется и расширяется.

Корпорация Intel описывает Intel VT как технологию, развивающую несколько основных направлений. На сегодня это:

Особенности AMD–V

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

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

Включение виртуализации на компьютере

Непосредственный запуск виртуальных машин выполняется с помощью специальных приложений:

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

Дело в том, что по умолчанию в настройках BIOS большинства материнских плат виртуализация отключена. И ее необходимо включить в соответствующем разделе, который называется у каждого производителя по-своему, например, «Virtualization Technology» изменив значение опции с «Disabled» на «Enabled».

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

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

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

Источник

Зачем же нужна виртуализация?

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

Типы виртуализации

Виртуализация приложений – достаточно интересное, и относительно новое направление. Рассказывать здесь подробно о нем я не буду, поскольку это тема для целой отдельной статьи. Коротко говоря, виртуализация приложений позволяет запускать отдельное приложение в своей собственной изолированной среде (иногда называется «песочница», sandbox). Такой способ помогает решить множество проблем. Во-первых – опять же безопасность: приложение, запущенное в изолированной среде – не способно нанести вред ОС и другим приложениям. Во-вторых – все виртуализированные приложения можно обновлять централизованно из одного источника. В-третьих – виртуализация приложений позволяет запускать на одном физическом ПК несколько разных приложений, конфликтующих друг с другом, или даже несколько разных версий одного и того же приложения. Более подробно о виртуализации приложений можно посмотреть, к примеру, в этом вебкасте: www.techdays.ru/videos/1325.html Возможно, однажды я даже напишу статью на эту тему.

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

Но кроме этого, виртуализация серверов может использоваться и в продакшн-среде. Причин тому много.
Виртуализация позволяет сократить количество серверов благодаря консолидации, то есть там, где раньше требовалось несколько серверов – теперь можно поставить один сервер, и запустить нужное число гостевых ОС в виртуальной среде. Это позволит сэкономить на стоимости приобретения оборудования, а так же снизить энергопотребление, а значит и тепловыделение системы – и, следовательно, можно использовать менее мощные, и, соответственно – более дешевые системы охлаждения. Но у этой медали есть и обратная сторона, и не одна. Дело в том, что при внедрении решений на базе виртуализации, скорее всего придется покупать новые сервера. Дело в том, что виртуальные сервера используют аппаратные ресурсы физического сервера, и, соответственно – понадобятся более мощные процессоры, большие объемы оперативной памяти, а так же более скоростная дисковая подсистема, и, скорее всего – большего объема. Кроме того, некоторые системы виртуализации (в частности – MS Hyper-V) требуют поддержки процессором аппаратных технологий виртуализации (Intel VT или AMD-V) и некоторых других функций процессора. Многие процессоры, которые выпускались до недавнего времени, в частности – все x86_32bit – этим требованиям не удовлетворяют, и поэтому от старых, хотя и вполне рабочих серверов придется отказаться. Однако же, один более мощный сервер скорее всего будет стоить намного дешевле нескольких менее мощных, да и старые сервера, скорее всего давно пора менять из-за морального устаревания.

Есть еще один очень важный момент: виртуализация северов позволяет до предела упростить администрирование инфраструктуры. Главное преимущество, которое оценят все сисадмины – это возможность удаленного доступа к консоли виртуальных серверов на «аппаратном», точнее – «вирутально-аппаратном» уровне, независимо от установленной гостевой ОС и ее состояния. Так, чтобы перезагрузить «зависший» сервер, теперь не нужно бежать в серверную, или покупать дорогостоящее оборудование типа IP-KVM-переключателей, достаточно просто зайти в консоль виртуального сервера и нажать кнопку «Reset». Помимо этого, виртуальные сервера поддерживают технологию моментальных снимков (о ней см. мою предыдущую статью), а так же бэкап и восстановление виртуальных систем намного легче.

Еще одно неоспоримое преимущество – ОС, запущенная внутри виртуальной машины (гостевая ОС) понятия не имеет, какое оборудование установлено на физическом сервере, внутри которого она работает (хост). Поэтому, при замене железа, при апгрейде или даже переезде на новый сервер необходимо обновить драйверы только на ОС самого хоста (хостовой ОС). Гостевые ОС по будут работать как и раньше, поскольку «видят» только виртуальные устройства.

Так же, хочется напомнить, что в виртуальной среде могут действовать особые правила лицензирования ПО (в частности, покупка лицензии на Microsoft Windows Server 2008 Enterprise позволяет использовать бесплатно четыре копии ОС в качестве гостевой, а Microsoft Windows Server 2008 Datacenter вообще разрешает использовать неограниченное число гостевых ОС при условии полного лицензирования по процессорам).

Еще нельзя не упомянуть о технологиях отказоустойчивости. Физические сервера, на которых запускаются виртуальные машины, могут быть объединены в кластер, и в случае отказа одного из серверов – автоматически «переезжать» на другой. Полной отказоустойчивости добиться не всегда возможно (в частности, в MS Hyper-V такой «внезапный переезд» будет выглядеть так же, и иметь такие же возможные последствия, как внезапное обесточивание сервера), но возможные простои сильно сократятся: «переезд» занимает несколько минут, тогда как ремонт или замена самого сервера может занять часы, а то и дни. Если же «переезд» виртуальных машин происходит в штатном режиме, то он может пройти совершенно незаметно для пользователей. Такие технологии у разных вендоров называются по-разному, к примеру у MS она называется «Live Migration», у VMware – Vmotion. Использование таких технологий позволит проводить работы, связанные с выключением сервера (к примеру – замену некоторых аппаратных компонент, или перезагрузку ОС после установки критических обновлений) в рабочее время и не выгоняя пользователей из их любимых приложений. Кроме этого, если инфраструктура построена соответствующим образом – запущенные виртуальные машины могут автоматически перемещаться на менее нагруженные сервера, или же наоборот «разгружать» наиболее загруженные. В инфраструктуре на базе технологий Microsoft для этого используются System Center Virtual Machine Manager и Operations Manager.

В заключение темы по виртуализации серверов — отмечу, что виртуализация не всегда одинаково полезна. В частности, не всегда будет хорошей идеей переносить в виртуальную среду высоконагруженные сервера, а особенно — высоконагруженные по дисковой подсистеме — это «тяжелые» СУБД, Exchange Server, особенно — роль Mailbox Server, и прочие высоконагруженные приложения. А вот сервера с меньшей нагрузкой (контроллеры доменов AD, WSUS, всевозможные System Center * Manager, веб-сервера) виртуализировать можно и даже нужно. Замечу, кстати, что именно с контроллерами доменов — очень желательно, чтобы хотя бы один из контроллеров был «железным», то есть не виртуальным. Нужно это потому, что для корректной работы всей инфраструктуры желательно, чтобы при запуске всех остальных серверов хотя бы один КД уже был доступен в сети.

Резюме

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

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

Если же вам нужно освободить место в стойке, снизить энергопотребление систем, избавиться от «серверного зоопарка» — то ваше решение – виртуализация серверов.

Недостатки – в принципе, те же, что и у терминальных решений:

Надеюсь, моя статья окажется для кого-то полезной. Благодарность и конструктивную критику, как всегда, можно высказать в комментариях.

Источник

Аппаратная виртуализация. Теория, реальность и поддержка в архитектурах процессоров

Введение

Виртуализация представляла интерес ещё до изобретения микропроцессора, во времена преобладания больших систем — мейэнфреймов, ресурсы которых были очень дорогими, и их простой был экономически недопустим. Виртуализация позволяла повысить степень утилизации таких систем, при этом избавив пользователей и прикладных программистов от необходимости переписывать своё ПО, так как с их точки зрения виртуальная машина была идентична физической. Пионером в этой области являлась фирма IBM с мэйнфреймами System/360, System/370, созданными в 1960-1970-х гг.

Классический критерий виртуализуемости

Неудивительно, что критерии возможности создания эффективного монитора виртуальных машин были получены примерно в то же время. Они сформулированы в классической работе 1974 г. Жеральда Попека и Роберта Голдберга «Formal requirements for virtualizable third generation architectures» [8]. Рассмотрим её основные предпосылки и сформулируем её основной вывод.

Модель системы

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

Классы инструкций

Достаточное условие построения монитора ВМ

Рис. 1: Выполнение условия виртуализуемости. Множество служебных инструкций является подмножеством привилегированных

Ограничения применимости критерия виртуализуемости

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

Рис. 2: Невыполнение условия виртуализуемости. Служебные, но не привилегированные инструкции требуют реализации сложной логики в мониторе

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

Структура гостевых программ

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

Периферия

Поскольку периферийные устройства являются служебным ресурсом ЭВМ, очевидно, что для обеспечения условий изоляции и эквивалентности необходимо, чтобы все попытки доступа к ним были контролируемы монитором ВМ так же, как они контролируются в многозадачной операционной системе её ядром. В настоящее время доступ к устройствам чаще всего производится через механизм отражения их в физической памяти системы (англ. memory mapped I/O), что означает, что внутри монитора это чтение/запись некоторых регионов должно или вызывать ловушку защиты памяти, или быть не служебным, т.е. не вызывать ловушку и не влиять на состояние неконтролируемым образом.
Интенсивность взаимодействия приложений с периферией может быть различна и определяется их функциональностью, что сказывается на их замедлении при виртуализации. Кроме того, монитор ВМ может делать различные классы периферии, присутствующей на хозяине, доступными внутри нескольких ВМ различными способами.

Прерывания

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

Многопроцессорные системы

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

Синхронизация и виртуализация

Введение в рассмотрение нескольких хозяйских и гостевых процессоров оставляет условие эффективной виртуализуемости в силе. Однако необходимо обратить внимание на выполнение условий эффективности работы многопоточных приложений внутри ВМ. В отличие от однопоточных, для них характерны процессы синхронизации частей программы, исполняющихся на различных виртуальных процессорах. При этом все участвующие потоки ожидают, когда все они достигнут заранее определённой точки алгоритма, т.н. барьера. В случае виртуализации системы один или несколько гостевых потоков могут оказаться неактивными, вытесненными монитором, из-за чего остальные будут попусту тратить время.
Примером такого неэффективного поведения гостевых систем является синхронизация с задействованием циклических блокировок (англ. spin lock) внутри ВМ [9]. Будучи неэффективной и поэтому неиспользуемой для однопроцессорных систем, в случае нескольких процессоров она является легковесной альтернативой другим, более тяжеловесным замкам (англ. lock), используемым для входа в критические секции параллельных алгоритмов. Чаще всего они используются внутри операционной системы, но не пользовательских программ, так как только ОС может точно определить, какие из системных ресурсов могут быть эффективно защищены с помощью циклических блокировок. Однако в случае виртуальной машины планированием ресурсов на самом деле занимается не ОС, а монитор ВМ, который в общем случае не осведомлён о них и может вытеснить поток, способный освободить ресурс, тогда как второй поток будет выполнять циклическую блокировку, бесполезно тратя процессорное время. Оптимальным решением при этом является деактивация заблокированного потока до тех пор, пока нужный ему ресурс не освободится.

Прерывания в многопроцессорных системах

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

Преобразование адресов

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

Рис. 3: Двухуровневая трансляция адресов. Первый уровень контролируется гостевыми ОС, второй — монитором виртуальных машин

Другой ресурс ЭВМ, отвечающий за преобразование адресов, — это буфер ассоциативной трансляции (англ. translation lookaside buffer, TLB), состоящий из нескольких записей. Каждая гостевая система имеет своё содержимое TLB, поэтому при смене активной ВМ или переходе в монитор он должен быть сброшен. Это негативно сказывается на производительности систем, так как восстановление его содержимого требует времени, в течение которого приходится использовать менее эффективное обращение к таблице трансляций адресов, расположенной в памяти.
Решение состоит в разделении ресурсов TLB между всеми системами [10]. Каждая строка буфера ассоциируется с идентификатором — тэгом, уникальным для каждой ВМ. При поиске в нём аппаратурой учитываются только строки, тэг которых соответствует текущей ВМ.

Преобразование адресов для периферийных устройств

Кроме процессоров к оперативной памяти напрямую могут обращаться и периферийные устройства — с помощью технологии DMA (англ. direct memory access). При этом обращения в классических системах без виртуализации идёт по физическим адресам. Очевидно, что внутри виртуальной машины необходимо транслировать такие адреса, что превращается в накладные расходы и понижение эффективности монитора.
Решение состоит в использовании устройства IOMMU (англ. Input output memory management unit), позволяющего контролировать обращения хозяйских устройств к физической памяти.

Расширение принципа

Расширим условие виртуализуемости, заменив в нём слово «инструкция» на «операция»: множество служебных операций является подмножеством привилегированных. При этом под операцией будем подразумевать любую архитектурно определённую активность по чтению или изменению состояния системы, в том числе инструкции, прерывания, доступы к устройствам, преобразования адресов и т.п.
При этом условие повышения эффективности виртуализации будет звучать следующим образом: в архитектуре системы должно присутствовать минимальное число служебных операций. Достигать его можно двумя способами: переводя служебные инструкции в разряд безвредных или уменьшая число привилегированных. Для этого большинство архитектур пошло по пути добавления в регистр состояния M нового режима r — режима монитора ВМ (англ. root mode). Он соотносится с режимом s так, как s — с u; другими словами, обновлёный класс привилегированных инструкций теперь вызывает ловушку потока управления, переводящую процессор из s в r.

Статус поддержки в современных архитектурах

Рассмотрим основные современные архитектуры вычислительных систем, используемых на серверах, рабочих станциях, а также во встраиваемых системах, с точки зрения практической реализации описанных выше теоретических принципов. См. также серию статей [5,6,7].

IBM POWER

Компания IBM была одной из первых, выведших архитектуру с аппаратной поддержкой виртуализации на рынок серверных микропроцессоров в серии POWER4 в 2001 году. Она предназначалась для создания изолированных логических разделов (англ. logical partitions, LPAR), с каждым из которых ассоциированы один или несколько процессоров и ресурсы ввода-вывода. Для этого в процессор был добавлен новый режим гипервизора к уже присутсвовавшим режимам супервизора и пользователя. Для защиты памяти каждый LPAR ограничен в режиме с отключенной трансляцией адресов и имеет доступ лишь к небольшому приватному региону памяти; для использования остальной памяти гостевая ОС обязана включить трансляцию, контролируемую монитором ВМ.
В 2004 году развитие этой архитектуры, названное POWER5, принесло серьёзные усовершенствования механизмов виртуализации. Так, было добавлено новое устройство таймера, доступное только для монитора ВМ, что позволило ему контролировать гостевые системы более точно и выделять им процессорные ресурсы с точностью до сотой доли от процессора. Также монитор ВМ получил возможность контролировать адрес доставки прерываний — в LPAR или в гипервизор. Самым важным же нововведением являлся тот факт, что присутствие гипервизора являлось обязательным — он загружался и управлял системными ресурсами, даже если в системе присутствовал единственный LPAR-раздел. Поддерживаемые ОС (AIX, Linux, IBM i) были модифицированы с учётом этого, чтобы поддерживать своеобразную паравиртуализационную схему. Для управления устройствами ввода-вывода один (или два, для балансировки нагрузки) из LPAR загружает специальную операционную систему — virtual I/O server (VIOS), предоставляющую эти ресурсы для остальных разделов.

SPARC

Компания Sun, развивавшая системы UltraSPARC и ОС Solaris, предлагала виртуализацию уровня ОС (т.н. контейнеры или зоны) начиная с 2004 г. В 2005 году в многопоточных процессорах Niagara 1 была представлена аппаратная виртуализация. При этом гранулярность виртуализации была равна одному потоку (всего чип имел восемь ядер, четыре потока на каждом).
Для взаимодействия ОС и гипервизора был представлен публичный и стабильный интерфейс для привилегированных приложений [3], скрывающий от ОС большинство архитектурных регистров.
Для трансляции адресов используется описанная ранее двухуровневая схема с виртуальными, реальными и физическими адресами. При этом TLB не хранит промежуточный адрес трансляции.

Intel IA-32 и AMD AMD64

В отличие от POWER и SPARC, архитектура IA-32 (и её расширение AMD64) никогда не была подконтрольна одной компании, которая могла бы добавлять функциональность (пара)виртуализации между аппаратурой и ОС, нарушающую обратную совместимость с существующими операционными системами. Кроме того, в ней явно нарушены условия эффективной виртуализации — около 17 служебных инструкций не являются привилегированными, что мешало создать аппаратно поддерживаемые мониторы ВМ. Однако программные мониторы существовали и до 2006 года, когда Intel представила технологию VT-x, а AMD — похожую, но несовместимую с ней AMD-V.
Были представлены новые режимы процессора — VMX root и non root, и уже существовавшие режимы привилегий 0-3 могут быть использованы в обоих из них. Переход между режимами может быть осуществлён с помощью новых инструкций vmxon и vmxoff.
Для хранения состояния гостевых систем и монитора используется новая структура VMCS (англ. virtual machine control structure), копии которой размещены в физической памяти и доступны для монитора ВМ.
Интересным решением является конфигурируемость того, какие события в госте будут вызывать событие ловушки и переход в гипервизор, а какие оставлены на обработку ОС. Например, для каждого гостя можно выбрать, будут ли внешние прерывания обрабатываться им или монитором; запись в какие биты контрольных регистров CR0 и CR4 будет перехватываться; какие исключения должны обрабатываться гостём, а какие — монитором и т.п. Данное решение позволяет добиваться компромисса между степенью контроля над каждой ВМ и эффективностью виртуализации. Таким образом, для доверенных гостей контроль монитора может быть ослаблен, тогда как одновременно исполняющиеся с ними сторонние ОС будут всё так же под его строгим наблюдением. Для оптимизации работы TLB используется описанная выше техника тэгирования его записей с помощью ASID (англ. address space identifier). Для ускорения процесса трансляции адресов двухуровневая схема трансляции получила имя Intel EPT (англ. extended page walk).

Intel IA-64 (Itanium)

Intel добавила аппаратную виртуализацию в Itanium (технология VT-i [4]) одновременно с IA-32 — в 2006 году. Специальный режим включался с помощью нового бита в статусном регистре PRS.vm. С включенным битом ранее служебные, но не привилегированные инструкции начинают вызывать ловушку и выход в монитор. Для возвращения в режим гостевой ОС используется инструкция vmsw. Часть инструкций, являющаяся служебными, при включенном режиме виртуализации генерируют новый вид синхронного исключения, для которого выделен собственный обработчик.
Поскольку операционная система обращается к аппаратуре посредством специального интерфейса PAL (англ. processor abstraction level), последний был расширен, чтобы поддерживать такие операции, как создание и уничтожение окружений для гостевых систем, сохранение и загрузка их состояния, конфигурирование виртуальных ресурсов и т.д. Можно отметить, что добавление аппаратной виртуализации в IA-64 потребовало меньшего количества усилий по сравнению с IA-32.

Архитектура ARM изначально была предназначена для встраиваемых и мобильных систем, эффективная виртуализация которых, по сравнению с серверными системами, долгое время не являлась ключевым фактором коммерческого и технологического успеха. Однако в последние годы наметилась тенденция к использованию ВМ на мобильных устройствах для обеспечения защиты критически важных частей системного кода, например, криптографических ключей, используемых при обработке коммерческих транзакций. Кроме того, процессоры ARM стали продвигаться на рынок серверных систем, и это потребовало расширить архитектуру и добавить в неё такие возможности, как поддержка адресации больших объёмов памяти и виртуализация.
Оба аспекта были отражены в избранном компанией ARM подходе к развитию своей архитектуры. На рис. 4 представлена схема, подразумевающая вложенность двух уровней виртуализации, представленная в 2010 году в обновлении архитектуры Cortex A15 [1].

Рис. 4: Виртуализация ARM. Монитор TrustZone обеспечивает изоляцию и криптографическую аутентификацию доверенного «мира». В обычном «мире» используется собственный монитор ВМ

Для обеспечения изоляции критических компонент используется первый слой виртуализации, называемый TrustZone. С его помощью все запущенные программные компоненты делятся на два «мира» — доверенный и обычный. В первой среде исполняются те части системы, работа которых не должна быть подвластна внешним влияниям обычного кода. Во второй среде исполняются пользовательские приложения и операционная система, которые теоретически могут быть скомпрометированы. Однако обычный «мир» не имеет доступа к доверенному. Монитор TrustZone обеспечивает доступ в обратном направлении, что позволяет доверенному коду контролировать состояние аппаратуры.
Второй слой виртуализации исполняется под управлением недоверенного монитора и предоставляет возможности мультиплексирования работы нескольких пользовательских ОС. В нём добавлены новые инструкции HVC и ERET для входа и выхода в/из режим(а) гипервизора. Для событий ловушки использован ранее зарезервированный вектор прерываний 0x14, добавлены новые регистры: указатель стэка SPSR, состояние виртуальных ресурсов HCR и регистр «синдрома» HSR, в котором хранится причина выхода из гостя в монитор, что позволяет последнему быстро проанализировать ситуацию и проэмулировать необходимую функциональность без избыточного чтения состояния гостя.
Так же, как это сделано в рассмотренных ранее архитектурах, для ускорения механизмов трансляции адресов используется двухуровневая схема, в которой физические адреса гостевых ОС являются промежуточными. Внешние прерывания могут быть настроены как на доставку монитору, который потом перенаправляет их в гость с помощью механизма виртуальных прерываний, так и на прямую отправку в гостевую систему.

Процессоры MIPS развивались в направлении, обратном наблюдаемому для ARM: от высокопроизводительных систем к встраиваемым и мобильным. Тем не менее, аппаратная виртуализация для неё появилась относительно недавно, в 2012 г. Архитектура MIPS R5 принесла режим виртуализации MIPS VZ [2]. Он доступен как для 32-битного, так и для 64-битного варианта архитектуры.
Добавленное архитектурное состояние позволяет хранить контекст ВМ и монитора отдельно. Например, для нужд гипервизора введена копия системного регистра COP0, независимая от копии гостя. Это позволяет оптимизировать время переключения между ними, в то время как переключение между несколькими гостевыми ОС требует обновления COP0 содержимым из памяти и является менее эффективным. Кроме того, часть бит гостевого регистра, описывающие набор возможностей текущего варианта архитектуры и потому ранее используемые только для чтения, из режима монитора доступны для записи, что позволяет ему декларировать возможности, отличные от действительно присутствующих на хозяине.
Привилегии гипервизора, операционной системы и пользователя образуют т.н. луковую (англ. onion) модель. В ней обработка прерываний идёт снаружи внутрь, т.е. сначала каждое из них проверяется на соответствие правилам монитора, затем ОС. Синхронные исключения (ловушки), наоборот, обрабатываются сперва ОС, а затем монитором.
Так же, как это сделано в рассмотренных ранее архитектурах, для ускорения механизмов трансляции адресов используют тэги в TLB и двухуровневую трансляцию в MMU. Для поддержки разработки паравиртуализационных гостей добавлена новая инструкция hypercall, вызывающая ловушку и выход в режим монитора.

Дополнительные темы

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

Уменьшение частоты и выходов в режим монитора с помощью предпросмотра инструкций

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

Таблица 1. Длительность перехода между режимами аппаратной виртуализации для различных поколений микроархитектур процессоров Intel IA-32 (данные взяты из [11])

Если прямое исполнение с использованием виртуализации оказывается неэффективным, имеет смысл переключиться на другую схему работы, например, на интерпретацию или двоичную трансляцию (см. мою серию постов на IDZ: 1, 2, 3).
На практике исполнения ОС характерна ситуация, что инструкции, вызывающие ловушки потока управления, образуют кластера, в которых две или более из них находятся недалеко друг от друга, тогда как расстояние между кластерами значительно. В следующем блоке кода для IA-32 приведён пример такого кластера. Звёздочкой обозначены все инструкции, вызывающие выход в монитор.

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

Рекурсивная виртуализация

Ситуация, когда монитор виртуальных машин запускается под управлением другого монитора, непосредственно исполняющегося на аппаратуре, называется рекурсивной виртуализацией. Теоретически она может быть не ограничена только двумя уровнями — внутри каждого монитора ВМ может исполняться следующий, тем самым образуя иерархию гипервизоров.
Возможность запуска одного гипервизора под управлением монитора ВМ (или, что тоже самое, симулятора) имеет практическую ценность. Любой монитор ВМ — достаточно сложная программа, к которой обычные методы отладки приложений и даже ОС неприменимы, т.к. он загружается очень рано в процессе работы системы, когда отладчик подключить затруднительно. Исполнение под управлением симулятора позволяет инспектировать и контролировать его работу с самой первой инструкции.
Голдберг и Попек в своей упомянутой ранее работе рассмотрели вопросы эффективной поддержки в том числе и рекурсивной виртуализации. Однако их выводы, к сожалению, не учитывают многие из упомянутых выше особенностей современных систем.
Рассмотрим одно из затруднений, связанных со спецификой вложенного запуска мониторов ВМ — обработку ловушек и прерываний. В простейшем случае за обработку всех типов исключительных ситуаций всегда отвечает самый внешний монитор, задача которого — или обработать событие самостоятельно, тем самым «спрятав» его от остальных уровней, или передать его следующему.
Как для прерываний, так и для ловушек это часто оказывается неоптимальным — событие должно пройти несколько уровней иерархии, каждый из которых внесёт задержку на его обработку. На рис. 5 показана обработка двух типов сообщений — прерывания, возникшего во внешней аппаратуре, и ловушки потока управления, случившейся внутри приложения.

Рис. 5: Рекурсивная виртуализация. Все события должны обрабатываться внешним монитором, который спускает их вниз по иерархии, при этом формируется задержка

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

Поддержка рекурсивной виртуализации в существующих решениях

Задаче аппаратной поддержки второго и более уровней вложенности виртуализации производители процессоров уделяют значительно меньше внимания, чем первому её уровню. Тем не менее такие работы существуют. Так, ещё в восьмидесятых годах двадцатого века для систем IBM/370 [13] была реализована возможность запуска копий системного ПО внутри уже работающей на аппаратуре операционной системы. Для этой задачи была введена инструкция SIE (англ. start interpreted execution) [14]. Существуют предложения об интерфейсе между вложенными уровнями виртуализации [12], который позволил бы эффективно поддерживать вложенность нескольких мониторов ВМ, и реализация рекурсивной виртуализации для IA-32 [15]. Однако современные архитектуры процессоров всё же ограничиваются аппаратной поддержкой максимум одного уровня виртуализации.

Источник