IT-Verantwortliche von kleinen und mittelgroßen Unternehmen haben es dieser Tage wahrlich nicht leicht. Schlimm genug schon, dass VMware nach dem Kauf durch Broadcom so heftig an der Preisschraube gedreht hat, dass das vielerorts liebgewonnene vCenter für manche Unternehmen schlicht unbezahlbar geworden ist. Zu allem Überfluss haben in den vergangenen Jahren auch die Hersteller von Storage-Systemen kontinuierlich ihre Preise erhöht. Fällt dieser Tage ein bestehendes NetApp-Device aus der Garantie, ist es längst nicht mehr überall so, dass Firmen vom selben Hersteller einfach eine neue Appliance bestellen und sich das Thema Storage dadurch für fünf weitere Jahre vom Hals schaffen.

Stattdessen ist Sparen angesagt, und genau dabei rücken immer häufiger auch Alternativen auf Open-Source-Basis in den Mittelpunkt des Interesses. Ceph etwa hat sich längst als quelloffene Alternative zum klassischen NAS-Storage etabliert. Kein Wunder, denn auf Basis des Objektspeichers RADOS gibt es sich kommunikationsfreudig und unterstützt neben dem blockbasierten Zugriff auch CephFS als POSIX-kompatibles Dateisystem sowie eine HTTP-Schnittstelle, die Amazons S3-Protokoll versteht. In Sachen Redundanz und Betriebssicherheit genießt Ceph zudem einen ausgezeichneten Ruf. Anders als klassische NAS-Appliances läuft es auf Standardhardware von der Stange. Blöd nur, dass sich die Einrichtung eines Ceph-Clusters als deutlich komplexer entpuppt als es bei einem vergleichbaren Produkt üblicherweise der Fall ist. Und das Thema ist in den vergangenen Jahren kaum besser geworden, denn mit nicht weniger als drei offiziellen Deployment-Werkzeugen haben die Ceph-Entwickler ihre Nutzerschaft seit 2014 gequält – und da sind die vielen alternativen Methoden noch gar nicht enthalten.

"Gar kein Problem" dachte sich unser Testkandidat PetaSAN und möchte als Ceph-Appliance jedermann den Bau und Betrieb von Ceph-Clustern mit mehreren PByte Nettokapazität ermöglichen. Das Produkt per se ist kostenlos zu beziehen, seine Brötchen verdient der Hersteller mit Support-Dienstleistungen. Was im Open-Source-Umfeld auch durchaus Sinn ergibt: Die wenigsten Unternehmen werden Ceph sofort gut genug durchdringen, um in brenzligen Situationen operativ wirklich handlungsfähig zu sein. Da ist es gut und beruhigend, den Hersteller im Rücken zu haben, der notfalls die Kohlen aus dem Feuer holt.

Interessanterweise ist PetaSAN mit seinem Ansatz zudem weitgehend allein auf weiter Flur. Red Hat selbst vermarktet als Eigentümer Ceph bloß noch in spezifischen Konfigurationen und meist zusammen mit Hardware von IBM. SUSE hat das eigene Produkt auf Ceph-Basis längst eingestampft. Bleibt noch Canonical mit Ubuntu, auch hier ist aber Selberbauen die Devise und ein fertig abgepacktes Produkt seitens des Anbieters existiert nicht. Entsprechend erfreut sich PetaSAN im Augenblick großer Beliebtheit: Wer ein bestehendes NAS ersetzen möchte, stößt früher oder später auch auf die Ceph- Appliance, die frei für jedermann zum Download bereitsteht und einen laufenden Ceph-Cluster auf Standardhardware in kürzester Zeit verspricht.

Grund genug, dem Produkt auf den Zahn zu fühlen. Weil PetaSAN besonders die einfache Ceph-Installation bewirbt, beschäftigen wir uns mit der Komplexität der Inbetriebnahme. Danach geht es um den technischen Unterbau und wir betrachten die eingesetzten Komponenten und wie zukunftssicher das Produkt ist. Ebenfalls wichtig ist die Frage nach dem alltäglichen Betrieb und den Features, die Administratoren zur Verfügung stehen, um die Appliance bequem zu betreiben und zu warten. Von zentraler Bedeutung ist bei PetaSAN auch die grafische Oberfläche. Die ist nicht deckungsgleich mit dem Ceph-Dashboard, will aber laut den PetaSAN-Machern vieles besser machen als dieses. Schließlich besticht ein Ceph-Cluster immer auch durch die Fähigkeit zur Skalierbarkeit in die Breite. Wie PetaSAN dies umsetzt, wollten wir ebenfalls in Erfahrung bringen.

PetaSAN besteht aus einem ISO-Abbild, das im Internet frei zum Download bereitsteht. Seine Autoren sehen vor, dass PetaSAN auf Standardservern mit mindestens zwei Netzwerkschnittstellen zum Einsatz kommt. Davon dient eine der Kommunikation mit Clients und die andere der Kommunikation der Ceph-Dienste untereinander. Letztere macht in einem RADOS-Cluster traditionell eine große Menge des anfallenden Traffics aus, weil die synchrone Replikation bei Ceph im Hintergrund zwischen den Diensten des Clusters geschieht. Sollen zusätzliche Dienste wie iSCSI, CIFS/SMB, NFS oder S3 zum Einsatz kommen, bietet PetaSAN die Möglichkeit, hierfür weitere Netzwerkschnittstellen zu integrieren.

Die GUI in der Installation erinnert zwar an Windows-98-Zeiten, erledigte ihre Aufgabe letztlich aber gut. Ein eigener Quick-Start-Guide half uns zudem bei der anfänglichen Installation und beschreibt die gängigsten Konfigurationsoptionen. Nach der Installation per ISO-Datei stand uns bereits das PetaSAN-Dashboard zur Verfügung, mit dessen Hilfe wir weitere grundlegende Einstellungen vornahmen. Das ist auch nötig, denn mehr als einen nackten RADOS-Cluster rollt PetaSAN in der Standardkonfiguration nicht aus. Pools, die RADOS-eigene Einheit für konfektionierten, nutzbaren Speicher legt PetaSAN nämlich ohne Auswahl der entsprechenden Dienste ebenso wenig an wie Frontends wie iSCSI oder NFS (über den Umweg des RADOS Block Device, RBD). In Summe präsentiert sich das Produkt im Hinblick auf das initiale Setup aber als umfangreich und funktional. Das Handling mehrerer Netzwerkschnittstellen für Traffic in verschiedene Richtungen und für verschiedene Dienste funktionierte in Summe gut – fast scheint es uns, als sei dies ein Hauptaugenmerk bei der PetaSAN-Entwicklung.

Auch das Deployment notwendiger RADOS-Dienste verlief im Test in Summe zufriedenstellend. Dabei ist zu beachten, dass RADOS selbst hier verschiedene Schwierigkeitsstufen kennt. Die Schnittstelle für RBD etwa ist in einem laufen RADOS-Cluster quasi latent aktiv. Legt der Admin einen entsprechenden Pool für RBD-Laufwerke an, ist der Zugriff per RBD-Protokoll direkt im Anschluss möglich. Dann sind auch virtuelle Instanzen aus einem RADOS-Cluster heraus unmittelbar zu bespielen, denn die meisten Distributionen liefern mittlerweile eine Version von Qemu aus, die sich über die RBD-Bibliothek "librbd" im Hintergrund nativ mit einem RADOS-Cluster verbinden kann. Wer stattdessen VMware oder Proxmox zur Virtualisierung nutzt, kommt ebenfalls auf seine Kosten: Mit nur wenigen Mausklicks in der PetaSAN-GUI konnten wir wahlweise ein Laufwerk per iSCSI-Protokoll exportieren oder mittels NFS zur Verfügung stellen. Die NFS-Freigabe basiert im Hintergrund dann aber auf CephFS, dem POSIX-kompatiblen Ceph-Dateisystem. Die für dessen Funktionalität nötigen Metadaten-Server rollte PetaSAN ohne weiteres Zutun unsererseits automatisch aus, es legte zudem ein entsprechendes CephFS-Dateisystem an und machte es wie gewünscht verfügbar.

Die S3-Schnittstelle von Ceph hilft, einen lokalen S3-Nachbau zu schaffen. Die gelang im Test ebenfalls mit wenigen Mausklicks. Dabei bildete die PetaSAN-GUI weitgehend die Vorgaben des RADOS-Gateways ab, das die S3-Schnittstelle zur Verfügung stellt: S3 lässt sich hierarchisch und aufgeteilt in Zonen und Realms ausrollen, sodass auch standortübergreifende Setups mit S3 möglich sind.

Einen Schnitzer erlaubt sich PetaSAN allerdings, wenn es um die Benutzerverwaltung im RADOS-Gateway geht. Denn dieses unterstützt auch die Authentifizierung per LDAP. Es ist also möglich, alle Benutzer für das RADOS-Gateway in LDAP zentral zu hinterlegen und sämtliche Instanzen des Gateways dann auf eben dieses LDAP zugreifen zu lassen. Nicht so bei PetaSAN: Hier besteht lediglich die Option, eine Benutzerdatenbank für das RADOS-Gateway direkt in der Software zu pflegen, also lokale Benutzer zu haben. Das stellt kleinere Installationen vermutlich nicht vor eine Herausforderung, gerade dann nicht, wenn es in der Firma gar kein zentrales Benutzerverzeichnis gibt. Sollte ein lokales LDAP oder Active Directory vorhanden sein, ist aber davon auszugehen, dass der Admin dies auch für die Bespielung des RADOS-Gateway mit Benutzern verwenden möchte – eine Funktion, die PetaSAN schlicht nicht bietet.

In Sachen Inbetriebnahme gibt es an PetaSAN mithin zunächst wenig auszusetzen. Deutlich weniger rosig stellte sich die Situation aber dar, als wir der Appliance unter die Haube schauten. Hier ergaben sich gleich mehrere Gründe für hochgezogene Augenbrauen. Das begann schon beim Basissystem: Eigentlich basiert PetaSAN auch in der aktuellen Version noch auf dem Userland von Ubuntu Linux 20.04. Das ist bereits merklich abgehangen, mit moderner Software bekommt der Administrator es hier also eher nicht zu tun.

Aus irgendeinem Grund haben die PetaSAN-Verantwortlichen aber zudem beschlossen, den eigentlich zu Ubuntu 20.04 gehörenden Kernel durch jenen Kernel zu ersetzen, den SUSE Linux als Bestandteil seiner Enterprise-Distribution in der Version 15 SP5 ausliefert. Praktisch bekommt der Administrator also ein Frankenstein-System mit einem einigermaßen aktuellen Kernel – nominal handelt es sich um Linux 5.14.21, das allerdings wie üblich bei SUSE bis zur Unkenntlichkeit gepatcht ist – und einem ziemlich angestaubten Userland von Canonical. Ob die Mühe der Kernelportierung den Nutzen rechtfertigt, sei dahingestellt: Für Ubuntu 20.04 steht mittlerweile schließlich Linux 5.15 als HWE-Backport aus Ubuntu 22.04 zur Verfügung, den Canonical ebenfalls heftig patcht und der dem SLES-Kernel in vielerlei Hinsicht in nichts nachstehen dürfte. Käme stattdessen das Userland von Ubuntu 22.04 zum Einsatz, stünde in Form von Linux 6.5 sogar ein deutlich modernerer Kernel zur Verfügung. Warum der antiquierte Userland von Ubuntu 20.04 zum Einsatz kommt, ist umso unverständlicher, wenn wir und vor Augen halten, dass die genutzte Ceph-Version die Version 17 alias Quincy ist, die mit Ubuntu 22.04 problemlos funktioniert.

Doch auch in Sachen Ceph 17 gibt es Grund zur Beanstandung. Denn selbst die aktuelle PetaSAN-Version 3.3.0, die vom Mai 2024 datiert, liefert noch Ceph 17 alias Quincy aus, das seinerseits über zwei Jahre alt ist und seitens seiner Entwickler offiziell nicht mehr unterstützt wird. De facto sind die PetaSAN-Macher hier also allein auf weiter Flur, denn Sicherheits- oder Bugfixes seitens Red Hat wird es für die in PetaSAN verarbeitete Ceph-Version ebenso wenig geben wie technische Unterstützung im Problemfall. Weil das Update von Ceph 17 auf Ceph 18 nahtlos möglich ist und Ceph 18 alias Reef diverse wichtige Fehlerkorrekturen enthält, ist unerklärlich, wieso sich PetaSAN freiwillig mit der antiquierten Ceph-Version herumschlägt. Zumal sich die Situation absehbar kaum verbessern wird: Ceph 20 ist bereits in Vorbereitung und wird zentrale Neuerungen bieten wie die Unterstützung des iSCSI-Ersatzes NVMe-over-Fabric, von denen auch PetaSAN massiv profitieren könnte. Solange die Entwickler jedoch ein Softwaremuseum betreiben, können sie von derartigen Features nur träumen.

