Увядзенне
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-га пакалення c 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). Можа быць адзін ці некалькі. Для шматлікіх варыянтаў падыходзіць выкарыстанне 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 CPU для virtual machine: 384;
- Maximum memory per virtual machine: 4 TiB;
- Максімум цэлага дыска для віртуальнай машыны: 8 TiB.
Host Maximums:
- Logical CPU cores or threads: 768;
- RAM: 12 TiB;
- Number of hosted virtual machines: 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. Іншыя палітыкі выкарыстоўваюць adaptive throughput values based on the speed of physical device. QoS policies can limit 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 (more): 1500;
- Maximum number of LUNs (more): 300;
- Maximum disk size: 500 TiB.
Варыянты ўкаранення
Як ужо гаварылася, 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