Allgemeine Theorie und Archäologie der Virtualisierung x86

Einleitung

Autorenteam

Gepostet von Anton Zhbankov ( AntonVirtual , cloudarchitect.cc )
Mitautoren: Grigory Pryalukhin , Evgeny Parfenov

Allgemeine Virtualisierungskonzepte

Ich musste eine Menge Interpretationen von Virtualisierung sehen und mir viele Kontroversen anhören, um das praktische Ergebnis zu diskutieren. Und wie Sie wissen, läuft das Argument zweier kluger Leute auf eine Debatte über Definitionen hinaus. Definieren wir, was Virtualisierung ist und was daraus entsteht.

Die wahrscheinlich am nächsten liegende Definition für Virtualisierung ist die „Abstraktion“ der objektorientierten Programmierung. Wenn es ins normale Russisch übersetzt wird, verbirgt dies die Implementierung hinter einer abstrakten Schnittstelle. Was natürlich alles auf einmal erklärte. Versuchen wir es noch einmal, aber für diejenigen, die noch kein Programmierstudium absolviert haben.

Virtualisierung - Versteckt eine bestimmte Implementierung hinter einer universellen standardisierten Methode für den Zugriff auf Ressourcen / Daten.

Wenn Sie versuchen, diese Definition in die Praxis umzusetzen, stellt sich heraus, dass sie bei völlig unerwarteten Themen funktioniert. Sagen wir die Uhr. So wurde vor mehreren tausend Jahren eine Sonnenuhr erfunden, und im Mittelalter wurde eine mechanische erfunden. Was haben wir gemeinsam? Die Sonne und ein paar Zahnräder? Eine Art Unsinn. Und dann Quarzoszillatoren und alles andere.
Die Quintessenz ist, dass wir eine Standardschnittstelle haben - einen Zeiger oder einen digitalen Zeiger, der in einer universellen Standardform die aktuelle Zeit anzeigt. Aber ist es uns wichtig, wie genau dieser Mechanismus in der Box implementiert ist, wenn die Zeit für uns mit ausreichender Genauigkeit angezeigt wird?
„Lassen Sie mich“, können Sie sagen, „aber ich dachte, bei der Virtualisierung geht es um Maschinen, Prozessoren und so weiter!
Ja, es geht um Autos und Prozessoren, aber dies ist nur ein Sonderfall. Lassen Sie uns einen breiteren Blick werfen, da der Artikel mutig eine allgemeine Theorie behauptet.

POZOR!

Uwaga! Achtung! Pozor!

Dieser Artikel hat ein allgemeines pädagogisches Ziel, eine ganze Reihe von Technologien und gruseligen Wörtern mit der Geschichte in einer bestimmten Struktur zu verknüpfen, und enthält aufgrund dieses Umstands eine erhebliche Anzahl absichtlicher Vereinfachungen. Natürlich enthält es auch eine große Anzahl nerviger Auslassungen und sogar abgedroschene Fehler bei Tippfehlern. Konstruktive Kritik ist nur zu begrüßen, insbesondere in Form von "Lassen Sie mich an diesen Teil erinnern."

Arten der Virtualisierung

Kehren wir von völlig abstrakten Konzepten zu den bekannten Begriffen unserer geliebten Computer zurück.

Speichervirtualisierung

Die erste ist wahrscheinlich die Art der Virtualisierung, auf die ein Anfänger trifft - die Virtualisierung eines Datenspeichersystems. In diesem Fall wird das Speichersystem nicht im Sinne eines großen Arrays mit Festplatten verwendet, die über einen Glasfaserkanal verbunden sind, sondern als logisches Subsystem, das für die langfristige Datenspeicherung verantwortlich ist.

FS -> LBA -> CHS

Nehmen Sie den einfachsten Fall eines Speichersystems auf einer einzelnen Festplatte. Das übliche Format für die Arbeit mit Daten sind die Dateien, die sich auf dem logischen Laufwerk befinden. Die Datei kann geöffnet, gelesen, geschlossen werden. Ein solches Objekt wie eine Datei existiert jedoch einfach nicht physisch - es gibt nur eine Möglichkeit, auf bestimmte Datenblöcke mit der Adressierungsmethode des Formulars „Laufwerk: \ Ordner1 \ Ordner2 \ Datei“ zuzugreifen. Das heißt Wir treffen auf die erste Ebene der Virtualisierung - von mnemonisch und für den Menschen verständlich, übersetzen wir alles in systemverständliche Adressen. In den Metadatentabellen sucht der Dateisystemtreiber nach der Art der Datenblöcke, und wir erhalten die Adresse im LBA-System (Logical Block Addressing). In dem LBA-System haben Blöcke eine feste Größe und folgen linear aufeinander, d.h. Irgendwie hat es vielleicht mit dem Speichern von Daten auf Magnetband zu tun, aber die Festplatte ist irgendwie ganz anders! Und hier kommen wir zur zweiten Ebene der Virtualisierung - der Übersetzung der LBA-Adressierung an CHS (Zylinder / Kopf / Sektor).



CHS wiederum beginnt bereits im Festplattencontroller, sich in physikalische Parameter zum Lesen umzusetzen, aber das ist eine ganz andere Geschichte.
Selbst bei einem einfachen Zugriff auf die Datei, um beispielsweise ein Video mit Memasics anzuzeigen, stießen wir sofort auf drei Virtualisierungsebenen.
Alles wäre zu einfach, wenn sich die Ebenen nicht in zufälliger Reihenfolge und auf verschiedene Weise überlappen würden.

RAID

Die nächste Virtualisierungsebene, die viele fälschlicherweise nicht als Virtualisierung bezeichnen, ist RAID (redundantes Array kostengünstiger / unabhängiger Festplatten).

Das Hauptmerkmal von RAID im Kontext der besprochenen Konzepte ist nicht die Fähigkeit, Daten vor dem Ausfall einer bestimmten physischen Festplatte zu schützen. RAID bietet eine zweite Ebene der LBA-Adressierung neben mehreren (manchmal sehr vielen) unabhängigen LBA-Adressen. Da wir unabhängig vom RAID-Level genauso auf das RAID zugreifen können wie auf eine einzelne Festplatte ohne RAID, können wir mit Sicherheit sagen:

RAID ist Festplattenvirtualisierung.

Darüber hinaus erstellt der RAID-Controller nicht nur eine große virtuelle Festplatte aus mehreren physischen Festplatten, sondern kann durch Hinzufügen einer weiteren Virtualisierungsebene eine beliebige Anzahl davon erstellen.

Virtualisierung anzeigen

