OpenVZ

Ядро OpenVZ — це модифіковане ядро Linux, що додає концепцію віртуального середовища (VE). Ядро забезпечує віртуалізацію, ізоляцію, управління ресурсами та чекпоїнтінг (збереження поточного стану VE).

Кожна VE — це окрема сутність і з погляду власника VE вона виглядає практично як звичайний фізичний сервер. Кожна VE має свої власні:

• Файли

Системні бібліотеки, застосунки, віртуалізовані ФС /proc и /sys, віртуалізовані блокування тощо.

• Користувачі та групи

Свої власні користувачі та групи, включаючи root.

• Дерево процесів

VE бачить тільки власні процеси (починаючи з init). Ідентифікатори процесів (PID) також віртуалізовани, тому PID програми init — 1, як і повинно бути.

• Мережу

Віртуальний мережевий пристрій (venet), що дозволяє VE мати свої власні IP-адреси, набори правил маршрутизації та фаєрвол (netfilter/iptables).

• Пристрої

За необхідності адміністратор OpenVZ сервера може дозволити VE доступ до реальних пристроїв, як мережеві адаптери, порти, розділи диска тощо.

• Об'єкти IPC

Пам'ять, що розподіляється, семафори, повідомлення.

Управління ресурсами в OpenVZ складається з трьох компонентів: дворівнева дискова квота, чесний планувальник процесора, і т. зв. юзербінкаунтери (англ. user beancounters). Ці ресурси можуть бути змінені під час роботи VE, перезавантаження не потрібне.

Адміністратор OpenVZ сервера може встановити дискові квоти на VE, в термінах дискового простору та кількості айнодів (англ. i-nodes), число яких приблизно дорівнює кількості файлів. Це перший рівень дискової квоти.

На додаток до цього, адміністратор VE (root) може використовувати звичайні утиліти всередині своєї VE для налаштувань стандартних дискових квот UNIX для користувачів і груп.

Планувальник процесора в OpenVZ також дворівневий. На першому рівні планувальник вирішує, якому VE дати квант процесорного часу, базуючись на значенні параметра cpuunits для VE. На другому рівні стандартний планувальник Linux вирішує, якому процесу у вибраному VE дати квант часу, базуючись на стандартних пріоритетах процесу в Linux тощо.

Адміністратор OpenVZ сервера може встановлювати різні значення cpuunits для різних VE, і процесорний час розподілятиметься відповідно до співвідношення призначених для VE величин .

Також є параметр обмеження — cpulimit, що встановлює у відсотках верхній ліміт процесорного часу, який відводиться для певного VE.

User Beancounters — це набір лічильників, обмежень і гарантій на кожне VE. Є набір з приблизно 20 параметрів, які вибрані для того, щоб покрити всі аспекти роботи VE так, щоб ніяке VE не могло зловживати будь-яким обмежений для всього сервера ресурсом, таким чином перешкоджаючи іншим VE.

Наявні контрольовані ресурси — це, в основному, оперативна пам'ять та різні об'єкти в ядрі, н-д, сегменти пам'яті IPC, що розділяються, мережеві буфери тощо. Кожен ресурс можна подивитися у файлі /proc/user_beancounters — для нього є п'ять значень: поточне використання, максимальне використання (за весь час життя VE), бар'єр, ліміт і лічильник відмов. Сенс бар'єру та ліміту залежить від параметра; якщо коротко, то про них можна думати як про м'який ліміт і жорсткий ліміт. Якщо якийсь ресурс намагається перевищити ліміт, його лічильник відмов збільшується — тобто власник VE може бачити, що відбувається, шляхом читання файлу /proc/user_beancounters у своєму VE.

Функціональність міграції «на льоту» та чекпоїнтінга була випущена для OpenVZ в середині квітня 2006. Вона дозволяє переносити VE з одного фізичного сервера на іншій без необхідності зупиняти/перезапускати VE. Цей процес називається чекпоїнтінг: VE «заморожується» і її повний стан зберігається у файл на диску. Далі цей файл можна перенести на іншу машину і там «розморозити» (відновити) VE. Затримка цього процесу (час, коли VE заморожена) — приблизно декілька секунд; важливо підкреслити, що це затримка в обслуговуванні, але не відмова в обслуговуванні.

Починаючи з версії 2.6.24, в ядро включено простори імен PID (англ. PID namespaces), унаслідок чого міграція «на льоту» стає «безпечною», оскільки в цьому випадку 2 процеси в різних VE зможуть мати один і той же pid.

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

Ця можливість робить реальними такі сценарії, як апгрейд сервера без необхідності його перезавантаження: наприклад, якщо СУБД потрібно більше пам'яті або потужніший процесор, купуєте нове обладнання та мігруєте VE з СУБД на нього, а потім збільшуєте ліміти на цю VE. Якщо потрібно додати оперативної пам'яті до сервера, мігруєте всі VE з цього сервера на іншій, вимикаєте сервер, встановлюєте додаткову пам'ять, запускаєте сервер і мігруєте всі VE назад.

