Geordnetes Wachstum

von Martin Loschwitz

Skalierbare Umgebungen benötigen skalierbaren Speicher. Für seine Kubernetes-Distribution OpenShift liefert Red Hat diesen in Form der OpenShift Data Foundation. Das Produkt bündelt zahlreiche Komponenten wie Ceph, Rook, CSI und NooBaa sowie passende Kubernetes-Operatoren. Es richtet sich an Umgebungen mit OpenShift-Clustern mit einer integrierten Storage-Plattform. Im Test überzeugte das Werkzeug technisch und funktional, hat in höheren Ausbaustufen jedoch das Potenzial, eine beachtliche Schneise in das IT-Budget zu fräsen.

Red Hat OpenShift Data Foundation (ODF) ist die Plattform für Software-defined-Storage für Red Hat OpenShift. Technisch basiert ODF auf Ceph und läuft vollständig containerisiert. Operatoren übernehmen die Integration zwischen Ceph und Kubernetes, dem Fundament von OpenShift. ODF eignet sich für OpenShift-Umgebungen, die persistenten, hochverfügbaren und skalierbaren Speicher benötigen – sowohl für klassische Stateful Workloads als auch für cloudnative Anwendungen und hybride Szenarien.

OpenShift bringt mit Kubernetes lediglich ein grundlegendes Storage-Framework mit. Dazu gehören PersistentVolumes (PV), PersistentVolumeClaims (PVC) und das Container Storage Interface (CSI). Kubernetes definiert damit, wie Pods Speicher anfordern und an Container anbinden. Eine eigene hochverfügbare Storage-Implementierung liefert Kubernetes jedoch nicht. Stattdessen greift es auf externe Speichersysteme zurück – etwa NFS, iSCSI-Targets, SAN-Systeme oder Cloud-Blockspeicher. Genau für diese Integration wurde das CSI geschaffen: Es ermöglicht, externe Storage-Funktionen über zusätzliche Komponenten einzubinden.

ODF liefert moderne Speichermechanismen

Hier setzt ODF an. Das Produkt stellt innerhalb des OpenShift-Clusters eine eigene verteilte Speicherschicht bereit. Anders als klassische Storage-Backends existiert diese Infrastruktur nicht außerhalb, sondern als Bestandteil des Clusters selbst. ODF nutzt vorhandene Kubernetes-Worker-Nodes mit lokalen Laufwerken als Storage-Nodes und verwaltet die Blockgeräte direkt.

In Kubernetes fordern Pods Speicher über PVCs an. Diese sind an StorageClasses gebunden, die definieren, wie Speicher bereitgestellt wird. CSI bildet dabei das generische Framework. Für den praktischen Einsatz sind jedoch ein technologiespezifischer Treiber und passende Parameter in der jeweiligen StorageClass erforderlich. Ohne ODF verweist eine StorageClass meist auf einen externen Provider – etwa AWS EBS, VMware vSphere, einen vorhandenen externen Ceph-Cluster oder eine klassische Storage-Appliance.

Gerade in On-Premises-Umgebungen entsteht hier häufig ein Problem: Klassische SAN- oder NAS-Systeme sind teuer oder für dynamische Container-Workloads zu unflexibel. Viele Administratoren vermeiden deshalb diese Infrastruktur. Kubernetes selbst stellt jedoch keine Mechanismen für Replikation, Datenverteilung oder Self- Healing auf Storage-Ebene bereit. Lediglich lokale Laufwerke lassen sich als Local Volumes einbinden – ein Ansatz, der für moderne Cluster-Infrastrukturen kaum ausreicht. ODF schließt diese Lücke. Das Produkt stellt Block-, File- und Object-Storage bereit, integriert sich direkt in das Kubernetes-CSI-Modell und übernimmt Replikation, Ausfallsicherheit sowie Daten- verteilung. Als natives Red-Hat-Produkt integriert es sich eng in OpenShift und lässt sich mit wenigen Schritten installieren.