Die nächste Art der Virtualisierung, die viele von uns fast täglich verwenden, jedoch nicht als Virtualisierung betrachten, ist eine Remoteverbindung zum Desktop.

Terminalserver, VDI und sogar nur RDP über VPN zum Server sind Sitzungsvirtualisierung. Über eine Standardschnittstelle (Monitor, Tastatur, Maus) arbeiten wir entweder mit einer realen Maschine oder mit einem unverständlichen Design von einem virtuellen Desktop auf einem verknüpften Klon mit einer containerisierten Anwendung, von der wir Daten über einen Puffer an eine Anwendung mit Streaming-Bereitstellung übertragen. Oder nicht, wer wird es herausfinden, außer dem, der es entworfen hat?

Einführung in die x86-Virtualisierung

Geschichte und Übersicht der Prozessoren

Programmausführung

In der ersten Stunde eines speziellen Programmierkurses sagte Vladimir Denisovich Lelyukh (für ihn in Frieden ruhen) zu den Schülern: Der Computer kann trotz seines Namens nicht zählen, er kann so tun, als könne er zählen. Aber wenn etwas wie eine Ente aussieht, wie eine Ente geht und wie eine Ente quakt, ist es aus praktischer Sicht eine Ente.

Versuchen wir, uns dies für die weitere praktische Verwendung zu merken.

Der Computer und insbesondere der Prozessor tun eigentlich nichts - er erwartet nur einige Eingabeparameter an bestimmten Stellen und liefert dann durch schreckliche schwarze Magie an bestimmten Stellen einige Ergebnisse.

Ein Programm ist in diesem Fall ein bestimmter Strom von Befehlen, die streng sequentiell ausgeführt werden, wodurch wir ein bestimmtes Ergebnis erwarten.
Aber wenn das Programm ausgeführt wird, wie können die Daten dann überhaupt eingegeben werden? Und im Allgemeinen irgendwie auf einem Computer interagieren?

Hierfür wurden Hardware-Interrupts erfunden. Der Benutzer drückt eine Taste - der Tastatur-Controller signalisiert dies und die Ausführung des aktuellen Code-Threads wird unterbrochen. Die Adressen von Interrupt-Handlern werden in einem bestimmten Speicherbereich aufgezeichnet, und nach dem Speichern des aktuellen Zustands wird die Steuerung an den Interrupt-Handler übertragen. Im Gegenzug sollte der Handler theoretisch schnell alles verarbeiten, dann schreiben er und der Handler die im gewünschten Puffer gedrückte Taste auf und geben die Kontrolle zurück. Somit scheint die Anwendung zu laufen und wir können mit dem System interagieren.

Interrupt-Handler (und der Haupttyp der Handler sind Gerätetreiber) haben die Möglichkeit, in einen speziellen Prozessormodus zu wechseln, wenn andere Interrupts vor dem Verlassen dieses Modus nicht implementiert werden können. Was am Ende oft zu einem Aufhängeproblem führte - ein Fehler im Treiber erlaubte es nicht, die Unterbrechung zu beenden.

Multitasking

Was tun, wenn mehrere Programme (Codestreams mit ihren Daten- und Speicherstrukturen) gleichzeitig ausgeführt werden müssen? Wenn es mehr Codestreams gibt als Geräte, die sie ausführen können, ist dies offensichtlich ein Problem.

Pseudo-Multitasking tritt auf, wenn eine Aufgabe ausgeführt wird, wenn direkt zu ihr gewechselt wird.

In Zukunft wird eine kooperative (nicht präemptives Multitasking) Aufgabe angezeigt. Die ausführbare Aufgabe selbst erkennt, dass sie keine Prozessorressourcen mehr benötigt und die Steuerung anderen Personen übergibt. Aber das alles ist nicht genug.

Und hier kommen wieder Unterbrechungen + die Fähigkeit vorzugeben, uns zu retten. Es ist für den Benutzer nicht wirklich wichtig, dass sie ausschließlich gleichzeitig ausgeführt werden. Es reicht aus, so auszusehen.
Daher wird ein Handler einfach aufgelegt, um den Zeitgeber zu unterbrechen, der zu steuern beginnt, welcher Codestream als nächstes ausgeführt werden soll. Wenn der Timer ziemlich oft ausgelöst wird (etwa 15 ms), sieht für den Benutzer alles wie ein Parallelbetrieb aus. Und so gibt es ein modernes Verdrängungs-Multitasking.

Realer Modus

Der reale Prozessormodus in diesem Artikel kann recht einfach beschrieben werden - der gesamte Speicher steht jedem zur Verfügung. Auf jede Anwendung, einschließlich Malware (Malware, Schadsoftware), kann von überall aus zugegriffen werden, sowohl zum Lesen als auch zum Schreiben.

Dies ist die anfängliche Betriebsart der Intel x86-Prozessorfamilie.

Geschützter Modus

1982 erschien eine Innovation im Intel 80286-Prozessor (im Folgenden einfach 286) - eine geschützte Betriebsart, die Innovationen bei der Organisation der Arbeit mit dem Speicher mit sich brachte (zum Beispiel die Zuweisung von Arten von Speichersegmenten - Code, Daten, Stapel). Das Wichtigste, was der 286-Prozessor der x86-Welt gebracht hat, ist das Konzept der Schutzringe, die wir immer noch verwenden.

Das Konzept der Schutzringe erschien ursprünglich im Multics-Betriebssystem für den GE645-Mainframe (1967) mit einer teilweise Software-Implementierung und vollständiger Hardware bereits 1970 im Honeywell 6180-System.



Die Grundidee der Verteidigungsringe ähnelt mehrstufigen mittelalterlichen Festungen, die wertvollste liegt genau in der Mitte hinter den mehreren Mauern. In diesem Fall ist der uneingeschränkte direkte Zugriff auf einen beliebigen RAM-Bereich und die Kontrolle über alle Prozesse das Wertvollste. Sie werden von Prozessen beherrscht, die im Null-Schutz-Ring arbeiten. Hinter der Wand arbeiten im ersten Ring weniger wichtige Prozesse, wie z. B. Gerätetreiber, und in den allerletzten Benutzeranwendungen. Das Prinzip ist einfach - von innen kann man nach außen gehen, aber von außen nach innen ist es verboten. Das heißt Kein Benutzerprozess kann auf den OS-Kernel-Speicher zugreifen, wie dies früher im Real-Modus möglich war.

Bei der allerersten vollständigen Implementierung des Honeywell 6180 wurden 8 Schutzringe implementiert, aber Intel entschied sich, die Schaltung auf 4 zu vereinfachen, von denen in der Praxis die Hersteller von Betriebssystemen nur zwei - null und drei - verwendeten.

