Початок: Наскільки корисними є вкладені гості KVM?

1. Про що це? Віртуальні машини з KVM - це добре перевірена та зріла технологія в Linux. Гості KVM...
2. Налаштування гіпервізора на фізичне обладнання
3. Налаштування гостей
4. Бенчмаркінг гостей
5. Ефективність читання блоку бенчмаркінгу
6. Ефективність процесорного процесора
7. Ефективність роботи мережі
8. Заключні думки

Про що це?

Віртуальні машини з KVM - це добре перевірена та зріла технологія в Linux. Гості KVM використовуються в багатьох місцях, щоб абстрагувати операційну систему з апаратного забезпечення нижче. Гостей можна зробити знімок / відновити, перенести на інші гіпервізори та багато іншого.

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

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

У той час як Red Hat зараз виконує певний рівень якості для каскадного КВМ, ми не підтримуємо його - тому він явно не призначений для використання у виробництві. У цій статті я оптимізую для швидкого розгортання, а не для надійності даних, наприклад, диски гостей налаштовані на "кеш = небезпечно" - що Red Hat не підтримує виробничі системи. Завдяки цьому час встановлення гостя першого рівня (гість1) швидкості встановлення скорочується на 30-40%. З іншого боку, єдиний спосіб забезпечити синхронізацію даних гостей на диску - це вимкнення гостя та використання "синхронізації".

Примітка редактора: для пояснення після публікації початкового блогу додано наступний параграф:

Якщо ви хочете зробити знімок або перенести наживо гостя L1 (батьків), переконайтеся, що базові гості (L2, дитина) не працюють. Якщо це зробити без належного вимкнення гостей L2, це призведе до аварії L1 гостя або його міграції не вдасться. Гостей L2 можна переселити без проблем.

Навіщо хотіти використовувати вкладених гостей?

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

Останнім часом ще більш складні налаштування потребують віртуалізації. Налаштування OpenShift зазвичай складаються з декількох вузлів з різними ролями. Протягом багатьох років ці системи віртуалізувались як окремі гості KVM на гіпервізорі, але тоді також часто доводиться встановлювати складні макети мережі безпосередньо на гіпервізорі. Середовища OpenStack складаються з ще більшої кількості систем та складних налаштувань мережі між вузлами.

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

А може, ви просто хочете реалізувати xkcd 350 з віртуальними гостями та хочуть отримати додатковий шар для безпеки. :)

Налаштування гіпервізора на фізичне обладнання

Процесорні процесори AMD роблять більшість віртуалізації безпосередньо в процесорі, вкладення доступне вже досить тривалий час та включено за замовчуванням. Я буду тут використовувати тестування апаратної віртуалізації Intel для тестування. Моя система також підтримує VT-d, тому можливе введення. Наступні спеціальні параметри модуля використовуються для модуля ядра kvm-intel:

[root @ fedora ~] # cat /etc/modprobe.d/kvm_intel.conf параметри kvm-intel вкладено = 1 параметр kvm-intel enable_shadow_vmcs = 1 параметр kvm-intel enable_apicv = 1 параметр kvm-intel ept = 1 [root @ fedora ~] #

Fedora 26 виступає тут як гіпервізор на апаратному забезпеченні, я називаю це гостем0. Я використовую virt-install та kickstart для розгортання Red Hat Enterprise Linux 7.4 у своїх гостях KVM. Після розгортання гостя з Red Hat Enterprise Linux 7.4 я готую гостя до вкладеного KVM і запускаю гостя наступного рівня всередину. Назвемо ці каскадні системи guest1, guest2 та guest3.

Налаштування гостей

У гостях я встановлюю KVM та virt-install, налаштовую NAT, щоб гість міг дістатися до мого сервера kickstart, розміщеного на guest0, та встановити наступного гостя. Цей приклад налаштування guest2 поверх gost1.

[root @ guest1 ~] # yum встановити qemu-kvm virt-install libvirt [root @ guest1 ~] # systemctl start libvirtd [root @ guest1 ~] # iptables -A POSTROUTING -t nat -o eth0 \ -s 192.168.122.0/ 24 -j MASQUERADE [root @ guest1 ~] # qemu-img create -f qcow2 \ -o preallocation = метадані, compat = 1.1 /tmp/image.qcow2 36G [root @ guest1 ~] # chown qemu /tmp/image.qcow2 [root @ guest1 ~] # virt-install -n guest2 -r 4096 --vcpus 2 --cpu хост \ --диск шлях = / tmp / image.qcow2, format = qcow2, bus = virtio, cache = небезпечний \ - -локація http://192.168.4.1/repos/rhel-7.4 - меню завантаження = увімкнено, useserial = on \ --графіка немає - консоль pty --os-варіант rhel7 \ - мережевий міст = virbr0, model = virtio --extra-args "ip = 192.168.122.2 ksdevice = eth0 netmask = 255.255.255.0 ks = http: //192.168.4.1/ks/guest2 шлюз = 192.168.122.1 nameserver = 10.0.0.23 repo = http: //192.168 .4.1 / repos / rhel-7.4 / console = tty0 console = ttyS0,115200n8 net.ifnames = 0 "

