© Mikhail Bulanov, 123RF

Während die IT-Welt noch dem Container-Hype hinterherhechelt, stellt Amazon eine Alternative zu KVM vor. Was wie ein Anachronismus wirken könnte, ist aber pfiffig – und verdient einen genaueren Blick.

Virtualisierung ist für viele Admins etwas, was man in Süddeutschland und Österreich als “gemähte Wiese” bezeichnen würde: Ein Thema, das sich im Grunde erledigt hat, in dem keine Spannung mehr steckt – ein Selbstläufer. Umso überraschender, wenn dabei doch noch jemand wirkliche Innovation oder zumindest neue Funktionen bieten kann. Amazon zündete letztes Jahr im November ein verfrühtes Silvesterfeuerwerk und veröffentlichte seinen Virtualisierer namens Firecracker [1] unter einer Open-Source-Lizenz. Bisher ist das Tool vor allem die Triebfeder hinter dem AWS-Dienst Lambda, bei dem es simple Virtualisierung kleiner VMs ermöglicht. Doch Firecracker kann viel mehr als das – und schickt sich an, sogar Containern das Wasser abzugraben.

Gleichwohl stehen zuerst einige grundsätzliche Fragen im Raum: Warum setzt man bei Amazon für simple Virtualisierung nicht einfach auf Container, so wie der Rest der Welt? Und wenn es Vollvirtualisierung sein soll, warum nimmt Amzon dann nicht die erprobte Kombination aus KVM und Qemu? Handelt es sich am Ende nur um einen besonders krassen Fall von “Not invented here”? Wer zu diesem Fazit kommt, macht es sich sicherlich zu leicht. Zur Aufklärung ist es nützlich, sich mit der Geschichte der Virtualisierung unter Linux zu beschäftigen.

Xen als Platzhirsch

Vor etwas mehr als zehn Jahren war die Virtualisierungswelt unter Linux noch eine völlig andere als heute. Für Technikrelationen sind zehn Jahre bekanntlich ohnehin eine lange Zeit, wer damals unter Linux virtualisieren wollte, setzte entweder auf proprietäre Containerlösungen wie Open VZ oder VMware oder griff gleich zu Xen.

Tatsächlich war Xen (Abbildung 1) damals der einzige freie Hypervisor, der für Linux als “Enterprise ready” gelten konnte und dieses Label tatsächlich verdiente. Doch 2005 hatte sich Avi Kivity bei Qumranet darangemacht, die Xen-Dominanz zu brechen, und werkelte im stillen Kämmerlein an jener Lösung, die später als KVM berühmt werden sollte (und die übrigens für Firecracker ebenso unerlässlich ist).

Abbildung 1: Xen war der Branchenprimus in Sachen Virtualisierung unter Linux, setzte aber lange einen Kernel voraus, der so alt war wie dieser Screenshot.

Viele waren aber auf Xen festgelegt. Was damals als gar nicht so riesige Herausforderung wahrgenommen wurde. Denn anders als heute hatte Virtualisierung keinen sonderlich hohen Stellenwert. In den gängigen CPUs etwa fanden sich ganz zu Anfang auch keine Sonderfunktionen für Virtualisierung wie VT-d bei Intel heute. Wer damals Setups bauen wollte, der plante diese auf echtem Blech.

Allerdings war absehbar, dass das nicht auf ewig so bleiben würde. Denn von anderen Betriebssystemen war das Prinzip der Virtualisierung ja bekannt, und langsam kristallisierte sich auch heraus, dass neue Hardware viel zu potent sein würde, um sie mit einer einzelnen Applikation auszulasten. Oder anders formuliert: Die Hersteller begannen nach und nach, Hardware für den Einsatzzweck Virtualisierung zu entwerfen.

Alter Wein

Xen geriet derweil in ernste Schwierigkeiten. Weil die Entwickler nach damaligen Standards vorgingen, patchten sie viel am Linux-Kernel herum, damit der Paravirtualisierer mit Linux weiterhin funktionieren konnte. Das ging so weit, dass Linux-Entwicklung und Xen-Kernel bald divergierten: Immer neue Kernelversionen kamen auf den Markt, doch etliche Jahre war man mit Xen unter Linux auf die Version 2.6.18 festgenagelt.