32bit

1985 wurde ein weiterer äußerst architektonisch wichtiger Prozessor in der x86-Reihe veröffentlicht - 80386 (im Folgenden 386), der eine 32-Bit-Speicheradressierung implementierte und 32-Bit-Befehle verwendete. Und natürlich Speichervirtualisierung. Wie bereits erwähnt, ist Virtualisierung das Verschleiern der tatsächlichen Implementierung durch die Bereitstellung künstlicher „virtueller“ Ressourcen. In diesem Fall handelt es sich um eine Speicheradressierung. Das Speichersegment hat eine eigene Adressierung, die nichts mit dem tatsächlichen Ort der Speicherzellen zu tun hat.
Der Prozessor war so gefragt, dass er vor 2007 produziert wurde.
Die Architektur in Bezug auf Intel heißt IA32.

64bit

Selbst ohne Virtualisierung Mitte der 2000er Jahre stieß die Branche natürlich bereits an die Grenzen von 32 Bit. Es gab teilweise Problemumgehungen in Form von PAE (Physical Address Extension), die den Code jedoch komplizierten und verlangsamten. Der Übergang zu 64 Bit war eine ausgemachte Sache.

AMD stellte seine Version der Architektur vor, die AMD64 heißt. Bei Intel hofften sie auf die IA64-Plattform (Intel Architecture 64), die wir auch unter dem Namen Itanium kennen. Der Markt begegnete dieser Architektur jedoch ohne große Begeisterung, so dass Intel gezwungen war, eine eigene Unterstützung für AMD64-Anweisungen zu implementieren, die zuerst EM64T und dann nur Intel 64 hieß.

Letztendlich kennen wir alle diese Architektur als AMD64, x86-64, x86_64 oder manchmal x64.

Da die Hauptnutzung von Servern zu dieser Zeit physisch ohne Virtualisierung sein sollte, passierte mit den ersten 64-Bit-Prozessoren in der Virtualisierung eine technisch witzige Sache. Verschachtelte Hypervisoren wurden häufig als Laborserver verwendet, da sich nicht jeder mehrere Cluster physischer Server leisten konnte. Am Ende stellte sich heraus, dass die Last-VM im eingebetteten Hypervisor nur im 32-Bit-Modus funktionieren konnte.

In den ersten x86-64-Prozessoren haben Entwickler, während sie die vollständige Kompatibilität mit dem 32-Bit-Betriebsmodus aufrechterhalten, einen erheblichen Teil der Funktionalität im 64-Bit-Modus verworfen. In diesem Fall bestand das Problem darin, die Speichersegmentierung erheblich zu vereinfachen. Die Möglichkeit, die Unverletzlichkeit eines kleinen Teils des Arbeitsspeichers in der VM zu gewährleisten, in der der Hypervisor-Ausnahmehandler ausgeführt wurde, wurde entfernt. Dementsprechend konnte das Gastbetriebssystem es ändern.
In der Folge gab AMD die Möglichkeit zurück, Segmente einzuschränken, und Intel wartete einfach auf die Einführung der Hardware-Virtualisierung.

UMA

X86-Multiprozessorsysteme begannen mit dem UMA-Modus (Uniform Memory Access) zu arbeiten, bei dem der Abstand zwischen einem Prozessor (Verzögerung beim Zugriff auf eine Speicherzelle) und einer Speicherleiste gleich ist. Bei Intel-Prozessoren wurde dieses Arbeitsschema auch nach dem Erscheinen von Multi-Core-Prozessoren bis zur 54xx-Generation (Harpertown) beibehalten. Seit der 55xx-Generation (Nehalem) haben Prozessoren auf die NUMA-Architektur umgestellt.

Aus Sicht der Ausführungslogik sind dies zusätzliche Hardware-Threads, denen Sie Code-Streams zur parallelen Ausführung zuweisen können.

NUMA

NUMA (Non Uniform Memory Access) - Architektur mit ungleichmäßigem Speicherzugriff. Innerhalb dieser Architektur verfügt jeder Prozessor über einen eigenen lokalen Speicher, auf den mit geringer Latenz direkt zugegriffen wird. Auf den Speicher anderer Prozessoren wird indirekt mit höheren Verzögerungen zugegriffen, was zu einer verringerten Leistung führt.

Bei Intel Xeon Scalable v2-Prozessoren für 2019 bleibt die interne Architektur weiterhin UMA innerhalb des Sockets und wird zu NUMA für andere Sockets (obwohl dies nicht wirklich der Fall ist und dies nur so tut, als wäre es der Fall). Die Opteron-Prozessoren von AMD verfügten bereits zur Zeit des ältesten UMA Xeon über eine NUMA-Architektur, und dann wurde NUMA bis zur letzten Generation von Rom, in der sie zu NUMA = socket zurückkehrten, sogar in den Sockel integriert.

Virtuelle Maschine

Virtuelle Maschine (VM, von der englischen virtuellen Maschine) - Ein Software- und / oder Hardwaresystem, das die Hardware einer bestimmten Plattform emuliert (Ziel ist die Ziel- oder Gastplattform) und Programme für die Zielplattform auf der Hostplattform ausführt (Host ist die Hostplattform) oder die Host-Plattform) oder die Virtualisierung einer Plattform und die Erstellung von Umgebungen, in denen Programme und sogar Betriebssysteme voneinander isoliert sind. Wikipedia
In diesem Artikel werden wir "virtuelle Maschine" sagen, was "virtuelle Systemmaschinen" bedeutet, wodurch alle Ressourcen und Hardware in Form von Softwarekonstrukten vollständig simuliert werden können.
Es gibt zwei Haupttypen von Software zum Erstellen virtueller Maschinen - mit vollständiger und resp. unvollständige Virtualisierung.

Die vollständige Virtualisierung ist ein Ansatz, bei dem die gesamte Hardware, einschließlich des Prozessors, emuliert wird. Ermöglicht das Erstellen von hardwareunabhängigen Umgebungen und das Ausführen von beispielsweise dem Betriebssystem und der Anwendungssoftware für die x86-Plattform auf SPARC-Systemen oder den bekannten Spectrum-Emulatoren mit dem Z80-Prozessor auf dem bekannten x86. Die Kehrseite der völligen Unabhängigkeit ist der hohe Overhead für die Virtualisierung des Prozessors und die geringe Gesamtleistung.

