Teil des croit Rust-Stacks für Ceph
croit FlashStore OSD:
ein Ceph-OSD, in Rust neu gebaut für NVMe
- +50%* Durchsatz Replizierte Pools, Mittel über 10 Tests, 30 NVMe-OSDs, Kernel-TCP
- −52%* p99-Latenz Replizierte Pools, 48 Clients × QD16, 30 NVMe-OSDs, Kernel-TCP
- −36%* CPU pro Operation Replizierte Pools, weniger in allen 20 Tests, 30 NVMe-OSDs, Kernel-TCP
*Basierend auf dem Benchmark vom 9. November 2026, Build 422be26.
Auf Flash wartet Ceph auf die CPU
Ein NVMe-Laufwerk fürs Rechenzentrum liefert mehrere hunderttausend 4k-IOPS. Der klassische OSD entstand, als das Laufwerk die Grenze war. Heute ist es die CPU-Zeit pro Operation, und ein schnelleres Laufwerk hilft nicht mehr.
- 01
Für aktive Workloads gebaut
Von VMware migrierte VMs, Datenbanken, ML-Pipelines, die GPUs auslasten, HPC-Scratch. Hier entscheiden Bandbreite und IOPS pro Kern, ob Ceph passt.
- 02
Gleiche Laufwerke, Server und Netz
Der Gewinn kommt aus dem Datenpfad des OSD. Auf hyperkonvergenten Knoten gehen frei gewordene CPU und frei gewordener Speicher an die VMs zurück; auf Storage-Knoten sind sie Reserve oder weniger Kerne beim nächsten Kauf.
- 03
Open Source, mit oder ohne croit
croit FlashStore OSD steht unter LGPL-3.0, die Rust-Client-Bibliotheken unter MPL-2.0. Es gibt keine Lizenzgebühr und keine kapazitätsbasierten Preise. croit FlashStore OSD läuft in bestehenden Ceph-Clustern, mit oder ohne croit.
Außen dasselbe Ceph, innen ein neuer Datenpfad
Beide Seiten zeigen den Weg eines Schreibvorgangs durch einen OSD. BlueStore schickt jede Operation durch gemeinsame Warteschlangen und Locks; seine Daten gehen direkt aufs Laufwerk, seine Metadaten durch RocksDB und BlueFS. croit FlashStore OSD gibt jedem CPU-Kern eine eigene Spur, vom Netzwerk bis zum Laufwerk, ohne RocksDB im Metadatenpfad.
1 · msgr2 · cephx
Außen ein gewöhnlicher OSD
Monitore, Manager, unveränderte Clients und klassische OSDs sprechen mit ihm wie gewohnt, unter derselben OSDMap und denselben CRUSH-Regeln. Ein Pool kann beide Arten von OSD enthalten. Innen betreibt jeder Kern eigene Verbindungen und reicht jede Operation über lock-freie Ringe an den Kern weiter, dem ihre PG gehört.
2 · Threads
Ein Kern pro Placement Group
Jede PG gehört genau einem gepinnten Kern und wartet daher nie auf ein Lock. Kern 0 übernimmt zusätzlich die Steuerung: Monitore, Manager, Heartbeats und Maps.
3 · Storage-Engine
B+-Baum und Log pro Kern
Jeder Kern besitzt einen Teil des Laufwerks mit eigenem Write-Ahead-Log, Copy-on-Write-B+-Baum, Allokator und Gerätewarteschlange. Der B+-Baum hält nur Metadaten; Daten landen in frischen 4K-Extents, werden nie an Ort und Stelle überschrieben und parallel zu ihrem Log-Eintrag geschrieben. Standardmäßig gibt es kein RocksDB, kein BlueFS und keine Compaction.
4 · I/O-Pfad
Keine Kopien im Store
Ein Schreibvorgang wird einmal kopiert, beim Empfang aus dem Netzwerk, mit RDMA nicht einmal dann. Der Store schreibt ihn per Referenz aus dem Empfangspuffer, über den eigenen io_uring- oder SPDK-Ring des Kerns. Bestätigt wird er erst, wenn er überall auf dem Medium liegt.
„BlueStore läuft in sehr vielen Produktionsclustern und muss für alle stabil und kompatibel bleiben. croit FlashStore OSD gab uns die Freiheit, eine Storage-Engine für NVMe von Grund auf zu entwerfen, neben BlueStore statt an seiner Stelle. Was wir dabei lernen, bieten wir dem Ceph-Projekt an.“
Igor Fedotov, Ceph-Engineer bei croit und Mitglied des Ceph Steering Committee
Was wir gemessen haben
Gleiche Hardware, schnellere Storage-Engine
Wir haben dieselben Benchmark-Tests auf demselben Cluster mit 30 NVMe-OSDs laufen lassen, einmal mit BlueStore aus unverändertem Ceph 21.2.0 und einmal mit croit FlashStore OSD, über Kernel-TCP mit unveränderten Ceph-Clients. Der Durchsatz stieg in replizierten Pools im Mittel um 50% und in Erasure-Coded-Pools um 54%, bei 4K-Random-Writes in Erasure-Coded-Pools um bis zu 187%. In replizierten Pools sank die p99-Latenz im Mittel um 52% und die OSD-CPU pro Operation um 36%.
Planbarer Speicher, kein Page Cache
BlueStore liest seine RocksDB-Metadaten über den Page Cache des Kernels, der mit dem Datenbestand wächst: in unseren Erasure-Coded-4K-Tests bis zu 26 GiB pro OSD. croit FlashStore OSD nutzt Direct I/O und lässt den Page Cache in Ruhe. Seine OSDs blieben in jedem Test im Median bei je 2,2 bis 4,8 GiB, und sein Prozessspeicher liegt etwa 13% unter dem von BlueStore. Für die Dimensionierung eines hyperkonvergenten Knotens zählt diese Vorhersagbarkeit womöglich mehr als die Durchsatzzahlen.
| Veränderung gegenüber BlueStore | Repliziert, Size 3 | Erasure Coded 2+2 |
|---|---|---|
| Durchsatz | +50%, bis zu +123% | +54%, bis zu +187% |
| p99-Latenz | −52%, bis zu −94% | −57% |
| OSD-CPU pro Operation | −36%, bis zu −59% | −37% |
48 Clients bei Queue Depth 16, 10 Benchmark-Tests pro Pool-Typ: 64K, 4K und gemischt. Die besten Einzelergebnisse sind 4K-Sequential-Reads im replizierten Pool und 4K-Random-Writes im Erasure-Coded-Pool. croit FlashStore OSD erreichte oder übertraf den Durchsatz von BlueStore in 27 von 28 gemessenen Tests; die Ausnahme, 64K-Random-Reads im replizierten Pool, liegt mit 0,99x gleichauf, und die bisherige Schwachstelle, 4K-Sequential-Writes im Erasure-Coded-Pool, steht jetzt bei 1,54x. Die p99-Latenz war in 25 von 28 niedriger, und alle 20 Tests bei Queue Depth 16 brauchten weniger CPU pro Operation.
Bei Queue Depth 1 stiegen die replizierten IOPS im Mittel über 8 Tests um 9%, um bis zu 18%. Mit 4-MiB-Objekten legten Writes auf 5 OSDs um 14% und auf 10 OSDs um 28% zu, Reads um 1% und 4%; auf 30 OSDs begrenzte das Client-Netzwerk die 4-MiB-Tests. Key/Value-Metadaten (OMAP), wie sie der S3-Bucket-Index und CephFS nutzen, waren auf 30 OSDs im Mittel 22% schneller, mit 19 von 26 Tests auf oder über BlueStore, und Scans 39% schneller; die schwächsten Tests erreichten 0,70x. Dieselben Daten belegen denselben Platz: 18,93 TiB belegte Rohkapazität gegenüber 19,09 TiB mit BlueStore.
Preview-Zahlen, Änderungen vorbehalten: croit FlashStore OSD wird weiter optimiert, neuere Builds messen daher anders, und wir erwarten bessere Werte. Aktualisierte Ergebnisse veröffentlichen wir mit Datum und Testbedingungen.
Benchmark-Report, Factsheet und Presse-Q&A
Der vollständige Benchmark-Report mit jedem Test, das Factsheet und das Presse-Q&A für Redaktionen, als PDF auf Englisch. Die Rohdaten schicken wir Ihnen auf Anfrage per E-Mail.
Passt es zu Ihrem Cluster?
croit FlashStore OSD ist für NVMe-Pools gebaut, in denen die CPU der Engpass ist: virtuelle Maschinen, Datenbanken, KI und HPC. Er beschleunigt den OSD; S3- und CephFS-Arbeit, die auf das Gateway oder den Metadatenserver wartet, bleibt daher wie sie ist, große Reads, die das Netzwerk begrenzt, bleiben gleich, und HDD-Pools bleiben beim klassischen OSD. Als Preview gehört er vorerst auf einen Testcluster.
Neben Ihren klassischen OSDs ausprobieren
- 1
Loslegen
Code und Deployment-Anleitung liegen auf GitHub. Im croit frontier release schalten Sie ihn in der croit-Management-Software ein. croit-Kunden testen begleitet: Sie sagen unseren Engineers, was getestet werden soll, und sie führen es live vor Ihnen aus.
- 2
Laufwerke neu ausrollen
Das On-Disk-Format ist ein anderes, daher gibt es keine Umwandlung im laufenden Betrieb: Laufwerk löschen und als croit FlashStore OSD neu aufsetzen, ein Laufwerk oder ein ganzer Server nach dem anderen, je nach Failure Domains. Mit croit wählen Sie ihn pro Laufwerk.
- 3
Backfill abwarten
Der Cluster befüllt es aus den anderen Kopien, genau wie beim Plattentausch.
- 4
Vergleichen
Klassische und croit FlashStore OSDs bedienen durchgehend denselben Pool, so können Sie beide direkt nebeneinander messen und nach jedem Schritt aufhören.
Teil des croit Rust-Stacks für Ceph
croit baut die leistungskritischen Teile von Ceph in Rust neu, und croit FlashStore OSD ist der erste davon. Die Monitore und Manager von Ceph laufen unverändert weiter. Zur Ankündigung (auf Englisch).
- Heute
Öffentliche Preview
croit FlashStore OSD; librustyrados, ein Drop-in für librados mit nativer Rust-API; librustyrbd, ein Drop-in für librbd für QEMU/KVM; ein RDMA-Transport (RoCEv2) zwischen Clients und OSDs.
- Q4 2026
Nächste Preview
Deduplizierung für replizierte und Erasure-Coded-Pools.
- Q1 2027
Allgemeine Verfügbarkeit und neue Previews
Allgemeine Verfügbarkeit von croit FlashStore OSD, den Rust-Clientbibliotheken, dem RDMA-Transport und der Deduplizierung. Previews eines KVBM/NIXL-Plugins für GPUDirect RDMA in den GPU-Speicher, eines neuen transaktionsbasierten Dateisystems, kompatibel mit libcephfs, samt Rust-Clientbibliothek, und eines RADOS Gateway (S3) in Rust.
- Q2 2027
Allgemeine Verfügbarkeit
Allgemeine Verfügbarkeit des KVBM/NIXL-Plugins, des neuen Dateisystems und des RADOS Gateway in Rust.
Alle Termine sind Richtwerte und können sich je nach Kundenbedarf ändern.
Gebaut von den Ceph-Entwicklern von croit
croit FlashStore OSD wird von Igor Fedotov und Md Mahamudur Rahaman Sajib gebaut, unterstützt von Martin Verges, CEO von croit. Für croit-Kunden ist er ohne Aufpreis im croit frontier release enthalten und wird in der croit-Management-Software eingeschaltet.
FAQs
Noch nicht. croit FlashStore OSD steht als Preview zum Testen und Evaluieren bereit. Für produktive Daten wird es noch nicht empfohlen.
Die allgemeine Verfügbarkeit ist für das erste Quartal 2027 geplant; croit gibt sie frei, wenn die Ceph-Entwickler das System für produktive Daten bereit sehen, nicht zu einem festen Datum.
Nichts. Er ist Open Source unter LGPL-3.0, ohne Lizenzgebühr und ohne kapazitätsbasierte Preise. Für croit-Kunden ist er ohne Aufpreis im croit frontier release enthalten.
Nein. Code und Deployment-Anleitung liegen auf GitHub, und er läuft in bestehenden Ceph-Clustern, mit oder ohne croit. Im croit frontier release schalten Sie ihn in der croit-Management-Software ein und wählen ihn pro Laufwerk.
Nein. Jedes Ergebnis auf dieser Seite wurde mit unveränderten Ceph-Clients auf Standard-librados gemessen. Auch Monitore, Manager und klassische OSDs laufen unverändert weiter.
Nein. Der RDMA-Transport (RoCEv2) ist Teil der Preview und optional. Jede Zahl auf dieser Seite wurde über Kernel-TCP gemessen.
Nein. Nur NVMe-Laufwerke mit Power-Loss-Protection. Bei drehenden Platten ist weiterhin das Laufwerk die Grenze, und dort gehört der klassische OSD hin.
Nichts ändert sich. Die Leistung bleibt, wie sie ist, bis Sie Laufwerke im Pool, der den Workload bedient, als croit FlashStore OSDs neu aufsetzen.
In unserem Benchmark erreichte oder übertraf croit FlashStore OSD den Durchsatz von BlueStore in 27 von 28 Tests. Die Ausnahme, 64K-Random-Reads in einem replizierten Pool, liegt mit 0,99x gleichauf. Die p99-Latenz war in 25 von 28 Tests niedriger, und einige Tests mit Key/Value-Metadaten (OMAP) waren langsamer, der schwächste bei 0,70x.
croit FlashStore OSD steht unter LGPL-3.0, die Rust-Client-Bibliotheken unter MPL-2.0.