Und daran, Xen in den Upstream-Kernel zu integrieren, war nicht zu denken: Linux-Vater Torvalds hatte etliche Male kundgetan, dass er zuvor eine standardisierte Schnittstelle für Virtualisierer im Linux-Kernel haben wollte, eine Technik, die heute unter dem Label “PVops” firmiert. KVM setzte von Anfang an auf jene Schnittstelle, Xen musste in weiten Teilen vollständig neu geschrieben werden, um sie zu verwenden.

So begann KVM seinen Siegeszug und etablierte sich als Standardlösung für Virtualisierung unter Linux. Wobei es hier wichtig ist, penibel auf die Begriffe zu achten. Denn KVM ist kein Virtualisierer, sondern viel mehr ein Hypervisor, der im Linux-Kernel existiert und zur Außenwelt hin eine Schnittstelle für die Nutzung von Virtualisierungsfeatures bietet (»/dev/kvm«). Wer sagt, dass er “mit KVM unter Linux virtualisiert”, unterschlägt dabei in der Regel die zweite Komponente, die zu diesem Gespann gehört: Qemu (Abbildung 2).

Abbildung 2: KVM löste in Kombination mit Qemu zwar Xen als freien De-facto-Standard ab, an vielen Stellen ist Qemu jedoch langsam und behäbig.

Weil Avi Kivity klar war, dass ein Hypervisor ohne passenden Emulator nutzlos wäre, patchte er das bereits existierende Qemu seinerzeit entsprechend. Zuvor musste Qemu echte Vollvirtualisierung betreiben, danach konnte es zumindest im Stil der Paravirtualisierung auf die Features der Host-CPU zugreifen. Später gaben die Entwickler KVM noch Paravirtualisierung für den Netzwerk- und Storage-Treiber mit auf Weg – und fertig war ein überzeugendes Gesamtpaket, das sich dann auch über viele Jahre als Standard etablierte.

Viel Overhead

Nun ist allerdings nicht alles Gold, was im Land der Linux-Virtualisierung glänzt. Eine große Herausforderung auf der KVM-Seite war etwa die Frage, wie virtuelle Maschinen sich auf einem Host verwalten lassen. Woher weiß eine Qemu-VM mit KVM-Anbindung etwa, wo die Root-Festplatte mit ihrem Hauptdateisystem liegt? Und wie wird es möglich, die quälend langen CLI-Befehlszeilen für Qemu automatisch zu generieren, damit der Nutzer sie sich nicht merken muss? Schnell entwickelte sich die Libvirt zu einer weiteren wichtigen Komponente, die auf einem Linux-KVM-System nicht fehlen durfte.

Doch während solche Probleme einigermaßen leicht in den Griff zu bekommen waren, sind andere praktisch unlösbar. Eines davon ist, dass virtuelle Maschinen auf Basis von KVM und Qemu selbst dann einen gewaltigen Overhead erzeugen, wenn sie fast nichts tun. Paravirtualisierung hat diesen Effekt gelindert, ihn abschaffen konnte sie aber nicht.

Das geht schon damit los, dass Qemu ein eigenes Bios emuliert, aus Rücksicht auf verschiedene Betriebssysteme (meistens aus Redmond), die ohne Bios den Dienst komplett verweigern. Das setzt sich fort damit, dass Paravirtualisierung eben nicht für alle Hardwarekomponenten in KVM zur Verfügung steht, sodass der Qemu-Prozess Anforderungen zwischen physischem Host und virtuellem Gast auf sehr CPU-lastige Art und Weise übersetzen muss.

Und dann gibt es freilich noch das Problem, dass jede virtuelle Maschine ein eigenes System darstellt, das gehegt, gepflegt und gewartet werden möchte. Das ist indes gerade bei Qemu eher kompliziert, weil der Admin es meist mit installierten Systemen zu tun hat, die sich nicht einfach durch frische Kopien aus der Dose ersetzen lassen.

KVM-Dämmerung