Unvollständige Virtualisierung ist ein Ansatz, bei dem nicht 100% der Hardware virtualisiert wird. Da unvollständige Virtualisierung in der Branche am häufigsten vorkommt, werden wir darüber sprechen. Informationen zu Plattformen und Technologien für virtuelle Systemmaschinen mit unvollständiger Virtualisierung für die x86-Architektur. In diesem Fall ist die Virtualisierung des Prozessors unvollständig, d.h. Mit Ausnahme des teilweisen Ersetzens oder Versteckens bestimmter Systemaufrufe wird der Binärcode der virtuellen Maschine direkt vom Prozessor ausgeführt.

Software-Virtualisierung

Die offensichtliche Konsequenz der Prozessorarchitektur und der Gewohnheiten von Betriebssystemen, im Nullring zu arbeiten, war das Problem - der Kernel des Gastbetriebssystems kann nicht an der üblichen Stelle arbeiten. Der Nullring wird vom Hypervisor belegt, und Sie müssen nur das Gastbetriebssystem dorthin lassen - zum einen sind wir mit allen Konsequenzen in den Real-Modus zurückgekehrt, zum anderen erwartet das Gastbetriebssystem dort niemanden und zerstört sofort alle Datenstrukturen und lässt das Auto fallen.

Aber alles war ganz einfach entschieden: Da für den Hypervisor das Gastbetriebssystem nur eine Reihe von Speicherseiten mit direktem Vollzugriff ist und der virtuelle Prozessor nur eine Reihe von Befehlen darstellt, warum nicht diese umschreiben? Direkt im laufenden Betrieb wirft der Hypervisor alle Anweisungen aus der Warteschlange der Anweisungen zur Ausführung auf dem virtuellen Prozessor aus und ersetzt sie durch weniger privilegierte Anweisungen. Das Ergebnis dieser Anweisungen wird jedoch genauso dargestellt, als befände sich das Gastbetriebssystem im Nullring. Auf diese Weise können Sie alles virtualisieren, bis ein Gastbetriebssystem vollständig fehlt.
Dieser Ansatz wurde 1999 vom Entwicklerteam in das VMware Workstation-Produkt und 2001 in die GSX-Serverhypervisoren (zweiter Typ, wie Workstation) und ESX (erster Typ) implementiert.

Paravirtualisierung

Die Paravirtualisierung ist ein sehr einfaches Konzept, bei dem davon ausgegangen wird, dass das Gastbetriebssystem weiß, dass es sich in einer virtuellen Maschine befindet, und dass es weiß, wie auf das Hostbetriebssystem für bestimmte Systemfunktionen zugegriffen wird. — , .
x86 2003 Linux Xen.

, . , VMware ESXi SCSI PVSCSI, , . ( VMware Tools), Linux (open-vm-tools).

, .

— Intel VT-x AMD-V , , . .

2 (hosted)

— , . . , , , . . , . , - , .

: VMware Workstation / Fusion, Oracle VM VirtualBox, Parallels Desktop, VMware Server (ex-GSX), Microsoft Virtual Server 2005

1 (bare-metal)

, . , , -. -, . . x86 VMware ESX, 1+. “” VMware ESXi — ESX, RHEL.

ESXi. API , VMkernel. , , . , .



: “” , HCL (hardware compatibility list).

1+ ( )

( 1+, 1a, 1.5) , (parent partition Microsoft Hyper-V) (domain dom0 Xen). , , . -.

, . : , ESXi, , HCL. , .

1+ :



: VMware ESX, Microsoft Hyper-V, Xen-based (Citrix XenServer Xen Linux). , Citrix XenServer – RHEL-based OS, Red-Hat Enterprise Linux. Xen : Linux Xen dom0. , Xen-based 1 .

VMware, . . , , . , , .

SLA

, SLA (RPO / RTO).

HA

High Availability — . . : RTO HA + / .

FT

Fault Tolerance — . , . , . . : RTO .

TCO

, TCO.

vMotion

vMotion — . , , .. . : RTO , , .

Storage vMotion

Storage vMotion — . , . : RTO , , .

DPM

Distributed Power Management - Technologie zur Steuerung der Hostlast und des Ein- und Ausschaltens von Hosts, wenn sich die Last des Clusters ändert. Benötigt DRS für seinen Betrieb. Effekt: Gesamtreduzierung des Stromverbrauchs.

Verteilter vSwitch

Distributed vSwitch ist eine Technologie zur zentralen Verwaltung der Netzwerkeinstellungen von virtuellen Host-Switches. Effekt: Reduzierung des Umfangs und der Komplexität der Arbeit an der Neukonfiguration des Netzwerksubsystems, Verringerung des Fehlerrisikos.

EVC

Enhanced vMotion Compatibility — , . , . : / .

QoS

, SLA .

vNUMA

vNUMA — NUMA (vCPU vRAM > NUMA). : , NUMA.

Resource Pool

— . : , .

Limit / Reserve

/ , / .

DRS

Dynamic Resource Scheduler — . vMotion.

Storage IO Control

Storage IO control — , “ ”, , . — / .

Network IO Control

Network IO Control — , “ ”, .

Storage Integration (VAAI etc)

:

• / , .
• — VAAI, ODX. , . , , , . , .

Sicherheit

Microsegmentation

— , . .

Agentless AV

. . , “ ”.

, — . . , .

. + + . . , “ ”. .

Architektur

, .

, , , . — SDS.

Wir bekommen:

• — , , , /. .
• — , , . .

, , . , .

— .
. , SDS. disaggregated HCI ( ). , , NetApp , . NetApp HCI ( 2019) — hybrid cloud infrastructure.

, , .

• 1. . SDS , vSAN + ESXi
• 1.5 . SDS , S2D + Hyper-V
• 2. . SDS . Nutanix, Cisco Hyperflex, HPE Simplivity.

, , . 1 , , 2 .

, , . , OSI, . — , .

— , . , .

vs

Die Vor- und Nachteile beider Ansätze sind recht einfach und direkt entgegengesetzt.

Vollständige Virtualisierung (VM) bietet vollständige Unabhängigkeit von der Eisenebene, einschließlich vollständig unabhängiger Betriebssystem-, Festplatten- und Netzwerkstacks. Auf der anderen Seite benötigt jede Anwendung, da wir uns an Schema 1 Anwendung = 1 Server halten, ein eigenes Betriebssystem, eine eigene Festplatte und einen eigenen Netzwerkstapel. d.h. Es gibt eine Vielzahl von Ressourcen.

Die Container verfügen über gemeinsame Festplatten- und Netzwerkstacks mit dem Host-Betriebssystem und verwenden alle zusammen denselben Kern auf dem gesamten physischen Server (nun ja, oder virtuell, seit einiger Zeit), sodass Sie in homogenen Landschaften ganz erheblich Ressourcen sparen können.

