oVirt over 2 uur. Deel 1. Open, fouttolerant virtualisatieplatform

Introductie

Open source-project oVirt — een gratis virtualisatieplatform op ondernemingsniveau. Nadat ik door habr had gescrolld, ontdekte ik dat oVirt wordt hier niet zo breed behandeld als het verdient.
oVirt is eigenlijk een upstream voor het commerciële systeem Red Hat Virtualization (RHV, voorheen RHEV), dat groeit onder de vleugels van Red Hat. Om verwarring te voorkomen dit geen hetzelfde als CentOS versus RHEL, model dichter bij Fedora versus RHEL.
Onder de motorkap - KVMVoor het beheer wordt een webinterface gebruikt. Gebaseerd op RHEL/CentOS 7 besturingssysteem.
oVirt kan worden gebruikt voor zowel “traditionele” server- als desktopvirtualisatie (VDI). In tegenstelling tot de VMware-oplossing kunnen beide systemen naast elkaar bestaan ​​in één complex.
Het project is goed gedocumenteerd, is al lang volwassen voor productief gebruik en is klaar voor hoge belastingen.
Dit artikel is het eerste in een serie over het bouwen van een werkend failovercluster. Nadat we ze hebben doorgenomen, krijgen we in korte tijd (ongeveer 2 uur) een volledig werkend systeem, hoewel een aantal problemen natuurlijk niet onthuld zullen worden; ik zal proberen ze in de volgende artikelen te behandelen.
Wij gebruiken het al enkele jaren, te beginnen met versie 4.1. Ons industriële systeem draait momenteel op HPE Synergy 480 en ProLiant BL460c 10e generatie computers met Xeon Gold CPU.
Op het moment van schrijven is de huidige versie 4.3.

Artikelen

  1. Introductie (we zijn er)
  2. Installatie van de manager (ovirt-engine) en hypervisors (hosts)
  3. Aanvullende instellingen

Functionele kenmerken

Er zijn 2 hoofdentiteiten in oVirt: ovirt-engine en ovirt-host(s). Voor degenen die bekend zijn met VMware-producten: oVirt als geheel als platform is vSphere, ovirt-engine - de controlelaag - voert dezelfde functies uit als vCenter, en ovirt-host is een hypervisor, zoals ESX (i). Omdat vSphere is een zeer populaire oplossing, ik zal het er soms mee vergelijken.
oVirt over 2 uur. Deel 1. Open, fouttolerant virtualisatieplatform
Rijst. 1 — oVirt-bedieningspaneel.

De meeste Linux-distributies en versies van Windows worden ondersteund als gastmachines. Voor gastmachines zijn er agenten en geoptimaliseerde virtuele apparaten en virtuele stuurprogramma's, voornamelijk de schijfcontroller en netwerkinterface.
Om een ​​fouttolerante oplossing en alle interessante functies te implementeren, heb je gedeelde opslag nodig. Er worden zowel blok-FC-, FCoE-, iSCSI- als NFS-bestandsopslagen enz. ondersteund. Om een ​​fouttolerante oplossing te implementeren, moet het opslagsysteem ook fouttolerant zijn (minstens 2 controllers, multipassing).
Het gebruik van lokale opslag is mogelijk, maar standaard zijn alleen gedeelde opslag geschikt voor een echt cluster. Lokale opslag maakt het systeem tot een ongelijksoortige set hypervisors, en zelfs met gedeelde opslag kan er geen cluster worden samengesteld. De meest correcte manier zijn schijfloze machines die opstarten vanaf SAN, of schijven van minimale grootte. Waarschijnlijk is via de vdsm hook de optie om Software Defined Storage vanaf lokale schijven (bijvoorbeeld Ceph) samen te stellen en deze aan een VM te presenteren mogelijk, maar ik heb er niet serieus over nagedacht.

Architectuur

oVirt over 2 uur. Deel 1. Open, fouttolerant virtualisatieplatform
Rijst. 2 - oVirt-architectuur.
Meer details over de architectuur zijn te vinden in documentatie ontwikkelaar.