Das Aufkommen der großen Cloudumgebungen wie Open Stack [2] bescherte KVM in Kombination mit Qemu unter Linux einen zweiten Frühling. Zwar waren auch Anbieter wie VMware darauf aus, möglichst schnell Kompatibilität jener Lösungen mit ihren proprietären Produkten zu erreichen. Doch weil KVM bereits zu Beginn der Open-Stack-Entwicklung unter Linux zur Verfügung stand, war es auch der erste Virtualisierer, der mit Open Stack vollumfänglich kooperierte (Abbildung 3).

Abbildung 3: Die Desktop-Applikation Virtmanager für das Verwalten virtueller Maschinen ist ein weiterer Puzzelstein, der zum KVM-Erfolg beigetragen hat.

Heute gilt KVM als integraler Bestandteil von Open Stack, auch wenn es eigentlich aus externen Quellen beigesteuert wird. Die meisten Open-Stack-Clouds dürften zudem ausschließlich auf KVM setzen, weil andere Hypervisoren wie etwa Microsofts Hyper-V erst deutlich später unterstützt wurden.

Dann allerdings passierte etwas, mit dem in der Community wohl niemand gerechnet hatte: Docker schwang sich auf, Container in Linux wiederzubeleben (Abbildung 4). Zweifellos haben Container manchen Vorteil gegenüber ihren behäbigen Pendants auf Seiten der Vollvirtualisierer: Sie benötigen wirklich nur jene Dateien, die die in ihnen gehostete Applikation braucht, und nicht ein komplettes Linux-System. Sie brauchen keinen eigenen Kernel, sondern nutzen den Host-Kernel. Sie brauchen kein Bios und es findet auch keine klassische Virtualisierung statt, sodass sich der Kernel das Übersetzen zwischen Host und VM erspart.

Abbildung 4: Container ersetzen den Hypervisor durch eine Container-Engine und benötigen kein separates OS – effizient, aber nicht unbedingt sicher.

Als sich zu Docker Kubernetes gesellte, war spätestens klar, dass der Containeransatz das Potenzial hat, die IT erneut grundlegend zu verändern (der Artikel zum Cloud-Native-Prinzip in diesem Heft erklärt dies detailliert). Plötzlich waren Container als Lösung gesetzt und manche Admins rümpften gar die Nase, wenn die Sprache auf KVM kam. Denn das sei träge und in den meisten Fällen auch unnötig – eben weil Container praktisch alle Funktionen bieten.

Das ist aber nur die halbe Wahrheit. Der Hype, den Lösungen wie Docker, Kubernetes oder Swarm losgetreten haben, versperrt den Blick auf Herausforderungen, die mit Containern einhergehen.

Was bei Containern fehlt

Denn manche Eigenschaften von Containern machen diese eher ungeeignet für bestimmte Einsatzbereiche. Was etwa sofort auffällt, ist, dass es innerhalb von Containern keine freie Betriebssystemwahl gibt. Man kann sich zwar zwischen verschiedenen Distributionen entscheiden, aber Linux ist gesetzt – eben weil der Kernel des Hosts die Arbeit erledigt. Selbst wer ein Linux nutzt, hat keine wirklich freie Wahl: Appliances wie etwa die diversen Router- oder Firewall-Systeme bräuchten ebenfalls eine speziell an Docker angepasste Version, um zu funktionieren.

Ein zweiter, nicht minder wichtiger Faktor betrifft das Thema Sicherheit. Ein Alptraum in jedem Virtualisierungsszenario ist es, wenn es Angreifern gelingt, aus einer virtuellen Maschine auszubrechen. Denn dann haben sie nicht nur Zugriff auf das physische System, sondern im schlimmsten Fall auch noch auf andere virtuelle Systeme, die auf demselben System laufen.

In Umgebungen wie Open Stack finden sich auf einem physischen Host meist VMs etlicher Kunden. Hier ist die Katastrophe im Falle eines erfolgreichen Angriffs also besonders groß. Grund genug für KVM und das von den Toten wiederauferstandene Xen, eine Vielzahl von Mechanismen zu nutzen, um solche Ausbrüche zu erschweren oder unmöglich zu machen.

Bei den Containern gibt es entsprechende Funktionen zwar auch – am Ende nutzen Container unter Linux ja sogar viele Kernelfeatures, um die Trennung zwischen Container und Host sowie Container und Container zu erreichen. Diese Funktionen sind jedoch kaum vergleichbar mit den zur Abschottung von VMs vorhandenen Features in Linux.

