Ceph: el camino hacia 1 TiB/s

Ceph: el camino hacia 1 TiB/s

• Un artículo que recorre el proceso de mejora de rendimiento de un clúster Ceph y cuenta cómo, tras una larga etapa de depuración y optimización, se alcanzó una velocidad de procesamiento de datos de 1 TiB/s.
• Comparte diversos problemas técnicos y sus soluciones que surgieron mientras la empresa Clyso ayudaba a construir un clúster Ceph de 10 petabytes basado en NVMe.
• La red del cliente es extremadamente rápida, una de las configuraciones Ethernet más veloces disponibles.

Agradecimientos

• Expresan su agradecimiento al cliente de Clyso, cuya colaboración hizo posible compartir esta experiencia con la comunidad de Ceph.
• También agradecen a IBM/Red Hat y a Samsung por proporcionar el hardware usado en las pruebas comparativas.
• Extienden además su agradecimiento a los contribuidores de Ceph por su esfuerzo para convertirlo en un gran software.

Configuración del clúster

• El cliente propuso 34 nodos 2U de doble socket distribuidos en 17 racks, pero Clyso sugirió varias configuraciones usando nodos más pequeños.
• Finalmente se eligió una arquitectura de Dell para reducir costos y ofrecer un mayor ancho de banda de memoria, más recursos de CPU y mayor rendimiento de red.
• Esto redujo a la mitad el impacto de la falla de un nodo sobre la recuperación del clúster.

Configuración de pruebas

• Se usó CBT para desplegar un clúster Ceph temporal y ejecutar pruebas con FIO.
• Se emplearon pruebas de FIO basadas en librerías para dividir el clúster en unidades pequeñas y compararlas con resultados previos.
• Se probaron replicación 3X y codificación de borrado 6+2, así como la versión 2 del mensajero en modo cifrado y modo seguro.

Precaución con la cantidad de PG

• Se probó experimentalmente cómo la cantidad de PG afecta el rendimiento.
• Una cantidad alta de PG puede influir positivamente en el rendimiento, aunque en producción debe evaluarse junto con otras configuraciones.

Por qué fue difícil empezar

• Tras iniciar sesión en el hardware por primera vez, resolver los problemas fue complicado porque el rendimiento era menor de lo esperado.
• Las pruebas iniciales de rendimiento fueron buenas, pero al probar con varios OSD apareció una degradación.

Un comportamiento extraño

• Al ejecutar distintas combinaciones de pruebas de OSD, descubrieron patrones anómalos en el rendimiento.
• Observaron que el sistema se degradaba después de pruebas multi-OSD y volvía a recuperarse horas después.

Tres soluciones

• Se resolvió un problema de latencia causado por los cambios de estado c-state de la CPU, lo que mejoró ligeramente el rendimiento.
• Desactivar IOMMU produjo una mejora importante de rendimiento.
• Se corrigió un problema con las banderas de compilación de RocksDB, duplicando el rendimiento de escritura aleatoria 4K.

La primera semana de 2024

• El primer día del año, una gran caída en otro clúster impidió concentrarse en las pruebas de rendimiento.
• El viernes se retomaron las pruebas y se confirmó que el clúster funcionaba bien incluso bajo alta carga.

La sonrisa del destino

• A medida que mejoraban los resultados, se confirmó que el clúster escalaba linealmente.
• En un clúster de 63 nodos se alcanzó una velocidad de procesamiento de datos de 635 GiB/s.

Una Estrella de la Muerte parcialmente funcional

• Como faltaban nodos cliente, fue necesario compartir los nodos OSD con los procesos FIO.
• Incluso con esa configuración se logró un rendimiento cercano a 950 GiB/s.

Alcanzando 1 TiB/s

• Ajustando la cantidad de shards de OSD y el número de hilos del mensajero, se alcanzó una velocidad de procesamiento de datos de 1 TiB/s.

Dormir; codificación de borrado

