Ceph NVMe over Fabrics 2025: Almacenamiento Distribuido

Introducción: Cuando el cuello de botella se muda a la red

El almacenamiento empresarial ha evolucionado de manera vertiginosa. Durante años, los discos duros mecánicos (HDD) fueron el principal cuello de botella en los centros de datos. Con la llegada de los SSD y, posteriormente, de los NVMe (Non-Volatile Memory Express), la latencia se redujo drásticamente, pero surgió un nuevo problema: la red. La infraestructura tradicional basada en iSCSI o Fibre Channel no podía aprovechar al máximo la velocidad de los dispositivos NVMe, que operan con colas de comandos masivamente paralelas y una latencia de microsegundos.

Aquí es donde entra en juego la combinación de Ceph como sistema de almacenamiento distribuido y NVMe over Fabrics (NVMe-oF) como protocolo de transporte. Juntos, forman una arquitectura capaz de ofrecer alto rendimiento, escalabilidad horizontal y redundancia a nivel de bloque, objeto y archivo, todo sobre hardware commodity.

En este artículo, desglosaremos cómo implementar y optimizar esta configuración, qué consideraciones técnicas debes tener en cuenta y por qué es la apuesta ganadora para cargas de trabajo críticas como bases de datos, virtualización o inteligencia artificial.

¿Por qué Ceph y NVMe over Fabrics?

Para entender la sinergia, primero debemos analizar cada componente por separado.

Ceph: El ADN del almacenamiento distribuido

Ceph no es un simple sistema de archivos; es una plataforma unificada que ofrece almacenamiento en tres modalidades:

RADOS Block Device (RBD): para discos en bloque (máquinas virtuales, bases de datos).
CephFS: sistema de archivos POSIX, ideal para aplicaciones tradicionales.
RADOS Gateway (RGW): compatible con Amazon S3 y Swift, perfecto para objetos.

Su magia reside en el CRUSH algorithm, que distribuye los datos de forma inteligente entre los nodos sin depender de un metadata server central. Esto permite escalar añadiendo más servidores (OSDs) mientras se mantiene la redundancia mediante replicación o erasure coding.

NVMe over Fabrics: El protocolo que elimina la latencia

NVMe-oF extiende el protocolo NVMe más allá del bus PCIe, permitiendo que un host acceda a un dispositivo NVMe remoto a través de una red de alta velocidad (RoCE, iWARP, Fibre Channel o TCP). La clave está en que mantiene la misma semántica de colas y comandos que NVMe local, minimizando la sobrecarga de software.

[INFO] Existen dos variantes principales: NVMe-oF sobre Fibre Channel (FC-NVMe) y sobre Ethernet (RoCE o TCP). Para entornos Ceph, la opción más flexible suele ser RoCE v2 o TCP, ya que no requiere hardware FC dedicado.

La combinación Ceph + NVMe-oF permite que los clientes (por ejemplo, un hipervisor KVM) accedan a discos RBD con una latencia cercana a la de un disco local, pero con toda la resiliencia distribuida.

Arquitectura de referencia: Nodos OSD con NVMe y redes de 25/100 Gbps

Para que esta configuración tenga sentido, necesitas servidores con las siguientes características:

Nodos de almacenamiento (OSD): equipados con SSDs NVMe (Intel Optane, Samsung PM9A3, etc.). Cada OSD debe tener al menos un dispositivo NVMe dedicado.
Red de backend (cluster network): conmutadores de 25 Gbps o 100 Gbps, preferiblemente con soporte para RDMA (RoCE v2). Esta red transporta el tráfico de replicación y recuperación entre OSDs.
Red de frontend (public network): también de alta velocidad, por donde los clientes acceden a los discos RBD vía NVMe-oF.
CPU y RAM: suficientes para manejar el cifrado, compresión (opcional) y el procesamiento del protocolo NVMe-oF. Recomendamos al menos 16 núcleos y 128 GB de RAM por nodo.

Ejemplo de configuración de red en /etc/ceph/ceph.conf:

[global]
    public network = 10.1.0.0/24
    cluster network = 10.2.0.0/24
    ms type = async+rdma   # Para habilitar RDMA
    ms bind ipv6 = false

Instalación y configuración paso a paso

1. Preparación del hardware y SO

Asegúrate de que tu kernel Linux sea 5.x o superior (mejor si es 6.x) y que tengas instalados los drivers de tu controladora NVMe y de la NIC (Mellanox, Intel, Broadcom). Activa el módulo nvme-rdma o nvme-tcp según tu elección:

# Para RDMA (RoCE)
modprobe nvme-rdma
# Para TCP
modprobe nvme-tcp

2. Despliegue de Ceph (versión Reef o Quincy)

Usa cephadm o ceph-ansible. En este ejemplo, con cephadm:

cephadm bootstrap --mon-ip 10.1.0.10
ceph orch apply osd --all-available-devices

Luego, etiqueta los dispositivos NVMe como nvme para que Ceph los reconozca:

ceph osd crush class create nvme
ceph osd crush set-device-class nvme /dev/nvme0n1

3. Configuración del target NVMe-oF

Ceph incluye el módulo nvmeof (desde Quincy) que permite exponer imágenes RBD como targets NVMe-oF. Debes instalar el paquete ceph-nvmeof en un nodo gateway (o en los propios OSDs, aunque no es recomendable por seguridad).

ceph nvme-gateway add --name "mygateway" --pool rbd --image test-image --size 10G

Esto crea un target NVMe-oF accesible por los clientes. Puedes verificar con nvme list en el cliente.

4. Conexión desde el cliente

En el servidor cliente (por ejemplo, un hipervisor Proxmox o un servidor de bases de datos):

# Para conexión TCP
nvme connect -t tcp -n "nqn.2024-01.com.ceph:mygateway" -a 10.1.0.10 -s 4420

# Para conexión RDMA
nvme connect -t rdma -n "nqn.2024-01.com.ceph:mygateway" -a 10.1.0.10 -s 4420

Una vez conectado, aparecerá un dispositivo /dev/nvme0n1 que se comporta como un disco local. Puedes formatearlo con XFS o usarlo directamente como disco para QEMU/KVM.

Optimización para alto rendimiento

Ajustes en Ceph

Tamaño de PG: Para pools con NVMe, usa un número de PGs mayor (512 o 1024) para distribuir mejor la carga.
Replicación vs. Erasure Coding: Para latencia ultra baja, prefiere replicación (size=3). El erasure coding es más eficiente en espacio pero añade latencia por el cómputo.
Caching: Desactiva el cache de página en los OSDs (opcional) si usas dispositivos NVMe con power-loss protection.

ceph osd pool set rbd size 3
ceph osd pool set rbd pg_num 1024

Ajustes en la red

Jumbo frames: Activa MTU 9000 en todas las interfaces.
Flow control: Desactiva el pause de flujo en los switches y usa ECN (Explicit Congestion Notification) para RDMA.
CPU pinning: Aísla núcleos de CPU para las interrupciones de la NIC y de NVMe.

[TIP] Usa perf y iostat para identificar si el cuello de botella está en la CPU, la red o el disco. En configuraciones bien afinadas, la latencia debe estar por debajo de 200 microsegundos.

Redundancia y tolerancia a fallos

La gran ventaja de Ceph es que la redundancia está en su núcleo. Si un OSD falla, el CRUSH algorithm redistribuye automáticamente los datos a otros OSDs. Con NVMe-oF, la redundancia se traslada también a la capa de red:

Múltiples gateways: Puedes desplegar varios nodos ceph-nvmeof y configurar multipath en el cliente para balancear carga y tolerar fallos.
Enlaces redundantes: Cada OSD debe tener al menos dos interfaces de red (una para cluster, otra para public). Si falla una, el tráfico se redirige.

Escenario de fallo simulado

Desconecta un OSD. Ceph marca los PGs como degraded.
El CRUSH algorithm inicia la recuperación automática.
El cliente NVMe-oF no nota nada, ya que el target sigue activo en otro gateway.
En pocos segundos, el cluster se recupera sin intervención manual.

[WARNING] La recuperación consume ancho de banda de red y CPU. Ajusta los parámetros osd recovery max active y osd recovery op priority para evitar impactar en la producción.

Casos de uso reales

Virtualización con Proxmox o OpenStack

Imagina un clúster de 10 nodos de cómputo, cada uno con 2 discos NVMe de 2 TB. Ceph los agrupa en un pool RBD de 20 TB útiles (con replicación 3). Los hipervisores se conectan vía NVMe-oF TCP a los discos de las máquinas virtuales. Resultado: una VM puede migrar en caliente entre nodos en menos de 2 segundos, con latencias de E/S de 100 µs.

Bases de datos PostgreSQL o MySQL

Las bases de datos son extremadamente sensibles a la latencia. Con NVMe-oF, una base de datos que corre en un servidor remoto puede tener un rendimiento comparable a un disco local. Ceph aporta la redundancia: si un OSD falla, la base de datos no se corrompe.

Desafíos y consideraciones

Costo: Los switches 100 Gbps y los NVMe empresariales no son baratos. Sin embargo, el TCO puede ser menor que soluciones propietarias como NetApp o Pure Storage.
Complejidad: La configuración de RDMA requiere conocimientos de redes avanzados. Para equipos menos experimentados, la opción NVMe-oF TCP es más sencilla.
Overhead de Ceph: Aunque Ceph ha mejorado mucho, sigue teniendo una sobrecarga de CPU mayor que un sistema de archivos local. Para cargas de trabajo 100% aleatorias, considera usar SPDK en lugar de kernel NVMe.

[INFO] Existen proyectos como Ceph Crimson y SeaStore que prometen reducir drásticamente el overhead de Ceph en entornos NVMe. Estate atento a las versiones futuras.

Conclusión: El futuro es distribuido y rápido

La combinación de Ceph y NVMe over Fabrics no es solo una moda; es la respuesta a las demandas de las aplicaciones modernas que necesitan alto rendimiento, escalabilidad y redundancia sin ataduras a hardware propietario. Con la madurez de Ceph (versión Reef y posteriores) y el soporte nativo de NVMe-oF, cualquier administrador de sistemas puede construir un clúster de almacenamiento que rivalice con soluciones empresariales de cinco cifras.

Si estás planeando una migración o un nuevo despliegue, te recomiendo empezar con un laboratorio pequeño (3 nodos, 25 Gbps, NVMe consumer) y escalar gradualmente. La curva de aprendizaje es pronunciada, pero los beneficios en términos de flexibilidad y rendimiento son inmensos.

¿Ya has probado Ceph con NVMe-oF? Comparte tu experiencia en los comentarios o síguenos para más tutoriales técnicos.