Kubernetes wirkt auf den ersten Blick wie eine perfekte Maschine für alles Flüchtige: Pods kommen und gehen, Deployments skalieren nach oben oder unten, Knoten tauscht der Administrator nahezu ohne Einfluss auf den laufenden Betrieb aus. Und die Plattform zuckt dabei kein bisschen. Genau darin liegt ihr Reiz. Bei der Datenhaltung kippt dieses Bild jedoch schnell. Kaum eine produktive Anwendung kommt ohne persistente Daten aus. Datenbanken schreiben Transaktionen, Message-Broker pflegen Queues, CI-Systeme legen Artefakte ab, Logging-Stacks bauen Indizes auf. Selbst vermeintlich "stateless"-Webanwendungen speichern früher oder später Sessions, Uploads oder Caches, die nicht bei jedem Container-Neustart verloren gehen sollen.

Damit landet der Admin zwangsläufig bei einer einfachen Frage: Wohin gehören die Daten, die erhalten bleiben müssen? Kubernetes bringt dafür passende Objekttypen mit: Persistent Volumes (PV) und Persistent Volume Claims (PVC) abstrahieren dauerhaften Speicher, auf den Workloads zugreifen. Die eigentliche Bereitstellung dieses Speichers bleibt jedoch außerhalb von Kubernetes – und damit weiterhin Verantwortung des Administrators. Was trivial klingt, entscheidet im Alltag über Zufriedenheit oder Frust. Schließlich bestimmt der Speicher Latenz, Durchsatz, Resilienz und Betriebskomplexität – und im Zweifel auch die Laune des Operators im Bereitschaftsdienst.

NAS und SAN als Fremdkörper

Grundsätzlich lässt sich Kubernetes an ein NAS- oder SAN-System anbinden. Viele Umgebungen tun genau das, und in bestimmten Szenarien passt diese Kombination sogar: Ein stabiles SAN liefert IOPS, ein NAS stellt einfache Shares bereit, der Admin kennt die Bedienung, und die Buchhaltung hat die Investition längst abgeschrieben. Das Kernproblem bleibt jedoch bestehen: Kubernetes funktioniert als Plattform, NAS- und SAN-Systeme meist als einzelne Geräte. Eine der zentralen Stärken von Kubernetes ist die horizontale Skalierung. Genau hier stoßen klassische Storage-Appliances an ihre Grenzen.

Bei genauerem Hinsehen zeigen sich drei Problemfelder. Erstens die Skalierung. Kubernetes skaliert horizontal: Neue Nodes kommen hinzu, die Plattform verteilt Last automatisch und ohne feste Zuordnungen. Klassische NAS- oder SAN-Devices wachsen dagegen häufig vertikal – über zusätzliche Controller, mehr Cache, stärkere CPUs oder größere Shelves. Zwar bieten Enterprise-Systeme auch Scale-out-Varianten, diese bewegen sich preislich jedoch in Regionen, in denen selbst Fahrzeuge der Oberklasse vergleichsweise bescheiden wirken. In der Praxis heißt das: Wächst der Cluster, wächst der Speicher nicht automatisch mit. Erreicht das Storage-System sein Limit, bremst es den gesamten Plattformansatz aus – es sei denn, der Administrator ist bereit oder in der Lage, erhebliche Summen nachzuschießen.

Zweitens gehören Engpässe bei klassischen Storage-Appliances zum Design. Zwar sind die Systeme intern redundant und auf hohe Bandbreiten ausgelegt, der Zugriff erfolgt jedoch stets über denselben Netzwerkpfad. Ist dieser ausgelastet, quetscht sich der Datenverkehr vieler Pods durch ein gemeinsames Nadelöhr. Zurück bleibt eine formal hochverfügbare Storage-Box, die im Alltag schlicht langsam ist.

