Garagenwagen

von Andreas Stolzenberger

Moderne Cloudanwendungen sichern Daten in S3-Objektspeichern. Wer diese nicht bei den üblichen Hyperscalern, sondern lieber selbst hosten will, nutzte bislang gerne das Open- Source-Programm MinIO. Doch dessen Hersteller beschneidet mittlerweile Open-Source-Features auf Kosten eines kommerziellen KI-Angebots. Wir schauen, was hinter AIStor steckt und ob das freie OpenMaxIO und Garage als mögliche S3-Alternativen für einfache Umgebungen zu gebrauchen sind.

Wer für kleine und mittelgroße Projekte einen zuverlässigen, selbst gehosteten S3-Storage-Server benötigt, der greift in der Regel zum frei verfügbaren Open-Source-Storage-Server MinIO [1]. Bis vor wenigen Monaten erhielten Anwender neben dem clusterfähigen S3-Objektspeicher auch ein schickes Web-GUI, um den Storage-Server zu verwalten. Doch ohne Vorwarnung kam die böse Überraschung: Mit dem Mai-Release verschwanden alle Admin-Funktionen aus der Weboberfläche und übrig blieb nur der Objektbrowser. Betreiber der freien MinIO-Variante müssen ihren Server nun über die Kommandozeile administrieren.

MinIO beschneidet freie Version

Damit ergeht es MinIO so wie vielen anderen erfolgreichen Open-Source-Projekten: Die Macher wenden sich langsam, aber sicher von den einstigen Prinzipien ab und legen den Fokus auf kommerzielle, lizenzpflichtige Software. Hier folgt Min-IO Vorbildern wie Nginx, Docker oder Redis. Es ist natürlich legitim, wenn Entwickler kommerzielle Versionen vorstellen, um damit Geld zu verdienen und die Weiterentwicklung zu finanzieren. Aber in der Regel erweitern die Anbieter den Versionsumfang der kostenpflichtigen Variante, um gegenüber der freien einen Kaufanreiz zu schaffen – gerade bei Speicherplattformen geben Unternehmen in der Regel gern Geld für professionellen Support aus.

Schade ist hingegen, wenn ein Hersteller wie bei MinIO etablierte und bekannte Funktionen aus der freien Version herausnimmt, um damit seine Community-Edition bewusst abzuwerten. Der Anbieter begründet die Umstellung mit der Aussage, er hätte nicht genug Ressourcen, um parallel ein verlässliches, freies, aber funktionell abgespecktes Admin-GUI für die Community-Edition und die vollumfängliche Benutzeroberfläche des kommerziellen AIStor [2] zu entwickeln.

GUI mittels Fork: OpenMaxIO

Wer die freie Variante von MinIO mit dem vollen GUI-Funktionsumfang nutzen möchte, hat aktuell zwei Optionen: Entweder nutzt er das letzte Container-Image mit integrierter Admin-Oberfläche "quay.io/ minio/minio:RELEASE.2025-04-08T15-41-24Z". Alternativ haben Community-Entwickler das Web-GUI-Repository geforkt und möchten nun mit "OpenMaxIO UI" [3] ein Admin-UI für die jeweils aktuelle MinIO-Version zur Verfügung stellen. Ob das funktioniert, bleibt abzuwarten. Leider hält sich die Aktivität der Community-Entwickler im GitHub-Repository aktuell in Grenzen.

In einem kurzen Testsetup haben wir einen S3-Server via Podman und "minio:latest"-Image aufgesetzt:

Auf einem separaten Mini-PC haben wir dann mit den Node.js-18- und Go-Build-Tools gemäß Anleitung die OpenMaxIO-Konsole eingerichtet, was auch funktionierte. Allerdings mussten wir hier den Git-Checkout auf eine alte Version zurücksetzen, was leider wieder ein Beweis dafür ist, dass OpenMaxIO derzeit nur ein Fork der alten Version, aber keine Weiterentwicklung darstellt.

Wer also auf MinIO als S3-Server setzen will, wird früher oder später nicht um eine kommerzielle Lizenz herumkommen. Es bleibt nicht auszuschließen, dass der Hersteller irgendwann nicht nur das freie Web-GUI, sondern gleich den kompletten Server auf eine geschlossene Lizenz umstellt.

MinIO AIStor