Eng verbunden mit dem Thema Sicherheit bei Containern ist das Thema Isolation. Ein krasses Beispiel ist der Netzwerktraffic: Bei Containern hängt die Art der Isolation völlig von der genutzten Containersoftware und gegebenenfalls auch noch vom Orchestrierer ab. Docker setzt ab Werk beispielsweise auf Netzwerk-Namespaces und Cgroups, was eine gute Lösung darstellt. Bei VMs geht die Isolation noch einen Schritt weiter: Jede virtuelle Maschine hat eine eigene virtuelle Netzwerkkarte, die beim Einsatz von Lösungen wie Open Vswitch SDN-seitig mit zusätzlichen Features in Sachen Isolation versehen ist.

Relevant ist das Thema Isolation auch bei der Beschränkung von Ressourcen: Läuft eine Applikation in einem Container Amok, etwa weil jemand sie vorsätzlich angreift (DDoS), zieht das mit hoher Wahrscheinlichkeit auch alle anderen Container des Hosts in Mitleidenschaft. Echte Hypervisoren wie KVM haben hingegen wirksame Schutzmechanismen implementiert: Sind einer virtuellen Maschine nur begrenzte Mengen an RAM und CPU zugewiesen, darf sie auch nur eben jene nutzen. Erhöhten Verbrauch unterbindet KVM im Kernel.

Wohlgemerkt: Für Container gibt es durchaus Möglichkeiten, etwa Cgroups, um die Verwendung bestimmter Ressourcen ebenfalls zu begrenzen. Viele Lösungen unterstützen die aber gar nicht erst – oder die Admins vergessen, sie zu nutzen, weil sie die implizite Sicherheit von KVM & Co. noch gewohnt sind. Und obwohl es heute bei Containerlösungen entsprechende Funktionen gibt, sind diese meist eben doch nicht so umfassend wie bei KVM oder Xen.

Sinnvoll wäre darum eine Virtualisierungslösung, die die Sicherheit und Isolation echter VMs mit der Leichtfüßigkeit von Containern kombiniert. Genau hier kommt Firecracker von Amazon ins Spiel – denn es verspricht genau diese Kombination.

Der technische Unterbau

Dass Amazon mal eine in seiner AWS-Umgebung eingesetzte Eigenlösung unter eine quelloffene Lizenz stellt und veröffentlicht, kommt gar nicht so oft vor. Im Falle von Firecracker ergibt das Vorgehen aber durchaus Sinn, denn Firecracker ist mit einer anderen Open-Souce-Technik eng verbunden: KVM.

Seit einiger Zeit bietet Amazon im Rahmen von AWS auch seinen Dienst Lambda (Abbildung 5) an. Der soll Nutzern simple virtuelle Maschinen auf magerer virtueller Hardware zur Verfügung stellen, die im Gegensatz zu den klassischen AWS-Instanzen aber auch deutlich billiger sind.

Abbildung 5: Amazons Lambda-Dienst war die Inspiration für Firecracker: Der Dienst führt auf Zuruf bestimmte Programme aus, um Daten zu verarbeiten.

Auf Container wollte Amazon bei diesem Produkt aber offensichtlich nicht setzen – der Hersteller erläutert, dass ihm die Sicherheits- und Isolations-Funktionen der gängigen Containerumsetzungen in Linux nicht überzeugen. KVM auf der anderen Seite war als Virtualisierer von der Stange viel zu schwergewichtig; produziert KVM pro VM 20 Prozent Overhead, ist das angesichts der Mengen, die AWS verkauft, gleich eine riesige Summe. Die Lösung lag aus Amazon-Sicht auf der Hand: Wenn es gelänge, die Funktionen von KVM ohne den Overhead des Qemu-Emulators zu nutzen, wäre das eigentlich die perfekte Kombination.

