Lorsque le CERN doit stocker et traiter les données du Grand collisionneur de hadrons (LHC, l’accélérateur de particules le plus grand et le plus puissant du monde), l’échelle compte. À ce niveau, la technologie et l’économie convergent vers une conclusion claire : les technologies open source telles que Ceph, EOS et Lustre ne sont pas une “alternative” aux solutions d’entreprise traditionnelles ; dans de nombreux scénarios, elles constituent la seule voie viable.

Avec plus de 1 exaoctet de stockage sur disque, 7 milliards de fichiers y 45 pétaoctets par semaine traités lors des campagnes de collecte de données, le plus grand laboratoire de physique des particules du monde évolue dans un domaine où les modèles classiques de licence de capacité n’ont plus de sens économique.

Cette réalité, documentée dans le document présenté à CHEP 2025, “Ceph at CERN in the multi-datacentre era”, reflète ce que de plus en plus d’universités et de centres de recherche réalisent : il existe des cas d’utilisation où l’open source ne rivalise pas avec les solutions d’entreprise.Ceph reflète ce que de plus en plus d’universités et de centres de recherche réalisent : il existe des cas d’utilisation où l’open source n’est pas en concurrence avec les solutions d’entreprise, il définit sa propre catégorieIl définit sa propre catégorie, pour laquelle les architectures traditionnelles n’ont tout simplement pas été conçues.

CERN : des chiffres qui changent les règles

Les chiffres du CERN ne sont pas seulement impressionnants, ils expliquent pourquoi certaines technologies sont choisies :

• >1 exaoctet de stockage sur disque, réparti sur ~2 000 serveurs avec 60 000 disques.

• >4 exaoctets de transferts annuels.

• Jusqu’à 45 PB/semaine et débit soutenu >10 Go/s débit soutenu pendant les périodes de collecte de données.

L’architecture est hétérogène par nécessité:

• EOS pour les fichiers de physique (plus de 1 EB).

• CTA (CERN Tape Archive) pour l’archivage à long terme.

• Ceph (plus de 60 PB) pour les blocs, les objets S3 et CephFS, colonne vertébrale de OpenStack.

Ce qui compte, ce n’est pas seulement le volume, mais aussi la trajectoire. En une décennie, ils sont passés de quelques pétaoctets à des exaoctets. sans saut architectural perturbateurajout de nœuds marchandise horizontalement. Cette élasticité n’existe pas dans le cabines propriétaires avec des licences de capacité.

L’économie de l’exaoctet : là où les modèles de capacité échouent.

Les modèles de licence actuels sur le marché des entreprises sont raisonnables pour des environnements typiques (dizaines ou centaines de téraoctets, croissance prévisible, CapEx et OpEx équilibrés). Ils fournissent une intégration, une assistance 24×7, des certifications et un écosystème de partenaires. Mais à à l’échelle du pétaoctet ou de l’exaoctet avec une croissance rapide, l’équation change.

• Au SIXE nous sommes partenaire principal d’IBMet nous avons évolué vers des licences basées sur la capacité.
  • IBM Spectrum Virtualize utilise Unités de capacité de stockage (SCU)~1 TB par SCU. Le coût annuel par SCU peut varier de 445 y 2.000 €en fonction du volume, du profil des clients et des conditions environnementales.

  • IBM Storage Defender utilise les unités de ressources (RU). Par exemple , IBM Storage Protect consomme 17 RUs/TB pour les 100 premiers To et 15 UR/TB pour les 250 To suivants, ce qui permet de combiner les capacités de résilience sous une licence unifiée.

• Des modèles similaires existent chez NetApp (licence de capacité à terme), Pure Storage, Dell Technologies et autres : payer pour une capacité gérée ou provisionnée.