oVirt over 2 uur. Deel 1. Open, fouttolerant virtualisatieplatform
Rijst. 3 — oVirt-objecten.

Het bovenste element in de hiërarchie is − Data Center. Het bepaalt of gedeelde of lokale opslag wordt gebruikt, evenals de gebruikte functieset (compatibiliteit, 4.1 tot 4.3). Het kunnen er een of meer zijn. Voor veel opties is het gebruik van het standaard Datacenter - Standaard - geschikt.
Datacenter bestaat uit een of meer Clusters. Het cluster bepaalt het processortype, het migratiebeleid, etc. Voor kleine installaties kunt u zich ook beperken tot het Standaardcluster.
Het cluster bestaat op zijn beurt uit gastheer's die het hoofdwerk doen: ze vervoeren virtuele machines en de opslag is ermee verbonden. Een cluster gaat uit van twee of meer hosts. Hoewel het technisch mogelijk is om met 2 host een cluster te maken, heeft dit in de praktijk geen nut.

oVirt ondersteunt vele functies, incl. live migratie van virtuele machines tussen hypervisors (live migratie) en opslagmigratie (opslagmigratie), desktopvirtualisatie (virtuele desktopinfrastructuur) met VM-pools, statefull en stateless VM's, ondersteuning voor NVidia Grid vGPU, import vanuit vSphere, KVM, er is een krachtig API en nog veel meer. Al deze functies zijn royaltyvrij beschikbaar en als ondersteuning nodig is, kan ondersteuning worden gekocht bij Red Hat via regionale partners.

Over RHV-prijzen

De kosten zijn niet hoog in vergelijking met VMware, er wordt alleen ondersteuning gekocht - zonder dat u de licentie zelf hoeft aan te schaffen. Ondersteuning wordt alleen gekocht voor hypervisors; ovirt-engine vereist, in tegenstelling tot vCenter Server, geen kosten.

Berekeningsvoorbeeld voor het 1e jaar van eigendom

Laten we een cluster van 4 2-socketmachines en winkelprijzen (zonder projectkortingen) beschouwen.
Standaard RHV-abonnement kost $ 999 per stopcontact/jaar (premium 365/24/7 — $1499), totaal 4*2*$999=$7992.
vSphere-prijs:

  • VMware vCenter Server Standard $10,837.13 per instance, plus Basic-abonnement $2,625.41 (productie — $3,125.39);
  • VMware vSphere Standard $1,164.15 + Basisabonnement $552.61 (productie $653.82);
  • VMware vSphere Enterprise Plus $ 6,309.23 + basisabonnement $ 1,261.09 (productie $ 1,499.94).

Totaal: 10 + 837,13 + 2 * 625,41 * (4 + 2) = $ 27 196,62 voor de jongste optie. Het verschil is ongeveer 3,5 keer!
In oVirt zijn alle functies zonder beperkingen beschikbaar.

Korte kenmerken en maxima

Systeemvereisten

De hypervisor vereist een CPU met hardwarevirtualisatie ingeschakeld, de minimale hoeveelheid RAM om te starten is 2 GiB, de aanbevolen opslaghoeveelheid voor het besturingssysteem is 55 GiB (meestal voor logs, enz., het besturingssysteem zelf neemt weinig in beslag).
Meer details - hier.
Voor Motor minimumvereisten 2 cores/4 GiB RAM/25 GiB opslag. Aanbevolen - vanaf 4 cores/16 GiB RAM/50 GiB opslag.
Zoals bij elk systeem zijn er beperkingen op volumes en hoeveelheden, waarvan de meeste de mogelijkheden van beschikbare massale commerciële servers overschrijden. Ja, koppel Intel Xeon Gold 6230 kan 2 TiB RAM adresseren en geeft 40 cores (80 threads), wat zelfs minder is dan de limieten van een enkele VM.

