Parte de la pila Rust de croit para Ceph

croit FlashStore OSD:
un OSD de Ceph reconstruido en Rust para NVMe

croit FlashStore OSD está disponible como versión preliminar para pruebas y evaluación. Todavía no se recomienda para datos de producción.
  • +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.

  1. 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.

  2. 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.

  3. 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.

The write path through an OSD. BlueStore: one messenger, threads through shared queues and locks; data goes straight to NVMe with O_DIRECT, metadata through RocksDB and BlueFS. croit FlashStore OSD: msgr2 on every core, each core owns its PGs, keeps metadata in its own B+tree and WAL, and writes data through its own io_uring or SPDK ring.
  • 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%.

croit FlashStore OSD against BlueStore, averages on replicated pools with 30 NVMe OSDs: 50% more throughput, 52% lower p99 latency and 36% less CPU per operation. Preview figures.

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.

  • Clúster: 30 OSD NVMe en cinco servidores AMD EPYC 9455P, 6 núcleos dedicados por OSD, 2 × 200 Gbit/s, TCP del kernel, sin RDMA.
  • Referencia: Ceph 21.2.0 de serie con BlueStore en el mismo clúster.
  • Clientes: sin modificar, fio con el motor rados sobre librados estándar. Todas las cifras se miden en RADOS.
  • Pruebas: pools replicados de tamaño 3 y pools con erasure coding 2+2, 10 pruebas de benchmark cada uno con 48 clientes × QD16, y 8 pruebas replicadas con profundidad de cola 1. Además, objetos de 4 MiB con 5 y 10 OSD y metadatos clave/valor (OMAP) con un OSD y con 30 OSD.
  • Promedios: medias geométricas de la relación por prueba. «Hasta» es la mejor prueba individual.
  • Arranque en frío: cada prueba de croit FlashStore OSD empezó en frío, tras reiniciar el OSD y vaciar la caché de páginas. Las pruebas de referencia de BlueStore no. En todo caso, esto favorece a BlueStore.
  • Ejecuciones: cada prueba se ejecutó una vez por motor.
  • No medido: RGW y CephFS de extremo a extremo.

Cada prueba con sus valores medidos: informe de benchmark (PDF, en inglés). Cómo está construido y cada resultado explicado: lea el artículo (en inglés).

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

Requisitos: Ceph 21.2.0, 20.2.5 o 20.2.4, unidades NVMe con protección ante cortes de energía y formato de sector de 4 KiB (los namespaces de 512 B deben reformatearse), y Linux 5.14 o posterior (RHEL o Alma 9) con io_uring activado.
  1. 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. 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. 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. 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).

  1. 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.

  2. T4 2026

    Próxima versión preliminar

    Deduplicación para pools replicados y con erasure coding.

  3. 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.

  4. 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.

Novedades de croit FlashStore OSD

Nuevas versiones, benchmarks actualizados y la disponibilidad general: le escribimos cuando haya algo nuevo que probar.