Moyens de calculs avec SLURM

Avant-propos

Slurm est un logiciel libre de gestion des ressources et d’ordonnancement des tâches de calcul. Il permet aux utilisateurs de soumettre leurs calculs, appelés jobs, en précisant les ressources nécessaires : nombre de cœurs, quantité de mémoire, GPU et durée maximale d’exécution.

Slurm organise ensuite l’exécution de ces jobs en fonction des ressources disponibles, des priorités et des règles de partage définies sur le cluster.

Ressources de calcul

Le cluster du laboratoire comprend plusieurs ensembles de nœuds, accessibles au travers de partitions.

Nœuds de calcul CPU

• 6 nœuds de 20 cœurs et 64 Go de mémoire vive chacun ;
• 5 nœuds de 36 cœurs et 192 Go de mémoire vive chacun, reliés par un réseau InfiniBand à 100 Gb/s, permettant notamment d’exécuter des calculs parallèles MPI répartis sur plusieurs nœuds.

Nœuds de calcul GPU

Trois serveurs complètent cette infrastructure pour les calculs nécessitant une accélération GPU :

Suivi des performances

Un système de suivi des performances et de la consommation énergétique permet d’observer en temps réel l’utilisation des ressources par les jobs, afin de mieux comprendre leur comportement et d’optimiser les calculs.

Demande d’accès

Pour utiliser le cluster de calcul, vous devez au préalable demander l’ouverture de votre accès auprès du service informatique du laboratoire.

La frontale

La frontale est la machine depuis laquelle vous soumettez vos jobs à Slurm et suivez leur exécution sur les nœuds de calcul. Celle du laboratoire s’appelle math5.

Pour vous y connecter, ouvrez un terminal et utilisez SSH, en remplaçant username par votre identifiant :

ssh username@math5

Si vous avez besoin d’afficher une application graphique distante, vous pouvez activer le transfert X11 :

ssh -Y username@math5

Cette option nécessite un serveur X fonctionnel sur votre ordinateur.

Important : ne lancez pas de calculs directement sur math5.

Cette machine virtuelle dispose de ressources limitées, partagées entre tous les utilisateurs. Un calcul lancé directement sur la frontale peut la saturer et perturber les connexions ou le travail des autres utilisateurs. Les calculs doivent être exécutés sur les nœuds de calcul, en passant par Slurm.

Les partitions

Dans Slurm, les nœuds de calcul sont regroupés en ensembles appelés partitions. Chaque partition possède ses propres ressources et règles d’utilisation, notamment une durée maximale d’exécution des jobs.

La commande sinfo permet de consulter les partitions et l’état de leurs nœuds :

$ sinfo
PARTITION  AVAIL  TIMELIMIT  NODES  STATE NODELIST
test          up    1:00:00      1 drain* ljad76
single*       up 7-00:00:00      4  idle~ ljad[137-140]
single*       up 7-00:00:00      1    mix ljad136
single*       up 7-00:00:00      1  alloc ljad134
multi         up 7-00:00:00      4  idle~ ljad[142-145]
multi         up 7-00:00:00      1    mix ljad141
amd6000       up 1-00:00:00      1   idle ljad146
intelv100     up 1-00:00:00      1   idle ljad147
quadro6000    up    8:00:00      1   idle ljad148

Partitions disponibles

Lire la sortie de sinfo

• PARTITION : nom de la partition. L’astérisque de single* indique la partition utilisée par défaut.
• AVAIL : état de la partition. up signifie qu’elle est active, sans garantir que ses nœuds soient disponibles immédiatement.
• TIMELIMIT : durée maximale d’un job, au format jours-heures:minutes:secondes.
• NODES : nombre de nœuds concernés par la ligne.
• STATE : état des nœuds.
• NODELIST : noms des nœuds concernés. Par exemple, ljad[137-140] désigne les nœuds ljad137 à ljad140.

Une partition peut apparaître sur plusieurs lignes lorsque ses nœuds sont dans des états différents.

Comprendre l’état des nœuds

Attention : l’astérisque n’a pas la même signification dans PARTITION (partition par défaut) et dans STATE (nœud ne répondant pas).