Storage läuft vollständig als Container-Workload

Die ODF-Installation erfolgt über einen von Red Hat bereitgestellten Operator. Im Kubernetes-Umfeld bezeichnet dieser Begriff Sammlungen von Custom Resource Definitions (CRDs), die das native Kubernetes-API um zusätzliche Objekttypen erweitern und gleichzeitig Automatisierungslogik bereitstellen. Der Operator rollt die Ceph-Komponenten als Pods im Cluster aus und stellt dabei alle zentralen Dienste des Objektspeichers mit seinem Kern RADOS bereit:

- OSDs (Object Storage Daemons)

- Metadata Server (MDS, für CephFS)

- Das Ceph-Object-Gateway (für S3-kompatiblen Objektspeicher)

Die auf den Kubernetes-Nodes vorhandenen Blockgeräte bindet ODF je nach Szenario über den ebenfalls enthaltenen "Local Storage Operator" oder direkt als Blockspeichergeräte ein. ODF verwaltet diese Geräte anschließend vollständig autonom. Red Hat formuliert das Versprechen entsprechend klar: installieren, konfigurieren und betreiben.

Im Test zeigt sich dabei ein wesentlicher Unterschied zu klassischen Ceph-Installationen: Administratoren arbeiten kaum noch direkt mit Ceph, die Konfiguration erfolgt primär über Custom Resource Definitions in OpenShift. Weil ODF intern auf Rook setzt, das Ceph vollständig in Kubernetes betreibt, tritt der eigentliche Storage-Stack weitgehend in den Hintergrund. Selbst erfahrene Ceph-Admins müssen daher zunächst einen Blick in die Dokumentation werfen, um die interne Struktur von ODF nachvollziehen zu können.

ODF stellt drei Storage-Typen bereit: Der Blockspeicher (RADOS Block Device, RBD) richtet sich vor allem an klassische Stateful Workloads wie Datenbanken oder Middleware. OpenShift bindet RBD-Images als PersistentVolume ein. Der typische Zugriff erfolgt im Modus Read-WriteOnce, also durch einen Client gleichzeitig. File Storage auf Basis von CephFS mit POSIX-Kompatibilität richtet sich an Anwendungen mit gemeinsam genutztem Speicher.

Hier unterstützt ODF den Zugriffstyp ReadWriteMany, sodass mehrere Pods parallel auf dieselben Daten zugreifen können. Auch ReadWriteOnce ist möglich. Schließlich bildet Object Storage S3-kompatiblen Speicher für cloudnative Anwendungen, Backups oder Anwendungsdaten. Typische Inhalte sind etwa Bilder, Videos oder andere Assets, auf die Anwendungen über HTTP(S) zugreifen.

Diese Dreiteilung deckt einen Großteil typischer Unternehmensanforderungen ab. Im Test arbeiteten insbesondere der S3-basierte Speicher über das Ceph Oject Gateway sowie Blockspeicher über RBD stabil und zuverlässig. File Storage reagiert dagegen stärker auf Netzwerk- und Latenzbedingungen. Ein über mehrere Standorte gestrecktes CephFS ist daher in der Praxis kaum sinnvoll.

Zuverlässige Datenkonsistenz und Wiederherstellung

ODF repliziert Daten standardmäßig dreifach über unterschiedliche Knoten. Fällt ein Worker-Node aus, startet Kubernetes die Ceph-Pods neu, während Ceph die Datenverteilung reorganisiert. Dieses Zusammenspiel ist zentral: Kubernetes stellt die Verfügbarkeit der Pods sicher, Ceph garantiert Datenkonsistenz und Replikation. Im Test erkannte Ceph zunächst die fehlenden OSDs und startete nach etwa zehn Minuten ein Rebalancing sowie die Wiederherstellung fehlender Replikate. Kubernetes versuchte parallel, die entsprechenden Pods neu zu starten. Ist jedoch das zugrunde liegende Blockgerät ausgefallen, kann dieser Mechanismus naturgemäß nicht greifen.

