Listado de la etiqueta: ceph

Almacenamiento open source para IA y HPC

Almacenamiento open source para IA y HPC: cuando Ceph deja de ser una alternativa para convertirse en el único camino viable

/en

Cuando el CERN necesita almacenar y procesar los datos del Gran Colisionador de Hadrones (en inglés Large Hadron Collider o LHC, el acelerador de partículas más grande y potente del mundo), la escala lo condiciona todo. A ese nivel, la técnica y la economía convergen en una conclusión clara: tecnologías open source como Ceph, EOS y Lustre no son una “alternativa” a las soluciones enterprise tradicionales; en muchos escenarios, son el único camino viable.
Con más de 1 exabyte de almacenamiento en disco, 7.000 millones de archivos y 45 petabytes semanales procesados durante las campañas de toma de datos, el mayor laboratorio de física de partículas del mundo se mueve en un terreno donde los modelos clásicos de licencias por capacidad dejan de tener sentido económico.
Esta realidad, documentada en el paper presentado en CHEP 2025, “Ceph at CERN in the multi-datacentre era”, refleja lo que cada vez más universidades y centros de investigación están comprobando: hay casos de uso donde el open source no compite con las soluciones enterprise, define su propia categoría, para la que las arquitecturas tradicionales simplemente no fueron diseñadas.
almacenamiento open source cern

El CERN: cifras que cambian las reglas

Las cifras del CERN no solo impresionan; explican por qué se eligen ciertas tecnologías:

  • >1 exabyte de almacenamiento en disco, distribuido en ~2.000 servidores con 60.000 discos.
  • >4 exabytes de transferencias anuales.
  • Hasta 45 PB/semana y un throughput sostenido >10 GB/s en periodos de toma de datos.

La arquitectura es heterogénea por necesidad:

  • EOS para los ficheros de física (más de 1 EB).
  • CTA (CERN Tape Archive) para archivo a largo plazo.
  • Ceph (más de 60 PB) para bloques, objetos S3 y CephFS, vertebrando OpenStack.

Lo relevante no es solo el volumen, sino la trayectoria. En una década han pasado de unos pocos petabytes al exabyte sin saltos arquitectónicos disruptivos, añadiendo nodos commodity de forma horizontal. Esa elasticidad no existe en las cabinas propietarias con licencias por capacidad.

La economía del exabyte: dónde fallan los modelos por capacidad

Los modelos de licencias actuales en el mercado enterprise son razonables para entornos típicos (decenas o cientos de terabytes, crecimientos previsibles, CapEx y OpEx equilibrados). Aportan integración, soporte 24×7, certificaciones y un ecosistema de partners. Pero a escala petabyte o exabyte con crecimientos rápidos, la ecuación cambia.

  • En SIXE somos Premier Partner de IBM, y hemos evolucionado hacia licencias basadas en capacidad.
    • IBM Spectrum Virtualize utiliza Storage Capacity Units (SCU): ~1 TB por SCU. El coste anual por SCU puede oscilar entre 445 y 2.000 €, según volumen, perfil de cliente y condiciones del entorno.
    • IBM Storage Defender usa Resource Units (RUs). Por ejemplo, IBM Storage Protect consume 17 RUs/TB para los primeros 100 TB y 15 RUs/TB para los siguientes 250 TB, permitiendo combinar capacidades de resiliencia bajo una licencia unificada.
  • Modelos similares existen en NetApp (term-capacity licensing), Pure Storage, Dell Technologies y otros: pagar por capacidad gestionada o aprovisionada.

Todo esto funciona en entornos enterprise convencionales. Sin embargo, gestionar 60 PB bajo licencias por capacidad, incluso con descuentos altos por volumen, puede traducirse en millones de euros anuales solo en software, sin contar hardware, soporte o servicios. En ese punto, la pregunta ya no es si el open source es “viable”, sino si existe alguna alternativa realista a él para esas escalas.

Capacidades técnicas: un open source ya maduro

