VM oder Container? Was Sie auf Proxmox verkaufen

Proxmox VE betreibt zwei Arten von Gast. Eine virtuelle KVM-Maschine startet ihren eigenen Kernel hinter emulierter Firmware, und ein LXC-Container teilt sich den Kernel des Hosts, auf dem er sitzt. Für einen Kunden, der einen VPS kauft, sind beide „ein Server mit root darauf“, und deshalb wird der Vergleich meist in einer Marketingtabelle mit Zeilen über Dichte und Overhead gezogen.

Diese Zeilen stimmen, und sie sind nicht die, die Sie etwas kosten werden. Was Sie etwas kostet, ist die Menge der Stellen, an denen die beiden in der API gleich aussehen und sich darunter unterschiedlich verhalten, denn genau dort tut ein Panel, ein Abrechnungssystem oder ein Bestellablauf still das Falsche, und einen Monat lang merkt es niemand.

Wir haben unserer eigenen Proxmox-Integration kürzlich eine zweite Rechenart hinzugefügt, was bedeutete, die API mit der konkreten Frage zu lesen: wo laufen diese beiden auseinander. Das ist dabei herausgekommen, in der Reihenfolge, in der es uns überrascht hat.

Ein Cluster, ein Nummernraum

Fangen Sie bei der Kennung an, denn alles andere hängt daran. Ein Proxmox-Gast wird über eine Nummer angesprochen, und es liegt nahe anzunehmen, dass virtuelle Maschinen und Container je einen eigenen Bereich bekommen: 100 könnte eine VM sein und 100 könnte ebenso ein Container sein, unterschieden durch den Typ.

Das können sie nicht. Der Nummernraum wird über den gesamten Cluster geteilt, und drei Eigenschaften der API sagen das. Der Endpunkt, der die nächste freie Kennung ausgibt, nimmt keinen Typparameter entgegen, er kann also nicht wissen, welche Art Sie gleich anlegen. Die Cluster-Ressourcenliste liefert Maschinen und Container gemeinsam auf demselben numerischen Feld. Und die Gästeliste des Clusters selbst ist über diese Nummer geschlüsselt.

Das hat eine unmittelbare Folge für alles, was Proxmox-Gäste in einer eigenen Datenbank ablegt. Nehmen Sie die Art in Ihre Eindeutigkeitsbedingung auf, sodass „Maschine 5001“ und „Container 5001“ zwei verschiedene Zeilen sind, dann haben Sie ein Schema, das zwei Datensätze für einen Gast halten kann und sie darum streiten lässt. Die Kennung ist für sich allein eindeutig, und die Art ist eine Beobachtung, die daneben gespeichert wird. Wenn Sie Bereiche für eine Flotte festlegen, ändert sich die Rechnung aus den VMID-Bereich für ein Hostinggeschäft wählen nicht, sobald Container dazukommen, und genau das ist der Punkt.

Ein Container wird entpackt, nicht geklont

Die zweite Abweichung ist der Weg zur Erzeugung, und er ist größer, als er aussieht.

Eine virtuelle Maschine entsteht normalerweise durch das Klonen einer Vorlage: Sie benennen eine Quelle, Sie wählen vollständig oder verknüpft, und Sie erhalten eine Kopie eines Plattenabbilds. Ein Container entsteht durch das Entpacken eines Archivs auf ein frisches Volume. Es gibt keinen Quellgast, es gibt keine Wahl zwischen vollständig und verknüpft, und es gibt kein Cloud-Init-Laufwerk, denn es gibt nichts, woran ein Laufwerk hängen könnte.

Der Anfragerumpf hat deshalb fast keine Felder mit dem gemeinsam, der eine Maschine anlegt. Ein Container will ostemplate mit Verweis auf ein Archiv auf einem Storage, ein unprivileged-Flag, einen hostname, ein rootfs und einen swap-Wert. Eine Maschine will scsi0, scsihw, bios, boot und ein ide2, wenn sie von einer ISO startet. Dasselbe Vokabular für das jeweils andere wiederzuverwenden ist der Fehler, den man bewusst vermeidet: Die Wörter ähneln sich genug, dass ein Feld namens disk innerhalb eines Jahres zwei verschiedene Dinge in derselben Codebasis bedeutet.

Zwei Details in diesem Rumpf lohnen sich unabhängig davon, worauf Sie aufbauen.