In unserem Test funktionierte dieser Prozess zuverlässig. Allerdings erzeugen Recovery- und Backfilling-Vorgänge in größeren Clustern messbare I/O-Last. Ursache ist unter anderem der CRUSH-Algorithmus von Ceph, der die Datenverteilung berechnet. Eine zentrale Metadaten-Datenbank existiert nicht. Stattdessen berechnet jeder Client anhand des CR-USH-Algorithmus selbst, auf welchen OSD Daten geschrieben oder von dort gelesen werden.

Horizontale Skalierung für mehr Kapazität und Leistung

ODF skaliert horizontal über zusätzliche Worker-Nodes oder weitere Blockgeräte. Im Test ließ sich die Kapazität durch das Hinzufügen neuer Laufwerke ohne Downtime erweitern. Der Operator erkennt neue Geräte automatisch und integriert sie in den Ceph-Cluster, sofern der Administrator keine abweichende Konfiguration definiert. Die Skalierung wirkt sich nicht nur auf die Kapazität aus. Zusätzliche OSDs schaffen weitere parallele I/O-Pfade und erhöhen damit auch die mögliche Bandbreite.

ODF ist eng in OpenShift integriert. Das Produkt erstellt automatisch passende StorageClasses für den Zugriff auf den Ceph-Cluster, stellt PersistentVolumeClaims für Entwicklungs-Workflows bereit und bindet den Storage direkt in OpenShift Observability ein. Auch Backups von Workloads lassen sich über OpenShift Advanced Data Protection (OADP) direkt auf ODF-Volumes speichern, intern über Velero. Im Unterschied zu externem Storage entfällt damit zusätzlicher Aufwand für Netzwerk- oder SAN-Konfiguration. ODF tritt als umfassende Storage-Infrastruktur innerhalb des Clusters auf.

Die Architektur funktioniert technisch stabil, bringt jedoch deutliche Ressourcenanforderungen mit sich. Wer ODF hyperkonvergent einsetzen möchte, muss ausreichend CPU, RAM sowie lokale NVMe- oder SSD-Kapazitäten einplanen. Für kleine Lab-Cluster ist ODF damit häufig überdimensioniert. In solchen Umgebungen bieten sich entweder leichtere Kubernetes-Distributionen oder ein direktes Ceph-Deployment über Rook an. In produktiven Umgebungen mit OpenShift schließt ODF jedoch eine reale Lücke zwischen Kubernetes und klassischer Storage-Infrastruktur – inklusive vollständigem Herstellersupport für OpenShift und ODF.

Lizenzen adressieren unterschiedliche Szenarien

Red Hat bietet OpenShift Data Foundation in zwei Varianten an: ODF Essentials und ODF Advanced. Beide basieren technisch auf derselben Ceph-Grundlage und nutzen identische Operator-Mechanismen in OpenShift. Die Unterschiede liegen nicht in der Architektur, sondern im Funktionsumfang und in den erforderlichen Red-Hat-Subskriptionen.

ODF Essentials konzentriert sich auf die Bereitstellung von persistentem Block-, Object- und File-Storage innerhalb eines einzelnen OpenShift-Clusters. Damit deckt die Variante die typischen Anforderungen vieler Stateful Workloads ab. Im Test zeigte sich, dass Essentials für zahlreiche Enterprise-Anwendungen ausreichend ist. Einschränkungen betreffen vor allem Multi-Cluster-Szenarien, Disaster-Recovery- Funktionen über Cluster-Grenzen hinweg sowie erweiterte Object-Storage-Funktionen. ODF Advanced erweitert den Funktionsumfang um Funktionen für größere Enterprise-Deployments. Dazu gehören insbesondere Multi-Cluster-Replikation, Disaster Recovery (Metro-DR, Regional-DR), erweiterte Objektspeicher-Funktionen und ein Multi-Cloud-Gateway zur Anbindung mehrerer S3-Ziele aus einer Umgebung heraus

