Einführung
Open-Source-Projekt — eine kostenlose Enterprise-Virtualisierungsplattform. Während ich auf Habr durchforstet habe, stellte ich fest, dass es hier nicht so umfassend behandelt wird, wie es verdient.
oVirt ist tatsächlich das upstream für das kommerzielle System Red Hat Virtualization (RHV, früher RHEV) und wächst unter dem Fittichen von Red Hat. Um Verwirrung zu vermeiden, ist das nicht das gleiche wie CentOS vs. RHEL, das Modell ist näher an Fedora vs. RHEL.
Unter der Haube — , используется ein Web-Interface zur Verwaltung. Es basiert auf dem Betriebssystem RHEL/CentOS 7.
oVirt kann sowohl für „traditionelle“ Server- als auch Desktop-Virtualisierung (VDI) verwendet werden, im Gegensatz zur VMware-Lösung können beide Systeme in einem Komplex koexistieren.
Das Projekt ist gut , hat seit langem den Reifegrad für produktive Anwendungen erreicht und ist bereit für hohe Lasten.
Dieser Artikel ist der erste in einer Reihe darüber, wie man einen funktionierenden ausfallsicheren Cluster aufbaut. Durch das Durchlaufen wird in kurzer Zeit (etwa 2 Stunden) ein vollständig funktionsfähiges System bereitgestellt, obwohl natürlich nicht alle Fragen umfassend behandelt werden können. Ich werde versuchen, sie in den folgenden Artikeln zu beleuchten.
Wir verwenden es seit mehreren Jahren, beginnend mit Version 4.1. Unser industrielles System läuft jetzt auf HPE Synergy 480 und ProLiant BL460c der 10. Generation mit Xeon Gold CPU.
Zum Zeitpunkt des Schreibens ist die aktuelle Version 4.3.
Artikel
- Einführung (Wir sind hier)
Funktionale Merkmale
In oVirt gibt es zwei Hauptbestandteile: ovirt-engine und ovirt-host(s). Für diejenigen, die mit den Produkten von VMware gut vertraut sind, ist oVirt insgesamt als Plattform das vSphere-System, wobei ovirt-engine die Management-Schicht ist, die dieselben Funktionen wie vCenter ausführt, während ovirt-host der Hypervisor, ähnlich wie ESX(i), ist. Da vSphere eine sehr beliebte Lösung ist, werde ich manchmal Vergleiche dazu anstellen.
Abb. 1 — oVirt-Dashboard.
Die meisten Linux-Distributive und Windows-Versionen werden als Gastmaschinen unterstützt. Für Gastmaschinen gibt es Agenten sowie optimierte virtuelle Geräte und Treiber virtio, insbesondere für den Festplattencontroller und die Netzwerkschnittstelle.
Für die Implementierung einer ausfallsicheren Lösung und aller interessanten Funktionen ist ein gemeinsamer Speicher erforderlich. Es werden sowohl blockbasierte FC, FCoE, iSCSI als auch dateibasierte NFS-Speicher unterstützt. Damit die ausfallsichere Lösung funktioniert, muss auch das Speichersystem ausfallsicher sein (mindestens 2 Controller, Multihoming).
Die Verwendung lokaler Speicher ist möglich, aber für einen echten Cluster sind standardmäßig nur gemeinsame Speicher (shared storages) geeignet. Lokale Speicher machen das System zu einer unverbundenen Sammlung von Hypervisoren, und selbst mit vorhandenem gemeinsamem Speicher kann ein Cluster nicht erstellt werden. Der beste Weg ist der Einsatz von diskless Maschinen mit Boot von SAN oder Platten mit minimalem Volumen. Wahrscheinlich besteht durch einen vdsm-Hook die Möglichkeit, lokale Festplatten in Software Defined Storage (z.B. Ceph) zu integrieren und es den VMs bereitzustellen, aber ich habe das nicht ernsthaft betrachtet.
Architektur von
Abb. 2 — Architektur von oVirt.
Weitere Informationen zur Architektur finden Sie in der Entwicklerdokumentation.
Abb. 3 — Objekte von oVirt.
Das oberste Element in der Hierarchie — Rechenzentrum. Es definiert, ob Shared- oder lokale Speicher verwendet werden, sowie die verwendete Funktionalität (Kompatibilität, von 4.1 bis 4.3). Es kann einen oder mehrere geben. Für viele Varianten ist die Verwendung des Standard-Data Centers - Default - geeignet.
Das Data Center besteht aus einem oder mehreren Clustern. Ein Cluster definiert den Typ des Prozessors, die Migrationsrichtlinien usw. Für kleinere Installationen kann man sich auch mit dem Standard-Cluster begnügen.
Ein Cluster besteht seinerseits aus HostHosts, die die Hauptarbeit leisten - sie tragen die virtuellen Maschinen, die mit den Speichern verbunden sind. In einem Cluster sind 2 oder mehr Hosts vorgesehen. Technisch ist es zwar möglich, ein Cluster mit einem Host zu erstellen, hat aber praktisch keinen Nutzen.
oVirt unterstützt viele Funktionen, einschließlich der Live-Migration von virtuellen Maschinen zwischen Hypervisoren (live migration) und Speichern (storage migration), Desktop-Virtualisierung (virtual desktop infrastructure) mit VM-Pools, stateful und stateless VMs, NVidia Grid vGPU-Unterstützung, Import aus vSphere, KVM und vieles mehr. All diese Funktionen sind ohne Lizenzgebühren verfügbar, und bei Bedarf kann Unterstützung über Red Hat bei regionalen Partnern erworben werden.
Preise für RHV
Die Kosten sind im Vergleich zu VMware gering, es wird nur Support erworben — ohne Kauf der Lizenz selbst. Support wird nur für Hypervisoren und ovirt-engine erworben, im Gegensatz zum vCenter Server, das keine Ausgaben erfordert.
Beispiel für die Berechnung im ersten Jahr des Besitzes
Betrachten wir einen Cluster aus 4 Maschinen mit 2 Sockeln und Einzelhandelspreisen (ohne ProjektRabatte).
Standard-Abonnement RHV pro Sockel/Jahr (Premium 365/24/7 — $1499), insgesamt 4*2*$999=$7992.
:
- VMware vCenter Server Standard $10,837.13 pro Exemplar, plus Basic-Abonnement $2,625.41 (Produktion — $3,125.39);
- VMware vSphere Standard $1,164.15 + Basic-Abonnement $552.61 (Produktion $653.82);
- VMware vSphere Enterprise Plus $6,309.23 + Basic-Abonnement $1,261.09 (Produktion $1,499.94).
Insgesamt: 10,837.13 + 2,625.41 + 4 * 2 * (1,164.15 + 552.61) = $27 196,62 für die einfachste Variante. Der Unterschied beträgt etwa das 3,5-fache!
In oVirt sind jedoch alle Funktionen ohne Einschränkungen verfügbar.
Kurze Spezifikationen und Höchstwerte
Systemanforderungen
Für den Hypervisor ist eine CPU mit aktivierter Hardware-Virtualisierung erforderlich, der minimale RAM für den Start beträgt 2 GiB, der empfohlene Speicherplatz für das Betriebssystem liegt bei 55 GiB (hauptsächlich für Protokolle usw., das Betriebssystem benötigt wenig Platz).
Mehr dazu — .
Für minimale Anforderungen 2 Kerne/4 GiB RAM/25 GiB Speicher. Empfohlen sind mindestens 4 Kerne/16 GiB RAM/50 GiB Speicher.
Wie in jedem System gibt es Einschränkungen hinsichtlich der Volumen und Mengen, von denen die meisten die Möglichkeiten der verfügbaren massenkommerzielle Server übersteigen. So kann eine Kombination aus kann 2 TiB RAM adressieren und bietet 40 Kerne (80 Threads), was sogar unter denLimits einer einzigen VM liegt.
Maximale Werte für virtuelle Maschinen:
- Maximale gleichzeitig laufende virtuelle Maschinen: Unbegrenzt;
- Maximale virtuelle CPUs pro virtueller Maschine: 384;
- Maximaler Speicher pro virtueller Maschine: 4 TiB;
- Maximale Einzelgerätgröße pro virtueller Maschine: 8 TiB.
Maximale Werte für Hosts:
- Logische CPU-Kerne oder Threads: 768;
- RAM: 12 TiB;
- Anzahl der gehosteten virtuellen Maschinen: 250;
- Gleichzeitige Live-Migrationen: 2 eingehend, 2 ausgehend;
- Live-Migrationsbandbreite: Standardmäßig 52 MiB (~436 Mb) pro Migration bei Verwendung der alten Migrationsrichtlinie. Andere Richtlinien verwenden adaptive Durchsatzwerte basierend auf der Geschwindigkeit des physischen Geräts. QoS-Richtlinien können die Migrationsbandbreite einschränken.
Maximale Werte für logische Einheiten des Managers:
In 4.3 gibt es .
- Rechenzentrum
- Maximale Anzahl an Rechenzentren: 400;
- Maximale Anzahl an Hosts: 400 unterstützt, 500 getestet;
- Maximale VM-Zahl: 4000 unterstützt, 5000 getestet;
- Cluster
- Maximale Clusteranzahl: 400;
- Maximale Anzahl an Hosts: 400 unterstützt, 500 getestet;
- Maximale VM-Zahl: 4000 unterstützt, 5000 getestet;
- Netzwerk
- Logische Netzwerke/Cluster: 300;
- SDN/externe Netzwerke: 2600 getestet, kein erzwungenes Limit;
- Speicher
- Maximale Domains: 50 unterstützt, 70 getestet;
- Hosts pro Domain: Keine Begrenzung;
- Logische Volumes pro Blockdomain (mehr): 1500;
- Maximale Anzahl der LUNs (mehr): 300;
- Maximale Festplattengröße: 500 TiB (standardmäßig auf 8 TiB limitiert).
Implementierungsoptionen
Wie bereits erwähnt, besteht oVirt aus zwei grundlegenden Komponenten — ovirt-engine (Verwaltung) und ovirt-host (Hypervisor).
Die Engine kann sowohl außerhalb der Plattform (Standalone-Manager — dies kann eine VM sein, die auf einer anderen Plattform oder einem separaten Hypervisor bzw. sogar auf einer physischen Maschine läuft), als auch auf der Plattform selbst (Self-hosted Engine, ähnlich dem VCSA-Ansatz von VMware) gehostet werden.
Der Hypervisor kann sowohl auf (EL-Host) als auch auf (oVirt-Node, basiert auf el7) installiert werden.
Die Hardwareanforderungen sind für alle Varianten etwa gleich.
Abb. 4 — Standardarchitektur.
Abb. 5 — Architektur des Self-hosted Engine.
Ich habe mich für die Variante Standalone-Manager und EL Hosts entschieden:
- Standalone-Manager ist etwas einfacher bei Startproblemen, es gibt kein Henne-und-Ei-Dilemma (genauso wie bei VCSA — man kann nicht starten, solange nicht mindestens ein Host vollständig hochgefahren ist), aber es entsteht eine Abhängigkeit von einem anderen System*;
- EL Host bietet die gesamte Leistung des Betriebssystems, was nützlich für externes Monitoring, Debugging, Fehlersuche usw. ist.
* Allerdings war dies in der gesamten Betriebszeit nicht erforderlich, selbst nach einem schwerwiegenden Stromausfall.
Aber jetzt zum Wesentlichen!
Für das Experiment haben wir die Möglichkeit, ein paar ProLiant BL460c G7 mit Xeon® CPU freizugeben. Auf ihnen werden wir den Installationsprozess reproduzieren.
Wir vergeben die Namen ovirt.lab.example.com, kvm01.lab.example.com und kvm02.lab.example.com.
Kommen wir direkt zu .
Quelle: habr.com