Tout cela fonctionne dans les environnements d’entreprise conventionnels. Cependant, gérer 60 PB dans le cadre d’une licence par capacité, même avec des remises importantes sur le volume, peut se traduire par des millions d’euros par an rien qu’en logiciels. des millions d’euros par an rien qu’en logicielssans compter le matériel, l’assistance ou les services. À ce moment-là, la question n’est plus de savoir si l’open source est “viable”, mais s’il est “viable”. Existe-t-il une alternative réaliste pour ces échelles.

Capacités techniques : une source ouverte mature

L’avantage économique ne s’appliquerait pas si la technologie était inférieure. Ce n’est pas le cas. Pour certaines charges d’IA et de HPC, les capacités sont équivalent ou supérieur:

• Ceph offre une virtualisation unifiée du stockage avec provisionnement fin, compression à BlueStore, instantanés y Clones COW sans pénalité significative, réplication multi-sites (RGW et RBD), et étagement entre les médias, et si tu veux que ton équipe comprenne comment tirer le meilleur parti de Ceph, nous avons…
  • Cours d’introduction à Ceph
  • Cours Ceph avancé
• Documents du CERN stratégies multi-centres de données stratégies pour la continuité des activités et la reprise après sinistre en utilisant grappes extensibles y la réplication multisiteavec RPO/RTO comparables aux solutions d’entreprise.

IBM reconnaît cette maturité avec IBM Storage Ceph (un dérivé de Red Hat Ceph Storage), qui combine la technologie open source technologie open source avec support, certifications et accords de niveau de service au niveau de l’entreprise. Au SIXEen tant que IBM Premier Partnernous implémentons IBM Storage Ceph lorsqu’un soutien commercial est nécessaire et également Ceph en amont lorsque la flexibilité et l’indépendance sont une priorité.

Différence clé dans l’architecture:

• IBM Spectrum Virtualize est une couche d’entreprise qui qui gère le stockage hétérogène de blocIl offre des fonctions de mobilité, de réplication et d’automatisation avancées.

• Ceph est un système distribué natif qui sert blocs, objets et fichiers à partir de la même infrastructure horizontaleéliminer les silos. Au pipelines pipelines – objets pour les ensembles de données, blocs pour les métadonnées, partage de fichiers pour la collaboration – cette unification apporte des avantages opérationnels clairs. des avantages opérationnels évidents.

IA et HPC à grande échelle : là où le distribué brille.

Les charges d’entraînement formation de formation des modèles fondamentaux lisent des pétaoctets en parallèleavec des bandes passantes globales de 100 Go/s ou plus. Les l’inférence nécessite des temps de latence inférieurs à 10 ms avec des milliers de demandes simultanées.

Architectures traditionnelles avec contrôleurs SAN contrôleurs souffrent de goulots d’étranglement lorsque des centaines de GPUS (A100, H100…) accèdent aux données en même temps. On estime qu’environ 33 % des GPU dans les environnements d’IA des entreprises fonctionnent à moins de 15 % d’utilisation en raison d’une saturation du stockagesaturation, coût actifs sous-utilisés.

Architectures distribuées architectures –Ceph, Lustre, BeeGFS– sont nés pour ces modèles :

• Éclat stimule 7 des 10 superordinateurs dans le Top500supercalculateurs, avec >1 TB/s dans les grandes installations. Frontier (ORNL) utilise ~700 PB dans Lustre et écrit >35 TB/s soutenu.

• BeeGFS fait évoluer le stockage et les métadonnées de manière indépendante indépendantdépassant 50 Go/s soutenu avec des dizaines de milliers de clients en production.

• MinIOoptimisé pour les objets dans l’IA, a démontré >2,2 TiB/s en lecture lors de la formation, ce qui est difficile à égaler pour les architectures centralisées.

Intégration avec GPU a également évolué : GPUDirect Storage permet aux GPU de lire les données des NVMe-oF sans passer par l’unité centrale, ce qui réduit la latence et libère des cycles. Les systèmes open source modernes prennent en charge ces protocoles. nativementdans des solutions propriétaires, ils s’appuient souvent sur des firmware y certifications qui prennent des trimestres à arriver.

SIXE : source ouverte durable, avec ou sans soutien commercial