Im Test erwies sich vor allem die Clusterübergreifende Replikation als entscheidender Unterschied. Während Essentials nur innerhalb eines Clusters replizierte, synchronisierte Advanced Daten zwischen zwei OpenShift-Clustern ("Zones"). Für Szenarien mit geografischer Redundanz oder getrennten Rechenzentren ist diese Funktion zentral. Darüber hinaus unterstützt Advanced komplexere Object-Storage-Szenarien, etwa das Tiering zu externen S3-Backends. Diese Funktionen sind technisch solide umgesetzt, erhöhen jedoch die Komplexität der Konfiguration deutlich. Administratoren müssen sich bei ODF Advanced daher auf eine spürbar steilere Lernkurve einstellen.

Open-Source-Komponenten optimieren Speichermanagement

ODF ist kein monolithisches Produkt, sondern kombiniert mehrere Open-Source-Technologien, die über Operatoren integriert und verwaltet werden. Wer ODF einsetzt, arbeitet faktisch mit einem kuratierten Ceph-Stack, ergänzt um Kubernetes-native Integrationskomponenten. Das enthaltene Ceph entspricht der von Red Hat gepflegten Downstream- Variante, die der Hersteller regelmäßig mit den jeweiligen Open-Shift-Versionen abstimmt.

ODF nutzt außerdem den Rook Operator, genauer gesagt eine von Red Hat angepasste Variante. Rook rollt Ceph als Container-Workload aus und übernimmt dessen Verwaltung im Kubernetes-Cluster. Die Verbindung zwischen Ceph und Kubernetes erfolgt über das Container Storage Interface. Für S3-kompatiblen Speicher kombiniert ODF zwei Komponenten. Die eigentliche S3-Funktionalität stellt Ceph über das RADOS Gateway (RGW) bereit. Für Szenarien mit mehreren S3-Backends nutzt ODF zusätzlich NooBaa. Diese Komponente fungiert als Multi-Cloud-Object-Storage-Gateway und bindet unterschiedliche S3-Ziele im Hintergrund an.

Der Vorteil liegt in der Transparenz für Anwendungen. Diese greifen stets auf eine einheitliche S3-Schnittstelle zu, während NooBaa intern verschiedene Speicherendpunkte verwaltet. So lassen sich etwa Replikation zwischen S3-Backends oder Tiering zwischen lokalem und externem Storage umsetzen. Nutzen IT-Verantwortliche diese Funktionen vollständig, entsteht ein echtes Multi-CloudObject-Gateway (MCG). RADOS Gateway und NooBaa ergänzen sich dabei funktional und ersetzen sich nicht gegenseitig.

Hyperkonvergent: Viel Leistung kann teuer werden

Red Hat bewirbt ODF als vollständig softwaredefiniert und containerisiert. Dieser Anspruch bestätigte sich im Test. Ceph und Rook arbeiten innerhalb von ODF zuverlässig zusammen. Neue Worker-Nodes mit geeigneten Blockgeräten ließen sich manuell oder automatisch in den Storage-Verbund integrieren. Der hyperkonvergente Ansatz hat jedoch Konsequenzen, denn Speicher konkurriert mit Workloads um CPU und RAM. Administratoren müssen daher ausreichende Ressourcen für Storage-Knoten einplanen. Gerade bei NVMe- oder SSD-basierter Infrastruktur kann das die Hardwarekosten deutlich erhöhen.

Ein wichtiges Argument für ODF ist die gleichzeitige Unterstützung von Block-, File- und Object-Storage. Im Test überzeugte insbesondere der Blockspeicher durch stabile Performance bei Datenbank-Workloads. PVCs provisioniert ODF zuverlässig und Resize-Operationen funktionieren online. Latenz und Durchsatz hängen dabei stark von der eingesetzten Hardware ab. Mit NVMe-Geräten lassen sich solide Werte erreichen. SATA-SSDs erhöhen die Latenz spürbar, klassische Festplatten eignen sich vor allem für selten genutzte Daten wie Archive.