Nochmals: Ein großer Teil des Overhead bei KVM wird gar nicht durch KVM selbst verursacht, sondern durch die Art, wie Qemu funktioniert. Zwar haben Avi Kivity und sein Team Qemu nach und nach an KVM angepasst und es für die Nutzung mit KVM optimiert. Verschiedene Themen, etwa die Ressourcennutzung, sind bei Qemu aber Design-seitig so tief verwurzelt, dass es ohne Rewrite unmöglich ist, die damit verbundenen Engpässe zu beseitigen. Als Amazon Firecracker in den Ring schickte, stellte die Firma aus Seattle also einen potenten Konkurrenten für Qemu vor, keinen Ersatz für KVM.

Abgeschaut

Firecracker ist definitiv kein hundertprozentiges Amazon-Eigengewächs. Der Hersteller gründet seine Arbeit auch auf vorangegangene Arbeiten, etwa die von Googles Chromium-Team. Selbst der Ansatz ist nicht komplett neu, denn auch die Kata Containers [3], die aktuell selbst eine Art Mini-Hype ausgelöst haben, folgen einem ähnlichen Schema. Zweifellos dürfte Amazon aber die Firma sein, die eine solche Lösung bereits produktiv auf einer großen Zahl von Systemen einsetzt. Logisch – wer hat, der kann.

Technisch betrachtet besteht Firecracker aus mehreren Komponenten. Da ist zunächst die eigentliche Kernkomponente, ein eigener Hypervisor, der direkt auf der KVM-Implementierung des Kernels aufbaut. Im Handstreich nimmt dieser so alle Vorteile mit, die KVM bietet: Paravirtualisierung für einzelne Geräte in den virtuellen Maschinen oder direkten Zugriff auf die CPU, um deren Virtualisierungsfunktionen zu nutzen. Wer in KVM und Qemu bisher mit »virtio-net« oder dem paravirtualisierten Virtio-Plattentreiber gearbeitet hat, kennt die Vorteile dieses Ansatzes zur Genüge.

Unter der Haube basiert der Hypervisor in Firecracker auf Crosvm, das der Entwicklung des Chrome-Browsers entspringt. Wie Crosvm ist deshalb auch Firecracker in Rust geschrieben.

Der Jailer sorgt für Sicherheit

Dem eigentlichen Hypervisor steht eine Komponente namens Jailer zur Seite, die sich umfassend um das Thema Sicherheit kümmert. Einerseits startet die Jailer-Komponente die eigentliche Firecracker-Applikation, die minimale virtuelle Maschinen auf Basis des Hypervisors aus dem Boden stampft.

Zugleich legt Jailer den verschiedenen Komponenten des Stack aber Handschellen an: Er konfiguriert Cgroups und Kernel-Namespaces, um gleich von vornherein festzulegen, worauf die VM überhaupt zugreifen kann. Per Seccomp-Filter schränkt Jailer die Berechtigungen einer Firecracker-VM weiter ein. Und weil das noch nicht reicht, entzieht Jailer VMs dynamisch auch Zugriffsrechte oder weist sie im Bedarfsfall zu.

Das ist eine ganze Menge Sicherheit und durchaus auf der Höhe der Zeit – hier wird allerdings auch offensichtlich, dass Amazon zumindest teilweise das Rad neu erfunden hat: Ein leistungsfähiges Framework zur Verwaltung virtueller Maschinen steht für Linux schließlich schon zur Verfügung, nämlich die Libvirt. Und die hätte sich sehr wahrscheinlich bei Bedarf um vergleichbare Funktionen erweitern lassen.

Ein echtes Novum ist hingegen das Restful-API, das ebenfalls zu Firecracker gehört. Fast möchte an meinen, das sei absolut erwartungsgemäß. Eine heute neu entwickelte Applikation kann sich ohne Restful-API mit Steuerfunktion ja kaum noch aus dem Haus trauen. Fernab von hipper Entwicklung und modernen Paradigmen hat das Firecracker-API bei Amazon aber auch ganz praktischen Nutzen: Darüber startet der Anwender unmittelbar Firecracker-VMs.

Libvirt bietet eine ähnliche Fernsteuerungsfunktion zwar auch, aber nicht per Restful-API. Und weil die Cloud heutzutage in jeder Hinsicht das Maß der Dinge ist, erscheint es wichtig, dass sich Technik mit typischen Cloudwerkzeugen steuern lässt. Ein API nach dem REST-Prinzip garantiert genau das.

Kein Drop-in-Ersatz