La ventaja económica no valdría si la tecnología fuese inferior. No es el caso. Para ciertas cargas de IA y HPC, las capacidades son equivalentes o superiores:

  • Ceph ofrece virtualización unificada de almacenamiento con thin provisioning, compresión en BlueStore, snapshots y clones COW sin penalización significativa, replicación multisite (RGW y RBD), y tiering entre medios, y si quieres que tu equipo comprenda cómo sacarle partido a Ceph, tenemos…
  • El CERN documenta estrategias multi-datacenter para continuidad de negocio y disaster recovery usando stretch clusters y multisite replication, con RPO/RTO comparables a soluciones enterprise.

IBM reconoce esta madurez con IBM Storage Ceph (derivado de Red Hat Ceph Storage), que combina tecnología open source con soporte, certificaciones y SLAs de nivel enterprise. En SIXE, como IBM Premier Partner, implementamos IBM Storage Ceph cuando se requiere soporte comercial y también Ceph upstream cuando se prioriza flexibilidad e independencia.
Diferencia clave de arquitectura:

  • IBM Spectrum Virtualize es una capa enterprise que gestiona almacenamiento heterogéneo de bloque, con nodos o instancias dedicadas, y funciones avanzadas de movilidad, replicación y automatización.
  • Ceph es un sistema distribuido nativo que sirve bloques, objetos y archivos desde la misma infraestructura horizontal, eliminando silos. En pipelines de IA —objetos para datasets, bloques para metadatos, archivos compartidos para colaboración— esta unificación aporta ventajas operativas claras.

Conceptual digital illustration symbolizing mature open source storage technology. Three distinct data flows (subtly different colors) converge into a single glowing structure, symbolizing integration and scalability. The environment evokes a modern data center with soft blue and white lighting, clean geometry, and a sense of precision and reliability.

IA a gran escala y HPC: donde lo distribuido brilla

Las cargas de entrenamiento de modelos fundacionales leen petabytes en paralelo, con anchos de banda agregados de 100 GB/s o más. La inferencia exige latencias sub-10 ms con miles de peticiones concurrentes.
Las arquitecturas tradicionales con controladoras SAN sufren cuellos de botella cuando cientos de GPU (A100, H100…) acceden a datos a la vez. Se estima que alrededor del 33 % de las GPUs en entornos corporativos de IA trabajan por debajo del 15 % de uso por saturación del almacenamiento, con el consiguiente coste en activos infrautilizados.
Las arquitecturas distribuidas —Ceph, Lustre, BeeGFS— nacieron para estos patrones:

  • Lustre impulsa 7 de los 10 supercomputadores del Top500, con >1 TB/s de throughput agregado en grandes instalaciones. Frontier (ORNL) usa ~700 PB en Lustre y escribe >35 TB/s sostenidos.
  • BeeGFS escala almacenamiento y metadatos de forma independiente, superando 50 GB/s sostenidos con decenas de miles de clientes en producción.
  • MinIO, optimizado para objetos en IA, ha demostrado >2,2 TiB/s de lectura en entrenamiento, difícil de igualar por arquitecturas centralizadas.

La integración con GPU también ha madurado: GPUDirect Storage permite que las GPUs lean desde NVMe-oF sin pasar por la CPU, reduciendo latencia y liberando ciclos. Los sistemas open source modernos soportan estos protocolos de forma nativa; en soluciones propietarias, a menudo dependen de firmware y certificaciones que tardan trimestres en llegar.
En SIXE hemos diseñado infraestructuras Ceph especializadas para IA y HPC que integran RBD para entrenamiento de modelos, RGW S3-compatible para datasets masivos y CephFS para cargas paralelas. Nuestros clústeres están optimizados para frameworks como PyTorch, TensorFlow y Hugging Face, con soporte 24/7 y SLA del 99.9%.

SIXE: open source sostenible, con o sin soporte comercial

Migrar a almacenamiento open source a gran escala no es trivial. Los sistemas distribuidos requieren experiencia específica.
En SIXE llevamos más de 20 años con Linux y open source. Como IBM Premier Partner, ofrecemos lo mejor de ambos mundos:

  • IBM Storage Ceph e IBM Storage Scale (antes Spectrum Scale/GPFS) para quienes necesitan SLAs garantizados, certificaciones y soporte global 24×7.
  • Ceph upstream (y tecnologías afines) para organizaciones que prefieren máxima flexibilidad y control.

