Einführung
Open-Source-Projekt ist eine kostenlose Virtualisierungsplattform der Enterprise-Klasse. Beim Scrollen durch Habr habe ich das gefunden wird nicht so umfassend abgedeckt, wie es verdient.
oVirt ist eigentlich der Upstream des kommerziellen Red Hat Virtualization (RHV, früher RHEV)-Systems und wächst unter der Fittiche von Red Hat. Um Verwirrung zu vermeiden, dies nicht Das gleiche wie CentOS vs. RHEL, das Modell ähnelt eher Fedora vs. RHEL.
Unter der Haube - Für die Verwaltung wird das Webinterface genutzt. Basierend auf dem Betriebssystem RHEL/CentOS 7.
oVirt kann sowohl für die „traditionelle“ Server- als auch für die Desktop-Virtualisierung (VDI) eingesetzt werden, im Gegensatz zur VMware-Lösung können beide Systeme in einem Komplex koexistieren.
Gut projizieren , hat längst die Reife für den produktiven Einsatz erreicht und ist bereit für hohe Belastungen.
Dieser Artikel ist der erste einer Reihe zum Aufbau eines funktionierenden Failover-Clusters. Nachdem wir sie durchgearbeitet haben, werden wir in kurzer Zeit (ca. 2 Stunden) ein voll funktionsfähiges System erhalten, obwohl einige Probleme natürlich nicht offengelegt werden können, ich werde versuchen, sie in den folgenden Artikeln zu behandeln.
Wir verwenden es seit mehreren Jahren, wir haben mit Version 4.1 begonnen. Unser Industriesystem basiert jetzt auf HPE Synergy 480- und ProLiant BL460c-Rechnern der 10. Generation mit Xeon Gold-CPUs.
Zum Zeitpunkt des Schreibens ist die aktuelle Version 4.3.
Artikel
- Einführung (Wir sind hier)
Funktionelle Merkmale
Es gibt zwei Haupteinheiten in oVirt: ovirt-engine und ovirt-host(s). Für diejenigen, die mit VMware-Produkten vertraut sind: oVirt als Ganzes als Plattform ist vSphere, ovirt-engine – die Kontrollschicht – führt die gleichen Funktionen wie vCenter aus und ovirt-host ist ein Hypervisor wie ESX (i). Weil vSphere ist eine sehr beliebte Lösung, manchmal vergleiche ich sie damit.
Reis. 1 - oVirt-Bedienfeld.
Die meisten Linux-Distributionen und Windows-Versionen werden als Gastmaschinen unterstützt. Für Gastmaschinen gibt es Agenten und optimierte virtuelle Geräte und Virtio-Treiber, hauptsächlich einen Festplattencontroller und eine Netzwerkschnittstelle.
Um eine fehlertolerante Lösung und alle interessanten Funktionen zu implementieren, benötigen Sie gemeinsam genutzten Speicher. Unterstützt werden sowohl Block-FC-, FCoE-, iSCSI- als auch Datei-NFS-Speicher usw. Um eine fehlertolerante Lösung zu implementieren, muss auch das Speichersystem fehlertolerant sein (mindestens 2 Controller, Multipassing).
Die Nutzung lokaler Speicher ist möglich, für einen echten Cluster eignen sich jedoch standardmäßig nur Shared Storages. Lokale Speicher machen das System zu einem heterogenen Satz von Hypervisoren, und selbst mit gemeinsam genutztem Speicher kann kein Cluster zusammengestellt werden. Der korrekteste Weg sind plattenlose Maschinen mit Start über SAN oder Festplatten mit der Mindestgröße. Wahrscheinlich ist es über den vdsm-Hook möglich, aus lokalen Festplatten von Software Defined Storage (z. B. Ceph) zu erstellen und seine VM zu präsentieren, aber ich habe nicht ernsthaft darüber nachgedacht.
Architektur
Reis. 2 - oVirt-Architektur.
Weitere Informationen zur Architektur finden Sie in Entwickler.
Reis. 3 – oVirt-Objekte.
Das oberste Element in der Hierarchie − Data Center. Es bestimmt, ob gemeinsamer oder lokaler Speicher verwendet wird, sowie den verwendeten Funktionsumfang (Kompatibilität, 4.1 bis 4.3). Es kann einen oder mehrere geben. Bei vielen Optionen ist die Verwendung des Standard-Rechenzentrums Standard.
Das Rechenzentrum besteht aus einem oder mehreren Cluster. Der Cluster bestimmt den Prozessortyp, Migrationsrichtlinien usw. Bei kleinen Installationen können Sie sich auch auf den Standardcluster beschränken.
Der Cluster wiederum besteht aus Gastgeber, die die Hauptarbeit erledigen – sie transportieren virtuelle Maschinen, Speicher sind mit ihnen verbunden. Der Cluster geht von 2 oder mehr Hosts aus. Obwohl es technisch möglich ist, einen Cluster mit einem Host zu bilden, ist dies nicht von praktischem Nutzen.
oVirt unterstützt viele Funktionen, inkl. Live-Migration virtueller Maschinen zwischen Hypervisoren (Live-Migration) und Speichern (Storage-Migration), Desktop-Virtualisierung (virtuelle Desktop-Infrastruktur) mit VM-Pools, Statefull- und Stateless-VMs, Unterstützung für NVidia Grid vGPU, Import aus vSphere, KVM, es gibt eine leistungsstarke und vieles mehr. Alle diese Funktionen sind lizenzgebührenfrei verfügbar und bei Bedarf kann Support über regionale Partner von Red Hat erworben werden.
Über RHV-Preise
Die Kosten sind im Vergleich zu VMware nicht hoch, es wird nur der Support erworben – ohne dass die Lizenz selbst erworben werden muss. Der Support wird nur für Hypervisoren erworben, für die Ovirt-Engine sind im Gegensatz zu vCenter Server keine Ausgaben erforderlich.
Berechnungsbeispiel für das 1. Besitzjahr
Betrachten Sie eine Gruppe von 4 2-Sockel-Maschinen und Einzelhandelspreisen (keine Projektrabatte).
RHV-Standardabonnement pro Steckdose/Jahr (Premium 365/24/7 – 1499 $), insgesamt 4*2*999=$7992.
:
- VMware vCenter Server Standard 10,837.13 $ pro Instanz plus Basisabonnement 2,625.41 $ (Produktion 3,125.39 $);
- VMware vSphere Standard 1,164.15 $ + Basisabonnement 552.61 $ (Produktion 653.82 $);
- VMware vSphere Enterprise Plus 6,309.23 $ + Basisabonnement 1,261.09 $ (Produktion 1,499.94 $).
Gesamt: 10 + 837,13 + 2 * 625,41 * (4 + 2) = $ 27 196,62 für die kleinste Option. Der Unterschied beträgt etwa das 3,5-fache!
In oVirt stehen alle Funktionen uneingeschränkt zur Verfügung.
Kurzcharakteristik und Maxima
Systemanforderungen
Der Hypervisor erfordert eine CPU mit aktivierter Hardwarevirtualisierung, die Mindestmenge an RAM zum Starten beträgt 2 GiB, die empfohlene Speichermenge für das Betriebssystem beträgt 55 GiB (hauptsächlich für Protokolle usw., das Betriebssystem selbst nimmt wenig ein).
Mehr Details - .
für Mindestanforderungen 2 Kerne/4 GiB RAM/25 GiB Speicher. Empfohlen – ab 4 Kernen / 16 GiB RAM / 50 GiB Speicher.
Wie bei jedem System gibt es Beschränkungen hinsichtlich der Volumina und Mengen, von denen die meisten die Kapazitäten verfügbarer kommerzieller Massenserver übersteigen. Ja, ein paar. kann 2 TiB RAM adressieren und ergibt 40 Kerne (80 Threads), was sogar weniger als die Grenzen einer VM ist.
Maximalwerte für virtuelle Maschinen:
- Maximale Anzahl gleichzeitig laufender virtueller Maschinen: Unbegrenzt;
- Maximale virtuelle CPUs pro virtueller Maschine: 384;
- Maximaler Speicher pro virtueller Maschine: 4 TiB;
- Maximale Einzelplattengröße pro virtueller Maschine: 8 TiB.
Host-Maximalwerte:
- Logische CPU-Kerne oder Threads: 768;
- RAM: 12 TiB
- Anzahl gehosteter virtueller Maschinen: 250;
- Gleichzeitige Live-Migrationen: 2 eingehende, 2 ausgehende;
- Live-Migrationsbandbreite: Standardmäßig 52 MiB (~436 MB) pro Migration, wenn die alte Migrationsrichtlinie verwendet wird. Andere Richtlinien verwenden adaptive Durchsatzwerte basierend auf der Geschwindigkeit des physischen Geräts. QoS-Richtlinien können die Migrationsbandbreite einschränken.
Maximalwerte für logische Manager-Entitäten:
In 4.3 gibt es .
- Rechenzentrum
- Maximale Anzahl Rechenzentren: 400;
- Maximale Hostanzahl: 400 unterstützt, 500 getestet;
- Maximale VM-Anzahl: 4000 unterstützt, 5000 getestet;
- Cluster
- Maximale Clusteranzahl: 400;
- Maximale Hostanzahl: 400 unterstützt, 500 getestet;
- Maximale VM-Anzahl: 4000 unterstützt, 5000 getestet;
- Netzwerk
- Logische Netzwerke/Cluster: 300
- SDN/externe Netzwerke: 2600 getestet, kein erzwungenes Limit;
- Lagerung
- Maximale Domänen: 50 unterstützt, 70 getestet;
- Hosts pro Domain: Keine Begrenzung;
- Logische Volumes pro Blockdomäne (mehr): 1500;
- Maximale Anzahl LUNs (mehr): 300;
- Maximale Festplattengröße: 500 TiB (standardmäßig auf 8 TiB begrenzt).
Umsetzungsmöglichkeiten
Wie bereits erwähnt, besteht oVirt aus zwei Grundelementen: ovirt-engine (Verwaltung) und ovirt-host (Hypervisor).
Die Engine kann sowohl außerhalb der Plattform selbst gehostet werden (eigenständiger Manager – es kann eine VM sein, die auf einer anderen Plattform oder einem separaten Hypervisor läuft, und sogar eine physische Maschine) als auch auf der Plattform selbst (selbst gehostete Engine, ähnlich dem VCSA-Ansatz von VMware).
Der Hypervisor kann installiert werden (EL-Host) und (oVirt-Node, basierend auf el7).
Die Hardwareanforderungen sind für alle Varianten ungefähr gleich.
Reis. 4 - Standardarchitektur.
Reis. 5 – Selbstgehostete Engine-Architektur.
Für mich selbst habe ich die Option „Standalone-Manager und EL-Hosts“ gewählt:
- Der eigenständige Manager ist bei Startproblemen etwas einfacher, es gibt kein Henne-Ei-Dilemma (wie bei VCSA – Sie starten erst, wenn mindestens ein Host vollständig hochgefahren ist), aber es besteht eine Abhängigkeit von einem anderen System *;
- EL Host bietet die volle Leistung des Betriebssystems, was für externe Überwachung, Fehlerbehebung, Fehlerbehebung und mehr nützlich ist.
* Dies war jedoch nicht während der gesamten Betriebszeit erforderlich, auch nicht nach einem schwerwiegenden Stromausfall.
Aber mehr auf den Punkt!
Zum Experimentieren ist es möglich, ein Paar ProLiant BL460c G7-Blades mit Xeon®-CPU herauszubringen. Wir werden den Installationsprozess auf ihnen reproduzieren.
Benennen wir die Knoten ovirt.lab.example.com, kvm01.lab.example.com und kvm02.lab.example.com.
Gehen wir direkt zu .
Source: habr.com