Віртуалізація Матрьошка

ІТ люблять віртуалізувати речі, дотримуючись старого правила, згідно з яким в інформатиці кожну проблему можна вирішити лише ще одним рівнем опосередкованості. Хмарні обчислення засновані на віртуалізації обчислювальних ресурсів - вам не потрібно знати, на якій фізичній машині насправді працює ваш додаток, і ви можете отримати нові, натиснувши кнопку. Раніше хмара була модним словом, однак VMware та інші віртуалізували машини на рівнях операційної системи. Останнім часом (з точки зору галасу, а не технології) контейнери приносять ще один рівень легкої віртуалізації обчислювальних ресурсів. І не забуваємо про віртуальну машину Java, яка також вимагає рівня віртуалізації. Що ми повинні робити з усіма цими рівнями віртуалізації?

Що таке віртуалізація?

Віртуалізація перетворює фізичні ресурси на логічні ресурси, які є більш гнучкими і часто доступними за запитом. Подумайте про це як про оренду автомобіля, на відміну від власності машини: ви можете орендувати кабріолет у гарну погоду, повний привід взимку та універсал (маєток) для перевезення речей. І ви платите за них лише тоді, коли вони вам потрібні. Купувати всі ці машини було б дуже неефективно, особливо коли ви рідко ними користуєтесь (я насправді володію універсалом і кабріолетом, тому я знаю). Роблячи речі віртуальними, ви можете створювати нові екземпляри чогось із існуючих ресурсів, наприклад, орендувати машину з великого басейну. У світі програмного забезпечення у нас є деякі додаткові можливості: ми можемо створювати різні операційні системи, такі як Windows або Linux, на одному і тому ж обладнанні та гіпервізорі, або можемо перетворити одну велику фізичну машину на кілька невеликих віртуальних машин. Тут аналогія з орендованим автомобілем закінчується: перетворити вагони на кабріолети набагато складніше, і один автомобіль навряд чи можна розділити на два мотоцикли.

Рівні віртуалізації

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

Однак більшість інтернет-гігантів не використовують гіпервізори всередині, оскільки вони несуть певні накладні витрати в діапазоні 5-15% і коштують чималих грошей за ліцензування, якщо ви використовуєте комерційний продукт. Якщо у вас є 100 машин, це, мабуть, не велика проблема, але якщо у вас 100 000 машин, ви хочете чогось іншого. Більшість публічних хмар використовують гіпервізори, напр. KVM для Google Compute Engine або Xen для Amazon EC2, оскільки вони повинні підтримувати декількох постачальників та версій операційних систем.

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

Віртуальна машина Java також була популяризована як вибраний рівень віртуалізації - "напиши один раз - запусти будь-де". На додаток до абстракції байтового коду, контейнери J2EE також забезпечували абстракцію під час виконання, керуючи кількома програмами, що працюють на одному сервері за допомогою пулів потоків тощо. Кілька додатків Java можна гаряче розгорнути до таких (Java) контейнерів за допомогою файлів WAR.

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

Чому ми хочемо все віртуалізувати?

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

Постачальники люблять надавати рівень віртуалізації з іншої причини: він розміщує їх прямо в середині обчислювальної екосистеми, виконуючи центральну роль, яку важко замінити. Наприклад, VMware ESX широко використовується і займає центральне місце в багатьох ІТ-інфраструктурах. Хоча апаратна віртуалізація в основному є прозорою для програми, засоби підготовки та управління не є, і це призводить до певної кількості блокування постачальника. OpenStack принесе певне полегшення в цій галузі, але термін реалізації все ще відрізняється.

Віртуалізація Матрьошка

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

Схуднення

Занадто багато шарів не тільки приносять складність та накладні витрати, але і не додають особливої вигоди. Тоді закономірне питання полягає в тому, який шар (шари) нам слід усунути. Щодо програм Java, ми, мабуть, хочемо зберегти JVM, але існує чітка тенденція до легших, вбудованих контейнерів, робота яких полягає не в тому, щоб запускати багато програм, а в одному додатку з якомога меншою абстракцією. Це знищує один рівень віртуалізації на рівні сервера додатків.

Платформи PaaS (Platform-as-a-a-service), які, як правило, використовують контейнери, починають ліквідувати рівень віртуальної машини операційної системи, розгортаючи на фізичних машинах так званий "голий метал PaaS". Вам знадобиться компонент, який управляє цими фізичними машинами, але більшу частину цього можна приховати під моделлю PaaS, що робить його в основному прозорим для розгортача додатків. OpenStack також розглядає металеву реалізацію Nova, яка працює під назвою Ironic. Все, що нам потрібно, це реалізація для відкритих обчислень, і ми готові піти.

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