Parte de la pila Rust de croit para Ceph
croit FlashStore OSD:
un OSD de Ceph reconstruido en Rust para NVMe
- +50%* Rendimiento Pools replicados, media de 10 pruebas, 30 OSD NVMe, TCP del kernel
- −52%* Latencia p99 Pools replicados, 48 clientes × QD16, 30 OSD NVMe, TCP del kernel
- −36%* CPU por operación Pools replicados, menos en las 20 pruebas, 30 OSD NVMe, TCP del kernel
*Según el benchmark del 9 de noviembre de 2026, build 422be26.
En flash, Ceph espera a la CPU
Una unidad NVMe de centro de datos atiende varios cientos de miles de IOPS de 4k. El OSD clásico se diseñó cuando la unidad era el límite. Hoy el techo es el tiempo de CPU por operación, y una unidad más rápida ya no ayuda.
- 01
Pensado para cargas de trabajo activas
Máquinas virtuales que salen de VMware, bases de datos, pipelines de ML que mantienen las GPU alimentadas, scratch de HPC. Aquí, el ancho de banda y las IOPS por núcleo deciden si Ceph encaja.
- 02
Mismas unidades, servidores y red
La mejora viene de la ruta de datos del OSD. En nodos hiperconvergentes, la CPU y la memoria liberadas vuelven a las VM; en nodos de almacenamiento son margen, o menos núcleos en la próxima compra.
- 03
Código abierto, con o sin croit
croit FlashStore OSD tiene licencia LGPL-3.0; las bibliotecas cliente en Rust, MPL-2.0. No hay cuota de licencia ni precios por capacidad. croit FlashStore OSD funciona en clústeres de Ceph existentes con o sin croit.
El mismo Ceph por fuera, una nueva ruta de datos por dentro
Ambos lados muestran el camino de una escritura a través de un OSD. BlueStore hace pasar cada operación por colas y bloqueos compartidos; sus datos van directamente a la unidad y sus metadatos, por RocksDB y BlueFS. croit FlashStore OSD da a cada núcleo de CPU su propio carril, desde la red hasta la unidad, sin RocksDB en la ruta de metadatos.
1 · msgr2 · cephx
Normal por fuera
Los monitores, los managers, los clientes sin modificar y los OSD clásicos se comunican con él como siempre, bajo el mismo OSDMap y las mismas reglas CRUSH. Un pool puede contener ambos tipos de OSD. Por dentro, cada núcleo gestiona sus propias conexiones y pasa cada operación al núcleo dueño de su PG mediante anillos sin bloqueos.
2 · Hilos
Un núcleo por placement group
Cada PG pertenece a un único núcleo fijo, así que nunca espera un bloqueo. El núcleo 0 se encarga además del trabajo de control: monitores, managers, heartbeats y mapas.
3 · Motor de almacenamiento
Un árbol B+ y un registro por núcleo
Cada núcleo posee una parte de la unidad con su propio registro de escritura anticipada, árbol B+ de copia en escritura, asignador y cola de dispositivo. El árbol B+ solo guarda metadatos; los datos van a extents nuevos de 4K, nunca se sobrescriben en su sitio y se escriben en paralelo con su entrada de registro. Por defecto no hay RocksDB, ni BlueFS, ni compactación.
4 · Ruta de E/S
Sin copias en el almacén
Una escritura se copia una vez, al recibirse por la red, y con RDMA ni siquiera eso. El almacén la escribe por referencia desde el búfer de recepción, a través del anillo io_uring o SPDK propio del núcleo. Solo se confirma cuando está en el medio en todas partes.
«BlueStore funciona en un número muy grande de clústeres en producción, y tiene que seguir siendo estable y compatible para todos ellos. croit FlashStore OSD nos dio la libertad de diseñar desde cero un motor de almacenamiento para NVMe, junto a BlueStore en lugar de sustituirlo. Lo que aprendamos lo ofreceremos al proyecto Ceph.»
Igor Fedotov, ingeniero de Ceph en croit y miembro del Ceph Steering Committee
Lo que medimos
El mismo hardware, un motor de almacenamiento más rápido
Ejecutamos las mismas pruebas de benchmark en el mismo clúster de 30 OSD NVMe, una vez con BlueStore de Ceph 21.2.0 de serie y otra con croit FlashStore OSD, sobre TCP del kernel con clientes de Ceph sin modificar. El rendimiento subió de media un 50% en pools replicados y un 54% en pools con erasure coding, hasta un 187% en escrituras aleatorias de 4K en pools con erasure coding. En pools replicados, la latencia p99 bajó de media un 52% y la CPU del OSD por operación un 36%.
Memoria previsible, sin caché de páginas
BlueStore lee los metadatos de su RocksDB a través de la caché de páginas del kernel, que crece con el conjunto de datos: hasta 26 GiB por OSD en nuestras pruebas de 4K con erasure coding. croit FlashStore OSD usa E/S directa y deja la caché de páginas en paz. Sus OSD se mantuvieron en una mediana de 2.2 a 4.8 GiB cada uno en todas las pruebas, y su memoria de proceso está un 13% por debajo de la de BlueStore. Para dimensionar un nodo hiperconvergente, esa previsibilidad puede importar más que las cifras de rendimiento.
| Cambio frente a BlueStore | Replicado, tamaño 3 | Erasure coding 2+2 |
|---|---|---|
| Rendimiento | +50%, hasta +123% | +54%, hasta +187% |
| Latencia p99 | −52%, hasta −94% | −57% |
| CPU del OSD por operación | −36%, hasta −59% | −37% |
48 clientes con profundidad de cola 16, 10 pruebas de benchmark por tipo de pool: 64K, 4K y mixtas. Los mejores resultados individuales son las lecturas secuenciales de 4K en el pool replicado y las escrituras aleatorias de 4K en el pool con erasure coding. croit FlashStore OSD alcanzó o superó el rendimiento de BlueStore en 27 de 28 pruebas medidas; la excepción, las lecturas aleatorias de 64K en el pool replicado, queda a la par con 0.99x, y el antiguo punto débil, las escrituras secuenciales de 4K en el pool con erasure coding, está ahora en 1.54x. La latencia p99 fue menor en 25 de 28, y las 20 pruebas con profundidad de cola 16 usaron menos CPU por operación.
Con profundidad de cola 1, las IOPS replicadas subieron de media un 9% en 8 pruebas, hasta un 18%. Con objetos de 4 MiB, las escrituras ganaron un 14% con 5 OSD y un 28% con 10 OSD, las lecturas un 1% y un 4%; con 30 OSD, las pruebas de 4 MiB estuvieron limitadas por la red de los clientes. Los metadatos clave/valor (OMAP), como los que usan el índice de buckets de S3 y CephFS, fueron de media un 22% más rápidos con 30 OSD, con 19 de 26 pruebas iguales o por encima de BlueStore, y los escaneos un 39% más rápidos; las pruebas más bajas llegaron a 0.70x. Los mismos datos ocupan el mismo espacio: 18.93 TiB brutos usados frente a 19.09 TiB con BlueStore.
Cifras de versión preliminar, sujetas a cambios: croit FlashStore OSD se sigue optimizando, así que las versiones más recientes darán otras mediciones, y esperamos que mejoren. Publicaremos los resultados actualizados con su fecha y sus condiciones de prueba.
Informe de benchmark, ficha técnica y preguntas para prensa
El informe de benchmark completo con cada prueba, la ficha técnica y las preguntas y respuestas para la prensa, en PDF y en inglés. Los datos en bruto se los enviamos por correo, bajo petición.
¿Es adecuado para su clúster?
croit FlashStore OSD está pensado para pools NVMe en los que la CPU es el cuello de botella: máquinas virtuales, bases de datos, IA y HPC. Acelera el OSD, así que el trabajo de S3 y CephFS que espera a la pasarela o al servidor de metadatos sigue igual, las lecturas grandes limitadas por la red quedan igual y los pools HDD siguen con el OSD clásico. Como versión preliminar, por ahora su lugar es un clúster de pruebas.
Pruébelo junto a sus OSD clásicos
- 1
Obténgalo
El código y la guía de despliegue están en GitHub. En la croit frontier release se activa en el software de gestión de croit. Los clientes de croit cuentan con pruebas supervisadas: usted indica a nuestros ingenieros qué probar y ellos lo ejecutan en directo delante de usted.
- 2
Vuelva a desplegar unidades
El formato en disco es distinto, así que no hay conversión en el sitio: borre una unidad y vuelva a ponerla en marcha como croit FlashStore OSD, una unidad o un servidor completo cada vez, según sus dominios de fallo. Con croit lo elige por unidad.
- 3
Deje que se rellene
El clúster la vuelve a llenar a partir de las demás copias, exactamente como cuando se sustituye un disco.
- 4
Compare
Los OSD clásicos y los croit FlashStore OSD sirven el mismo pool en todo momento, así que puede medir ambos uno al lado del otro y detenerse después de cualquier paso.
Parte de la pila Rust de croit para Ceph
croit está reconstruyendo en Rust las partes de Ceph críticas para el rendimiento, y croit FlashStore OSD es la primera. Los monitores y managers de Ceph siguen funcionando sin cambios. Lea el anuncio (en inglés).
- Hoy
Versión preliminar pública
croit FlashStore OSD; librustyrados, un sustituto directo de librados con una API nativa en Rust; librustyrbd, un sustituto directo de librbd para QEMU/KVM; un transporte RDMA (RoCEv2) entre clientes y OSD.
- T4 2026
Próxima versión preliminar
Deduplicación para pools replicados y con erasure coding.
- T1 2027
Disponibilidad general y nuevas versiones preliminares
Disponibilidad general de croit FlashStore OSD, las bibliotecas cliente en Rust, el transporte RDMA y la deduplicación. Versiones preliminares de un plugin KVBM/NIXL para GPUDirect RDMA hacia la memoria de la GPU, un nuevo sistema de archivos basado en transacciones y compatible con libcephfs con su biblioteca cliente en Rust, y un RADOS Gateway (S3) en Rust.
- T2 2027
Disponibilidad general
Disponibilidad general del plugin KVBM/NIXL, el nuevo sistema de archivos y el RADOS Gateway en Rust.
Todas las fechas son orientativas y pueden cambiar en función de la demanda de los clientes de croit.
Creado por los ingenieros de Ceph de croit
croit FlashStore OSD lo crean Igor Fedotov y Md Mahamudur Rahaman Sajib, con el apoyo de Martin Verges, CEO de croit. Para los clientes de croit está incluido sin coste adicional en la croit frontier release y se activa en el software de gestión de croit.
Preguntas frecuentes
Todavía no. croit FlashStore OSD está disponible como versión preliminar para pruebas y evaluación. Todavía no se recomienda para datos de producción.
La disponibilidad general está prevista para el primer trimestre de 2027. croit lo publicará cuando sus ingenieros de Ceph estén seguros de que está listo para datos de producción, no en una fecha fija.
Nada. Es de código abierto bajo LGPL-3.0, sin cuota de licencia ni precios por capacidad. Para los clientes de croit está incluido sin coste adicional en la croit frontier release.
No. El código y la guía de despliegue están en GitHub, y funciona en clústeres de Ceph existentes con o sin croit. En la croit frontier release se activa en el software de gestión de croit y se elige por unidad.
No. Todos los resultados de esta página se midieron con clientes de Ceph sin modificar sobre librados estándar. Los monitores, los managers y los OSD clásicos también siguen funcionando sin cambios.
No. El transporte RDMA (RoCEv2) forma parte de la versión preliminar y es opcional. Todas las cifras de esta página se midieron sobre TCP del kernel.
No. Solo con unidades NVMe con protección ante cortes de energía. En discos giratorios la unidad sigue siendo el límite, y ahí es donde corresponde el OSD clásico.
Nada cambia. El rendimiento sigue igual hasta que redespliegue discos como croit FlashStore OSD en el pool que sirve la carga.
En nuestro benchmark, croit FlashStore OSD alcanzó o superó el rendimiento de BlueStore en 27 de 28 pruebas. La excepción, las lecturas aleatorias de 64K en un pool replicado, queda a la par con 0.99x. La latencia p99 fue menor en 25 de 28 pruebas, y algunas pruebas de metadatos clave/valor (OMAP) fueron más lentas, la más baja con 0.70x.
croit FlashStore OSD se publica bajo LGPL-3.0, y las bibliotecas cliente en Rust bajo MPL-2.0.
