Proxmox, TrueNAS und die Frage nach einer eigenen Storage-Appliance

Die Idee, die offensichtlich klingt, bis man sie anfasst

Jede populäre Plattform erreicht irgendwann denselben unangenehmen Moment. Die Nutzer hören auf zu fragen, was sie kann, und fangen an zu fragen, warum der Rest ihres Stacks überhaupt noch existieren muss. Proxmox betreibt bereits die Hosts. Es versteht VMs, Container, ZFS-Pools, Clustering, Backups, Berechtigungen und genug Storage-Integration, um ein Homelab wie eine kleine private Cloud wirken zu lassen. Der Pitch schreibt sich also fast von selbst: Warum nicht auch ein eigenes Proxmox-Storage-Produkt bauen? Nennen wir es ProxStorage. Einfach gehalten, Debian-basiert, rein ZFS, ohne App-Store-Gerümpel, ohne Plugin-Wucherung, ohne Identitätskrise. Es exportiert NFS und iSCSI, lässt Proxmox die Snapshots sauber verwalten und gibt den Nutzern ein Ökosystem statt einer weiteren Appliance mit einem weiteren Dashboard und einem weiteren Satz Annahmen.

Diese Idee traf einen Nerv, weil sie etwas Echtes anspricht. Viele Leute mögen TrueNAS für das, was es am besten kann, aber sie sind es leid, zuzusehen, wie Storage-Plattformen in Richtung „Alles-Box" abdriften. Apps, Plugins, UI-Wandel, Produktsegmentierung, kommerzielle Verunsicherung und glänzende Nebenprojekte lassen manche Nutzer sich wieder eine langweilige Storage-Appliance wünschen, die kein Kubernetes-Spielplatz, kein Mediaserver-Launcher und keine Lifestyle-Marke für Festplatten sein will. Einfach nur ein seriöses, ZFS-gestütztes Storage-Ziel für Virtualisierung, das sagt: Hier sind Ihre Pools, Datasets, Snapshots, NFS-Exports, iSCSI-Targets, Replikationsjobs und Berechtigungen. Schlafen Sie gut.

Der Reiz ist offensichtlich. Eine Storage-Appliance, gebaut von denselben Leuten, die Proxmox VE bauen, könnte sich nativer anfühlen, als es TrueNAS, OpenMediaVault, XigmaNAS oder eine selbstgebastelte Debian-Kiste je könnten. Man stellt sich Storage-Snapshots vor, die in der Proxmox-UI wie Backups auftauchen, dazu VM-bewusste Snapshot-Koordination ohne Klebeband und eine saubere Oberfläche, die darum herum gebaut ist, PVE-Cluster zu bedienen statt jedes erdenkliche NAS-Hobby. Am Ende stehen weniger Übersetzungsschichten zwischen „Ich brauche zuverlässigen VM-Storage" und „hier ist das Ding, das diesen Job erledigt". So weit der Traum. Storage-Träume haben allerdings die unangenehme Angewohnheit, sich in Support-Albträume zu verwandeln.

TrueNAS macht mehr, als Dateien freizugeben

Ein Großteil der anfänglichen Verwirrung entstand, weil Leute den Vorschlag behandelten, als ginge es um simples File-Sharing. Jemand fragte, warum man überhaupt TrueNAS brauche, wenn man einfach eine winzige NAS-VM in Proxmox laufen lassen könnte. Ein anderer wies darauf hin, dass Proxmox bereits ZFS-Pools und sogar einen UI-Bereich dafür habe. Das stimmt, verfehlt aber den Kern der Idee. Gemeint war kein Ordner-Share, gemeint war ein Weg, Proxmox ein dediziertes Storage-Backend zu geben, das mit der SAN-Rolle konkurriert, die TrueNAS oft übernimmt.

