Introduktion
Open source projekt — en gratis platform for virksomhedsniveau virtualisering. Efter at have gennemgået habr, fandt jeg ud af, at det ikke er blevet belyst så bredt, som det fortjener.
oVirt er faktisk upstream for det kommercielle system Red Hat Virtualization (RHV, tidligere RHEV), og vokser under Red Hats vinger. For at undgå forvirring, det ikke er det samme som CentOS vs RHEL, modellen ligner Fedora vs RHEL.
Under hætten — , administreres ved hjælp af et webinterface. Baseret på RHEL/CentOS 7.
oVirt kan bruges til både "traditionel" server- og desktopvirtualisering (VDI), modsat VMware-løsningen, kan begge systemer eksistere i samme kompleks.
Projektet er godt , har længe nået modenhed til produktionsbrug og er klar til høje belastninger.
Denne artikel er den første i en cyklus om, hvordan man bygger et fungerende fejltolerant cluster. Ved at følge dem vil vi inden for kort tid (omkring 2 timer) have et helt fungerende system, selvom nogle spørgsmål selvfølgelig ikke vil kunne dækkes, jeg vil forsøge at belyse dem i de næste artikler.
Vi har brugt det i flere år, begyndte med version 4.1. Vores industrielle system kører nu på HPE Synergy 480 og ProLiant BL460c 10. generation med Xeon Gold CPU.
På tidspunktet for skrivningen er den nuværende version 4.3.
Artikler
- Introduktion (Vi er her)
Funktionelle egenskaber
I oVirt er der 2 primære enheder: ovirt-engine og ovirt-host(s). For dem, der er godt bekendt med VMware-produkter, er oVirt generelt som en platform vSphere, ovirt-engine — styringslaget — udfører de samme funktioner som vCenter, og ovirt-host — hypervisor ligesom ESX(i). Da vSphere er en meget populær løsning, vil jeg nogle gange sammenligne med den.
Fig. 1 — oVirt kontrolpanel.
Som gæstemaskiner understøttes de fleste Linux-distributioner og versioner af Windows. For gæstemaskiner er der agenter og optimerede virtuelle enheder og virtio-drivere, primært diskcontroller og netværksinterface.
For at implementere en fejltolerant løsning og alle de interessante funktioner er der brug for delt lager. Der understøttes både blok- FC, FCoE, iSCSI samt filbaserede NFS-lagringssystemer mv. For at implementere en fejltolerant løsning skal lagersystemet også være fejltolerant (min. 2 controllere, multipathing).
Brug af lokale lagerpladser er muligt, men som standard er kun delte lagerpladser (shared storages) egnet til en virkelig klynge. Lokale lagringssystemer gør systemet til et fragmenteret sæt hypervisorer, og selv med delte lagringspladser kan en klynge ikke samles. Den mest korrekte vej er diskløse maskiner med boot fra SAN eller diske med minimal størrelse. Muligvis er der via vdsm hook en mulighed for at samle fra lokale diske med Software Defined Storage (fx, Ceph) og præsentere det for VMs, men det er ikke blevet alvorligt overvejet.
Arkitektur
Fig. 2 — oVirt arkitektur.
Man kan læse mere om arkitekturen i udviklerens.
Fig. 3 — oVirt objekter.
Det øverste element i hierarkiet — Data Center. Det bestemmer, om der bruges delte (shared) eller lokale lagringspladser, samt hvilke funktioner (kompatibilitet, fra 4.1 til 4.3) der anvendes. Der kan være én eller flere. For mange scenarier kan man bruge standard Data Center — Default.
Data Center består af en eller flere Clusters. Klyngen bestemmer typen af processor, migrationspolitikker osv. For små installationer kan man også nøjes med klyngen Default.
Klyngen består i sin tur af Host’e, der udfører det primære arbejde — de bærer virtuelle maskiner og er tilsluttet lagerpladser. Der forventes 2 eller flere værter i klyngen. Selvom det rent teknisk er muligt at lave en klynge med 1 vært, er det ikke praktisk.
oVirt understøtter mange funktioner, herunder live migration af virtuelle maskiner mellem hypervisorer (live migration) og lagringspladser (storage migration), desktop virtualisering (virtual desktop infrastructure) med VM-pooler, stateful og stateless VMs, støtte til NVidia Grid vGPU, import fra vSphere, KVM, og meget mere. Alle disse funktioner er tilgængelige uden licensafgifter, og hvis der er behov for support, kan den købes fra Red Hat gennem regionale partnere. Om priserne på RHV
Prisen er ikke høj sammenlignet med VMware; man køber kun support — uden krav om at købe selve licensen. Support købes kun til hypervisorerne, ovirt-engine, i modsætning til vCenter Server, som ikke kræver udgifter.
Eksempel på beregning for 1. år af ejerskab
Lad os overveje en klynge bestående af 4 2-socket maskiner og detailpriser (uden projekt-rabatter).
Standard RHV abonnement
koster $999 Pris på vSphere$7992.
:
- VMware vCenter Server Standard 10.837,13 $ pr. instans, plus Basic abonnement 2.625,41 $ (Produktion — 3.125,39 $);
- VMware vSphere Standard 1.164,15 $ + Basic abonnement 552,61 $ (Produktion 653,82 $);
- VMware vSphere Enterprise Plus 6.309,23 $ + Basic abonnement 1.261,09 $ (Produktion 1.499,94 $).
I alt: 10.837,13 + 2.625,41 + 4 * 2 * (1.164,15 + 552,61) = $27 196,62 for den laveste variant. Forskellen er omkring 3,5 gange!
I oVirt er alle funktioner tilgængelige uden begrænsninger.
Kort specifikation og maksimale værdier
Systemkrav
For hypervisoren kræves en CPU med aktiveret hardwarevirtualisering, minimum hukommelse til opstart — 2 GB, anbefalet lagerplads til OS — 55 GB (for det meste til logs m.m., selve OS optager lidt).
Mere — .
For minimumskrav 2 kerner/4 GB RAM/25 GB lager. Anbefalede — fra 4 kerner/16 GB RAM/50 GB lager.
Som i ethvert system er der begrænsninger på størrelse og antal, hvoraf de fleste overstiger kapaciteterne for tilgængelige kommercielle servere. Så et par kan adressere 2 TiB RAM og giver 40 kerner (80 tråde), hvilket endda er mindre end grænserne for en VM.
Maksimale værdier for virtuelle maskiner:
- Maksimalt antal samtidige kørende virtuelle maskiner: Ubegrænset;
- Maksimalt virtuelle CPU'er pr. virtuel maskine: 384;
- Maksimal hukommelse pr. virtuel maskine: 4 TiB;
- Maksimal størrelser for enkelt-disk pr. virtuel maskine: 8 TiB.
Maksimale værdier for værten:
- Logiske CPU-kerner eller tråde: 768;
- RAM: 12 TiB;
- Antal hostede virtuelle maskiner: 250;
- Samtidige live migrationer: 2 indkommende, 2 udgående;
- Live migrationsbåndbredde: Standard 52 MiB (~436 Mb) pr. migration ved brug af den ældre migrationspolitik. Andre politikker bruger adaptive gennemstrømningsværdier baseret på hastigheden af den fysiske enhed. QoS-politikker kan begrænse migrationsbåndbredden.
Maksimale værdier for logiske enheder i Manager:
I 4.3 eksisterer der .
- Data center
- Maksimalt antal datacentre: 400;
- Maksimalt antal værter: 400 understøttet, 500 testet;
- Maksimalt antal VM'er: 4000 understøttet, 5000 testet;
- Cluster
- Maksimalt antal klynger: 400;
- Maksimalt antal værter: 400 understøttet, 500 testet;
- Maksimalt antal VM'er: 4000 understøttet, 5000 testet;
- Netværk
- Logiske netværk/klynge: 300;
- SDN/eksterne netværk: 2600 testet, uden håndhævet grænse;
- Storage
- Maksimalt antal domæner: 50 understøttet, 70 testet;
- Værter pr. domæne: Ingen grænse;
- Logiske volumener pr. blokdomæne (mere): 1500;
- Maksimalt antal LUN'er (mere): 300;
- Maksimal diskstørrelse: 500 TiB (begrænset til 8 TiB som standard).
Implementeringsmuligheder
Som nævnt tidligere, er oVirt bygget op af 2 grundlæggende elementer — ovirt-engine (styring) og ovirt-host (hypervisor).
Motoren kan placeres enten uden for selve platformen (standalone Manager — dette kan være en VM, der kører på en anden platform eller en separat hypervisor, og endda en fysisk maskine), eller på selve platformen (self-hosted engine, tilsvarende til VCSA-tilgangen fra VMware).
Hypervisoren kan installeres på (EL Host), såvel som på (oVirt-Node, baseret på el7).
Hardwarekravene for alle muligheder er nogenlunde ens.
Fig. 4 — standardarkitektur.
Figur 5 — Arkitektur for egen-hosted Engine.
Jeg valgte standalone Manager og EL Hosts til mig selv:
- Standalone Manager er lidt nemmere ved opstartsproblemer, der er ikke noget dilemma med hønen og ægget (ligesom med VCSA — du kan ikke starte det, før mindst én host er helt oppe at køre), men der opstår en afhængighed af et andet system*;
- EL Host giver al kraften fra operativsystemet, hvilket er nyttigt til ekstern overvågning, fejlfinding, fejlsøgning osv.
* Men i hele min brugstid har dette ikke været nødvendigt, selv efter en alvorlig strømafbrydelse.
Men lad os komme til sagen!
Til eksperimentet er der mulighed for at frigøre et par knive fra ProLiant BL460c G7 med Xeon® CPU. Det er på dem, vi vil reproducere installationsprocessen.
Vi vil give knudepunkterne navne som ovirt.lab.example.com, kvm01.lab.example.com og kvm02.lab.example.com.
Lad os gå direkte til .
Kilde: habr.com