Migrer vers un système de stockage open source à grande échelle n’est pas trivial. Les systèmes distribués nécessitent expérience spécifique.

Sur SIXE nous sommes plus de 20 ans avec Linux y source ouverte. Comme Partenaire principal d’IBMnous offrons le meilleur des deux mondes:

• IBM Storage Ceph e IBM Storage Scale (anciennement Spectrum Scale/GPFS) pour ceux qui ont besoin de des accords de niveau de service (SLA) garantis, certifications y une assistance mondiale 24×7.

• Ceph en amont (et technologies connexes) pour les organisations qui préfèrent un maximum de flexibilité et de contrôle.

Il ne s’agit pas d’une position contradictoire, mais d’une stratégiqueDes profils différents, des besoins différents. A banque multinationale valeurs les certifications et le soutien aux entreprises. A centre de recherche doté d’un solide équipement technique, peut opérer en amont directement.

Nos Nos formations intensives sur Ceph Les ateliers sont ateliers de trois joursateliers : des clusters réels sont déployés et les décisions de conception sont expliquées. décisions de conception. Le transfert de connaissances réduit la dépendance à l’égard des consultants et des habiliter à l’équipe interne. Si ton équipe a encore peu d’expérience avec Ceph, clique ici pour voir notre cours pour débutants, si par contre tu veux tirer le maximum de Ceph, nous te laissons ici le cours Ceph avancé, où ton équipe pourra intégrer deux facteurs technologiques cruciaux à l’heure actuelle : Stockage + IA.

Notre philosophieNous ne vendons pas de technologie, nous transférons des capacités. Nous mettons en œuvre IBM Storage Ceph avec une assistance complète, Ceph en amont avec notre système de sauvegarde spécialisé ou Ceph en aval. les approches hybridesau cas par cas.

L’opportunité de la science et du big data

Plusieurs facteurs s’alignent :

• Les données augmentent de façon exponentielle: a NovaSeq X Plus peut générer 16 TO par cycle ; le télescope télescope SKA produira exaoctets par an; les modèles d’IA exigent ensembles de données données.

• Les budgets ne se développent pas au même rythme. Lla modèles de licences de capacité rendent irréalisables de faire évoluer les systèmes propriétaires au rythme requis.

Les solutions open source, qu’elles soient en amont o soutenues par le commerce (ex, IBM Storage Ceph), élimine cette dichotomie : la croissance est planifiée en fonction du coût du matériel. le coût du matériel y la capacité opérationnelleavec logiciel dont les coûts ne sont pas linéaires par téraoctet.

Des centres tels que Fermilab, DESYle CERN ou le Barcelona Supercomputing Center ont démontré que cette approche est techniquement possible y supérieure sur le plan opérationnel pour leurs cas. Dans son récent document, le CERN détaille multi-centres de données pour DR avec Ceph (stretch et multisite), atteignant une disponibilité comparable aux solutions d’entreprise, avec flexibilité et un contrôle total.

Un écosystème qui arrive à maturité : planifie dès maintenant

L’écosystème de stockage open source pour HPC e AI évolue rapidement :

• Fondation Ceph (Fondation Linux) coordonne les contributions du CERN, Bloomberg, DigitalOcean, OVH, IBMentre autres, alignés sur les besoins réels de production.

• IBM maintient IBM Storage Ceph en tant que produit pris en charge et contribue activement en amont.

C’est la confluence idéale de l’innovation open source y le soutien aux entreprises. Pour les organisations ayant un horizon de décenniesdécennies, la question n’est plus de savoir si adopter l’open source, mais quand et comment le faire de façon manière structurée.

La technologie est matureLa technologie est mature, des exemples de réussite sont documentées et le soutien existe à la fois en mode communautaire et commercial. Ce qui manque souvent, c’est la l’expertise pour établir la feuille de route : modèle (en amont, commercial ou hybride), dimensionnement, formation y fonctionnement durable.

SIXE : ton partenaire vers un stockage qui grandit avec toi