Wer bis hierhin den Eindruck gewonnen hat, Firecracker sei eigentlich nur ein schlankerer Ersatz für Qemu und Libvirt, liegt falsch. Zwischen den Lösungen gibt es erhebliche Unterschiede, und die werden auch sehr schnell offensichtlich. So lässt sich in Firecracker etwa nicht jede Distribution einfach so starten. Stattdessen braucht der Nutzer ein spezielles Kernelpaket und ein Root-Dateisystem, beides stellt Amazon aktuell als einziger Anbieter zur Verfügung.

Es handelt sich um ein Alpine Linux, also nicht um eine der gängigeren Distributionen. Wenn Firecracker mehr Verbreitung erlangt, werden die Firecracker-Packs anderer Hersteller aber nicht sehr lange auf sich warten lassen. Das ist übrigens laut Amazon explizit auch ein Grund dafür, die Lösung jetzt als Open-Source-Software zu veröffentlichen: Zusammen mit der Community möchte der Hersteller Firecracker nicht nur weiterentwickeln, sondern es auch aufhübschen und es auf das Fundament einer großen Entwicklergemeinde stellen.

Firecracker kann nur wenige virtuelle Geräte in die VM durchreichen, etwa eine virtuelle Netzwerkkarte, den virtuellen Blockgeräte-Treiber sowie eine serielle Konsole zum Abfangen von Ausgaben und eine Tastatur, die aber nur eine Taste hat und Notfallzwecken dient.

Die reduzierte Herangehensweise von Firecracker zahlt sich aus: Amazon rechnet vor, dass der Alpine-Kernel samt Root-Dateisystem in 125 Millisekunden zu einer lauffähigen VM führt, die ein vollwertiges Linux-System darstellt. Da kann Qemu in der Tat nicht mithalten – schon die Linux-Distributionen, die als komplettes System im Gespann aus Qemu und KVM üblicherweise starten, benötigen ein Vielfaches dieser Zeit. Selbst das Bios, das Qemu emuliert, braucht schon mehr Zeit zum Laden. Die Operation “Schlanke VM” ist Amazon also ganz offensichtlich gelungen.

Für wen?

Stellt sich freilich noch die Frage, für wen außer Amazon sich Firecracker noch eignet. Der Konzern gibt hier einen Tipp: Auch und besonders wolle man Firecracker all jenen Menschen ans Herz legen, die sich andernfalls für die Virtualisierung per Container entschieden hätten. Offenbar sieht Amazon hier eine Art Doppelvirtualisierung vor: VMs in Firecracker sollen die Basis etwa für Docker sein. Dann könnten Nutzer die Vorteile von Firecracker und echter Containervirtualisierung kombinieren: minimaler Overhead, aber exakt dieselbe Isolation und Sicherheit, die auch Qemu im Vergleich böte.

Noch fehlt dazu allerdings einiges. Eine Integration von Firecracker in andere Lösungen wie Open Stack gibt es aktuell schlicht noch nicht. Das Mindeste wäre ein »nova-compute-firecrack«. Unwahrscheinlich allerdings, dass Amazon das entwickeln wird, schließlich machte man sich dann indirekt selbst Konkurrenz in Sachen Cloud. Hier wäre also die Community gefragt. Falls sich Firecracker als nützlich und hilfreich erweist, ist aber auch nicht völlig ausgeschlossen, dass einer der großen Linux-Distributoren in die Bresche springt.

Fazit

Ein erstes Fazit zu Firecracker lautet entsprechend: Coole Sache, die aber im Alltag gerade im produktiven Umfeld noch nicht sinnvoll nutzbar ist. Es wird zu großen Teilen von der Akzeptanz der Community und der Integration in andere Lösungen abhängen, ob Firecracker langfristig erfolgreich sein kann. Leider ist nämlich auch nicht auszuschließen, dass Amazon der Lösung am Ende wieder den Garaus macht und doch auf Kata Containers oder eine ganz andere Lösung setzt, falls die vorgesehene Verankerung in der Community nicht recht gelingt.

Wer sich für Virtualisierung interessiert und eine leichtfüßige Alternative zu Qemu sucht, sollte sich Firecracker aber im Detail anschauen.