Diese Frage möchten wir in der folgenden Blogmeldung beantworten. Um den Unterschied zwischen der KVM- und der Container-Virtualisierung aufzuzeigen, erläutern wir die allgemeine Virtualisierungsthematik zu Beginn.
Warum setzt die IT auf Virtualisierung? Die Virtualisierung von Servern, Netzwerkkomponenten, Storage-Lösungen und Applikationen ist in der heutigen Zeit unumgänglich. Dabei sollen die Ressourcen der Serverhardware optimal genutzt werden, was durch leistungsfähige Hardwarekomponenten umgesetzt werden kann. So können unter anderem die Energie- und Datacenterkosten reduziert werden.
Da die Virtualisierungstechnologien eine weitere Ebene in der technischen Landschaft darstellen, werden für diese neue Ebene jedoch zusätzliche Spezialisten benötigt. So senkt die Einführung einer Virtualisierungtechnologie zwar die Betriebskosten, erhöht allerdings die Komplexität.
Seit wann ist Virtualisierungstechnologie attraktiv?
Vor knapp 10 Jahren begannen die ersten Firmen produktive Systeme auf virtuellen Hosts zu betreiben. Zwar verfügten manche IT-Grosskonzerne zu diesem Zeitpunkt bereits über Virtualisierungslösungen, doch funktionierten diese Lösungen nur mit speziellen Servertypen, teuren Betriebssystemen und Lizenzpaketen.
Mit der Integration der Virtualisierungbefehlssätze (VT-X, AMD-V, etc.) auf Server- und Workstationprozessoren, sowie der neu gewonnenen Hypervisor-Stabiliät konnte sich die Virtualisierung in der IT schlussendlich durchsetzen.
Was ist ein Hypervisor?
Der Hypervisor ist die technische logische Komponente, welche die Kommunikation zwischen den virtuellen Maschinen und den Hardwareressourcen ermöglicht. In der Server-Virtualisierung spricht man von Hypervisor-Typen.
1. Hypervisor Typ-1
Dieser Hypervisor ist vor allem durch die VMWare ESX und XEN Produkte bekannt. Beim Hypervisor Typ-1 wird kein vollwertiges installiertes Betriebssystem benötigt. Die virtuellen Maschinen müssen ESX- oder XEN-Treiber kennen, um den Betrieb zu gewährleisten. Umgangsprachlich wird der Hypervisor Typ-1 auch Bare-Metal genannt.
2. Hypervisor Typ-2
Der Hypervisor Typ-2 benötigt zur Installation ein Betriebssystem, z.B. Ubuntu, Debian oder eine andere Linux Distribution. Im Unix/Linux Umfeld wird fast ausschliesslich das Produkt KVM (Kernel-based Virtual Machine) eingesetzt. Zwar gibt es noch weitere Produkte, wie z.B. Linux-VServer oder LXC, doch ist hier der Unterschied zu KVM zu beachten, da LXC nur eine virtuelle Umgebung (aka Container) und keine vollwertige virtuelle Maschine bietet.
/hypervisor.png?width=546&height=321&name=hypervisor.png "Hypervisor @nine")
Ist die Container-Virtualisierung auch für den Betrieb Ihrer Applikation sinnvoll? In unserem Whitepaper finden Sie alle Informationen rund um den Einsatz von Containern:
Welche Technologie setzt nine ein und wie funktioniert das Provisioning?
Unsere Managed VServer und Root VServer laufen auf einem Hypervisor-Typ-2 Modell. Für die Produktpalette unserer virtuellen Server setzen wir die folgenden Technologien ein:
- Host Betriebssystem
- Ubuntu Xenial 16.04 LTS
- Hypervisor Technologie: KVM
Dabei ist es wichtig zu erwähnen, dass es sich hierbei um eine Vollvirtualisierung handelt. Der Kernel des Host-Betriebssystems und der virtuellen Maschinen sind getrennt und von den anderen VMs isoliert.
Wie funktioniert das Provisioning der VMs?
Im internen Virtualisierungs-Management-Tool von nine werden die maximalen Ressourcen (Anzahl der Prozessoren, Memory und Storage) der jeweiligen Produkte als Template gespeichert. Je nach Produkt lädt das Managementtool das notwendige Template und erstellt die neue VM mit den entsprechenden Ressourcenparametern.
Was aber passiert bei einem Up- oder Downgrade einer VM? Hierbei verändert nine die Konfiguration der virtuellen Maschine. Die neuen Ressourcenwerte weist der Hypervisor jedoch erst nach einem sauberen Stop / Start Befehl der virtuellen Maschine zu.
<memory unit='KiB'>12582912</memory> = Memory Reservierung für den Host 12GB
<currentMemory unit='KiB'>12582912</currentMemory>
<vcpu placement='static'>6</vcpu> = Anzahl Prozessoren
<os>
<type arch='x86_64' machine='pc-i440fx-trusty'>hvm</type>#
<boot dev='network'/>
<boot dev='hd'/>
</os>
KVM-Virtualisierung (Vollvirtualisierung) vs. Container-Virtualisierung
Nach den vorangegangenen Erläuterungen zu allgemeinen Informationen über die Virtualisierung widmen wir uns nun dem eigentlichen Thema unserer Blogmeldung.
Was ist ein Container?
Ein Container stellt eine abgetrennte Umgebung bereit in welcher eine bestimmte Software oder Applikation läuft. Er basiert auf einem Image, welches diese Software bereits fertig installiert und konfiguriert hat. Diesem Image fehlen Kernel und Treiber, da die Komponenten vom laufenden Host System bereitgestellt werden. Solche Images sind relativ schlank gehalten, da sie nur die notwendigen Binaries, Libraries, Konfigurationen und Applikationsdaten beinhalten. Der Begriff Anwendungsvirtualisierung wird ebenfalls mit der Container-Virtualisierung assoziiert.
Durch den klar definierten Container-Software-Layer ist die Portierung eines Images von einem Entwicklungssystem zu einem produktiven System um einiges einfacher und mit weniger Abhängigkeiten verbunden als bei den VM’s. In einer Container-Management-Lösung wie OpenShift, Kubernetes oder Docker(-Swarm) übernimmt der Kunde die Erstellung des Container-Images, kümmert sich um die entsprechende Applikationslandschaft und initiiert den Container-Erstellungsprozess. So kann er sich die gewünschte Applikationsumgebung mit den zuvor gebauten Images erstellen.
Architekturunterschied zwischen beiden UmgebungenIm folgenden Bild sind die Unterschiede der beiden Technologien ersichtlich.
/differences-vm-container.png?width=483&height=328&name=differences-vm-container.png "Architektur VM vs. Container @nine")
Einsatzbereiche der jeweiligen Technologien
| KVM | Container |
|---|---|
| Systeme, die dedizierte Ressourcen benötigen | Applikationsumgebungen, die oft skaliert werden müssen |
| Systeme, welche einen eigenen Linux Kernel benötigen | lokale Applikationsentwicklung |
| Microservices Architektur |
Vor & Nachteile der Virtualisierungstechnologien
KVM
| Vorteile | Nachteile |
|---|---|
| Erhöhte Sicherheit aufgrund der Isolierung vom Host Kernel | Administration der gesamten virtuellen Instanz |
| Klare Ressourcenvergabe | Längere Einrichtungszeit bei einer neuen Instanz, selbst wenn Automatisierungstools im Einsatz sind |
| Höhere Betriebskosten (Virtual Machine, Systemadministration und Applikationsentwicklung) |
Container
| Vorteile | Nachteile |
|---|---|
| Schnellere Skalierbarkeit der Umgebung | Container-Isolierung ist nicht auf dem gleichen Niveau wie die VM-Isolierung |
| Schnelle Erstellung & Verteilung der Applikation | Komplexität der Gesamtlösung |
| Kleinerer Speicherbedarf (Images) | Handling der persistenten Daten sowie der Logs muss durchdacht werden (ein Storagepool, in dem der Container Schreib- und Leserechte besitzt, wird zur Datensicherung benötigt. |
| Portierbarkeit der Entwicklungsmaschine (Desktop & Server) zum Testen oder zur Produktion | |
| Tiefere Betriebskosten (Containerbeschaffung & Container Image Entwicklung) |
Fazit
Die Wahl einer geeigneten Virtualisierungslösung hängt von der Sicherheit, der Bereitstellungszeit und den Ressourcen ab.
Für Applikationen oder Systeme, die einen hohen Sicherheitsstandard erfüllen müssen, empfehlen wir eine VM, da hier noch eine extra Abstraktionsschicht den Zugriff auf das Host System und damit die Kompromittierung erschwert. Es sei aber auch erwähnt dass Container sehr stark in Sicherheitsaspekten aufgeholt haben (bspw. Nutzung von User Namespaces). Weiterhin muss natürlich jede VM bspw. bei einem Kernel-Bug geupdatet werden. Dies entfällt bei Containern, da hier nur das Host System zu behandeln ist.
Die Portierung einer Applikation von der Entwicklungs- in die Produktionsumgebung ist dagegen mit der Container-Lösung deutlich günstiger und schneller umgesetzt. Ausserdem eignet sich diese Virtualisierung gut für Applikationen, die rasch deployed und skalierbar sein müssen und das nicht abhängig von Systemressourcen der VM. Die Bereitstellung der VM’s und die Konfiguration entfallen hier somit komplett.
Aus technischer Sicht ist die Mischung von Container- und VM-Lösungen eine optimale Konstellation, obwohl diese im Vergleich zur reinen Container-Variante teurer und komplexer (Aufbau, Betreuung und Lifecycle Management) ist. Die Abbildung der finalen Applikationen und Umgebungen ist mit einer gemischten Landschaft am stabilsten und sicher. Datenbanken und besonders sensible Applikationen oder Systeme sollten auf dedizierten Systemen oder VMs betrieben werden.
Ist die Container-Virtualisierung auch für den Betrieb Ihrer Applikation sinnvoll? In unserem Whitepaper finden Sie alle Informationen rund um den Einsatz von Containern:
