© alphaspirit / 123RF.com

Suse treibt die Entwicklung beim Projekt Longhorn stetig voran. Mit Hochdruck arbeiten die Entwickler derzeit an der Longhorn Engine V2, einem neuen Unterbau auf Grundlage von SPDK, Intels Bibliothek für den flotten Zugriff auf NVMe-basierte Speichergeräte.

Suse und Storage-Appliance-Produkte – das war in der Vergangenheit selten eine runde Sache. Das beste Beispiel dafür ist der freie Objektspeicher Ceph: Den propagierte Suse erst begeistert und vermarktete ihn in Form eines eigenen Produkts namens Suse Enterprise Storage. Nachdem jedoch Verhandlungen zur Übernahme von Inktank, der Firma hinter Ceph, scheiterten und Red Hat sich das kalifornische Unternehmen einverleibte, gab man das eigene Ceph-Engagement zunächst ersatzlos auf. Später wendet man sich dem Thema Speicher doch wieder zu, nämlich nach dem Zukauf von Rancher: Zusammen mit dem Verwalter für Kubernetes-Installationen holte man sich in Nürnberg auch dessen Speicherlösung für Kubernetes ins Haus, Longhorn.

Hier beweist der Hersteller bisher zumindest in Teilen mehr Durchhaltevermögen: Unter der Führung Suses entwickelt sich Longhorn stetig weiter und wird schrittweise besser. Mittlerweile ist Longhorn, die Ursprungsversion des heutigen Suse Storage, allerdings ein CNCF-Projekt und steht damit unter der Obhut der Linux Foundation. Noch immer gibt Suse aber in Sachen Longhorn-Entwicklung den Ton an.

Im Linux-Magazin war Longhorn zuletzt Anfang 2023 Thema [1]. Seither hat sich beim Projekt eine Menge getan. Es gab viele Verbesserungen im Detail, aktuell arbeiten die Entwickler zudem an einem komplett neuen Unterbau. Der soll das Storage Performance Development Kit nutzen, eine von Intel entwickelte Bibliothek für den flotten Zugriff auf NVMe-Geräte. Die Entwickler versprechen sich davon massive Performance-Gewinne, mehr Stabilität und bessere Administrierbarkeit. Grund genug, genauer hinzusehen: Was hat sich bei Longhorn getan, welche Änderungen sind geplant, wie präsentiert sich die Software heute?

Die Idee hinter Longhorn

Um Longhorn (Abbildung 1) und die aktuell damit verbundenen Entwicklungen zu verstehen, hilft es, sich in Erinnerung zu rufen, mit welcher Mission das Projekt angetreten ist.

Abbildung 1: Longhorn bietet persistenten und nativ mit Kubernetes integrierten Speicher an. Die Lösung entwickelt sich ständig weiter. Aktuell bauen die Entwickler den gesamten Unterbau der Lösung neu.

Longhorn startete innerhalb von Rancher. Dort war man mit den damaligen Speicherlösungen und allen voran mit Ceph nicht zufrieden, und das aus einem bestimmten Grund: Ceph war nicht in Kubernetes integriert. Kubernetes verfügt immerhin über eine Schnittstelle für die Integration von Plugins. Prominent sind dabei vor allem das Container Network Interface (CNI [2]), an das externe SDN-Lösungen wie Cilium, Flannel oder Calico andocken, sowie das Container Storage Interface (CSI [3]). Es dient der Anbindung externen Speichers an eine Containerumgebung.

“Anbindung” ist dabei allerdings mehr oder weniger wörtlich zu verstehen, denn das CSI ermöglicht es zunächst nur, einen bereits vorhandenen, externen Speicher mit Kubernetes zu nutzen. Dabei spielt es für Kubernetes mit seiner CSI-Schnittstelle zunächst keinerlei Rolle, wie der jeweilige Speicher provisioniert wird, wo er steht und wer ihn administriert. Will man etwa Ceph mit Kubernetes verbinden, legt man wahlweise via RBD einen Pool für virtuelle Festplatten oder in CephFS ein eigenes Volume an. Dann erstellt man einen Nutzer, der nur auf diese Ressource zugreifen darf, und hinterlegt die Zugangsdaten im Anschluss in der Kubernetes-Konfiguration. Das CSI-Ceph-Plugin erledigt dann den Rest der Arbeit.

