{"id":82495,"date":"2020-05-22T01:42:27","date_gmt":"2020-05-21T23:42:27","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/ovirt-za-2-chasa-chast-1-otkrytaya-otkazoustojchivaya-platforma-virtualizaczii"},"modified":"2020-05-22T01:42:27","modified_gmt":"2020-05-21T23:42:27","slug":"ovirt-za-2-chasa-chast-1-otkrytaya-otkazoustojchivaya-platforma-virtualizaczii","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/ovirt-za-2-chasa-chast-1-otkrytaya-otkazoustojchivaya-platforma-virtualizaczii","title":{"rendered":"oVirt in 2 Stunden. Teil 1. Offene, ausfallsichere Virtualisierungsplattform","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Einf\u00fchrung<\/h2>\n

\nOpen-Source-Projekt oVirt<\/a><\/noindex> \u2014 eine kostenlose Enterprise-Virtualisierungsplattform. W\u00e4hrend ich auf Habr durchforstet habe, stellte ich fest, dass oVirt<\/a><\/noindex> es hier nicht so umfassend behandelt wird, wie es verdient.
\noVirt ist tats\u00e4chlich das upstream f\u00fcr das kommerzielle System Red Hat Virtualization (RHV, fr\u00fcher RHEV) und w\u00e4chst unter dem Fittichen von Red Hat. Um Verwirrung zu vermeiden, ist das nicht<\/b> das gleiche wie CentOS vs. RHEL, das Modell ist n\u00e4her an Fedora vs. RHEL.
\nUnter der Haube \u2014 KVM<\/a><\/noindex>, \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u0443\u0435\u0442\u0441\u044f ein Web-Interface zur Verwaltung. Es basiert auf dem Betriebssystem RHEL\/CentOS 7.
\noVirt kann sowohl f\u00fcr \u201etraditionelle\u201c Server- als auch Desktop-Virtualisierung (VDI) verwendet werden, im Gegensatz zur VMware-L\u00f6sung k\u00f6nnen beide Systeme in einem Komplex koexistieren.
\nDas Projekt ist gut dokumentiert<\/a><\/noindex>, hat seit langem den Reifegrad f\u00fcr produktive Anwendungen erreicht und ist bereit f\u00fcr hohe Lasten.
\nDieser Artikel ist der erste in einer Reihe dar\u00fcber, wie man einen funktionierenden ausfallsicheren Cluster aufbaut. Durch das Durchlaufen wird in kurzer Zeit (etwa 2 Stunden) ein vollst\u00e4ndig funktionsf\u00e4higes System bereitgestellt, obwohl nat\u00fcrlich nicht alle Fragen umfassend behandelt werden k\u00f6nnen. Ich werde versuchen, sie in den folgenden Artikeln zu beleuchten.<\/a><\/noindex>
\nWir verwenden es seit mehreren Jahren, beginnend mit Version 4.1. Unser industrielles System l\u00e4uft jetzt auf HPE Synergy 480 und ProLiant BL460c der 10. Generation mit Xeon Gold CPU.
\nZum Zeitpunkt des Schreibens ist die aktuelle Version 4.3. <\/p>\n

Artikel<\/h2>\n

<\/p>\n

    \n
  1. Einf\u00fchrung (Wir sind hier)<\/li>\n
  2. Installation des Managers (ovirt-engine) und der Hypervisoren (Hosts)<\/a><\/noindex><\/li>\n
  3. Zus\u00e4tzliche Einstellungen<\/a><\/noindex><\/li>\n<\/ol>\n

    Funktionale Merkmale<\/h2>\n

    \nIn oVirt gibt es zwei Hauptbestandteile: ovirt-engine und ovirt-host(s). F\u00fcr 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\u00fchrt, w\u00e4hrend ovirt-host der Hypervisor, \u00e4hnlich wie ESX(i), ist. Da vSphere eine sehr beliebte L\u00f6sung ist, werde ich manchmal Vergleiche dazu anstellen.
    \n\"oVirt
    \nAbb. 1 \u2014 oVirt-Dashboard.<\/p>\n

    Die meisten Linux-Distributive und Windows-Versionen werden als Gastmaschinen unterst\u00fctzt. F\u00fcr Gastmaschinen gibt es Agenten sowie optimierte virtuelle Ger\u00e4te und Treiber virtio, insbesondere f\u00fcr den Festplattencontroller und die Netzwerkschnittstelle.
    \nF\u00fcr die Implementierung einer ausfallsicheren L\u00f6sung und aller interessanten Funktionen ist ein gemeinsamer Speicher erforderlich. Es werden sowohl blockbasierte FC, FCoE, iSCSI als auch dateibasierte NFS-Speicher unterst\u00fctzt. Damit die ausfallsichere L\u00f6sung funktioniert, muss auch das Speichersystem ausfallsicher sein (mindestens 2 Controller, Multihoming).
    \nDie Verwendung lokaler Speicher ist m\u00f6glich, aber f\u00fcr einen echten Cluster sind standardm\u00e4\u00dfig 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\u00f6glichkeit, lokale Festplatten in Software Defined Storage (z.B. Ceph) zu integrieren und es den VMs bereitzustellen, aber ich habe das nicht ernsthaft betrachtet.<\/p>\n

    Architektur von<\/h4>\n

    \n\"oVirt
    \nAbb. 2 \u2014 Architektur von oVirt.
    \nWeitere Informationen zur Architektur finden Sie in     Dokumentation.<\/a><\/noindex> der Entwicklerdokumentation.<\/p>\n

    \"oVirt
    \nAbb. 3 \u2014 Objekte von oVirt.<\/p>\n

    Das oberste Element in der Hierarchie \u2014 Rechenzentrum<\/b>. Es definiert, ob Shared- oder lokale Speicher verwendet werden, sowie die verwendete Funktionalit\u00e4t (Kompatibilit\u00e4t, von 4.1 bis 4.3). Es kann einen oder mehrere geben. F\u00fcr viele Varianten ist die Verwendung des Standard-Data Centers - Default - geeignet.
    \nDas Data Center besteht aus einem oder mehreren Clustern<\/b>. Ein Cluster definiert den Typ des Prozessors, die Migrationsrichtlinien usw. F\u00fcr kleinere Installationen kann man sich auch mit dem Standard-Cluster begn\u00fcgen.
    \nEin Cluster besteht seinerseits aus Host<\/b>‘\u043e\u0432, \u0432\u044b\u043f\u043e\u043b\u043d\u044f\u044e\u0449\u0438\u0445 \u043e\u0441\u043d\u043e\u0432\u043d\u0443\u044e \u0440\u0430\u0431\u043e\u0442\u0443 \u2014 \u043e\u043d\u0438 \u043d\u0435\u0441\u0443\u0442 \u0432\u0438\u0440\u0442\u0443\u0430\u043b\u044c\u043d\u044b\u0435 \u043c\u0430\u0448\u0438\u043d\u044b, \u043a \u043d\u0438\u043c \u043f\u043e\u0434\u043a\u043b\u044e\u0447\u0435\u043d\u044b \u0445\u0440\u0430\u043d\u0438\u043b\u0438\u0449\u0430. \u0412 \u043a\u043b\u0430\u0441\u0442\u0435\u0440\u0435 \u043f\u0440\u0435\u0434\u043f\u043e\u043b\u0430\u0433\u0430\u0435\u0442\u0441\u044f 2 \u0438\u043b\u0438 \u0431\u043e\u043b\u0435\u0435 \u0445\u043e\u0441\u0442\u043e\u0432. \u0425\u043e\u0442\u044f \u0442\u0435\u0445\u043d\u0438\u0447\u0435\u0441\u043a\u0438 \u0432\u043e\u0437\u043c\u043e\u0436\u043d\u043e \u0441\u0434\u0435\u043b\u0430\u0442\u044c \u043a\u043b\u0430\u0441\u0442\u0435\u0440 \u0441 1-\u043c \u0445\u043e\u0441\u0442\u043e\u043c, \u043d\u043e \u044d\u0442\u043e \u043d\u0435 \u0438\u043c\u0435\u0435\u0442 \u043f\u0440\u0430\u043a\u0442\u0438\u0447\u0435\u0441\u043a\u043e\u0439 \u043f\u043e\u043b\u044c\u0437\u044b.<\/p>\n

    oVirt unterst\u00fctzt viele Funktionen, einschlie\u00dflich 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\u00fctzung, Import aus vSphere, KVM und vieles mehr. API<\/a><\/noindex> All diese Funktionen sind ohne Lizenzgeb\u00fchren verf\u00fcgbar, und bei Bedarf kann Unterst\u00fctzung \u00fcber Red Hat bei regionalen Partnern erworben werden.<\/p>\n

    Preise f\u00fcr RHV<\/h4>\n

    \nDie Kosten sind im Vergleich zu VMware gering, es wird nur Support erworben \u2014 ohne Kauf der Lizenz selbst. Support wird nur f\u00fcr Hypervisoren und ovirt-engine erworben, im Gegensatz zum vCenter Server, das keine Ausgaben erfordert.<\/p>\n

    Beispiel f\u00fcr die Berechnung im ersten Jahr des Besitzes<\/h4>\n

    \nBetrachten wir einen Cluster aus 4 Maschinen mit 2 Sockeln und Einzelhandelspreisen (ohne ProjektRabatte).
    \nStandard-Abonnement RHV     kostet $999<\/a><\/noindex> pro Sockel\/Jahr (Premium 365\/24\/7 \u2014 $1499), insgesamt 4*2*$999=$7992<\/b>.
    \n    Preis f\u00fcr vSphere<\/a><\/noindex>:<\/p>\n