Bevezetés
Nyílt forráskódú projekt — ingyenes, vállalati szintű virtualizációs platform. A habr böngészése során felfedeztem, hogy itt nem kapott akkora figyelmet, amennyit megérdemelne.
Az oVirt valójában a Red Hat Virtualization (RHV, korábban RHEV) kereskedelmi rendszer upstreamje, mely a Red Hat szárnyai alatt fejlődik. Az össze nem tévesztés érdekében ez nem ugyanaz, mint a CentOS vs RHEL, a modell közelebb áll a Fedora vs RHEL-hez.
A kulisszák mögött — , a kezelést webes felület végzi. RHEL/CentOS 7 operációs rendszeren alapul.
Az oVirt használható a "hagyományos" szerver- és asztali virtualizációhoz (VDI), eltérően a VMware megoldásától, mindkét rendszer képes együttműködni egy komplexumban.
A projekt jól , régóta elérte a termelési érettséget és készen áll a magas terhelések kezelésére.
Ez a cikk az első egy ciklusban, amelyben arról van szó, hogyan építsünk fel egy működő hibatűrő klasztert. Ezeket végigjárva viszonylag rövid idő alatt (körülbelül 2 óra) egy teljesen működő rendszert kapunk, bár bizonyos kérdéseket természetesen nem tudunk majd teljesen körbejárni, ezeket megpróbálom a következő cikkekben bemutatni.
Mi néhány éve használjuk, 4.1 verzióval kezdtünk. A mi ipari rendszerünk jelenleg HPE Synergy 480-as és ProLiant BL460c 10. generációs Xeon Gold CPU-ra épül.
A cikk írásának időpontjában az aktuális verzió 4.3.
Cikkek
- Bevezetés (Itt vagyunk)
Funkcionális jellemzők
Az oVirt 2 fő entitással rendelkezik: ovirt-engine és ovirt-host(s). A VMware termékeivel jól ismerőknek az oVirt mint platform a vSphere, az ovirt-engine — a kezelő réteg — ugyanazokat a funkciókat látja el, mint a vCenter, míg az ovirt-host — a hypervisor, mint az ESX(i). Mivel a vSphere nagyon népszerű megoldás, néha azzal fogok összehasonlítást végezni.
1. ábra — oVirt vezérlőpanel.
A vendéggépként a legtöbb Linux disztribúció és Windows verzió támogatott. A vendéggépekhez elérhetők ügynökök és optimalizált virtuális eszközök és virtio driverek, elsősorban a lemezvezérlő és a hálózati interfész.
A megbízható megoldás megvalósításához és minden érdekes funkcióhoz megosztott tárolóra van szükség. Támogatottak a blokkos FC, FCoE, iSCSI, valamint a fájlos NFS tárolók és mások. A megbízható megoldás megvalósításához a tárolórendszernek is megbízhatónak kell lennie (minimum 2 vezérlő, multipathing).
Helyi tárolók használata lehetséges, de alapértelmezés szerint a valódi klaszterhez csak megosztott tárolók alkalmasak. A helyi tárolók a rendszert különálló hipervizorok halmazává teszik, sőt, még megosztott tárolóval sem lehet klasztert létrehozni. A legjobb megoldás a lemez nélküli gépek boot from SAN lehetőséggel, vagy minimális méretű lemezek. Valószínű, hogy a vdsm hook révén megvalósítható a helyi lemezekből készült Szoftver Alapú Tárolás (pl. Ceph) és a VM-ek prezentálása, de ezt komolyan nem vizsgáltam.
Architektúra
2. ábra – az oVirt architektúrája.
További információk az architektúráról a fejlesztőtől.
3. ábra – oVirt objektumok.
A hierarchia felső eleme – Data Center. Meghatározza, hogy megosztott (shared) vagy helyi tárolók kerülnek felhasználásra, valamint a használt funkciók halmazát (kompatibilitás, 4.1-től 4.3-ig). Lehet egy vagy több. Sok esetben megfelelő a megadott Data Center használata – Default.
A Data Center egy vagy több Clusters-ből áll. A klaszter meghatározza a processzor típusát, a migrációs politikákat és másokat. Kis telepítések esetén a Default klaszterre is korlátozódhat.
A klaszter, viszont, Host‘okból áll, amelyek végzik a fő munkát – ők hordozzák a virtuális gépeket, és tárolókhoz csatlakoznak. A klaszterben 2 vagy több hoszt várható. Bár technikailag lehetséges egy egy hoszttal rendelkező klasztert létrehozni, ez gyakorlatilag nem hasznos.
Az oVirt számos funkciót támogat, beleértve a virtuális gépek élő migrációját a hipervizorok (live migration) és tárolók (storage migration) között, virtuális asztali infrastruktúrát (digital desktop infrastructure) VM poolokkal, statefull és stateless VM-eket, NVidia Grid vGPU támogatását, importálást vSphere-ből, KVM-et, erőteljes és még sok mást. Mindezek a funkciók licencdíjak nélkül érhetők el, és szükség esetén támogatást vásárolhatunk a Red Hattől regionális partnereken keresztül.
Az RHV árakról
Az ár nem magas a VMware-hez képest, csak a támogatást kell megvásárolni — anélkül, hogy a licencet is meg kellene venni. A támogatás csak a hipervizorokra és az ovirt-engine-re vonatkozik, az vCenter Server-hez képest nem igényel költségeket.
Példa a tulajdonlás első évének költségeire
Vegyünk egy 4 gépből álló, 2 socket-es klasztert, és nézzük meg a kiskereskedelmi árakat (projekt kedvezmények nélkül).
Standard RHV előfizetés socket/év (prémium 365/24/7 — 1499 $), összesen 4*2*999=$7992.
:
- VMware vCenter Server Standard 10,837.13 $ példányonként, plusz Basic előfizetés 2,625.41 $ (Production — 3,125.39 $);
- VMware vSphere Standard 1,164.15 $ + Basic előfizetés 552.61 $ (Production 653.82 $);
- VMware vSphere Enterprise Plus 6,309.23 $ + Basic előfizetés 1,261.09 $ (Production 1,499.94 $).
Összesen: 10,837.13 + 2,625.41 + 4 * 2 * (1,164.15 + 552.61) = $27 196,62 a legfiatalabb opcióra. A különbség körülbelül 3,5-szeres!
Az oVirt esetében azonban minden funkció korlátozás nélkül elérhető.
Rövid jellemzők és maximumok
Rendszerkövetelmények
A hipervizorhoz olyan CPU szükséges, amelyben engedélyezve van a hardveres virtualizálás, a minimális induló RAM mennyiség 2 GiB, a javasolt operációs rendszer tároló méret pedig 55 GiB (főként naplókhoz stb., az operációs rendszernek nem nagy a helyigénye).
További részletek — .
A minimális követelmények: 2 mag/4 GiB RAM/25 GiB tárolás. Javasolt: minimum 4 mag/16 GiB RAM/50 GiB tárolás.
Mint minden rendszerben, itt is vannak korlátozások a méretekre és mennyiségekre, amelyek többsége meghaladja a rendelkezésre álló kereskedelmi szerverek képességeit. Például egy pár címzett 2 TiB RAM és 40 magot (80 szálat) ad, ami még egy virtuális gép korlátainál is kevesebb.
Virtuális gép maximumai:
- Maximum párhuzamosan futó virtuális gépek: Korlátlan;
- Maximum virtuális CPU-k száma egy virtuális gépen: 384;
- Maximum memória egy virtuális gépen: 4 TiB;
- Maximum egyedisztikus méret egy virtuális gépen: 8 TiB.
Gazda maximumai:
- Logikai CPU magok vagy szálak: 768;
- RAM: 12 TiB;
- Kínált virtuális gépek száma: 250;
- Párhuzamos élő migrációs lehetőségek: 2 bejövő, 2 kimenő;
- Élő migrációs sávszélesség: Alapértelmezett 52 MiB (~436 Mb) migrációnként a régi migráló politika használatakor. Egyéb politikák az alkalmazás sebessége alapján változó áthaladási értékeket használnak. QoS politikák korlátozhatják a migrációs sávszélességet.
Meneder Logikai Entitás Maximumai:
A 4.3 verzióban vannak .
- Adatközpont
- Maximum adatközpontok száma: 400;
- Maximum gazda szám: 400 támogatott, 500 tesztelt;
- Maximum VM szám: 4000 támogatott, 5000 tesztelt;
- Klaszter
- Maximum klaszter szám: 400;
- Maximum gazda szám: 400 támogatott, 500 tesztelt;
- Maximum VM szám: 4000 támogatott, 5000 tesztelt;
- Hálózat
- Logikai hálózatok/klaszter: 300;
- SDN/külső hálózatok: 2600 tesztelt, nincs érvényesített korlátozás;
- Tárolás
- Maximum domainek: 50 támogatott, 70 tesztelt;
- Gazdák a domainekben: Nincs korlátozás;
- Logikai kötetek a blokk domainekben (több): 1500;
- Maximum LUN-ok száma (több): 300;
- Maximum lemezméret: 500 TiB (alapértelmezés szerint 8 TiB-ra korlátozva).
Bevezetési lehetőségek
Ahogy már említettük, az oVirt két alapvető elemre épül — ovirt-engine (kezelés) és ovirt-host (hipervizor).
A motor elhelyezhető a platform keretein kívül (standalone Manager - ez lehet egy másik platformon futó VM, külön hipervizorban vagy akár fizikai gépként) és a platformon belül (self-hosted engine, hasonlóan a VMware VCSA megközelítéséhez).
A hipervizor telepíthető (EL Host), vagy (oVirt-Node, el7 alapú).
A hardverkövetelmények minden változat esetében körülbelül azonosak.
4. ábra - standard architektúra.
5. ábra - Self-hosted Engine architektúra.
Én a standalone Manager és az EL Hosts verziót választottam:
- a standalone Manager egy kicsit egyszerűbb a problémák esetén, nem áll fenn a tojás és a csirke dilemmája (ahogy a VCSA esetében is - nem indítható el, amíg legalább egy host teljesen fel nem áll), de egy másik rendszertől való függőséget teremt*;
- az EL Host biztosítja az operációs rendszer teljes erejét, ami hasznos a külső monitorozáshoz, hibakereséshez, problémák feltárásához stb.
* Azonban a használat során erre soha nem volt szükség, még súlyos áramkimaradás után sem.
De most már jöhet a lényeg!
A kísérlethez szabadon tudunk átadni néhány ProLiant BL460c G7 lapkát Xeon® CPU-val. Ezekkel fogjuk reprodukálni a telepítési folyamatot.
A csomópontok nevei: ovirt.lab.example.com, kvm01.lab.example.com és kvm02.lab.example.com lesznek.
Most pedig folytatjuk az .
Forrás: habr.com
