GlusterFS sollte tot sein, dann hat es jemand zurück nach Proxmox gezerrt

Das Feature, das verschwand, und die Leute, die nicht loslassen wollten

Manche Entfernungen fühlen sich weniger wie Aufräumen an und mehr wie eine Tür, die einer ganzen Nutzergruppe vor der Nase zugeschlagen wird. Proxmox 9 hat GlusterFS als Storage-Typ gestrichen, und für alle, die es noch im Einsatz hatten, war das mehr als ein Eintrag im Changelog. Die Botschaft war klar: Hier will die Plattform ihre Energie nicht mehr investieren. Weiterziehen, Ceph nutzen oder etwas anderes nutzen, und aufhören, an einem Storage-Stack festzuhalten, den das weitere Ökosystem längst wie altes Kellermobiliar behandelt.

Open-Source-Communities akzeptieren die offizielle Stimmungslage aber nicht immer. Ein Nutzer schrieb ein eigenes Storage-Plugin, um die GlusterFS-Funktionalität in Proxmox 9 wiederherzustellen, samt zusätzlicher Patches, um Teile wie pvesm scan und GUI-Unterstützung zurückzubringen. Das ist die Art von Sache, die Leute gleichzeitig jubeln und zusammenzucken lässt. Auf der einen Seite ist es genau der Grund, warum man diese Welt liebt: Ein Feature wird gestrichen, und jemand mit genug Verärgerung und Können sagt: "Gut, dann baue ich es eben selbst wieder ein." Auf der anderen Seite wirft es die unbequeme Frage auf, der niemand ewig ausweichen kann. Wenn eine Plattform die Unterstützung entfernt hat, weil die Upstream-Lage wackelig ist, löst die Wiederherstellung dann das Problem oder verschafft sie nur Zeit?

Diese Spannung zog sich durch die gesamte Diskussion. Manche waren dankbar, andere skeptisch, und manche trauerten fast um GlusterFS wie um einen alten Freund, den man in der Öffentlichkeit nicht mehr so leicht verteidigen konnte. Hinter dem Plugin stand die Frage, was passiert, wenn eine Storage-Technologie für manche Nutzer noch funktioniert, noch emotionale Loyalität genießt und noch eine Nische füllt, aber nicht mehr sauber in die Enterprise-first-Roadmap des Hypervisors um sie herum passt.

Das schmerzt, weil viele Nutzer GlusterFS gar nicht hassten. Verschwunden ist es, weil Support-Aufwand, Upstream-Dynamik, QEMU-Änderungen und Enterprise-Erwartungen allesamt in die falsche Richtung zeigten.

"Gepflegt" trägt hier eine Menge Gewicht

Der schärfste Streitpunkt drehte sich um ein einziges Wort: gepflegt. Das klingt einfach, bis ein Storage-System davon abhängt. Ein Lager verwies darauf, dass GlusterFS End-of-Life sei oder zumindest nicht mehr in einer Weise gepflegt werde, die sie als bedeutsam ansahen. Die Warnung war unverblümt: Es wurde aus gutem Grund aus Proxmox entfernt, und man solle vorsichtig sein, bevor man etwas Wichtiges auf einem wiederbelebten Plugin aufbaut. Jemand sagte im Grunde, dass eine Handvoll Leute, die Code am Leben halten, nachdem die große Unterstützung durch ein Unternehmen weggefallen ist, nicht dasselbe sei wie ein gesundes, supportfähiges Projekt.

Diese Sichtweise ist hart, aber nicht irrational. Enterprise-Plattformen brauchen langweilige Abhängigkeiten, also Projekte mit aktivem Upstream, vorhersehbaren Fixes, klaren Release-Pfaden und genug Nutzung, um den Support-Aufwand zu rechtfertigen. Ein Storage-Plugin ist mehr als eine Menüoption. Es betrifft VM-Disks, Migrationen, Backups, Scans, Provisioning und all die schrecklichen Randfälle, die erst auftauchen, wenn ein Kunde bereits verärgert ist. Aus dieser Perspektive war die Streichung von GlusterFS durch Proxmox schlicht Risikomanagement.

