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

Матеріал з Вікіпедії — вільної енциклопедії.
Перейти до навігації Перейти до пошуку
Ця стаття є сирим перекладом з іншої мови. Можливо, вона створена за допомогою машинного перекладу або перекладачем, який недостатньо володіє обома мовами. Будь ласка, допоможіть поліпшити переклад. (жовтень 2018)

Віртуалізація апаратних засобів комп'ютера це є віртуалізація комп'ютерів, як повноцінних апаратних платформ, певних логічних абстракцій їх складових, або лише їх функціональності необхідної для запуску різних операційних систем. Віртуалізація приховує фізичні характеристики обчислювальних платформ від користувачів, представляючи натомість іншу абстрактну обчислювальну платформу.[1][2] На початку, програмне забезпечення, яке контролювало віртуалізацію називали «управляюча програма», але з плином часу термін «гіпервізор» або «монітор віртуальних машин» більш уживаним.[3]

Концепція[ред. | ред. код]

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

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

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

Причини віртуалізації[ред. | ред. код]

  • У випадку консолідації серверів, безліч дрібних фізичних серверів замінюються одним більшим фізичним серверів для збільшення використання дорогих апаратних ресурсів, таких як центральний процесор. Хоч апаратне забезпечення об'єднане, типово, що операційні системи ні. Замість цього, кожна ОС працює на фізичному сервері перетворюється в окрему ОС, що працює всередині віртуальної машини. Великий сервер «хост» може вміщувати багато таких «гостьових» віртуальних машин. Це відомо як процес розв'язки та міграції ОС фізичних серверів, додатків та даних до гостової віртуальної машини розміщеної на віртуалізованій платформі(P2V).
  • Консолідація серверів може також надати додаткову перевагу у зниженні споживання енергії. Типовий сервер працює на 425 Вт і VMware оцінює середнє об'єднання серверів в співвідношенні 10:1.
  • Віртуальна машина може бути легко контрольована і перевірена ззовні, як фізична одиниця, і його конфігурація є більш гнучкою. Це дуже корисно в розробці ядра і для викладання курсів по операційним системам.
  • Нова віртуальна машина може бути підготовлене за міру необхідності без необхідності в попередній покупці апаратного забезпечення.
  • За необхідності віртуальна машина може бути легко переміщені з одного фізичного комп'ютера на інший. Наприклад, продавець збирається до клієнта може скопіювати віртуальну машину з демонстрацією програмного забезпечення до свого ноутбука, без необхідності транспортувати фізичний комп'ютер. Точно так само, помилка у віртуальній машині не шкодить хост-системі, отже немає ніякого ризику виходу з ладу ОС на ноутбуці.
  • Через легкість переміщення, віртуальні машини можуть бути використані в сценаріях аварійного відновлення.

Тим не менше, коли кілька віртуальних машин одночасно працює на тому ж фізичному хості, кожна віртуальна машина може показувати різну і нестабільну роботу, яка сильно залежить від завантаженості накладеної на систему іншими віртуальними машинами, доки відповідні методи використовуються для тимчасової ізоляції серед віртуальних машин.

Є кілька підходів до віртуалізації платформи.

Приклади сценаріїв віртуалізації:

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


Повна віртуалізація[ред. | ред. код]

Логічна схема повної віртуалізації.

У повній віртуалізації, віртуальна машина імітує достатньо обладнання, щоб дозволити незміненій гостьовій ОС (один розроблений для того ж набору команд) для запуску в ізоляції. Цей підхід був вперше в 1966 році з IBM CP-40 і CP-67, попередників сімейства VM. Приклади поза діапазоном мейнфреймів включають: Parallels Workstation, Parallels Desktop для Mac, VirtualBox, Virtual Iron, Oracle VM, Virtual PC, Virtual Server, Hyper-V, VMware Workstation, VMware Server, VMware ESXi, QEMU, ADEOS, Mac-на-Linux, Win4BSD, Win4Lin Pro і технології Egenera vBlade.

Апаратна-підтримка віртуалізації[ред. | ред. код]

При даному типі віртуалізації апаратне забезпечення надає архітектурну підтримку, що полегшує побудову гіпервізорів і дозволяє гостьовим ОС бути запущеними в ізоляції. Апаратна підтримка віртуалізації була вперше представлена на IBM System/370 в 1972 році, для використання разом з операційною системою VM/370.

У 2005-2006 роках компанії Intel і AMD представили технології апаратної віртуалізації архітектури x86. Sun Microsystems (нині Корпорація Oracle) додали схожі особливості у своїх процесорах UltraSPARC T-серії в 2005 році. Прикладами платформ віртуалізації адаптованих до такого апаратного забезпечення відносяться KVM, VMware Workstation, VMware Fusion, Hyper-V, Windows Virtual PC, Xen Desktop для Parallels Mac, Oracle VM сервер для SPARC, VirtualBox і Parallels Workstation.

Часткова віртуалізація[ред. | ред. код]

При частковій віртуалізації включається віртуалізація адресного простору, віртуальна машина імітує кілька примірників багатьох речей з основи апаратного середовища, зокрема, адресні простори. Як правило, це означає, що всі операційні системи не можуть працювати у віртуальній машинної, щоб було ознакою повної віртуалізації проте ця множина додатків може бути запущена. Ключова ознака часткової віртуалізації є віртуалізація адресного простору, в якій кожна віртуальна машина складається з незалежного адресного простору. Ця можливість вимагає переміщення адрес апаратного забезпечення, і присутня у більшості практичних прикладів часткового віртуалізації.

