Fait partie de la pile Rust de croit pour Ceph
croit FlashStore OSD :
un OSD Ceph réécrit en Rust pour NVMe
- +50%* Débit Pools répliqués, moyenne sur 10 tests, 30 OSD NVMe, TCP noyau
- −52%* Latence p99 Pools répliqués, 48 clients × QD16, 30 OSD NVMe, TCP noyau
- −36%* CPU par opération Pools répliqués, moins dans les 20 tests, 30 OSD NVMe, TCP noyau
*D'après le benchmark du 9 novembre 2026, build 422be26.
Sur la flash, Ceph attend le CPU
Un disque NVMe de datacenter fournit plusieurs centaines de milliers d'IOPS 4k. L'OSD classique a été conçu quand le disque était la limite. Aujourd'hui, le plafond est le temps CPU par opération, et un disque plus rapide n'aide plus.
- 01
Conçu pour les charges actives
VM migrées depuis VMware, bases de données, pipelines ML qui alimentent les GPU, scratch HPC. Ici, la bande passante et les IOPS par cœur décident si Ceph convient.
- 02
Mêmes disques, serveurs et réseau
Le gain vient du chemin de données de l'OSD. Sur les nœuds hyperconvergés, le CPU et la mémoire libérés reviennent aux VM ; sur les nœuds de stockage, c'est de la marge, ou moins de cœurs au prochain achat.
- 03
Open source, avec ou sans croit
croit FlashStore OSD est sous licence LGPL-3.0, les bibliothèques client Rust sous MPL-2.0. Il n'y a ni frais de licence ni tarif à la capacité. croit FlashStore OSD fonctionne dans les clusters Ceph existants, avec ou sans croit.
Le même Ceph à l'extérieur, un nouveau chemin de données à l'intérieur
Les deux côtés montrent le chemin d'une écriture à travers un OSD. BlueStore fait passer chaque opération par des files et des verrous partagés ; ses données vont directement sur le disque, ses métadonnées passent par RocksDB et BlueFS. croit FlashStore OSD donne à chaque cœur CPU sa propre voie, du réseau jusqu'au disque, sans RocksDB dans le chemin des métadonnées.
1 · msgr2 · cephx
Ordinaire vu de l'extérieur
Les moniteurs, les managers, les clients non modifiés et les OSD classiques lui parlent comme d'habitude, sous la même OSDMap et les mêmes règles CRUSH. Un même pool peut contenir les deux types d'OSD. À l'intérieur, chaque cœur gère ses propres connexions et transmet chaque opération au cœur propriétaire de sa PG via des anneaux sans verrou.
2 · Threads
Un cœur par placement group
Chaque PG appartient à exactement un cœur épinglé et n'attend donc jamais de verrou. Le cœur 0 assure en plus le travail de contrôle : moniteurs, managers, heartbeats et maps.
3 · Moteur de stockage
Un arbre B+ et un journal par cœur
Chaque cœur possède une partie du disque avec son propre journal d'écriture anticipée, son arbre B+ copy-on-write, son allocateur et sa file de périphérique. L'arbre B+ ne contient que des métadonnées ; les données vont dans de nouvelles extensions de 4K, ne sont jamais réécrites sur place et sont écrites en parallèle de leur entrée de journal. Par défaut, il n'y a ni RocksDB, ni BlueFS, ni compaction.
4 · Chemin d'E/S
Aucune copie dans le stockage
Une écriture est copiée une seule fois, à la réception réseau, et avec RDMA même pas. Le stockage l'écrit par référence depuis le tampon de réception, via l'anneau io_uring ou SPDK propre au cœur. Elle n'est acquittée qu'une fois sur le support partout.
« BlueStore fait tourner un très grand nombre de clusters en production, et il doit rester stable et compatible pour chacun d'eux. croit FlashStore OSD nous a donné la liberté de concevoir de zéro un moteur de stockage pour NVMe, à côté de BlueStore plutôt qu'à sa place. Ce que nous apprenons, nous le proposerons au projet Ceph. »
Igor Fedotov, ingénieur Ceph chez croit et membre du Ceph Steering Committee
Ce que nous avons mesuré
Le même matériel, un moteur de stockage plus rapide
Nous avons lancé les mêmes tests de benchmark sur le même cluster de 30 OSD NVMe, une fois avec BlueStore de Ceph 21.2.0 d'origine et une fois avec croit FlashStore OSD, sur TCP noyau avec des clients Ceph non modifiés. Le débit a augmenté en moyenne de 50 % dans les pools répliqués et de 54 % dans les pools à code d'effacement, jusqu'à 187 % en écritures aléatoires 4K sur les pools à code d'effacement. Dans les pools répliqués, la latence p99 a baissé en moyenne de 52 % et le CPU de l'OSD par opération de 36 %.
Une mémoire prévisible, sans cache de pages
BlueStore lit ses métadonnées RocksDB via le cache de pages du noyau, qui grandit avec le volume de données : jusqu'à 26 GiB par OSD dans nos tests 4K à code d'effacement. croit FlashStore OSD utilise les E/S directes et laisse le cache de pages tranquille. Ses OSD sont restés à une médiane de 2,2 à 4,8 GiB chacun dans tous les tests, et sa mémoire de processus est inférieure d'environ 13 % à celle de BlueStore. Pour dimensionner un nœud hyperconvergé, cette prévisibilité peut compter davantage que les chiffres de débit.
| Écart par rapport à BlueStore | Répliqué, taille 3 | Code d'effacement 2+2 |
|---|---|---|
| Débit | +50%, jusqu'à +123% | +54%, jusqu'à +187% |
| Latence p99 | −52%, jusqu'à −94% | −57% |
| CPU de l'OSD par opération | −36%, jusqu'à −59% | −37% |
48 clients à une profondeur de file de 16, 10 tests de benchmark par type de pool : 64K, 4K et mixtes. Les meilleurs résultats individuels sont les lectures séquentielles 4K dans le pool répliqué et les écritures aléatoires 4K dans le pool à code d'effacement. croit FlashStore OSD a atteint ou dépassé le débit de BlueStore dans 27 des 28 tests mesurés ; l'exception, les lectures aléatoires 64K dans le pool répliqué, est à égalité à 0,99x, et l'ancien point faible, les écritures séquentielles 4K dans le pool à code d'effacement, est désormais à 1,54x. La latence p99 était plus basse dans 25 des 28, et les 20 tests à une profondeur de file de 16 ont tous consommé moins de CPU par opération.
À une profondeur de file de 1, les IOPS répliquées ont augmenté de 9 % en moyenne sur 8 tests, jusqu'à 18 %. Avec des objets de 4 MiB, les écritures ont gagné 14 % sur 5 OSD et 28 % sur 10 OSD, les lectures 1 % et 4 % ; sur 30 OSD, les tests 4 MiB étaient limités par le réseau client. Les métadonnées clé/valeur (OMAP), utilisées par l'index des buckets S3 et par CephFS, ont été 22 % plus rapides en moyenne sur 30 OSD, avec 19 des 26 tests au niveau de BlueStore ou au-dessus, et les parcours 39 % plus rapides ; les tests les plus faibles ont atteint 0,70x. Les mêmes données occupent la même place : 18,93 TiB bruts utilisés contre 19,09 TiB avec BlueStore.
Chiffres de préversion, susceptibles d'évoluer : croit FlashStore OSD est encore en cours d'optimisation, les builds plus récents donneront donc d'autres mesures, et nous nous attendons à ce qu'elles s'améliorent. Nous publierons les résultats mis à jour avec leur date et leurs conditions de test.
Rapport de benchmark, fiche technique et Q&R presse
Le rapport de benchmark complet avec chaque test, la fiche technique et les Q&R pour la presse, en PDF et en anglais. Les données brutes vous sont envoyées par e-mail, sur demande.
Est-ce adapté à votre cluster ?
croit FlashStore OSD est conçu pour les pools NVMe où le CPU est le goulot d'étranglement : machines virtuelles, bases de données, IA et HPC. Il accélère l'OSD ; le travail S3 et CephFS qui attend la passerelle ou le serveur de métadonnées reste donc tel quel, les grandes lectures limitées par le réseau restent au même niveau, et les pools HDD restent sur l'OSD classique. En tant que préversion, il a pour l'instant sa place sur un cluster de test.
Essayez-le à côté de vos OSD classiques
- 1
L'obtenir
Le code et le guide de déploiement sont sur GitHub. Dans la croit frontier release, vous l'activez dans le logiciel de gestion croit. Les clients croit bénéficient de tests accompagnés : vous dites à nos ingénieurs quoi tester, et ils l'exécutent en direct devant vous.
- 2
Redéployer des disques
Le format sur disque est différent, il n'y a donc pas de conversion sur place : effacez un disque et remettez-le en service comme croit FlashStore OSD, un disque ou un serveur entier à la fois, selon vos domaines de défaillance. Avec croit, vous le choisissez par disque.
- 3
Laisser le backfill se faire
Le cluster le remplit à partir des autres copies, exactement comme lors d'un remplacement de disque.
- 4
Comparer
Les OSD classiques et les croit FlashStore OSD servent le même pool tout du long, vous pouvez donc mesurer les deux côte à côte et vous arrêter après n'importe quelle étape.
Fait partie de la pile Rust de croit pour Ceph
croit réécrit en Rust les parties de Ceph critiques pour les performances, et croit FlashStore OSD en est la première. Les moniteurs et les managers de Ceph continuent de fonctionner sans changement. Lire l'annonce.
- Aujourd'hui
Préversion publique
croit FlashStore OSD ; librustyrados, un librados à substituer directement, avec une API Rust native ; librustyrbd, un librbd à substituer directement pour QEMU/KVM ; un transport RDMA (RoCEv2) entre clients et OSD.
- T4 2026
Prochaine préversion
La déduplication pour les pools répliqués et à code d'effacement.
- T1 2027
Disponibilité générale et nouvelles préversions
Disponibilité générale de croit FlashStore OSD, des bibliothèques clientes Rust, du transport RDMA et de la déduplication. Préversions d'un plugin KVBM/NIXL pour GPUDirect RDMA vers la mémoire GPU, d'un nouveau système de fichiers transactionnel compatible avec libcephfs avec sa bibliothèque cliente Rust, et d'une RADOS Gateway (S3) en Rust.
- T2 2027
Disponibilité générale
Disponibilité générale du plugin KVBM/NIXL, du nouveau système de fichiers et de la RADOS Gateway en Rust.
Toutes les dates sont indicatives et peuvent changer selon la demande des clients croit.
Conçu par les ingénieurs Ceph de croit
croit FlashStore OSD est développé par Igor Fedotov et Md Mahamudur Rahaman Sajib, avec le soutien de Martin Verges, CEO de croit. Pour les clients croit, il est inclus sans surcoût dans la croit frontier release et s'active dans le logiciel de gestion croit.
FAQ
Pas encore. croit FlashStore OSD est disponible en préversion pour les tests et l'évaluation. Il n'est pas encore recommandé pour des données de production.
La disponibilité générale est prévue pour le premier trimestre 2027. croit le publiera lorsque ses ingénieurs Ceph seront convaincus qu'il est prêt pour des données de production, et non à une date fixe.
Rien. Il est open source sous LGPL-3.0, sans frais de licence ni tarif à la capacité. Pour les clients croit, il est inclus sans surcoût dans la croit frontier release.
Non. Le code et le guide de déploiement sont sur GitHub, et il fonctionne dans les clusters Ceph existants avec ou sans croit. Dans la croit frontier release, vous l'activez dans le logiciel de gestion croit et le choisissez par disque.
Non. Chaque résultat de cette page a été mesuré avec des clients Ceph non modifiés sur librados standard. Les moniteurs, les managers et les OSD classiques continuent eux aussi de fonctionner sans changement.
Non. Le transport RDMA (RoCEv2) fait partie de la préversion et reste optionnel. Chaque chiffre de cette page a été mesuré sur TCP noyau.
Non. Uniquement des disques NVMe protégés contre les coupures de courant. Sur disques rotatifs, le disque reste la limite, et c'est là que l'OSD classique a sa place.
Rien ne change. Les performances restent les mêmes jusqu'à ce que vous redéployiez des disques en croit FlashStore OSD dans le pool qui sert la charge.
Dans notre benchmark, croit FlashStore OSD a atteint ou dépassé le débit de BlueStore dans 27 des 28 tests. L'exception, les lectures aléatoires 64K dans un pool répliqué, est à égalité à 0,99x. La latence p99 était plus basse dans 25 des 28 tests, et certains tests de métadonnées clé/valeur (OMAP) étaient plus lents, le plus faible à 0,70x.
croit FlashStore OSD est publié sous LGPL-3.0, les bibliothèques clientes Rust sous MPL-2.0.
