oVirt in 2 Stunden. Teil 1. Offene ausfallsichere Virtualisierungsplattform.

Einführung

Open-Source-Projekt oVirt — eine freie Virtualisierungsplattform auf Unternehmensniveau. Beim Durchsehen von Habr habe ich festgestellt, dass oVirt es hier nicht so umfassend behandelt wird, wie es verdient.
oVirt ist faktisch das Upstream-Projekt für das kommerzielle System Red Hat Virtualization (RHV, früher RHEV), das unter dem Schutz von Red Hat wächst. 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 — KVM, wird ein Web-Interface zur Verwaltung verwendet. Es basiert auf RHEL/CentOS 7.
oVirt kann sowohl für „traditionelle“ Server- als auch Desktop-Virtualisierung (VDI) verwendet werden; im Gegensatz zur Lösung von VMware können beide Systeme in einem Komplex koexistieren.
Das Projekt ist gut dokumentiert, hat seit Langem seine Reife für den produktiven Einsatz erreicht und ist bereit für hohe Lasten.
Dieser Artikel ist der erste in einer Reihe darüber, wie man einen funktionsfähigen Hochverfügbarkeitscluster aufbaut. Indem wir sie durchgehen, werden wir in kurzer Zeit (etwa 2 Stunden) ein voll funktionsfähiges System erhalten, auch wenn einige Fragen natürlich nicht behandelt werden können; ich werde versuchen, diese in zukünftigen Artikeln zu beleuchten.
Wir verwenden es seit mehreren Jahren, angefangen bei 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

1. Einführung (Wir sind hier)
2. Installation des Managers (ovirt-engine) und der Hypervisoren (Hosts)
3. Zusätzliche Einstellungen

Funktionale Merkmale

In oVirt gibt es zwei Hauptbestandteile: ovirt-engine und ovirt-host(s). Für diejenigen, die mit den Produkten von VMware vertraut sind, ist oVirt insgesamt eine Plattform wie vSphere; ovirt-engine — die Steuerungsebene — erfüllt die gleichen Funktionen wie vCenter, und ovirt-host — der Hypervisor, wie ESX(i). Da vSphere eine sehr beliebte Lösung ist, werde ich gelegentlich Vergleiche zu ihr anstellen.

Abb. 1 — das Dashboard von oVirt.

Als Gastmaschinen werden die meisten Linux-Distributionen und Windows-Versionen unterstützt. Für Gastmaschinen gibt es Agents, optimierte virtuelle Geräte und virtio-Treiber, in erster Linie für den Festplattencontroller und die Netzwerkschnittstelle.
Um eine hochverfügbare Lösung und alle interessanten Funktionen zu realisieren, wird ein Shared Storage benötigt. Unterstützt werden sowohl Block-Storage wie FC, FCoE, iSCSI, als auch Datei-Storage wie NFS und andere. Um eine hochverfügbare Lösung zu realisieren, muss das Storage-System ebenfalls hochverfügbar sein (mindestens 2 Controller, Multipathing).
Die Nutzung von lokalen Speichern ist möglich, jedoch sind für einen echten Cluster standardmäßig nur Shared Storages geeignet. Lokale Speicher machen das System zu einer uneinheitlichen Gruppe von Hypervisoren, und selbst mit einem Shared Storage lässt sich der Cluster nicht aufbauen. Der sinnvollste Weg sind disklose Maschinen mit Boot von SAN oder Festplatten mit minimaler Kapazität. Wahrscheinlich ist über vdsm Hook eine Konfiguration mit lokalen Festplatten für Software Defined Storage (z.B. Ceph) und deren Präsentation als VM möglich, jedoch habe ich dies nicht ernsthaft in Betracht gezogen.

Architektur

Abb. 2 — Architektur von oVirt.
Detailinformationen zur Architektur sind erhältlich bei Dokumentation dem Entwickler.

Abb. 3 — Objekte von oVirt.

Das oberste Element in der Hierarchie — Rechenzentrum. Es bestimmt, ob Shared oder lokale Speicher verwendet werden und welche Funktionen (Kompatibilität, von 4.1 bis 4.3) zur Verfügung stehen. Es kann ein einzelnes oder mehrere Rechenzentren geben. Für viele Anwendungsmöglichkeiten ist die Verwendung des Standard-Rechenzentrums – Default – ausreichend.
Ein Rechenzentrum besteht aus einem oder mehreren Clusters. Ein Cluster definiert den Prozessor-Typ, Migrationsrichtlinien usw. Für kleine Installationen kann man auch mit dem Cluster Default auskommen.
Ein Cluster besteht seinerseits aus HostHosts, die die Hauptarbeit verrichten — sie tragen die virtuellen Maschinen und sind mit Speicher verbunden. In einem Cluster sind 2 oder mehr Hosts vorgesehen. Obwohl es technisch möglich ist, einen Cluster mit nur 1 Host zu erstellen, hat dies keinen praktischen Nutzen.

oVirt unterstützt viele Funktionen, einschließlich Live-Migration von virtuellen Maschinen zwischen Hypervisoren (Live-Migration) und Speichern (Speichermigration), Desktop-Virtualisierung (Virtual Desktop Infrastructure) mit VM-Pools, stateful und stateless VMs, Unterstützung für NVidia Grid vGPU, 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 über regionale Partner erworben werden. API Die Preise für RHV

sind im Vergleich zu VMware recht niedrig, es wird lediglich Unterstützung erworben — ohne die Verpflichtung, eine Lizenz zu kaufen. Unterstützung wird nur für die Hypervisoren und ovirt-engine erworben, im Gegensatz zum vCenter Server sind keine weiteren Ausgaben erforderlich.

Beispielrechnung für das erste Jahr des Besitzes

