Individueller Provider-Block-Storage vs. Ceph

Speicher als Cloud-Feature oder als kontrollierbare Plattform

Persistenter Storage gehört zu den unscheinbarsten, aber wirkungsmächtigsten Schichten moderner Plattformen. Er entscheidet darüber, ob Anwendungen skalierbar bleiben, ob Daten beweglich sind – und wie teuer ein späterer Richtungswechsel wird. Block Storage der Cloud-Provider wirkt dabei oft wie ein neutrales Infrastrukturfeature. In Wirklichkeit ist er tief in die jeweilige Plattformlogik eingebettet.

Provider-Block-Storage und Ceph lösen dasselbe Grundproblem: zustandsbehaftete Daten zuverlässig speichern. Architektonisch stehen sie jedoch für zwei gegensätzliche Modelle. Das eine bindet Storage an die Cloud. Das andere macht ihn zu einer eigenständigen, kontrollierbaren Plattformkomponente.

Provider-Block-Storage: Storage als Teil der Cloud-Plattform

Block-Storage-Angebote der Cloud-Provider sind auf schnelle Verfügbarkeit optimiert. Volumes lassen sich mit wenigen Klicks an virtuelle Maschinen oder Kubernetes–Nodes binden. Snapshots, Replikation und grundlegende Ausfallszenarien sind integriert, Betrieb und Verfügbarkeit liegen vollständig beim Anbieter.

Für viele Workloads ist das ausreichend – insbesondere dann, wenn Architektur, Laufzeitumgebung und Datenhaltung innerhalb einer einzelnen Cloud verbleiben. Der Einstieg ist einfach, der operative Aufwand minimal.

Diese Form von Storage ist jedoch kein eigenständiger Layer.

Plattformlogik statt neutraler Speicherschicht

Provider-Block-Storage ist Teil der jeweiligen Cloud-Plattformlogik. Volumes sind an Zonen gebunden, Performance-Profile werden über vordefinierte Klassen gesteuert, Replikation folgt internen Anbieterarchitekturen. Kubernetes nutzt diese Ressourcen über CSI-Treiber, bleibt jedoch an die Einschränkungen des jeweiligen Storage-Angebots gebunden.

Ein Wechsel der Umgebung bedeutet fast immer eine aktive Datenmigration. Diese erfolgt unter Last, ist zeitkritisch und verursacht zusätzliche Kosten. Architekturentscheidungen auf Storage-Ebene wirken damit langfristig und oft irreversibel.

Storage wird hier konsumiert – nicht gestaltet.

Ceph: Storage als eigenständige Infrastruktur

Ceph adressiert Storage aus einer anderen Perspektive. Als verteiltes Open-Source-System stellt Ceph Block-Storage über RBD bereit, das sich nahtlos in Kubernetes integrieren lässt. Replikation, Fehlertoleranz und Self-Healing sind integrale Bestandteile des Systems.

Storage wird damit zu einer eigenständigen Plattformkomponente – unabhängig davon, ob Kubernetes On-Premises, in einer europäischen Cloud oder verteilt über mehrere Standorte betrieben wird. Daten liegen nicht in Zonen, sondern in einem Cluster.

Ceph ist nicht Cloud-Storage. Es ist Storage-Infrastruktur.

Architekturkontrolle als Kernunterschied

Der entscheidende Unterschied liegt in der Architekturkontrolle. Ceph abstrahiert Hardware vollständig und verteilt Daten über ein skalierbares Cluster. Kapazität und Performance wachsen horizontal. Redundanz, Replikation und Ausfallsicherheit werden über Policies definiert – nicht über SKU-Auswahl oder Anbieter-Limits.

Für Kubernetes–Plattformen entsteht so ein persistenter Storage-Layer, der nicht an einzelne Nodes, Zonen oder Clouds gekoppelt ist. Stateful Workloads bleiben beweglich. Cluster lassen sich erweitern, verschieben oder neu aufsetzen, ohne die Datenhaltung neu zu denken.

Das ist mit Provider-Block-Storage strukturell nicht möglich.

Operative Reife statt Bequemlichkeit

Dieser Ansatz verlangt operative Reife. Ceph ist kein „Fire-and-Forget"-Service. Netzwerkdesign, Hardwareauswahl, Monitoring, Upgrades und Lifecycle-Management sind Teil der Verantwortung. Fehler in der Architektur wirken sich unmittelbar aus.

Dafür entsteht ein Storage-System, das langfristig planbar ist: technisch transparent, auditierbar und unabhängig von kurzfristigen Preis- oder Produktentscheidungen einzelner Anbieter. Optimierung bedeutet bessere Architektur – nicht höhere Service-Tiers.

Komplexität wird hier nicht vermieden, sondern kontrolliert.

Relevanz für Kubernetes–Plattformen

Gerade in Kubernetes–Umgebungen mit zustandsbehafteten Anwendungen, regulatorischen Anforderungen oder europäischem Infrastrukturanspruch verschiebt sich die Bewertung deutlich. Provider-Block-Storage vereinfacht den Einstieg, bindet Storage jedoch fest an die Plattform.

Ceph entkoppelt Datenhaltung von Compute und Cloud. Storage wird wiederverwendbar, konsistent und über mehrere Umgebungen hinweg nutzbar. Für Plattformen, die langfristig betrieben und weiterentwickelt werden sollen, ist das ein entscheidender Unterschied.

Verdichteter Vergleich

Wann welcher Ansatz sinnvoll ist

Provider-Block-Storage ist sinnvoll für:

• einfache Cloud-Workloads
• schnelle Proof-of-Concepts
• geringe Anforderungen an Datenportabilität
• Fokus auf minimalen Betriebsaufwand

Ceph ist sinnvoll für:

• Kubernetes–zentrale Plattformarchitekturen
• zustandsbehaftete Anwendungen
• regulierte oder souveräne Infrastrukturen
• Multi-Cluster- oder Hybrid-Setups
• langfristige Speicherstrategien

Fazit

Persistente Daten sind kein Nebenprodukt der Plattform. Sie entscheiden darüber, wie beweglich eine Architektur bleibt – heute und in den nächsten Jahren.

Provider-Block-Storage ordnet Storage der Cloud unter. Ceph macht Storage zu einer eigenständigen, gestaltbaren Infrastrukturkomponente.

Der Unterschied ist nicht primär technisch, sondern strategisch. Wer Speicher an eine Plattform bindet, bindet auch seine Daten. Wer Storage kontrolliert, behält Freiheit – selbst dann, wenn sich Cloud, Standort oder Betriebsmodell ändern.