Noch ein weiterer Grund gibt bei PetaSAN Anlass zur Sorge. Eingangs hatten wir bereits erwähnt, dass Ceph selbst einige Anläufe brauchte, um ein funktionales, allgemein akzeptiertes Deployment-Werkzeug auf die Beine zu stellen. Dieses liegt in Form von "cephadm" mittlerweile aber vor. Es bringt ein eigenes Management-Framework mit, das auch Orchestrierung und Automation für die Ceph-Dienste beherrscht und über die "ceph-mgr"-Komponenten innerhalb des Clusters befeuert wird.

Von derart modernem Schnickschnack hält man bei PetaSAN aber offenbar wenig. Das gesamte Deployment-Modell ist stattdessen eine Eigenkonstruktion, die auf standardisierte Werkzeuge wie "cephadm" komplett verzichtet. Das bringt mehrere elementare Nachteile mit sich. Zunächst hat sich die Ceph-Welt mittlerweile weitgehend darauf geeinigt, dass Ceph künftig vor allem in Container-Form zum Einsatz kommen soll. Das hat den Vorteil für Red Hat, dass es pro Ceph-Release bloß noch einen Satz Container-Abbilder pflegen muss, statt für jede Distribution in jeder Version einzelne Pakete anzubieten. Andererseits bringt der Betrieb auf Container-Basis aber auch im Alltag erhebliche Vorteile, etwa bei Updates von einer Ceph-Version zur nächsten. Der Betrieb per Container ist zudem eine Voraussetzung dafür, dass sich "cephadm" und die Ceph-Manager sinnvoll nutzen lassen.

PetaSAN hingegen rollt Ceph noch immer auf Grundlage der Ceph-Pakete für Ubuntu 20.04 aus, von Containern ist also weit und breit keine Spur. Das macht Upgrades von einer PetaSAN-Version beispielsweise hin zu einer neuen Major-Version unnötig kompliziert. Das Fehlen von "cephadm" führt zudem dazu, dass die PetaSAN-Entwickler für ihre Appliance alle Standardprozesse nachbauen müssen, die in "cephadm" längst fertig und erprobt zur Verfügung stehen. Auch das Deployment des RADOS-Gateways, der NFS-Dienste oder der iSCSI-Targets ist in PetaSAN insofern eher ein Bretterverschlag aus diversen PetaSAN-spezifischen Shell-Skripten als ein Prozess, der die seitens der Entwickler ohnehin bereitgestellten Standardwerkzeuge nutzt.

Aus Sicht des Administrators lässt sich an dieser Stelle einwenden, dass es sich bei PetaSAN schließlich um eine Appliance handelt und es egal ist, wie diese entsteht. Hinter PetaSAN steht aber kein Großkonzern, sondern ein eher kleines Unternehmen in Ägypten, das nicht beliebig viel Manpower zur Verfügung hat und das unter der Last, die die Wartung der eigenen Custom-Ceph-Distribution hervorruft, ziemlich ächzen dürfte. So zumindest ist auch zu erklären, wieso PetaSAN in Sachen Ceph-Version und Feature-Set so weit hinterherhinkt, wie es zum Teil der Fall ist.

Der zum Teil verworrene Unterbau schlägt unmittelbar auf de Admin-Alltag durch. Grundsätzlich gilt: Ist ein Ceph-Cluster mit PetaSAN einmal eingerichtet und konfiguriert, läuft dieser ohne externe Einflüsse wie etwa den Ausfall eines Speicherlaufwerks zunächst reibungslos. Das liegt jedoch weniger an PetaSAN, sondern eher an der impliziten Stabilität von RADOS. Wer sich nicht ständig mit der PetaSAN-GUI herumschlagen möchte, findet zudem die reguläre CLI-Schnittstelle vor, also das "ceph"-Programm auf der Shell, das ebenfalls funktioniert. Aufgaben wie das neue Anlegen eines CephFS-Dateisystems oder eines neuen Pools für RBD konnten wir mithin per GUI oder Kommandozeile genauso gut erledigen.

Auch die meisten außergewöhnlichen Aufgaben deckte PetaSAN im Test gut ab. Das Hinzufügen zusätzlicher Server etwa ging per GUI leicht von der Hand und war auch auf der Shell zu bewerkstelligen. Dasselbe gilt für den Austausch von Laufwerken, die bereits Teil des Clusters waren, aber ausgefallen sind. Hier wurde PetaSAN den Ansprüchen an eine Appliance durchaus gerecht, denn es ist ähnlich komfortabel zu bedienen wie beispielsweise ein NetApp-Gerät mit ONTAP-Betriebssystem.

