Аппаратная виртуализация - Hardware virtualization

Аппаратная виртуализация это виртуализация из компьютеры как полные аппаратные платформы, определенные логические абстракции их компонентов или только функциональные возможности, необходимые для запуска различных операционные системы. Виртуализация скрывает физические характеристики вычислительной платформы от пользователей, вместо этого представляя абстрактную вычислительную платформу.[1][2] Первоначально программное обеспечение, управляющее виртуализацией, называлось «управляющей программой», но в терминах «гипервизор "или" монитор виртуальной машины "со временем стал предпочтительнее.[3]

Концепция

Термин «виртуализация» был придуман в 1960-х для обозначения виртуальная машина (иногда называемый «псевдо-машиной»), термин, восходящий к экспериментальному IBM M44 / 44X система.[нужна цитата ] В последнее время создание виртуальных машин и управление ими стали называть «виртуализацией платформы» или «виртуализацией серверов».

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

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

Причины виртуализации

  • В случае сервер При консолидации многие небольшие физические серверы заменяются одним большим физическим сервером, чтобы уменьшить потребность в более (дорогостоящих) аппаратных ресурсах, таких как процессоры и жесткие диски. Хотя оборудование консолидировано в виртуальных средах, обычно ОС - нет. Вместо этого каждая ОС, работающая на физическом сервере, преобразуется в отдельную ОС, работающую внутри виртуальной машины. Таким образом, большой сервер может «размещать» множество таких «гостевых» виртуальных машин. Это известно как Из физического в виртуальный (P2V) преобразование.
  • Помимо снижения затрат на оборудование и трудозатрат, связанных с обслуживанием оборудования, консолидация серверов может также иметь дополнительное преимущество в виде снижения энергопотребления и глобального воздействия на экологические секторы технологий. Например, типичный сервер работает на 425 Вт.[4] а VMware оценивает коэффициент уменьшения аппаратного обеспечения до 15: 1.[5]
  • Виртуальной машиной (ВМ) легче управлять и проверять с удаленного сайта, чем с физической машины, а конфигурация ВМ более гибкая. Это очень полезно при разработке ядра и для обучения курсам по операционным системам, включая работу с устаревшими операционными системами, которые не поддерживают современное оборудование.[6]
  • При необходимости новую виртуальную машину можно подготовить без предварительной покупки оборудования.
  • При необходимости виртуальную машину можно легко перенести с одной физической машины на другую. Например, продавец, идущий к покупателю, может скопировать виртуальную машину с демонстрационным программным обеспечением на свой портативный компьютер без необходимости транспортировки физического компьютера. Точно так же ошибка внутри виртуальной машины не вредит хост-системе, поэтому нет риска сбоя ОС на ноутбуке.
  • Благодаря простоте перемещения виртуальные машины можно легко использовать в аварийное восстановление сценарии без проблем с воздействием восстановленных и неисправных источников энергии.

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

Есть несколько подходов к виртуализации платформы.

Примеры вариантов использования виртуализации:

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

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

Основная статья: Полная виртуализация
Логическая схема полной виртуализации.

При полной виртуализации виртуальная машина имитирует достаточно оборудования, чтобы позволить немодифицированной «гостевой» ОС, предназначенной для того же Набор инструкций работать изолированно. Этот подход был впервые применен в 1966 году в IBM CP-40 и CP-67, предшественники ВМ семья.

Аппаратная виртуализация

Основная статья: Аппаратная виртуализация

При аппаратной виртуализации аппаратное обеспечение обеспечивает архитектурную поддержку, которая облегчает создание монитора виртуальных машин и позволяет изолированно запускать гостевые ОС.[7] Аппаратная виртуализация была впервые представлена ​​в IBM System / 370 в 1972 году для использования с VM / 370, первой операционной системой виртуальных машин.

В 2005 и 2006 гг. Intel и AMD предоставил дополнительное оборудование для поддержки виртуализации. Sun Microsystems (сейчас Корпорация Oracle ) добавили аналогичные функции в свои UltraSPARC серии T процессоров в 2005 году.

В 2006 году было обнаружено, что поддержка 32- и 64-разрядного оборудования x86 первого поколения редко дает преимущества в производительности по сравнению с программной виртуализацией.[8]

