oVirt kahe tunni jooksul. Osa 1. Avatud taluvusvõime platvorm virtualiseerimiseks

Sissejuhatus

Avatud lähtekoodiga projekt oVirt — tasuta ettevõttesiseseks virtuellusimiseks mõeldud platvorm. Habr'i sirvides leidsin, et oVirt selle kohta pole räägitud nii palju, kui see vääriks.
oVirt on tegelikult upstream kaubanduslikule süsteemile Red Hat Virtualization (RHV, varem RHEV), areneb Red Hat'i tiiva all. Et segadust ei tekiks, on see ei sama, mis CentOS vs RHEL, mudel sarnaneb rohkem Fedora vs RHEL.
Kappa all — KVM, haldamiseks kasutatakse veebiliidest. Põhineb RHEL/CentOS 7-l.
oVirt'i saab kasutada nii 'traditsioonilise' serverivirtuelisatsiooni kui ka lauaarvuti virtuelisatsiooni (VDI) jaoks, erinevalt VMware lahendusest, kus mõlemad süsteemid saavad eksisteerida samas kompleksis.
Projekt on hästi dokumenditud, on ammu jõudnud küpsuseastmesse tootmisrakenduseks ja on valmis suurtele koormustele.
See artikkel on esimene osa tsüklist, kuidas ehitada toimiv tõrkekindel klaster. Nende kaudu liikudes saame lühikese ajaga (umbes 2 tundi) täielikult toimiva süsteemi, kuigi mõne küsimuse käsitlemine ei õnnestu kindlasti, püüan neid käsitleda järgnevates artiklites.
Oleme seda kasutanud mitu aastat, alustasime versiooniga 4.1. Meie tootmissüsteem töötab praegu HPE Synergy 480 ja ProLiant BL460c 10. põlvkonna Xeon Gold CPU'Del.
Kirjutamise ajaks on aktiivne versioon 4.3.

Artiklid

1. Sissejuhatus (Oleme siin)
2. Halduri (ovirt-engine) ja hüperviisorite (hostid) installimine
3. Lisa seadistused

Funktsionaalsed omadused

oVirt'is on 2 põhielementi: ovirt-engine ja ovirt-host(s). Neile, kes on VMware tootega hästi tuttavad, on oVirt platsina vSphere, ovirt-engine — halduskiht — täidab samu funktsioone nagu vCenter ja ovirt-host — hüperviisor nagu ESX(i). Kuna vSphere on väga populaarne lahendus, võin aegajalt tuua selle kohta võrdlusi.

Joon. 1 — oVirt'i juhtpaneel.

Külalismasinana toetatakse enamikku Linuxi distributsioonidest ning Windowsi versioone. Külalismasinatele on saadaval agendid ja optimeeritud virtuaalsed seadmed ning virtio draiverid, eelkõige ketasjuht ja võrgu liides.
Tõrkekindla lahenduse rakendamiseks ja kõigi huvitavate funktsioonide jaoks on vajalik jagatud salvestusruum. Toetatud on nii plokilised FC, FCoE, iSCSI, kui ka failipõhised NFS salvestussüsteemid jne. Tõrkekindla lahenduse rakendamiseks peab ka salvestussüsteem olema tõrkekindel (vähemalt 2 kontrollerit, multipath).
Kohalike salvestuste kasutamine on võimalik, kuid vaikimisi sobivad tõeliseks klastriks ainult jagatud salvestused (shared storages). Kohalikud salvestused muudavad süsteemi killustatud hüperviisorite kogumiks ning isegi jagatud salvestuse olemasolul on klastri loomine võimatu. Parim lähenemine on ilma kettadeta masinad, mis käivituvad SAN-ist, või minimaalsete mahtude kettad. Tõenäoliselt on kohalike kettaste põhjal tarkvara määratud salvestuse (nt Ceph) ehitamine ja selle VM-ide esitamine võimalik läbi vdsm hook’i, kuid ma ei ole seda tõsiselt kaalunud.