In der hippen Container-Welt ist das aber gerade nicht das, was Entwickler und Admins sich vorstellen, wenn sie von nativer Integration sprechen: Ein laufender Speicher, egal ob Ceph oder eine andere Technik, wird in diesem Konstrukt nicht durch Kubernetes verwaltet. Genau das ist aber das Ziel jeder Kubernetes-Installation. Der Flottenvirtualisierer für Container will möglichst jede im Rechenzentrum anfallende Funktion in Software abbilden und per API steuerbar machen.

Das schließt Administration und Konfiguration von Speicher ausdrücklich ein. Als Longhorn entstand, war es schlicht nicht möglich, Lösungen wie Ceph direkt in Kubernetes zu betreiben und mit dem Werkzeug zu verwalten. Wenn die Longhorn-Entwickler von nativem Kubernetes-Speicher sprechen, meinen sie Speicher, der direkt aus Kubernetes heraus nicht nur betrieben, sondern auch gesteuert und konfiguriert wird.

Die Konkurrenz hat aufgeholt

Allerdings haben andere Lösungen in Sachen Kubernetes-Integration längst aufgeholt. Rook beispielsweise ist ein etabliertes Werkzeug, um Ceph direkt aus Kubernetes heraus zu steuern. Es rollt alle zum Objektspeicher RADOS gehörenden Dienste als Kubernetes-Ressource aus, ebenso die nötigen Dienste für die Frontends, also RBD, CephFS und das RADOS Gateway. Rook rüstet zudem die notwendigen Funktionen nach, um die Konfiguration von Ceph aus Kubernetes heraus zu beeinflussen. Volumes für RBD etwa lassen sich direkt in Rook erstellen. Rook selbst ist dann wieder per CSI an Kubernetes angebunden. So entsteht eine gut nutzbare, durchgehende Lösung.

Parallel dazu lässt sich Ceph aber eben auch außerhalb von und vollständig ohne Kubernetes installieren und nutzen. Der native Kubernetes-Ansatz, den Longhorn verfolgt, hat einen solchen Betrieb hingegen nie vorgesehen. Bis heute ist das empfohlene und de facto einzig nutzbare Szenario für ein Longhorn-Deployment das als Komponente in einer Kubernetes-Installation. Mit ebendiesem Pfund versucht Suse bei seinem Storage-Produkt am Markt zu punkten. Im Fokus stehen dabei vor allem Rancher-Kunden, die sich ein Komplettpaket aus Speicher und Orchestrierung für Container wünschen. Die beglückt man mit dem Gespann aus Rancher und Longhorn perfekt.

Ein neues Herzstück

Vernehmlich murren Longhorn-Nutzer allerdings auch darüber, dass die Software in ihrer jetzigen Form vor allem eines ist: langsam. Diesem Problem nehmen sich die Entwickler konsequent an. Seit Mitte 2023 werkelt man an einem komplett neuen Unterbau für Longhorn. Das unter dem Codenamen Data Engine V2 firmierende Projekt ersetzt praktisch den gesamten bisherigen Longhorn-Code durch einen Rewrite – und der hat es in sich. Um zu verstehen, welche Berge man seitens der Entwickler hier versetzt, ist ein kleiner Ausflug in die Welt der Datenträger nötig.

