Запровадження
Open source проект - Вільна платформа віртуалізації корпоративного рівня. Погортавши habr, виявив, що освітлений тут не так широко, як того заслуговує.
oVirt фактично є апстрімом для комерційної системи Red Hat Virtualization (RHV, раніше RHEV), росте під крилом Red Hat. Щоб не виникло плутанини, це НЕ те ж, що CentOS vs RHEL, модель ближче до Fedora vs RHEL.
Під капотом - , для керування використовується веб-інтерфейс. Базується на ОС RHEL/CentOS 7.
oVirt може використовуватися як для «традиційної» серверної, так і десктопної віртуалізації (VDI), на відміну від рішення VMware обидві системи можуть використовуватися в одному комплексі.
Проект добре , давно досягнув зрілості для продуктивного застосування та готовий до високих навантажень.
Ця стаття - перша в циклі про те, як побудувати працюючий відмовостійкий кластер. Пройшовши ними, ми за короткий (близько 2-х годин) отримаємо повністю працюючу систему, хоча низку питань, звичайно, розкрити не вдасться, постараюся висвітлити їх у наступних статтях.
У себе використовуємо кілька років, починали з версії 4.1. Наша промислова система зараз живе на обчислювачах HPE Synergy 480 та ProLiant BL460c 10-го покоління з Xeon Gold CPU.
На момент написання чинна версія 4.3.
Статті
- Вступ (Ми тут)
функціональні особливості
У oVirt є дві основні сутності: ovirt-engine і ovirt-host(s). Для тих, хто добре знайомий з продукцією VMware, oVirt загалом як платформа це vSphere, ovirt-engine – керуючий шар – виконує ті ж функції, що vCenter, а ovirt-host – гіпервізор, як ESX(i). Т.к. vSphere дуже популярне рішення, іноді наводитиму порівняння з нею.
Мал. 1 - панель керування oVirt.
Як гостьові машини підтримується більшість дистрибутивів Linux і версій Windows. Для гостьових машин є агенти та оптимізовані віртуальні пристрої та драйвери virtio, насамперед дисковий контролер та мережевий інтерфейс.
Для реалізації відмовостійкого рішення і всіх цікавих функцій знадобиться сховище, що розділяється. Підтримуються як блокові FC, FCoE, iSCSI, так і файлові NFS сховища та ін. Для реалізації стійкості до відмови система зберігання також повинна бути відмовостійкою (мінімум 2 контролера, мультипасинг).
Використання локальних сховищ можливе, але за умовчанням для справжнього кластера годяться тільки сховища, що розділяються (shared storages). Локальні сховища роблять систему розрізненим набором гіпервізорів і навіть за наявності сховища, що розділяється, кластер зібрати не вийде. Найбільш правильний шлях - бездискові машини з boot from SAN або диски мінімального об'єму. Ймовірно, через vdsm hook можливий варіант складання з локальних дисків Software Defined Storage (напр., Ceph) та презентації його ВМ, але серйозно його не розглядав.
Архітектура
Мал. 2 - архітектура oVirt.
Докладніше з архітектурою можна ознайомитись у розробника.
Мал. 3 - об'єкти oVirt.
Верхній елемент в ієрархії Центр обробки даних. Він визначає, чи використовуються розділені (shared) або локальні сховища, а також використовуваний набір функцій (сумісність, від 4.1 до 4.3). Може бути один чи кілька. Для багатьох варіантів підходить використання Data Center за замовчуванням - Default.
Data Center складається з одного або кількох Кластери. Кластер визначає тип процесора, політики міграції та ін. Для невеликих інсталяцій можна обмежитися кластером Default.
Кластер, у свою чергу, складається з ГосподарТов, які виконують основну роботу — вони несуть віртуальні машини, до них підключені сховища. У кластері передбачається 2 або більше хостів. Хоча технічно можна зробити кластер з 1-м хостом, але це не має практичної користі.
У oVirt підтримується безліч функцій, зокрема. жива міграція віртуальних машин між гіпервізорами (live migration) та сховищами (storage migration), десктопна віртуалізація (virtual desktop infrastructure) з пулами ВМ, statefull та stateless ВМ, підтримка NVidia Grid vGPU, імпорт із vSphere, KVM, є потужне і багато іншого. Всі ці функції доступні без ліцензійних відрахувань, а за необхідності підтримки її можна придбати у Red Hat через регіональних партнерів.
Про ціни на RHV
Вартість не висока в порівнянні з VMware, купується лише підтримка без вимоги покупки самої ліцензії. Підтримка купується тільки на гіпервізори, ovirt-engine, на відміну від vCenter Server витрат не вимагає.
Приклад розрахунку 1-й рік володіння
Розглянемо кластер із 4-х 2-х сокетних машин та роздрібні ціни (без проектних знижок).
Стандартна підписка RHV за сокет / рік (преміум 365/24/7 - $ 1499), разом 4 * 2 * $ 999 =$7992.
:
- VMware vCenter Server Standard $10,837.13 за екземпляр, плюс передплата Basic $2,625.41 (Production — $3,125.39);
- VMware vSphere Standard $1,164.15 + Basic Subscription $552.61 (Production $653.82);
- VMware vSphere Enterprise Plus $6,309.23 + Basic Subscription $1,261.09 (Production $1,499.94).
Разом: 10 837,13 + 2 625,41 + 4 * 2 * (1 164,15 + 552,61) = $ 27 196,62 за наймолодший варіант. Різниця близько 3,5 разів!
У oVirt'е всі функції доступні без обмежень.
Короткі характеристики та максимуми
Системні вимоги
Для гіпервізора потрібний ЦПУ з включеною апаратною віртуалізацією, мінімальний обсяг ОЗУ для старту - 2 ГіБ, рекомендований об'єм сховища для ОС - 55 ГіБ (здебільшого для журналів і т.п., сама ОС займає мало).
Детальніше - .
Для мінімальні вимоги 2 ядра/4 ГіБ ОЗУ/25 ГіБ сховища. Рекомендовані - від 4 ядра/16 ГіБ ОЗУ/50 ГіБ зберігання.
Як і в будь-якій системі, є обмеження на обсяги та кількості, більшість з яких перевищує можливості доступних масових комерційних серверів. Так, пара може адресувати 2 ТіБ ОЗП і дає 40 ядер (80 потоків), що менше навіть лімітів однієї ВМ.
Virtual Machine Maximums:
- Maximum concurrently running virtual machines: Unlimited;
- Maximum virtual CPUs per virtual machine: 384;
- Maximum memory per virtual machine: 4 TiB;
- Maximum single disk size per virtual machine: 8 TiB.
Host Maximums:
- Logical CPU cores or threads: 768;
- RAM: 12 TiB;
- Кількість hosted віртуальних машин: 250;
- Simultaneous live migrations: 2 incoming, 2 outgoing;
- Live migration bandwidth: Default to 52 MiB (~436 Mb) per migration when using the legacy migration policy. Інші політики використовують пристосовані черезвихідні значення, що базуються на швидкості фізичного пристрою. QoS policies може обмеження migration bandwidth.
Manager Logical Entity Maximums:
У 4.3 існують .
- Центр обробки даних
- Maximum data center count: 400;
- Maximum host count: 400 supported, 500 tested;
- Maximum VM count: 4000 supported, 5000 tested;
- кластер
- Maximum cluster count: 400;
- Maximum host count: 400 supported, 500 tested;
- Maximum VM count: 4000 supported, 5000 tested;
- мережу
- Logical networks/cluster: 300;
- SDN/external networks: 2600 tested, не обмежений обмеження;
- зберігання
- Maximum domains: 50 supported, 70 tested;
- Hosts per domain: No limit;
- Logical volumes per block domain (більше): 1500;
- Максимальний номер LUNs (більше): 300;
- Maximum disk size: 500 TiB.
Варіанти впровадження
Як мовилося раніше, oVirt будується з двох базових елементів — ovirt-engine (управління) і ovirt-host (гіпервізор).
Engine може розміщуватися як поза самою платформою (standalone Manager - це може бути ВМ, запущена в іншій платформі або окремому гіпервізорі і навіть фізична машина), так і на самій платформі (self-hosted engine, аналогічно підходу VCSA від VMware).
Гіпервізор може бути встановлений як на (EL Host), так і на (oVirt-Node, заснована на el7).
Апаратні вимоги для всіх варіантів приблизно однакові.
Мал. 4 - стандартна архітектура.
Мал. 5 - Self-hosted Engine архітектура.
Для себе вибрав варіант standalone Manager та EL Hosts:
- standalone Manager трохи простіше при проблемах запуску, немає дилеми курки та яйця (як і для VCSA - не запустиш, поки повністю не підніметься хоча б один хост), але з'являється залежність від іншої системи *;
- EL Host надає всю потужність ОС, що є корисним для зовнішнього моніторингу, налагодження, пошуку несправностей і т.д.
* Проте за весь час експлуатації це не знадобилося, навіть після серйозної аварії з харчуванням.
Але вже ближчий до справи!
Для експерименту є можливість звільнити пару лез ProLiant BL460c G7 із Xeon® CPU. На них і відтворюватимемо процес установки.
Вузлам дамо імена ovirt.lab.example.com, kvm01.lab.example.com та kvm02.lab.example.com.
Переходимо безпосередньо до .
Джерело: habr.com