Diese Unterscheidung zählt. TrueNAS stammt aus einer Welt, in der Bare-Metal-Storage der eigentliche Punkt war. Performance, Replikation, skalierbare Pools, Block-Storage und sauberes Management waren dort das Produkt und keine Nebenaufgabe. Ein Kommentator beschrieb den Betrieb einer Bare-Metal-TrueNAS-Box mit rund 300 TB Storage, von denen ein Teil iSCSI-Block-Storage bereitstellte, der früher VMware und heute Proxmox versorgt. Eine Mikro-NAS-VM, die eine Familienfoto-Freigabe bedient, spielt in einer anderen Liga. So eine Box ist Infrastruktur, ein eigenes Storage-Subsystem.

Fair formuliert lautet die ProxStorage-Idee deshalb: Proxmox könnte sein Ökosystem zusätzlich zum hyperkonvergenten Ceph mit einem konvergenten Storage-Produkt abrunden. Das ist viel interessanter als ein TrueNAS-Klon für Leute, die keine Plugins mögen. Ceph ist bereits Teil der Proxmox-Geschichte, aber Ceph ist keine beiläufige Single-Box-Storage-Appliance. Es will mehrere Nodes, Planung, Netzwerk, Disks, Monitore, OSDs, Failure Domains und eine gewisse emotionale Reife. Ein NAS- oder SAN-Produkt kann gerade deshalb nützlich sein, weil es keine drei oder mehr physischen Maschinen braucht, um sinnvoll zu sein.

Dieser Punkt kam auch direkt zur Sprache: Ein NAS sollte nicht 3 oder mehr Geräte brauchen, um zu funktionieren. Jemand anderes widersprach, dass ein sicheres, skalierbares NAS in einem kleinen Unternehmen absolut seinen Platz habe, selbst wenn ein winziges Homelab mit weniger auskommt. Beide Seiten haben recht. Eine einzelne Storage-Appliance ist etwas anderes als ein verteilter Storage-Cluster, und so zu tun, als würden beide dasselbe Problem lösen, ist der Grund, warum Leute am Ende wütend auf Ceph sind, weil es kein Synology ist, oder wütend auf ein NAS, weil es kein Scale-out-Storage-Fabric ist.

Die stärkste Unterstützung für den Vorschlag kam von Leuten, die diesen Mittelweg verstanden. Ein dediziertes, Proxmox-verwaltetes ZFS- und vielleicht Ceph-bewusstes Storage-Ziel, speziell für PVE gebaut, könnte nützlich sein. TrueNAS ist nicht schlecht, und die bestehenden Tools funktionieren. Im Proxmox-Ökosystem klafft aber eine Lücke zwischen „lokalem ZFS auf jedem Host" und „vollständigem Ceph-Cluster". In dieser Lücke lebt ein Großteil des echten Storage in kleinen Unternehmen und Labs.

Die „Nutzt doch, was schon da ist"-Fraktion hat gute Argumente

Die andere Seite des Arguments ist hart praktisch: Warum sollte Proxmox ein ganzes Storage-Produkt bauen, wenn die Bausteine schon existieren? Sie können ZFS direkt auf einem PVE-Node aufbauen, Datasets über einen LXC-Container mit Samba exportieren, XigmaNAS oder ein anderes NAS-Betriebssystem in eine VM packen, NFS und iSCSI von Hand auf Debian aufsetzen, TrueNAS bare metal betreiben, OpenMediaVault nutzen oder ein kommerzielles SAN kaufen. Das Ökosystem ist unordentlich, aber es ist alles andere als leer.

Ein Kommentator schlug XigmaNAS vor und beschrieb es als langjährigen FreeNAS-Fork, der vieles von dem bietet, was gefragt wird. Ein anderer schlug vor, LXC „Zamba" zu nutzen und ein ZFS-Dataset zu exportieren. Jemand anderes merkte an, dass man auf Proxmox ein ZFS-Dataset anlegen und Storage so in eine VM durchreichen kann, dass der Pool auf PVE bleibt. Diese Vorschläge sind realistisch, genau so lösen viele Leute dieses Problem heute: ZFS dort behalten, wo Proxmox es sehen kann, und dann einen leichtgewichtigen Dienst oder eine VM nutzen, um es freizugeben.