Das Netzwerk bleibt – wie bei Ceph üblich – ein zentraler Leistungsfaktor. Ethernet bildet häufig die praktische Obergrenze der erreichbaren Latenz. Mit Infiniband- oder FibreChannel-basierten Storage-Architekturen kann ODF daher nicht konkurrieren. Alle Standardfunktionen des Container Storage Interface unterstützt ODF vollständig. Dazu gehören die dynamische Volume-Erstellung, die Erweiterung bestehender Volumes, Snapshotting und das Klonen von Volumes. Im Test arbeiteten Snapshot-Operationen konsistent und erzeugten keine inkonsistenten Volume-Zustände.

CephFS glänzt bei geteilten Daten

CephFS zeigte im Test seine Stärken bei gemeinsam genutzten Daten, etwa in Continuous-Integration-Umgebungen. Mehrere Pods konnten parallel auf dieselben Dateisysteme zugreifen, ohne Stabilitätsprobleme zu verursachen. Die Performance liegt jedoch unter dem Niveau spezialisierter NAS-Systeme, insbesondere bei metadatenintensiven Operationen. Hersteller wie NetApp haben ihre Plattformen über Jahre gezielt auf diese Anforderungen optimiert und erreichen hier weiterhin bessere Werte.

Objektspeicher über NooBaa und RADOS Gateway arbeitete im Test kompatibel mit mehreren gängigen S3-Clients. Die Performance reicht für Backups und typische Anwendungsdaten aus, eignet sich jedoch weniger für stark latenzkritische Workloads. In vielen Szenarien spielt die interne Latenz ohnehin eine untergeordnete Rolle, da bei externen S3-Zielen die Netzwerklatenz zwischen Plattform und Client meist deutlich höher ist.

Positiv fiel die Integration in OpenShift auf. Anwendungen können S3-Buckets dynamisch über Custom Resource Definitions anlegen. Dieser Ansatz integriert Object Storage sauber in den Kubernetes-Workflow und wirkt deutlich eleganter als viele klassische Ceph-Deployments.

Self-Healing schützt zuverlässig

Node-Ausfälle erkannte ODF im Test zuverlässig. Fehlende Replikate bestehender Daten ersetzte der Cluster nach kurzer Zeit automatisch. Beim Ausfall eines Worker-Nodes blieben Volumes ohne Unterbrechung erreichbar, und laufende I/O-Vorgänge setzten sich ohne erkennbare Störung fort. Damit eignet sich ODF auch für kritische Anwendungen.

ODF Advanced unterstützt zusätzlich Metro-DR- und Regional-DR-Szenarien. Dabei repliziert das System Volumes synchron oder asynchron zwischen Clustern. Im Test erwies sich das Einrichten allerdings als deutlich komplexer als bei klassischen Storage-Systemen. Die Konfiguration über DR-Richtlinien ("Policies") erforderte eine präzise Abstimmung zwischen den beteiligten Clustern sowie sorgfältige Tests, insbesondere im Hinblick auf die vorhandene Latenz. Nach erfolgreicher Einrichtung funktionierte der Failover zwischen replizierten Volumes jedoch reproduzierbar. Intern greift ODF hier auf bestehende Ceph-Funktionen zurück, vor allem auf "rbd-mirror".

ODF ermöglicht zudem die Definition mehrerer StorageClasses mit unterschiedlichen Replikations- oder Performanceprofilen. Im Test erwies sich das als hilfreich für verschiedene SLA-Klassen oder gemischte Konfigurationen mit SSDs und HDDs. Diese lassen sich über Policys sauber voneinander trennen und gezielt exponieren. Die Policy-basierte Verwaltung orientiert sich dabei konsequent an Kubernetes-Standards.

Fazit