Паравиртуализация

Основная статья: Паравиртуализация

При паравиртуализации виртуальная машина не обязательно имитирует оборудование, но вместо этого (или в дополнение) предлагает специальный API, который можно использовать только путем изменения[требуется разъяснение ] «гостевая» ОС. Для этого должен быть доступен исходный код «гостевой» ОС. Если доступен исходный код, достаточно заменить важные инструкции вызовами API-интерфейсов VMM (например: «cli» на «vm_handle_cli ()»), затем повторно скомпилировать ОС и использовать новые двоичные файлы. Этот системный вызов гипервизор называется "гипервызовом" в ТРАНГО и Xen; это реализовано с помощью аппаратной инструкции DIAG («диагностировать») в IBM CMS под ВМ[требуется разъяснение ] (откуда произошел термин гипервизор)..

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

Основная статья: Виртуализация на уровне операционной системы

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

Аварийное восстановление аппаратной виртуализации

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

Ленточное резервное копирование для долгосрочного архивирования данных программного обеспечения
Этот распространенный метод можно использовать для хранения данных вне офиса, но восстановление данных может оказаться сложным и длительным процессом. Данные резервного копирования на магнитную ленту пригодны для хранения последней копии. Для методов резервного копирования на ленту потребуется устройство резервного копирования и постоянный материал для хранения.
Репликация целых файлов и приложений
Реализация этого метода потребует управляющего программного обеспечения и емкости хранилища для репликации приложений и файлов данных, как правило, на одном сайте. Данные реплицируются на другой раздел диска или отдельное дисковое устройство и могут быть запланированы для большинства серверов и реализованы в большей степени для приложений типа базы данных.
Аппаратное и программное резервирование
Этот метод обеспечивает высочайший уровень защиты от аварийного восстановления для решения аппаратной виртуализации за счет дублирования аппаратной и программной репликации в двух различных географических областях.[11]

Смотрите также

Рекомендации

  1. ^ Тюрбан, E; King, D .; Lee, J .; Филанд, Д. (2008). «19». Электронная коммерция: управленческая перспектива (PDF) (5-е изд.). Прентис-Холл. п. 27.
  2. ^ «Виртуализация в образовании» (PDF). IBM. Октябрь 2007 г.. Получено 6 июля 2010.
  3. ^ Кризи, Р.Дж. (1981). «Происхождение системы разделения времени VM / 370» (PDF). IBM. Получено 26 февраля 2013.
  4. ^ [1] Профилирование использования энергии для эффективного потребления; Раджеш Чхеда, Дэн Шуковски, Стив Стефанович и Джо Тоскано
  5. ^ Обзор консолидации серверов VMware
  6. ^ Изучение VMware Журнал доктора Добба, август 2000 г. Автор Джейсон Ние и Озгур Джан Леонард
  7. ^ Uhlig, R. et al .; «Технология виртуализации Intel», Компьютер, том 38, № 5, стр. 48-56, май 2005 г.
  8. ^ Сравнение программных и аппаратных технологий для виртуализации x86, Кейт Адамс и Оле Агесен, VMware, ASPLOS’06, 21–25 октября 2006 г., Сан-Хосе, Калифорния, США «Удивительно, но мы обнаружили, что поддержка оборудования первого поколения редко дает преимущества в производительности по сравнению с существующими программными технологиями. Мы объясняем эту ситуацию высокими затратами на переход между VMM и гостевой системой и жесткой моделью программирования, которая оставляет мало места для гибкости программного обеспечения при управлении частотой или стоимость этих переходов ».
  9. ^ «Основное руководство по аварийному восстановлению: как обеспечить непрерывность ИТ и бизнеса» (PDF). Vision Solutions, Inc. 2010. Архивировано с оригинал (PDF) 16 мая 2011 г.
  10. ^ Уолд, G (2008). «Процесс планирования аварийного восстановления». Архивировано из оригинал 15 августа 2012 г.
  11. ^ «Виртуализация аварийного восстановления, защищающая производственные системы с помощью виртуальной инфраструктуры VMware и Double-Take» (PDF). VMware. 2010. Архивировано с оригинал (PDF) 23 сентября 2010 г.

внешняя ссылка