Almacenamiento para IA y HPC con Ceph.
Diseñamos, montamos y mantenemos en tu CPD el clúster del que leen tus GPU. Datasets, modelos, checkpoints y documentos viven en un solo sistema que crece añadiendo servidores.
Por qué el almacenamiento frena a las GPU
Cuando el almacenamiento no da abasto, la GPU se queda esperando y la máquina más cara del CPD deja de trabajar. Suele pasar por dos motivos: los metadatos no aguantan millones de ficheros pequeños, o la red entre nodos se queda corta, y ninguno de los dos se arregla añadiendo capacidad.
Ceph reúne en un clúster lo que la IA pide por separado: objetos S3 para datasets y modelos, un sistema de ficheros compartido para los nodos GPU y bloque para máquinas virtuales y bases de datos. Lo que rinda depende del diseño, así que empezamos midiendo tu carga y dimensionamos discos, red y metadatos a partir de esa medida.
Qué necesita cada carga
Un clúster de IA rara vez hace una sola cosa, y cada carga aprieta en un sitio distinto. Por eso repartimos los datos en pools y accesos diferentes dentro del mismo Ceph.
| Carga | Qué le pide al almacenamiento | Cómo lo resolvemos con Ceph |
|---|---|---|
| Entrenamiento | Leer el dataset desde muchos nodos a la vez, a menudo con millones de ficheros pequeños. | CephFS con metadatos en NVMe y varios MDS activos, o RGW si tu framework lee por S3. |
| Checkpoints | Escrituras grandes y a ráfagas que no frenen el entrenamiento. | Un pool NVMe en CephFS y, después, copia a un pool de capacidad. |
| Inferencia | Cargar los mismos pesos en muchos nodos y arrancar deprisa al escalar. | CephFS compartido por todos los nodos, o RGW con caché local en NVMe. |
| RAG | Millones de documentos y fragmentos, más una base vectorial sensible a la latencia. | RGW para los originales, CephFS para lo procesado y RBD en NVMe para Milvus, Qdrant o pgvector. |
| HPC | Directorios de usuario y de proyecto compartidos, y resultados que hay que conservar. | CephFS para usuarios y proyectos, y RGW con erasure coding para los resultados. |
| Archivo | Guardar datasets y versiones de modelos durante años con el menor coste por TB. | RGW con erasure coding sobre discos de gran capacidad y reglas de ciclo de vida. |
Bloque, ficheros y objetos en el mismo clúster
CephFS
El directorio compartido que ven todos los nodos GPU, que es lo que esperan PyTorch o vLLM cuando les das una ruta.
Cómo lo montamos
En Kubernetes llega como volumen ReadWriteMany a través de Rook. Dimensionamos aparte los MDS, los servidores de metadatos, y el pool de metadatos va siempre en NVMe.
RGW
Una API S3 dentro de tu red para datasets, pesos de modelos y resultados. Lo que ya habla S3 solo cambia de dirección.
Cómo lo montamos
Con versionado, reglas de ciclo de vida y cuotas por equipo. Lo frío pasa a discos de capacidad con erasure coding, y varias pasarelas reparten las peticiones.
RBD
Discos para máquinas virtuales, bases de datos y bases vectoriales, con snapshots y clones que no copian todo el volumen.
Cómo lo montamos
En Kubernetes es un volumen ReadWriteOnce, y en OpenStack o Proxmox VE, el disco de las máquinas. Lo sensible a la latencia va en un pool NVMe propio.
Qué decide el rendimiento
La red Cada escritura replicada viaja varias veces entre nodos, y las recuperaciones compiten por el mismo cable. Separamos la red de clúster de la de clientes y la dimensionamos según lo que pidan tus GPU: con discos NVMe partimos de 100 GbE, porque cambiarla después obliga a tocar un clúster en producción.
Los metadatos Con millones de ficheros pequeños, el primer atasco suele estar aquí y no en los discos. Ponemos el pool de metadatos en NVMe y repartimos el trabajo entre varios MDS activos, con directorios fijados a cada uno cuando la carga lo pide.
Réplica o erasure coding Tres réplicas escriben mejor, pero gastan tres veces la capacidad. El erasure coding aprovecha mucho más el disco a cambio de más CPU y red. Usamos réplica para lo caliente y erasure coding para lo frío, en pools distintos del mismo clúster.
Los fallos Con las reglas de CRUSH, las copias se reparten entre hosts, racks o salas para que una avería no se lleve más de una. También ajustamos la recuperación para que reconstruir un disco no frene a las GPU.
Cuándo te proponemos otra cosa
Si tu carga principal es entrenar a gran escala con GPUDirect Storage, o simulaciones en las que miles de procesos escriben a la vez en el mismo fichero, un sistema de ficheros paralelo como IBM Storage Scale o Lustre suele rendir más.
Muchas veces lo que encaja es combinarlos: el paralelo para el trabajo más intenso y Ceph para la capacidad y el S3. Somos IBM Business Partner y trabajamos con los dos, así que hacemos esta cuenta con tu carga delante. La comparación completa está en Storage Scale o Ceph para inferencia y en qué almacenamiento elegir para IA y HPC.
Hardware para el clúster
Estas son las configuraciones Supermicro Gold Series que usamos como punto de partida. Si ya tienes servidores, revisamos cuáles se pueden aprovechar.
Cómo trabajamos
Podemos llevar el clúster nosotros o dejarlo preparado para que lo lleve tu equipo.
Vemos qué lee y escribe tu carga, con qué tamaños y desde cuántos nodos, y cuántos datos vas a tener dentro de dos años.
Definimos discos, red, pools y dominios de fallo, y te decimos qué comprar y qué aprovechar.
Desplegamos con cephadm o con Rook, conectamos Kubernetes y tu plataforma de inferencia, y movemos los datos desde tu NAS o cabina por fases.
Repetimos la medida con fio y con tus propios trabajos antes de pasar a producción, y nos quedamos con esas cifras como referencia.
Las actualizaciones y las incidencias las lleva el mismo equipo que diseñó el clúster, con nuestro soporte técnico de Ceph. También formamos a tu equipo en nuestros cursos de Ceph.
Preguntas frecuentes
¿Ceph sirve para entrenar modelos?
Sí, sobre todo cuando el entrenamiento convive con inferencia, RAG y datasets compartidos, y el clúster tiene NVMe y una red de 100 GbE o más. Si lo único que importa es sacar el máximo ancho de banda a muchas GPU, te proponemos un sistema de ficheros paralelo, solo o junto a Ceph.
¿Hace falta que todo el clúster sea NVMe?
No. Lo habitual es reservar NVMe para metadatos, checkpoints y datos calientes, y dejar en discos de capacidad lo que se lee poco. Así el gasto en flash se queda donde se nota.
¿Cuántos nodos necesito?
Con tres ya se puede montar un clúster replicado. Con erasure coding hacen falta más, tantos como fragmentos de datos y de paridad más uno, para que los datos puedan reconstruirse cuando cae un nodo. El número real sale de la capacidad y del rendimiento que necesites, y lo calculamos con tu carga medida.
¿Ceph de la comunidad o IBM Storage Ceph?
Implementamos los dos. La versión de la comunidad te da independencia y ningún coste de licencia. IBM Storage Ceph añade el soporte del fabricante, algo que algunas empresas necesitan por contrato o por auditoría.
¿Funciona con Kubernetes?
Sí. Con Rook, Ceph corre dentro del propio clúster de Kubernetes, y con Ceph CSI se conecta a un clúster externo. En los dos casos los pods reciben volúmenes RBD y CephFS, y las aplicaciones pueden usar S3 a través de RGW.
¿Se pueden traer los datos desde un NAS o una cabina?
Sí. Los movemos por fases: primero lo que está frío y después lo que está en uso, que se sincroniza y se cambia en una ventana acordada contigo.
¿Podemos aprovechar el hardware que ya tenemos?
Muchas veces, sí. Revisamos discos, red y memoria de tus servidores y te decimos qué sirve para Ceph, qué sirve solo para capacidad y qué conviene cambiar antes de empezar.
¿Qué tienen que leer tus GPU?
Cuéntanos qué entrenas o sirves, cuántas GPU tienes y cuántos datos manejas. Te decimos si Ceph encaja y cómo lo montaríamos.
