Въведение
Проект с отрытым исходным кодом — безплатна платформа за виртуализация на корпоративно ниво. Преглеждайки habr, открих, че не е осветена тук толкова широко, колкото заслужава.
oVirt по същество е основата на комерсиалната система Red Hat Virtualization (RHV, преди RHEV), която расте под крилото на Red Hat. За да не възникне объркване, това не е същото като CentOS срещу RHEL, моделът е по-близък до Fedora срещу RHEL.
Под капака — , управлението се осъществява чрез уеб интерфейс. Базирана е на ОС RHEL/CentOS 7.
oVirt може да се използва както за "традиционна" сървърна, така и за десктопна виртуализация (VDI), в отличие от решението на VMware, и двете системи могат да съществуват в един комплекс.
Проектът е добре , вече е достигнал зрялост за продуктивно приложение и е готов за високи натоварвания.
Тази статия е първата в цикъла за това как да изградим работещ отказоустойчив кластер. Преминавайки през тях, за кратко време (около 2 часа) ще получим напълно работеща система, въпреки че редица въпроси, разбира се, няма да могат да бъдат разгледани, ще се постарая да ги осветя в следващите статии.
Използваме го от няколко години, започнахме с версия 4.1. Нашата промишлена система в момента работи на изчислители HPE Synergy 480 и ProLiant BL460c 10-то поколение с Xeon Gold CPU.
Към момента на написването, активната версия е 4.3.
Статии
- Въведение (Ние сме тук)
Функционални характеристики
В oVirt има 2 основни същности: 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). Може да има един или повече. За много варианти подходящо е използването на Център за данни по подразбиране — Default.
Центърът за данни се състои от един или повече Клъстери.Клъстерът определя типа процесор, политики за миграция и др. За малки инсталации можете да се ограничите и до клъстера 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 две сокетни машини и търговските цени (без проектови отстъпки).
Стандартна абонаментна такса за RHV за сокет/година (премиум 365/24/7 — $1499), общо 4*2*$999=$7992.
:
- VMware vCenter Server Standard 10,837.13 $ на инстанция, плюс основна абонамент 2,625.41 $ (Производство — 3,125.39 $);
- VMware vSphere Standard 1,164.15 $ + Основна абонамент 552.61 $ (Производство 653.82 $);
- VMware vSphere Enterprise Plus 6,309.23 $ + Основна абонамент 1,261.09 $ (Производство 1,499.94 $).
Общо: 10,837.13 + 2,625.41 + 4 * 2 * (1,164.15 + 552.61) = $27 196,62 за най-базовата опция. Разликата е около 3.5 пъти!
В oVirt всички функции са достъпни без ограничения.
Кратки характеристики и максимуми
Системни изисквания
За хипервизора е необходим CPU с включена хардуерна виртуализация, минимален обем RAM за стартиране — 2 ГБ, препоръчителен обем за съхранение на ОС — 55 ГБ (предимно за журнали и т.н., самата ОС заема малко).
Повече информация — .
За минимални изисквания 2 ядра / 4 ГБ RAM / 25 ГБ съхранение. Препоръчителни — от 4 ядра / 16 ГБ RAM / 50 ГБ съхранение.
Както при всяка система, има ограничения на обемите и количествата, повечето от които надвишават възможностите на достъпните масови търговски сървъри. Така, двойка може да адресира 2 TiB RAM и да предостави 40 ядра (80 потока), което е по-малко дори от лимитите на едно ВМ.
Максимуми на виртуалните машини:
- Максимален брой едновременно работещи виртуални машини: Неограничен;
- Максимален брой виртуални CPU на виртуална машина: 384;
- Максимална памет на виртуална машина: 4 TiB;
- Максимален размер на един диск на виртуална машина: 8 TiB.
Максимуми на хост:
- Логически ядра на CPU или нишки: 768;
- RAM: 12 TiB;
- Брой хоствани виртуални машини: 250;
- Едновременни живи миграции: 2 входящи, 2 изходящи;
- Пропускна способност за жива миграция: По подразбиране 52 MiB (~436 Mb) на миграция при използване на политиката за наследствена миграция. Други политики използват адаптивни стойности за пропускна способност, основани на скоростта на физическото устройство. Политики за управление на качеството могат да ограничат пропускната способност на миграцията.
Максимуми на логическите ентитети на мениджъра:
В 4.3 съществуват .
- Център за данни
- Максимален брой центрове за данни: 400;
- Максимален брой хостове: 400 поддържани, 500 тествани;
- Максимален брой ВМ: 4000 поддържани, 5000 тествани;
- Cluster
- Максимален брой клъстери: 400;
- Максимален брой хостове: 400 поддържани, 500 тествани;
- Максимален брой ВМ: 4000 поддържани, 5000 тествани;
- Мрежа
- Логически мрежи/клъстър: 300;
- SDN/външни мрежи: 2600 тествани, без наложен лимит;
- Хранилище
- Максимален брой домейни: 50 поддържани, 70 тествани;
- Хостове на домейн: Без ограничение;
- Логически томове на блоков домейн (повече): 1500;
- Максимален брой LUNs (повече): 300;
- Максимален размер на диск: 500 TiB (ограничен на 8 TiB по подразбиране).
Варианти на внедряване
Както вече споменахме, oVirt се състои от 2 основни елемента — ovirt-engine (управление) и ovirt-host (хипервизор).
Engine може да бъде разположен както извън самата платформа (самостоятелен мениджър — това може да бъде ВМ, пусната в друга платформа или отделен хипервизор и дори физическа машинa), така и на самата платформа (self-hosted engine, подобно на подхода VCSA от VMware).
Хипервизорът може да бъде инсталиран както на (EL Host), така и на (oVirt-Node, основана на el7).
Хардуерните изисквания за всички варианти са приблизително еднакви.
Рис. 4 — стандартна архитектура.
Рис. 5 — Архитектура на самообслужваните енджини.
Избрах опцията 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