Die andere Seite widersprach. Der Ersteller argumentierte, GlusterFS werde noch immer gepflegt, nur langsamer, besonders nachdem sich Red Hat zurückgezogen hatte. Wichtiger noch: Er argumentierte, die Entfernung durch Proxmox sei falsch angelegt gewesen, weil der QEMU-Block-Treiber nur ein Teil dessen war, was das Storage-Plugin leistete. Selbst wenn QEMU seinen nativen Gluster-Treiber fallen ließ, konnten VMs weiterhin über GlusterFS via FUSE laufen, ungefähr nach demselben Muster wie bei Directory-Storage. Für Nutzer, die bereits in Gluster investiert hatten, zählt das. Sie baten Proxmox nicht darum, die Welt für immer zu forken, sie wollten, dass die bestehende Storage-Integration dort nützlich bleibt, wo sie es noch sein kann.

Im Streit ging es vor allem um Vertrauen. Ist ein Projekt "gepflegt", wenn ein paar Leute noch Fehler beheben? Ist es "tot", wenn große Anbieter ihre Aufmerksamkeit anderswohin verlagert haben, Nutzer es aber weiterhin betreiben können? Ist langsame Pflege für ein Homelab akzeptabel, aber inakzeptabel für Enterprise? Die Antwort hängt davon ab, wer ans Telefon gehen muss, wenn etwas kaputtgeht. Deshalb kann dasselbe Plugin für die eine Person heldenhaft wirken und für die andere leichtsinnig.

Hier existiert eine Art Open-Source-Fegefeuer: nicht tot genug, um zu verschwinden, und nicht lebendig genug, um Vertrauen zu wecken. GlusterFS lebt jetzt in diesem seltsamen Zwischenraum, in dem treue Nutzer es am Laufen halten können, sich aber jedes Upgrade anfühlt wie die Frage, ob der Boden noch da ist.

Das Enterprise-Argument gegen Nostalgie

Das Enterprise-Argument kam klar durch: Proxmox ist eine Enterprise-first-Plattform, auch wenn es dank seiner Open-Source-Wurzeln eine riesige Fangemeinde außerhalb des Enterprise-Bereichs hat. Das Projekt kann also nicht jedes Feature am Leben erhalten, nur weil eine Teilmenge der Nutzer es weiterhin mag. Wenn Upstream-QEMU ein Verhalten fallen lässt, wenn das Gluster-Ökosystem nicht mehr gesund aussieht und wenn Enterprise-Support-Tickets keine ausreichende Nachfrage zeigen, dann wird es schwer zu rechtfertigen, GlusterFS innerhalb der offiziellen Plattform zu behalten.

Das ist emotional nicht befriedigend, aber so überleben Produkte. Storage zu unterstützen ist etwas anderes als das Unterstützen einer vergessenen Theme-Option, denn Storage-Bugs sind karrierebeendende Bugs. Ein instabiles Plugin kann Vertrauen schneller zerstören als fast alles andere in einem Virtualisierungs-Stack. Enterprise-Nutzer wollen Features, hinter die Anbieter stehen können, ohne von Patches, FUSE-Schichten und "na ja, technisch funktioniert es noch" zu murmeln. Wenn man Support verkauft, reicht "technisch" nicht aus.

Ein Kommentator verwies auf Proxmox' eigene erklärte Sichtweise, dass Enterprise-Support-Auswertungen keine ausreichende GlusterFS-Nutzung zeigten, um den Aufwand zu rechtfertigen. Das mag kalt klingen, erklärt aber vieles. Software-Projekte treffen Entscheidungen danach, wo ihre Nutzer stehen, wohin sich Upstream entwickelt und wo die Support-Kosten wahrscheinlich explodieren. In dieser Rechnung wurde GlusterFS zu einer schlechten Wette, während Ceph, Object Storage und OpenStack-nahe Prioritäten das Rennen gewannen. GlusterFS wurde zur Antwort von gestern.