No es una postura contradictoria, sino estratégica: distintos perfiles, distintas necesidades. Un banco multinacional valora certificaciones y soporte enterprise. Un centro de investigación con equipos técnicos fuertes puede operar upstream directamente.
Nuestras formaciones intensivas en Ceph son talleres prácticos de tres días: se despliegan clústeres reales y se explican las decisiones de diseño. La transferencia de conocimiento reduce la dependencia de consultores y empodera al equipo interno. Si tu equipo aún tiene poca experiencia con Ceph, haz click aquí para ver nuestro curso de iniciación, si por el contrario quieres exprimir al máximo Ceph, te dejamos aquí el curso avanzado en Ceph, donde tu equipo será capaz de integrar dos factores tecnológicos cruciales ahora mismo: Almacenamiento + IA.

Nuestra filosofía: no vendemos tecnología, transferimos capacidad. Implementamos IBM Storage Ceph con soporte completo, Ceph upstream con nuestro respaldo especializado o enfoques híbridos, según cada caso. Si trabajas con machine learning o computación de alto rendimiento, nuestra consultoría especializada en Ceph para IA y HPC puede ayudarte a diseñar la arquitectura óptima desde el primer día.

La oportunidad para ciencia y datos masivos

Se alinean varios factores:

  • Los datos crecen exponencialmente: un NovaSeq X Plus puede generar 16 TB por ejecución; el telescopio SKA producirá exabytes anuales; los modelos de IA demandan datasets crecientes.
  • Los presupuestos no crecen al mismo ritmo. Los modelos de licencias por capacidad hacen inviable escalar sistemas propietarios al ritmo requerido.

Las soluciones open source, ya sea upstream o comercialmente soportadas (p. ej., IBM Storage Ceph), eliminan esa dicotomía: se planifica el crecimiento por coste de hardware y capacidad operativa, con software cuyos costes no escalan linealmente por terabyte.
Centros como Fermilab, DESY, el propio CERN o el Barcelona Supercomputing Center han demostrado que este enfoque es técnicamente viable y operativamente superior para sus casos. En su paper reciente, el CERN detalla multi-datacenter para DR con Ceph (stretch y multisite), logrando disponibilidad comparable a soluciones enterprise, con flexibilidad y control total.

Un ecosistema en plena madurez

El ecosistema de almacenamiento open source para HPC e IA evoluciona rápido:

  • Ceph Foundation (Linux Foundation) coordina contribuciones de CERN, Bloomberg, DigitalOcean, OVH, IBM, entre otros, alineadas con necesidades reales de producción.
  • IBM mantiene IBM Storage Ceph como producto soportado y contribuye activamente upstream.

Es la confluencia ideal entre innovación open source y respaldo enterprise. Para organizaciones con horizonte de décadas, la pregunta ya no es si adoptar open source, sino cuándo y cómo hacerlo de forma estructurada.
La tecnología es madura, los casos de éxito están documentados y el soporte existe tanto en modalidad comunitaria como comercial. Lo que suele faltar es el expertise para trazar la hoja de ruta: modelo (upstream, comercial o híbrido), dimensionamiento, formación y operación sostenible.

SIXE: tu partner hacia un almacenamiento que crece contigo

En SIXE trabajamos en esa intersección. Como IBM Premier Partner, accedemos a soporte de primer nivel, roadmaps y certificaciones. A la vez, mantenemos expertise profundo en upstream y en otras tecnologías del ecosistema, porque no hay una única solución válida para todo.
Cuando un centro nos contacta, no empezamos por el catálogo, sino por las preguntas clave:

  • ¿Cuáles son tus patrones de acceso?
  • ¿Qué crecimiento proyectas?
  • ¿Qué capacidades tiene tu equipo?
  • ¿Qué riesgos puedes asumir?
  • ¿Qué presupuesto manejas (CapEx/OpEx)?

