Aller au contenu

R3 · Cluster et Slurm

Le trou le plus visible de la maquette FISA, et le plus facile à combler chez soi.

Volume ⏱ 60 h
Quand Semestre 4, ou l'été suivant
Prérequis Linux en ligne de commande, réseau IP, une machine capable de faire tourner 4 VM
Ce que la maquette FISA donne déjà DEVO35 (S5) : Docker, Kubernetes, GitLab CI, Airflow — l'infrastructure as code, pas l'ordonnanceur
Livrable Un cluster de 4 nœuds reconstructible par script, avec un HPL qui tourne dessus

D'où vient ce module

Son programme est celui de LOCL24 · Logiciel cluster, enseigné dans la formation sous statut étudiant. Aucune UE de la maquette FISA ne le couvre.

Le seul module de la liste qui ne demande aucun matériel

Quatre machines virtuelles sur un portable suffisent pour tout, sauf la mesure de bande passante réseau. C'est ce qui en fait le premier module à faire si vous n'avez pas encore d'accès machine : il produit un livrable montrable, et c'est le projet P7.

Le programme à couvrir

Objectifs cités :

« Cette UE présente l'architecture matérielle et logicielle d'un cluster de calcul intensif HPC (High Performance Computing) en détaillant le fonctionnement des composants logiciels les plus critiques. Le cours s'appuiera sur le système d'exploitation Linux et les logiciels Open Source les plus utilisés dans les grands centres de calcul et les datacenters.

A la fin de l'UE, les étudiants seront capables de concevoir l'architecture d'un cluster Linux pour le HPC, de planifier son installation, de réaliser son déploiement et son intégration dans un centre de calcul, et mettre en place les principaux services nécessaires à sa mise en production. »

Contenu cité, module ASCC24 architecture matérielle et logicielle des super-calculateurs :

Présentation générale de l'architecture d'un super-calculateur :

  • nœuds de calcul (Xeon, ARM, accélérateurs, FPGA) ;
  • nœuds de services (login, passerelles) ;
  • nœuds de dépouillement, post-traitement ;
  • réseaux internes ;
  • défis pour le passage à l'exaflops.

Services d'administration et logiciels open source associés :

  • systèmes d'installation automatique de serveurs (Kickstart, Cobbler, SystemImager) et protocoles associés ;
  • systèmes de contrôle de serveurs (BMC, IPMI), gestion de consoles et d'alimentation ;
  • gestion des fichiers de log ;
  • système de gestion des configurations Puppet ;
  • service de synchronisation de temps (NTP) ;
  • service d'annuaires (LDAP) ;
  • service de résolution de noms de domaine (DNS) ;
  • outil de compilation automatique de logiciels open source.

Gestionnaire de travaux open source SLURM.

Une coquille du document source

La section SLURM du syllabus FISE reproduit par erreur la liste de puces de la section précédente (Kickstart, BMC, logs, Puppet). Le contenu réel sur Slurm n'est donc pas détaillé dans le document. Compte tenu de l'objectif annoncé — « mettre en place les principaux services nécessaires à sa mise en production » — on peut supposer qu'il couvre l'installation, la configuration des partitions et des QOS, la comptabilité (slurmdbd) et la soumission. À vérifier auprès de l'intervenant.

Compétences cotées « 2 – Maîtrise » : rédiger l'information produite, résoudre des problèmes techniques en TP, analyser les besoins d'un client ou d'un projet, mobiliser des connaissances théoriques et techniques pointues, chercher des outils complexes et les lier entre eux, choisir le meilleur outil.

Ce que ça vaut pour le HPC

Maximal, et irremplaçable.

C'est le seul endroit de votre formation où vous verrez comment un supercalculateur est construit du point de vue de celui qui l'exploite. Ce contenu est presque impossible à acquérir seul, parce qu'il suppose du matériel : on ne pratique pas l'IPMI et le déploiement PXE sur un ordinateur portable.

Trois points valent une attention particulière.

1. Slurm. C'est l'ordonnanceur de la grande majorité des supercalculateurs mondiaux. Savoir écrire un sbatch correct est le minimum vital ; savoir configurer un slurm.conf, comprendre les politiques de backfill, la comptabilité, les limites de QOS et les contraintes de nœuds vous place dans une autre catégorie. En compétition, c'est ce qui vous permet de garantir qu'une exécution obtient exactement les ressources voulues.

2. La chaîne de déploiement. PXE, Kickstart, Cobbler, Puppet. Dans une Student Cluster Competition sur site, l'équipe reçoit du matériel et doit en faire un cluster fonctionnel. Ce n'est pas une métaphore du cours : c'est le cours.