З огляду на те, що OpenVZ використовує одне ядро для всіх VE, система є такою ж масштабованою, як і звичайне ядро Linux 2.6, тобто підтримує до 64-ти процесорів та до 64-ти ТБ оперативної пам'яті. Єдине віртуальне середовище може бути розширене до розмірів всього фізичного сервера, тобто використовувати весь доступний процесорний час і пам'ять.

Можна використовувати OpenVZ з єдиним віртуальним середовищем на сервері. Цей підхід дозволяє VE повністю використовувати всі апаратні ресурси сервера з практично «рідною» продуктивністю, користуючись додатковими перевагами: незалежність VE від «заліза», підсистему управління ресурсами, «живу» міграцію.

 

OpenVZ здатна розміщувати сотні віртуальних середовищ на сучасному апаратному забезпеченні. Основними обмежувальними чинниками є обсяг ОЗП і швидкість процесора.

Графік справа показує залежність часу відгуку вебсерверів VE до кількості VE на машині.^{[джерело?]} Вимірювання були зроблені на машині з 768 МБ (¾ ҐБ) ОЗП; на кожній VE був запущений звичайний набір процесів: init, syslogd, crond, sshd та вебсервер Apache. Демони Apache віддавали статичні сторінки, які закачувалися утилітою http_load, і при цьому вимірювався час першого відгуку. Як можна бачити, при збільшенні кількості VE час відгуку стає більше — це відбувається зважаючи на брак оперативної пам'яті та значного своппінгу.

У цьому сценарії можливо запустити до 120 таких VE на машині з ¾ ҐБ ОЗП. Оскільки при збільшенні обсягу оперативної пам'яті щільність зростає практично лінійно, можна екстраполювати, що на машині з 2 ҐБ пам'яті можливо запустити приблизно 320 таких VE, за умови збереження хорошої продуктивності.

Власник фізичного сервера з OpenVZ (root) може бачити всі процеси і файли всіх VE. Ця особливість робить можливим масове управління, на відміну від інших технологій віртуалізації (напр. VMware чи Xen), де віртуальні сервери є окремою сутністю, якою неможливо безпосередньо керувати з хост-системи.

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

Безпека

Використовуйте окремі VE для кожного мережевого сервісу (напр. таких, як вебсервер, поштовий сервер, DNS сервер тощо). У випадку, якщо гакер знаходить і використовує вразливість в одному із застосунків, щоб потрапити до системи, все, що він зможе зламати, це той самий сервіс з уразливістю — решта сервісів знаходяться в окремих ізольованих VE, до яких він не матиме доступу.

Консолідація серверів

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

Хостинг

Схоже, що віртуалізація на рівні ОС — це єдиний тип віртуалізації, який можуть собі дозволити гостинг-компанії, щоб продавати дешеві (н-д, за ціною $5…15 у місяць) віртуальні середовища для своїх клієнтів. Відмітьте при цьому, що ці дешеві VE мають повний рутовий доступ, а значить, власник VE може перевстановити усе, що завгодно, і навіть використовувати такі можливості, як власний брандмауер.

Розробка і тестування ПЗ

Зазвичай розробникам та тестувальникам програмного забезпечення під GNU/Linux потрібний доступ до безлічі різних дистрибутивів, і у них часто виникає необхідність перевстановлення дистрибутивів з нуля. Використовуючи OpenVZ, вони можуть отримати все це на одному сервері, без необхідності перезавантажень і з «рідною» продуктивністю. Нову «машину» можна створити за хвилину. Клонувати VE теж дуже просто — потрібно всього лише скопіювати файли VE, а також її конфігураційний файл.

Освіта

Кожен студент може отримати віртуальне середовище з правами адміністратора, у якому можна інсталювати різні дистрибутиви GNU/Linux.

Інші реалізації технології віртуалізації на рівні операційної системи: LXC, Linux-VServer, FreeBSD Jails, Solaris Containers, VDSmanager

В ролі «гостьової» системи, можуть виступати лише різні дистрибутиви Linux.

Усі контейнери використовують один і той же своп-розділ. Свопінг обмежений лише побічно (параметром privvmpages, який по суті включає ОЗП та своп).^{[джерело?]}

• Віртуалізація на рівні операційної системи
• Порівняння віртуальних машин
• Virtuozzo^[en]

• Comparison with other virtualization techniques [Архівовано 8 березня 2007 у Wayback Machine.]
• Офіційний сайт OpenVZ [Архівовано 20 серпня 2008 у Wayback Machine.]
• Керівництво по створенню віртуальних виділених серверів на базі Virtuozzo [Архівовано 25 вересня 2008 у Wayback Machine.](рос.)