Dans cet exemple, les trois nœuds des partitions GPU sont libres. Les partitions single et multi comportent des nœuds partiellement occupés et des nœuds en économie d’énergie. Le nœud de la partition test est indisponible.

L’affichage est un instantané : l’état des ressources évolue au fil des soumissions et des fins de jobs.

État et annulation des jobs

Consulter les jobs

La commande squeue affiche les jobs en cours d’exécution ou en attente de ressources :

$ squeue
             JOBID PARTITION     NAME     USER ST       TIME  NODES NODELIST(REASON)
               960    single interact  rruelle  R    3:20:31      1 ljad134

Les colonnes indiquent :

Dans cet exemple, le job 960, soumis par rruelle à la partition single, s’exécute sur ljad134 depuis 3 heures, 20 minutes et 31 secondes.

Pour afficher uniquement vos propres jobs :

squeue -u "$USER"

Annuler un job

La commande scancel, suivie de l’identifiant du job, permet d’annuler un job en attente ou d’arrêter un job en cours d’exécution :

scancel 960

Remplacez 960 par l’identifiant du job à annuler, obtenu avec squeue. Vous ne pouvez annuler que vos propres jobs.

Sessions interactives

Une session interactive permet de travailler directement sur un nœud de calcul depuis un terminal : tester un programme, compiler du code ou lancer des commandes en suivant leur exécution.

Démarrer une session

Connectez-vous à la frontale avec votre identifiant :

ssh username@math5

Demandez ensuite des ressources avec salloc. Par exemple, pour réserver 1 nœud et 4 CPU pour une tâche, pendant 2 heures :

salloc -p single -N 1 -n 1 -c 4 --time=02:00:00

Si les ressources ne sont pas immédiatement disponibles, la demande reste en attente.

Sur le cluster du laboratoire, salloc est configuré pour ouvrir directement un shell sur le nœud attribué. La commande hostname permet de vérifier sur quelle machine vous travaillez :

rruelle@math5:~ $ salloc -p single -N 1 -n 1 -c 4 --time=02:00:00
salloc: Granted job allocation 959
salloc: Waiting for resource configuration
salloc: Nodes ljad134 are ready for job
rruelle@ljad134:~ $ hostname
ljad134

Choisir les ressources

Ne confondez pas -n, -N et -c :

• -N 1 -n 1 -c 4 réserve une tâche disposant de quatre CPU sur un seul nœud, par exemple pour un programme multithread.
• -N 1 -n 4 -c 1 réserve les ressources pour quatre tâches disposant chacune d’un CPU sur un seul nœud, par exemple pour quatre processus MPI.

La réservation des ressources ne rend pas automatiquement un programme parallèle : celui-ci doit être conçu et configuré pour les utiliser.

Définir la durée

Utilisez --time pour préciser la durée souhaitée :

# Session de 2 heures
salloc -p single -N 1 -n 1 --time=02:00:00

# Session de 2 jours
salloc -p single -N 1 -n 1 --time=2-00:00:00

La durée demandée doit respecter la limite de la partition : 7 jours pour single et multi, 24 heures pour amd6000 et intelv100, 8 heures pour quadro6000 et 1 heure pour test.

À l’expiration du temps alloué, la session et les calculs associés sont arrêtés. Prévoyez une durée adaptée et sauvegardez vos résultats régulièrement.

Utiliser des applications graphiques

Connectez-vous à la frontale avec le transfert X11, puis demandez une session avec --x11 :

ssh -Y username@math5

salloc -p single -N 1 -n 1 -c 4 --time=02:00:00 --x11

Un serveur X fonctionnel est nécessaire sur votre ordinateur.

Charger des logiciels

Une fois sur le nœud de calcul, vous pouvez consulter les modules disponibles :

module avail

Chargez ensuite le module souhaité en utilisant le nom affiché, par exemple :

module load miniconda3

Les logiciels et versions disponibles peuvent varier selon le nœud et évoluer dans le temps.

Terminer la session

Lorsque vous avez terminé, quittez le shell du nœud de calcul :

exit

Vous revenez sur la frontale et les ressources sont libérées. Pensez à fermer votre session dès que vous n’en avez plus besoin.