Die meisten Administratoren nutzen im Alltag NVMe-Laufwerke, ohne ihnen große Beachtung zu schenken. Dabei sind sie verglichen mit den Speicherlösungen der Vergangenheit eigentlich kleine Wunderwerke der Technik. Von Blockspeichern früherer Generationen unterscheiden sich NVMes vor allem durch einen Faktor: Sie sind nicht über einen Storage-Controller mit eigenem Protokoll mit dem Rest des Systems verbunden, sondern fungieren selbst als PCI-Gerät. Entsprechend hängen sie über die PCI-Lanes des Systems direkt an RAM und CPU. Sie arbeiten deshalb insbesondere im Hinblick auf die Zugriffszeiten deutlich flinker als der ohnehin schon pfeilschnelle Speicher in Form klassischer SSDs, die SATA- oder SAS-Schnittstellen nutzen.

Weil hier aber der Storage-Controller als Mittler zwischen den Welten fungiert, ist die inhärente Latenz dieser Protokolle viel größer als bei NVMe-Laufwerken. Wobei “viel größer” in diesem Zusammenhang relativ ist: Tatsächlich geht es hier um Zeiten im Bereich von Tausendstelsekunden. Wird ein Gerät aber intensiv genutzt, addiert sich der Performance-Gewinn durch die hohe Anzahl von Zugriffen beträchtlich. Das zieht noch gar nicht den Umstand in Betracht, dass sich in NVMes andere und vor allem schnellere und bessere Flash-Chips nutzen lassen.

Zugriff auf Geräte

Aus Sicht einer Anwendung im Userspace eines Linux-Systems kommen NVMes und SSDs indes erst einmal ganz ähnlich daher. Beide Geräte lassen sich nur unmittelbar durch den jeweiligen Treiber des Kernels sowie dessen I/O-Stack hindurch verwenden. Auch der Linux-Kernel knabbert insofern ein Stück der Performance weg, wenn Flash-basierte Laufwerke zum Einsatz kommen.

Intel war das zumindest in der Vergangenheit ein Dorn im Auge. Arrivierte Systemadministratoren erinnern sich vermutlich noch an die mit viel Glanz und Gloria vermarkteten Optane-Laufwerke [4] des Herstellers. Anders als gängige NVMes nutzten die mittlerweile eingestellten Optane-SSDs (Abbildung 2) sogenannten 3D-XPoint-Speicher. Das ist eine spezielle Form von Flash-Speicher, die Intel zusammen mit Micron entwickelte und die sich durch besonders geringe Latenz auszeichnete. In den Bereich von Mikrosekunden für einzelne Writes war bis zur Veröffentlichung der gepriesenen Optane-Serie kein Speichermedium vorgedrungen. Das Problem: Die Strukturen des Linux-Kernels waren kaum in der Lage, die Performance von Laufwerken mit 3D-XPoint-Speicher zu den gängigen Anwendungen durchzureichen.

Abbildung 2: Unter dem Markennamen Optane vermarktete Intel eine Weile lang besonders schnelle Flash-Laufwerke. Die gibt es zwar nicht mehr, aber die Idee des direkten Zugriffs auf NVMe-Geräte lebt in Form des SPDK weiter. Quelle: Thomas Krenn

Intel begann deshalb parallel zur Entwicklung von 3D XPoint damit, auch eine eigene Tool-Suite zu entwickeln, mittels derer der Zugriff auf Speicherlaufwerke direkt aus einer Anwendung heraus möglich sein sollte. Weil Optane-Laufwerke fast so schnell wie RAM waren, wollte man eine Softwareschnittstelle schaffen, deren Funktionalität dem RAM-Handling des Linux-Kernels ähnelt. Schnell bekam das Kind einen Namen: Storage Performance Development Kit, kurz SPDK. Die Krux an der Sache: Damit eine Anwendung von den Vorteilen von SPDK profitiert, muss sie dafür geschrieben und konzipiert sein. Es ist also nicht möglich, einer Standardapplikation wie MySQL mal eben SPDK unterzujubeln.

Intel hat es vorgemacht: Seine verteilte Speicherlösung DAOS fußt auf SPDK und dessen Cousin DPDK (Data Plane Development Kit). DPDK leistet dabei für Netzwerkkarten ähnliche Dienste wie SPDK für Speicherlaufwerke: Es ermöglicht Anwendungen den direkten Zugriff auf das Laufwerk durch das RAM hindurch (DMA, Direct Memory Access). In praktisch jedem Benchmark hatte DAOS in den vergangenen Jahren die Nase weit vorn, nicht zuletzt wegen des SPDK.

