{"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 freie Virtualisierungsplattform auf Unternehmensniveau. Beim Durchsehen von Habr habe ich festgestellt, dass oVirt<\/a><\/noindex> es hier nicht so umfassend behandelt wird, wie es verdient.
\noVirt ist faktisch das Upstream-Projekt f\u00fcr das kommerzielle System Red Hat Virtualization (RHV, fr\u00fcher RHEV), das unter dem Schutz von Red Hat w\u00e4chst. 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>, wird ein Web-Interface zur Verwaltung verwendet. Es basiert auf RHEL\/CentOS 7.
\noVirt kann sowohl f\u00fcr \u201etraditionelle\u201c Server- als auch Desktop-Virtualisierung (VDI) verwendet werden; im Gegensatz zur L\u00f6sung von VMware k\u00f6nnen beide Systeme in einem Komplex koexistieren.
\nDas Projekt ist gut dokumentiert<\/a><\/noindex>, hat seit Langem seine Reife f\u00fcr den produktiven Einsatz erreicht und ist bereit f\u00fcr hohe Lasten.
\nDieser Artikel ist der erste in einer Reihe dar\u00fcber, wie man einen funktionsf\u00e4higen Hochverf\u00fcgbarkeitscluster aufbaut. Indem wir sie durchgehen, werden wir in kurzer Zeit (etwa 2 Stunden) ein voll funktionsf\u00e4higes System erhalten, auch wenn einige Fragen nat\u00fcrlich nicht behandelt werden k\u00f6nnen; ich werde versuchen, diese in zuk\u00fcnftigen Artikeln zu beleuchten.<\/a><\/noindex>
\nWir verwenden es seit mehreren Jahren, angefangen bei 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 vertraut sind, ist oVirt insgesamt eine Plattform wie vSphere; ovirt-engine \u2014 die Steuerungsebene \u2014 erf\u00fcllt die gleichen Funktionen wie vCenter, und ovirt-host \u2014 der Hypervisor, wie ESX(i). Da vSphere eine sehr beliebte L\u00f6sung ist, werde ich gelegentlich Vergleiche zu ihr anstellen.
    \n\"oVirt
    \nAbb. 1 \u2014 das Dashboard von oVirt.<\/p>\n

    Als Gastmaschinen werden die meisten Linux-Distributionen und Windows-Versionen unterst\u00fctzt. F\u00fcr Gastmaschinen gibt es Agents, optimierte virtuelle Ger\u00e4te und virtio-Treiber, in erster Linie f\u00fcr den Festplattencontroller und die Netzwerkschnittstelle.
    \nUm eine hochverf\u00fcgbare L\u00f6sung und alle interessanten Funktionen zu realisieren, wird ein Shared Storage ben\u00f6tigt. Unterst\u00fctzt werden sowohl Block-Storage wie FC, FCoE, iSCSI, als auch Datei-Storage wie NFS und andere. Um eine hochverf\u00fcgbare L\u00f6sung zu realisieren, muss das Storage-System ebenfalls hochverf\u00fcgbar sein (mindestens 2 Controller, Multipathing).
    \nDie Nutzung von lokalen Speichern ist m\u00f6glich, jedoch sind f\u00fcr einen echten Cluster standardm\u00e4\u00dfig nur Shared Storages geeignet. Lokale Speicher machen das System zu einer uneinheitlichen Gruppe von Hypervisoren, und selbst mit einem Shared Storage l\u00e4sst sich der Cluster nicht aufbauen. Der sinnvollste Weg sind disklose Maschinen mit Boot von SAN oder Festplatten mit minimaler Kapazit\u00e4t. Wahrscheinlich ist \u00fcber vdsm Hook eine Konfiguration mit lokalen Festplatten f\u00fcr Software Defined Storage (z.B. Ceph) und deren Pr\u00e4sentation als VM m\u00f6glich, jedoch habe ich dies nicht ernsthaft in Betracht gezogen.<\/p>\n

    Architektur<\/h4>\n

    \n\"oVirt
    \nAbb. 2 \u2014 Architektur von oVirt.
    \nDetailinformationen zur Architektur sind erh\u00e4ltlich bei     Dokumentation<\/a><\/noindex> dem Entwickler.<\/p>\n

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

    Das oberste Element in der Hierarchie \u2014 Rechenzentrum<\/b>. Es bestimmt, ob Shared oder lokale Speicher verwendet werden und welche Funktionen (Kompatibilit\u00e4t, von 4.1 bis 4.3) zur Verf\u00fcgung stehen. Es kann ein einzelnes oder mehrere Rechenzentren geben. F\u00fcr viele Anwendungsm\u00f6glichkeiten ist die Verwendung des Standard-Rechenzentrums \u2013 Default \u2013 ausreichend.
    \nEin Rechenzentrum besteht aus einem oder mehreren Clusters<\/b>. Ein Cluster definiert den Prozessor-Typ, Migrationsrichtlinien usw. F\u00fcr kleine Installationen kann man auch mit dem Cluster Default auskommen.
    \nEin Cluster besteht seinerseits aus Host<\/b>Hosts, die die Hauptarbeit leisten \u2013 sie tragen virtuelle Maschinen, an die Speicher angeschlossen sind. Im Cluster sind 2 oder mehr Hosts vorgesehen. Technisch ist es zwar m\u00f6glich, einen Cluster mit nur 1 Host zu erstellen, aber das hat keinen praktischen Nutzen.<\/p>\n

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

    sind im Vergleich zu VMware recht niedrig, es wird lediglich Unterst\u00fctzung erworben \u2014 ohne die Verpflichtung, eine Lizenz zu kaufen. Unterst\u00fctzung wird nur f\u00fcr die Hypervisoren und ovirt-engine erworben, im Gegensatz zum vCenter Server sind keine weiteren Ausgaben erforderlich.<\/h4>\n

    \nBeispielrechnung f\u00fcr das erste Jahr des Besitzes<\/p>\n

    Betrachten wir einen Cluster aus 4 Maschinen mit 2 Sockeln und Einzelhandelspreisen (ohne Projekt-Rabatte).<\/h4>\n

    \nDas Standard-Abonnement f\u00fcr RHV
    \nkostet 999 $     pro Sockel\/Jahr (Premium 365\/24\/7 \u2014 1499 $), insgesamt 4*2*999=<\/a><\/noindex> Preis von vSphere$7992<\/b>.
    \n    Preis von vSphere<\/a><\/noindex>:<\/p>\n