Les scripts de soumission : 

la commande sbatch

Un script de soumission permet d’exécuter un calcul sans maintenir une session interactive ouverte. Une fois le job soumis, vous pouvez vous déconnecter : Slurm se charge de lancer le calcul lorsque les ressources sont disponibles.

Il s’agit d’un script shell contenant des directives destinées à Slurm, sous forme de lignes commençant par #SBATCH. Ces directives doivent être placées avant les premières commandes du script.

Exemple de script MPI

Créez un fichier nommé my_job.slurm :

#!/bin/bash

#SBATCH --job-name=jacobi
#SBATCH --partition=single
#SBATCH --nodes=1
#SBATCH --ntasks=20
#SBATCH --cpus-per-task=1
#SBATCH --time=02:00:00
#SBATCH --output=jacobi-%j.out
#SBATCH --error=jacobi-%j.err
#SBATCH --mail-type=BEGIN,END,FAIL
#SBATCH --mail-user=prenom.nom@exemple.fr

# Charger l'environnement MPI adapté au programme
module purge
module load mpi/mpich-x86_64

# Exécuter le calcul
time mpirun -np "$SLURM_NTASKS" ./jacobi-mpi 700 700

Remplacez l’adresse de notification par la vôtre. Le programme jacobi-mpi doit être accessible depuis le répertoire de travail et avoir été compilé avec une bibliothèque MPI compatible avec le module chargé.

Comprendre les paramètres

Dans cet exemple, le job demande 20 tâches MPI, avec un CPU par tâche, sur un seul nœud de la partition single, pendant au maximum 2 heures.

La variable SLURM_NTASKS, fournie par Slurm, contient le nombre de tâches demandé. Elle est utilisée ici pour préciser à mpirun le nombre de processus à lancer.

Comme pour les sessions interactives, la durée demandée doit respecter la limite de la partition. Par exemple, sur single ou multi, vous pouvez demander jusqu’à sept jours :

#SBATCH --time=7-00:00:00

Cette durée est une limite maximale : si le programme se termine avant, les ressources sont libérées immédiatement.

Demander de la mémoire

La mémoire allouée par défaut dépend de la configuration de la partition. Pour adapter la réservation aux besoins de votre programme, vous pouvez préciser :

• --mem-per-cpu : mémoire demandée par CPU alloué ;
• --mem : mémoire totale demandée par nœud.

Ces deux options ne doivent pas être utilisées ensemble.

Par exemple, pour quatre tâches disposant chacune d’un CPU et de 6 Go de mémoire :

#SBATCH --nodes=1
#SBATCH --ntasks=4
#SBATCH --cpus-per-task=1
#SBATCH --mem-per-cpu=6G

Cela représente une demande totale de 24 Go sur le nœud.

Pour un programme utilisant un seul CPU mais nécessitant beaucoup de mémoire, vous pouvez demander :

#SBATCH --nodes=1
#SBATCH --ntasks=1
#SBATCH --cpus-per-task=1
#SBATCH --mem=24G

Il n’est donc pas nécessaire de réserver davantage de tâches simplement pour demander plus de mémoire. La demande doit toutefois rester compatible avec les ressources du nœud et les limites configurées sur la partition.

Soumettre le job

Depuis la frontale, placez-vous dans le répertoire contenant votre programme et vos données, puis soumettez le script :

$ sbatch my_job.slurm
Submitted batch job 963

Le nombre 963 est l’identifiant du job. Le message confirme sa soumission ; son exécution peut commencer plus tard selon la disponibilité des ressources.

Vous pouvez suivre son état avec :

squeue -u "$USER"

Consulter les résultats

Par défaut, le répertoire de travail est celui depuis lequel vous avez exécuté sbatch.

Avec les directives de l’exemple, les sorties sont écrites dans deux fichiers :

• jacobi-963.out pour la sortie standard ;
• jacobi-963.err pour les messages d’erreur.

Pour consulter la sortie :

cat jacobi-963.out

Pour suivre son évolution pendant le calcul :

tail -f jacobi-963.out

