Въведение
Проект с отрытым исходным кодом — безплатна платформа за виртуализация на корпоративно ниво. Прегледах habr и открих, че това не е осветено тук толкова широко, колкото заслужава.
oVirt е в действителност upstream за търговската система 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.
Горният елемент в иерархията е Data Center. Той определя дали се използват споделени (shared) или локални хранилища, а също и набора функции (съвместимост, от 4.1 до 4.3). Може да има един или повече. За много варианти е подходящо използването на Data Center по подразбиране — Default.
Data Center се състои от едно или повече Clusters. Клъстерът определя типа процесор, политиките за миграция и др. За малки инсталации може да се ограничи само до клъстера Default.
Клъстерът, от своя страна, се състои от Host‘ове, които извършват основната работа — те носят виртуални машини, към тях са свързани хранилища. В клъстера се предполага 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 ТиБ RAM и предлага 40 ядра (80 потока), което е по-малко дори от лимитите на една ВМ.
Максимуми на Виртуалната Машина:
- Максимален брой виртуални машини, които могат да работят едновременно: Неограничено;
- Максимално виртуални CPU на виртуална машина: 384;
- Максимална памет на виртуална машина: 4 ТиБ;
- Максимален размер на един диск на виртуална машина: 8 ТиБ.
Максимуми на хоста:
- Логически ядра или нишки на CPU: 768;
- RAM: 12 ТиБ;
- Брой хоствани виртуални машини: 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 ТиБ (ограничен до 8 ТиБ по подразбиране).
Варианти на внедряване
Както вече споменахме, oVirt се изгражда от 2 основни елемента — 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
