въведение
проект с отворен код е безплатна платформа за виртуализация от корпоративен клас. Превъртайки habr, открих това не се отразява толкова широко, колкото заслужава.
oVirt всъщност е нагоре по веригата за търговската система за виртуализация на Red Hat (RHV, по-рано RHEV), която расте под крилото на Red Hat. За да избегнете объркване, това не същото като CentOS срещу RHEL, моделът е по-близо до Fedora срещу RHEL.
Под капака - , уеб интерфейсът се използва за управление. Базиран на RHEL/CentOS 7 OS.
oVirt може да се използва както за "традиционен" сървър, така и за десктоп виртуализация (VDI), за разлика от решението на VMware, двете системи могат да съществуват съвместно в един комплекс.
Проектирайте добре , отдавна е достигнал зрялост за продуктивна употреба и е готов за високи натоварвания.
Тази статия е първата от поредица за това как да изградите работещ отказоустойчив клъстер. След като ги прегледаме, за кратко време (около 2 часа) ще получим напълно работеща система, въпреки че редица проблеми, разбира се, не могат да бъдат разкрити, ще се опитам да ги покрия в следващите статии.
Използваме го от няколко години, започнахме с версия 4.1. Нашата индустриална система сега живее на 480-то поколение HPE Synergy 460 и ProLiant BL10c изчисления с процесори Xeon Gold.
Към момента на писане текущата версия е 4.3.
Статии
- Въведение (ние сме тук)
Функционални характеристики
Има 2 основни обекта в 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 контролера, многопроходно).
Използването на локални хранилища е възможно, но по подразбиране само споделените хранилища са подходящи за истински клъстер. Локалните хранилища правят системата различен набор от хипервайзори и дори при споделено хранилище не може да се сглоби клъстер. Най-правилният начин е бездискови машини с зареждане от SAN или дискове с минимален размер. Вероятно чрез куката vdsm е възможно да се изгради от локални дискове софтуерно дефинирано хранилище (например Ceph) и да се представи неговата виртуална машина, но не го обмислях сериозно.
архитектура
Ориз. 2 - oVirt архитектура.
Повече информация за архитектурата можете да намерите в разработчик.
Ориз. 3 - oVirt обекти.
Най-горният елемент в йерархията − Център за данни. Той определя дали се използва споделено или локално хранилище, както и използвания набор от функции (съвместимост, 4.1 до 4.3). Може да има един или повече. За много опции използването на центъра за данни по подразбиране е по подразбиране.
Центърът за данни се състои от един или повече Клъстерите. Клъстерът определя типа на процесора, политиките за миграция и т.н. За малки инсталации можете също да се ограничите до клъстера по подразбиране.
Клъстерът от своя страна се състои от Домакинкоито изпълняват основната работа - те носят виртуални машини, към тях са свързани хранилища. Клъстерът предполага 2 или повече хоста. Въпреки че е технически възможно да се направи клъстер с 1 хост, това не е от практическа полза.
oVirt поддържа много функции, вкл. миграция на живо на виртуални машини между хипервайзори (миграция на живо) и хранилища (миграция на съхранение), виртуализация на десктоп (инфраструктура на виртуален десктоп) с VM пулове, виртуални машини без състояние и без състояние, поддръжка за 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 на инстанция плюс основен абонамент $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 GiB, препоръчителното количество памет за ОС е 55 GiB (най-вече за регистрационни файлове и т.н., самата ОС заема малко).
Повече информация - .
За минимални изисквания 2 ядра/4 GiB RAM/25 GiB памет. Препоръчително - от 4 ядра / 16 GiB RAM / 50 GiB памет.
Както при всяка система, има ограничения за обеми и количества, повечето от които надхвърлят възможностите на наличните масови търговски сървъри. Да, двойка. може да адресира 2 TiB RAM и дава 40 ядра (80 нишки), което е дори по-малко от границите на една VM.
Максимални стойности за виртуална машина:
- Максимален брой едновременно работещи виртуални машини: Неограничен;
- Максимален брой виртуални процесори на виртуална машина: 384;
- Максимална памет на виртуална машина: 4 TiB;
- Максимален размер на единичен диск на виртуална машина: 8 TiB.
Максимални стойности на хоста:
- Логически процесорни ядра или нишки: 768;
- RAM: 12 TiB
- Брой хоствани виртуални машини: 250;
- Едновременни живи миграции: 2 входящи, 2 изходящи;
- Честотна лента за миграция на живо: По подразбиране 52 MiB (~436 Mb) на миграция, когато се използва наследената политика за миграция. Други политики използват адаптивни стойности на пропускателна способност въз основа на скоростта на физическото устройство. Политиките за QoS могат да ограничат честотната лента на миграцията.
Максимални стойности на логическия обект на мениджъра:
В 4.3 има .
- Център за данни
- Максимален брой центрове за данни: 400;
- Максимален брой хостове: 400 поддържани, 500 тествани;
- Максимален брой VM: 4000 поддържани, 5000 тествани;
- Група
- Максимален брой клъстери: 400;
- Максимален брой хостове: 400 поддържани, 500 тествани;
- Максимален брой VM: 4000 поддържани, 5000 тествани;
- мрежа
- Логически мрежи/клъстер: 300
- SDN/външни мрежи: 2600 тествани, без наложено ограничение;
- Съхранение
- Максимален брой домейни: 50 поддържани, 70 тествани;
- Хостове на домейн: Без ограничение;
- Логически обеми на блок домейн (повече): 1500;
- Максимален брой LUN (повече): 300;
- Максимален размер на диска: 500 TiB (ограничен до 8 TiB по подразбиране).
Варианти за изпълнение
Както вече споменахме, oVirt е изграден от 2 основни елемента - ovirt-двигател (управление) и ovirt-хост (хипервайзор).
Двигателят може да бъде хостван както извън самата платформа (самостоятелен мениджър - може да бъде виртуална машина, работеща на друга платформа или отделен хипервайзор, и дори физическа машина), така и на самата платформа (самостоятелно хостван двигател, подобен на VCSA на VMware Приближаване).
Хипервайзорът може да се инсталира на (EL Host) и (oVirt-Node, базиран на el7).
Хардуерните изисквания за всички варианти са приблизително еднакви.
Ориз. 4 - стандартна архитектура.
Ориз. 5 - Самостоятелно хоствана архитектура на двигателя.
За себе си избрах опцията standalone Manager и EL Hosts:
- самостоятелният мениджър е малко по-лесен с проблеми при стартиране, няма дилема кокошка и яйце (както за VCSA - няма да стартирате, докато поне един хост не е напълно готов), но има зависимост от друга система *;
- EL Host предоставя пълната мощност на операционната система, която е полезна за външен мониторинг, отстраняване на грешки, отстраняване на проблеми и др.
* Това обаче не се изискваше през целия период на работа, дори и след сериозно прекъсване на захранването.
Но по-точно!
За експериментиране е възможно да се пусне чифт блейд устройства ProLiant BL460c G7 с процесор Xeon®. Ние ще възпроизведем процеса на инсталиране върху тях.
Нека кръстим възлите ovirt.lab.example.com, kvm01.lab.example.com и kvm02.lab.example.com.
Да преминем директно към .
Източник: www.habr.com