Stockage pour l’IA et le HPC avec Ceph.
Nous concevons, montons et maintenons dans votre datacenter le cluster sur lequel lisent vos GPU. Datasets, modèles, checkpoints et documents vivent dans un seul système qui grandit en ajoutant des serveurs.
Pourquoi le stockage freine vos GPU
Quand le stockage ne suit pas, le GPU attend et la machine la plus chère du datacenter cesse de travailler. Il y a généralement deux causes : les métadonnées ne tiennent pas face à des millions de petits fichiers, ou le réseau entre les nœuds devient trop juste, et aucune des deux ne se règle en ajoutant de la capacité.
Ceph réunit dans un cluster ce que l’IA demande séparément : des objets S3 pour les datasets et les modèles, un système de fichiers partagé pour les nœuds GPU et du bloc pour les machines virtuelles et les bases de données. Ses performances dépendent de la conception : nous commençons donc par mesurer votre charge, puis nous dimensionnons disques, réseau et métadonnées à partir de cette mesure.
Ce dont chaque charge a besoin
Un cluster d’IA fait rarement une seule chose, et chaque charge sollicite un point différent. C’est pourquoi nous répartissons les données dans des pools et des accès distincts au sein du même Ceph.
| Charge | Ce qu’elle demande au stockage | Comment nous y répondons avec Ceph |
|---|---|---|
| Entraînement | Lire le dataset depuis de nombreux nœuds à la fois, souvent sur des millions de petits fichiers. | CephFS avec métadonnées sur NVMe et plusieurs MDS actifs, ou RGW si votre framework lit en S3. |
| Checkpoints | De grosses écritures par rafales qui ne freinent pas l’entraînement. | Un pool NVMe dans CephFS, puis une copie vers un pool de capacité. |
| Inférence | Charger les mêmes poids sur de nombreux nœuds et démarrer vite lors d’une montée en charge. | CephFS partagé par tous les nœuds, ou RGW avec un cache local sur NVMe. |
| RAG | Des millions de documents et de fragments, plus une base vectorielle sensible à la latence. | RGW pour les originaux, CephFS pour les données traitées et RBD sur NVMe pour Milvus, Qdrant ou pgvector. |
| HPC | Des répertoires d’utilisateurs et de projets partagés, et des résultats à conserver. | CephFS pour les utilisateurs et les projets, et RGW avec erasure coding pour les résultats. |
| Archivage | Conserver datasets et versions de modèles pendant des années au coût le plus bas par To. | RGW avec erasure coding sur des disques de grande capacité et règles de cycle de vie. |
Bloc, fichiers et objets dans le même cluster
CephFS
Le répertoire partagé que voient tous les nœuds GPU, ce qu’attendent PyTorch ou vLLM quand vous leur donnez un chemin.
Comment nous le montons
Dans Kubernetes, il arrive comme volume ReadWriteMany via Rook. Nous dimensionnons à part les MDS, les serveurs de métadonnées, et le pool de métadonnées va toujours sur NVMe.
RGW
Une API S3 dans votre réseau pour les datasets, les poids des modèles et les résultats. Ce qui parle déjà S3 change simplement d’adresse.
Comment nous le montons
Avec versionnage, règles de cycle de vie et quotas par équipe. Les données froides passent sur des disques de capacité avec erasure coding, et plusieurs passerelles se répartissent les requêtes.
RBD
Des disques pour les machines virtuelles, les bases de données et les bases vectorielles, avec des snapshots et des clones qui ne copient pas tout le volume.
Comment nous le montons
Dans Kubernetes, c’est un volume ReadWriteOnce ; dans OpenStack ou Proxmox VE, le disque des machines. Ce qui est sensible à la latence dispose de son propre pool NVMe.
Ce qui décide des performances
Le réseau Chaque écriture répliquée traverse le réseau plusieurs fois, et les reconstructions se disputent les mêmes liens. Nous séparons le réseau de cluster du réseau client et le dimensionnons selon les besoins de vos GPU : avec des disques NVMe, nous partons de 100 GbE, car le changer plus tard oblige à intervenir sur un cluster en production.
Les métadonnées Avec des millions de petits fichiers, le premier goulot d’étranglement se trouve souvent ici et non dans les disques. Nous plaçons le pool de métadonnées sur NVMe et répartissons le travail entre plusieurs MDS actifs, en attribuant des répertoires à chacun quand la charge le demande.
Réplication ou erasure coding Trois réplicas écrivent mieux, mais consomment trois fois la capacité. L’erasure coding exploite bien mieux le disque en échange de plus de CPU et de réseau. Nous utilisons la réplication pour les données chaudes et l’erasure coding pour les froides, dans des pools distincts du même cluster.
Les pannes Les règles CRUSH répartissent les copies entre hôtes, racks ou salles pour qu’une panne n’en emporte jamais plus d’une. Nous réglons aussi la reconstruction pour que remplacer un disque ne freine pas vos GPU.
Quand nous vous proposons autre chose
Si votre charge principale est l’entraînement à grande échelle avec GPUDirect Storage, ou des simulations où des milliers de processus écrivent en même temps dans le même fichier, un système de fichiers parallèle comme IBM Storage Scale ou Lustre est généralement plus performant.
Souvent, le bon choix est de les combiner : le parallèle pour le travail le plus intensif et Ceph pour la capacité et le S3. Nous sommes IBM Business Partner et nous travaillons avec les deux : nous faisons donc ce calcul avec votre charge sous les yeux. La comparaison complète se trouve dans Storage Scale ou Ceph pour l’inférence et dans quel stockage choisir pour l’IA et le HPC.
Le matériel du cluster
Voici les configurations Supermicro Gold Series qui nous servent de point de départ. Si vous avez déjà des serveurs, nous vérifions lesquels peuvent être réutilisés.
Notre façon de travailler
Nous pouvons gérer le cluster pour vous ou le laisser prêt pour que votre équipe s’en occupe.
Nous regardons ce que votre charge lit et écrit, avec quelles tailles et depuis combien de nœuds, et le volume de données que vous aurez dans deux ans.
Nous définissons disques, réseau, pools et domaines de panne, et nous vous disons quoi acheter et quoi réutiliser.
Nous déployons avec cephadm ou Rook, connectons Kubernetes et votre plateforme d’inférence, et déplaçons les données depuis votre NAS ou votre baie par étapes.
Nous répétons la mesure avec fio et vos propres travaux avant la mise en production, et nous gardons ces chiffres comme référence.
Les mises à jour et les incidents sont pris en charge par l’équipe qui a conçu le cluster, avec notre support technique Ceph. Nous formons aussi votre équipe dans nos cours Ceph.
Questions fréquentes
Ceph convient-il pour entraîner des modèles ?
Oui, surtout quand l’entraînement cohabite avec l’inférence, le RAG et des datasets partagés, et que le cluster dispose de NVMe et d’un réseau de 100 GbE ou plus. Si la seule priorité est d’offrir un maximum de bande passante à de nombreux GPU, nous vous proposons un système de fichiers parallèle, seul ou avec Ceph.
Tout le cluster doit-il être en NVMe ?
Non. On réserve généralement le NVMe aux métadonnées, aux checkpoints et aux données chaudes, et on laisse sur des disques de capacité ce qui est peu lu. Le budget flash reste ainsi là où il se voit.
Combien de nœuds me faut-il ?
Un cluster répliqué peut démarrer avec trois nœuds. L’erasure coding en demande davantage : autant que de fragments de données et de parité, plus un, pour pouvoir reconstruire les données quand un nœud tombe. Le nombre réel dépend de la capacité et des performances dont vous avez besoin, et nous le calculons à partir de votre charge mesurée.
Ceph communautaire ou IBM Storage Ceph ?
Nous mettons en œuvre les deux. La version communautaire vous donne l’indépendance et aucun coût de licence. IBM Storage Ceph ajoute le support de l’éditeur, nécessaire à certaines entreprises pour des raisons contractuelles ou d’audit.
Fonctionne-t-il avec Kubernetes ?
Oui. Avec Rook, Ceph tourne dans le cluster Kubernetes lui-même, et avec Ceph CSI il se connecte à un cluster externe. Dans les deux cas, les pods reçoivent des volumes RBD et CephFS, et les applications peuvent utiliser S3 via RGW.
Pouvez-vous reprendre les données d’un NAS ou d’une baie ?
Oui. Nous les déplaçons par étapes : d’abord les données froides, puis celles en cours d’utilisation, qui sont synchronisées et basculées dans une fenêtre convenue avec vous.
Pouvons-nous réutiliser le matériel que nous avons déjà ?
Souvent, oui. Nous examinons les disques, le réseau et la mémoire de vos serveurs et nous vous disons ce qui convient à Ceph, ce qui ne sert qu’à la capacité et ce qu’il vaut mieux changer avant de commencer.
Que doivent lire vos GPU ?
Dites-nous ce que vous entraînez ou servez, combien de GPU vous avez et quel volume de données vous gérez. Nous vous dirons si Ceph convient et comment nous le monterions.
