Inleiding
Open source project — een open-source virtualisatieplatform van ondernemingsniveau. Door habr te bladeren, ontdekte ik dat het hier niet zo breed verlicht is als het verdient.
oVirt is feitelijk de upstream voor het commerciële systeem Red Hat Virtualization (RHV, voorheen RHEV) en groeit onder de vleugels van Red Hat. Om verwarring te voorkomen, is dit niet hetzelfde als CentOS vs RHEL, het model is dichter bij Fedora vs RHEL.
Onder de motorkap — , voor beheer wordt een webinterface gebruikt. Het is gebaseerd op het OS RHEL/CentOS 7.
oVirt kan worden gebruikt voor zowel 'traditionele' server- als desktopvirtualisatie (VDI); in tegenstelling tot de oplossing van VMware kunnen beide systemen samenleven in één set.
Het project is goed , heeft lang geleden volwassenheid bereikt voor productief gebruik en is klaar voor hoge belasting.
Dit artikel is de eerste in een cyclus over het opbouwen van een werkende failover-cluster. Door ze te volgen, zullen we in korte tijd (ongeveer 2 uur) een volledig operationeel systeem hebben, hoewel een aantal vragen natuurlijk niet kan worden behandeld, ik zal proberen deze in de volgende artikelen aan te snijden.
We gebruiken het al een paar jaar, we zijn begonnen met versie 4.1. Ons industriële systeem draait nu op HPE Synergy 480 en ProLiant BL460c 10e generatie met Xeon Gold CPU.
Op het moment van schrijven is de huidige versie 4.3.
Artikelen
- Inleiding (We zijn hier)
Functionele kenmerken
In oVirt zijn er 2 hoofddiensten: ovirt-engine en ovirt-host(s). Voor degenen die goed bekend zijn met de producten van VMware, is oVirt als platform in het algemeen vergelijkbaar met vSphere; ovirt-engine — de behe laag — vervult dezelfde functies als vCenter, en ovirt-host — de hypervisor, zoals ESX(i). Aangezien vSphere een zeer populaire oplossing is, zal ik soms vergelijkingen met het maken.
Figuur 1 — oVirt bedieningspaneel.
De meeste Linux-distributies en versies van Windows worden als gastmachines ondersteund. Voor gastmachines zijn er agents en geoptimaliseerde virtuele apparaten en virtio-drivers, voornamelijk de schijfcontroller en het netwerkinterface.
Voor de implementatie van een failover-oplossing en alle interessante functies is gedeeld opslag vereist. Zowel blokkade FC, FCoE, iSCSI, als bestands-NFS-opslag worden ondersteund, enz. Voor de implementatie van een failover-oplossing moet het opslagsysteem ook failover-veilig zijn (minimaal 2 controllers, multipathing).
Het gebruik van lokale opslag is mogelijk, maar standaard zijn alleen gedeelde opslag (shared storages) geschikt voor een echte cluster. Lokale opslag maakt het systeem een onsamenhangende verzameling hypervisors, en zelfs met gedeelde opslag is het niet mogelijk om een cluster op te bouwen. De beste aanpak is om schijfloze machines met boot from SAN te gebruiken, of schijven met een minimale capaciteit. Waarschijnlijk is het via een vdsm hook mogelijk om een opstelling te maken van lokale schijven Software Defined Storage (bijv. Ceph) en dit aan te bieden aan VM's, maar dit heb ik niet serieus overwogen.
Architectuur
Figuur 2 — de architectuur van oVirt.
Details over de architectuur zijn beschikbaar in de ontwikkelaar.
Figuur 3 — oVirt-objecten.
Het bovenste element in de hiërarchie is Datacenter. Dit bepaalt of gedeelde (shared) of lokale opslag wordt gebruikt, evenals de set functies die worden gebruikt (compatibiliteit, van 4.1 tot 4.3). Er kan één of meerdere zijn. Voor veel varianten is het gebruik van een Data Center standaard — Default.
Een Data Center bestaat uit één of meerdere Clusters. Een cluster bepaalt het type processor, migratiebeleid, enz. Voor kleine installaties kan ook volstaan worden met het Default-cluster.
Een cluster bestaat op zijn beurt uit Hosthosts die het zware werk doen — zij dragen de virtuele machines, en ze zijn verbonden met de opslag. In een cluster wordt 2 of meer hosts verondersteld. Hoewel het technisch mogelijk is om een cluster met 1 host te maken, heeft dit geen praktische waarde.
oVirt ondersteunt vele functies, waaronder live migratie van virtuele machines tussen hypervisors (live migration) en opslag (storage migration), desktopvirtualisatie (virtual desktop infrastructure) met VM-pools, statefull en stateless VM's, ondersteuning voor NVidia Grid vGPU, import vanuit vSphere, KVM, er is krachtige en nog veel meer. Al deze functies zijn beschikbaar zonder licentiekosten, en indien ondersteuning nodig is, kan deze worden aangeschaft bij Red Hat via regionale partners.
Over prijzen voor RHV
De kosten zijn niet hoog vergeleken met VMware, alleen de ondersteuning wordt aangeschaft — er is geen verplichting tot aanschaf van de licentie zelf. Ondersteuning wordt alleen gekocht voor hypervisors, ovirt-engine, in tegenstelling tot vCenter Server vereist dit geen uitgaven.
Voorbeeld van berekening voor het eerste jaar van eigendom
Laten we een cluster van 4 machines met 2 sockets bekijken en de detailhandelsprijzen (zonder projectkortingen).
Standaardabonnement RHV per socket/jaar (premium 365/24/7 — $1499), in totaal 4*2*$999=$7992.
:
- VMware vCenter Server Standard €10.837,13 per exemplaar, plus Basic abonnement €2.625,41 (Productie — €3.125,39);
- VMware vSphere Standard €1.164,15 + Basic abonnement €552,61 (Productie €653,82);
- VMware vSphere Enterprise Plus €6.309,23 + Basic abonnement €1.261,09 (Productie €1.499,94).
Totaal: 10.837,13 + 2.625,41 + 4 * 2 * (1.164,15 + 552,61) = $27 196,62 voor de meest basale optie. Het verschil is ongeveer 3,5 keer!
In oVirt zijn alle functies zonder beperkingen beschikbaar.
Korte specificaties en maxima
Systeemvereisten
Voor de hypervisor is een CPU met ingeschakelde hardwarevirtualisatie vereist, minimum RAM voor opstarten — 2 GiB, aanbevolen opslagcapaciteit voor het OS — 55 GiB (voornamelijk voor logs, het OS zelf neemt weinig ruimte in beslag).
Meer informatie — .
Voor minimale vereisten 2 cores / 4 GiB RAM / 25 GiB opslag. Aangeraden — vanaf 4 cores / 16 GiB RAM / 50 GiB opslag.
Net als in elk systeem zijn er limieten op hoeveelheden en aantallen, waarvan de meeste de mogelijkheden van beschikbare commerciële servers overschrijden. Zo kan een paar tot 2 TiB RAM adresseren en biedt 40 cores (80 threads), wat zelfs onder de limieten van één VM ligt.
Virtual Machine Maxima:
- Maximum gelijktijdig draaiende virtuele machines: Onbeperkt;
- Maximum virtuele CPU's per virtuele machine: 384;
- Maximum geheugen per virtuele machine: 4 TiB;
- Maximum grootte van enkele schijf per virtuele machine: 8 TiB.
Host Maxima:
- Logische CPU cores of threads: 768;
- RAM: 12 TiB;
- Aantal gehoste virtuele machines: 250;
- Gelijktijdige live migraties: 2 binnenkomend, 2 uitgaand;
- Live migratiebandbreedte: Standaard 52 MiB (~436 Mb) per migratie bij gebruik van het oude migratiebeleid. Andere beleidsregels gebruiken adaptieve doorvoersnelheden op basis van de snelheid van het fysieke apparaat. QoS-beleidsregels kunnen de migratiebandbreedte beperken.
Manager Logische Entiteit Maxima:
In 4.3 zijn er .
- Datacenter
- Maximum aantal datacenters: 400;
- Maximum aantal hosts: 400 ondersteund, 500 getest;
- Maximum aantal VM's: 4000 ondersteund, 5000 getest;
- Cluster
- Maximum aantal clusters: 400;
- Maximum aantal hosts: 400 ondersteund, 500 getest;
- Maximum aantal VM's: 4000 ondersteund, 5000 getest;
- Netwerk global log /dev/log local0 log /dev/log local1 notice chroot /var/lib/haproxy stats timeout 30s user haproxy group haproxy daemondefaults log global mode http option httplog option dontlognull timeout connect 5000 timeout client 50000 timeout server 50000frontend http_front bind *:80 stats uri /haproxy?stats default_backend http_backbackend http_back balance roundrobin server server_name1 private_ip1:80 check server server_name2 private_ip2:80 check
- Logische netwerken / cluster: 300;
- SDN / externe netwerken: 2600 getest, geen afgedwongen limiet;
- Opslag
- Maximum aantal domeinen: 50 ondersteund, 70 getest;
- Hosts per domein: Geen limiet;
- Logische volumes per blokdomein (meer): 1500;
- Maximum aantal LUN's (meer): 300;
- Maximum schijfgrootte: 500 TiB (standaard beperkt tot 8 TiB).
Implementatie opties
Zoals eerder vermeld, is oVirt opgebouwd uit 2 basiscomponenten — ovirt-engine (beheer) en ovirt-host (hypervisor).
Engine kan zowel buiten het platform zelf worden gehost (standalone Manager — dit kan een VM zijn die op een ander platform of een aparte hypervisor draait, of zelfs een fysieke machine), als op het platform zelf (self-hosted engine, vergelijkbaar met de VCSA-aanpak van VMware).
De hypervisor kan worden geïnstalleerd op (EL Host), of op (oVirt-Node, gebaseerd op el7).
De hardwarevereisten voor alle opties zijn ongeveer gelijk.
Figuur 4 — standaardarchitectuur.
Figuur 5 — Architectuur van de zelf-gehoste Engine.
Ik heb gekozen voor de standalone Manager en EL Hosts:
- De standalone Manager is iets eenvoudiger bij opstartproblemen, er is geen dilemma van de kip en het ei (zoals bij VCSA — je kunt het niet starten totdat ten minste één host volledig is opgestart), maar er ontstaat afhankelijkheid van een ander systeem*;
- EL Host biedt de volledige kracht van het besturingssysteem, wat nuttig is voor extern toezicht, debugging, foutopsporing, enz.
* Echter, gedurende de hele gebruiksperiode was dit niet nodig, zelfs niet na een ernstige stroomstoring.
Maar laten we nu ter zake komen!
Voor het experiment is het mogelijk om een paar ProLiant BL460c G7 blades met Xeon® CPU vrij te maken. Daar zullen we het installatieproces uitvoeren.
We zullen de knooppunten de namen ovirt.lab.example.com, kvm01.lab.example.com en kvm02.lab.example.com geven.
Laten we direct naar .
Bron: habr.com