In der Vergangenheit verfügte x86 zunächst über Container für alles sowie über physische Server. Nach dem Aufkommen der vollständigen Virtualisierung nahm die Bedeutung von Containern um fast 15 Jahre dramatisch ab, und in der Unternehmenswelt herrschten dicke VMs. Zu dieser Zeit befanden sich Container bei Hostern, die Hunderte von Webservern des gleichen Typs bereitstellten, bei denen ihre Leichtigkeit gefragt war. Aber in den letzten Jahren, seit etwa 2015, sind Container in Form von Cloud-nativen Anwendungen in die Unternehmensrealität zurückgekehrt.

Behälter 0.1

Chroot

Der Prototyp von Containern war 1979 Chroot.

„Chroot ist das Ändern des Stammverzeichnisses unter Unix-ähnlichen Betriebssystemen. Ein Programm, das mit einem geänderten Stammverzeichnis gestartet wird, hat nur Zugriff auf die in diesem Verzeichnis enthaltenen Dateien. “

Das heißt Tatsächlich erfolgt die Isolation nur auf Dateisystemebene, andernfalls ist dies nur ein normaler Vorgang im Betriebssystem.

Freebsd Gefängnis

Deutlich weiter fortgeschritten war das 1999 erschienene Gefängnis für freies BSD. Mit Jail konnten Sie vollwertige virtuelle Betriebssysteminstanzen mit eigenen Anwendungen und Konfigurationsdateien erstellen, die auf der Basis-FreeBSD basieren. Sicherlich gibt es diejenigen, die sagen - und was macht das Gefängnis in Containern, denn das ist Paravirtualisierung! Und sie werden teilweise recht haben.

Vor der vollständigen Virtualisierung (und ihrer Variante in Form einer Paravirtualisierung) fehlt dem Gefängnis jedoch die Möglichkeit, den Kernel einer anderen Version in der Gast-VM auszuführen und mit der Migration der VM auf ein anderes Hostsystem zu clustern.

Solaris-Zonen

Solaris Zones ist eine Betriebssystemvirtualisierungstechnologie (Containervirtualisierung), die 2004 in Sun Solaris eingeführt wurde. Das Grundprinzip ist ein geringer Virtualisierungsaufwand.

Die Migration auf OpenSolaris und darauf basierende Distributionen, die 2019 verfügbar waren, erlangte kaum Popularität.

Behälter 1.0

Im Zeitalter von Containern 1.0 sind zwei Hauptrichtungen der Containerisierung aufgetreten: kommerzielle Produkte für Hosting-Anbieter und Containerisierung von Anwendungen.

Virtuozzo / OpenVZ

Russische SWsoft stellte 2001 seine erste Version der Containervirtualisierung Virtuozzo vor, die auf den Markt von Hosting-Anbietern ausgerichtet ist. Aufgrund der Entschlossenheit und der spezifischen kommerziellen Zielgruppe erwies sich das Produkt als recht erfolgreich und gewann an Popularität. Technologisch wurde 2002 der gleichzeitige Betrieb von 2500 Containern auf einem Server mit 8 Prozessoren demonstriert.

2005 erschien eine offene Version von Virtuozzo-Containern für Linux mit dem Namen OpenVZ. Und wurde fast zum Goldstandard für das Hosting von VPS.

Lxc

LinuX Containers (LXC) ist eine weitere bekannte Containervirtualisierung basierend auf Namespaces und cgroups, die 2008 veröffentlicht wurde. Sie liegt den derzeit beliebten Dockern usw. zugrunde.

Container 1.1 (Anwendungsvirtualisierung)

Wenn die verbleibenden Container das Basisbetriebssystem in Segmente unterteilen sollen, können Sie diese Schicht des Systems abreißen und in einer einzigen Box mit der Anwendung und der gesamten Umgebung verpacken. Und dann kann dieses fertige Paket als normale Anwendung auf Benutzerebene gestartet werden.

App-v

Microsoft Application Virtualization (App-V), ehemals Softricity SoftGrid - Technologie zum Containerisieren bestimmter Anwendungen (der Container ist das Gegenteil) in einer isolierten Sandbox, dann Microsoft. Im Jahr 2006 erwarb Microsoft das Softricity-Startup, das den Container tatsächlich umdrehte.

Thinapp

VMware ThinApp (ehemals Thinstall) ist ein Application Containerization-Produkt von Jilt, das 2008 von VMware erworben wurde. VMware schätzt, dass 90-95% aller Anwendungen auf der Welt diese Technologie verwenden.

Behälter 2.0

Die Entstehungsgeschichte von Containern 2.0 ist stark mit einer Veränderung des Softwareentwicklungsprozesses verbunden. Der Wunsch des Unternehmens, einen so wichtigen Parameter wie Time-to-Market zu reduzieren, zwang die Entwickler, die Ansätze zur Erstellung von Softwareprodukten zu überdenken. Die Waterfall-Entwicklungsmethode (lange Release-Zyklen, die gesamte Anwendung wird aktualisiert) wird durch Agile ersetzt (kurze, zeitlich festgelegte Release-Zyklen, Anwendungskomponenten werden unabhängig aktualisiert) und zwingt Entwickler, monolithische Anwendungen in Komponenten zu unterteilen. Während die Komponenten von monolithischen Anwendungen immer noch recht groß sind und nicht viele von ihnen in virtuellen Maschinen platziert werden können, sind virtuelle Maschinen nicht sehr geeignet, wenn eine Anwendung aus Dutzenden oder Hunderten von Komponenten besteht. Darüber hinaus tritt auch das Problem von zusätzlichen Softwareversionen, Bibliotheken und Abhängigkeiten auf. Oft kommt es vor, dass unterschiedliche Komponenten unterschiedliche Versionen oder unterschiedlich konfigurierte Umgebungsvariablen erfordern. Solche Komponenten müssen auf verschiedene virtuelle Maschinen verteilt werden, weil Es ist fast unmöglich, mehrere Softwareversionen gleichzeitig auf demselben Betriebssystem auszuführen. Die Anzahl der VMs wächst wie eine Lawine. Hier werden Container auf der Bühne angezeigt, sodass im Rahmen eines Gastbetriebssystems mehrere isolierte Umgebungen zum Starten von Anwendungskomponenten erstellt werden können. Durch die Containerisierung von Anwendungen können Sie die Segmentierung einer monolithischen Anwendung in noch kleinere Komponenten fortsetzen und zum Paradigma einer Aufgabe = einer Komponente übergehen - eines Containers, der als Microservice-Ansatz bezeichnet wird, und jede dieser Komponenten ist ein Microservice.

Behälter unter der Haube

