Por qué mi clúster Ceph de 3 nodos choca contra un muro a 25GbE

Monté lo que sobre el papel parecía un monstruo: un clúster Proxmox de tres nodos con cuatro OSD NVMe por nodo, todos de gama empresarial, además de NIC y switches de 25Gb separados para el tráfico público y privado de Ceph. Era limpio, estaba sobredimensionado y era rápido.

O al menos eso se suponía, hasta que llegaron los resultados del benchmark: 2756 MB/sec de ancho de banda, 689 IOPS y 23ms de latencia media. De repente, esa reluciente red de 25Gb ya no parecía tan reluciente.

Era un laboratorio para aprender y para jugar, no un sistema en producción. Aun así, cuando te gastas dinero de verdad en unidades NVMe y en red de 25Gb, esperas fuegos artificiales. En cambio me encontré con un techo, y empezaron a llegar los comentarios.

El montaje debería haber volado

Este es el hardware:

• 3 nodos MS-02 Ultra 285HX
• 64GB de DDR5 5600 por nodo
• 4 unidades NVMe Micron 7450 Pro por nodo
• PCIe Gen4
• Red dual de 25Gb (redes pública y de clúster separadas)

Sobre el papel, esto debería volar.

La prueba de escritura se lanzó con:

Coderados bench -p ultra-pool 20 write -t 16 --object_size=4MB --no-cleanup

El resultado fue constante, de entre 2.7 y 2.8 GB/sec. No había picos ni inestabilidad, simplemente estaba… topado.

Una respuesta lo resumió sin rodeos: Estás chocando con el límite de la red. Otro usuario hizo las cuentas en voz alta: casi 3 GBytes/sec son unos 24 Gbits, que es básicamente un 25GbE al máximo.

Duele cuando te lo dice otro, porque tú ya lo sabías de antemano.

“Ceph brilla a gran escala”, y ahí está la pega

Una de las primeras respuestas fue directa al grano:

Es difícil saberlo. Pero yo diría que es por el tamaño tan pequeño del clúster. Ceph brilla a gran escala. 3 nodos es el mínimo absoluto.

La gente no siempre quiere oír eso. Tres nodos es el clúster mínimo viable, el punto en el que Ceph apenas empieza a ser Ceph.

El almacenamiento distribuido no saca músculo hasta que le das espacio para respirar. En cuanto añades más OSD y más nodos y repartes más la carga, empiezas a ver paralelismo de verdad.

Con solo tres nodos estás encajonado. El tráfico de replicación rebota entre las mismas máquinas, la saturación de la red aparece enseguida y los datos no tienen dónde esconderse. Las cifras del benchmark reflejan esa disposición más que cualquier debilidad de Ceph.

El miedo a las IOPS

Lo que de verdad asustó a un comentarista fueron las IOPS, más que el ancho de banda: 689 de media.

Alguien intervino para decir que él saca unas 127 IOPS de sus SSD SAS, así que en comparación esto pinta mejor. Pero es que estas son unidades NVMe Micron 7450 Pro, y en local pueden dar cifras absurdas.

Entonces, ¿por qué el almacenamiento distribuido parece tan… normal?

Porque una escritura aquí va mucho más allá de un único NVMe hablando con una CPU por PCIe. Implica:

• Escritura del cliente
• Salto de red
• Escritura en el OSD primario
• Escritura(s) en los OSD réplica
• Cadena de confirmaciones
• Journaling
• Commit

Cada objeto de 4MB pasa por esa ceremonia de consenso y seguridad. En un clúster replicado no obtienes las cifras de marketing del NVMe. Lo que obtienes es durabilidad, tolerancia a fallos y supervivencia, y eso tiene un precio.

¿Es 25GbE el villano?

Vamos con la red. 25GbE suena rápido, y lo es, hasta que empiezas a empujar varios objetos de 4MB por los flujos de replicación.

A ~2.8 GB/sec, contando la sobrecarga, estás prácticamente saturando un enlace de 25Gb. Ya estás en el límite.

Un comentarista ofreció una sugerencia práctica: LAG o ECMP.

Los flujos individuales no pasarán de 25Gb. Pero puedes mover 50Gb por segundo sin problema.

Ese es el matiz. Un único flujo TCP no va a superar los 25Gb por arte de magia, pero varios flujos por varios puertos cambian el panorama.

ECMP puede repartir el tráfico entre varios enlaces. LAG también puede funcionar, pero en algunos equipos se vuelve raro a partir de dos puertos. De repente estás metido de lleno en arquitectura de redes, además de hacer benchmarks de almacenamiento. Así es como pasa: empiezas con un clúster y acabas rediseñando tu fabric de switching.

La madriguera del tamaño de bloque de 4K

Luego la cosa se puso más interesante. Alguien preguntó si usaba un switch o una red full mesh, y después llegó la sugerencia de reformatear las unidades NVMe a un tamaño de bloque de 4K. Ahí es cuando sabes que estás oficialmente metido hasta el fondo.