Entsprechend der neuen Ausrichtung hin zum kommerziellen SDS-Objekt-Storage bewirbt MinIO jetzt AIStor als sein wesentliches Produkt. Es basiert auf dem bekannten, Cluster-fähigen Objekt-Storage-Unterbau, fügt diesem aber ein paar neue Funktionen sowohl im Front- als auch im Backend hinzu. Zu den bekannten Kernfeatures zählen unter anderem Objektreplikation in einem MinIO-Cluster, Objektversionierung und -verschlüsselung, Access-Management sowie eben das komfortable Web-GUI.

Neu hinzugefügt hat MinIO eine Reihe von Funktionen, die den Umgang mit KI-Setups verbessern – das "AI" in AIStor ist damit nicht ein Marketing-Gag, um irgendwie auf der Welle des KI-Hypes mitzuschwimmen, so wie das bei vielen anderen Produkten der Fall ist. Als zusätzliches Frontendprotokoll unterstützt AIStor mit dem "AIHub" ein Hugging-Face-API. Für KI-Setups ist Hugging Face [4] in etwa das, was GitHub für Codeprojekte darstellt: Ein Repository, das Modelle und Versionen verwaltet. Mit einem Hugging-Face-kompatiblen API können lokale oder Airgapped-Umgebungen mit KI-Anwendungen nun ohne Codeänderungen ihre Modelle in bekannter Hugging-Face-Manier verwalten, wobei die Applikationen dabei mit AIStor anstatt mit dem Internet-Service von Hugging Face kommunizieren.

Schnell und teuer

Ein weiteres wesentliches AI-Feature von AIStor ist "S3 over RDMA". Die Abkürzung steht für "Remote Direct Memory Access" und vernetzt das DMA-Konzept. DMA wurde schon in den 80ern eingeführt, um die damals noch schwachen CPUs zu entlasten. Geräte wie SCSI-Adapter oder Ethernet-Controller konnten Daten "vorbei an der CPU" direkt in definierte RAM-Fenster transferieren. In den 90ern und frühen 2000ern kamen dann InfiniBand-Adapter zum Einsatz, um via RDMA Memory-Seiten in HPC-Clustern zu verteilen.

Im Lauf der Zeit ersetzte das günstige Ethernet zunehmend spezialisierte Netzwerktechnologien wie FibreChannel für Storage oder InfiniBand für RDMA. Die speziellen Protokolle wanderten in Ethernet- (Layer 2) oder IP- (Layer-3) Frames, wie FCoE, iSCSI oder eben RoCEv1 (RDMA over Converged Ethernet, Layer 2) und RoCEv2 (over IP, Layer 3).

AIStor kann RoCEv2 für mehre Zwecke verwenden: Zum einen beschleunigt es Objekt-Replikationen in schnellen Netzwerken wie 400-GBit/s-Ethernet mit Transferraten von bis zu 50 GByte/s. So kann AIStor dann auch zügig mit synchroner Replikation Daten auf Knoten verteilen. Zudem kooperiert MinIO bei der RDMA-Implementation mit NVIDIA, das 2020 den InfiniBand-Hersteller und RDMA-Spezialisten Mellanox übernommen hat. NVIDIA verwendet RDMA und DMA, um Datenblöcke mit dem VRAM von GPUs auszutauschen. Die AIStor-Anbindung erlaubt es dann, große KI-Modelle flott vom verteilten redundanten Speicher direkt in das GPU-VRAM auf den KI-Knoten zu bringen.

Alles, was mit KI zu tun hat, fällt dementsprechend teuer aus. Die GPU-Karten kosten ab 10.000 Euro aufwärts, 400-GbE-Adapter liegen bei rund 3000 Euro und die passenden 400-GbE-Switches fangen bei 25.000 Euro an. So ist kaum verwunderlich, dass MinIO bei AIStor nicht gerade zimperlich bei den Lizenzkosten ist: Die jährliche Gebühr liegt bei 96.000 US-Dollar, was eine Kapazität von 400 TByte einschließt. Wem das ein bisschen zu hochpreisig ausfällt, weil für reguläre Anwendungen ein simpler S3-Storage völlig ausreicht, muss künftig wohl nach alternativen S3-Speichern Ausschau halten. Ceph ist hier natürlich immer eine zuverlässige, wenn auch nicht ganz simple Option, im Test auf Seite 24 haben wir uns außerdem SeaweedFS angeschaut.

