Nehmen Sie Firecracker-Mikrovirtuals auf. Wir verwenden zwei beliebte Methoden zum Isolieren von Mehrbenutzer-Workloads - virtuelle Maschinen und Container. Wir drücken das Beste aus beiden Ansätzen aus, vereinfachen so viel wie möglich und testen auf einer echten Hochlast. Als Ergebnis erhalten wir eine undurchdringliche Isolation von virtuellen Computern, die in Hunderten von Millisekunden gestartet werden können. Diese Lösung funktioniert unter der Haube von AWS Lambda und Fargate und führt jede Sekunde Millionen von Funktionen und Containern ohne Server in der Cloud aus. Es heißt Kracher.
Dieses Mikrovirtualisierungstool ist in
OpenSource verfügbar. Wenn Ihre Aufgaben eine Mandantenisolation erfordern (z. B. wenn Sie sich für die Erstellung einer eigenen Cloud entscheiden), ist Firecracker genau das Richtige für Sie.
Vasily Pantyukhin , Architekt von Amazon Web Services, spricht über die Firecracker-Architektur, wie sie von AWS Lambda verwendet wird, vergleicht sie mit alternativen Lösungen und gibt Beispiele für die Integration.
Haftungsausschluss: Alles, was unten steht, ist Vasilys persönliche Meinung und stimmt möglicherweise nicht mit der Position von Amazon Web Services überein.Natürliche Merkmale öffentlicher Wolken
Eine der grundlegenden Eigenschaften von Public Clouds ist die Mandantenfähigkeit.
Jemand übersetzt diesen Begriff als "Mandantenfähigkeit" oder "Mehrbenutzerumgebung". Aus meiner Sicht spiegelt dies jedoch nicht das Wesentliche wider. Mandantenfähigkeit ist, wenn verschiedene Benutzer und ihre Lasten in derselben physischen Infrastruktur leben, diese untereinander teilen, aber nichts voneinander wissen. Bei Mehrbenutzer-Workloads unterscheidet sich die Mandantenfähigkeit durch grundlegend strengere Anforderungen an die Ressourcenisolierung und den Zugriff auf diese.
Eine weitere Eigenschaft, die öffentlichen Clouds innewohnt, ist die Hochlast.
Glauben Sie mir, im Fall von AWS ist dies eine enorme Belastung! Der Screenshot ist ein Beispiel für reale Daten. Ich werde nicht sagen, wie lange und in welcher Region diese Millionen von "Papageien" gemessen wurden, aber dies ist kein Notfall, sondern die für uns übliche Betriebsart.
Es stellt sich ein gewisser Widerspruch heraus. Einerseits müssen wir die Benutzer so isoliert wie möglich halten. Andererseits müssen wir ein sehr hohes Maß an Produktivität und Ressourcennutzung sicherstellen. Die Verbesserung des einen führt oft zu den Einschränkungen des anderen. Wie kann man einen Kompromiss finden und noch besser, um an allen Fronten das Maximum zu erreichen?
Virtuelle Maschinen oder Container?
Es gibt zwei grundlegende Ansätze, die möglicherweise helfen könnten. Dies sind virtuelle Maschinen und Container. Jeder hat seine Vor- und Nachteile.
Der Hauptnachteil virtueller Maschinen besteht darin, dass das
Laden lange dauert . Normalerweise dauert es einige zehn Sekunden oder sogar Minuten, um die Maschine zu starten. Aber Virtualoks haben eine Tugend - sie
isolieren Betonlasten voneinander. Und aus beiden Blickwinkeln:
- Sicherheit, wenn eine virtuelle Maschine nicht auf Daten in einer anderen Maschine zugreifen kann;
- Ressourcen , als ich 8 GB Speicher bestellt habe, hoffe ich, dass dieser RAM mir gehört und niemand die Ressource beanspruchen kann, für die ich bezahlt habe.
Das Gegenteil ist bei Containern der Fall: Sie sind leicht und
laden daher
sehr schnell. Sie können leicht horizontal skaliert werden. Es gibt jedoch eine Funktion, mit der wir als öffentlicher Cloud-Anbieter nicht leben können. Sie verwenden einen
gemeinsam genutzten Kernel - der Betriebssystemkernel wird von allen Containern gemeinsam genutzt .
Kann man sagen, dass Container unsicher sind? Nein, obwohl es schwerwiegende Sicherheitslücken gibt.
Ich glaube, dass ein ordnungsgemäß „geschweißter“ Behälter heute ein ausreichendes Maß an Sicherheit bietet.
Das Problem ist anders: Ein gemeinsam genutzter Kernel garantiert nicht grundsätzlich, dass irgendwann in der Zukunft keine Schwachstellen auftreten, die die Isolation der Mandanten aufheben. Die öffentliche Cloud kann es sich nicht einmal theoretisch leisten.
Es gibt noch einen weiteren Widerspruch, und es muss nach einer Lösung gesucht werden. Der einfachste Weg ist, das Beste von Mama - einer virtuellen Maschine - und von Papa - einem Container - zu nehmen, zu kreuzen und etwas
Konvergentes zu bekommen . Eigentlich haben wir es geschafft. Es stellte sich heraus, Kracher.
Kracher ist bereits in Produktion. In der gleichen Menge kritischer Dienste, zum Beispiel AWS Lambda (Serverless-Funktionen) und AWS Fargate (Serverless-Container).
Probleme des alten AWS Lambda
AWS Lambda ist ein Serverless Feature Service. Wir übernehmen die Funktion in Java, Go, Python oder einer anderen Sprache, wir werfen sie in Lambda und sie wird magisch ausgeführt. Es ist nicht erforderlich, Ressourcen zuzuweisen und zu verwalten. Wie wurde das vorher umgesetzt?
Für jedes AWS-Konto wurden eine oder mehrere separate virtuelle EC2-Maschinen zugewiesen, um Funktionen zu isolieren, die verschiedenen Mandanten gehören. Eine solche virtuelle Maschine verbraucht Ressourcen, selbst wenn sie nichts tut. Angenommen, wir führen eine Funktion alle 10 Minuten einmal aus und sie wird in 200 ms wie ein normaler Lambda ausgeführt. Es stellt sich heraus, dass die EC2-Maschine innerhalb einer Stunde nur wenige Sekunden benutzt wird. Darüber hinaus verbraucht es auch zur Laufzeit nicht alle verfügbaren Ressourcen - Entsorgung unterhalb der Fußleiste. Das ist wütend unrentabel.
Wie haben Sie das Recyclingproblem gelöst?
Entwickelte von Grund auf ihre eigene Firecracker-Lösung. Dies geht aus dem Titel des Berichts hervor :)
Um mit der Entwicklung eines neuen Produkts zu beginnen, benötigen Sie eine technische Aufgabe. Es enthält viel Text, aber wenn Sie nur die Bedeutung auswählen, erhalten Sie Folgendes.
- Unterstützt von KVM als Hypervisor. Wer mit AWS arbeitet, weiß, dass wir zwei Lieblingshypervisoren haben. Legacy-VMs werden unter Xen ausgeführt. Seit Ende 2017 lebt KVM unter der Haube aller Autos.
- Es beginnt so schnell wie möglich. Auf der Referenzhardware war die Anforderung eine volle Auslastung des Mikrovirtuals in 125 ms.
- Minimaler Virtualisierungsaufwand . In der Referenzarchitektur verbraucht eine einzelne mikro-virtuelle Firecracker-Maschine zusätzlich nur 5 MB Speicher.
- Die Möglichkeit des dichtesten Starts . Designparameter - volle Last von 5 Mikrovirtualen pro Kern pro Sekunde. Diese Anforderung ist für Dienste wie AWS Lambda von grundlegender Bedeutung. Funktionen müssen schnell abheben, trainieren und sterben, um Ressourcen für die nächsten freizugeben.
- Die Möglichkeit einer erneuten Anmeldung . Es ist eine Gelegenheit - es ist nicht notwendig, sie zu nutzen. Tatsächlich ist dies die Zuweisung virtueller Ressourcen in größerem Umfang, als sie physisch verfügbar sind. Dies bedeutet, dass der Server über 16 GB RAM verfügt und Sie gleichzeitig 4 virtuelle Maschinen ausführen, von denen jede sicher ist, dass er über 8 GB Arbeitsspeicher verfügt.
AWS Lambda mit Kracher unter der Haube
Was hat sich in der neuen Version von AWS Lambda geändert? Aus Sicht des Endbenutzers hat sich nichts geändert. Die Migration zu einer aktualisierten Architektur in der Produktion war vollständig transparent und für die Verbraucher unsichtbar. Lambda-Funktionen sind von kurzer Dauer - das war einfach.
Wie sieht moderne Architektur aus?
Auf der untersten Ebene befindet sich jetzt keine virtuelle Maschine, sondern ein physisches Bare-Metal.
Solche Server ermöglichen die vollständige Nutzung aller Funktionen der CPU, beispielsweise Intel VT. Dies bietet zusätzliche Vorteile bei Verwendung der Virtualisierung auf höheren Ebenen.
Auf dem Stück Eisen befindet sich das
Host-Betriebssystem mit dem KVM-Modul im Kernel.
Firecracker- Mikrovirtuals mit eigenen
Gastbetriebssystemen werden oben gestartet. Nun, sie haben bereits Komponenten des AWS Lambda-Service selbst implementiert.
Bisher haben wir für jeden Kunden, der die Lambda-Funktionen verwendet, separate virtuelle EC2-Maschinen mit geringer Auslastung zugewiesen. Mit dem neuen Ansatz können Sie ein leichtes Mikrovirtual nur dann ausführen, wenn Sie es wirklich benötigen. Durch das Isolieren von Firecracker-Ressourcen voneinander können wir dies auf einer gemeinsamen Hardware mit maximaler Dichte tun. Die Ressourcennutzung hat sich grundlegend verbessert.
Was ist in der Box?
Ich habe Anboxing versprochen, also gehen wir die Hauptkomponenten von Firecracker durch, betrachten sie einzeln und setzen dann alles zusammen.
Gestaltungsprinzipien
Als wir zum ersten Mal über die Entwicklung von Firecracker diskutierten, waren wir uns einig, zwei Prinzipien einzuhalten.
Alles Unnötige loswerden. Warum wurden klassische virtuelle Maschinen langsam geladen? Insbesondere, weil der Code überladen ist. Sie müssen eine Vielzahl von Legacy-Geräten unterstützen. Aber warum ein Gerät emulieren, das vor 10 Jahren noch niemand benutzt hat? Es besteht keine Notwendigkeit, deshalb werden wir alles überflüssige los. Wir lösen eine bestimmte enge Aufgabe, und alle Funktionen, die zur Lösung dieses Problems nicht beitragen, werden als unnötig angesehen.
Befreien Sie sich von allem Überflüssigen und konzentrieren Sie sich auf eine Aufgabe.
Vereinfachen Sie, was noch übrig ist. Auch was übrig bleibt, sollte so einfach wie möglich sein.
Worüber haben sie geschrieben?
Firecracker ist in trendigem Rust geschrieben, weil:
- Sie können damit sichereren Code schreiben, insbesondere in Bezug auf den Speicher.
- Leistung und Overhead sind vergleichbar mit modernem C ++;
- Rust wird seit langem verwendet und hat seit 2015 viele coole Hochlastlösungen geschrieben.
Eisen
Ich wiederhole - Firecracker erfordert die Installation auf echter Hardware. Als Referenzkonfiguration wurde die Bare-Metal-Maschine i3.metal gewählt.
Hinweis: Der Bericht wurde Anfang April 2019 erstellt. Zu diesem Zeitpunkt wurde nur die Intel-Plattform unterstützt. Im Mai wurde die Alpha-Unterstützung für AMD und im Juni für ARM hinzugefügt. AMD ist möglicherweise etwas billiger als Intel, und der ARM-Support bietet interessante Möglichkeiten für die Arbeit mit IoT mit mehreren Mandanten.Wenn Sie eine i3.metal- oder andere Bare-Metal-Maschine in AWS bestellen, ist diese für Experimente zu leistungsfähig und zu teuer. Wenn Sie sich entscheiden, Firecracker darauf zu installieren, vergessen Sie daher nicht, diese Maschinen nach den Experimenten auszuzahlen. Andernfalls wird am Ende des Monats eine anständige Punktzahl erzielt.
Gibt es eine günstigere Option? Ja, Sie können Firecracker in einer virtuellen Umgebung starten. Aber nicht mehr in AWS - wir unterstützen verschachtelte Virtualisierung auf EC2 grundsätzlich nicht. Sie können dies jedoch in GCP, Azure, DigitalOcean oder mit Proxmox, Parallels und VMware Fusion tun. Alles funktioniert, wenn Sie die Anforderungen einhalten, insbesondere entsprechend der Kernel-Version des Gastbetriebssystems.
Der Kern
Das grundlegende Element der Lösung ist das KVM-Kernelmodul.
Nur für den Fall, ich werde als Exkurs beschreiben, was KVM ist. Dies ist nicht der gesamte Hypervisor, sondern nur ein Teil davon. Die Hauptaufgaben bestehen darin
, einen virtuellen Prozessor (vCPU)
einzurichten und
eine virtuelle Maschine zu starten .
Für eine vollwertige Arbeit reicht dies jedoch nicht aus. Neben dem Prozessor werden einige andere Geräte benötigt. Ihre Emulation erfolgt im User Space.
VMM
Damit mindestens grundlegende Geräte angezeigt werden, benötigen Sie eine andere Komponente - Virtual Machine Manager (VMM). Vor Firecracker war QEMU die primäre VMM-Option.
Wir haben ernsthaft über die Möglichkeit nachgedacht, QEMU zu verwenden, aber beschlossen, unser eigenes „Fahrrad“ zu entwickeln. Dafür gab es mehrere Gründe.
Entwicklungsmanagement . QEMU ist ein großes, ausgereiftes Produkt mit über einer Million Codezeilen. Um Änderungen vorzunehmen, müssen Sie zu viele Quellcodes anzeigen. Viele Menschen beteiligen sich an der Entwicklung und Entscheidungsfindung bei der Entwicklung.
Sicherheit QEMU kann viele Geräte emulieren. Deshalb hat es eine ziemlich große Angriffsfläche. Unsere Aufgabe ist es, ein Mikrovirtual zu machen. Aus Sicherheitsgründen müssen wir die Angriffsfläche minimieren.
Die Notwendigkeit, neue Funktionen zu implementieren. QEMU hat guten Code. Dies ist ein ausgereiftes Produkt, in dem alle offensichtlichen Fehler bereits erkannt wurden. In der jetzigen Form passte die QEMU-Funktionalität jedoch immer noch nicht zu uns - wir müssten viel hinzufügen. Unter diesem Gesichtspunkt hätte der neue Code in QEMU und im neuen Produkt die gleiche Qualität. Daher würde ein besonderer Gewinn nicht funktionieren.
Geräte
Firecracker implementiert VMM, mit dem Geräte emuliert werden. Wir emulieren folgende Geräte:
- Konsole Eine nützliche und notwendige Sache, obwohl sie ausgeschaltet werden kann.
- Tastatur Wir haben eine knifflige Tastatur erstellt - mit nur einer "Reset" -Taste. Wir vertrauen einfach nicht der Software "Reset" der Betriebssysteme, die möglicherweise in Firecracker ausgeführt werden könnten. Deshalb machten sie Eisen.
- Virtio-Treiber für Festplatte und Netzwerk . Virtio ist ein sehr primitives Gerät. Im Wesentlichen ist dies ein "Ringpuffer". Das Gastsystem hat etwas in den Puffer geschrieben, auf den Aufruf geklickt und das Hostsystem hat die Daten aus diesem Puffer durch eine Datei gelesen.
In einigen Fällen, zum Beispiel für die Integration in Container, benötigen wir noch ein Netzwerkgerät, das die Grundfunktionalität einer normalen Netzwerkkarte darstellt. Virtio passt hier nicht, zu einfach. Daher verwenden wir für das Netzwerk ein anderes Gerät -
Vsock .
Nun, wir brauchen auch die Fähigkeit, den Ressourcenverbrauch zu kontrollieren. Der
Ratenbegrenzer ist dafür verantwortlich.
Es gibt Geräte. Aber wie werden Mikrovirtuale verwaltet und konfiguriert? Die Management-API hilft uns hier.
Management
Amazon hat mehrere unzerbrechliche Grundprinzipien. Einer davon ist, dass alle Dienste nur über die API miteinander kommunizieren. Es spielt keine Rolle, ob es sich um externe Dienste handelt, die Sie als Benutzer verwenden, oder um unsere internen Dienste. Es kommt nicht vor, dass ein Dienst direkt in die Datenbank eines anderen Dienstes geht - es ist verboten und strafbar. Der Firecracker-API-Thread wird nur verwendet, um über die REST-API auf die Einstellungen und Funktionen von Mikrovirtualen zuzugreifen.
Wir halten uns an die Open API-Spezifikation, sodass Sie Swagger verwenden können.
Metadaten
Es gibt so eine böse - harte Kodierung. In diesem Fall werden einige Daten direkt in den Code eingenäht, z. B. das Login und das Kennwort für den Zugriff auf eine andere Ressource. Dies ist natürlich nicht zulässig. In regelmäßigen Abständen müssen wir einige Daten innerhalb des Mikrovirtuals übertragen. Dies erfolgt über den
Metadatendienst .
Wir geben die erforderlichen Informationen über den Socket an den IMDS-Metadatenhandel weiter. Um diese Informationen im Mikrovirtual zu erhalten, müssen Sie
http://169.254.169.254/latest/meta-data mithilfe der REST-API anfordern. AWS-Benutzer kennen diese magische IP bereits. Auf die gleiche Weise können Mikrovirtualisten detaillierte Informationen über ihre eigene Konfiguration erhalten.
Protokolle
Es ist unerlässlich, Protokolle von Mikrovirtualen in die Außenwelt werfen zu können, bevor sie stirbt. Dies erfolgt über ein reguläres Unix-
FIFO .
Zusätzliche Isolierung
Das Hauptplus der virtuellen Maschine für sich. Es scheint, dass dies ausreichen sollte, aber wir gingen weiter. Für den Fall, dass in der Produktion gearbeitet werden soll, wird empfohlen, eine zusätzliche Isolationsschicht namens
Jailer aufzubringen .
Dies sind die üblichen Vorsichtsmaßnahmen:
- cGruppen zur Begrenzung von Ressourcen;
- Namespace zum Isolieren von Prozessen;
- seccomp - ein Analogon der Firewall für Systemaufrufe;
- und natürlich jedermanns Lieblings- Chroot.
Integration mit anderen Diensten
Gibt es fertige Lösungen, die auf Firecracker basieren? Ja natürlich.
OSV
Dieses Betriebssystem ist darauf zugeschnitten, nur eine Anwendung auszuführen. Aus diesem Grund hat sie die Arbeit mit Speicher und einem Planer sehr einfach organisiert. Ein leistungsstarkes und einfach zu verwaltendes Betriebssystem
funktioniert jetzt zusätzlich
zu Firecracker .
Container
Wir haben auch die Integration mit Containerd gemacht. Wenn Sie bereits mit ihm zusammenarbeiten, müssen Sie mit minimalem Aufwand Container starten, die zur Isolierung in Firecracker verpackt sind.
Anstelle der üblichen Unterlegscheibe bezieht sich Containerd auf die Firecracker-Unterlegscheibe. Es verwaltet runc bereits über einen Agenten, der im Mikrovirtual installiert ist.
Überprüft, funktioniert .
Kata-Container
Als wir Firecracker zum ersten Mal ankündigten, war eine der beliebtesten Kundenfragen:
- Der Mechanismus zum Isolieren von Behältern wurde bereits erfunden - dies sind Kata-Behälter. Warum hast du sie nicht benutzt? Warum eigene entwickeln?- Kata arbeitet mit QEMU, aber wir möchten nicht mit QEMU arbeiten. Deshalb haben wir uns entschlossen, selbst zu kochen.Aber es stellte sich als interessant heraus. Kata-Entwickler trafen sich mit Firecracker-Entwicklern und stimmten der Integration zu. Weil jeder dies als großes Plus ansieht.
Kata Containers v1.5 unterstützt bereits QEMU und Firecracker.
Es stellt sich heraus, dass wir nicht miteinander konkurrieren, sondern uns harmonisch ergänzen. In Kubernetes mit Version 1.12 können Sie runtimeClassName als Kata FC oder Kata QEMU definieren und Ihre Container in geeigneter Isolation ausführen.
Wie wähle ich die Isolierung aus, die zu Ihrer Anwendung passt - Firecracker oder QEMU? Meine persönliche Meinung ist, dass es darauf
ankommt, ob es sich bei Ihrer Bewerbung um
Haustiere oder Rinder handelt .
Kata mit QEMU ist eine Lösung für Haustiere. QEMU ist ein großes, multifunktionales System. Möglicherweise bietet es mehr Unterstützung und Behandlungsmöglichkeiten für Ihre Lieblingstiere.
Kracher ist geeignet, wenn die Ladung Vieh ist. Für den Fall, dass Ihre zustandslose Anwendung ursprünglich für eine flexible horizontale Skalierung konzipiert wurde und der Ausfall eines oder mehrerer Container nicht kritisch ist. Durch die zuverlässige Isolierung können Sie schnell die erforderliche Anzahl neuer Container laden, um ausgefallene zu ersetzen.
Was ist das Ergebnis?
Wir haben mit Widersprüchen begonnen. Es scheint, dass die Lösung des Widerspruchs ein „sowohl unser als auch Ihr“ Ansatz ist, etwas dazwischen, das alle zufriedenstellen wird. Die Erfahrung zeigt jedoch, dass ein Kompromiss nicht erforderlich ist.
Wir haben uns zum Ziel gesetzt, eine neue Lösung zu entwickeln, bei der es nichts Überflüssiges gibt, das zur Lösung einer engen Aufgabe nicht erforderlich ist. Es war auch wichtig, alles, was wir verwenden, so weit wie möglich zu vereinfachen. Ich würde gerne glauben, dass wir keinen Kompromiss gefunden haben, sondern eine solide Lösung, mit der Sie schnell und dicht Tausende von Mikrovirtualen starten können, ohne ihre Isolation zu beeinträchtigen.
Wir verwenden Firecracker bereits bei der Produktion einiger unserer Dienstleistungen. Das Hauptvorteil, das wir erhalten haben, ist die Verbesserung der Service-Nutzung. Dadurch konnten erhebliche Einsparungen erzielt werden. Ein Teil dieser Einsparungen haben wir mit Kunden geteilt. Beispielsweise fielen nach der Einführung von Firecracker die Preise für serverlose AWS Fargate-Container im Januar 2019 um 35-50%. Der Nutzen ist mit bloßem Auge sichtbar, daher besteht kein Zweifel daran, dass wir dieses Produkt weiterentwickeln und unsere Best Practices mit Open Source teilen werden. Die Tatsache, dass Firecracker bereits begonnen hat, sich in andere Lösungen zu integrieren, zeigt ein wachsendes Interesse der Community.
Wenn Sie eine Idee oder ein fertiges Produkt haben, in dessen Beschreibung die Wörter „Mandantenisolation“ stehen, ist dies ein klarer Indikator dafür, was Sie mit Firecracker-Mikrovirtuals experimentieren sollten.
Dieser Bericht veranschaulicht perfekt das Prinzip, an das wir uns bei Ontiko- Konferenzen halten wollen - um weltweite Erfahrungen von russischsprachigen Experten zu erhalten. Und es geht nicht nur um eine mögliche Sprachbarriere, sondern auch um die Kultur, die wir gewohnt sind, technische Details auszutauschen. Im November wird Vasily wieder bei HighLoad ++ auftreten. Dazu kommen beispielsweise Artemy Kolesnikov von Facebook, Vittorio Cioe von Oracle und natürlich Petr Zaitsev von Percona. Wir werden auch Berichte in englischer Sprache haben, den Newsletter abonnieren - wir werden Ihnen mitteilen, wann neue zu den vierzig akzeptierten Berichten hinzugefügt werden.