• Después de probar con replicación 3X, el clúster se reconfiguró con la codificación de borrado 6+2 que usaría el cliente y se volvió a probar.
• El rendimiento de lectura superó los 500 GiB/s y el de escritura llegó a casi 400 GiB/s.

Opinión de GN⁺:

1. Este artículo explica en detalle el proceso de optimización de rendimiento de un clúster Ceph y ofrece perspectivas técnicas al mostrar un caso donde se alcanzó un alto desempeño mediante una compleja resolución de problemas.
2. Muestra cómo la colaboración con el cliente, el esfuerzo de los contribuidores de la comunidad y diversas estrategias de optimización de hardware y software pueden producir grandes resultados en el mundo real.
3. El texto aporta información útil no solo para especialistas que trabajan con sistemas de almacenamiento de datos a gran escala, sino también para ingenieros interesados en la optimización de rendimiento.

[GN⁺]

Comentarios de Hacker News

• La noticia de alcanzar 1 TB/s en CERN y la historia de Ceph
  • Un usuario menciona que en CERN lograron una velocidad de 1 TB/s mediante un clúster EOS, explicando que este clúster usa principalmente HDD y cuenta con más nodos. También comparte la interesante historia de que Ceph fue creado en Dreamhost por necesidades internas y después fue adquirido por Red Hat.
• La experiencia de un antiguo líder técnico y su aprecio por Ceph
  • Un usuario recuerda su experiencia trabajando como líder técnico en Cisco, configurando Kubernetes sobre bare metal y experimentando con GlusterFS y Ceph, y comenta que disfrutó mucho esos experimentos. También elogia que el artículo está muy bien escrito.
• Sugerencia sobre reducir el tamaño de los nodos
  • Un usuario señala que el consumo energético por nodo del sistema actual es alto y propone un esfuerzo de ingeniería para reducir el tamaño de los nodos. Sostiene que así serían suficientes menos nodos y se reduciría el impacto de una sola falla sobre 10 discos.
• Perspectiva histórica sobre la cantidad de datos digitales almacenados
  • Un usuario comenta que en algún momento de los últimos 60 años debió existir un día en que por primera vez se almacenó 1 TiB de datos digitales en todo el mundo, y expresa su asombro de que ahora esa cantidad de datos se mueve cada segundo.
• Experiencia de mejora de rendimiento del caché de Docker con un clúster Ceph
  • Un usuario comparte que opera un clúster de almacenamiento Ceph para mantener el caché de capas de Docker, y que después de pasar de EBS a Ceph el throughput mejoró de forma considerable. También menciona que Ceph casi no requiere mantenimiento.
• Problemas del software controlador de almacenamiento dentro de Kubernetes
  • Un usuario menciona que el mayor problema relacionado con el almacenamiento dinámico dentro de Kubernetes no tiene que ver con I/O, sino con que el software controlador de almacenamiento falla cuando enfrenta problemas reales. En particular, dice haber experimentado casos en los que los PVC solo se adjuntaban después de mucho tiempo al usar rook/ceph y Longhorn.
• Análisis del rendimiento de 1 TiB/s frente a los límites teóricos del hardware
  • Un usuario analiza cómo se compara el rendimiento de 1 TiB/s con los límites teóricos del hardware y señala que la red está generando el cuello de botella. También concluye que la complejidad de Ceph impone una carga importante al CPU y que el modelo de threading de OSD no está optimizado, y espera que mejore.
• Solicitud de comparación entre Ceph y otros motores de almacenamiento de objetos
  • Un usuario pide ver comparaciones y benchmarks entre Ceph y otros motores de almacenamiento de objetos como MinIO y Garage.
• Consulta sobre la idoneidad de Ceph para bases de datos transaccionales y la latencia de IO
  • Un usuario pregunta si Ceph es adecuado para almacenamiento de bases de datos transaccionales y cómo es la latencia de IO, y expresa que le gustaría migrar a un sistema de archivos económico que pueda competir con sistemas como el sistema de archivos en clúster de Oracle o Veritas.