Longhorn vs. Rook-Ceph: Storage für Kubernetes

Persistente Workloads im Cluster sauber betreiben lassen? WZ-IT plant, baut und betreibt Kubernetes-Cluster inklusive Storage und Backup - auf Proxmox, Bare Metal und europäischer Infrastruktur, mit klarem Betriebs-Scope. Managed Kubernetes ansehen

Sobald Datenbanken oder zustandsbehaftete Anwendungen in Kubernetes laufen, braucht der Cluster persistenten Speicher. Zwei Lösungen dominieren die Diskussion um selbst betriebenes Storage: Longhorn und Rook-Ceph. Sie stehen für zwei Philosophien - schlankes Block-Storage gegen einen vollwertigen Storage-Orchestrator. Dieser Vergleich ordnet beide ein und beantwortet die eigentliche Frage: welche Lösung zu welchem Cluster passt. Stand Juli 2026.

Inhaltsverzeichnis

• Zwei Philosophien für Cluster-Storage
• Longhorn: schlankes Block-Storage
• Rook-Ceph: der Storage-Orchestrator
• Die beiden im Vergleich
• Und OpenEBS?
• Welche Lösung für welchen Cluster

Zwei Philosophien für Cluster-Storage

Der Unterschied beginnt beim Anspruch. Longhorn will genau eine Sache gut können: verteiltes Block-Storage für persistente Volumes, einfach zu betreiben. Rook-Ceph bringt mit Ceph ein vollwertiges Storage-System in den Cluster, das Block-, Datei- und Objekt-Storage zugleich liefert - mächtiger, aber auch schwerer.

Die Wahl ist damit weniger eine Feature-Frage als eine Abwägung zwischen Einfachheit und Mächtigkeit. Wer nur zuverlässige Volumes braucht, zahlt bei Ceph für Fähigkeiten, die er nicht nutzt. Wer mehrere Storage-Arten oder große Skalierung braucht, stößt bei reinem Block-Storage an Grenzen.

Longhorn: schlankes Block-Storage

Longhorn ist ein leichtgewichtiges, verteiltes Block-Storage-System, das von Rancher gestartet wurde und heute ein CNCF-Incubating-Projekt ist (seit November 2021). Es installiert sich als Kubernetes-Anwendung und legt für jedes Volume einen eigenen Controller an, mit synchroner Replikation über mehrere Knoten (Longhorn-Dokumentation).

Die wichtigsten Eigenschaften:

• Kein Single Point of Failure durch die verteilte Architektur.
• Inkrementelle Snapshots mit effizienter Änderungserkennung.
• Backups nach NFS oder S3-kompatiblen Speicher als getrennter Pfad.
• Web-Oberfläche für Verwaltung und Überblick.
• Keine dedizierten Storage-Knoten nötig - Longhorn nutzt die Volumes der vorhandenen Nodes.

Damit ist Longhorn der pragmatische Standard für die meisten selbst betriebenen Cluster: schnell aufgesetzt, überschaubar im Betrieb, robust genug für produktive Datenbanken. Wichtig bleibt die Abgrenzung: Replikation schützt vor Knoten-Ausfall, ist aber kein Backup - der Backup-Pfad gehört immer dazu.

Rook-Ceph: der Storage-Orchestrator

Rook ist ein CNCF-graduiertes Projekt und orchestriert Ceph in Kubernetes - ein ausgereiftes, im Petabyte-Bereich bewährtes verteiltes Storage-System. Rook automatisiert dabei Deployment, Konfiguration, Skalierung und Heilung des Ceph-Clusters, sodass er sich weitgehend selbst verwaltet.

Der entscheidende Vorteil: Ceph liefert drei Storage-Arten in einem System:

• Block (RBD) - für persistente Volumes wie bei Longhorn.
• Dateisystem (CephFS) - geteilter Zugriff mehrerer Pods auf dieselben Daten.
• Objekt (RGW) - eine S3-kompatible Schnittstelle direkt im Cluster.

Der Preis dafür ist Komplexität und Ressourcenbedarf. Ceph besteht aus Monitors, OSDs und Managern, die deutlich mehr RAM als Longhorn brauchen, dedizierte Datenträger pro Storage-Knoten voraussetzen und Tuning-Erfahrung verlangen. Rook nimmt viel Betriebsarbeit ab, aber das Fundament bleibt ein anspruchsvolles Storage-System - das sich erst ab einer gewissen Größe und Anforderung auszahlt.

Die beiden im Vergleich

Und OpenEBS?

Als dritte Option taucht häufig OpenEBS auf. Es verfolgt einen modularen Ansatz mit mehreren Storage-Engines und ist besonders dort interessant, wo lokale, latenzarme Volumes im Vordergrund stehen. Für die Grundsatzentscheidung gilt aber dieselbe Logik: Die meisten Cluster brauchen zuverlässiges Block-Storage mit guten Backups - und dafür ist der Weg über Longhorn der kürzeste. Rook-Ceph und OpenEBS lohnen sich, wenn konkrete Anforderungen (Objekt-Storage, geteiltes Dateisystem, spezielle Performance-Profile) darüber hinausgehen.

Welche Lösung für welchen Cluster

Die ehrliche Kurzfassung: Im Zweifel mit Longhorn starten. Die meisten Cluster, die glauben, Ceph zu brauchen, brauchen eigentlich verlässliches Block-Storage mit guten Backups - und das liefert Longhorn mit einem Bruchteil der Betriebsfläche.

• Longhorn, wenn Sie persistente Volumes für Datenbanken und Anwendungen brauchen, den Betrieb schlank halten wollen und keine dedizierten Storage-Knoten stellen möchten.
• Rook-Ceph, wenn Sie zusätzlich geteiltes Dateisystem oder S3-Objekt-Storage im Cluster brauchen, in den zweistelligen Knoten-Bereich skalieren oder Ceph-Erfahrung im Team haben.

Unabhängig von der Wahl gehört ein getrennter, getesteter Backup-Pfad dazu - welche Ebenen dabei separat geschützt werden müssen, zeigt der Leitfaden zu Kubernetes-Backups. Und wie die Distribution darunter das Betriebsmodell prägt, ordnet k3s vs. RKE2 vs. Talos ein.