Von ebendieser Funktionalität möchte man bei Longhorn nun auch profitieren: Die Data Engine V2 [5], also der neu geschriebene Kern von Longhorn, baut ebenfalls auf SPDK. Jedoch sind die Vorzeichen mittlerweile andere, denn Intel hat sein Optane-Geschäft eingestampft und entsprechende Laufwerke sind neu nicht mehr zu bekommen. Dennoch hat die Open-Source-Gemeinde reagiert, wie in solchen Fällen üblich: Sie hat das SPDK so erweitert, dass es sich auch mit “normalen” NVMe-Laufwerken nutzen lässt. Optane ist also längst keine Voraussetzung mehr, um in den Genuss der Performance-Vorteile von SPDK zu kommen.

Noch steckt die Arbeit an der Data Engine V2 in Longhorn allerdings in den Kinderschuhen, was man im Alltag übrigens auch regelmäßig merkt: In beinahe jedem Changelog einer heutigen Longhorn-Version finden sich ausdrückliche Warnungen im Hinblick auf die Data Engine V2. Vor allem sind es inkompatible Veränderungen, die Nutzern hier das Leben schwer machen und zum Teil umständliche Migrationsprozesse erzwingen. Eben das will man aber gerade in der Produktion nicht haben.

Performance-Aspekte

Dass die Arbeiten an der Longhorn Engine V2 dringend notwendig sind, zeigen diverse, im Netz kursierende Performance-Tests der Lösung. Bereits in der Anfangsphase der Longhorn-Entwicklung hatten Early Adopter sich darüber beschwert, dass das Tool vergleichsweise behäbig und langsam war. Besonders fatal aus Longhorn-Sicht: Wo andere Lösungen wie Ceph offensichtliche Stärken und klare Schwächen hatten, schnitt Longhorn auf ganzer Linie höchstens mittelmäßig ab.

Speicher-Performance hat zwei Dimensionen. Einerseits geht es um die Zeit, die eine einzelne Information braucht, um von der Quelle zum Ziel zu kommen, also die Latenz. Andererseits spielt die Menge an Daten eine Rolle, die sich in einer definierten Zeit von der Quelle zum Ziel übertragen lassen, also die Bandbreite. Ceph als klassisches Beispiel bietet eine hohe Bandbreite, weil es viele Festplatten virtuell bündelt und somit die Bandbreite der einzelnen Laufwerke bei geringem Overhead kombiniert. Entsprechend lässt sich die Bandbreite eines Ceph-Clusters erweitern, indem man mehr Laufwerke integriert.

Im Hinblick auf Latenz hingegen zeigt Ceph chronische Schwächen, der dort genutzte Algorithmus CRUSH ist besonders für Latenz anfällig. Hinzu kommt bei allen verteilten Speichern, die auf Ethernet fußen, die inhärente Ethernet-Latenz. Sie ist deutlich höher als bei anderen Transportmedien wie Fibre Channel oder InfiniBand. Ceph allerdings schneidet durch die Bank in allen Latenz-Benchmarks schlechter ab als die Konkurrenz, mit zumindest bisher einer Ausnahme: Longhorn mit der Engine V1 ist verglichen mit Ceph noch schlechter.

Die Benchmark-Werte, die sich im Netz finden und die sich mit wenig Aufwand gut nachstellen lassen, fallen verheerend aus: Auf derselben Hardware wie Ceph produziert Longhorn demnach 50 Prozent mehr Latenz bei signifikant weniger Durchsatz. Testen lassen sich beide Dimensionen der Performance dabei relativ simpel: Wer die Latenz messen möchte, lässt einen einzelnen Thread (Queue Depth 1) 4-KByte-Blöcke zufällig auf ein angebundenes Longhorn-Volume schreiben. Um den Durchsatz zu messen, nutzt man Blöcke mit einer Größe von 4 MByte und einer möglichst hohen Parallelität, etwa mit einer Queue Depth von 32.