Freie Alternative Garage

Von der Non-Profit-Organisation Deuxfleurs aus Frankreich stammt der S3-Server Garage [5]. Der Anbieter möchte damit einen simplen, ressourcensparenden, aber zuverlässigen S3-Dienst bereitstellen. Garage läuft auf x86-64- oder ARM-CPUs (ab v7) und benötigt lediglich ein System mit 1 GByte RAM. Der Server läuft im Userspace, als Docker/Podman-Container oder via Helm-Chart auf Kubernetes. Nutzer setzen einen oder mehrere Konten mit der entsprechenden Redundanz (zwei oder drei Kopien) auf. Ein Single-Node-Setup ohne Redundanz ist für Testzwecke möglich.

Die Basiskonfiguration jedes Knotens mit Verzeichnissen und Schlüsseln schreibt der Administrator in eine simple TOML-Datei. Zusätzlich betreibt jeder Knoten eine LMDB- oder SQLite-Datenbank für die laufende Konfiguration. Jeder einmal ausgerollte Knoten erhält eine eindeutige ID und ein vorgegebenes Speicherkontingent. Mithilfe der ID und dem zuvor festgelegten Schlüssel schaltet der Admin seine Knoten zu einem Cluster zusammen. Sogenannte Layouts steuern Zonen, die Knoten und Speicherkapazitäten enthalten. In diesen Zonen legen Nutzer dann ihre S3-Buckets an und legen die gewünschten Objekte darin ab.

Die Konfiguration und Wartung von Garage erfolgt in erster Linie über das CLI. Alternativ gibt es ein Web-GUI-Projekt, das dem Service ein Frontend mit Dashboard und einfachen Admin-Diensten und einem Objektbrowser spendiert.

Im kurzen Test setzen wir Garage auf einem älteren Mini-Computer Odroid C2 ein. Das System nutzt einen Cortex-A53-SOC (ARMv8, Quad-Core), 2 GByte RAM, eine 128-GByte-SD-Karte und läuft unter dem OS Armbian 25.1 (basierend auf Debian 12.11).

Dort starten wir den Garage-Server und das Web-GUI aus den Binaries, die auf GitHub zum Download bereitstehen. Für den Test mit einem Single-Node-Setup passen wir die empfohlene "garage.toml"-Konfigurationsdatei etwas an:

Der Rest bleibt prinzipiell wie in der Dokumentation. Die Basiskonfiguration für Layout, Bucket und Access Key erledigt das CLI in wenigen Minuten und schon steht der Basis-S3-Dienst im LAN zur Verfügung. Über das CLI erhalten wir mit garage status die ID des Clusters, die wir im Anschluss in das Layout der Zone "dc1" übernehmen:

Es folgt der erste Bucket, ein Access-Key und die Zugriffsregel:

Folgender Befehl gibt dann die Key-ID und das Secret zurück:

Fertig ist der erste S3-Bucket – der Zugriff erfolgt via "http://odroid:3900". Dem vollständigen Dienst fehlt es dann nur noch an der TLS-Verschlüsselung via Loadbalancer oder Reverse-Proxy. Für Tests via HTTP reicht das Setup aber aus.

Fazit

AIStor von MinIO ist ein interessanter Ansatz für Enterprise-KI-Anwendungen. Mit einem Preis von fast 100.000 US-Dollar im Jahr ist die Software als reiner S3-Speicher jedoch nicht mehr interessant. MinIO hätte hier vielleicht zweigleisig fahren sollen: Ein vernünftig lizenzierter S3-Storage ohne KI-Schnörkel, der auch kleine und mittelgroße Installationen anspricht, und AIStor als separater High-End-SDS.

So hingegen dürften Anwender, die lediglich S3-Dienste benötigen, weiter bei der quelloffenen Version bleiben oder zu Alternativen wie Ceph und Garage wechseln. Garage stellt sich als solide S3-Serveroption für kleine Installationen dar, die ebenfalls mit wenigen Ressourcen auskommt und gute Dienste leistet.

S3-kompatible Alternativen zu MinIO

Garagenwagen

MinIO beschneidet freie Version

MinIO beschneidet freie Version

GUI mittels Fork: OpenMaxIO

MinIO AIStor

Schnell und teuer

Freie Alternative Garage

Fazit