In einem früheren
Artikel wurden Optionen in Betracht gezogen, für die vorhandene Systeme im Rahmen der Implementierung der Importsubstitutionsreihenfolge ersetzt werden können. Weitere Artikel konzentrieren sich auf die Auswahl spezifischer Produkte, die derzeit eingesetzte Produkte ersetzen sollen. Beginnen wir mit dem Ausgangspunkt - Virtualisierungssystemen.
1. Mehl der Wahl
Woraus können Sie wählen? Im
Register des Kommunikationsministeriums gibt es eine Auswahl :
- Servervirtualisierungssystem " R-Virtualisierung " (libvirt, KVM, QEMU)
- Das Softwarepaket " Brest Virtualization Tools " (libvirt, KVM, QEMU)
- Verwaltungs- und Überwachungsplattform für die Sharx Stream- Virtualisierungsumgebung (eine Cloud-Lösung, die in 95% der Fälle nicht für den öffentlichen Sektor geeignet ist (Datenschutz usw.)
- HOST- Virtualisierungssoftware für Server, Desktops und Anwendungen (KVM x86)
- Das System der sicheren Verwaltung der Virtualisierungsumgebung " Z | virt " (auch bekannt als oVirt + KVM)
- Das ROSA Virtualization Virtualization Environment Management System (auch bekannt als oVirt + KVM)
- QP VMM Hypervisor (zu ähnlich zu Oracle Virtual Box, um etwas anderes zu sein)
Sie können auch Hypervisoren berücksichtigen, die Teil der Betriebssystembereitstellung sind oder sich in ihrem Repository befinden. Zum Beispiel hat das gleiche Astra Linux KVM-Unterstützung. Und da es in den Betriebssystem-Repositorys enthalten ist, kann es für die Installation und Verwendung als "legitim" angesehen werden. Die Tatsache, dass „was im Rahmen der Importsubstitution verwendet werden kann und was nicht“, wurde in einem früheren
Artikel erörtert, daher werde ich nicht auf dieses Thema eingehen.
Tatsächlich finden Sie hier eine Liste der Astra Linux-VirtualisierungstoolsLink- Virtualbox
- Virt-Manager (KVM) Adlerstrom
- libvirt über KVM
ROSA Linux hat keine solche Liste, aber im Wiki finden Sie die folgenden Pakete:Link- ROSA-Virtualisierung über OVirt über KVM
- QEMU über KVM
- Über 3,5 über KVM
Alt Linux im Repository gefunden:Link- QEMU über KVM
- libvirt über KVM
- Virtualbox
Berechnen Sie gefundenes folgendes:Link- QEMU über KVM
- libvirt über KVM
- Virtualbox
1.2. Es gibt einen ABER
Bei näherer Betrachtung kommen wir zu dem Schluss, dass wir uns nur mit wenigen bekannten Hypervisoren befassen müssen, nämlich:
- Kvm
- Virtualbox
- QEMU
- bhyve
QEMU ist ein kostenloses Open-Source-Programm zum Emulieren von Hardware verschiedener Plattformen, die ohne Verwendung von KVM funktionieren kann. Die Verwendung von Hardwarevirtualisierung beschleunigt jedoch die Gastsysteme erheblich. Daher ist die Verwendung von KVM in QEMU (-enable-kvm) die bevorzugte Option. (c) Das heißt, QEMU ist ein Typ-2-Hypervisor, der in einer Produktumgebung nicht akzeptabel ist. Es kann mit KVM verwendet werden. In diesem Fall wird QEMU jedoch als KVM-Verwaltungstool verwendet.
bhyve - Hypervisionen des zweiten Typs. Es ist markiert.
Die Verwendung der ursprünglichen
VirtualBox im Handel stellt in der Tat einen
Verstoß gegen die Lizenz dar : „Ab Version 4, die im Dezember 2010 veröffentlicht wurde, wird der Großteil des Produkts unter der GPL v2-Lizenz kostenlos vertrieben. Das darüber installierte Zusatzpaket, das USB 2.0- und 3.0-Geräte, RDP (Remote Desktop Protocol), Laufwerksverschlüsselung, Boot von NVMe und PXE unterstützt, wird unter einer speziellen PUEL-Lizenz („für den persönlichen Gebrauch und zur Einarbeitung“) vertrieben, unter der das System arbeitet "Kostenlos für den persönlichen Gebrauch, zu Bildungszwecken oder zur Bewertung, bevor Sie sich für den Kauf einer kommerziellen Version entscheiden." (c) Plus VirtualBox ist auch ein Typ-2-Hypervisor und verschwindet daher ebenfalls.
Insgesamt: In seiner reinen Form haben wir nur
KVM .
2. Der Rest: KVM oder KVM?

Wenn Sie immer noch zu einem „inländischen“ Hypervisor wechseln müssen, haben Sie ehrlich gesagt eine kleine Auswahl. Es wird
KVM in dem einen oder anderen Wrapper mit verschiedenen Modifikationen sein, aber es wird immer noch KVM sein. Zum Guten oder Schlechten - die Frage ist anders, es gibt sowieso keine Alternative.
Wenn die Bedingungen nicht so streng sind, dann, wie im vorherigen
Artikel angegeben : „Wir müssen die Indikatoren an die festgelegten Grenzen bringen. In der Tat bedeutet dies, dass wir die vorhandenen Betriebssysteme durch Produkte aus der Registrierung des Ministeriums für Kommunikation und Kommunikation ersetzen und die Anzahl der ersetzten Betriebssysteme auf 80% erhöhen müssen. ... Wir können den Cluster also sicher auf Hyper-V belassen, da wir ihn bereits haben und ihn mögen. .. "(c) Wir stehen also vor der Wahl:
Microsoft Hyper-V oder
KVM .
Bei KVM sind möglicherweise Steuerelemente „angeschraubt“, es bleibt jedoch das gleiche
KVM .
Diese Produkte wurden weit mehr als
einmal verglichen, nicht
zweimal , nicht
dreimal ... Nun, Sie verstehen ...
Über die Bereitstellung und Konfiguration von
KVM wurde es auch mehr als
einmal , nicht
zweimal , nicht
dreimal und nicht
viermal geschrieben ... Mit einem Wort, sie
haben es geschafft .
Gleiches gilt für
Microsoft Hyper-V ..Ich sehe keinen Grund, diese Systeme zu wiederholen und zu beschreiben, zu vergleichen usw. Sie können natürlich wichtige Punkte aus den Artikeln herausziehen, aber dies wird meiner Meinung nach Respektlosigkeit für die Autoren bedeuten. Wer wählen muss - er wird nicht nur das lesen, sondern auch einen Berg von Informationen zu entscheiden.
Der einzige Unterschied, auf den ich mich konzentrieren möchte, ist das Failover-Clustering. Wenn Microsoft dies in das Betriebssystem und die Funktionalität des Hypervisors integriert hat, müssen Sie im Fall von KVM Software von Drittanbietern verwenden, die in den Betriebssystem-Repositorys enthalten sein sollte. Zum Beispiel die gleichen Corosync + Pacemaker. (Fast alle inländischen Betriebssysteme haben diesen Haufen ... vielleicht hat jeder, aber ich habe nicht 100% überprüft.) Es gibt auch viele Handbücher zum Konfigurieren von Clustering.
3. Fazit
Nun, wie immer haben sich unsere Kulibins nicht darum gekümmert, sie haben genommen, was passiert ist, haben ein wenig selbst geschraubt und ein „Produkt“ ausgegeben, das laut den Dokumenten inländisch ist, aber tatsächlich - OpenSource. Ist es sinnvoll, Geld aus dem Budget für „separate“ Virtualisierungssysteme auszugeben (nicht im Betriebssystem enthalten)? Ich glaube nicht. Da Sie immer noch die gleiche KVM erhalten, müssen Sie nur dafür bezahlen.
Die Wahl des Ersatzes für den Hypervisor hängt daher davon ab, welches Server-Betriebssystem Sie für das Unternehmen erwerben und betreiben möchten. Oder, wie in meinem Fall, bleiben Sie bei dem, was Sie bereits haben (Hyper-V \ ESXi \ enter_necessary).
Auch zum Thema können Sie lesen:Vorheriger Artikel zur Importsubstitutionsplanung.
Und weiter:Ein Artikel über "inländische" Betriebssysteme.
Ein Artikel über Systeme und Dienste.
Und darüber hinaus zum
QP-Betriebssystem .