3. Les « défis pour le passage à l'exaflops ». Consommation électrique, tolérance aux pannes, hiérarchie de stockage, hétérogénéité, bruit système. Ce sont les questions qu'un jury pose en entretien, et celles qui structurent la recherche en HPC actuelle.

Le contexte, en septembre 2026

Fait, consulté le 17 septembre 2026. La liste TOP500 de juin 2026 est dominée par le système chinois LineShine, installé au centre national de calcul de Shenzhen, mesuré à 2,198 exaflop/s sur HPL avec 13 789 440 cœurs, sur une plateforme propriétaire « LingKun » à processeurs LX2 de 304 cœurs à 1,55 GHz, interconnexion « LingQi » et système Kylin. C'est le premier système chinois en tête depuis Sunway TaihuLight en 2017, et il devance de plus de 20 % le second.

Retenez l'ordre de grandeur : un exaflop, c'est \(10^{18}\) opérations flottantes par seconde, et il faut plus de dix millions de cœurs pour y parvenir. Tous les « défis pour le passage à l'exaflops » du programme de LOCL24 sont des conséquences de ces deux nombres.

Arriver prêt

⏱ 12 h, et c'est très rentable parce que le temps de TP est limité.

  1. Monter un mini-cluster virtuel pour commencer. Trois machines virtuelles sous Vagrant, Multipass ou libvirt : un nœud maître, deux nœuds de calcul. Configurer SSH sans mot de passe, NFS pour un /home partagé, et /etc/hosts. ⏱ 5 h. Vous aurez ainsi un bac à sable pour tout le semestre.
  2. Installer Slurm dessus. slurmctld sur le maître, slurmd sur les nœuds, munge pour l'authentification. C'est fastidieux la première fois et c'est exactement l'objectif. ⏱ 4 h. Documentation : slurm.schedmd.com, Quick Start Administrator Guide.
  3. Réviser TCP/IP et le sous-réseau. Calcul de masque, adressage, routage statique. ⏱ 3 h.

Ressources

Priorité 1

  • La documentation Slurm (slurm.schedmd.com) : Quick Start User Guide, Quick Start Administrator Guide, et les pages de manuel de sbatch, srun, salloc, squeue, sacct, scontrol, sinfo. C'est complet et fiable. Les Slurm Publications and Presentations de la même page contiennent les exposés des journées utilisateurs, très instructifs sur les politiques d'ordonnancement réelles.
  • Les guides utilisateurs des grands centres de calcul. Ce sont des documents pédagogiques remarquables, écrits pour des scientifiques non informaticiens, et qui expliquent des architectures réelles :
    • IDRIS (idris.fr/jean-zay/) en français, sur Jean Zay ;
    • CINES sur Adastra ;
    • NERSC (docs.nersc.gov) sur Perlmutter, particulièrement bien fait ;
    • OLCF (docs.olcf.ornl.gov) sur Frontier.

Lire deux ou trois de ces guides vous apprendra plus sur l'architecture réelle d'un supercalculateur que n'importe quel livre.

Priorité 2

  • La documentation de Puppet et, en alternative, celle d'Ansible (plus répandu aujourd'hui dans les petites installations, et qu'aucune UE de la maquette FISA n'enseigne). Apprenez les deux principes : Puppet est déclaratif avec un agent, Ansible est procédural sans agent.
  • La documentation de xCAT, de Warewulf et d'OpenHPC. OpenHPC en particulier est un projet qui fournit une pile logicielle complète de cluster HPC prête à déployer, avec un guide d'installation pas à pas. C'est la manière la plus rapide de monter un cluster réaliste, et c'est un excellent support d'apprentissage.
  • ipmitool et la spécification IPMI, au moins les commandes de base : power status, power cycle, sol activate, sdr pour les capteurs. La lecture des capteurs de puissance par IPMI est, en compétition, la manière de surveiller son budget électrique.
  • Sur les réseaux d'interconnexion : la documentation InfiniBand (perftest, ibstat, ibdiagnet), et les concepts de fat-tree, dragonfly, tore. L'article de Kim et al. sur dragonfly (ISCA 2008) est le point d'entrée académique.

Priorité 3 — le contexte et l'histoire

  • Les listes TOP500 et Green500 (top500.org) : lisez les highlights de chaque édition, deux fois par an. C'est la manière la plus efficace de suivre l'état du domaine.
  • Le site de l'EuroHPC JU (eurohpc-ju.europa.eu) pour les machines européennes et la stratégie continentale.
  • Le rapport Exascale Computing Project (ECP) des laboratoires américains, et les publications associées, pour les défis techniques de l'exaflops traités en profondeur.

Outils à maîtriser