Arhitektuur

Joonis 2 — oVirt arhitektuur.
Arhitektuuriga saab tutvuda dokumentatsioon arendaja.

Joonis 3 — oVirt objektid.

Hierarhia ülemine element on Andmekeskus. See määrab, kas kasutatakse jagatud (shared) või kohalikke salvestusi, samuti funktsioonide komplekti (ühilduvus, alates 4.1 kuni 4.3). Võib olla üks või mitu. Paljude variantide jaoks sobib vaikimisi Data Center — Default.
Data Center koosneb ühest või mitmest Klastrist. Klastri määrab protsessori tüübi, migratsiooni poliitikad jne. Väikeste installeerimiste puhul võib samuti piirduda Default klastri kasutamisega.
Klaster koosneb omakorda Hosthost'idest, mis teevad põhitäidise — nad kannavad virtuaalseid masinaid, neile on ühendatud salvestused. Klastris on eeldatud 2 või enama host'i olemasolu. Kuigi tehniliselt on võimalik luua klaster 1 hostiga, ei ole sellel praktilist kasu.

oVirt toetab mitmeid funktsioone, sealhulgas virtuaalmasinate elavat migreerimist hüperviisorite vahel (live migration) ja salvestustega (storage migration), töölauavirtualiseerimist (virtual desktop infrastructure) VM-ide basseinidega, statefull ja stateless VM-e, NVidia Grid vGPU toetamist, vSphere impordi, KVM, ning seal on palju muud. Kõik need funktsioonid on saadaval ilma litsentsitasudeta, vajadusel saab tuge osta Red Hat'ilt läbi piirkondlike partnerite. API ja palju muud. Kõik need funktsioonid on saadaval ilma litsentsitasudeta, vajadusel saab tuge osta Red Hat'ilt läbi piirkondlike partnerite.

RHV hindadest

Hind ei ole võrreldes VMware'iga kõrge, ostetakse vaid tugi — ilma litsentsi ostmise nõudeta. Tugi ostetakse ainult hüperviisoritele, ovirt-engine, erinevalt vCenter Serverist, ei nõua kulusid.

Näidis 1. aasta omamise arvutus

Vaatleme klastrit, mis koosneb 4-st 2-soketmasinast ja jaemüügihindadest (ilma projektialaste allahindlusteta).
Standardne RHV tellimus maksab 999 dollarit soketi/aasta kohta (premium 365/24/7 — 1499 dollarit), kokku 4*2*999=$7992.
vSphere hind:

• VMware vCenter Server Standard 10,837.13 $ eksemplar, pluss basis abonnement 2,625.41 $ (Produksjon — 3,125.39 $);
• VMware vSphere Standard 1,164.15 $ + Basisabonnement 552.61 $ (Produksjon 653.82 $);
• VMware vSphere Enterprise Plus 6,309.23 $ + Basisabonnement 1,261.09 $ (Produksjon 1,499.94 $).

Totalt: 10,837.13 + 2,625.41 + 4 * 2 * (1,164.15 + 552.61) = $27 196,62 for det mest grunnleggende alternativet. Forskjellen er omtrent 3,5 ganger!
I oVirt er alle funksjoner tilgjengelige uten begrensninger.

Kort spesifikasjon og maksimale

Süsteeminõuded