Red Hat OpenShift Data Foundation ist technisch eine konsequent in OpenShift integrierte Ceph-Distribution mit erweitertem Funktionsumfang für Enterprise-Szenarien. Im Test erfüllte ODF die typischen Storage-Anforderungen containeri- sierter Workloads zuverlässig. Block- und File-Volumes lassen sich dynamisch bereitstellen, Snapshot-Funktionen arbeiten stabil, und Node-Ausfälle führen weder zu Datenverlust noch zu unmittelbarer Downtime. Die Stärken von ODF liegen vor allem in der engen Integration in OpenShift. Storage-Classes, Monitoring, Lifecycle-Management und Operator-gesteuerte Updates greifen sauber ineinander. Administratoren müssen weder separate Storage-Appliances noch eigenständige Managementoberflächen betreiben. Das vereinfacht den Betrieb deutlich, insbesondere in homogenen OpenShift-Umgebungen.

Dem stehen jedoch zwei Einschränkungen gegenüber. Erstens ist ODF ressourcenintensiv. Für den produktiven Einsatz sind ausreichend CPU, RAM und leistungsfähige lokale Laufwerke erforderlich. In kleinen Clustern wirkt ODF daher schnell überdimensioniert. Zweitens steigt die Komplexität mit erweiterten Funktionen wie Multi-Cluster-Replikation oder Multi-Cloud-Gateway deutlich an. Diese Funktionen arbeiten zuverlässig, verlangen jedoch sorgfältige Planung und erfahrene Administratoren.

Insgesamt hinterlässt ODF einen stabilen und ausgereiften Eindruck. Klassische SAN- oder NAS-Systeme ersetzt es jedoch nicht in jedem Szenario. Für containerisierte Workloads in OpenShift stellt ODF jedoch eine durchgängig integrierte und technisch belastbare Speicherinfrastruktur bereit. Wer OpenShift als zentrale Plattform betreibt und Stateful Workloads konsistent integrieren möchte, erhält mit ODF ein leistungsfähiges, wenn auch ressourcenintensives Fundament.

Produkt	Softwaredefinierter Speicher für Kubernetes.
Hersteller	Red Hat https://www.redhat.com/en/technologies/cloud-computing/openshift-data-foundation
Preis	Der Preis orientiert sich an Speicherbedarf und Supportlevel. Üblicherweise ist das Produkt in 256 TByte großen "Expansion Packs" lizenziert, die für eine Jahressub-skription bei rund 14.000 US-Dollar liegen.
Systemanforderungen	30 logische CPU-Kerne (auch vCPUs) und 72 GByte RAM. Das Produkt erfordert mindestens drei Speicherlaufwerke (für die Grundausstattung), pro zusätzlichem Satz von Laufwerken (jeweils drei) weitere sechs logische CPUs sowie 15 GByte RAM.
Technische Daten	https://www.it-administrator.de/downloads/datenblaetter

Produkt	Softwaredefinierter Speicher für Kubernetes.
Hersteller	Red Hat https://www.redhat.com/en/technologies/cloud-computing/openshift-data-foundation
Preis	Der Preis orientiert sich an Speicherbedarf und Supportlevel. Üblicherweise ist das Produkt in 256 TByte großen "Expansion Packs" lizenziert, die für eine Jahressub-skription bei rund 14.000 US-Dollar liegen.
Systemanforderungen	30 logische CPU-Kerne (auch vCPUs) und 72 GByte RAM. Das Produkt erfordert mindestens drei Speicherlaufwerke (für die Grundausstattung), pro zusätzlichem Satz von Laufwerken (jeweils drei) weitere sechs logische CPUs sowie 15 GByte RAM.
Technische Daten	https://www.it-administrator.de/downloads/datenblaetter

Integration in OpenShift	8
Disaster Recovery	8
Handhabung und Konfiguration	8
Skalierbarkeit	8
Performance	7
Die Details unserer Testmethodik finden Sie unter https://www.it-administrator.de/testmethodik