oVirt på 2 timmar. Del 1. Öppen felsäker plattform för virtualisering

Introduktion

Öppen källkod projekt oVirt — en fri plattform för virtualisering av företagsnivå. Efter att ha bläddrat på habr, upptäckte jag att oVirt det inte har uppmärksammats här så mycket som det förtjänar.
oVirt är faktiskt upstream för det kommersiella systemet Red Hat Virtualization (RHV, tidigare RHEV), som växer under Red Hats beskydd. För att undvika förvirring är detta inte detsamma som CentOS vs RHEL, modellen är närmare Fedora vs RHEL.
Under huven — KVM, används ett webbaserat gränssnitt för hantering. Bygger på RHEL/CentOS 7.
oVirt kan användas både för "traditionell" server- och skrivbordsvirtualisering (VDI), till skillnad från VMware-lösningen kan båda systemen samexistera i samma komplex.
Projektet är väl dokumenterat, har länge nått mognad för produktionsanvändning och är redo för hög belastning.
Denna artikel är den första i en serie om hur man bygger en fungerande redundant kluster. Genom att följa dem kommer vi på kort tid (ungefär 2 timmar) att få ett helt fungerande system, även om vissa frågor tyvärr inte kan belysas, kommer jag att försöka täcka dem i kommande artiklar.
Vi har använt det i flera år, började med version 4.1. Vårt produktionssystem körs nu på HPE Synergy 480 och ProLiant BL460c 10:e generationen med Xeon Gold CPU.
Vid tidpunkten för skrivandet är den aktuella versionen 4.3.

Artiklar

1. Introduktion (Vi är här)
2. Installation av hanteraren (ovirt-engine) och hypervisorer (värdar)
3. Ytterligare inställningar

Funktionella egenskaper

I oVirt finns det två grundläggande enheter: ovirt-engine och ovirt-host(s). För dem som är välbekanta med VMware-produkterna är oVirt i allmänhet som en plattform som vSphere, ovirt-engine — styrskiktet — utför samma funktioner som vCenter, medan ovirt-host — hypervisor, precis som ESX(i). Eftersom vSphere är en mycket populär lösning kommer jag ibland att göra jämförelser med den.

Fig. 1 — oVirt kontrollpanel.

De flesta Linux-distributioner och Windows-versioner stöds som gästmaskiner. För gästmaskiner finns det agenter och optimerade virtuella enheter och virtio-drivrutiner, i första hand diskcontroller och nätverksgränssnitt.
För att implementera en redundant lösning och alla intressanta funktioner krävs en delad lagring. Såväl block-FC, FCoE, iSCSI samt filbaserade NFS-lagringar stöds m.m. För att implementera en redundant lösning måste lagringssystemet också vara redundant (minst 2 kontrollers, multipath).
Användning av lokala lagringslösningar är möjligt, men som standard är endast delade lagringslösningar (shared storages) lämpliga för den aktuella klustret. Lokala lagringslösningar gör systemet till en splittrad uppsättning hypervisorer, och även med en delad lagring går det inte att bygga ett kluster. Den mest korrekta vägen är diskfria maskiner med boot from SAN, eller diskar med minimal kapacitet. Det är möjligt att, via vdsm hook, skapa en lösning med lokala diskar i Software Defined Storage (t.ex. Ceph) och presentera dem för VM, men jag har inte övervägt detta seriöst.

Arkitektur

Fig. 2 — arkitektur för oVirt.
Mer om arkitekturen kan läsas i dokumentationen utvecklarens dokumentation.

Fig. 3 — oVirt-objekt.

Översta elementet i hierarkin — Datacenter. Det definierar om delade (shared) eller lokala lagringslösningar används, samt vilka funktioner som stöds (kompatibilitet, från 4.1 till 4.3). Det kan finnas en eller flera. För många scenarier fungerar det att använda standard Data Center — Default.
Data Center består av en eller flera Clusters. Klustret definierar typ av processor, migrationspolicyer och mer. För små installationer kan man även begränsa sig till klustret Default.
Klustret består i sin tur av Värdvärdar som utför huvuduppgiften — de har virtuella maskiner och är anslutna till lagringslösningar. Ett kluster förutsätter 2 eller fler värdar. Även om det tekniskt är möjligt att göra ett kluster med 1 värd, så har det ingen praktisk nytta.

oVirt stöder många funktioner, inklusive live migration av virtuella maskiner mellan hypervisorer (live migration) och lagringslösningar (storage migration), desktopvirtualisering (virtual desktop infrastructure) med VM-pooler, stateful och stateless VM, stöd för NVidia Grid vGPU, import från vSphere, KVM, och har kraftfulla API och mycket mer. Alla dessa funktioner är tillgängliga utan licensavgifter, och vid behov kan stöd köpas från Red Hat via regionala partners.

Priser för RHV

Kostnaden är låg i jämförelse med VMware; stöd köps endast — utan krav på att köpa själva licensen. Stöd köps endast för hypervisorer, ovirt-engine, till skillnad från vCenter Server som kräver kostnader.

Exempel på beräkning för det första året av ägande

Tänk på ett kluster av 4 stycken maskiner med 2 socklar och detaljhandelspriser (utan projektavdrag).
Standardprenumeration för RHV kostar $999 per sockel/år (premium 365/24/7 — $1499), totalt 4*2*$999=$7992.
Priset för vSphere:

• VMware vCenter Server Standard 10 837,13 kr per instans, plus Basic-prenumeration 2 625,41 kr (Production — 3 125,39 kr);
• VMware vSphere Standard 1 164,15 kr + Basic-prenumeration 552,61 kr (Production 653,82 kr);
• VMware vSphere Enterprise Plus 6 309,23 kr + Basic-prenumeration 1 261,09 kr (Production 1 499,94 kr).

Totalt: 10 837,13 + 2 625,41 + 4 * 2 * (1 164,15 + 552,61) = $27 196,62 för den mest grundläggande varianten. Skillnaden är cirka 3,5 gånger!
I oVirt är dock alla funktioner tillgängliga utan begränsningar.

Kortfattad information och maxvärden

Systemkrav

Hypervisorn kräver en CPU med aktiverad hårdvaruvirtualisering, det minimi minneskrav för start är 2 GiB, rekommenderad lagringsutrymme för OS är 55 GiB (främst för loggar osv., själva OS tar lite).
Mer information — här.
För Motor minimikrav 2 kärnor/4 GiB RAM/25 GiB lagring. Rekommenderat — från 4 kärnor/16 GiB RAM/50 GiB lagring.
Precis som i vilket system som helst finns det begränsningar på volymer och antal, de flesta av vilka överstiger kapaciteten hos tillgängliga massmarknadsservrar. Så, en uppsättning Intel Xeon Gold 6230 kan adressera 2 TiB RAM och erbjuder 40 kärnor (80 trådar), vilket är mindre än till och med gränserna för en VM.

Maximala maskinvarukrav för virtuella maskiner:

• Maximalt antal samtidigt körande virtuella maskiner: Obegränsat;
• Maximala virtuella CPU:er per virtuell maskin: 384;
• Maximalt minne per virtuell maskin: 4 TiB;
• Maximal storlek på enskild disk per virtuell maskin: 8 TiB.

Värdmaximum:

• Logiska processorerkärnor eller trådar: 768;
• RAM: 12 TiB;
• Antal värdgratulerade virtuella maskiner: 250;
• Samtida live-migreringar: 2 inkommande, 2 utgående;
• Live-migreringsbandbredd: Standard 52 MiB (~436 Mb) per migrering när den använder den traditionella migreringspolicyn. Andra policys använder adaptiva genomströmningsvärden baserade på hastigheten på den fysiska enheten. QoS-policys kan begränsa migreringsbandbredden.

Maximala logiska enheter för hanteraren:

I 4.3 finns det följande begränsningar.

• Datacenter
  • Maximalt antal datacentra: 400;
  • Maximalt värdantal: 400 stödda, 500 testade;
  • Maximalt antal VM: 4000 stödda, 5000 testade;
• Kluster
  • Maximalt antal kluster: 400;
  • Maximalt värdantal: 400 stödda, 500 testade;
  • Maximalt antal VM: 4000 stödda, 5000 testade;
• Nätverk
  • Logiska nätverk/kluster: 300;
  • SDN/externa nätverk: 2600 testade, ingen tvingande gräns;
• Storage
  • Maximala domäner: 50 stödda, 70 testade;
  • Värdar per domän: Ingen gräns;
  • Logiska volymer per blockdomän (mer): 1500;
  • Maximalt antal LUN: 300;
  • Maximal diskkapacitet: 500 TiB (begränsad till 8 TiB som standard).

Implementeringsalternativ

Som redan nämnts, bygger oVirt på 2 grundläggande element — ovirt-engine (hantering) och ovirt-host (hypervisor).
Motor kan placeras antingen utanför plattformen (standalone Manager — det kan vara en VM som körs på en annan plattform eller en separat hypervisor och till och med en fysisk maskin), eller på själva plattformen (self-hosted engine, liknande VCSA-ansatsen från VMware).
Hypervisorn kan installeras både på vanlig OS RHEL/CentOS 7 (EL-värd), såväl som på specialiserad minimal OS (oVirt-Node, baserad på el7).
Hårdvarukraven för alla alternativ är ungefär desamma.

Fig. 4 — standardarkitektur.

Fig. 5 — Självhostad Engine-arkitektur.

Jag valde alternativet standalone Manager och EL Hosts:

• Standalone Manager är något enklare när det gäller startproblem, det finns ingen dilemma med hönan och ägget (som för VCSA — du kan inte starta förrän åtminstone en värd är helt igång), men det finns beroende av ett annat system*;
• EL Host erbjuder hela kraften i operativsystemet, vilket är användbart för extern övervakning, debug, felsökning osv.

* Men under hela användningen har detta aldrig varit nödvändigt, inte ens efter en allvarlig strömavbrott.
Men nu börjar vi på riktigt!
För experimentet finns möjlighet att frigöra ett par ProLiant BL460c G7 med Xeon® CPU. Det är de vi ska använda för att återskapa installationsprocessen.
Vi ger värdarna namn ovirt.lab.example.com, kvm01.lab.example.com och kvm02.lab.example.com.
Vi går direkt till installation.

Källa: habr.com