Es gab auch Vorwürfe in Richtung Red Hat und IBM, vorgebracht im bitteren Ton von Leuten, die sich noch erinnern, als GlusterFS zentraler wirkte. Eine Person sagte, IBM habe die Nutzer im Regen stehen lassen, als es den Stecker zog. Eine andere sagte, Red Hat habe schlicht die Richtung gewechselt, hin zu Object Storage und OpenStack. Wie man es auch dreht, das Gefühl bleibt gleich: Eine Technologie, der Menschen vertrauten und die sie nutzten, verlor institutionelle Dynamik, und nachgelagerte Projekte reagierten entsprechend.

Das ist der Teil, den Nutzer am meisten hassen. Etwas kann noch nützlich sein und trotzdem von den Unternehmen fallen gelassen werden, die ihm einst Legitimität verliehen haben. Dann bleiben den Betreibern Skripte, Plugins, Forenthreads und eine Entscheidung: migrieren, bevor sich der Boden wieder verschiebt, oder weiter patchen, weil das aktuelle Setup noch seinen Zweck erfüllt.

Warum Menschen GlusterFS immer noch vermissen

Die Zuneigung zu GlusterFS war nicht eingebildet. Eine Person sagte, sie bevorzuge es gegenüber Ceph, weil Ceph mehr Overhead mit sich bringe, während man GlusterFS auf fast alles ansetzen könne und es einfach "alles klar" sage. Diese Zeile bringt den Reiz perfekt auf den Punkt, denn GlusterFS wirkte zugänglich. Es verlangte nicht dieselbe Art von sorgfältig dimensioniertem Cluster, schnellem Netzwerk, Laufwerksplanung und operativer Disziplin, die Ceph oft erfordert. Für kleinere Setups, Labore, ungewöhnliche Hardware und Leute, die verteilten Storage wollten, ohne eine ganze Kathedrale darum herum zu bauen, hatte GlusterFS Charme.

Ceph kann brillant sein, arbeitet aber nicht beiläufig. Es will ein echtes Design, genug Nodes, genug Disks, genug Netzwerk und genug Wissen. GlusterFS wirkte, zumindest in seiner freundlichsten Form, nachsichtiger. Deshalb greifen Menschen immer noch danach. Es gewinnt nicht jeden Benchmark und hakt nicht jede moderne Enterprise-Anforderung ab, aber es machte bestimmte unordentliche Setups möglich, ohne von Nutzern zu verlangen, über Nacht zu Storage-Architekten zu werden.

Die Nostalgie kam trotzdem mit Narben. Jemand, der GlusterFS einst liebte, sagte, diese Liebe habe beim Node-Ausfall geendet, weil Rebuilds das Problem waren. Ein anderer Nutzer sagte, er habe es mit einem dedizierten 10-Gbit/s-Netzwerk für die Kommunikation zwischen Nodes ausprobiert und trotzdem eine Performance unterhalb der Erwartungen vorgefunden. Er ließ es auch fallen, weil native Snapshots fehlten. Das sind keine kleinen Beschwerden, denn Performance, Rebuild-Verhalten und Snapshots sind keine dekorativen Features, wenn es um VM-Storage geht. Sie machen den Unterschied zwischen "das ist clever" und "das wird das Wochenende ruinieren".

Deshalb wurde aus der Diskussion keine simple Feier. GlusterFS hat Fans, aber selbst die Fans wissen, wo die blauen Flecken sitzen. Das Plugin stellt einen Weg für Leute wieder her, die es weiterhin wollen, ohne die Geschichte umzuschreiben. Es macht Rebuilds nicht angenehm, und es fügt nicht magisch das operative Vertrauen zurück hinzu, das mit dem Wegfall des großen Anbieter-Supports verschwand. Es gibt Nutzern Kontrolle, was mächtig ist, macht den Betrieb dadurch aber nicht sicherer.

Trotzdem ist etwas zutiefst nachvollziehbar daran, wenn Menschen sich weigern, ein Tool aufzugeben, nur weil es nicht mehr auf der geweihten Spur liegt. Infrastruktur ist voll von solchen Loyalitäten. Menschen nutzen weiterhin, was sie verstehen, was ins Budget passt, was frühere Katastrophen überlebt hat, oder was auf Hardware, über die Ceph nur die Nase rümpfen würde, einfach gut genug funktioniert. Manchmal ist das schlechtes Engineering, manchmal praktische Weisheit, und meistens beides.