Grund zum Handeln gab es für die Longhorn-Entwickler insofern seit Langem. Dass man sich nun gleich für den radikalsten Ansatz entschieden hat, der auf dem SPDK fußt und die Nutzung regulärer Festplatten weitgehend ausschließt, spricht im Hinblick auf die avisierten Ziele Bände. Erste Tests der Vorserienversion der Engine V2 legen die Vermutung nahe, dass sich das neue Longhorn in Sachen Latenz wie in Sachen Durchsatz deutlich besser schlägt als sein Vorgänger.

Die Krux daran: Bei Redaktionsschluss fehlten in der Liste der unterstützten Features der Engine V2 einige Eigenschaften, die bereits Bestandteil der Engine V1 waren. Noch ist man beim Longhorn-Projekt insofern ein gutes Stück weit davon entfernt, Feature-Parität zu erreichen. Das aber ist das Ziel, um die V2 für produktiv nutzbar und reif für den alltäglichen Einsatz zu erklären. Noch handelt es sich um Preview-Software, von deren produktiven Einsatz die Entwickler dringend abraten. Hier werden die kommenden Monate spannend.

Auf der Kommandozeile

Zwar dominieren die Arbeiten an der Data Engine V2 aktuell die Arbeit an Longhorn. Seit der letzten Erwähnung des Projekts im Linux-Magazin haben sich aber auch fernab davon einige Dinge geändert und verbessert. So liefert Longhorn mittlerweile ein eigenes Kommandozeilenwerkzeug namens »longhornctl« mit. Mit diesem CLI-Programm lassen sich Volumes direkt von der Kommandozeile aus in Longhorn anlegen, modifizieren und löschen. Bis zur Einführung des neuen Werkzeugs war das eine eher nervige Angelegenheit, denn getreu der Ansicht der Entwickler, Longhorn sei nur im Gespann mit Kubernetes überhaupt sinnvoll zu nutzen, waren Änderungen an Longhorn-Volumes bis dato nur durch die Kubernetes-API hindurch möglich. Diese Einschränkung entfällt nun.

S3 im Fokus

Ein zentraler Punkt, der in den Augen vieler Administratoren für den Einsatz von Ceph spricht, ist dessen Vielseitigkeit. Neben der Verwendung als virtueller Blockspeicher oder als verteiltes POSIX-Dateisystem kommt auch ein Einsatz als S3-Umgebung mit dem RADOS Gateway in Betracht.

Longhorn selbst unterstützt hingegen nativ nicht die S3-Schnittstelle. Ebendarum hat Suse eine Eigenentwicklung ins Leben gerufen, das S3GW. Zum Zeitpunkt des Erscheinens des ersten Longhorn-Artikels im Linux-Magazin war es gerade aktiv in Entwicklung und eines der zentralen Argumente Suses, Longhorn zu bewerben. Bald darauf scheint die glühende Euphorie für das Produkt allerdings merklich abgekühlt zu sein.

Wirft man heute einen Blick in das Github-Verzeichnis des Projekts, stammt der letzte Commit aus dem März 2024. Und fast noch schlimmer: Der bezog sich vor allem auf Dokumentation. Das letzte Release, Version 0.23.0, ist über zwei Jahre alt, stammt also noch aus der Zeit unmittelbar nach dem seinerzeit erschienenen Text im Linux-Magazin. Im Anschluss scheint man bei Suse das Interesse an S3GW verloren zu haben, zumindest aber ist es stark zurückgegangen.

Wohlgemerkt: Dass ein Git-Verzeichnis seit einiger Zeit keine Aktualisierungen mehr erhalten hat, ist nicht per se ein Problem. Gerade bei einem sich schnell verändernden Protokoll wie S3 aber darf man wohl eher davon ausgehen, dass aktuellere S3-Features mit dem S3GW heute schlicht nicht funktionieren. Dazu passt, dass sich die Anzahl der aktiven Nutzer in Grenzen zu halten scheint.