Sur SIXE nous travaillons à cette intersection. Comme Partenaire principal d’IBMnous avons accès à une assistance de classe mondiale, feuilles de route y certifications. En même temps, nous maintenons une expertise approfondie en amont et d’autres technologies de l’écosystème, parce qu’il n’y a pas de il n’y a pas de solution universelle n’est pas une solution unique.

Lorsqu’un centre nous contacte, nous ne commençons pas par le cataloguemais par les questions clés:

• Quels sont tes modèles d’accès?

• Ce que croissance prévois-tu ?

• Quelles sont les capacités ton équipe dispose-t-elle de capacités ?

• Quels sont les risques peux-tu prendre ?

• Ce que budget gères-tu (CapEx/OpEx) ?

Les réponses orientent la recommandation : IBM Storage Ceph avec le support de l’entreprise, en amont avec notre support, un hybride, ou même évaluer si une solution traditionnelle a encore du sens dans ton cas. Nous concevons des solutions qui fonctionnent pendant 5 et 10 ans, l’important pour nous est de créer des solutions durables et pérennes ;).

Nous nous engageons à des technologies durablesdes technologies qui ne sont pas soumises aux fluctuations commerciales, qui donnent contrôle de l’infrastructure et de l’échelle techniquement et économiquement.

Le cas du CERN Le cas du CERN n’est pas une curiosité académique : il montre où va le stockage des charges utiles à forte intensité de données. charges de données intensives. La question n’est pas de savoir si ton organisation y parviendra, mais si elle y parviendra tout court. comment arriveront : préparé o en route. La fenêtre d’opportunité de planifier calmement est ouverte. ouverte. Lla succès existent. Les technologie est prêt. Les écosystème également. Il reste à prendre le décision stratégique d’investir dans une infrastructure qui accompagnera ton organisation pendant des décennies. décennies de croissance des données.

Voulez-vous parler?

Ton organisation génère-t-elle des volumes massifs de données pour l’ L’IA o recherche? A SIXE Nous aidons les instituts de recherche, les universités et les organisations innovantes à concevoir, mettre en oeuvre et exploiter stockage modulable avec Ceph, Échelle de stockage et d’autres technologies de pointe, à la fois en amont comme pour Soutien commercial d’IBMselon tes besoins. Contacte-nous à pour un consultation stratégique sans obligation.

Références

• Goggin, Z., Lekshmanan, A., Valverde, R. et Bocchi, E. (2025). Ceph au CERN à l’ère des centres de données multiples.. EPJ Web of Conferences, 337., 01331.

• Groupe de stockage du CERN. (2024). Systèmes de stockage Open Source du CERN. FOSDEM 2024.

• Fondation Linux. (2024). Ceph, le choix par défaut du stockage d’entreprise pour les charges de travail critiques.

• IBM. (2024). IBM Storage Defender : Résilience unifiée des données grâce à l’octroi de licences pour les unités de ressources.

Ceph est une solution puissante et flexible pour le stockage distribué, mais comme tout outil complexe, il n’est pas exempt d’erreurs difficiles à diagnostiquer. Si tu obtiens le message “could not connect to ceph cluster despite configured monitors”, tu sais que quelque chose ne va pas avec ton cluster. Et non, ce n’est pas que les moniteurs sont endormis. Cette erreur est plus fréquente qu’il n’y paraît, surtout après des changements de réseau, des redémarrages ou lorsque quelqu’un a touché à la configuration “juste un peu”.

Dans cet article, nous allons droit au but : nous t’expliquons les vraies causes derrière ce problème et, plus important encore, comment le résoudre sans perdre tes données ou ta raison dans le processus.

Que signifie vraiment l’erreur “could not connect to ceph cluster despite configured monitors” ?

Lorsque Ceph te dit qu’il ne peut pas se connecter au cluster “malgré les moniteurs configurés”, ce qui se passe en réalité, c’est que le client ou le démon peut voir la configuration des moniteurs, mais ne peut établir de communication avec aucun d’entre eux. C’est comme être ghosting, tu as beau appeler, ils ne décrochent pas.