Ein Plugin kann ein Feature wiederbeleben, kein Ökosystem

Das eigene Plugin ist nützlich und beeindruckend, aber keine Zeitmaschine. Es kann die GlusterFS-Storage-Unterstützung innerhalb von Proxmox 9 wiederherstellen, Scans patchen und das GUI-Verhalten zurückbringen. Es kann Leuten das Leben erleichtern, die bereits aktualisiert haben oder aktualisieren wollen, ohne vorher ihren Storage-Stack herauszureißen. Für Community-Nutzer ist das ein echtes Geschenk, weil aus "geht nicht" ein "geht, mit Einschränkungen" wird. In der Open-Source-Welt zählt das.

Die Einschränkungen sind allerdings die ganze Geschichte. Sobald der Support außerhalb der Hauptplattform liegt, werden Nutzer Teil des Support-Modells, ob es ihnen gefällt oder nicht. Jedes Proxmox-Update, jede QEMU-Änderung, jede GlusterFS-Eigenart, jedes FUSE-Verhalten und jeder seltsame Storage-Randfall wird zu etwas, das man im Auge behalten muss. Das Plugin mag heute stabil sein und morgen nerven, ohne dass die Person, die es geschrieben hat, dafür etwas kann. Das ist die Steuer, die man zahlt, wenn man ein Feature wiederherstellt, das die Plattform bewusst zurückgelassen hat.

Es gibt hier eigentlich drei Seiten. Die erste sagt, Proxmox habe recht gehabt: GlusterFS sei upstream zu schwach, habe zu wenig Enterprise-Nachfrage und sei zu riskant, um es offiziell weiterzutragen. Die zweite sagt, die Entfernung sei zu grob gewesen, weil GlusterFS auch ohne den QEMU-Treiber über FUSE weiterhin funktioniere und das Storage-Plugin mehr leiste als nur eine einzelne, enge Block-Treiber-Aufgabe. Die dritte sagt, das alles verfehle den praktischen Punkt: Manche Leute haben bereits GlusterFS, kennen bereits dessen Kompromisse und brauchen eine Brücke statt einer Predigt.

Diese dritte Seite ist vielleicht die ehrlichste. Nicht jedes Plugin ist eine Revolution, manchmal ist es ein Rettungsboot oder ein Überdruckventil, und manchmal einfach ein fähiger Nutzer, der sagt: "Ich weiß, das ist nicht die Zukunft, aber es ist noch meine Gegenwart."

Die Gefahr besteht darin, so zu tun, als sei das Rettungsboot ein Kreuzfahrtschiff. GlusterFS über Community-Patches in Proxmox 9 zu betreiben, mag für Labore, Migrationen, Nischen-Setups und Leute funktionieren, die den Blast Radius vollständig verstehen. Für frische Enterprise-Deployments ist es schwerer zu rechtfertigen, es sei denn, es gibt einen sehr spezifischen Grund und einen sehr nüchternen Support-Plan. Das Plugin bringt Wahlfreiheit zurück, offizielles Vertrauen bringt es nicht zurück.

Das macht diese ganze Episode so ungeschönt, denn sie handelt vom unordentlichen Nachleben nützlicher Software. Ein Projekt verblasst, ein Anbieter zieht weiter, eine Plattform streicht den Support, Nutzer protestieren, und dann schreibt jemand Code. Das Feature kehrt zurück, aber nicht auf dieselbe Weise. Jetzt trägt es ein Etikett, sichtbar oder nicht: von der Community wiederbelebt, mit offenen Augen fortfahren.

GlusterFS ist nicht ganz tot und auf die alte Art auch nicht mehr richtig lebendig. Irgendwo in dieser unbequemen Mitte tut ein selbstgebautes Proxmox-Plugin genau das, was Open Source schon immer am besten konnte: sich zu weigern, das offizielle Ende als das einzige Ende gelten zu lassen.