Las respuestas guían la recomendación: IBM Storage Ceph con soporte enterprise, upstream con nuestro soporte, un híbrido, o incluso valorar si una solución tradicional sigue teniendo sentido en tu caso. Diseñamos soluciones que funcionen a 5 y 10 años, lo importante para nosotros es crear soluciones duraderas y sostenibles en el tiempo ;)
Si estás evaluando almacenamiento para proyectos de IA que requieren alto throughput, baja latencia y escalabilidad horizontal, nuestro equipo de expertos en Ceph para IA y HPC puede realizar un análisis detallado de tus requisitos y diseñar una arquitectura que maximice el rendimiento de tus GPUs y acelere tus cargas de entrenamiento e inferencia.

¿Hablamos?

¿Tu organización genera volúmenes masivos de datos para IA o investigación? En SIXE ayudamos a centros de investigación, universidades y organizaciones innovadoras a diseñar, implementar y operar almacenamiento escalable con Ceph, Storage Scale y otras tecnologías líderes, tanto upstream como con soporte comercial de IBM, según tus necesidades.
Ya sea que necesites acelerar el entrenamiento de modelos, optimizar pipelines de inferencia o escalar tu infraestructura HPC, nuestros servicios especializados de Ceph para IA y HPC incluyen consultoría personalizada, implementación rápida y soporte técnico 24/7 con SLA del 99.9%. Contáctanos para una consulta estratégica sin compromiso.

Referencias

Logo Ceph sur le logo SIXE

Cómo corregir el error más común en Ceph

/en

Ceph es una solución potente y flexible para almacenamiento distribuido, pero como toda herramienta compleja, no está exenta de errores difíciles de diagnosticar. Si te ha aparecido el mensaje “could not connect to ceph cluster despite configured monitors”, ya sabes que algo no va bien en tu cluster. Y no, no es que los monitores estén dormidos. Este error es más común de lo que parece, especialmente después de cambios de red, reinicios o cuando alguien ha tocado la configuración “solo un poquito”.

En este artículo vamos al grano: te contamos las causas reales detrás de este problema y lo más importante, cómo solucionarlo sin perder los datos ni la cordura en el proceso.

Qué significa realmente el error ” could not connect to ceph cluster despite configured monitors “

Cuando Ceph te dice que no puede conectar al cluster “despite configured monitors”, lo que realmente está pasando es que el cliente o daemon puede ver la configuración de los monitores, pero no puede establecer comunicación con ninguno de ellos. Es como que te hagan ghosting, por mucho que llames, no te lo cogen.

Los monitores de Ceph son el cerebro del cluster: mantienen el mapa de la topología, gestionan la autenticación y coordinan el estado global. Sin conexión a los monitores, tu cluster Ceph es básicamente un montón de discos caros sin funcionalidad.

Solucionar errores de Ceph

Las 5 causas más comunes (y sus soluciones)

1. Problemas de red y conectividad

La causa número uno suele ser la red. Ya sea por firewalls mal configurados, cambios de IP o problemas de routing.

Diagnóstico rápido:

# Verifica conectividad básica
telnet [IP_MONITOR] 6789
# o con netcat
nc -zv [IP_MONITOR] 6789

# Comprueba las rutas
ip route show

Solución:

  • Asegúrate de que los puertos 6789 (monitor) y 3300 (msgr2) estén abiertos
  • Verifica que no hay reglas de iptables bloqueando la comunicación
  • Si usas firewalld, abre los servicios correspondientes:
firewall-cmd --permanent --add-service=ceph-mon
firewall-cmd --reload

2. Monmap desactualizado tras cambios de IP

Si has cambiado IPs de los nodos o modificado la configuración de red, es probable que el monmap (mapa de monitores) esté obsoleto.

Diagnóstico:

# Revisa el monmap actual
ceph mon dump

# Compara con la configuración
cat /etc/ceph/ceph.conf | grep mon_host

Solución:

# Extrae un monmap actualizado de un monitor funcionando
ceph mon getmap -o monmap_actual

# Inyecta el monmap corregido en el monitor problemático
ceph-mon -i [MON_ID] --inject-monmap monmap_actual

3. Problemas de sincronización de tiempo

Los monitores de Ceph son muy estrictos con la sincronización temporal. Un desfase de más de 50ms puede causar este error.