Nur ist „das kann man schon machen" eben etwas anderes als ein kohärentes Produkt. Ein handgebauter ZFS-Export-Stack mag für die Person, die ihn gebaut hat, wunderbar funktionieren. Für den nächsten Admin ist er vielleicht ein verwirrender Haufen Annahmen. TrueNAS existiert, weil Storage-Management aus mehr besteht als aus einer Handvoll Befehle. Es umfasst Lifecycle, Berechtigungen, Alerts, Replikation, Snapshots, Freigaben, Monitoring, Upgrades und Recovery. Eine Proxmox-native Storage-Appliance müsste all das leisten, ohne zu dem aufgeblähten Ding zu werden, das sie angeblich ersetzen sollte.

Das ist der schwierige Teil. Jeder will „einfach", und niemand ist sich einig, wo einfach endet. Fügen Sie nur NFS und iSCSI hinzu, und sofort fragt jemand nach SMB. Fügen Sie SMB hinzu, und jemand fragt nach Object Storage. Fügen Sie Object Storage hinzu, und schon driften Sie in genau die Feature-Wucherung ab, die alle vermeiden wollten. Fügen Sie Apps hinzu, und der Pitch stirbt komplett. Lassen Sie die Apps weg, und ein Teil des NAS-Markts zuckt mit den Schultern und bleibt, wo er ist. Produktfokus klingt einfach, bis jedes fehlende Feature für irgendjemanden ein Dealbreaker ist.

Es gab auch einen vernünftigen verfahrenstechnischen Einwand: Feature-Wünsche gehören in Bugzilla und nicht nur in beiläufige Diskussionen. Das ist keine romantische Antwort, aber die erwachsene. Wenn das Ziel ist, Entwickler anzuziehen, braucht ein echter Feature-Wunsch Scope, Use Cases, Non-Goals, Integrationspunkte und einen Grund, warum es dem Unternehmen hinter Proxmox helfen würde. „Bitte baut ein Storage-Betriebssystem" ist keine kleine Bitte, das ist eine Produktlinie.

Bei der TrueNAS-Verunsicherung geht es um Vertrauen

Die Kritik an TrueNAS hatte eine emotionale Kante, und dahinter stand ein Gefühl: Das Ding wirkt aufgebläht, die UI ändert sich ständig, und was, wenn es noch kommerzieller wird? Diese Angst ist in Open-Source-nahen Communities verbreitet. Leute bauen ihr Zuhause, ihre Labs und ihre Unternehmen auf einem Tool auf und beobachten dann, wie sich das Unternehmen dahinter weiterentwickelt. Plötzlich gibt es neue Produkte, neues Branding, neue Prioritäten, und die Nutzer fragen sich, ob sie noch die Zielgruppe sind.

Ein Teil dieser Verunsicherung mag unfair sein. TrueNAS erfüllt weiterhin eine wichtige Rolle und hat eine lange Erfolgsbilanz. Ein Storage-Produkt darf eine polierte UI, kommerzielle Angebote und größere Ambitionen haben. Unternehmen brauchen Geld. Entwickler brauchen Gehälter. Hardware-Hersteller brauchen Kunden. Dass ein Projekt am Leben bleibt, bedeutet meist, dass jemand für den Sauerstoff bezahlt.

Trotzdem ist das Unbehagen real. Nutzer, die eine Storage-Appliance für Proxmox wollen, wollen nicht unbedingt eine Allzweck-NAS-Plattform mit eigener Persönlichkeit. Sie wollen etwas Ruhigeres, ein Storage-Ziel mit weniger Meinungen außerhalb seiner Spur, etwas, das sich nicht so anfühlt, als könnte es zu einem weiteren Ökosystem werden, das man erst entschlüsseln muss. So gesehen steckt hinter der ProxStorage-Idee mehr als eine Abneigung gegen TrueNAS, nämlich der Wunsch nach Storage, das sich wie Teil desselben operativen Gehirns wie Proxmox anfühlt.