Einen Fehlereintrag auf Github, der eine S3-Schnittstelle als offizielle Longhorn-Komponente versprach, haben die Entwickler in der Zwischenzeit als wontfix markiert. Man hat also nicht vor, eine entsprechende Schnittstelle als offiziellen Teil der Lösung zu liefern. Das ist zumindest ein kleines Debakel für Anwender, deren Use Case das Vorhandensein einer S3-Schnittstelle voraussetzt. Gerade in Web-Setups ist das heute oft der Fall, weil S3 dort zum Verteilen von Asset-Daten zum Einsatz kommt.

Feature complete war S3GW ebenfalls nicht: Zentrale Funktionen wie die Off-Site-Replikation, die bei der Konkurrenz, also dem RADOS Gateway, seit Jahren zum Lieferumfang gehören, beherrscht der Longhorn-Aufsatz schlicht nicht. Gut möglich insofern, dass sich S3GW für Longhorn in die lange Liste der Storage-Projekte einreiht, die Suse einst anfing, dann aber nicht fortgeführt hat.

Zum Verständnis: Dass Longhorn keine aktuelle S3-Schnittstelle mehr anbietet, bedeutet nicht, dass Longhorn selbst S3 nicht als sekundäre Backup-Lösung weiter nutzen kann. Das Feature existiert bereits seit einer ganzen Weile. Es erlaubt Longhorn, einen S3-kompatiblen Speicher unter anderem als Ziel für Backups in einer anderen Site zu nutzen (Abbildung 3), die ein Nutzer von einem Longhorn-Volume anfordert. Seit Longhorn 1.8.0 lassen sich für ein Volume übrigens auch verschiedene parallele Backup-Ziele parallel zueinander festlegen, darunter eben S3.

Abbildung 3: S3 kann für Longhorn seit einiger Zeit als Backup-Ziel fungieren. Derweil dümpelt die für Longhorn von Suse eigens geschaffene S3-Schnittstelle scheinbar eher ziellos umher. Quelle: Dan Foulkes

Mehr MAT

Es liegt in der Natur der Sache, dass eine skalierbare Umgebung wie Longhorn andere Anforderungen in Sachen Monitoring, Alerting und Trending (MAT) stellt als eine konventionelle Maschine von NetApp. Hier will der Administrator schließlich nicht nur wissen, in welchem Zustand das System sich gerade befindet, sondern auch abschätzen, wann der verfügbare Speicherplatz in der Umgebung sich dem Ende neigt und wann er Hardware nachschießen muss.

Das ist nur über Trending zu realisieren, also über eine regelmäßige Abfrage diverser Metrikwerte des Clusters, aus denen sich dann eine Prognose für die weitere Entwicklung des Speicherbedarfs errechnen lässt. Als eine Art Nebenprodukt des Trendings fällt klassisches Monitoring auf Grundlage von Ereignissen an. Trending nutzt Zeitreihendatenbanken, Prometheus ist eine solche und mittlerweile der Quasi-Standard in Sachen MAT skalierbarer Umgebungen. Streng genommen ist die Angabe “Laufende Apache-Prozesse zum jetzigen Zeitpunkt” ja ebenfalls eine Zeitreihe, wenn auch eine sehr kurze, mit nur einem Eintrag. Prometheus kann diese Zeitreihe gegen einen Sollzustand abgleichen und daraus Rückschlüsse ziehen.

Die Longhorn-Entwickler machen sich die Tatsache zunutze, dass es verhältnismäßig leicht fällt, für die eigene Anwendung eine Anbindung an Prometheus zu schaffen. Bereits seit 2021 lässt sich in Longhorn ein Endpunkt für Metrikdaten aktivieren. Dann öffnet es selbst einen Port auf jedem beteiligten System, über den es Metrikdatenwerte im Prometheus-Format exportiert. Die Entwickler bauen diese Schnittstelle kontinuierlich aus. Sowohl Longhorn 1.7 als auch 1.8 und 1.9 haben kontinuierlich die Menge der bereitgestellten Metrikdaten erweitert.

Die noch aktuelle Version, Longhorn 1.9 fügte eine Vielzahl von Metrikdatenwerten hinzu, die sich auf Custom Resources in einem laufenden Kubernetes beziehen und dort insbesondere auf Longhorn-Volumes, die einem aktiven Recovery-Prozess unterliegen. Im Kern exponiert Longhorn dafür die genauen Zustände aller Volumes sowohl auf den Longhorn-Engines als auch auf den zugehörigen Custom Resources (CRs) in Kubernetes. Dadurch lässt sich in Prometheus und mithin auch in daran angeschlossenen Grafana-Instanzen detailliert nachprüfen, ob Volumes gerade im Recovery sind, und falls ja, welchen Status sie dabei aktuell haben.

Noch etwas zu wünschen übrig lassen die seitens der Entwickler bereitgestellten Grafana-Dashboards (Abbildung 4). Hier verlässt man sich vor allem auf die Community [6] und steuert selbst keine eigenen Exemplare bei. Schade: Der MAT-Stack ist nur halb fertig, wenn nur Prometheus und sein Alert Manager zur Verfügung stehen. Für die echte MAT-Erfahrung ist die Aufbereitung der Daten mit Grafana zur besseren Darstellung unerlässlich. Immerhin springt die Community ein und liefert gleich mehrere brauchbare Grafana-Dashboards (Abbildung 5). Entwickler wie Adrian Goodyer [7] halten sie stetig aktuell und erweitern sie, sobald Longhorn neue Fähigkeiten in Sachen Prometheus-Export hinzugewinnt.

Abbildung 4: In Sachen Grafana-Dashboard verlässt man sich bei Longhorn eher auf die Community. Die liefert, wie das hier dargestellte Beispiel zeigt. Quelle: ONZACK

Abbildung 5: Auch Adrian Goodyer stellt ein Grafana-Dashboard für Prometheus zur Verfügung, das er regelmäßig an die erweiterten Fähigkeiten der Lösung anpasst. Quelle: Adrian Goodyer

Fazit: Viel getan, viel zu tun

Longhorn ist ein perfektes Beispiel für Open-Source-Software, die kontinuierlich besser wird und fortwährend gedeiht. Daran hat Suse großen Anteil: Endlich wähnt man sich in Nürnberg in der Lage, dem Erzkonkurrenten mit dem roten Hut im Storage-Markt Paroli zu bieten. Bis dato aber war Longhorn kaum in der Lage, es mit dem Platzhirschen Ceph aufzunehmen. Dass man bei der Longhorn Engine V2, praktisch einem Rewrite der originalen Longhorn-Version mit weitgehender Feature-Kompatibilität, in die Vollen geht, liegt also nahe. Die Anstrengungen scheinen von Erfolg gekrönt: Weil die neue Version der Software konsequent auf modernste Technologien wie SPDK setzt, hat sie Ceph womöglich sogar einiges voraus.

Allerdings schläft man bei Red Hat auch nicht: Dort werkeln die Entwickler bereits seit einiger Zeit fleißig an einer neuen Version von OSD, der zentralen Komponente zum Ablegen von Daten. Und siehe da: Auch das “SeaStore” getaufte Projekt soll für die Nutzung mit NVMes optimiert sein und SPDK nutzen. Gut möglich also, dass Ceph ebenfalls bald deutlich bessere Performance-Werte erzielen kann. Die Longhorn-Entwickler ficht das nicht an: Selbst wenn es gelingt, mit Ceph auch nur auf Augenhöhe zu sein, wäre das ein enormer Erfolg für das Projekt. Die Longhorn-Zukunft bleibt entsprechend spannend. Die Engine V2 soll Mitte 2026 in Serie gehen. (jcb)