Innledning
Åpen kildekode-prosjekt — en gratis virtualiseringsplattform på bedriftsnivå. Etter å ha scrollet gjennom habr, oppdaget jeg det er ikke dekket her så mye som det fortjener.
oVirt er faktisk en oppstrøm for det kommersielle systemet Red Hat Virtualization (RHV, tidligere RHEV), som vokser under vingen til Red Hat. For å unngå forvirring, dette no samme som CentOS vs RHEL, modell nærmere Fedora vs RHEL.
Under panseret - , brukes et nettgrensesnitt for administrasjon. Basert på RHEL/CentOS 7 OS.
oVirt kan brukes til både "tradisjonell" server- og desktopvirtualisering (VDI), i motsetning til VMware-løsningen, kan begge systemene sameksistere i ett kompleks.
Prosjektet er bra , har lenge nådd modenhet for produktiv bruk og er klar for høy belastning.
Denne artikkelen er den første i en serie om hvordan du bygger en fungerende failover-klynge. Etter å ha gått gjennom dem, vil vi i løpet av kort tid (ca. 2 timer) få et fullt fungerende system, selv om en rekke problemer selvfølgelig ikke vil bli avslørt; jeg vil prøve å dekke dem i de følgende artiklene.
Vi har brukt den i flere år, fra og med versjon 4.1. Vårt industrielle system kjører for tiden på HPE Synergy 480 og ProLiant BL460c 10. generasjons datamaskiner med Xeon Gold CPU.
I skrivende stund er gjeldende versjon 4.3.
Artikler
- Introduksjon (Vi er her)
Funksjonelle funksjoner
Det er 2 hovedenheter i oVirt: ovirt-motor og ovirt-vert(er). For de som er kjent med VMware-produkter, er oVirt som helhet som en plattform vSphere, ovirt-engine - kontrolllaget - utfører de samme funksjonene som vCenter, og ovirt-host er en hypervisor, som ESX (i). Fordi vSphere er en veldig populær løsning, noen ganger vil jeg sammenligne den med den.
Ris. 1 — oVirt kontrollpanel.
De fleste Linux-distribusjoner og versjoner av Windows støttes som gjestemaskiner. For gjestemaskiner er det agenter og optimaliserte virtuelle enheter og virtio-drivere, først og fremst diskkontrolleren og nettverksgrensesnittet.
For å implementere en feiltolerant løsning og alle de interessante funksjonene, trenger du delt lagring. Både blokk FC-, FCoE-, iSCSI- og NFS-fillagringer osv. For å implementere en feiltolerant løsning må lagringssystemet også være feiltolerant (minst 2 kontrollere, multipassering).
Det er mulig å bruke lokal lagring, men som standard er bare delte lagringer egnet for en ekte klynge. Lokal lagring gjør systemet til et uensartet sett med hypervisorer, og selv med delt lagring kan en klynge ikke settes sammen. Den mest korrekte måten er diskløse maskiner med oppstart fra SAN, eller disker av minimal størrelse. Sannsynligvis, gjennom vdsm-kroken, er muligheten til å sette sammen Software Defined Storage fra lokale disker (for eksempel Ceph) og presentere den til en VM mulig, men jeg har ikke seriøst vurdert det.
arkitektur
Ris. 2 - oVirt arkitektur.
Flere detaljer om arkitekturen finner du i utvikler.
Ris. 3 — oVirt objekter.
Det øverste elementet i hierarkiet er − Datasenter. Den bestemmer om delt eller lokal lagring brukes, samt funksjonssettet som brukes (kompatibilitet, 4.1 til 4.3). Det kan være en eller flere. For mange alternativer er det egnet å bruke standard datasenter - Standard.
Datasenter består av ett eller flere klynger. Klyngen bestemmer prosessortype, migreringspolicyer osv. For små installasjoner kan du også begrense deg til standardklyngen.
Klyngen består på sin side av Hoster som gjør hovedarbeidet - de har virtuelle maskiner, lagring er koblet til dem. En klynge antar 2 eller flere verter. Selv om det er teknisk mulig å lage en klynge med 1 vert, har det ingen praktisk nytte.
oVirt støtter mange funksjoner, inkl. live migrering av virtuelle maskiner mellom hypervisorer (live migrering) og lagringsmigrering (lagringsmigrering), desktop virtualisering (virtuell skrivebordsinfrastruktur) med VM-pooler, statefull og stateless VM-er, støtte for NVidia Grid vGPU, import fra vSphere, KVM, det er en kraftig og mye mer. Alle disse funksjonene er tilgjengelige avgiftsfritt, og hvis støtte er nødvendig, kan støtte kjøpes fra Red Hat gjennom regionale partnere.
Om RHV-priser
Kostnaden er ikke høy sammenlignet med VMware, kun støtte kjøpes – uten krav om å kjøpe selve lisensen. Støtte kjøpes kun for hypervisorer; ovirt-engine, i motsetning til vCenter Server, krever ingen utgifter.
Eksempel på beregning for 1. eierår
La oss vurdere en klynge med 4 2-sockets maskiner og utsalgspriser (uten prosjektrabatter).
Standard RHV abonnement per stikkontakt/år (premium 365/24/7 — $1499), totalt 4*2*$999=$7992.
:
- VMware vCenter Server Standard $10,837.13 2,625.41 per forekomst, pluss Basic-abonnement $3,125.39 XNUMX (Produksjon — $XNUMX XNUMX);
- VMware vSphere Standard $1,164.15 552.61 + Grunnabonnement $653.82 (Produksjon $XNUMX);
- VMware vSphere Enterprise Plus $6,309.23 1,261.09 + Grunnabonnement $1,499.94 XNUMX (Produksjon $XNUMX XNUMX).
Totalt: 10 837,13 + 2 625,41 + 4 * 2 * (1 164,15 + 552,61) = $ 27 196,62 for det yngste alternativet. Forskjellen er ca 3,5 ganger!
I oVirt er alle funksjoner tilgjengelige uten begrensninger.
Korte egenskaper og maksimum
Systemkrav
Hypervisoren krever en CPU med maskinvarevirtualisering aktivert, minimumsmengden RAM for å starte er 2 GiB, den anbefalte lagringsmengden for operativsystemet er 55 GiB (mest for logger osv., selve operativsystemet tar opp lite).
Mer informasjon - .
For minimumskrav 2 kjerner/4 GiB RAM/25 GiB lagring. Anbefalt - fra 4 kjerner/16 GiB RAM/50 GiB lagring.
Som med ethvert system, er det begrensninger på volumer og mengder, hvorav de fleste overstiger mulighetene til tilgjengelige kommersielle masseservere. Ja, par kan adressere 2 TiB RAM og gir 40 kjerner (80 tråder), som er mindre enn grensene for en enkelt VM.
Maksimum for virtuell maskin:
- Maksimalt samtidig kjørende virtuelle maskiner: Ubegrenset;
- Maksimalt antall virtuelle CPUer per virtuell maskin: 384;
- Maksimalt minne per virtuell maskin: 4 TiB;
- Maksimal enkelt diskstørrelse per virtuell maskin: 8 TiB.
Vertsmaksimum:
- Logiske CPU-kjerner eller -tråder: 768;
- RAM: 12 TiB;
- Antall vertsbaserte virtuelle maskiner: 250;
- Samtidige direkteoverføringer: 2 innkommende, 2 utgående;
- Live migreringsbåndbredde: Standard til 52 MiB (~436 Mb) per migrering ved bruk av den eldre migrasjonspolicyen. Andre retningslinjer bruker adaptive gjennomstrømningsverdier basert på hastigheten til den fysiske enheten. QoS-policyer kan begrense migreringsbåndbredden.
Maksimum for lederlogiske enheter:
I 4.3 er det .
- Datasenter
- Maksimalt antall datasenter: 400;
- Maksimalt vertantall: 400 støttes, 500 testet;
- Maksimalt VM-antall: 4000 støttes, 5000 testet;
- Cluster
- Maksimalt clusterantall: 400;
- Maksimalt vertantall: 400 støttes, 500 testet;
- Maksimalt VM-antall: 4000 støttes, 5000 testet;
- Network
- Logiske nettverk/cluster: 300;
- SDN/eksterne nettverk: 2600 testet, ingen påtvunget grense;
- oppbevaring
- Maks domener: 50 støttes, 70 testet;
- Verter per domene: Ingen grense;
- Logiske volumer per blokkdomene (mer): 1500;
- Maksimalt antall LUN-er (flere): 300;
- Maksimal diskstørrelse: 500 TiB (begrenset til 8 TiB som standard).
Implementeringsmuligheter
Som allerede nevnt er oVirt bygget av 2 grunnleggende elementer - ovirt-motor (kontroll) og ovirt-host (hypervisor).
Motoren kan være plassert enten utenfor selve plattformen (frittstående Manager - dette kan være en VM som kjører på en annen plattform eller en separat hypervisor, eller til og med en fysisk maskin) eller på selve plattformen (selv-vertsmotor, lik VCSA-tilnærmingen fra VMware).
Hypervisoren kan installeres på begge (EL Host), og videre (oVirt-Node, basert på el7).
Maskinvarekravene for alle alternativer er omtrent de samme.
Ris. 4 - standard arkitektur.
Ris. 5 - Selvdrevet motorarkitektur.
For meg selv valgte jeg alternativet frittstående Manager og EL Hosts:
- frittstående Manager er litt enklere når det kommer til oppstartsproblemer, det er ingen kylling og egg-dilemma (som med VCSA - du kan ikke starte før minst én vert er helt oppe), men det er en avhengighet av et annet system*;
- EL Host gir all kraften til operativsystemet, som er nyttig for ekstern overvåking, feilsøking, feilsøking, etc.
* Dette var imidlertid ikke nødvendig under hele driftsperioden, selv etter et alvorlig strømbrudd.
Men la oss komme til poenget!
For eksperimentering er det mulig å frigjøre et par ProLiant BL460c G7-blader med en Xeon® CPU. Vi vil bruke dem til å reprodusere installasjonsprosessen.
La oss gi nodene navnene ovirt.lab.example.com, kvm01.lab.example.com og kvm02.lab.example.com.
La oss gå direkte til .
Kilde: www.habr.com