Inledning
Öppen källkod-projekt — en gratis virtualiseringsplattform på företagsnivå. Efter att ha scrollat igenom habr upptäckte jag det täcks inte här så brett som det förtjänar.
oVirt är faktiskt ett uppströms för det kommersiella systemet Red Hat Virtualization (RHV, tidigare RHEV), som växer under Red Hats vingar. För att undvika förvirring, detta ingen samma som CentOS vs RHEL, modell närmare Fedora vs RHEL.
Under huven - , används ett webbgränssnitt för hantering. Baserat på RHEL/CentOS 7 OS.
oVirt kan användas för både "traditionell" server- och skrivbordsvirtualisering (VDI), till skillnad från VMware-lösningen kan båda systemen samexistera i ett komplex.
Projektet är bra , har länge nått mognad för produktiv användning och är redo för höga belastningar.
Den här artikeln är den första i en serie om hur man bygger ett fungerande failover-kluster. Efter att ha gått igenom dem kommer vi på kort tid (cirka 2 timmar) att få ett fullt fungerande system, även om ett antal problem naturligtvis inte kommer att avslöjas; jag kommer att försöka täcka dem i följande artiklar.
Vi har använt det i flera år, från och med version 4.1. Vårt industrisystem körs för närvarande på HPE Synergy 480 och ProLiant BL460c 10:e generationens datorer med Xeon Gold CPU.
I skrivande stund är den aktuella versionen 4.3.
Artiklar
- Introduktion (Vi är här)
Funktionsegenskaper
Det finns två huvudenheter i oVirt: ovirt-motor och ovirt-värd(ar). För de som är bekanta med VMware-produkter är oVirt som helhet som en plattform vSphere, ovirt-engine - kontrollskiktet - utför samma funktioner som vCenter, och ovirt-host är en hypervisor, som ESX (i). Därför att vSphere är en mycket populär lösning, ibland kommer jag att jämföra den med den.
Ris. 1 — oVirt kontrollpanel.
De flesta Linux-distributioner och versioner av Windows stöds som gästdatorer. För gästdatorer finns agenter och optimerade virtuella enheter och virtio-drivrutiner, främst diskkontrollern och nätverksgränssnittet.
För att implementera en feltolerant lösning och alla intressanta funktioner behöver du delad lagring. Både block FC, FCoE, iSCSI och NFS fillagringar etc. För att implementera en feltolerant lösning måste lagringssystemet också vara feltolerant (minst 2 styrenheter, multipass).
Det är möjligt att använda lokal lagring, men som standard är endast delade lagringar lämpliga för ett riktigt kluster. Lokal lagring gör systemet till en disparat uppsättning hypervisorer, och även med delad lagring kan ett kluster inte sättas ihop. Det mest korrekta sättet är disklösa maskiner med boot från SAN, eller diskar av minimal storlek. Förmodligen, genom vdsm-kroken, är alternativet att montera Software Defined Storage från lokala diskar (till exempel Ceph) och presentera det för en virtuell dator möjligt, men jag har inte seriöst övervägt det.
Arkitektur
Ris. 2 - oVirt arkitektur.
Mer information om arkitekturen finns i utvecklare.
Ris. 3 — oVirt föremål.
Det översta elementet i hierarkin är − Data Center. Den bestämmer om delad eller lokal lagring används, samt vilken funktionsuppsättning som används (kompatibilitet, 4.1 till 4.3). Det kan finnas en eller flera. För många alternativ är det lämpligt att använda standarddatacenter - Standard.
Datacenter består av en eller flera kluster. Klustret bestämmer processortyp, migreringspolicyer etc. För små installationer kan du också begränsa dig till standardklustret.
Klustret består i sin tur av Hostär som gör huvudarbetet - de bär virtuella maskiner, lagring är ansluten till dem. Ett kluster förutsätter 2 eller fler värdar. Även om det är tekniskt möjligt att göra ett kluster med 1 värd, är det inte till någon praktisk användning.
oVirt stöder många funktioner, inkl. livemigrering av virtuella maskiner mellan hypervisorer (live-migrering) och lagringsmigrering (lagringsmigrering), skrivbordsvirtualisering (virtuell skrivbordsinfrastruktur) med virtuella datorer, tillståndslösa och tillståndslösa virtuella datorer, stöd för NVidia Grid vGPU, import från vSphere, KVM, det finns en kraftfull och mycket mer. Alla dessa funktioner är tillgängliga royaltyfritt, och om support krävs kan support köpas från Red Hat via regionala partners.
Om RHV priser
Kostnaden är inte hög jämfört med VMware, endast support köps – utan krav på att köpa själva licensen. Support köps endast för hypervisorer, ovirt-engine kräver, till skillnad från vCenter Server, inga utgifter.
Exempel på beräkning för 1:a ägaråret
Låt oss överväga ett kluster med 4 maskiner med två uttag och detaljhandelspriser (utan projektrabatter).
Standard RHV-abonnemang per uttag/år (premium 365/24/7 — $1499), totalt 4*2*$999=$7992.
:
- VMware vCenter Server Standard 10,837.13 2,625.41 USD per instans, plus grundprenumeration 3,125.39 XNUMX USD (Produktion — XNUMX XNUMX USD);
- VMware vSphere Standard $1,164.15 552.61 + Grundprenumeration $653.82 (Produktion $XNUMX);
- VMware vSphere Enterprise Plus 6,309.23 1,261.09 USD + Grundprenumeration 1,499.94 XNUMX USD (produktion XNUMX XNUMX USD).
Totalt: 10 837,13 + 2 625,41 + 4 * 2 * (1 164,15 + 552,61) = $ 27 196,62 för det yngsta alternativet. Skillnaden är cirka 3,5 gånger!
I oVirt är alla funktioner tillgängliga utan begränsningar.
Korta egenskaper och maximivärden
Systemkrav
Hypervisorn kräver en CPU med hårdvaruvirtualisering aktiverad, minsta mängd RAM för att starta är 2 GiB, den rekommenderade lagringsmängden för operativsystemet är 55 GiB (mest för loggar, etc., själva operativsystemet tar upp lite).
Fler detaljer - .
för minimikrav 2 kärnor/4 GiB RAM/25 GiB lagring. Rekommenderas - från 4 kärnor/16 GiB RAM/50 GiB lagring.
Som med vilket system som helst finns det begränsningar för volymer och kvantiteter, varav de flesta överstiger kapaciteten hos tillgängliga kommersiella massservrar. Ja, par kan adressera 2 TiB RAM och ger 40 kärnor (80 trådar), vilket är mindre än till och med gränserna för en enda virtuell dator.
Maximum för virtuell maskin:
- Maximalt antal virtuella maskiner som körs samtidigt: Obegränsat;
- Maximalt antal virtuella processorer per virtuell maskin: 384;
- Maximalt minne per virtuell maskin: 4 TiB;
- Maximal enkel diskstorlek per virtuell maskin: 8 TiB.
Värdmaximum:
- Logiska CPU-kärnor eller -trådar: 768;
- RAM: 12 TiB;
- Antal värdbaserade virtuella maskiner: 250;
- Samtidiga livemigreringar: 2 inkommande, 2 utgående;
- Live migreringsbandbredd: Standard till 52 MiB (~436 Mb) per migrering när du använder den äldre migreringspolicyn. Andra policyer använder adaptiva genomströmningsvärden baserade på den fysiska enhetens hastighet. QoS-policyer kan begränsa migreringsbandbredden.
Manager logiska entitetsmaximum:
I 4.3 finns det .
- datacenter
- Maximalt antal datacenter: 400;
- Maximalt antal värdar: 400 stöds, 500 testade;
- Maximalt antal virtuella datorer: 4000 stöds, 5000 testade;
- kluster
- Maximalt antal kluster: 400;
- Maximalt antal värdar: 400 stöds, 500 testade;
- Maximalt antal virtuella datorer: 4000 stöds, 5000 testade;
- nätverks
- Logiska nätverk/kluster: 300;
- SDN/externa nätverk: 2600 testade, ingen påtvingad gräns;
- lagring
- Maximalt antal domäner: 50 stöds, 70 testade;
- Värdar per domän: Ingen gräns;
- Logiska volymer per blockdomän (mer): 1500;
- Maximalt antal LUN:er (fler): 300;
- Maximal diskstorlek: 500 TiB (begränsat till 8 TiB som standard).
Genomförandealternativ
Som redan nämnts är oVirt byggt av 2 grundläggande element - ovirt-motor (kontroll) och ovirt-host (hypervisor).
Motorn kan placeras antingen utanför själva plattformen (fristående Manager - detta kan vara en virtuell dator som körs på en annan plattform eller en separat hypervisor, eller till och med en fysisk maskin) eller på själva plattformen (självvärd motor, liknande VCSA-metoden från VMware).
Hypervisorn kan installeras på båda (EL Host), och vidare (oVirt-Node, baserat på el7).
Hårdvarukraven för alla alternativ är ungefär desamma.
Ris. 4 - standardarkitektur.
Ris. 5 - Egen värd motorarkitektur.
För mig själv valde jag alternativet fristående Manager och EL Hosts:
- fristående Manager är lite lättare när det kommer till startproblem, det finns inget kyckling- och äggdilemma (som med VCSA - du kan inte starta förrän minst en värd är helt uppe), men det finns ett beroende av ett annat system*;
- EL Host ger all kraft i operativsystemet, vilket är användbart för extern övervakning, felsökning, felsökning, etc.
* Detta behövdes dock inte under hela drifttiden, även efter ett allvarligt strömavbrott.
Men låt oss komma till saken!
För experiment är det möjligt att släppa ett par ProLiant BL460c G7-blad med en Xeon® CPU. Vi kommer att använda dem för att återskapa installationsprocessen.
Låt oss ge noderna namnen ovirt.lab.example.com, kvm01.lab.example.com och kvm02.lab.example.com.
Låt oss gå direkt till .
Källa: will.com