Maximumwaarden voor virtuele machines:

  • Maximaal gelijktijdig draaiende virtuele machines: Onbeperkt;
  • Maximale virtuele CPU's per virtuele machine: 384;
  • Maximaal geheugen per virtuele machine: 4 TiB;
  • Maximale grootte van één schijf per virtuele machine: 8 TiB.

Hostmaxima:

  • Logische CPU-kernen of threads: 768;
  • RAM: 12 TiB;
  • Aantal gehoste virtuele machines: 250;
  • Gelijktijdige live migraties: 2 inkomend, 2 uitgaand;
  • Bandbreedte voor livemigratie: standaard ingesteld op 52 MiB (~436 Mb) per migratie bij gebruik van het oude migratiebeleid. Ander beleid maakt gebruik van adaptieve doorvoerwaarden op basis van de snelheid van het fysieke apparaat. QoS-beleid kan de migratiebandbreedte beperken.

Manager Logische Entiteit Maximum:

In 4.3 zijn er de volgende limieten.

  • datacenter
    • Maximaal aantal datacenters: 400;
    • Maximaal aantal hosts: 400 ondersteund, 500 getest;
    • Maximaal aantal VM's: 4000 ondersteund, 5000 getest;
  • TROS
    • Maximaal aantal clusters: 400;
    • Maximaal aantal hosts: 400 ondersteund, 500 getest;
    • Maximaal aantal VM's: 4000 ondersteund, 5000 getest;
  • Netwerk
    • Logische netwerken/cluster: 300;
    • SDN/externe netwerken: 2600 getest, geen opgelegde limiet;
  • Opbergen
    • Maximaal aantal domeinen: 50 ondersteund, 70 getest;
    • Hosts per domein: Geen limiet;
    • Logische volumes per blokdomein (meer): 1500;
    • Maximaal aantal LUN's (meer): 300;
    • Maximale schijfgrootte: 500 TiB (standaard beperkt tot 8 TiB).

Implementatiemogelijkheden

Zoals reeds vermeld is oVirt opgebouwd uit 2 basiselementen: ovirt-engine (controle) en ovirt-host (hypervisor).
De engine kan zich buiten het platform zelf bevinden (standalone Manager - dit kan een VM zijn die op een ander platform draait of een aparte hypervisor, of zelfs een fysieke machine) of op het platform zelf (zelf-gehoste engine, vergelijkbaar met de VCSA-aanpak van VMware).
De hypervisor kan op beide worden geïnstalleerd regulier besturingssysteem RHEL/CentOS 7 (EL Host) en zo verder gespecialiseerd minimaal besturingssysteem (oVirt-Node, gebaseerd op el7).
De hardwarevereisten voor alle opties zijn ongeveer hetzelfde.
oVirt over 2 uur. Deel 1. Open, fouttolerant virtualisatieplatform
Rijst. 4 - standaardarchitectuur.

oVirt over 2 uur. Deel 1. Open, fouttolerant virtualisatieplatform
Rijst. 5 - Zelf-gehoste engine-architectuur.

Voor mezelf heb ik gekozen voor de optie standalone Manager en EL Hosts:

  • standalone Manager is iets eenvoudiger als het gaat om opstartproblemen, er is geen sprake van een kip-en-ei-dilemma (zoals bij VCSA: je kunt pas starten als ten minste één host volledig actief is), maar er is wel een afhankelijkheid van een ander systeem*;
  • EL Host biedt alle kracht van het besturingssysteem, wat handig is voor externe monitoring, foutopsporing, probleemoplossing, enz.

* Gedurende de gehele bedrijfsperiode was dit echter niet nodig, ook niet na een ernstige stroomstoring.
Maar laten we ter zake komen!
Voor experimenten is het mogelijk om een ​​paar ProLiant BL460c G7-blades met een Xeon® CPU uit te brengen. We zullen ze gebruiken om het installatieproces te reproduceren.
Laten we de knooppunten de namen ovirt.lab.example.com, kvm01.lab.example.com en kvm02.lab.example.com geven.
Laten we direct naar gaan installatie.

Bron: www.habr.com

Voeg een reactie