Les moniteurs Ceph sont les cerveaux du cluster : ils maintiennent la carte topologique, gèrent l’authentification et coordonnent l’état global. Sans connexion aux moniteurs, ton cluster Ceph n’est qu’un tas de disques coûteux sans aucune fonctionnalité.

Les 5 causes les plus courantes (et leurs solutions)

1. problèmes de réseau et de connectivité

La cause numéro un est généralement le réseau. Qu’il s’agisse de pare-feu mal configurés, de changements d’IP ou de problèmes de routage.

Diagnostic rapide :

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

# Comprueba las rutas
ip route show

Solution :

• Assure-toi que les ports 6789 (moniteur) et 3300 (msgr2) sont ouverts.
• Vérifie qu’il n’y a pas de règles iptables qui bloquent la communication.
• Si tu utilises firewalld, ouvre les services correspondants :

firewall-cmd --permanent --add-service=ceph-mon
firewall-cmd --reload

2. Monmap n’est plus à jour après les changements d’IP

Si tu as changé les IP des nœuds ou modifié la configuration du réseau, il est probable que la monmap (carte du moniteur) ne soit plus à jour.

Diagnostic :

# Revisa el monmap actual
ceph mon dump

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

Solution :

# 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. Problèmes de synchronisation du temps

Les moniteurs Ceph sont très stricts en matière de synchronisation temporelle. Un décalage de plus de 50 ms peut provoquer cette erreur.

Diagnostic :

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

# Comprueba el skew entre nodos
ceph status

Solution :

# 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. Moniteurs critiques ou corrompus

Si les moniteurs ont subi une corruption de données ou sont dans un état incohérent, ils risquent de ne pas répondre correctement.

Diagnostic :

# 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]/

Solution :

# 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. Configuration incorrecte du client

Parfois, le problème se situe du côté du client : configuration obsolète, clés incorrectes ou paramètres mal définis.

Diagnostic :

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

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

Solution :

# 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

Quand demander de l’aide (avant qu’il ne soit trop tard)

Cette erreur peut s’aggraver rapidement si elle n’est pas gérée correctement. Si tu te trouves dans l’une de ces situations, il est temps d’arrêter et de demander l’aide d’un professionnel :

• Tous les moniteurs sont éteints simultanément
• Tu as perdu le quorum et tu ne peux pas le récupérer.
• Les données semblent corrompues ou inaccessibles
• Le cluster est en production et tu ne peux pas te permettre de faire des expériences.

Les clusters Ceph en production ne sont pas un environnement d’essais et d’erreurs. Un faux mouvement peut transformer un problème de connectivité en une perte de données.

La meilleure solution à l’erreur “could not connect to ceph cluster despite configured monitors” : prévenir.

Pour éviter de rencontrer cette erreur à l’avenir :

Surveillance proactive :

• Définis des alertes sur l’état des moniteurs
• Surveille la latence du réseau entre les nœuds
• Contrôle la synchronisation de l’heure

Bonne pratique :

• Déploie toujours au moins 3 moniteurs (mieux vaut 5 en production).
• Conserve des sauvegardes régulières de la monmap et des clés.
• Documente toute modification de la configuration du réseau
• Utilise des automatismes (Ansiblepar exemple, est parfait pour les changements de configuration).

Tests réguliers :

• Teste périodiquement la connectivité entre les nœuds
• Simule les défaillances du moniteur dans l’environnement de développement
• Vérifie que tes procédures de récupération fonctionnent

Besoin d’aide avec ton cluster Ceph ?

Les clusters de stockage distribués tels que Ceph nécessitent une expertise spécifique pour fonctionner de manière optimale. Si tu as rencontré cette erreur et que les solutions ci-dessus ne résolvent pas ton problème, ou si tu veux simplement t’assurer que ton infrastructure Ceph est correctement configurée et optimisée, nous pouvons t’aider.

