Container vs. Virtuelle Maschinen: Vertraue der Macht, Indy
In vielen Unternehmen werden mehrere IT-Dienste betrieben. Um maximale Flexibilität zu gewährleisten, sollen diese unabhängig voneinander laufen. Werden die Dienste auf physikalischen Servern bereitgestellt, müssen sie so dimensioniert sein, dass auch bei erhöhter Auslastung der Applikationen - wie bei der Flucht aus einem peruanischen Tempel - ausreichend Leistung zur Verfügung steht. Im Umkehrschluss bedeutet das, dass die Server zu Zeiten normaler oder geringer Nutzung überdimensioniert sind und im Outer Rim dahintreiben.
In den seltensten Fällen haben mehrere Server zur gleichen Zeit erhöhten Leistungsbedarf. Durch die Virtualisierung können auf einem physikalischen Gerät, dem Host, mehrere Dienste isoliert voneinander bereitgestellt werden, was die Nutzung der Hardware und somit die Effizienz erheblich steigert.
Die zwei Technologien, die hauptsächlich für die Virtualisierung eingesetzt werden, sind Virtuelle Maschinen (VMs) und Container.
Virtuelle Maschinen (öffnet im neuen Fenster) bilden einen physikalischen Computer nach. Sie stellen sämtliche Hardware wie CPU, RAM, Disk und mehr virtuell zur Verfügung.
Erste VMs in den 60ern
Bereits 1966 veröffentlichte IBM ein Betriebssystem, welches Virtualisierung unterstützte. Dadurch war es erstmals möglich, mehreren Benutzern ein eigenes, unabhängiges Betriebssystem auf einem physischen Rechner zur Verfügung zu stellen. Ab 1967 lieferte IBM Hardware aus(öffnet im neuen Fenster) , die eine komplette Virtualisierung implementiert hatte.
Durch günstigere und leistungsfähigere Hardware verlor die Virtualisierung ganzer Computersysteme an Bedeutung. Häufig war es sinnvoller, dedizierte Server zu verwenden, die aufgrund der Leistung mehrere Dienste zur Verfügung stellen konnten.
Die immer tiefere Integration der IT in betriebliche Abläufe stärkte schließlich den Wunsch, diese Dienste ausfallsicher zu betreiben. Dank Virtualisierung ist es möglich, schnell auf sich ändernde Anforderungen oder auftretende Probleme zu reagieren und Systeme bei Bedarf auf andere Hosts zu übertragen. Seit 2000 steigt der Einsatz Virtueller Maschinen. Die vermehrte Nutzung von Cloudservices hat der Verbreitung und Weiterentwicklung zusätzlichen Schub verliehen.
VMs basierend auf Hard- oder Software
Eine VM kann rein hardwarebasiert, rein softwarebasiert oder durch eine Kombination von Hard- und Software implementiert werden. Hardwarebasierte und kombinierte VMs werden in der Regel direkt auf dem Prozessor des Hostcomputers ausgeführt. Der Großteil der aktuellen CPUs unterstützt diese Funktion.
Hardwarebasierte Virtualisierungen sind beispielsweise ESX/ESXi von VMware oder Xen, welches von Citrix weiterentwickelt wird.
Als Beispiel für softwarebasierte Virtualisierung können Emulatoren gesehen werden. Softwarevirtualisierung kann auch eine andere Gerätearchitektur als die des Hostsystems zur Verfügung stellen (z. B. ein Android-Emulator auf einem Windows-Computer mit x86-Architektur).
Andere Technologien wie Virtualbox, Virtual PC oder VMware Workstation sind häufig eine Kombination aus hard- und softwareseitiger Virtualisierung. Diese laufen als Applikation und benötigen ein Basisbetriebssystem als Grundlage.
Die Virtualisierung der Computer erfolgt durch den Hypervisor. Dieser verwaltet den Zugriff auf die bereitgestellten Ressourcen und ist eine zusätzliche Schicht zwischen Gast und Host.
Auf einem Host können mehrere VMs ausgeführt werden. Diese teilen sich die verfügbare Hardware. Ressourcen wie RAM, CPU und Disk werden meist dediziert zugewiesen. Eine dynamische Zuweisung ist nur möglich, wenn dies auch vom zu installierenden Betriebssystem unterstützt wird.
Virtualisierte Computer laufen in einer Sandbox, also isoliert von den anderen VMs und Host. Aus Sicht des Gastbetriebssystems ist es nicht möglich, auf den Host oder die Hardware anderer VMs zuzugreifen.
Im Enterprise-Umfeld kann die Virtualisierung als Cluster aufgesetzt werden. VMs können die gesamte Hardware aller im Cluster befindlichen Hosts nutzen. Das Verschieben einer VM auf einen anderen Host kann ohne Unterbrechung des Betriebs erfolgen.
Container bilden nur das Betriebssystem ab
Container virtualisieren (öffnet im neuen Fenster) nur das Betriebssystem. Der Container enthält in der Regel nur eine Anwendung inklusive aller zur Ausführung notwendigen Binaries und Bibliotheken.
Der Grundstein für diese Art der Virtualisierung wurde bereits 1979 gelegt. Unix-Entwickler führten CHROOT ein(öffnet im neuen Fenster) , mit dem sich Teile des Dateisystems isolieren ließen. Diese Technik wurde hauptsächlich zum Schutz von Servern eingesetzt.
In den späten 1990er Jahren gab es Bestrebungen, mit User Mode Linux ein Betriebssystem im Betriebssystem zu betreiben. Bekanntheit erlangten sie aber kaum. Mit FreeBSD Jail kam im Jahr 2000 die erste Virtualisierung mittels Containertechnik.
Ab den 2000er Jahren begannen Webhoster mit OpenVZ und Virtuozzo , viele Hosts isoliert voneinander auf einem physischen Server zu betreiben.
Linux Containers (LXC) ist ein Verfahren zur Virtualisierung auf Betriebssystemebene. Es kombiniert dafür eine Vielzahl von Techniken. Konfiguration und Betrieb erfordern aber viel Fachwissen über Betriebssysteme.
2013 stellte das Unternehmen Dotcloud das Produkt Docker vor . Damit wurde Entwicklern das Verpacken von Anwendungen und Diensten in einen Container erheblich erleichtert. Die Containervirtualisierung erlebte eine massive Verbreitung.
Hardwareressourcen gemeinsam nutzen
Sämtliche Cloudanbieter stellen heute die Virtualisierung über Container, aber auch die Orchestrierung (automatisiertes Bereitstellen, Verwalten, Skalieren usw. von Containern) als Platform as a Service zur Verfügung. Häufig wird dafür Kubernetes oder Openshift verwendet.
Mehrere Container, die auf einem Host ausgeführt werden, teilen sich dessen Kernel und die zugehörigen Binärdateien und Bibliotheken. Die gemeinsame Nutzung dieser Ressourcen führt dazu, dass sie nicht mehrmals kopiert werden müssen. Umgekehrt bedeutet diese Abhängigkeit aber, dass eine Änderung am Host-Betriebssystem Auswirkungen auf alle Container hat.
Die meisten Containersysteme arbeiten mit Images. Diese beinhalten lediglich die Applikation inklusive der nötigen Binaries und Bibliotheken. Die Größe eines Containers beträgt oft nur wenige Megabyte. Das ermöglicht den Start innerhalb weniger Sekunden.
Containervirtualisierung hat die Softwareentwicklung verändert
Der Einsatz der Containervirtualisierung hat die Entwicklung von Software stark beeinflusst. Die Flexibilität und die Möglichkeit der schnellen Bereitstellung führen dazu, dass eine Applikation auf mehrere kleine Services verteilt wird, die unabhängig voneinander laufen (Microservice-Architektur). Das ermöglicht es, einzelne Teile einer Applikation schnell und einfach zu aktualisieren oder zu erweitern.
Durch die vermehrte Verbreitung und Verwendung haben sich Repositories etabliert, die bereits fertige Container-Images enthalten. Nicht alle Images stammen aus vertrauenswürdigen Quellen und sollten vor der Bereitstellung genauestens geprüft werden. Viele Images werden auch von Bastlern bereitgestellt und eventuelle Sicherheitsvorgaben oder Best Practices werden nicht immer eingehalten.
Die wichtigsten Unterschiede zwischen VM und Container
Bei Containern ist man an das Betriebssystem und die Architektur des Hosts gebunden, als könnten auf einem Sternenzerstörer ausschließlich Schiffe des Imperiums landen. Auf einer VM kann ein beliebiges, kompatibles Betriebssystem installiert werden.
Oft unterstützt oder simuliert der Hypervisor auch eine andere Hardwarearchitektur als der Host, beispielsweise bei Emulatoren. So kann ein Betriebssystem ausgeführt werden, welches auf der Hardware des Hosts nicht lauffähig ist - als würde man ein goldenes Götzenbild durch ein Säckchen Sand ersetzen.
Die Installation verschiedener Betriebssysteme führt dazu, dass man sich gegebenenfalls über deren Lizenzierung Gedanken machen muss. Viele Softwarehersteller bieten dafür eigene Lizenzsysteme an.
Manche Hersteller wie zum Beispiel Apple verbieten die Virtualisierung ihrer Betriebssysteme auf fremder Hard- oder Software, obwohl es technisch durchaus möglich ist.
Ressourcen vs. Sicherheit
Die Ausführung von Containern benötigt weniger Ressourcen als die Ausführung einer VM. Für Letztere wird ein Teil der Ressourcen des Hosts für die Virtualisierung der Hardware über den Hypervisor verwendet. Somit steht nicht die gesamte Hardware für die VM zur Verfügung. Ein Betriebssystem muss zusätzlich ausgeführt werden, was ebenfalls gewisse Ressourcen bindet.
VMs sind isolierte Systeme. Für Angreifer ist es nicht möglich, aus der VM auszubrechen und über den Host auf die anderen VMs zuzugreifen. Gelingt es Angreifern, aus einem Container auf den Kernel zuzugreifen, sind alle auf dem Host befindlichen Container betroffen.
Allerdings stellt der Hypervisor selbst einen zusätzlichen Angriffspunkt dar. Wie jede Software wird auch diese nicht fehlerfrei sein. Um nicht wie der Todesstern zu enden, sind zusätzliche Schutzmechanismen und Strategien erforderlich. Eine Wartung, um den Hypervisor mit Updates zu versorgen, ist oft mit einer Downtime verbunden und somit nicht einfach umzusetzen.
Wurde auf einer VM ein Dienst fehlerhaft konfiguriert, betrifft das nur die eine VM. Ein fehlerhafter Dienst oder Applikation in einem Container kann Auswirkungen wie das Öffnen der Bundeslade haben. Der gesamte Host und alle darauf befindlichen Dienste können in Mitleidenschaft gezogen werden.
Container sind grundsätzlich so konzipiert, dass Daten im Container nicht dauerhaft gespeichert werden. Sofern nicht anders definiert, sind die Daten nach einem Neustart oder einer neuen Bereitstellung weg. VMs verhalten sich wie Computer. Daten, die in einem Ordner abgelegt wurden, bleiben dort, bis sie gelöscht werden.
Bereitstellung erfolgt automatisiert
Container sind darauf hin optimiert, nicht gesichert zu werden. Tritt ein Problem auf, wird der Container zerstört und neu bereitgestellt. Daten, die für die Ausführung der Applikation benötigt werden, sollten außerhalb des Containers in einer Datenbank oder einem Verzeichnis liegen. Diese Daten können gesichert werden. Die Sicherung eines laufenden Containers ist nicht möglich.
Zusätzlich zur Sicherung der Daten einer VM kann auch die komplette VM gesichert werden. Hier wird von der laufenden VM inkl. Speicherabbild ein Snapshot erstellt und gesichert. Nach einem Restore befindet sich die VM im gleichen Status wie zum Zeitpunkt der Sicherung.
Sowohl bei Containern als auch VM kann die Bereitstellung automatisiert werden. Bei einem neuen Container beschränkt sich dieser Vorgang auf das Herunterladen des Images und Starten des Containers. Eine Automatisierung ist erheblich einfacher als bei einer VM.
Nach dem Erstellen einer neuen VM müssen meist noch ein Betriebssystem, Dienste und Applikationen installiert werden. Auch wenn mit System-Images gearbeitet wird, müssen meist mehrere Gigabyte an Daten kopiert werden. Die Bereitstellung einer neuen VM dauert erheblich länger.
Skalierbarkeit ist wichtig
Durch die schnelle Bereitstellung von Containern kann eine horizontale Skalierung (hinzufügen zusätzlicher Instanzen, scale out ) einfach umgesetzt werden - vorausgesetzt, der Dienst unterstützt dies. Abhängig von verschiedenen Kennzahlen (etwa Auslastung des Hosts) und Limits (etwa benötigte Ressourcen des Containers) können weitere Instanzen gestartet oder gestoppt werden - vergleichbar mit einem Geschwader T-65 X-Wing.
Da bei Cloudapplikationen häufig die tatsächlich genutzten Ressourcen verrechnet werden, können die Kosten dadurch so gering wie möglich gehalten werden.
Die Bereitstellung einer VM nimmt mehr Zeit in Anspruch. Deshalb wird meistens eine vertikale Skalierung (zusätzliche Ressourcen, scale up ) umgesetzt. Das bedeutet, wenn eine Applikation zu langsam ist, werden zusätzliche Ressourcen wie CPU oder RAM zur Verfügung gestellt. Was einem Upgrade einer Dreadnought auf die Executor-Klasse entspräche.
Viele Hypervisors unterstützen das dynamische Hinzufügen von Ressourcen zur Laufzeit einer VM. Um diese im Betriebssystem nutzen zu können, ist oft ein Neustart erforderlich.
Und was ist besser?
Container oder VM - was denn jetzt?
Beide Technologien haben Vor- und Nachteile, schließen sich gegenseitig aber nicht aus. So ist es gängige Praxis, einen Container Node in einer VM zu betreiben.
Nicht jede Applikation kann in einem Container ausgeführt werden. Auch ist es nicht für jede Applikation sinnvoll, sie im Container laufen zu lassen, nur weil es möglich ist. Welche Technologie optimal ist, ist von der Art der zu betreibenden Applikation abhängig.
Ressourcenintensive Anwendungen wie Datenbanken oder ERP-Systeme behalten viele Daten im Arbeitsspeicher und reservieren einen Großteil davon. Eine dynamische Zuweisung von Ressourcen würde dazu führen, dass diese während der Verarbeitung allokiert werden müssen. Massive Auswirkungen auf die Performance der Applikation sind die Folgen. Ein Podrennen auf Tatooine wird man damit nicht mehr gewinnen. Auch wenn die meisten Datenbanken als Container-Image zur Verfügung stehen, ist hier eine VM sicher die bessere Wahl.
Die Virtualisierung über Container bringt den größten Vorteil, wenn die Software bereits für den Betrieb in Containern entwickelt wird. Verteilte Applikationen, die aus mehreren kleinen Services bestehen, profitieren davon, dass einzelne Container schnell aktualisiert oder ausgetauscht werden können.
Fazit
Beide Technologien bedienen verschiedene Einsatzszenarien. Während VMs bereits in vielen Unternehmen eingesetzt werden, ist der Betrieb einer eigenen Containerumgebung noch wenig verbreitet.
Um Dienste und Ressourcen optimal nutzen zu können, wird eine IT-Abteilung früher oder später beide Technologien betreiben.
Wie bei Luke und Dr. Jones kann beides ein Abenteuer sein - mit entsprechender Planung und Vorbereitung ebenfalls mit Happy End.