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

Introduktion

Öppen källkod projekt oVirt — en fri plattform för företagsvirtualisering. Jag har bläddrat genom habr och upptäckte att oVirt den inte har belysts här så mycket som den förtjänar.
oVirt är faktiskt upstream för det kommersiella systemet Red Hat Virtualization (RHV, tidigare RHEV) och växer under taket av Red Hat. För att undvika förvirring är detta inte samma sak som CentOS vs RHEL, modellen ligger närmare Fedora vs RHEL.
Under huven — KVM, för hantering används ett webbgränssnitt. 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 inom samma komplex.
Projektet är väl dokumenterat, har länge nått mognad för produktiv användning och är redo för hög belastning.
Denna artikel är den första i en serie om hur man bygger en fungerande hög tillgänglighetskluster. Genom att följa dessa kommer vi på kort tid (cirka 2 timmar) få ett helt fungerande system, även om en del frågor förstås inte kommer att kunna belysas, jag ska försöka ta upp 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 2 huvudsakliga entiteter: ovirt-engine och ovirt-host(s). För dem som är bekanta med VMware-produkter är oVirt i huvudsak en plattform som vSphere, ovirt-engine - kontrollskiktet - utför samma funktioner som vCenter, och ovirt-host - hypervisor, 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.

Som gästdatorer stöds de flesta Linux-distributioner och versioner av Windows. Det finns agenter för gästdatorer och optimerade virtuella enheter och drivers virtio, först och främst diskontroller och nätverksgränssnitt.
För att realisera en hög tillgänglighetslösning och alla intressanta funktioner behövs en delad lagring. Stöder både blockbaserade FC, FCoE, iSCSI, samt filbaserade NFS-lagringar och andra. För att implementera en hög tillgänglighetslösning måste lagringssystemet också vara hög tillgängligt (minst 2 kontrollers, multipathing).
Användning av lokala lagringssystem är möjlig, men som standard är endast delade lagringssystem (shared storages) lämpliga för den aktuella klustret. Lokala lagringssystem gör systemet till en uppsättning av skilda hypervisorer, och även vid närvaro av delad lagring går det inte att sätta ihop ett kluster. Den mest korrekta vägen är diskfria maskiner med boot from SAN, eller diskar av minimal storlek. Det är troligt att en variant av att bygga från lokala diskar som Software Defined Storage (t.ex. Ceph) och presentera det för VM är möjlig genom vdsm hook, men det har jag inte övervägt seriöst.

Arkitektur

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

Fig. 3 — objekt i oVirt.

Den övre nivån i hierarkin är Datacenter. Den definierar vilka delade (shared) eller lokala lagringssystem som används samt vilken uppsättning funktioner som är tillgängliga (kompatibilitet, från 4.1 till 4.3). Det kan finnas en eller flera. För många alternativ går det bra att använda standard Data Center — Default.
Data Center består av ett eller flera kluster.Ett kluster definierar typ av processor, migrationspolicyer och mer. För små installationer kan man även nöja sig med klustret Default.
Ett kluster består i sin tur av Värdvärdar som utför det huvudsakliga arbetet — de bär virtuella maskiner och har lagringssystem anslutna till sig. I ett kluster antas det finnas två eller fler värdar. Även om det tekniskt är möjligt att skapa ett kluster med en värd, har det ingen praktisk nytta.

oVirt stöder många funktioner, inklusive levande migrering av virtuella maskiner mellan hypervisorer (live migration) och lagringssystem (storage migration), skrivbordsvirtualisering (virtual desktop infrastructure) med VM-pooler, statefull och stateless VM, stöd för NVidia Grid vGPU, import från vSphere, KVM, samt en kraftfull API och mycket mer. Alla dessa funktioner är tillgängliga utan licensavgifter, och om support behövs kan den köpas från Red Hat genom regionala partners.

Angående priser på RHV

Kostnaden är inte hög i jämförelse med VMware, man köper endast support — utan krav på att köpa själva licensen. Support köps endast för hypervisorer och ovirt-engine, till skillnad från vCenter Server kräver den inga kostnader.

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

Vi betraktar ett kluster med 4 tvåsockliga maskiner och detaljhandelspriser (utan projektpriser).
Standardabonnemanget 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 (Produktion — 3 125,39 kr);
• VMware vSphere Standard 1 164,15 kr + Basic-prenumeration 552,61 kr (Produktion 653,82 kr);
• VMware vSphere Enterprise Plus 6 309,23 kr + Basic-prenumeration 1 261,09 kr (Produktion 1 499,94 kr).

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

Kortfattade egenskaper och maxvärden

Systemkrav

För hypervisor krävs en CPU med aktiverad hårdvaruvirtualisering, minneskrav för start — 2 GiB, rekommenderad lagringskapacitet för OS — 55 GiB (främst för loggar och liknande, själva OS:et tar upp lite).
Läs mer — här.
För Engine minimala krav 2 kärnor/4 GiB RAM/25 GiB lagring. Rekommenderade — från 4 kärnor/16 GiB RAM/50 GiB lagring.
Som i alla system finns det begränsningar för volymer och antal, de flesta av vilka överstiger kapaciteten hos tillgängliga massmarknadsservrar. Till exempel kan två Intel Xeon Gold 6230 adressera 2 TiB RAM och erbjuder 40 kärnor (80 trådar), vilket är mindre än även gränserna för en VM.

Maximala virtuella maskiner:

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

Värdmaximala värden:

• Logiska CPU-kärnor eller trådar: 768;
• RAM: 12 TiB;
• Antal värdarbete virtuella maskiner: 250;
• Samtidiga live-migreringar: 2 inkommande, 2 utgående;
• Bandbredd för live-migrering: Standard 52 MiB (~436 Mb) per migrering när den använder den äldre migreringspolitiken. Andra policyer använder adaptiva genomströmningsvärden baserat på hastigheten på den fysiska enheten. QoS-policyer kan begränsa migreringsbandbredd.

Maximala logiska enheter för hanterare:

I 4.3 finns det följande gränser.

• Datacenter
  • Maximalt antal datacenter: 400;
  • Maximalt antal värdar: 400 stödda, 500 testade;
  • Maximalt antal VM: 4000 stödda, 5000 testade;
• Kluster
  • Maximalt antal kluster: 400;
  • Maximalt antal värdar: 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 fast 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;
  • Maximala antalet LUN:er (mer): 300;
  • Maximal disklagringskapacitet: 500 TiB (begränsad till 8 TiB som standard).

Implementeringsalternativ

Som redan nämnts byggs oVirt av 2 grundläggande element — ovirt-engine (hantering) och ovirt-host (hypervisor).
Engine 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, motsvarande VCSA-metoden från VMware).
Hypervisorn kan installeras antingen på vanlig RHEL/CentOS 7 (EL Host), eller 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 för mig själv:

• Standalone Manager är något enklare vid startproblem, det finns ingen hönan och ägget-dilemma (som för VCSA — du kan inte starta förrän åtminstone en värd är helt uppe), men det skapar beroende av ett annat system*;
• EL Host ger hela kraften hos OS, vilket är användbart för extern övervakning, felsökning, problemidentifiering, etc.

* Men under hela driftstiden har detta inte varit nödvändigt, även efter en allvarlig strömavbrott.
Men nu går vi in på sak!
För experimentet finns möjligheten att frigöra några ProLiant BL460c G7 med Xeon® CPU. På dem ska vi utföra installationsprocessen.
Vi ger noder namnen ovirt.lab.example.com, kvm01.lab.example.com och kvm02.lab.example.com.
Vi går direkt till installation.

Källa: habr.com