Kritisch wird es allerdings, wenn mal etwas schiefläuft, wenn sich etwa ein ausgefallenes Speicherlaufwerk nicht ohne Weiteres aus dem Cluster entfernen lässt. Dann kommt die GUI schnell an ihre Grenzen und auf der Kommandozeile fällt dieselbe Arbeit an, die auch ohne PetaSAN nötig wäre. Zum Teil sind hier wegen des Fehlens moderner Werkzeuge wie "cephadm" sogar mehr Klimmzüge nötig, als es bei einer zeitgenössischen, sinnvoll gepflegten Ceph-Installation ohne PetaSAN der Fall wäre. Das nervt und macht die Freude, die PetaSAN anfangs vermittelt, rabiat zunichte.

Überhaupt erweist sich die PetaSAN-GUI als guter Begleiter für alltägliche Aufgaben, offenbart aber große Schwächen, wenn es um wichtige Details geht. In RADOS kommt der CRUSH-Algorithmus für die Platzierung von Daten auf den Laufwerken des Clusters zum Einsatz. Dessen Verhalten lässt sich über eine eigene Konfiguration, die sogenannte CRUSH-Map, bis ins kleinste Detail konfigurieren. Wer beispielsweise Betriebssicherheit über mehrere Racks oder lokale Brandschutzzonen erreichen möchte, dreht genau dafür an den Stellschrauben der CRUSH-Map.

PetaSAN hat die Konfiguration der CRUSH-Map in der eigenen GUI zwar abgebildet, aber nicht in einer Art und Weise, die Ceph-Neulinge vor den typischen Fehlern bewahrt. So schlägt die Oberfläche beispielsweise keinen Alarm, wenn ein Administrator die CRUSH-Regeln für einzelne Pools so konfiguriert, dass gar keine physischen Laufwerke mehr übrig bleiben, die der Cluster überhaupt noch für den jeweiligen Pool verwenden darf. Der Cluster schwenkt dann auf den "HEALTH_CRIT"-Zustand und zeigt Fehler an, mit denen ein erfahrener Ceph-Admin womöglich noch etwas anzufangen weiß, ein unbedarfter Ceph-Neuling aber nicht. Der falsche Klick in der Administrationsoberfläche führt damit möglicherweise dazu, dass der gesamte Cluster temporär offline geht. Sinnvoll und notwendig wäre es hier stattdessen, dass die PetaSAN-GUI etwaige Einstellungen gar nicht erst zulässt, sondern ihr Einspielen mit einer Fehlermeldung quittiert.

Darüber hinaus erscheint fragwürdig, wie gerechtfertigt der Aufwand noch ist, den PetaSAN mit seiner eigenen GUI treibt. Zu Ceph gehört seit vielen Jahren schließlich das Ceph-Dashboard, das aus dem ehemaligen openATTIC hervorgegangen ist und das die Ceph-Entwickler nach wie vor weiterentwickeln. Es zeigt eine ähnlich bunte und eingängige Übersicht über den aktuellen Zustand des Clusters und ermöglicht ebenfalls verschiedene Einstellungen und Rekonfigurationen. Das Deployment von Nodes gehört zwar nicht zum primären Aufgabenbereich des Ceph-Dashboards, dafür hat ein modernes Ceph aber eben auch sein eigenes Orchestrierungswerkzeug an Bord und etwaige Änderungen sind mit "cephadm" leicht durchgeführt. In Sachen Trending und Statistik zeigt das Dashboard zudem viele Graphen an, die auch bei PetaSAN zum Lieferumfang gehören – ist auf Knopfdruck aber beliebig erweiterbar.

Überhaupt muss an dieser Stelle die Frage erlaubt sein, ob sich der Zustand eines RADOS-Clusters nicht mit Prometheus und Grafana besser visualisieren lässt, zumal dann eigene Dashboards möglich sind, die auch andere Faktoren wie den Zustand der physischen Systeme umfassend darstellen können. Letztendlich ist die PetaSAN-GUI nett und funktioniert weitgehend ordentlich, dient meistens aber nur dazu, Features anzubieten, die in Ceph ohnehin vorhanden sind und bewahrt andererseits den Administrator nicht davor, dysfunktionale Konfigurationen zu bauen.