Бенчмаркінг гостей

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

Я призначив гостям 2 ядра, 4 Гб оперативної пам’яті та тонкий передбачений диск qcow2 і виміряв час початку роботи. Я виміряв 2 налаштування, тонку і велику установку з більшою кількістю пакетів.

тонка установка

(483 пакети)

більший монтаж

(1141 пакетів)

гість1

221 сек

422 секунди

гість2

370 секунд

511 секунди

гість3

1297 секунд

1984 секунд

Ми бачимо досить уповільнений час встановлення для гостя3, тут установка дуже схожа на використання модему в старі часи та вхід у систему BBS . Тож слід уважно розглянути, чи дійсно потрібен гість3 чи прийнятний один шар менше.

Ефективність читання блоку бенчмаркінгу

Тут я дивився на швидкість читання блокового пристрою кореневого диска. Для guest0, системи Fedora, я переглянув / dev / sda, який підтримується SSD.

Для цих тестів

• Я скинув усі схованки у гостя

• Прочитайте 3 рази однакові дані з дискового пристрою (без кешу, що пропадає між ними)

• І вимірювали швидкість зчитування даних

Я вимірював швидкість читання для кількох розмірів даних між 1 і 32 ГБ.

Показання холодного кешу вимірюються порожнім кешем на вимірювальній системі. SSD гіпервізора читає дані зі швидкістю близько 550 Мбіт / с, незалежно від того, скільки даних зчитується. Гостьові [1-3] системи віртуалізовані, тому кеш у нижченаведеній системі вражає - і допомагає guest1 та guest2 домогтися кращих показників, ніж сам гіпервізор.

Це читання з теплими кешами. Гості (крім guest3) демонструють продуктивність, досить схожу на гіпервізор. У цьому тесті гості мали різні розміри оперативної пам’яті, тому вони продовжували працювати, поки вони могли обслуговувати кешовані дані з оперативної пам’яті: guest0 мав 20 ГБ, гість1 12 ГБ, гість2 8 ГБ та гість3 4 ГБ оперативної пам’яті.

Ефективність процесорного процесора

Для еталону процесора було обчислено хеш sha256 файлу 2 Гб, заповнений даними з / dev / urandom.

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

Виконання Guest0 (гіпервізор), guest1 та guest2 майже однакове, тому одиночні еліпси, що ілюструють тривалість тестових пробіжок, важко розрізнити на графічному графіку. Guest3 був набагато повільнішим, а також продуктивність була менш передбачуваною.

Друга графіка - це порівняння часу, необхідного для виконання великого циклу оболонки bash. Від гостя0 (гіпервізор) до гостя1 нам потрібно 29% більше часу, від гостя1 до гостя2 6%. Від guest2 до guest3 нам потрібно на 140% більше часу.

Ефективність роботи мережі

Для дослідження пропускної спроможності мережі було запропоновано ізотодне зображення Fedora 2,5 Гб через HTTP. Налаштування мережі використовували звичайні мости Linux та драйвер virtio_net. Спочатку було перевірено, що файл знаходиться в кеш-пам'яті гіпервізорів, потім було виміряно пропускну здатність для гостей.

У всіх випадках найвища пропускна здатність була досягнута при доступі до послуги HTTP безпосередньо із системи, що приймає послугу. Для guest0, guest1 та guest3 ми також бачимо, що доступ із сусідніх шарів досить швидкий, але чим далі, тим нижче пропускна здатність. Guest3 досягає значно нижчої пропускної здатності.

Заключні думки

• На даний момент Red Hat не підтримує вкладений KVM, він не призначений для виробництва. Мої параметри тестування тут були зосереджені на розробці / тестових середовищах та швидкому виконанні, ціною надійності.

• продуктивність гостей0, 1 і 2 в основному порівнянна. Можливе обертання гостя3, але продуктивність досить обмежена. Тому розгортання складних налаштувань, таких як середовища OpenShift всередині гостя1, включаючи декілька систем2, може мати сенс для тестування / розробки.

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

Крістіан Горн - Red Hat AMC TAM в Токіо. AMC посилається на критичну програму Red Hat Advanced Mission Critical , де партнери разом з Red Hat надають підтримку для систем, які особливо важливі для компаній та бізнесу. У своїй роботі інженера / архітектора Linux в Німеччині з 2001 року, пізніше як Red Hat TAM в Німеччині та Японії, віртуалізація, операції та налаштування продуктивності є одними з повертаючих тем цієї щоденної роботи.

А Менеджер технічних рахунків Red Hat (TAM) - це спеціалізований експерт із продуктів, який співпрацює з ІТ-організаціями, щоб стратегічно планувати успішні розгортання та допомагати реалізувати оптимальну ефективність та зростання. TAM є частиною світового класу Red Hat Досвід та взаємодія з клієнтами організація та надає проактивні поради та рекомендації, які допоможуть вам визначити та вирішити потенційні проблеми до їх виникнення. Якщо виникає проблема, ваш TAM буде власником проблеми та залучатиме найкращі ресурси для її вирішення якнайшвидше з мінімальними перешкодами для вашого бізнесу.

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