Betrachten wir einen Cluster aus 4 Maschinen mit 2 Sockeln und Einzelhandelspreisen (ohne Projekt-Rabatte).

Das Standard-Abonnement für RHV
kostet 999 $ pro Sockel/Jahr (Premium 365/24/7 — 1499 $), insgesamt 4*2*999= Preis von vSphere$7992.
Preis von vSphere:

• VMware vCenter Server Standard 10.837,13 $ pro Instanz, plus Basis-Abonnement 2.625,41 $ (Produktion — 3.125,39 $);
• VMware vSphere Standard 1.164,15 $ + Basis-Abonnement 552,61 $ (Produktion 653,82 $);
• VMware vSphere Enterprise Plus 6.309,23 $ + Basis-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 basiste Variante. Der Unterschied beträgt etwa das 3,5-fache!
In oVirt sind jedoch alle Funktionen ohne Einschränkungen verfügbar.

Kurze Spezifikationen und Maximalwerte

Systemanforderungen

Für den Hypervisor wird ein Prozessor mit aktivierter Hardwarevirtualisierung benötigt, der minimale RAM-Bedarf zum Start beträgt 2 GiB, der empfohlene Speicherplatz für das Betriebssystem liegt bei 55 GiB (hauptsächlich für Protokolle usw., das Betriebssystem selbst benötigt wenig).
Weitere Einzelheiten — hier.
Für Engine minimale Anforderungen 2 Kerne/4 GiB RAM/25 GiB Speicher. Empfohlen sind 4 Kerne/16 GiB RAM/50 GiB Speicher.
Wie in jedem System gibt es Einschränkungen hinsichtlich Größen und Mengen, von denen die meisten die Möglichkeiten verfügbarer massengeprüfter Server überschreiten. So kann ein Paar Intel Xeon Gold 6230 2 TiB RAM adressieren und bietet 40 Kerne (80 Threads), was sogar unter den Limits einer VM liegt.

Maximalwerte für virtuelle Maschinen:

• Maximale gleichzeitig ausgeführte virtuelle Maschinen: Unbegrenzt;
• Maximale virtuelle CPUs pro virtueller Maschine: 384;
• Maximaler Speicher pro virtueller Maschine: 4 TiB;
• Maximale einzelner Datenträgergröße pro virtueller Maschine: 8 TiB.

Maximalwerte 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-Migrations-Bandbreite: Standardmäßig 52 MiB (~436 Mb) pro Migration bei Verwendung der alten Migrationsrichtlinie. Andere Richtlinien verwenden adaptive Durchsatzwerte, die auf der Geschwindigkeit des physischen Geräts basieren. QoS-Richtlinien können die Migrationsbandbreite einschränken.

Maximalwerte für logische Manager-Entitäten:

In 4.3 gibt es die folgenden Limits.

• Rechenzentrum
  • Maximale Anzahl von Rechenzentren: 400;
  • Maximale Anzahl von Hosts: 400 unterstützt, 500 getestet;
  • Maximale Anzahl von VMs: 4000 unterstützt, 5000 getestet;
• Cluster
  • Maximale Anzahl von Clustern: 400;
  • Maximale Anzahl von Hosts: 400 unterstützt, 500 getestet;
  • Maximale Anzahl von VMs: 4000 unterstützt, 5000 getestet;
• Netzwerk
  • Logische Netzwerke/Cluster: 300;
  • SDN/externe Netzwerke: 2600 getestet, kein Durchsatzlimit;
• Speicher
  • Maximale Domains: 50 unterstützt, 70 getestet;
  • Hosts pro Domain: Keine Begrenzung;
  • Logische Volumes pro Blockdomain (mehr): 1500;
  • Maximale Anzahl von LUNs (mehr): 300;
  • Maximale Datenträgergröße: 500 TiB (standardmäßig auf 8 TiB begrenzt).

Implementierungsvarianten

Wie bereits erwähnt, besteht oVirt aus 2 grundlegenden Elementen — 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 und sogar auf einer physischen Maschine ausgeführt wird) als auch auf der Plattform selbst (Self-hosted Engine, ähnlich dem VCSA-Ansatz von VMware) gehostet werden.
Der Hypervisor kann entweder auf einem regulären Betriebssystem RHEL/CentOS 7 (EL Host) oder auf einem spezialisierten minimalen Betriebssystem (oVirt-Node, basiert auf el7) installiert werden.
Die Hardwareanforderungen sind für alle Varianten ungefähr gleich.

Abb. 4 — Standardarchitektur.

Abb. 5 – Architektur des selbstgehosteten Engines.

Ich habe mich für den Standalone-Manager und EL Hosts entschieden:

• Der Standalone-Manager ist bei Startproblemen etwas einfacher, da es kein Dilemma zwischen Huhn und Ei gibt (wie bei VCSA – man kann es nicht starten, solange nicht mindestens ein Host vollständig hochgefahren ist), aber es besteht eine Abhängigkeit von einem anderen System*;
• Der EL Host bietet die gesamte Leistungsfähigkeit des Betriebssystems, was für externes Monitoring, Debugging, Fehlersuche usw. nützlich ist.

* Allerdings war dies während der gesamten Betriebszeit nicht erforderlich, selbst nach einem schwerwiegenden Stromausfall.
Aber kommen wir nun zur Sache!
Für das Experiment besteht die Möglichkeit, ein paar ProLiant BL460c G7 mit Xeon® CPU freizugeben. Auf diesen werden wir den Installationsprozess durchführen.
Wir werden die Knoten ovirt.lab.example.com, kvm01.lab.example.com und kvm02.lab.example.com nennen.
Kommen wir direkt zu installieren.

Quelle: habr.com