Utilisez Ctrl+C pour arrêter le suivi du fichier : cela n’arrête pas le job. L’affichage peut être différé si le programme conserve ses sorties en mémoire tampon.

Sans directives --output et --error, les deux flux sont regroupés dans un fichier nommé slurm-<JOBID>.out, par exemple slurm-963.out.

Stockage : répertoire personnel et espace scratch

Le répertoire personnel

Votre répertoire personnel (homedir) est accessible depuis chaque nœud de calcul. Il contient vos fichiers et est partagé avec les autres services du laboratoire.

Son utilisation pour les calculs présente toutefois plusieurs contraintes :

• Le quota de stockage, qui limite le volume de données que vous pouvez conserver.
• L’authentification Kerberos : les tickets ont une durée de validité de 24 heures et sont renouvelables pendant une semaine. Leur expiration peut empêcher les accès aux fichiers et perturber les calculs en cours. Le renouvellement n’est pas implicite.
• Le partage du réseau et du stockage avec les autres services : des lectures et écritures intensives peuvent affecter leurs performances.

L’espace scratch

Un espace de stockage BeeGFS, accessible dans /scratch, est destiné aux données de travail des calculs.

Avant la première utilisation, demandez au service informatique la création de votre espace personnel :

/scratch/<username>/

Cet espace permet de travailler sans les contraintes de quota et de tickets Kerberos du répertoire personnel, tout en évitant de solliciter la baie de stockage générale.

Organiser les fichiers d’un calcul

Pour chaque job, utilisez un répertoire de travail distinct, par exemple :

/scratch/<username>/my_job_dir/

Le déroulement conseillé est le suivant :

1. Copier le programme et les données nécessaires depuis votre répertoire personnel vers ce répertoire de travail.
2. Exécuter le calcul dans /scratch, en y écrivant également les fichiers temporaires et les résultats.
3. Recopier les résultats à conserver vers votre répertoire personnel à la fin du calcul.
4. Nettoyer le répertoire de travail après avoir vérifié la bonne récupération des résultats.

Ces étapes peuvent être intégrées au script de soumission .slurm.

Attention aux calculs longs : la copie finale vers le répertoire personnel nécessite encore un accès Kerberos valide. Si les tickets ont expiré, conservez les résultats dans /scratch et effectuez leur récupération après avoir rétabli votre accès.

Utilisation de Conda et Miniforge

Les environnements Conda peuvent être utilisés aussi bien en session interactive que dans un script de soumission Slurm.

Charger Conda

Sur le nœud de calcul, chargez le module :

module load miniconda3

Si l’activation d’un environnement affiche un message demandant d’exécuter conda init, initialisez Conda pour le shell courant.

Avec Bash :

eval "$(conda shell.bash hook)"

Avec Zsh :

eval "$(conda shell.zsh hook)"

Activez ensuite votre environnement, en remplaçant mon_environnement par son nom :

conda activate mon_environnement

Utilisation dans un script de soumission

Dans un script commençant par #!/bin/bash, utilisez l’initialisation pour Bash, même si votre shell interactif habituel est Zsh.

Après les directives #SBATCH, ajoutez :

module load miniconda3
eval "$(conda shell.bash hook)"
conda activate mon_environnement

python mon_programme.py

L’environnement doit avoir été créé au préalable et être accessible depuis le nœud de calcul. Pensez à l’activer explicitement dans chaque script de soumission.

Miniforge

La distribution Miniforge3 est également disponible. Elle permet d’utiliser les environnements Conda avec le canal conda-forge, configuré par défaut, ainsi que Mamba dans la distribution proposée au laboratoire.

Consultez le wiki consacré à Miniforge pour les instructions d’utilisation.

Commandes utiles

Consulter les détails d’un job

La commande scontrol show job affiche les caractéristiques d’un job : état, ressources demandées ou allouées, durée, nœuds utilisés et répertoire de travail.

scontrol show job <JOB_ID>

Remplacez <JOB_ID> par l’identifiant obtenu lors de la soumission ou avec squeue.

Par exemple :

scontrol show job 974

Voici un extrait illustratif des informations affichées :