Der Eindruck einer Bastellösung, den PetaSAN phasenweise hinterlässt, rächt sich beim Thema Skalierbarkeit. Die ist gewiss kein unwichtiges Thema im Ceph-Kontext, denn schließlich ist dessen zentrales Versprechen, Speicher beinahe beliebiger Größe bauen zu können. Das umfasst einerseits die Möglichkeit, beliebig viele Laufwerke in beliebig vielen Servern dem Cluster hinzuzufügen. PetaSAN gibt sich bei diesem Teilaspekt keine Blöße.

Schwierig wird die Sache hingegen, wenn CephFS ein Thema ist. Das POSIX-kompatible Dateisystem war im Ceph-Kontext lange Zeit so etwas wie das hässliche Entlein, auch weil es als letzte der Schnittstellen produktiv nutzbare Reife erreichte und anfangs nicht gut oder schnell funktionierte. Diese Probleme sind mittlerweile aber aus der Welt geschafft und mittels "cephadm" lässt sich CephFS gut und sicher betreiben. Ein Knackpunkt bei CephFS sind dabei die Metadatenserver: Diese fungieren als großer Cache für die POSIX-Metadaten, die in einem eigenen Pool im Objektspeicher liegen. Gerade größere Setups benötigen meist mehrere aktive Metadatenserver, die sich den POSIX-Baum dann in einer als "Subtree Partitioning" getauften Art und Weise aufteilen. Jeder aktive MDS ist dabei für einen Teil des Dateisystembaums zuständig. Damit beim Ausfall eines MDS nicht eine längere Downtime für Clients entsteht, ist es sinnvoll, jedem aktiven Metadatenserver einen "Replay"-Server als Hot Standby zur Verfügung zu stellen. Zudem sollten IT-Verantwortliche clusterweit mindestens einen Cold-Standby-MDS betreiben, der im Falle eines Ausfalls der neue Replay-Server für eine aktive MDS-Instanz werden kann.

Ein normales CephFS-Setup mit zwei aktiven Metadaten-Servern braucht mithin mindestens fünf laufende Instanzen des Metadatendienstes. Genau dieses Setup kann PetaSAN aber nicht ausrollen. Denn das vermurkste Deployment-System kennt nur eine "Infrastruktur"-Rolle, in der sowohl der Monitoring- als auch der MDS-Dienst enthalten sind. Und der ist auf drei Dienste pro Cluster beschränkt. Zwar hat der Admin die Möglichkeit, weitere MDS-Instanzen an PetaSAN vorbei in den Cluster aufzunehmen. Dann ist aber keine Appliance erforderlich, sondern dies lässt sich mittels der Ceph-Bordmittel erledigen. PetaSAN liefert mithin gerade keine überzeugenden Argumente für seine Daseinsberechtigung in einem solchen Setup.

PetaSAN hinterlässt insgesamt einen wenig positiven Eindruck. Wer einen einfachen Drei-Knoten-Cluster für Ceph benötigt und auf Features aktueller Ceph-Versionen verzichten kann, kommt mit PetaSAN in kurzer Zeit zu einer laufenden Ceph-Umgebung, etwa als iSCSI-Backend für VMware. Dabei unterstützt PetaSAN sogar Aktiv-Aktiv-iSCSI mit Multipfad-Konfiguration. Verfolgt die IT jedoch Ziele, die jenseits der von PetaSAN definierten Pfade angesiedelt sind, befindet sie sich schnell allein auf weiter Flur.

Die hoffnungslos veraltete Software, mit der PetaSAN antritt, tut ebenso wenig, um den negativen Gesamteindruck aufzubessern, wie das zusammengebastelte Deployment-Framework unter der Haube oder die GUI, die kaum mehr sinnvolle Features bietet als das offizielle Ceph-Dashboard. Wer sich in 2024 erstmals mit dem Bau eines Ceph-Clusters für das eigene Setup befasst, ist mit einer auf Ubuntu 22.04 oder 24.04 basierenden Intrastruktur inklusive "cephadm" und "ceph-mgr" jedenfalls besser bedient. Das ist schade, denn an und für sich ist die Idee hinter PetaSAN gut und richtig. Gelingt es dem Hersteller, das Produkt aus der Vergangenheit in die Gegenwart zu holen, es mit aktueller Software auszustatten und die eigene GUI sinnvoll mit "cephadm" zu integrieren, könnte noch ein Schuh daraus werden. So aber ist PetaSAN eine Ceph-Appliance beinahe ohne jeden Mehrwert im Vergleich mit Werkzeugen, deren "Boxed Product"-Charakter deutlich weniger ausgeprägt ist. Und das, obwohl Letztere mehr Handarbeit auf der Systemebene bedingen.