Notre équipe a de l’expérience dans la résolution de problèmes Ceph complexes dans des environnements de production, du dépannage urgent à l’optimisation des performances et à la planification de la haute disponibilité.

Nous offrons de l’aide pour

• Assistance technique et conseil Ceph
• Cours d’introduction cours y cours avancés au Ceph
• Soutien urgent aux systèmes

Ne laisse pas un problème de connectivité devenir un gros mal de tête. La bonne expertise peut te faire gagner du temps, de l’argent et surtout du stress.

L’intelligence artificielle ne se contente plus de répondre, elle prend aussi des décisions. Avec des frameworks comme LangGraph et des plateformes comme watsonx.ai , tu peux construire des agents qui raisonnent et agissent de manière autonome ?.

Dans cet article, nous allons t’expliquer comment mettre en place un agent ReAct (Reasoning + Action) en local et le déployer sur IBM Cloud, le tout avec un exemple pratique incluant un outil de requête météorologique ?️.

Un guide pratique pour utiliser tes agents avec LangGraph et Watsonx.ai

Architecture du projet

• Machine avec projet local
  • Ici, tu développes et testes l’agent avec Python, LangGraph et les dépendances.
• ZIP (pip-zip)
  • Paquet avec ton code et des outils supplémentaires.
• Spécification du logiciel
  • Environnement contenant les bibliothèques nécessaires à l’exécution de l’agent.
• watsonx.ai
  • Platform où tu déploies le service en tant qu’API REST.
• Stockage d’objets dans le nuage IBM
  • Stocke les actifs de déploiement.

Préparons l’environnement pour notre agent

Nous avons besoin de :

• Python 3.12 installé
• IBM Cloud access et watsonx.ai
• Poésie pour la gestion des dépendances

As-tu tout ce qu’il te faut ? Avant toute chose, clone le dépôt que nous allons utiliser comme exemple. Il est basé sur les exemples officiels d’IBM.

git clone https://github.com/thomassuedbroecker/watsonx-agent-langgraph-deployment-example.git 
cd ./agents/langgraph-arxiv-research

Tout d’abord, comprenons le projet d’exemple.

Les principaux fichiers de l’agent sont :

Passons maintenant à la mise en place de l’environnement

Nous te recommandons également d’utiliser Anaconda ou miniconda. Il nous permet de gérer des environnements virtuels ou des paquets Python de manière simple et est largement utilisé en ML.

Pour que Python puisse trouver nos modules personnalisés (tels que les agents et les outils), nous devons inclure le répertoire actuel dans la variable d’environnement. PYTHONPATH

export PYTHONPATH=$(pwd):${PYTHONPATH}

Une fois l’environnement prêt, il est temps de passer aux variables. Tu dois créer un fichier config.toml si tu n’en as pas déjà un et utiliser tes identifiants IBM Cloud:

Tu trouveras tes variables ici :

https://dataplatform.cloud.ibm.com/developer-access

Une fois sur place, sélectionne ton espace de déploiement et copie les données nécessaires (API Key, Space ID, etc.).

Exécution dans les locaux de l’agent

Il est temps de tester l’agent :

Puisqu’il s’agit d’un agent météorologique, pourquoi n’essaies-tu pas avec quelque chose comme… ?

« Quel temps fait-il actuellement à Madrid ? »

La console devrait te donner l’heure à Madrid – félicitations, il ne nous reste plus qu’à faire le déployer dans watsonx.ai

Déploiement d’agents dans watsonx.ai

source ./.venv/bin/activate
poetry run python examples/query_existing_deployment.py

Conclusions

Si tu as des doutes, nous te recommandons le tutoriel vidéo suivant où tu pourras suivre pas à pas le développement connecté à watsonx.ai.

Si tu veux approfondir ces mises en œuvre ou en savoir plus sur le développement du cloud et l’intelligence artificielle, nous t’invitons à explorer nos cours sur l’IA.?

• Chez IBM
• Dans Canonical / Ubuntu