Deshalb ist die Snapshot-Idee wichtig. „Die VM sieht native ProxStorage-Snapshots" mag vage klingen, aber der Wunsch dahinter ist scharf umrissen. Nutzer wollen storage-bewusste Virtualisierung ohne klobige Grenzen, und sie wollen, dass Hypervisor, Storage-Ziel und Backup-System sich gegenseitig verstehen. Proxmox Backup Server zeigt bereits, wie viel dieses Ökosystem-Denken wert ist. Er speichert Dateien und passt dabei zu der Art, wie PVE über Backups denkt. Eine Proxmox-Storage-Appliance könnte theoretisch dasselbe für Shared Storage leisten.

Trotzdem gilt Vertrauen in beide Richtungen. Nutzer vertrauen Proxmox vielleicht, aber in einer neuen Kategorie müsste Proxmox sich dieses Vertrauen erst verdienen. Storage-Appliances werden hart beurteilt, weil Datenverlust unverzeihlich ist. Eine raue Kante in einer VM-UI ist nervig. Eine raue Kante im Storage-Replikationsverhalten oder bei iSCSI kann ein unternehmensbeendendes Ereignis werden. Ein „Sorgenfrei-Storage"-Produkt klingt wunderbar, und es klingt gleichzeitig wie ein Erpresserbrief aus der zukünftigen Support-Warteschlange.

Das fehlende Produkt ist real, aber die Falle auch

Die überzeugendste Version von ProxStorage wäre schmal geschnitten: Debian-basiert, ZFS zuerst, kein App Store und kein Docker-Theater, dafür starkes NFS und iSCSI. SMB-Support gehört nur dann dazu, wenn das Produkt bereit ist, ihn richtig zu betreuen. Dazu kämen Proxmox-native Authentifizierung, Snapshot- und Replikations-Workflows, die zu PVE passen, gutes Monitoring, ernst gemeinte Alerts, erstklassige Dokumentation und ein sauberer Upgrade-Pfad. Vielleicht optionale Ceph-Integration für größere Designs, aber keine erzwungene Ceph-zuerst-Geschichte. Im Grunde: eine Storage-Appliance für Leute, die einen SAN/NAS-Begleiter für Proxmox wollen, kein Lifestyle-NAS.

Das könnte kraftvoll sein. Es würde kleinen Betrieben und Labs eine sauberere Alternative zu „TrueNAS bare metal installieren und verkabeln" oder „einen Haufen individueller Debian-Storage-Arbeit machen und hoffen, dass alle dokumentieren" geben. MSPs und interne IT-Teams bekämen eine konsistentere Support-Story. Nutzern, die Shared Storage wollen, aber weder die Komplexität von Ceph noch die Weitläufigkeit einer allgemeinen NAS-Appliance, wäre geholfen. Und das Ökosystem würde sich auf eine Weise erweitern, die sich natürlich anfühlt.

Gleichzeitig würde so ein Produkt um Entwickler-Aufmerksamkeit konkurrieren, gegen alles, was Proxmox bereits pflegen muss: PVE, PBS, Mail Gateway, SDN, Clustering, HA, Ceph-Integration, ZFS-Integration, Backup-Verbesserungen, UI-Arbeit, Kernel-Probleme, Hardware-Support, Dokumentation und Enterprise-Support. Ein Storage-Produkt ist nicht „wenig Arbeit", nur weil Debian und ZFS schon existieren. Der Wert steckt in der Integration, den Tests, den Leitplanken und dem Support, und genau das ist der teure Teil.