Часткова віртуалізація була важливим історичним етапом на шляху до повної віртуалізації. Вона була використана в першому поколінні систем поділу часу CTSS, в IBM M44/44X експериментальній системі поділу пам'яті на сторінки і, можливо систем таких як MVS і Commodore 64 (пари програм «перемикач завдань»). Термін також може бути використаний для опису будь-якої операційної системи, яка забезпечує окремі адресні простори для окремих користувачів або процесів, у тому числі багатьох, що сьогодні не буде розглянутих як системи віртуальних машин. Досвід роботи з частковою віртуалізації, і її обмеженнями привели до створення першої системи повної віртуалізації (IBM, СР-40, першай ітерація CP/CMS, який в кінцевому рахунку стане ВМ сім'ї IBM).

Часткова віртуалізація значно простіша в реалізації, ніж повна віртуалізація. Вона часто надає корисні, надійні віртуальні машини, здатні підтримувати важливі програми. Часткова віртуалізації виявилася вельми успішною для передачі комп'ютерних ресурсів між декількома користувачами.

Тим не менше, в порівнянні з повною віртуалізацією, її недоліком є ​​в ситуаціях, що вимагають зворотної сумісності або переносимості. Може бути важко передбачити, які саме особливості були використані в даному додатку. Якщо певні апаратні особливості не були змодельовані, то будь-яка програма, що буде використовувати ці функції не буде працювати.

Пара-віртуалізація[ред. | ред. код]

У пара-віртуалізації, віртуальна машина не повинна моделювати апаратне забезпечення, але натомість пропонує спеціальні API, які можуть бути використані тільки шляхом зміни гостьової ОС. Щоб це було можливим, вихідний код гостьової ОС повинен бути доступний. Якщо вихідний код доступний, досить замінити уразливі інструкції з викликами API, VMM (наприклад: «CLI» з «vm_handle_cli ()»), а потім перекомпілювати ОС і використовувати нові виконавчі файли. Цей системний виклик до гіпервізора називається «гіпер-виклик» в TRANGO і Xen; це реалізовано через DIAG за допомогою апаратних інструкцій в CMS IBM під VM (який був вихідною точкою терміну гіпервізор). Приклади включають в себе: IBM's LPARs, Win4Lin 9x, Sun's Logical Domains, z/VM and TRANGO.

Віртуалізація на рівні ОС[ред. | ред. код]

У віртуалізації на рівні операційної системи, фізичний сервер віртуалізований на рівні операційної системи, даючи змогу запустити на одному фізичному сервері декілька ізольованих і захищених віртуальних серверів. Середовища гостьової операційної системи поширюють один і той же запущений екземпляр операційної системи як хост-системи. Отже, те ж саме ядро ​​операційної системи також використовується для виконання гостьових середовищ і програм, що працюють в даному гостьовому середовищі виглядаючи як автономна система. Першим хто це релізував були FreeBSD jails; інші приклади включають Solaris Containers, OpenVZ, Linux-VServer, LXC, AIX Workload Partitions, Parallels Virtuozzo Containers, and iCore Virtual Accounts.

Апаратна віртуалізація аварійного відновлення[ред. | ред. код]

План Аварійного відновлення (АВ) хороша бізнес практика для рішення апаратної віртуалізації платформ. АВ середовища віртуалізації може забезпечувати високий рівень доступності для широкому діапазоні ситуацій, які порушують нормальну діяльність. Продовження операцій віртуальних машин є критично важливим і АВ може компенсувати занепокоєння продуктивності апаратного забезпечення та вимог до технічого обслуговування. Апаратна віртуалізація Ав середовища містить в собі апаратні і програмні рішення захисту на основі безперервних потреб бізнесу, які включають методи, описані нижче.

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

Цей поширений метод може бути використаний для позасайтового зберігання даних, але процес відновлення ваших даних може бути важкий і довготривалий. Стрічки резервного копіювання даних є настільки хорошими, як остання збережена копія. Методи резервного копіювання на стрічку вимагають відповідних пристроїв резервного копіювання і поточний матеріал для зберігання.

Цілий-файл і реплікація додатків

Реалізація цього методу вимагає управління та програмне забезпечення можливості для зберігання та застосування реплікації зберігання файлів даних зазвичай на тому ж сайті. Дані репликуються на інший розділ диска або окремого пристрою диска і може бути заплановано діяльність для більшості серверів і реалізується більше для додатків баз даних типу.

Апаратна і програмна надмірність

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

Примітки[ред. | ред. код]

  1. ↑ Turban, E; King, D.; Lee, J.; Viehland, D. (2008). 19. Electronic Commerce A Managerial Perspective (PDF) (вид. 5th). Prentice-Hall. с. 27. Архів оригіналу (PDF) за 21 травня 2009. Процитовано 22 листопада 2015.
  2. ↑ Virtualization in education (PDF). IBM. October 2007. Архів оригіналу (PDF) за 25 грудня 2010. Процитовано 6 July 2010.
  3. ↑ Creasy, R.J. (1981). The Origin of the VM/370 Time-sharing System (PDF). IBM. Архів оригіналу (PDF) за 7 травня 2016. Процитовано 26 February 2013.

Див. також[ред. | ред. код]

Література[ред. | ред. код]

Посилання[ред. | ред. код]

Отримано з https://uk.wikipedia.org/w/index.php?title=Апаратна_віртуалізація&oldid=40517679