Drittens kollidieren Betriebsmodell und Deployment-Tempo klassischer NAS- oder SAN-Systeme mit der Arbeitsweise von Kubernetes. Entwickler automatisieren Installationen, rollen Updates in Wellen aus und behandeln Infrastruktur wie Code. Dafür benötigen sie Volumes dynamisch und on demand. Klassischer Storage erzwingt dagegen häufig Tickets, Provisioning-Prozesse und manuelle Freigaben. Zwar lässt sich all das integrieren, doch genau dabei geht der Vorteil verloren, den Kubernetes verspricht: Geschwindigkeit ohne Kontrollverlust. Zusätzlich bindet sich der IT-Verantwortliche eng an einen Hersteller. Stellt Net-App, Dell EMC oder ein anderer Anbieter die Kubernetes-Unterstützung ein, wird der teure Speicher schnell zum überdimensionierten Briefbeschwerer. Das Spannungsfeld ist damit klar: Der Administrator benötigt Persistenz, will sie aber im selben Stil betreiben wie den Rest der Plattform. Genau an dieser Stelle kommen Ceph und Longhorn ins Spiel.

Software-defined Storage wächst mit

Wenn von Software-defined Storage (SDS) die Rede ist, geht es um einen grundlegenden Perspektivwechsel. Speicherfunktionen lösen sich von proprietärer Hardware und wandern in Software, die auf Standardhardware läuft. Statt einer monolithischen Appliance im Rack entsteht ein System, das über normale Server, Standardlaufwerke und übliche Netzwerke skaliert. Ceph und Longhorn verfolgen dieses Ziel, setzen jedoch unterschiedliche Schwerpunkte.

Ceph gilt seit Jahren als Alleskönner: Blockspeicher über RBD, Objektspeicher über das Ceph Object Gateway mit S3-Kompatibilität und ein POSIX-Dateisystem mit CephFS. In Kubernetes stehen vor allem Blockspeicher und CephFS im Fokus, abhängig vom jeweiligen Workload. Ceph verteilt Daten über zahlreiche OSDs (Object Storage Daemons), nutzt Replikation oder Erasure Coding und hält Metadaten über mehrere Monitoringdienste konsistent. Der Administrator baut damit einen echten Scale-out-Cluster, der Ausfälle verkraftet, ohne dass ein einzelner Controller zur Achillesferse wird.

Diese Flexibilität erkauft sich Ceph allerdings mit Komplexität. Der Betrieb verlangt saubere Netzwerke, sinnvoll definierte Failure-Domains, geeignete SSDs oder NVMe-Platten sowie eine durchdachte Architektur und sauberes Tuning. Wer Ceph unvorbereitet aufsetzt, erzeugt zwar kein völliges Datengrab, sehr wohl aber ein dauerhaftes Ärgernis. Wer den Cluster hingegen sorgfältig plant, erhält ein Storage-Fundament, das sich über Jahre hinweg im laufenden Betrieb erweitern und modernisieren lässt – eine Umgebung also, die gemeinsam mit der Plattform wächst.

Longhorn hingegen stammt direkt aus der Kubernetes-Welt und setzt bewusst eine Ebene tiefer an. Der Fokus liegt klar auf Blockspeicher für Container-Workloads. Longhorn repliziert Daten über alle Knoten mit lokalen Laufwerken, erstellt Snap-shots und Backups und bindet sich eng in Kubernetes-Mechanismen ein. Viele Administratoren schätzen, dass Longhorn die Denkweise der Plattform konsequent übernimmt: Die Installation erfolgt als Komponente im Cluster, die Verwaltung über Kubernetes-Objekte. Auf diese Weise steht schnell persistenter Speicher zur Verfügung, ohne parallel ein eigenes Storage-Universum betreiben zu müssen.

Zur Vollständigkeit gehört jedoch: Longhorn ist kein Selbstläufer. Der Administrator muss Ressourcen einplanen – CPU, Arbeitsspeicher und Netzwerk –, sinnvolle Replikationsfaktoren wählen und sich mit Performanceprofilen beschäftigen. Andernfalls überfordert Longhorn die Kubernetes-Umgebung, in der es läuft. Für typische Kubernetes-Persistenz eignet sich das Werkzeug häufig sehr gut. Ein universelles Storage-Backend für jede denkbare Anforderung liefert es jedoch nicht automatisch. Genau deshalb lohnt sich der direkte Vergleich mit Ceph.

