Hypervisor und Container

Von IT zu zeitkritischer OT

28. August 2018, 17:18 Uhr | Heinz Egger, CEO bei Linutronix
Diesen Artikel anhören

Fortsetzung des Artikels von Teil 1

Virtualisierung und Container

Das Thema Virtualisierung ist tatsächlich deutlich älter als landläufig angenommen: Seinen Anfang nahm es vor mehr als 50 Jahren, mit IBMs ersten Forschungen über virtuelle Maschinen auf dem IBM 360 Mainframerechner. Um die virtuelle Maschine auf der 360er zu verwalten wurde der Virtual Machine Manager, auch Hypervisor genannt, eingeführt.

Die virtuellen Maschinen zeigten der Anwendung und dem Betriebssystem eine Hardware, die so nicht vorhanden gewesen ist: sie wurde von einer Software auf dem Großrechner nur virtuell erzeugt. Popek und Goldberg [1] stellten 1974 eine Arbeit zur Klassifizierung eines Hypervisors vor, die bis heute Gültigkeit hat.

Bei einer Virtualisierung stellt der Hypervisor alle benötigten Systemressourcen zur Verfügung. Die Software bildet nicht vorhandene Hardware oder auch nur Hardwarezugriffe aus der virtuellen Maschine heraus nach. Dieser Vorgang heißt Emulation. Emulation beansprucht Ressourcen und ist per se nicht so leistungsfähig wie eine real existierende Hardware. Um diese Leistungseinbußen zu vermeiden hat man die Paravirtualisierung eingeführt. Hier wird dem Betriebssystem nicht mehr die Illusion des vollständigen Hardwarezugangs geschaffen. Eine Software-Schnittstelle im Hypervisor verwaltet den direkten (physikalischen) Zugriff auf die physische Systemressource durch das Gastsystem. Das Gastsystem benötigt also eigene Treiber, die mit dem Hypervisor kommunizieren und den Emulator überspringen.

Bei einer virtuellen Maschine handelt es sich immer um das Paket aus Betriebssystem und Anwendungscode, das in der virtuellen Umgebung, also im User Space, läuft. Mit Hilfe eines Emulators kann dem Paket sogar eine andere Hardwarearchitektur als physikalisch vorhanden angezeigt werden.

passend zum Thema

Type-1 Hypervisor
Bild 1: Schematischer Aufbau einer VM- und ...
© Linutronix
...einer Container-basierten Lösung
...einer Container-basierten Lösung.
© Linutronix

 

Beim Container-Ansatz wird auf die virtuelle Maschine, das Anzeigen einer eigenen Hardware und Betriebssystems, verzichtet. Das Betriebssystem ist für alle Container identisch, alle Container teilen sich die gleiche Hardware.

Die Separierung der einzelnen Container erfolgt über spezielle Funktionen des Betriebssystems (unter Linux sind dies zum Beispiel CGROUPS und Namespaces). Das macht die Container schlank, das heißt, sie benötigen nicht viel zusätzlichen Code zu Ihrer eigentlichen Aufgabe. Innerhalb eines Containers befindet sich die Anwendung (oft nur eine einzige, kleine Applikation) und die dafür benötigten Libs und Frameworks. Eine Nutzung von Containern entkoppelt die Applikation von der Infrastruktur und bietet damit eine Portabilität, die heute mit Cloud-zentrierten Ansätzen erwartet wird. Die eigentliche Anwendung wird in viele kleine Applikationen aufgeteilt, jede bekommt ihren eigenen Container: zusammen ergeben diese sog. Microservices die gewünschte Lösung. Damit wird der DevOps-Ansatz unterstützt, die Erstellung und Nutzung der Container wird durch Standardisierung wie Docker vereinfacht. Das Zusammenspiel von unterschiedlichen Containern wird mittels Orchestrierungs-Frameworks wie Kubernetes automatisierbar. Bild 1 zeigt den schematischen Aufbau einer VM und einer Container-basierten Lösung. 


  1. Von IT zu zeitkritischer OT
  2. Virtualisierung und Container
  3. IT und OP
  4. Container versus VM

Lesen Sie mehr zum Thema


Das könnte Sie auch interessieren

Jetzt kostenfreie Newsletter bestellen!