Wenn Sie sich den Container mit einem Blick des Systemadministrators ansehen, dann sind dies nur Linux-Prozesse mit eigenen Pids usw. Was macht es möglich, Prozesse, die in Containern ablaufen, voneinander zu isolieren und die Ressourcen des Gastbetriebssystems gemeinsam zu verbrauchen? Zwei Standardmechanismen, die im Kernel jeder modernen Linux-Distribution vorhanden sind. Der erste, Linux-Namespaces, der sicherstellt, dass jeder Prozess seine eigene Betriebssystemdarstellung (Dateisystem, Netzwerkschnittstellen, Hostname usw.) und der zweite, Linux-Kontrollgruppen (cgroups), sieht, dass der Prozess nur die Ressourcen des Gastbetriebssystems (CPU, Speicher) beansprucht Netzwerkbandbreite usw.).

Linux-Namespaces

Standardmäßig enthält jedes Linux-System einen einzelnen Namespace. Alle Systemressourcen wie Dateisysteme, Prozesskennungen (Prozess-IDs), Benutzer-IDs (Benutzer-IDs) und Netzwerkschnittstellen gehören zu diesem Namespace. Aber niemand hindert uns daran, zusätzliche Namespaces zu erstellen und Systemressourcen zwischen ihnen neu zu verteilen.

Wenn ein neuer Prozess gestartet wird, startet er in einem Namespace, einem Systemstandard oder einem der erstellten. Bei diesem Vorgang werden nur die Ressourcen angezeigt, die in dem zum Ausführen verwendeten Namespace verfügbar sind.

Aber nicht alles ist so einfach, jeder Prozess gehört nicht zu einem einzelnen Namespace, sondern zu einem Namespace in jeder der Kategorien:

• Mount (mnt)
• Prozess-ID (pid)
• Netzwerk (netto)
• Prozessübergreifende Kommunikation (IPC)
• UTS
• Benutzer-ID (Benutzer)

Jeder Namespace-Typ isoliert eine entsprechende Ressourcengruppe. Beispielsweise definiert der UTS-Bereich den für Prozesse sichtbaren Hostnamen und Domänennamen. Somit können zwei Prozesse innerhalb des Gastbetriebssystems davon ausgehen, dass sie auf verschiedenen Servern ausgeführt werden.

Der Netzwerk-Namespace bestimmt die Sichtbarkeit der Netzwerkschnittstellen. Der Prozess darin sieht nur die Schnittstellen, die zu diesem Namespace gehören.

Linux-Kontrollgruppen (cgroups)

Linux Control Groups (cgroups) ist der Kernel-Systemmechanismus (Kernel) von Linux-Systemen, der den Verbrauch von Systemressourcen durch Prozesse begrenzt. Jeder Prozess oder jede Gruppe von Prozessen kann nicht mehr Ressourcen (CPU, Speicher, Netzwerkbandbreite usw.) abrufen, als ihm zugewiesen ist, und kann nicht die "anderen" Ressourcen erfassen - die Ressourcen benachbarter Prozesse.

Docker

Wie oben erwähnt, hat Docker keine Container als solche erfunden. Container gibt es schon seit vielen Jahren (auch auf LXC-Basis), doch Docker machte sie sehr beliebt, indem es das erste System entwickelte, mit dem Container einfach und problemlos zwischen verschiedenen Maschinen ausgetauscht werden konnten. Docker hat ein Tool zum Erstellen von Containern erstellt - das Packen der Anwendung und ihrer Abhängigkeiten sowie das Ausführen von Containern auf jedem Linux-System, auf dem Docker installiert ist.

Ein wichtiges Merkmal von Docker ist die Portabilität nicht nur der Anwendung selbst und ihrer Abhängigkeiten zwischen völlig verschiedenen Linux-Distributionen, sondern auch die Portabilität der Umgebung und des Dateisystems. Ein unter CentOS erstellter Container kann beispielsweise auf einem Ubuntu-System ausgeführt werden. In diesem Fall wird das Dateisystem innerhalb des gestarteten Containers von CentOS geerbt, und die Anwendung geht davon aus, dass es auf CentOS ausgeführt wird. Dies ähnelt in gewisser Weise einem OVF-Image einer virtuellen Maschine, das Konzept eines Docker-Images verwendet jedoch Ebenen. Dies bedeutet, dass beim Aktualisieren nur eines Teils des Image nicht das gesamte Image erneut heruntergeladen werden muss. Es reicht aus, nur die geänderte Ebene herunterzuladen, als ob es im OVF-Image möglich wäre, das Betriebssystem zu aktualisieren, ohne das gesamte Image zu aktualisieren.

Docker hat ein Ökosystem zum Erstellen, Speichern, Übertragen und Starten von Containern geschaffen. Die Docker-Welt besteht aus drei Hauptkomponenten:

• Bilder - ein Bild, dies ist die Entität, die Ihre Anwendung, die erforderliche Umgebung und andere Metadaten enthält, die zum Starten des Containers erforderlich sind.
• Register - Repository, Speicherort für Docker-Images. Es gibt eine Vielzahl von Repositorys, die von offiziell - hub.docker.com bis hin zu privaten Repositorys reichen, die in der Infrastruktur des Unternehmens bereitgestellt werden.
• Container - Ein Container, ein Linux-Container, der aus einem Docker-Image erstellt wurde. Wie oben erwähnt, handelt es sich um einen Linux-Prozess, der auf einem Linux-System mit installiertem Docker ausgeführt wird und von anderen Prozessen und dem Betriebssystem selbst isoliert ist.

Berücksichtigen Sie den Lebenszyklus des Containers. Zunächst erstellt ein Entwickler mit seiner Anwendung (dem Docker-Build-Befehl) ein Docker-Image, das vollständig von Grund auf neu erstellt wurde oder bereits erstellte Images als Grundlage verwendet (denken Sie an Ebenen). Außerdem kann dieses Image vom Entwickler direkt auf seinem eigenen Computer gestartet oder auf einen anderen Computer übertragen werden - den Server. Aus Gründen der Portabilität werden häufig Repositorys verwendet (Docker-Push-Befehl) - sie laden das Image in das Repository. Danach kann das Image auf einen anderen Computer oder Server heruntergeladen werden (Docker Pull). Erstellen Sie abschließend einen Arbeitscontainer (Docker-Lauf) aus diesem Image.

Kubernetes