CSI als Steckdose für Storage

Damit Ceph oder Longhorn als Lieferanten persistenten Speichers fungieren können, benötigt Kubernetes eine saubere Anbindung. Früher übernahmen sogenannte In-Tree-Treiber diese Aufgabe direkt im Kubernetes-Kern. Diese enge Kopplung erwies sich jedoch als unflexibel und verlagerte zu viel Funktionalität in das Herz der Plattform. Heute regelt das Container Storage Interface (CSI) die Speicherkonnektivität. CSI definiert, wie ein Storage-System Volumes bereitstellt, an Nodes anbindet, dort einhängt, skaliert, Snapshots erzeugt und Ressourcen anschließend wieder freigibt.

CSI funktioniert damit wie eine klassische Plug-in-Schnittstelle. Sie abstrahiert den Zugriff auf Speicher so weit, dass sich nahezu jede SDS-Umgebung nahtlos in Kubernetes integrieren lässt. Was im Inneren des Speichers geschieht, spielt für Kubernetes zunächst keine Rolle. Aus dieser Trennung ergeben sich mehrere Vorteile. Zum einen gewinnt der Administrator Austauschbarkeit und Flexibilität. Er beschreibt in YAML, welche Storage Class genutzt wird und welche Parameter gelten – etwa Replikation, Pools oder Dateisysteme. Kubernetes übernimmt mit dem jeweiligen CSI-Treiber im Rücken den Rest. Infrastruktur als Code wird damit praktisch umsetzbar.

Zum anderen entsteht ein einheitliches Betriebsmodell, das Speicher dynamisch über PVCs bereitstellt sowie Volumes auf Knoten ein- und aushängt. Kubernetes orchestriert den Lebenszyklus des Speichers ebenso wie jenen der Anwendung. Ceph und Longhorn liefern jeweils eigene CSI-Treiber, die genau diese Aufgaben erfüllen. Entscheidend ist daher nicht die Frage "Kann Kubernetes das?", sondern wie zuverlässig der Speicher arbeitet, wie gut er betrieben wird und wie sauber der CSI-Treiber als Bindeglied zwischen Storage und Plattform fungiert.

Ceph und RADOS untrennbar

Ceph erscheint von außen wie ein Sammelsurium aus Daemons, Pools, Werkzeugen und Abkürzungen. Im Kern bleibt die Architektur jedoch erstaunlich klar. RADOS (Reliable Autonomic Distributed Object Store) bildet das Herzstück von Ceph in Form eines verteilten Objektspeichers. Sämtliche von Ceph angebotenen Dienste – Blockspeicher, Dateisystem und S3-kompatibler Objektspeicher – setzen letztlich auf RADOS auf. Wer Ceph verstehen will, beginnt daher mit RADOS.

 

 

In RADOS speichern OSDs (Object Storage Daemons) die eigentlichen Daten. Ein OSD entspricht in der Regel einem einzelnen physischen Laufwerk. Ceph verteilt seine Objekte über diese OSDs hinweg. Anders als klassische RAID-Controller arbeitet das System ohne zentrale Instanz. Stattdessen verteilt es Daten gleichmäßig über alle Laufwerke im Cluster. Der Administrator erhält damit keinen einzelnen Flaschenhals, sondern viele gleichberechtigte Speicherträger, die gemeinsam einen Pool und mehrere logische Pools bilden.

Die zweite Säule von RADOS stellen die MONs (Monitore) dar. Sie überwachen den Cluster-Zustand und halten zentrale Metadaten konsistent: Welche Nodes gehören zum Cluster? Welche OSDs sind aktiv? Welche Regeln steuern die Platzierung der Daten? Und wie verhält sich der Cluster bei Netzpartitionen, etwa nach dem Ausfall eines Switches? In solchen Fällen sorgen die MONs dafür, dass es nicht zu Split-Brain-Situationen kommt.