rootfs=<storage>:<size> ist eine Zuteilung, keine Referenz. Es bedeutet: lege auf diesem Storage ein neues Volume mit so vielen Gigabyte an. Die Form, die ein bestehendes Volume benennt, sieht fast gleich aus und tut etwas grundsätzlich anderes: Sie übernimmt ein Volume, das noch die Daten von jemand anderem enthalten kann.

Einen Parameter wegzulassen ist die sichere Antwort. Nesting, keyctl, FUSE, Bind Mounts und das Durchreichen von Geräten sind alle aus, solange Sie sie nicht senden, und es gibt keinen leeren Wert, an dessen Schreiben Sie denken müssten. Die richtige Grundhaltung für eine Hosting-Plattform ist deshalb eine kurze Anfrage statt einer langen. Beim Architekturfeld ist es dieselbe Geschichte: Proxmox leitet es aus dem Archiv ab, und wer eines sendet, das dem widerspricht, scheitert beim Entpacken.

Drei Dinge, die ein Container nie tun wird

Manche Lücken sind Punkte auf einer Roadmap. Drei sind strukturell, und diese beiden Kategorien im eigenen Produkt zu verwechseln ist der Weg, am Ende eine Funktion zu versprechen, die es nicht geben kann.

Fünf dieser Zeilen brauchen mehr als eine Zelle, in drei Gruppen.

Netboot, ISO-Installation und Firmware-Auswahl sind aus einem Grund unmöglich, nicht aus dreien: Ein Container hat keine Firmware. Er führt keinen Bootloader aus, er hat keine Bootreihenfolge, und ihn zu starten umfasst nichts, dem gesagt werden könnte, es solle es zuerst über das Netz versuchen. Wenn Sie ein Produkt verkaufen, bei dem „Neuinstallation aus unserer Abbildbibliothek“ eine Funktion ist, beachten Sie, dass es zum Weg von der DHCP-Antwort zur fertigen Installation keine Entsprechung für Container gibt. Einen Container neu aufzubauen ist ein anderer Mechanismus mit anderen Zusicherungen, und er verdient einen eigenen Bildschirm statt einer ausgegrauten Schaltfläche.

Die Konsole ist dieselbe Art von Unterschied unter einem vertrauten Namen. Proxmox gibt Ihnen eine Konsole für einen Container, aber sie ist ein Terminal über einen WebSocket und nicht der Framebuffer eines Grafikadapters, und ein VNC-Client stellt sie nicht dar. Hinter einem Konsolenreiter stehen jetzt zwei Umsetzungen, und die ehrliche Zwischenantwort lautet, den Reiter als noch nicht verfügbar auszuweisen, statt einen Betrachter zu öffnen, der ein schwarzes Rechteck zeigt.

Anhalten und Ruhezustand verdienen eine Fußnote, weil sie die Durchsetzungslogik in eine Falle laufen lassen. Wenn Ihre Plattform eine Maschine aussetzt, sobald ein Kunde ein Limit überschreitet, und aussetzen heißt anhalten, dann fallen Container vollständig aus der Durchsetzung heraus: Der Befehl wird abgelehnt, kein Worker meldet etwas, und der Kunde läuft weiter. Die Grenze gehört an den Modus, nicht an den Befehl. Einen Container zu stoppen ist ohne Weiteres möglich.

Swap ist eine Produktentscheidung, kein Standardwert

Hier kommt die Sache, die in Supportanfragen auftauchen wird.

Proxmox gibt einem neuen Container 512 MiB Swap, sofern Sie nichts anderes sagen. Übernehmen Sie das stillschweigend, dann liefert ein als 2 GiB Arbeitsspeicher verkaufter Tarif 2,5 GiB nutzbaren Speicher, und der Unterschied taucht nirgends als größere Zahl auf: Er taucht als Container auf, der langsam wird, statt in einen ehrlichen Speichermangel zu laufen, Monate später, auf einem Host, der zu swappen begonnen hat.

Wir senden den Wert bei jedem Anlegen ausdrücklich mit, mit null als unserem Standard. Null ist eine Wahl und keine Abwesenheit. Was auch immer Sie wählen, wählen Sie es bewusst, schreiben Sie es in den Tarif, und stellen Sie sicher, dass die Zahl, die ein Kunde sieht, die Zahl ist, die der Hypervisor bekommt.