Diagnóstico:

# Verifica el estado de NTP/chrony
chrony sources -v
# o con ntpq
ntpq -p

# Comprueba el skew entre nodos
ceph status

Solución:

# Configura chrony correctamente
systemctl enable chronyd
systemctl restart chronyd

# Si tienes servidores NTP locales, úsalos
echo "server tu.servidor.ntp.local iburst" >> /etc/chrony.conf

4. Monitores en estado crítico o corruptos

Si los monitores han sufrido corrupción de datos o están en un estado inconsistente, pueden no responder correctamente.

Diagnóstico:

# Revisa los logs del monitor
journalctl -u ceph-mon@[MON_ID] -f

# Verifica el estado del almacén del monitor
du -sh /var/lib/ceph/mon/ceph-[MON_ID]/

Solución:

# Para un monitor específico, reconstruye desde los OSDs
systemctl stop ceph-mon@[MON_ID]
rm -rf /var/lib/ceph/mon/ceph-[MON_ID]/*
ceph-objectstore-tool --data-path /var/lib/ceph/osd/ceph-0 --journal-path /var/lib/ceph/osd/ceph-0/journal --type bluestore --op update-mon-db --mon-store-path /tmp/mon-store
ceph-mon --mkfs -i [MON_ID] --monmap /tmp/monmap --keyring /tmp/ceph.mon.keyring

5. Configuración de cliente incorrecta

A veces el problema está en el lado del cliente: configuración obsoleta, claves incorrectas o parámetros mal definidos.

Diagnóstico:

# Verifica la configuración del cliente
ceph config show client

# Comprueba las claves de autenticación
ceph auth list | grep client

Solución:

# Regenera las claves de cliente si es necesario
ceph auth del client.admin
ceph auth get-or-create client.admin mon 'allow *' osd 'allow *' mds 'allow *' mgr 'allow *'

# Actualiza la configuración
ceph config dump > /etc/ceph/ceph.conf
Cuándo pedir ayuda (antes de que sea tarde)

Este error puede escalar rápidamente si no se maneja correctamente. Si te encuentras en alguna de estas situaciones, es momento de parar y buscar ayuda profesional:

  • Todos los monitores están caídos simultáneamente
  • Has perdido el quorum y no puedes recuperarlo
  • Los datos parecen corruptos o inaccesibles
  • El cluster está en producción y no puedes permitirte experimentos

Los clusters Ceph en producción no son terreno para prueba y error. Un movimiento en falso puede convertir un problema de conectividad en una pérdida de datos.

La mejor solución al error  “could not connect to ceph cluster despite configured monitors” : prevenir

Para evitar encontrarte con este error en el futuro:

Monitorización proactiva:

  • Configura alertas para el estado de los monitores
  • Monitoriza la latencia de red entre nodos
  • Supervisa la sincronización temporal

Buenas prácticas:

  • Siempre despliega al menos 3 monitores (mejor 5 en producción)
  • Mantén backups regulares del monmap y las claves
  • Documenta cualquier cambio de configuración de red
  • Usa automatizaciones (Ansible, por ejemplo, es perfecto para para cambios de configuración)

Testing regular:

  • Prueba periódicamente la conectividad entre nodos
  • Simula fallos de monitores en entorno de desarrollo
  • Verifica que tus procedimientos de recovery funcionan

¿Necesitas ayuda con tu cluster Ceph?

Los clusters de almacenamiento distribuido como Ceph requieren experiencia específica para funcionar de manera óptima. Si te has encontrado con este error y las soluciones anteriores no resuelven tu problema, o si simplemente quieres asegurar que tu infraestructura Ceph está correctamente configurada y optimizada, podemos ayudarte.

En nuestro equipo tenemos experiencia solucionando problemas complejos de Ceph en entornos de producción, desde troubleshooting urgente hasta optimización de rendimiento y planificación de alta disponibilidad.

Te ofrecemos ayuda con

No dejes que un problema de conectividad se convierta en un dolor de cabeza mayor. La experiencia correcta puede ahorrarte tiempo, dinero y, sobre todo, estrés.

SIXE