Redundanz ist in RADOS kein Zusatz, sondern Grundprinzip. Der IT-Verantwortliche definiert Replikationsfaktoren oder Erasure-Coding-Profile, und Ceph legt Daten so ab, dass der Ausfall einzelner Laufwerke oder ganzer Nodes die Verfügbarkeit nicht beeinträchtigt. Fällt ein Laufwerk aus, markiert Ceph die betroffenen OSDs als "down" und "out", verteilt die zugehörigen Placement Groups neu, erzeugt fehlende Replikate und balanciert die Daten erneut aus. Dieser Prozess wirkt wie eine eingebaute Selbstheilung, solange ausreichend Kapazität und gesunde OSDs verfügbar bleiben.

Die Skalierung folgt demselben Muster: Statt bestehende Geräte zu vergrößern, ergänzt der Administrator Nodes und OSDs. Ceph integriert die neuen OSDs in seine CRUSH-Topologie (Controlled Replication Under Scalable Hashing, verteilt die Daten neu und vergrößert so den Pool. Mit sauberer Planung lässt sich der Speicher nahezu beliebig horizontal erweitern – bedarfsgerecht und kalkulierbar, was auch dem Controlling gefällt.

Was RADOS im Detail leistet

Ausgehend von RADOS stellt Ceph drei Frontends bereit, die jeweils unterschiedliche Workloads bedienen. Das RADOS Block Device (RBD) liefert emulierten Blockspeicher. Der Admin erhält damit das klassische Werkzeug für Datenbanken, Virtualisierung und Kubernetes-PVCs. Ein Volume verhält sich wie eine lokale Platte, inklusive Snapshots und Klonen. Intern liegen die Daten als Objekte in RADOS, nach außen sieht der Pod ein Block Device im Sinne des Block Device Layers des Linux-Kernels.

CephFS stellt ein POSIX-Dateisystem bereit und auch hier bildet RADOS die Grundlage. Für das Verzeichnis- und Metadaten-Management kommen MDS-Daemons (Metadata-Server) zum Einsatz. Diese fungieren als große Metadaten-Caches, die POSIX-Informationen an angebundene Clients ausliefern. Die Metadaten selbst speichert Ceph ebenfalls in RADOS. CephFS eignet sich damit für Shared-Storage-Szenarien, Build-Farmen, Content-Workflows und alle Workloads mit vielen Dateien und parallelen Zugriffen. Der Administrator erhält ein verteiltes Dateisystem im Stil von NFS, jedoch ohne ein zentrales NAS-Gerät als Single-Point-of-Failure.

Das Ceph Object Gateway (RGW) liefert Objektspeicher über S3- und Swift-kompatible Schnittstellen. RGW spricht HTTP und stellt Buckets und Objekte bereit, während RADOS die eigentliche Datenhaltung übernimmt. Ceph positioniert sich damit auch als Backupziel, Archivspeicher und Basis für cloudnative Anwendungen oder Data-Warehouse-Szenarien. In Kubernetes-Umgebungen dient RGW häufig als Backend für S3-Backups, Artefaktspeicher oder Anwendungen, die bereits auf S3-APIs setzen.

Diese Dreiteilung wirkt zunächst komplex, doch in der Praxis schafft sie klare Zuständigkeiten: Der Administrator wählt die passende Schnittstelle für den jeweiligen Workload, RADOS übernimmt Verteilung, Redundanz und Selbstheilung im Hintergrund.

Wichtige CSI-Treiber für RADOS

Für Kubernetes zählt weniger die interne Ceph-Architektur, als die saubere Bereitstellung von persistentem Speicher in Form von Persistent Volumes. An dieser Stelle greift die Integration von Ceph in das Container Storage Interface. Der Administrator bindet Ceph dabei über zwei etablierte CSI-Treiber an:

- ceph-csi-rbd provisioniert RBD-Volumes dynamisch und bindet sie als Blockspeicher an Pods an. Das gewünschte Verhalten modelliert der Administrator über Storage Classes: Pool-Auswahl, Image-Features, Replikationsvorgaben, Secrets und Mount-Optionen. Kubernetes übernimmt daraufhin das Anlegen und Entfernen der Volumes entlang des PVC-Lebenszyklus.

- ceph-csi-cephfs provisioniert CephFS-Subvolumes oder Verzeichnisse und hängt sie dynamisch in Pods ein. Der IT-Verantwortliche erhält damit geteilten Speicher nach Kubernetes-Logik, inklusive POSIX-Zugriffsmodellen, Quotas und – falls gewünscht – einer sauberen Trennung pro Namespace.

In beiden Fällen übersetzt der CSI-Treiber Kubernetes-Operationen in Ceph-Operationen. Das entbindet den Admin jedoch nicht davon, Ceph parallel zu Kubernetes als eigenständige Umgebung stabil zu betreiben. Was Ceph an Qualität nicht liefert, kann Kubernetes nicht kompensieren.

Mit Rook Ceph als Kubernetes-Ressource bereitstellen

Wer Ceph nicht neben Kubernetes, sondern direkt innerhalb der Plattform betreiben möchte, stößt schnell auf Rook. Rook bringt Ceph als Operator in Kubernetes und verwaltet Cluster, OSDs, Pools und Daemons als Kubernetes-Ressourcen. Das IT-Team beschreibt gewünschte Zustände über Custom Resource Definitions (CRDs), Rook setzt diese anschließend im Cluster um. Deployments für MONs, DaemonSets für OSDs, Services, Secrets und Updates gehören dabei zum festen Funktionsumfang.

Auf den ersten Blick wirkt dieser Ansatz wie der Königsweg, da er ein einheitliches Betriebsmodell verspricht. Gleichzeitig verschiebt Rook Verantwortung: Ceph folgt dann dem Takt der Kubernetes-Control-Plane – inklusive deren Upgrades, Scheduling-Entscheidungen und möglicher Störungen.

 

 

Longhorn tief in Kubernetes integriert

Longhorn verfolgt einen deutlich anderen Ansatz als Ceph. Während Ceph als universeller SDS-Baukasten auftritt, ist Longhorn konsequent auf Kubernetes ausgerichtet. Das Werkzeug stammt aus dem Rancher-Umfeld und adressiert ein Problem, das viele Cluster-Admins gut kennen: Persistente Volumes sollen sich so "cloudig" anfühlen wie Deployments – ohne SAN-Terminologie und ohne externe Storage-Appliance. Offiziell beschreibt Longhorn sich als "Cloud native distributed Block Storage for Kubernetes". Die Zielrichtung ist damit klar: Blockspeicher für Container – und ausdrücklich nicht "alles für alle".

Technisch setzt Longhorn auf einen Ansatz, der in der Praxis gut nachvollziehbar bleibt. Für jedes Volume erzeugt Longhorn einen eigenen Controller und repliziert die Daten synchron über mehrere Replikate auf unterschiedliche Nodes. Redundanz ist damit kein Zusatz, sondern Betriebszustand. Fällt ein Node oder ein Laufwerk aus, bleibt mindestens ein weiteres Replikat verfügbar, und Longhorn organisiert die Wiederherstellung über neue Replikate auf gesunden Knoten. Das gesamte System läuft als Sammlung aus Containern und Microservices im Cluster und nutzt Ressourcen, die in Kubernetes ohnehin vorhanden sind: CPU, Arbeitsspeicher, Netzwerk und lokale Datenträger.

Der entscheidende Unterschied zu Ceph liegt weniger im "ob" als im "wo". Longhorn existiert ausschließlich innerhalb von Kubernetes. Die Installation erfolgt über Kubernetes-Ressourcen, die Verwaltung über API-Objekte der Plattform. Das Werkzeug nutzt genau dort die Stärken von Kubernetes: Lifecycle-Management, Scheduling, Rolling Updates und deklarative Konfiguration.

Auch bei Longhorn erfolgt die Anbindung über CSI. Kubernetes kommuniziert über den CSI-Treiber mit Longhorn, fordert Volumes an, bindet sie an Nodes, hängt sie in Pods ein und räumt sie nach dem Ende ihres Lebenszyklus wieder auf. Für den Administrator fühlt sich das wie eine konsequente Fortsetzung des Plattformgedankens an: Ein neu angelegter Persistent Volume Claim führt unmittelbar zu einem bereitgestellten Volume – ganz ohne Ticket an ein separates Storage-Team. Von Ceph unterscheidet Longhorn sich damit vor allem durch seine tiefe native Integration in Kubernetes.

Der Nachteil dieser Nähe zur Plattform liegt im Reifegrad. Longhorn ist deutlich jünger als Ceph mit RADOS und befindet sich aktuell in einer Phase tiefgreifender Veränderungen. Das Projekt treibt die sogenannte "V2 Data Engine" voran und arbeitet damit faktisch an einer neuen Generation des gesamten Datenpfads. Verglichen mit der bisherigen Version bleibt dabei kaum ein Stein auf dem anderen. In den Release Notes zu Longhorn v1.10.0 weist das Entwicklerteam explizit darauf hin, dass es sich um einen "Major Milestone" handelt. Die Version bringt zahlreiche Neuerungen, darunter auch solche, die die Kompatibilität zu früheren Versionen brechen. Das ist ein klarer Hinweis darauf, dass der Umbau nicht kosmetisch ausfällt, sondern tief in die Architektur eingreift.

 

 

Longhorn-Neuerungen beachten

Ein so grundlegender Umbau bringt zwangsläufig Phasen mit sich, in denen Feature-Parität nicht überall gegeben ist. Longhorn dokumentiert diesen Zustand offen und führt eine eigene Übersicht, die zeigt, welche Funktionen zwischen der bisherigen Data Engine V1 und der neuen V2 bereits angeglichen wurden und wo noch Lücken bestehen. Derzeit befindet sich Longhorn damit klar im Übergang. Die Data Engine V1 bleibt etablierten Werkzeugen wie Ceph in mehreren Punkten unterlegen, insbesondere bei der Performance. Die Data Engine V2 verspricht deutliche Verbesserungen, ist jedoch noch nicht abgeschlossen und verändert sich kontinuierlich. Für IT-Verantwortliche erschwert das aktuell eine belastbare Entscheidung, wenn Konsistenz in der Administration, planbare Performance und betriebliche Stabilität im Vordergrund stehen.

Für den Betrieb ergibt sich daraus eine nüchterne Konsequenz: Longhorn liefert heute eine sehr Kubernetes-nahe Storage-Erfahrung, erfordert aber eine bewusste Planung mit Blick auf den Reifegrad der V2-Entwicklung. Wer Longhorn neu einführt, entscheidet sich entweder für die etablierte V1 und bindet sich damit eine spätere Migration ans Bein oder setzt auf V2 und akzeptiert den Betrieb nahe an der Entwicklungsfront.

Zwei unterschiedliche Wege zur Persistenz

Bei Vergleich von Ceph und Longhorn im Kubernetes-Alltag stehen sich weniger zwei Produkte gegenüber als zwei grundlegend unterschiedliche Betriebsmodelle. Beide liefern Persistenz über CSI, beide verteilen Daten über mehrere Knoten, beide zielen auf Resilienz. Die Unterschiede in Architektur, Integrationsgrad und Fehlerbildern sind jedoch so deutlich, dass die Entscheidung am Ende nicht über einzelne Features fällt, sondern über die Frage, welches Modell zur eigenen Organisation passt.

Longhorn setzt Kubernetes von Beginn an als Heimat voraus. Der Administrator installiert Longhorn als Workloads im Cluster, verwaltet es im selben Kontext wie Deployments, Services und Ingress und verankert Storage-Lebenszyklen direkt in den Mechanismen der Plattform. Daraus entsteht ein spürbarer Gleichklang: Was Kubernetes als Desired State beschreibt, setzt Longhorn unmittelbar als Storage-Realität um. In vielen Umgebungen reduziert das Reibung, weil Teams weniger zwischen klassischer Storage-Welt und Container-zentrierter Arbeitsweise wechseln müssen.

Der Preis dafür liegt auf der Hand. Longhorn lebt vollständig im Rhythmus des Clusters, teilt sich Ressourcen mit produktiven Workloads und reagiert empfindlich auf Engpässe, die Kubernetes selbst gern produziert: überbuchte CPUs, knappe I/O-Budgets oder ein Netzwerk, das das IT-Team für "wahrscheinlich ausreichend" hielt. Laufen die Pods, die Longhorn-Dienste tragen, auf Systemen mit ohnehin hoher Last, droht im ungünstigsten Fall ein Dominoeffekt, der nicht nur Container, sondern auch deren Speicher in Mitleidenschaft zieht.

Ceph wirkt aus derselben Perspektive weniger wie ein Teil des Clusters, sondern wie eine eigenständige Speicherbasis, die Kubernetes bedient. Selbst wenn Rook Ceph als Kubernetes-Ressource ausrollt, bleibt die innere Logik von Ceph eine Storage-Logik. RADOS steuert Platzierung, Redundanz, Recovery und Rebalancing strikt nach eigenen Regeln. Der Administrator erhält dafür eine Speicherumgebung, die nicht nur Pods versorgt, sondern über RBD, CephFS und das Ceph Object Gateway mehrere Zugriffsmodelle auf Basis desselben RADOS-Objektspeichers anbietet.

Genau diese Breite macht Ceph attraktiv, sobald ein Cluster mehr darstellt als nur Kubernetes. Wachsen Plattformen, Teams oder Datenströme zusammen, profitieren sie von einem gemeinsamen Storage-Fundament. Eine gepflegte S3-Schnittstelle existiert für Longhorn dagegen nicht mehr. Zwar hatte SUSE entsprechende Pläne, das Longhorn-S3-Projekt gilt jedoch faktisch als eingestellt. Cephs Object Gateway hingegen befindet sich in aktivem und stabilem Betrieb. Der Preis für diese Flexibilität ist Komplexität. Ceph erfordert Planung und Betrieb als eigene Disziplin im administrativen Alltag. Zwar verursacht RADOS wenig laufenden Aufwand, wenn es sauber aufgesetzt ist. Um diesen Zustand zu erreichen, muss der Administrator sich jedoch intensiv mit Architektur und Betrieb befassen.

Performance aktuell im Wandel

Ein direkter Performancevergleich zwischen Longhorn und Ceph wirkt an dieser Stelle beinahe unfair. Die bisherige Longhorn Data Engine V1 gilt als träge, was ein wesentlicher Auslöser für den laufenden Neuaufbau war. Da dieser noch nicht abgeschlossen ist, kann eine Bewertung der Leistung nur den aktuellen Stand berücksichtigen.

Longhorn arbeitet Volume-orientiert und repliziert Blockdaten synchron über Knoten hinweg. Das passt gut zu vielen Kubernetes-Workloads, in denen StatefulSets jeweils ein Volume pro Instanz nutzen und Persistenz entlang klarer PVC-Grenzen organisiert ist. Der Administrator erkennt schnell, welches Volume unter Druck gerät, und kann Replikationsfaktoren oder Platzierung gezielt anpassen. Gleichzeitig macht sich die synchrone Replikation über das Netzwerk bemerkbar. Dieser Effekt fällt bei Longhorn weniger stark ins Gewicht als bei Ceph, wird jedoch durch die eingeschränkte Performance der V1 Data Engine zusätzlich verstärkt. Wer die Latenzen lokaler NVMe-Laufwerke gewohnt ist, wird mit Longhorn eher nicht zufrieden sein.

 

 

Auch bei Ceph bleibt die synchrone Replikation über Ethernet ein limitierender Faktor. Trotz erheblicher Fortschritte bei Bandbreiten hat sich an der Latenz klassischer Ethernet-Netze in den vergangenen Jahrzehnten wenig geändert. Ceph verteilt I/O über viele OSDs und skaliert über zusätzliche Nodes und Laufwerke. Das wirkt im Betrieb weniger Volume- als Cluster-orientiert. Der Verteilalgorithmus CRUSH gilt zudem nicht als besonders schnell. Die Entwickler haben jedoch kontinuierlich an Optimierungen gearbeitet. In der Praxis erreicht ein gut abgestimmtes Ceph bei gleichen Eingangsparametern – etwa Queue Depth und Request Size – häufig höhere IOPS-Werte als Longhorn.

Funktionen, die den Einsatz bestimmen

Der Funktionsumfang beeinflusst die Einsatzentscheidung unmittelbar, weil er Architektur- und Teamgrenzen berührt. Longhorn konzentriert sich konsequent auf Blockspeicher für Kubernetes und versucht, diesen Pfad möglichst reibungsarm zu gestalten. Das reicht in vielen Umgebungen aus, da Stateful-Workloads primär Blockvolumes benötigen und Object Storage oder Shared Filesystems ohnehin separat betrieben oder extern bezogen werden.

Ceph bringt diese zusätzlichen Zugriffsmethoden von Haus aus mit. Der IT-Verantwortliche konsolidiert damit häufig mehrere Anforderungen: CephFS für Shared Storage, RGW als S3-Ziel für Backups oder Artefakte – insbesondere für Anwendungen in Kubernetes –, und RBD für klassische Blockvolumes. Diese Breite macht Ceph vor allem für Plattformteams attraktiv, die Storage-Services aus einer Hand bereitstellen wollen.

Ein weiterer Unterschied liegt im organisatorischen Besitz des Speichers. In vielen Kubernetes-Teams stehen Selbstbedienung, schnelle Iterationen und GitOps-nahe Betriebsmodelle im Vordergrund. Longhorn erfüllt diese Erwartungen häufig, weil es sich wie ein natives Kubernetes-Subsystem verhält und Persistenz im selben Vokabular beschreibt wie Applikationen. Ceph passt besser dort, wo ein Infrastruktur- oder Plattformteam Storage als internes Produkt liefert – als stabile Grundlage für mehrere Cluster, Teams oder auch Verbraucher außerhalb von Kubernetes. In solchen Szenarien rechtfertigt der Mehraufwand den Nutzen, da eine wiederverwendbare Speicherbasis entsteht.

Fazit

Am Ende entscheidet der Administrator, welches Risiko er lieber managt. Longhorn verlagert Risiken stärker in die unmittelbare Kubernetes-Sphäre: Ressourcenknappheit, Node-Hygiene, Upgradedisziplin und der Reifegrad des Plattformbetriebs gewinnen an Bedeutung. Ceph verlangt hingegen Storage-Disziplin: Sauberes Netzdesign, klar definierte Failure-Domains, ausreichende Kapazitätsreserven, durchdachte Recovery-Strategien und das Bewusstsein, dass ein selbstheilendes System im Störfall aktiv arbeitet und dabei Last erzeugt – auch durch Rebalancing und Recovery, im Zweifel über die Kubernetes-Grenzen hinaus.

Beide Wege führen zu funktionierender Persistenz, fühlen sich im Betrieb jedoch grundlegend unterschiedlich an. IT-Verantwortliche sollten die Wahl daher nicht als Glaubensfrage behandeln. Wer primär Kubernetes-Workloads mit Blockvolumes versorgt, über ein Team mit starker Kubernetes-Kompetenz verfügt und Persistenz als Teil der Plattformautomation versteht, greift häufig zu Longhorn.

Wer Storage als skalierende Grundlage für Wachstum plant, neben Block auch Dateisysteme oder Objektspeicher aus derselben Basis nutzen will und bereit ist, Ceph als eigene Disziplin zu betreiben, landet oft bei Ceph – weil es langfristig die größere strategische Flexibilität bietet. (jp)