Hypervisor krever en CPU med aktivert maskinvarevirtualisering, minimum RAM for oppstart — 2 GiB, anbefalt lagringskapasitet for OS — 55 GiB (for det meste for logger etc., selve OS'en tar lite).
Mer informasjon — siin.
Tooge Motor minimumskrav 2 kjerner/4 GiB RAM/25 GiB lagring. Anbefalt — fra 4 kjerner/16 GiB RAM/50 GiB lagring.
Som i alle systemer, er det begrensninger på volum og antall, hvorav de fleste overstiger kapasiteten til tilgjengelige kommersielle servere. Så, et par Intel Xeon Gold 6230 kan adressere 2 TiB RAM og gi 40 kjerner (80 tråder), noe som er mindre enn grensene for en VM.

Maksimale virtuelle maskiner:

• Maksimalt antall kjørende virtuelle maskiner samtidig: Ubegrenset;
• Maksimalt antall virtuelle CPU-er per virtuell maskin: 384;
• Maksimalt minne per virtuell maskin: 4 TiB;
• Maksimal enkelt diskstørrelse per virtuell maskin: 8 TiB.

Vertskap Maksimale:

• Logiske CPU-kjerner eller tråder: 768;
• RAM: 12 TiB;
• Antall vertede virtuelle maskiner: 250;
• Samtidige live-migrasjoner: 2 innkommende, 2 utgående;
• Live-migrasjonsbåndbredde: Standard til 52 MiB (~436 Mb) per migrasjon når du bruker den eldre migreringspolitikken. Andre politikker bruker tilpassede gjennomstrømmingsverdier basert på hastigheten til den fysiske enheten. QoS-politikker kan begrense migrasjonsbåndbredden.

Manager Logiske Enhet Maksimale:

I 4.3 er det følgende grenser.

• Datacenter
  • Maksimalt antall datsentere: 400;
  • Maksimalt antall verter: 400 støttet, 500 testet;
  • Maksimalt antall VM-er: 4000 støttet, 5000 testet;
• Cluster
  • Maksimalt antall klynger: 400;
  • Maksimalt antall verter: 400 støttet, 500 testet;
  • Maksimalt antall VM-er: 4000 støttet, 5000 testet;
• Võrk
  • Logiske nettverk/klynge: 300;
  • SDN/eksterne nettverk: 2600 testet, ingen håndhevet grense;
• Salvestus
  • Maksimalt antall domener: 50 støttet, 70 testet;
  • Verter per domene: Ingen grense;
  • Logiske volumer per blokkdomen (mer): 1500;
  • Maksimalt antall LUN-er (mer): 300;
  • Maksimal diskstørrelse: 500 TiB (begrenset til 8 TiB som standard).

Implementeringsalternativer

Som allerede nevnt, er oVirt bygget opp av 2 grunnleggende elementer — ovirt-engine (administrasjon) og ovirt-host (hypervisor).
Motoren kan plasseres enten utenfor plattformen selv (standalone Manager — dette kan være en VM som kjører på en annen plattform eller en separat hypervisor, og til og med en fysisk maskin), eller på selve plattformen (self-hosted engine, på lignende måte som tilnærmingen VCSA fra VMware).
Hypervisor kan installeres både på vanlig OS RHEL/CentOS 7 (EL Host), samt på spesialisert minimal OS (oVirt-Node, basert på el7).
Maskinvarekrev er omtrent de samme for alle alternativer.

Fig. 4 — standardarkitektur.

Joonis 5 — Enesehitatud Engine arhitektuur.

Valisin endale standalone Manageri ja EL Hosts'i variandi:

• standalone Manager on käivitamisprobleemide korral veidi lihtsam, ei ole kana ja muna dilemmat (nagu VCSA puhul — ei saa käivitada, enne kui vähemalt üks host on täielikult üles tõusnud), kuid tekib sõltuvus teisest süsteemist*;
• EL Host pakub kogu OS-i võimsust, mis on kasulik väliseks jälgimiseks, silumiseks, tõrkeotsinguks jne.

* Siiski ei ole seda kogu kasutusaja jooksul kunagi vaja läinud, isegi pärast tõsist toitekatkestust.
Aga nüüd asja juurde!
Eksperimendi jaoks on võimalik vabastada paar ProLiant BL460c G7 terast Xeon® CPU-ga. Just nendel teeme installimisprotsessi.
Noodile anname nimed ovirt.lab.example.com, kvm01.lab.example.com ja kvm02.lab.example.com.
Liigume otse edasi paigaldamiseks.

Allikas: habr.com