Puede que las unidades Micron 7450 estén funcionando en 512e en lugar de 4Kn nativo. Ese desajuste puede costar rendimiento, sobre todo en sistemas de almacenamiento distribuido a los que la alineación les importa muchísimo.

Pero reformatear unidades NVMe no es algo que se haga a la ligera. No basta con pulsar un botón. Tienes que:

• Retirar un OSD
• Esperar al rebalanceo
• Reformatear la unidad
• Volver a añadirla como OSD nuevo
• Esperar al rebalanceo
• Repetir

Lo haces despacio y con cuidado, disco a disco, lo que se parece más a una cirugía que a un ajuste.

En lo emocional, cuando eres nuevo en Ceph, hasta preguntarte si tienes que rehacer todo el clúster abruma. No quieres reventar el laboratorio que acabas de montar, pero así es como se aprende.

Benchmarks frente a realidad

Apareció otra voz sensata:

El mejor benchmark probablemente sea tu carga de trabajo real o un benchmark con fio que se parezca a tu carga de trabajo.

Esa es la parte incómoda de los benchmarks de almacenamiento. rados bench es sintético, limpio y controlado. No se parece al tráfico de VM, a las bases de datos ni a las copias de seguridad.

Puedes perseguir cifras de benchmark eternamente, o puedes preguntarte si esto aguanta lo que de verdad piensas ejecutar. Si tu carga de trabajo no satura los 25Gb, quizá en la vida real no tienes ningún cuello de botella, y este “límite” solo existe en las pruebas de estrés del laboratorio. Esa perspectiva importa.

¿De verdad es tan malo el almacenamiento distribuido?

En un momento de la conversación, alguien vino a preguntar si el almacenamiento distribuido es realmente tan malo.

No es malo. Es caro, en arquitectura además de en dinero. Cambias la velocidad bruta del NVMe local por:

• Redundancia
• Autorreparación
• Distribución de los datos
• Tolerancia a la caída de nodos

Ceph está diseñado para sobrevivir a que un nodo muera a las 2 de la madrugada sin que te enteres. En un clúster como este, eso importa más que cualquier cifra de benchmark de una sola unidad.

La fase de principiante es la mejor

Un comentario se me quedó grabado:

Soy nuevo en todo esto, pero hasta ahora me lo estoy pasando bien aprendiendo.

Esa es la energía correcta, porque esta fase, en la que lo cuestionas todo, es donde se forma la comprensión profunda. ¿Por qué Ceph escala con los nodos? ¿Por qué la replicación multiplica la carga de red? ¿Por qué importa la alineación del tamaño de bloque? ¿Por qué ECMP cambia las características del rendimiento?

No entiendes de verdad los sistemas distribuidos hasta que te decepcionan y empiezas a tirar del hilo.

Entonces, ¿qué está pasando realmente?

Si alejamos el zoom, las cifras quedan así:

• ~2.7 GB/sec de ancho de banda de escritura
• ~24 Gbit/sec de rendimiento efectivo
• Red de 25Gb
• Clúster replicado de 3 nodos
• Objetos de 4MB
• 16 hilos

Es una saturación de red casi de manual. Las unidades no son el cuello de botella, PCIe Gen4 no es el cuello de botella y las CPU (285HX) no van jadeando. El límite es el fabric, y con solo tres nodos el escalado horizontal es limitado.

Añadir más nodos aumenta el rendimiento porque la replicación se reparte más y el ancho de banda agregado crece. Añadir más enlaces rompe el techo de un único enlace. Ajustar el tamaño de bloque y la alineación podría arañar algo más de eficiencia.

Aquí no hay nada que parezca roto; así es la física de un enlace saturado.

Lo que enseñan los laboratorios “exagerados”

Hay algo que te baja los humos al darte cuenta de que tu laboratorio “sobredimensionado” ya está al máximo. Creías que 25Gb era enorme, y resulta que es finito. Creías que el NVMe empresarial significaba cifras de clúster absurdas, pero no anula las matemáticas de la replicación. Creías que tres nodos era una escala seria, y es la línea de salida. Son los sistemas distribuidos descorriendo el telón.

La buena noticia

El clúster es estable, el ancho de banda es constante, la latencia no es caótica y el sistema se comporta de forma predecible. En almacenamiento, la previsibilidad vale oro.

He encontrado un límite, y los límites son donde empiezan las decisiones de arquitectura de verdad. ¿Qué haces?

• ¿Añadir nodos?
• ¿Añadir enlaces de red?
• ¿Pasar a 100Gb?
• ¿Ajustar la configuración de los OSD?
• ¿Cambiar la replicación?
• ¿Aceptar el techo?

Ahora son decisiones de diseño.

Tres nodos, doce unidades NVMe y 25GbE me dieron casi 3 GB/sec de escritura. Ese es el momento en que te das cuenta de que el almacenamiento distribuido responde a tu topología, esperaras lo que esperaras de él. Y, la verdad, eso es lo que lo hace adictivo.