Swap zu messen hat seinen eigenen Preis. Die Sammelabfrage, die Ihnen Zähler für CPU, Arbeitsspeicher, Platte und Netz für jeden Gast in einem Cluster liefert, trägt überhaupt kein Swap-Feld, für keine der beiden Arten. Die einzige Stelle, an der Proxmox ihn meldet, ist der Statusendpunkt pro Gast, es ist also ein zusätzlicher HTTP-Aufruf pro laufendem Container, für immer. Wir lesen ihn einmal pro Minute: dreimal pro Minute verdreifacht die Last auf dem Hypervisor eines anderen für eine Zahl, die sich im Minutentakt bewegt, und einmal alle fünf Minuten legt genau einen Messwert in einen Fünf-Minuten-Eimer, was die Maximalspalte gleich dem Durchschnitt macht und damit zur Verzierung.

Zwei Fehler, die wir ausgeliefert haben, weil wir beides für dasselbe hielten

Beide waren monatelang live, bevor die Runde danach gesucht hat.

Der erste: Unser Importbildschirm führte Container als virtuelle Maschinen auf. Die Cluster-Ressourcenliste mit type=vm ist kein QEMU-Filter, sie liefert beide Arten zurück, und das Feld, das sagt, welche davon, wurde schlicht nicht gelesen. Nichts ist fehlgeschlagen. Die Liste war falsch.

Der zweite war leiser. Jeder laufende Container bekam pro Abfragerunde zwei Aufrufe des Gastagenten, dazu einen nach jedem Befehl, gegen einen Pfad, den es nur für QEMU gibt. Jeder davon war ein garantierter Fehlschlag, und nichts trat zutage, denn eine fehlgeschlagene optionale Anreicherung soll überlebbar sein, und das war sie. Gefunden wurde es von einem Test, der zählt, welche Pfade aufgerufen werden, statt Ergebnisse zu behaupten, und diese Gewohnheit lohnt sich zu übernehmen: Wer nur auf Ergebnisse prüft, hält eine ganze Kategorie sinnloser Arbeit unsichtbar.

Was wir aufschreiben würden, bevor wir das eine oder das andere verkaufen

Wenn Sie entscheiden, was ein Hosting-Produkt auf Proxmox anbieten soll, bringen vier Fragen Sie den größten Teil des Weges.

1. 01Ist die Art eine Eigenschaft des Tarifs oder eine Wahl an der Kasse? Beides ist vertretbar. Ein Standardwert unter der Wahl ist es nicht: Ein Kunde, der einen Container bestellt und eine Maschine bekommen hat, hat ein anderes Sicherheitsmodell, einen anderen Kernel und einen anderen Satz von Fähigkeiten erhalten als den, den er ausgewählt hat.
2. 02Welche Ablehnungen sind dauerhaft und welche vorübergehend? Sagen Sie es in der Oberfläche, und zwar mit diesen Worten. „Für einen Container nicht möglich“ und „noch nicht gebaut“ sind verschiedene Versprechen.
3. 03Woher kommt der Schutz gegen gefälschte Absender? Die ehrliche Lücke in unserer eigenen Arbeit: Eine geklonte Maschine bekommt bei der Auslieferung IP-Filterung, ein Container noch nicht. Proxmox hat für beide dieselben Firewall-Endpunkte, es ist also ein Bauschritt und kein Hindernis, aber ein ohne ihn übergebener Container kann Verkehr senden, der behauptet, jemand anderes zu sein.
4. 04Was zeigt die Überwachung für einen Container? Alles, was aus einem Gastagenten, einem Framebuffer oder aus Firmware abgeleitet ist, ist leer. Leer ist in Ordnung. Leer, dargestellt als gesunde Null, ist es nicht.

Wir haben das Tarif-Feld, den Bestellweg und die Anlegeanfrage gebaut und gegen die rohe HTTP-Form der API gemessen. Was wir nicht getan haben, ist, einen Container auf dem Produktivhypervisor von jemandem anzulegen. Die ehrliche Beschreibung unserer Container-Unterstützung lautet deshalb: die Form stimmt und der Rundlauf ist ungetestet. Das ist eine nützliche Sache, die man über die eigene Plattform laut sagen können sollte.

Das ist beim Bau der Proxmox-Integration für Provibr entstanden, wo der Agent im eigenen Netz des Kunden läuft und sich ausschließlich nach außen verbindet. Die verwandte Gewohnheit, der Erfolgsantwort eines Hypervisors nicht zu trauen, steht in warum eine 200 von Proxmox kein Ergebnis ist.