Аппаратная виртуализация — это виртуализация компьютеров как полных аппаратных платформ, определенных логических абстракций их компонентов или только функциональности, необходимой для работы различных операционных систем . Виртуализация эмулирует аппаратную среду своей хостовой архитектуры, позволяя нескольким ОС работать без изменений и изолированно. В начале программное обеспечение, которое управляло виртуализацией, называлось «программой управления», но со временем термины « гипервизор » или «монитор виртуальной машины» стали предпочтительными. [1]
Концепция
Термин «виртуализация» был придуман в 1960-х годах для обозначения виртуальной машины (иногда называемой «псевдомашиной»), термин, который сам по себе восходит к экспериментальной системе IBM M44/44X . [1] Создание и управление виртуальными машинами в последнее время также называют «платформенной виртуализацией» или «серверной виртуализацией». [2] [3]
Виртуализация платформы выполняется на заданной аппаратной платформе хост -программным обеспечением ( программой управления ), которое создает имитируемую компьютерную среду, виртуальную машину (ВМ), для своего гостевого программного обеспечения. Гостевое программное обеспечение не ограничивается пользовательскими приложениями; многие хосты позволяют выполнять полные операционные системы. Гостевое программное обеспечение выполняется так, как если бы оно работало непосредственно на физическом оборудовании, с несколькими заметными оговорками. Доступ к физическим системным ресурсам (таким как сетевой доступ , дисплей, клавиатура и дисковое хранилище ) обычно управляется на более ограничительном уровне, чем хост -процессор и системная память. Гостям часто ограничен доступ к определенным периферийным устройствам или может быть ограничен подмножеством собственных возможностей устройства, в зависимости от политики доступа к оборудованию, реализованной хостом виртуализации. [4] : 5,13
Виртуализация часто приводит к снижению производительности, как в плане ресурсов, необходимых для работы гипервизора, так и в плане снижения производительности на виртуальной машине по сравнению с запуском нативной среды на физической машине. [4] : 35,67-68
Причины виртуализации
В случае консолидации серверов многие небольшие физические серверы можно заменить одним большим физическим сервером, чтобы уменьшить потребность в более (дорогостоящих) аппаратных ресурсах, таких как ЦП и жесткие диски. Хотя оборудование консолидируется в виртуальных средах, операционные системы обычно не консолидируются. Вместо этого каждая ОС, работающая на физическом сервере, преобразуется в отдельную ОС, работающую внутри виртуальной машины. Таким образом, большой сервер может «размещать» много таких «гостевых» виртуальных машин. Это известно как преобразование Physical-to-Virtual (P2V). Средняя загрузка сервера в начале 2000-х составляла от 5 до 15%, но с принятием виртуализации эта цифра начала расти, чтобы сократить количество необходимых серверов. [5]
Помимо снижения затрат на оборудование и рабочую силу, связанных с обслуживанием оборудования, консолидация серверов может также иметь дополнительное преимущество в виде снижения потребления энергии и глобального воздействия на экологические секторы технологий. Например, типичный сервер работает на 425 Вт [6] , а VMware оценивает коэффициент снижения оборудования до 15:1. [7]
Виртуальную машину (ВМ) легче контролировать и проверять с удаленного сайта, чем физическую машину, а конфигурация ВМ более гибкая. Это очень полезно при разработке ядра и для обучения курсам операционных систем, включая запуск устаревших операционных систем, которые не поддерживают современное оборудование. [8]
Новую виртуальную машину можно подготовить по мере необходимости без необходимости предварительной покупки оборудования.
Виртуальную машину можно легко переместить с одной физической машины на другую по мере необходимости. Например, продавец, отправляющийся к клиенту, может скопировать виртуальную машину с демонстрационным ПО на свой ноутбук, без необходимости переносить физический компьютер. Аналогично, ошибка внутри виртуальной машины не наносит вреда хостовой системе, поэтому нет риска сбоя ОС на ноутбуке.
Благодаря простоте перемещения виртуальные машины можно без проблем использовать в сценариях аварийного восстановления, не беспокоясь о влиянии восстановленных и неисправных источников энергии.
Однако, когда несколько виртуальных машин одновременно работают на одном физическом хосте, каждая виртуальная машина может демонстрировать различную и нестабильную производительность, которая в значительной степени зависит от рабочей нагрузки, налагаемой на систему другими виртуальными машинами. Эту проблему можно решить с помощью соответствующих методов установки для временной изоляции между виртуальными машинами .
Существует несколько подходов к виртуализации платформ.
Примеры вариантов использования виртуализации:
Запуск одного или нескольких приложений, которые не поддерживаются хостовой ОС: виртуальная машина, работающая под управлением требуемой гостевой ОС, может разрешить запуск требуемых приложений без изменения хостовой ОС.
Оценка альтернативной операционной системы: новая ОС может работать на виртуальной машине без изменения основной ОС.
Виртуализация серверов: на одном физическом сервере можно запустить несколько виртуальных серверов, чтобы более полно использовать аппаратные ресурсы физического сервера.
Дублирование определенных сред: виртуальная машина может, в зависимости от используемого программного обеспечения виртуализации, быть дублирована и установлена на нескольких хостах или восстановлена до ранее сохраненного состояния системы.
Создание защищенной среды: если гостевая ОС, работающая на виртуальной машине, повреждена таким образом, что ее ремонт невыгоден с точки зрения затрат, например, при изучении вредоносного ПО или установке некорректно работающего программного обеспечения, виртуальную машину можно просто удалить без вреда для хост-системы, а чистую копию использовать после перезагрузки гостевой машины.
Полная виртуализация
Логическая схема полной виртуализации.
При полной виртуализации виртуальная машина имитирует достаточно оборудования, чтобы позволить немодифицированной «гостевой» ОС, разработанной для того же набора инструкций, работать изолированно. Этот подход был впервые применен в 1966 году с IBM CP-40 и CP-67 , предшественниками семейства VM .
Паравиртуализация
При паравиртуализации виртуальная машина не обязательно имитирует аппаратное обеспечение, но вместо этого (или в дополнение) предлагает специальный API, который может быть использован только путем изменения [ требуется разъяснение ] «гостевой» ОС. Чтобы это было возможно, исходный код «гостевой» ОС должен быть доступен. Если исходный код доступен, достаточно заменить конфиденциальные инструкции вызовами API VMM (например: «cli» на «vm_handle_cli()»), затем перекомпилировать ОС и использовать новые двоичные файлы. Этот системный вызов гипервизора называется «гипервызовом» в TRANGO и Xen ; он реализуется через аппаратную инструкцию DIAG («диагностика») в CMS IBM под VM [ требуется разъяснение ] (откуда произошел термин гипервизор ).
Аппаратная виртуализация
В аппаратной виртуализации оборудование обеспечивает архитектурную поддержку, которая облегчает создание монитора виртуальной машины и позволяет гостевым ОС работать изолированно. [9] Это может использоваться для поддержки как полной виртуализации, так и паравиртуализации. Аппаратная виртуализация была впервые представлена на процессорах IBM 308X в 1980 году с инструкцией Start Interpretive Execution (SIE). [10]
В 2005 и 2006 годах Intel и AMD разработали дополнительное оборудование для поддержки виртуализации, запущенной на их платформах. Sun Microsystems (теперь Oracle Corporation ) добавила аналогичные функции в свои процессоры UltraSPARC T-Series в 2005 году.
В 2006 году было обнаружено, что поддержка оборудования x86 первого поколения для 32- и 64-разрядных систем редко обеспечивает преимущества в производительности по сравнению с программной виртуализацией. [11]
Виртуализация на уровне операционной системы
При виртуализации на уровне операционной системы физический сервер виртуализируется на уровне операционной системы, что позволяет нескольким изолированным и защищенным виртуализированным серверам работать на одном физическом сервере. Среды «гостевой» операционной системы совместно используют тот же запущенный экземпляр операционной системы, что и хостовая система. Таким образом, то же ядро операционной системы также используется для реализации «гостевых» сред, и приложения, работающие в данной «гостевой» среде, рассматривают ее как автономную систему.
Восстановление после сбоев аппаратной виртуализации
План аварийного восстановления (DR) часто считается хорошей практикой для платформы виртуализации оборудования. DR среды виртуализации может обеспечить высокую скорость доступности в широком диапазоне ситуаций, которые нарушают нормальные бизнес-операции. В ситуациях, когда важна непрерывная работа платформ виртуализации оборудования, план аварийного восстановления может гарантировать выполнение требований к производительности оборудования и обслуживанию. План аварийного восстановления виртуализации оборудования включает как аппаратную, так и программную защиту различными методами, включая описанные ниже. [12] [13]
Резервное копирование на ленту для долгосрочного архивирования данных программного обеспечения
Этот распространенный метод можно использовать для хранения данных вне офиса, но восстановление данных может быть сложным и длительным процессом. Данные резервного копирования на ленте настолько хороши, насколько хороша последняя сохраненная копия. Методы резервного копирования на ленте потребуют устройства резервного копирования и постоянного хранения материала.
Репликация целых файлов и приложений
Реализация этого метода потребует программного обеспечения управления и емкости хранилища для репликации приложений и файлов данных, как правило, на одном сайте. Данные реплицируются на другой раздел диска или отдельное дисковое устройство и могут быть запланированным действием для большинства серверов и больше реализованы для приложений типа базы данных.
Аппаратное и программное резервирование
Этот метод обеспечивает наивысший уровень защиты от аварийного восстановления для решения виртуализации оборудования, обеспечивая дублирование аппаратного и программного обеспечения в двух различных географических областях. [14]
^ ab Creasy, RJ (1981). "Происхождение системы разделения времени VM/370" (PDF) . IBM . Получено 26 февраля 2013 г. .
^ Томсон, Джулиан (23 мая 2018 г.). «Виртуальные машины: введение в виртуализацию платформ». Performance Software . Получено 8 июля 2023 г. .
^ «Что такое виртуализация серверов?».
^ ab Bugnion, Edouard; Nieh, Jason; Tsafrir, Dan (2017). Аппаратная и программная поддержка виртуализации . Сан-Рафаэль, Калифорния: Morgan & Claypool Publishers. ISBN9781627056939.
^ «Старение чипов ускоряется». 14 февраля 2018 г.
^ Раджеш Чхеда; Дэн Шуковски; Стив Стефанович; Джо Тоскано (14 января 2009 г.). «Профилирование использования энергии для эффективного потребления».
^ "Обзор консолидации серверов VMware". Архивировано из оригинала 8 января 2022 г.
^ Джейсон Ниех ; Озгур Кан Леонард (август 2000 г.). «Исследование VMware». Журнал доктора Добба . Архивировано из оригинала 22 ноября 2019 г.
^ IBM System/370 Extended Architecture Interpretive Execution (PDF) (Первое издание). IBM. Январь 1984 г. SA22-7095-0 . Получено 27 октября 2022 г.
^ Кит Адамс; Оле Агесен (21–25 октября 2006 г.). Сравнение программных и аппаратных методов виртуализации x86 (PDF) . ASPLOS'06. Сан-Хосе, Калифорния, США. Архивировано из оригинала (PDF) 8 января 2022 г. Удивительно, но мы обнаруживаем, что поддержка оборудования первого поколения редко обеспечивает преимущества в производительности по сравнению с существующими программными методами. Мы приписываем эту ситуацию высоким затратам на переход VMM/гость и жесткой модели программирования, которая оставляет мало места для гибкости программного обеспечения в управлении частотой или стоимостью этих переходов.
^ "The One Essential Guide to Disaster Recovery: How to Ensure IT and Business Continuity" (PDF) . Vision Solutions, Inc. 2010. Архивировано из оригинала (PDF) 16 мая 2011 г.
^ Wold, G (2008). "Процесс планирования восстановления после стихийных бедствий". Архивировано из оригинала 15 августа 2012 года.
^ "Виртуализация аварийного восстановления, защищающая производственные системы с помощью виртуальной инфраструктуры VMware и Double-Take" (PDF) . VMware. 2010. Архивировано из оригинала (PDF) 23 сентября 2010 г.
Внешние ссылки
Введение в виртуализацию Архивировано 22 октября 2020 г. на Wayback Machine , автор Амит Сингх
Xen и искусство виртуализации, ACM, 2003, группа авторов
Программное обеспечение для виртуализации Linux
Zoppis, Bruno (27 августа 2007 г.) [1-я публикация. LinuxDevices:2007]. "Использование гипервизора для согласования GPL и проприетарного встроенного кода". Linux Gizmos . Архивировано из оригинала 24 декабря 2013 г.
.svg/1280px-Hardware_Virtualization_(copy).svg.png)