Outil Usage
sbatch, srun, salloc Soumission ; comprendre la différence entre les trois
squeue, sinfo, scontrol show job Diagnostic de file d'attente
sacct, sstat, seff Comptabilité et efficacité d'un travail passé
--exclusive, --ntasks-per-node, --cpus-per-task, --hint=nomultithread Contrôle du placement
ipmitool Alimentation, console série, capteurs
pdsh, clush (ClusterShell) Exécuter une commande sur N nœuds
module / lmod Environnements logiciels
ibstat, ib_write_bw, ib_send_lat Diagnostic InfiniBand
Prometheus + Grafana, ou Ganglia Surveillance

Le script Slurm que tout compétiteur doit savoir écrire de mémoire

#!/bin/bash
#SBATCH --job-name=hpl
#SBATCH --nodes=4
#SBATCH --ntasks-per-node=2        # 2 rangs MPI par nœud
#SBATCH --cpus-per-task=32         # 32 threads OpenMP par rang
#SBATCH --exclusive                # personne d'autre sur les nœuds
#SBATCH --time=00:30:00
#SBATCH --output=%x-%j.out         # nom-du-job-id.out

export OMP_NUM_THREADS=$SLURM_CPUS_PER_TASK
export OMP_PROC_BIND=close
export OMP_PLACES=cores

# Une ligne de traçabilité dans chaque sortie : indispensable
echo "host=$(hostname) date=$(date -Is) commit=$(git rev-parse --short HEAD)"
module list
srun --cpu-bind=cores ./xhpl

Chaque ligne a une raison. --exclusive élimine le bruit des voisins. --cpus-per-task avec OMP_NUM_THREADS cohérent évite le sur-abonnement, qui est la faute la plus fréquente et la plus coûteuse. OMP_PROC_BIND et --cpu-bind fixent les threads sur les cœurs, sans quoi le système les migre et détruit la localité NUMA. La ligne d'écho rend la mesure reproductible.

Exercices

E1 · ★ ⏱ 3 h — Le cluster virtuel. Trois machines virtuelles, un /home partagé par NFS, SSH par clés, Slurm fonctionnel. Soumettre un hostname sur les deux nœuds de calcul et vérifier la sortie. C'est le socle de tous les autres exercices.

E2 · ★★ ⏱ 3 h — Placement et sur-abonnement. Sur votre cluster virtuel ou sur une machine réelle, lancer le même programme OpenMP avec : OMP_NUM_THREADS égal, inférieur puis supérieur au nombre de cœurs alloués ; avec et sans OMP_PROC_BIND ; avec et sans --cpu-bind. Tracer le temps dans les six configurations. Le sur-abonnement doit produire un effondrement net.

E3 · ★★ ⏱ 4 h — Déploiement automatisé. Écrire un playbook Ansible (ou un manifeste Puppet) qui, à partir d'une machine virtuelle vierge, installe et configure un nœud de calcul complet : paquets, utilisateurs, NFS, Slurm, NTP, limites système. Le tester par destruction et reconstruction complète de la machine virtuelle. Critère de réussite : ansible-playbook site.yml deux fois de suite ne change rien la seconde fois (idempotence).

E4 · ★★★ ⏱ 4 h — Surveillance. Installer Prometheus et Grafana sur le nœud maître, avec node_exporter sur les nœuds de calcul. Construire un tableau de bord affichant charge processeur, occupation mémoire, trafic réseau et, si le matériel l'expose, consommation électrique. Lancer un calcul et observer. Pourquoi c'est important : en compétition, on surveille en temps réel pour éviter de dépasser le budget électrique.

E5 · ★★★ ⏱ 3 h — La comptabilité Slurm. Configurer slurmdbd avec une base MariaDB, créer deux comptes et deux QOS avec des priorités et des limites différentes, soumettre une dizaine de travaux et observer l'ordre de passage. Puis interroger sacct pour produire un rapport d'utilisation. C'est la partie que personne n'aime et qui distingue l'administrateur du simple utilisateur.

E6 · ★★★★ ⏱ 6 h — Le diagnostic à l'aveugle. Demander à un camarade de casser quelque chose sur votre cluster virtuel — arrêter un service, changer une route, corrompre un fichier de configuration, désynchroniser l'horloge — et le diagnostiquer sans savoir ce qui a été fait. Chronométrer. Refaire avec les rôles inversés. C'est l'exercice qui prépare le mieux aux quarante-huit heures d'une compétition, où quelque chose casse toujours.

Le piège de l'horloge

Une désynchronisation d'horloge entre nœuds casse Munge, donc Slurm, avec un message d'erreur qui ne parle pas d'horloge. C'est un classique. NTP figure au programme pour cette raison. Quand quelque chose d'incompréhensible se produit sur un cluster, date sur tous les nœuds est dans les trois premières vérifications.

Projet