JobId=974 JobName=interactive
   JobState=RUNNING Reason=None
   RunTime=00:00:17 TimeLimit=7-00:00:00
   Partition=single
   NodeList=ljad134
   NumNodes=1 NumCPUs=1 NumTasks=1 CPUs/Task=1
   TRES=cpu=1,mem=3200M,node=1,billing=1
   WorkDir=/home/rruelle

Les principaux champs à consulter sont :

Dans cet exemple, le job s’exécute sur ljad134, dans la partition single, avec un CPU et 3 200 Mio de mémoire allouée. Cette valeur décrit la réservation mémoire, pas la consommation réelle du programme.

Analyser un job terminé avec seff

La commande seff fournit un bilan de l’utilisation des ressources d’un job après son exécution :

seff <JOB_ID>

Par exemple :

seff 963

Extrait illustratif :

State: COMPLETED (exit code 0)
Nodes: 1
Cores per node: 4
CPU Utilized: 02:00:00
CPU Efficiency: 50.00% of 04:00:00 core-walltime
Job Wall-clock time: 01:00:00
Memory Utilized: 8.00 GB
Memory Efficiency: 33.33% of 24.00 GB

Comprendre les résultats

Dans cet exemple, le job a réservé 4 CPU pendant une heure d’exécution, soit 4 heures CPU disponibles. Il en a consommé 2 : son efficacité CPU est donc de 50 %. Ce calcul utilise la durée réelle d’exécution, pas la limite définie par --time.

Ajuster les prochaines réservations

• Une faible efficacité CPU peut indiquer un nombre excessif de CPU réservés, un programme peu parallélisé ou du temps passé à attendre des lectures, écritures ou communications.
• Une utilisation mémoire très inférieure à la réservation peut permettre de réduire la mémoire demandée, en conservant une marge pour les variations entre calculs.
• Une durée proche de la limite autorisée peut justifier d’augmenter --time pour les prochaines exécutions.

Utilisez seff une fois le job terminé : les données d’un job encore actif peuvent être incomplètes.

Les mesures mémoire restent des estimations, notamment pour les jobs MPI ou comportant plusieurs étapes. Enfin, l’efficacité CPU ne mesure pas l’utilisation des GPU : un job GPU peut présenter une faible activité CPU tout en exploitant correctement ses accélérateurs.

Métrologie et profilage

Le cluster dispose d’un environnement de suivi des performances et de la consommation énergétique, accessible depuis une interface web Grafana :

Accéder à Grafana

Cet outil permet de suivre vos jobs en temps réel, de consulter leur consommation énergétique et une estimation des émissions de CO₂ associées.

Outils utilisés

L’environnement repose sur plusieurs outils complémentaires :

Les émissions affichées sont des estimations, dépendantes des données et des hypothèses utilisées pour convertir la consommation électrique en émissions de CO₂.

Activer le profilage

Le profilage permet d’analyser plus finement l’exécution d’un programme afin d’identifier les parties du code qui consomment du temps de calcul.

Pour l’activer, chargez le module profiler avant de lancer votre programme, dans votre session interactive ou dans votre script de soumission :

module load profiler

Dans un script .slurm, placez cette commande après les directives #SBATCH et avant la commande exécutant le calcul.

Le surcoût du profilage est estimé entre 4 et 5 % sur le cluster, avec des variations possibles selon le programme. Son activation est donc facultative : utilisez-le pour analyser ou optimiser un calcul, lorsque ce niveau de détail est nécessaire.

Le suivi énergétique dans Grafana reste distinct de cette activation du profilage.

Pour en savoir plus : projet CEEMS.

Économie d’énergie

Afin de réduire la consommation électrique du cluster, les coûts associés et son impact environnemental, les nœuds de calcul inutilisés depuis 10 minutes sont automatiquement éteints.

Slurm les rallume automatiquement lorsque des jobs nécessitent leurs ressources. Aucune intervention de votre part n’est nécessaire.

Un délai supplémentaire peut donc s’ajouter avant le démarrage d’un job, le temps que le serveur démarre et soit prêt à exécuter le calcul.

Dans la sortie de sinfo, les nœuds libres placés en économie d’énergie apparaissent avec l’état idle~. Cet état est normal et ne signale pas une panne.