Ceph bajo la lupa: pruebas IO500 revelan ajustes clave para maximizar el rendimiento

En un sector donde cada milisegundo de latencia y cada megabyte por segundo cuentan, un reciente análisis de rendimiento de Ceph —basado en pruebas exhaustivas con el benchmark IO500— ha arrojado conclusiones reveladoras para administradores de sistemas y arquitectos de almacenamiento distribuido. El estudio, realizado en un entorno controlado con hardware empresarial, ha permitido identificar qué configuraciones y optimizaciones aportan mejoras tangibles, cuáles son irrelevantes e incluso qué cambios pueden resultar contraproducentes.

Más allá de las métricas, este trabajo subraya la importancia de validar cualquier ajuste en un laboratorio antes de trasladarlo a producción, evitando caer en la tentación de aplicar “recetas” genéricas sin comprender el impacto real sobre la carga de trabajo específica.

Contexto: Ceph y el benchmark IO500

Ceph se ha consolidado como una de las soluciones de almacenamiento distribuido más versátiles y robustas del mercado. Su capacidad para ofrecer almacenamiento en bloque, de objetos y en modo de sistema de archivos (CephFS) lo convierte en una opción recurrente para entornos de alto rendimiento, desde centros de datos corporativos hasta supercomputación.

Para evaluar su rendimiento, el estudio empleó IO500, un benchmark reconocido en la comunidad HPC (High-Performance Computing) por medir de manera equilibrada operaciones de entrada/salida pequeñas y grandes, tanto en lectura como en escritura. IO500 es utilizado habitualmente para comparar sistemas en la lista TOP500 y proporciona una visión completa de la capacidad del sistema para manejar cargas reales.

Metodología de las pruebas

El laboratorio configuró un clúster Ceph con nodos de almacenamiento equipados con discos SSD/NVMe y red de alta velocidad. La configuración base utilizó:

• CPU de alto rendimiento por nodo.
• Conectividad de 100 Gb/s en red interna.
• Nodos MDS (Metadata Server) dedicados para CephFS.
• Entre 12 y 24 OSDs por nodo según escenario.

Las pruebas se ejecutaron múltiples veces, ajustando parámetros clave como:

• Número de OSDs activos.
• Afinidad de CPU.
• Tamaño máximo de transferencia (MTU).
• Número de MDS activos.
• Uso de SSDs frente a NVMe.
• Variaciones en osd_memory_target y bluestore_cache_size.

Cada cambio fue medido para identificar si ofrecía mejoras, era neutro o degradaba el rendimiento.

Hallazgos clave: lo que realmente marca la diferencia

Uno de los resultados más claros fue el impacto del rendimiento de CPU en las pruebas de metadatos. IO500 incluye operaciones intensivas en metadatos (creación, listado, borrado de ficheros), y en este apartado el cuello de botella no fue el almacenamiento físico, sino la capacidad de proceso de los nodos MDS.

Otra conclusión relevante fue la relación directa entre el número de OSDs y el rendimiento global. Más OSDs activos, hasta un punto óptimo, permitieron un mejor aprovechamiento del paralelismo, especialmente en operaciones de lectura y escritura secuenciales.

En la parte de red, el aumento del MTU a valores altos (como 9000) no supuso mejoras consistentes en todos los escenarios. Esto sugiere que, en ciertos entornos Ceph, la optimización de red no siempre se traduce en ganancias perceptibles si otros factores son el verdadero cuello de botella.

Optimización efectiva: cambios que sí funcionaron

Del conjunto de pruebas, varias optimizaciones demostraron aportar mejoras reproducibles:

1. Asignar más CPU y RAM a los nodos MDS
   Incrementar recursos en los servidores de metadatos redujo drásticamente la latencia en operaciones de pequeño tamaño.
2. Aumentar el número de OSDs equilibradamente
   Un mayor número de OSDs, bien distribuidos y con hardware homogéneo, elevó el rendimiento en IO secuencial y aleatorio.