Projet R3 · Le cluster complet, du métal au benchmark

⏱ 35 h · ★★★★

Sujet. Construire, documenter et mesurer un cluster HPC fonctionnel. Sur matériel réel si vous en avez (quelques machines de récupération, des Raspberry Pi, des instances cloud), sinon en virtuel.

Les sept étapes :

  1. Conception : un document d'architecture de trois pages. Combien de nœuds, quels rôles, quel réseau, quel stockage, quelle authentification, quel budget électrique estimé. Justifier chaque choix.
  2. Déploiement automatisé : PXE et Kickstart si vous êtes sur du métal, sinon des images et Ansible ou Puppet. Contrainte : la reconstruction complète du cluster doit être scriptée et prendre moins d'une heure.
  3. Services : NTP, DNS ou /etc/hosts géré, LDAP ou utilisateurs locaux synchronisés, NFS, Slurm avec comptabilité.
  4. Pile logicielle : compilateur, MPI, BLAS, avec lmod ou Spack pour les environnements. Voir Build et environnement.
  5. Surveillance : Prometheus et Grafana, avec alerte sur au moins une métrique.
  6. Validation par benchmarks : les OSU Micro-Benchmarks pour le réseau, STREAM pour la mémoire, HPL pour le calcul. Comparer le HPL obtenu au pic théorique de vos machines et expliquer l'écart — un HPL à 60-70 % du pic sur un cluster mal réglé, 85-90 % sur un cluster bien réglé, c'est l'ordre de grandeur.
  7. La documentation d'exploitation : un guide utilisateur d'une page et un guide administrateur de trois pages, y compris la procédure de reconstruction après panne.

Critère de réussite : détruire complètement le cluster, le reconstruire depuis vos scripts, et retrouver le même chiffre HPL à 5 % près.

Pourquoi ce projet. Parce que c'est littéralement l'épreuve d'une Student Cluster Competition, et parce que ce projet est le meilleur objet possible à mettre dans un dossier de candidature. Voir Éligibilité et candidature.

Erreurs fréquentes

Sept fautes d'administration qui font perdre des heures

  1. Le sur-abonnement silencieux. --ntasks-per-node=64 et OMP_NUM_THREADS=64 sur un nœud à 64 cœurs, cela fait 4 096 threads. Le code ne plante pas : il rampe. Vérifiez toujours la cohérence entre la demande Slurm et les variables d'environnement.
  2. Oublier --exclusive pour une mesure. Un autre travail sur le même nœud pollue la mesure de façon invisible et non reproductible.
  3. Ne pas fixer les threads. Sans OMP_PROC_BIND ni --cpu-bind, le système migre les threads entre les cœurs et entre les domaines NUMA, détruisant la localité. Perte typique : 20 à 50 % sur un code mémoire.
  4. Croire que le réseau fonctionne parce que ping passe. Un cluster peut avoir un réseau Ethernet fonctionnel et un InfiniBand mal configuré ; MPI retombera silencieusement sur TCP et vous perdrez un facteur dix. Vérifiez avec ib_write_bw et les OSU Micro-Benchmarks, et exigez de MPI qu'il échoue plutôt que de retomber en TCP.
  5. Les horloges désynchronisées. Voir l'encadré ci-dessus.
  6. Une pile logicielle non reproductible. « J'ai compilé OpenMPI à la main en janvier, je ne sais plus avec quelles options. » Spack ou EasyBuild existent pour cela.
  7. Pas de plan de reconstruction. Le jour où un nœud meurt, s'il faut trois heures pour en réinstaller un, la compétition est finie. Tout doit être scripté et testé.

Où ce module s'insère

Se relie à Comment
DEVO35 (S5, tronc commun) Le seul recouvrement FISA : conteneurs, CI/CD, orchestration. Traitez DEVO35 comme la moitié « infrastructure » et ce module comme la moitié « ordonnanceur »
PRPA23 Lancer du MPI sous Slurm avec le bon placement de rangs
R4 · Stockage parallèle Le cluster sans système de fichiers partagé ne sert à rien : les deux modules se font ensemble
Build et environnement Spack, modules, conteneurs — la pile logicielle qu'on installe sur le cluster
Rôles dans l'équipe Le rôle « infrastructure » d'une équipe de compétition, c'est exactement ce module

À retenir

R3 en trois phrases

Aucune UE de la maquette FISA n'enseigne l'administration d'un cluster ni Slurm, alors que c'est le premier geste de toute compétition et de tout accès à un centre de calcul. DEVO35 en donne le réflexe — tout doit être reconstructible par script — mais pas le contenu. C'est le module le moins cher de la liste : quatre machines virtuelles, soixante heures, et un livrable qui se montre.

Module suivant : R4 · Stockage parallèle.