Virtualisierung
Virtuelle Maschinen versus Container
Es gibt die Meinung, dass Container die Software-Entwicklung agil gestalten – und, dass für Aufgaben, die länger dauern können, virtuelle Maschinen ausreichen. Das mag stimmen, greift aber zu kurz. Ein Überblick zu den verschiedenen Virtualisierungsansätzen.
Vor gut 20 Jahren spielte ein Administrator auf einem physikalischen Server das Betriebssystem auf. Das geschah direkt auf das „Blech“, weswegen diese Art des Serverbetriebes auch Bare-Metal-Server genannt wird. Im nächsten Schritt installierte er eine oder mehrere Anwendungen oder Serverdienste. Ein Server hatte genau eine Aufgabe, also eine Anwendung oder einen Auftrag (Workload), auszuführen. Jeder weitere Workload verlangte einen extra Server, der jeweils Strom, Klimatisierung und Platz brauchte. Über die Jahre stieg die Leistungsfähigkeit der Server, sodass diese nicht annähernd ausgelastet wurden. Einfach mehr Software auf einem Server zu installieren, hätte zu Kompatibilitätsproblemen zwischen den Anwendungen oder Problemen mit der Compliance führen können.
Die Lösung dafür brachte erst die Virtualisierung, die einen Software-Unterbau zwischen Hardware und Betriebssystem bereitstellt. Bei dieser Schicht handelt es sich um einen Hypervisor, der den physikalischen Server in mehrere virtuelle Server aufteilt. Zu den gängigen Hypervisor-Systemen zählen VMware ESX, Microsoft Hyper-V oder OpenStack.
Virtuelle Maschinen lasten Server aus
Auf dem Hypervisor werden virtuelle Maschinen (VMs) angelegt und installiert. Eine VM ist eine eigenständige Umgebung, die über ihr eigenes Betriebssystem und eine oder mehrere Anwendungen verfügt. Auf einem Server lässt sich so eine zwei- bis dreistellige Anzahl von VMs betreiben, wobei jede einzelne isoliert von den anderen läuft. Der Hypervisor stellt die Leistung des Servers den VMs zur Verfügung. Die VMs teilen sich CPU (zentrale Prozessoreinheit), Arbeitsspeicher und Speicherplatz eines Servers. Das einzelne virtuelle System startet innerhalb von Minuten und lässt sich leicht vervielfältigen.
Der isolierte Betrieb ist sicherheitsrelevant, denn damit lässt sich verhindern, dass sich ein Virenbefall oder Hackerangriff, der eine VM erfasst, zu leicht auf andere virtuelle Nachbarsysteme überträgt. Andererseits muss jemand, der eine VM erstellen will, auch immer ein Betriebssystem bereitstellen. Das Betriebssystem kann unter Umständen immer dasselbe sein, beansprucht stets Speicherplatz und Pflegeaufwand, so zum Beispiel für Updates. Auf der Ebene des Betriebssystems setzen nun Container an.
Container teilen sich das Betriebssystem
In einem Container gibt es kein komplettes Betriebssystem. In ihm stecken nur Teile davon, wie zum Beispiel Laufzeitumgebungen, sogenannte Runtimes, Anwendungen und genau die Dateien, Konfigurationen, Abhängigkeiten und Bibliotheken, um die Anwendungen auszuführen. Softwaretechnisch wird eine Umgebung für die jeweilige Applikation geschaffen und diese von den anderen abgegrenzt. Auf einem Server lassen sich mehrere Container betreiben, die sich das Betriebssystem des Servers – meist Linux – teilen. Auch werden Middleware-Komponenten gemeinsam genutzt, um beispielsweise eine Anwendung mit einer Datenbank im Backend zu verbinden.
Da sie kein vollständiges Betriebssystem enthalten, sind Container schlanker aufgebaut als VMs. Sie starten schneller und verbrauchen weniger Ressourcen, die der Server (Host) bereitstellt. Deswegen lassen sich auf einem Server im Regelfall mehr Container als VMs betreiben. Allerdings verhindert das gemeinsame Nutzen des Betriebssystems ein vollständiges Isolieren der Container. Tritt eine Sicherheitslücke im Betriebssystem auf, wirkt sich diese auf alle Container aus.
- Virtuelle Maschinen versus Container
- Docker und Kubernetes
Lesen Sie mehr zum Thema