3. Uso de NVMe para journaling y metadatos
   Separar los metadatos en dispositivos NVMe permitió mejorar las operaciones pequeñas, donde la latencia del medio de almacenamiento es crítica.
4. Ajustes en osd_memory_target
   Adaptar la memoria caché de los OSDs a la RAM física disponible optimizó el uso de recursos, evitando swapping y manteniendo un acceso rápido a datos frecuentemente solicitados.

Optimizaciones ineficaces o contraproducentes

El análisis también sirvió para desmontar algunos mitos:

• Incrementar el MTU de forma indiscriminada no siempre aporta beneficios, e incluso en determinados casos introdujo latencias adicionales por fragmentación y reensamblado.
• Aumentar en exceso el número de hilos de cliente degradó el rendimiento al provocar saturación de CPU y colas de I/O más largas.
• Forzar configuraciones de cache demasiado agresivas terminó generando picos de latencia cuando el sistema necesitaba liberar memoria de forma abrupta.

El mejor resultado reproducible

Tras múltiples iteraciones, el equipo de pruebas logró una configuración que ofrecía el mejor equilibrio entre rendimiento de operaciones pequeñas y grandes. Este ajuste incluyó:

• 2 MDS activos con CPU y RAM ampliadas.
• 20 OSDs por nodo con almacenamiento NVMe.
• osd_memory_target optimizado al 75 % de la RAM disponible por OSD.
• MTU estándar, evitando modificaciones innecesarias en entornos estables.
• Separación de datos y metadatos en dispositivos distintos.

Con esta configuración, las métricas IO500 alcanzaron picos de rendimiento que, de forma consistente, superaban los escenarios base en más de un 30 % para operaciones pequeñas y un 20 % para transferencias grandes.

Recomendaciones prácticas para administradores de Ceph

A partir de estos resultados, se desprenden varias recomendaciones que pueden servir de guía para quienes gestionan entornos Ceph:

1. Medir siempre antes y después de cualquier cambio, utilizando benchmarks fiables y escenarios representativos de la carga real.
2. Priorizar CPU y RAM en MDS cuando las operaciones de metadatos sean críticas para la aplicación.
3. Escalar OSDs con criterio: más no siempre es mejor si la red o la CPU no pueden soportar la carga.
4. Aislar metadatos y journals en NVMe para reducir latencias.
5. Evitar cambios masivos sin pruebas previas, especialmente en parámetros de red y cache.

La importancia de la validación continua

El estudio confirma que no existen configuraciones mágicas que sirvan para todos los despliegues Ceph. La combinación óptima de hardware y parámetros depende de la naturaleza de la carga de trabajo, el patrón de acceso y los recursos disponibles.

En este sentido, replicar un enfoque metódico —como el empleado en estas pruebas IO500— puede marcar la diferencia entre un sistema que simplemente funciona y uno que exprime al máximo las capacidades del hardware.

Preguntas frecuentes (FAQ)

1. ¿Qué es IO500 y por qué se usa para probar Ceph?
IO500 es un benchmark estándar en HPC que evalúa el rendimiento de sistemas de almacenamiento midiendo operaciones pequeñas y grandes, tanto en lectura como en escritura. Su relevancia radica en que simula cargas mixtas similares a las que experimentan entornos de producción.

2. ¿Aumentar el MTU a 9000 mejora siempre el rendimiento en Ceph?
No necesariamente. Aunque en teoría reduce el overhead de red, en estas pruebas no supuso una mejora significativa y en algunos casos introdujo latencias. Depende de la topología y del resto de la configuración.

3. ¿Es mejor usar SSD o NVMe para Ceph?
Los NVMe ofrecen menor latencia y mayor rendimiento que los SSD tradicionales, especialmente beneficioso para metadatos y journaling. Sin embargo, su coste y disponibilidad pueden influir en la decisión final.

4. ¿Cuántos OSDs por nodo son recomendables?
No hay una cifra universal. En estas pruebas, 20 OSDs por nodo con hardware equilibrado ofrecieron un buen rendimiento, pero cada entorno debe validarlo según su carga y recursos.

vía: croit.io