Wie wir bereits gesagt haben, bedeutet das Konzept der Mikrodienste, eine monolithische Anwendung in viele kleine Dienste zu unterteilen, die normalerweise eine einzige Funktion ausführen. Nun, wenn es Dutzende solcher Dienste gibt, können sie immer noch manuell über beispielsweise Docker verwaltet werden. Aber was tun, wenn es Hunderte und Tausende solcher Dienste gibt? Zusätzlich zur industriellen Umgebung benötigen Sie eine Testumgebung und zusätzliche Umgebungen für verschiedene Versionen des Produkts, d. H. multiplizieren Sie mit 2, mit 3 oder noch mehr. Google hatte die gleichen Probleme: Die Ingenieure von Google waren die ersten, die Container im industriellen Maßstab einsetzten. So wurde Kubernetes (K8s) geboren, unter dem Namen Borg in den Wänden von Google-Produkt erstellt, später der breiten Öffentlichkeit zugänglich gemacht und umbenannt.

K8s ist ein System, mit dem Containeranwendungen (Microservices) einfach bereitgestellt, verwaltet und überwacht werden können. Wie wir bereits wissen, ist jeder Linux-Rechner zum Starten von Containern geeignet und die Container sind voneinander isoliert. K8s können verschiedene Server mit unterschiedlicher Hardware und unter der Kontrolle verschiedener Linux-Distributionen verwalten. All dies hilft uns, die verfügbare Hardware effektiv zu nutzen. Wie bei der Virtualisierung bietet K8s einen gemeinsamen Ressourcenpool zum Starten, Verwalten und Überwachen unserer Mikrodienste.

Da dieser Artikel hauptsächlich für Virtualisierungstechniker gedacht ist, um ein allgemeines Verständnis der Funktionsprinzipien und der Hauptkomponenten von K8s zu erhalten, empfehlen wir Ihnen, den Artikel zu lesen, in dem die Parallele zwischen K8s und VMware vSphere dargestellt wird: https://medium.com/@pryalukhin/kubernetes-introduction-for-vmware- users-232cc2f69c58

Geschichte der X86 Industrial Virtualization

VMware

VMware erschien 1998 und begann mit der Entwicklung eines zweiten Hypervisortyps, der später als VMware Workstation bekannt wurde.

Das Unternehmen trat 2001 mit zwei Hypervisoren in den Servermarkt ein - GSX (Ground Storm X, zweiter Typ) und ESX (Elastic Sky X, erster Typ). Im Laufe der Zeit sind die Aussichten des zweiten Typs in Serveranwendungen offensichtlich geworden, d.h. Keine. Und die bezahlte GSX wurde zuerst in einen kostenlosen VMware-Server verwandelt und dann vollständig gestoppt und begraben.

Im Jahr 2003 wurden das zentrale Managementsystem von Virtual Center, die vSMP-Technologie und die Livemigration von virtuellen Maschinen eingeführt.

Im Jahr 2004 wurde VMware von EMC, einem Speichergiganten, übernommen, jedoch betriebsunabhängig gelassen.

Im Jahr 2008, als VMware de facto zum Industriestandard wurde, stimulierte es das schnelle Wachstum wettbewerbsfähiger Angebote - Citrix, Microsoft usw. Es wird deutlich, dass eine kostenlose Version des Hypervisors erforderlich ist, was unmöglich war - da ein übergeordneter Abschnitt in ESX recht kommerzielles RHEL verwendete. Das Projekt, RHEL durch etwas einfacheres und kostenloses zu ersetzen, wurde 2008 mit dem System busybox umgesetzt. Das Ergebnis ist ESXi, das heute allen bekannt ist.

Parallel dazu entwickelt sich das Unternehmen durch interne Projekte und Akquisitionen von Startups. Vor einigen Jahren nahm eine Liste von VMware-Produkten einige A4-Seiten ein. Sagen wir einfach. VMware für 2019 ist mit einem Marktanteil von mehr als 70% und einem absoluten Technologieführer nach wie vor der De-facto-Standard im On-Premise-Markt für die vollständige Virtualisierung von Unternehmen. Eine detaillierte Überprüfung der Geschichte verdient einen eigenen, sehr umfangreichen Artikel.

Connectix

Connectix wurde 1988 gegründet und arbeitete bis zur Einführung der Virtualisierung an einer Vielzahl von Systemdienstprogrammen. 1997 wurde das erste VirtualPC-Produkt für den Apple Macintosh entwickelt, mit dem Windows auf einer virtuellen Maschine ausgeführt werden kann. Die erste Version von VirtualPC für Windows erschien im Jahr 2001.

Im Jahr 2003 kaufte Microsoft VirtualPC und im Einvernehmen mit Connectix wechselten die Entwickler zu Microsoft. Danach wurde Connectix geschlossen.

Das VHD-Format (Virtual Hard Disk) wurde von Connectix für VirtualPC entwickelt. Zur Erinnerung: Die virtuellen Festplatten von Hyper-V-Maschinen enthalten in ihrer Signatur „conectix“.
Wie Sie sich vorstellen können, ist der virtuelle PC ein klassischer Desktop-Hypervisor des zweiten Typs.

Microsoft

Die Reise von Microsoft in die industrielle Virtualisierung begann mit dem Kauf von Connectix und dem Rebranding von Connectix Virtual PC in Microsoft Virtual PC 2004. Der für eine Weile entwickelte virtuelle PC wurde unter Windows 7 unter dem Namen Windows Virtual PC aufgenommen. In Windows 8 und höher wurde Virtual PC durch ersetzt Desktop-Version von Hyper-V.

Basierend auf Virtual PC wurde der Virtual Server Server Hypervisor erstellt, der bis Anfang 2008 bestand. Aufgrund des offensichtlichen technologischen Verlusts vor VMware ESX wurde beschlossen, die Entwicklung des zweiten Hypervisortyps zugunsten des eigenen ersten Hypervisortyps, Hyper-V, zu drosseln. Es gibt eine inoffizielle Meinung in der Branche, dass Hyper-V Xen in der Architektur überraschend ähnlich ist. Ungefähr das Gleiche wie .Net in Java.

"Natürlich könnte man denken, dass Microsoft die Idee von Java gestohlen hat." Aber das stimmt nicht, Microsoft hat sie inspiriert! - (aus einer Rede eines Microsoft-Vertreters bei der Präsentation von Windows 2003 Server)

Aus den kuriosen Augenblicken ist zu ersehen, dass die Verwendung eigener Virtualisierungsprodukte innerhalb von Microsoft in den letzten null Jahren, gelinde gesagt, optional war. Es gibt Screenshots von Technet aus Artikeln zur Virtualisierung, in denen das VMware Tools-Logo deutlich in der Taskleiste vorhanden ist. Außerdem führte Mark Russinovich auf der Plattform 2009 in Moskau eine Demonstration mit VMware Workstation durch.

Um neue Märkte zu erschließen, hat Microsoft mit Azure eine eigene öffentliche Cloud erstellt, die einen stark modifizierten Nano-Server mit Hyper-V-, S2D- und SDN-Unterstützung als Plattform verwendet. Es ist erwähnenswert, dass Azure anfangs an einigen Stellen weit hinter den On-Premise-Systemen zurückblieb. Beispielsweise wurde die Unterstützung für virtuelle Maschinen der zweiten Generation (mit Unterstützung für sicheren Start, Start von GPT-Partitionen, PXE-Start usw.) erst 2018 in Azure angezeigt. In On-Premise sind VMs der zweiten Generation seit Windows Server 2012R2 bekannt. Gleiches gilt für Portallösungen: Bis 2017 verwendeten Azure und das Windows Azure Pack (mandantenfähige Cloud-Lösung mit SDN- und Shielded VM-Unterstützung, die 2013 den System Center App Controller ersetzte) dasselbe Portaldesign. Nachdem Microsoft einen Kurs zu öffentlichen Clouds angekündigt hatte, trat Azure vor, um verschiedene Kenntnisse zu entwickeln und zu implementieren. Um das Jahr 2016 herum kann man ein völlig logisches Bild beobachten: Jetzt stammen alle Innovationen in Windows Server von Azure, aber nicht in die entgegengesetzte Richtung. Die Tatsache, dass Teile der Dokumentation „wie sie sind“ von Azure in den On-Premise-Modus kopiert werden, weist darauf hin (siehe Dokumentation zu Azure SDN und Network Controller), was einerseits auf die Einstellung zu On-Premise-Lösungen hinweist und andererseits auf die Beziehung der Lösungen hinweist in Bezug auf Einheiten und Architektur. Wer hat von wem kopiert und wie ist es wirklich - eine strittige Frage.

Im März 2018 gab Satya Nadela (Microsoft-CEO) offiziell bekannt, dass die öffentliche Cloud zur Priorität des Unternehmens wird. Dies ist offensichtlich ein Symbol für das allmähliche Zusammenfalten und Verblassen der Serverlinie für On-Premise-Produkte (eine Stagnation war jedoch bereits 2016 zu beobachten, wurde jedoch mit der ersten Betaversion von Windows Server und anderen On-Premise-Produktlinien bestätigt), mit Ausnahme von Azure Edge - dem minimal erforderlichen Server Infrastruktur im Büro des Kunden für Dienste, die nicht in die Cloud übertragen werden können.

Virtuelles Eisen

2003 Virtual Iron Xen , .
2009 Oracle Oracle VM x86. Oracle VM SPARC.

Innotek

2007 Innotek GmbH VirtualBox, . .

2008 Sun, 2010 Oracle. Oracle .
VirtualBox — VDI (), VMDK (VMware), VHD (Microsoft). , Windows, macOS, Linux, Solaris OpenSolaris. VirtualBox FreeBSD.

Ibm

— ( : 60- 1 ). , : . -. - , . (!) ( , , – ). – , . - , IBM .

60- XX , , . . ( Pay as you go , ?). . .

IBM IBM System/360-67. CP/CMS , , . CP (Control Program) – , « » (VM). CMS ( – Cambridge Monitor System, Conversational Monitor System) . , CMS z/VM. , 90- ( , ) Time-Sharing. , – , . , , .

CP/CMS VM/370 System/370 2 1972 . – VM, VM IBM. , ( ) – VM/370. : () System/370 VM/370 ( ! – ). .

80- « ». VM , . , VM. (Logical Partition Access Resources LPAR), . , - VM, LPAR VM . - , . , VM , 80-:

VM/SP – System z
VM/SP HPO (High Performance Option) – VM/SP System z
VM/XA (extended architecture) – VM S/370.

90- x86 , . , , - . , , , . , IBM , .

Linux Xen

Xen ( ) — , (Ian Pratt) GPL. 2003 . , XenSource.
2013 Xen Linux Foundation.

XenSource

XenServer XenEnterprise, 2007 Citrix.

Citrix XenServer

XenSource 500 , Citrix . , , XenServer , . VMware ESX XenServer 2009 . XenCenter .
Citrix Microsoft , , .

, Citrix XenApp XenDesktop Xen.

Amazon

Amazon IaaS EC2 (Elastic Compute) 2006 . EC2 Xen, Amazon , , .

2017 EC2 KVM . , EC2 KVM .

Linux QEMU / KVM

QEMU (Quick EMUlator) — , GPL v2. x86 ARM, MIPS, RISC-V, PowerPC, SPARC, SPARC64. QEMU , . QEMU x86 , KVM (Kernel-based Virtual Machine) Qumranet.

KVM — QEMU KVM, qcow2 (QEMU copy-on-write 2) KVM.
, QEMU , QEMU / KVM .

Qumranet

, KVM SPICE. 2005 , KVM Linux. 4 2008 Red Hat.

Roter Hut

GNU/Linux, 2010 Red Hat Xen. , , . , KVM. Red Hat Enterprise Virtualization 2.2 (RHEV) 2010 VDI Citrix VMware Qumranet, . , Live Migration, 2 ( RHEL). , , Red Hat Xen .

28 2018 IBM Red Hat.

OpenStack

OpenStack - VMware x86. 2010 Rackspace Hosting ( ) NASA ( Nebula). , 2012 VMware OpenStack, -.

Canonical (Ubuntu Linux), Debian, SUSE, Red Hat, HP, Oracle.

. 2012 NASA , AWS. 2016 HPE Helion OpenStack.

OpenStack KVM. OpenStack , OpenStack .

OpenStack . — OpenStack. , , .

OpenStack , . OpenStack — , .

OpenStack . , , OpenStack .

Nutanix AHV

Nutanix VMware vSphere. - , - VMware , . KVM, AHV (Acropolis HyperVisor).

Parallels

7 Virtuozzo KVM.

Proxmox

Proxmox VE (Virtual Environment) — Proxmox Server Solutions GmbH Debian Linux. 2008 .
LXC ( OpenVZ), KVM.

Parallels / Virtuozzo /

1999 SWsoft . 2003 - Plesk.

2004 SWsoft Parallels Parallels Workstation ( Windows).
Parallels Parallels Desktop Mac ( MacOS).

, . Virtuozzo OpenVZ, . Parallels Parallels Bare Metal Server ( Parallels Hypervisor Cloud Server, Virtuozzo), Cloud Storage. .

2015 — ( ) Virtuozzo, . Depo IBS -.

7 Virtuozzo , 7 KVM. , — KVM.
, 2019 .

Parallels Desktop Parallels Corel. Odin IngramMicro. Virtuozzo / .