Und die Community würde sich sofort spalten. Manche würden endlich ein sauberes Proxmox-SAN feiern, andere fragen, warum man TrueNAS duplizieren soll. Manche wollten Ceph fest eingebaut, manche würden SMB fordern, manche Object Storage. Manche wollten eine Single-Node-Appliance, andere HA-Storage. Manche würden darauf bestehen, dass ein NAS einfach sein muss, und manche darauf, dass einfach unverantwortlich ist. Das Produkt würde in tausend Erwartungen hineingeboren.

Der Vorschlag braucht deshalb Disziplin, was noch nichts gegen das Produkt sagt. „TrueNAS ersetzen" ist als Ziel zu breit, zu emotional und wahrscheinlich unnötig. Die bessere Formulierung lautet: eine Proxmox-Storage-Appliance bauen, die sich darauf konzentriert, das beste Shared-Storage-Backend für PVE zu sein. Das ist ein saubereres Ziel. Es muss nur die Proxmox-Storage-Lücke besser lösen als der aktuelle Flickenteppich, die restliche NAS-Welt darf es anderen überlassen.

Die besten Ideen fangen meist als Beschwerden an

Was diese Diskussion interessant macht: Der ursprüngliche Pitch war unordentlich, der Instinkt dahinter aber stark. Die Leute wollen tatsächlich Storage, das sich nativ zu ihrer Virtualisierungsplattform anfühlt. Sie wollen tatsächlich weniger Bloat. Sie wollen tatsächlich eine Alternative zwischen lokalem ZFS und vollem Ceph. Sie wollen tatsächlich Snapshots, Replikation, NFS, iSCSI und PVE-Integration, ohne ein separates Universum jonglieren zu müssen. Und ja, manche Leute sind es leid, zuzusehen, wie Storage-Plattformen zu App-Plattformen mit angeschlossenen Festplatten werden.

Auch die Kritiker hatten einen Punkt. Proxmox hat bereits ZFS, bestehende NAS-Tools existieren, und TrueNAS ist mehr als nur Bloat. XigmaNAS, OMV, handgebautes Debian und einfache Container-Exports decken bereits viele Use Cases ab. Ein neues Produkt würde Support-Last, Scope Creep und tausend Wege bringen, Leute zu enttäuschen. „Sorgenfreies Storage" ist die Art von Phrase, die großartig klingt, bis der erste Nutzer einen Pool verliert, weil er sich durch eine Warnung geklickt hat, die er nicht verstanden hat.

Es gibt hier eigentlich drei Lager. Das erste will eine Proxmox-native Storage-Appliance, weil sich das Ökosystem ohne sie unvollständig anfühlt. Das zweite sagt, die bestehenden Tools reichten aus, und Proxmox solle keine Energie darauf verschwenden, Storage-Management neu zu erfinden. Das dritte sieht das größere Bild: Es mag Raum für ein konvergentes Storage-Produkt geben, aber nur, wenn es fokussiert darauf bleibt, Proxmox-Cluster zu bedienen, statt jedem erdenklichen NAS-Feature hinterherzujagen.

Dieses dritte Lager kommt der Wahrheit wahrscheinlich am nächsten. Proxmox muss TrueNAS weder töten noch klonen und schon gar nicht zu einem weiteren aufgeblähten NAS mit App-Katalog und Identitätskrise werden. Ein sauberer, fokussierter Storage-Begleiter, aufgebaut um ZFS, Shared Block- und File-Exports, Snapshots und PVE-bewusste Workflows, ist dagegen keine alberne Idee. Das ist die Art von fehlendem Puzzlestück, nach dem Nutzer zu fragen beginnen, wenn eine Plattform wichtig genug wird, um das ganze Lab oder Unternehmen darum herum zu organisieren.

Offen bleibt, ob Proxmox diese Verantwortung übernehmen will. Denn Storage zu bauen ist einfach, auf dieselbe Weise, wie eine Brücke zu bauen einfach ist: Die Form ist offensichtlich, die Materialien existieren, und alle sind sich einig, wo das andere Ufer liegt. Der schwierige Teil besteht darin, dass die Leute ihr auch vertrauen, wenn sie darüberfahren.