Skip to main content

Moyens de calculs avec SLURM

Avant-propos

 

SLURM est un logiciel open source d’ordonnancement de tâches informatiques. Il permet de créer des systèmes qui géreront les tâches que les utilisateurs lui soumettent en respectant des règles de placement optimal et de réservation des ressources. 

SLURM est actuellement utilisé par 60% des machines du Top 500. Il s'agit donc d'une solution largement connue, robuste et soutenue par sa large communauté. 

Actuellement, ce système est utilisable sur un cluster comportant plusieurs partitions : 

  • 6 nœuds de 20 cores et 64GB de ram par nœud.
  • 5 nœuds de 36 cores et 192GB de ram par nœud. Cet ensemble de nœuds permet également la soumission de jobs MPI sur plusieurs nœuds, grâce à une connexion Infiniband 100Gb/s.

Un système de métrologie énergétique et de performance est également installé. Il permet de réaliser du profiling temps réel sur les jobs.

Demande d'accès

Pour accéder au cluster de calcul la première fois, il est nécessaire de faire une demande d'accès auprès du service informatique du laboratoire. 

 

La frontale

 

Pour soumettre ses tâches à SLURM, il faut se connecter sur une machine particulière qui ne servira qu'à communiquer avec les machines de calculs. La frontale s'appelle math5.

Typiquement, pour s'y connecter, on peut utiliser ssh. 

ssh username@math5

ou 

ssh -Y username@math5 (avec support graphique)

IMPORTANT : math5 est une machine virtuelle. Elle n'est aucunement destinée à lancer des calculs. Une tâche lancée directement sur cette machine peut entraîner une impossibilité pour les autres utilisateurs de se connecter et/ou de l'utiliser dans de bonnes conditions.

 

Les partitions

 

Dans SLURM, les ressources de calculs sont regroupées en des ensembles appelés "partitions". 

On peut avoir des informations sur l'état actuel des partitions via la commande sinfo. 

[25-07-02 10:24:26]rruelle@math5:/home/rruelle $ sinfo
PARTITION AVAIL  TIMELIMIT  NODES  STATE NODELIST
test         up    1:00:00      1   idle ljad76
math5*       up 7-00:00:00      1    mix ljad134
math5*       up 7-00:00:00      6   idle ljad[135-140]

Ici, on voit qu'il y a deux partitions : "test" et "math5". Chacune étant composée d'un ou plusieurs nœuds. On voit ainsi que le noeud ljad134 est en partie occupé ("mix") et que les noeuds 135 à 140 sont libres ("idle")

 

 

Etat et opérations sur les travaux soumis

 

La commande squeue permet de voir l'état actuel des travaux et, le cas échéant, des files d'attente 

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

La commande scancel permet d'annuler un travail 

rruelle@math5:/home/rruelle $ scancel 960

Pour ne voir que ses travaux : 

$ squeue -u $USER
            JOBID PARTITION     NAME     USER ST       TIME  NODES NODELIST(REASON)
              974     math5 interact  rruelle  R      40:30      1 ljad134

 

 

 

Sessions interactives

 

Voici un exemple de connexion à la frontale et de démarrage d'une session interactive :

$ ssh rruelle@math5
Last login: Thu Jul  3 15:30:49 2025 from 134.59.10.78


*********************************
*   Bienvenue sur la frontale   *
*  SLURM des moyens de calculs  *
*           du LJAD             *
*********************************

     1ere regle de la frontale :
-> On ne calcule pas sur la frontale <-

État des partitions (sinfo)
PARTITION AVAIL  TIMELIMIT  NODES  STATE NODELIST
test         up    1:00:00      1   idle ljad76
math5*       up 7-00:00:00      7   idle ljad[134-140]

Quelques rappels :
* Pour faire afficher les modules disponibles sur les noeuds
  depuis la frontale : module_avail

* Pour se connecter en interactif sur une partition :
  salloc -p math5 -n 16
  (ici on reserve 16 cores sur la partition math5)

* Pour soumettre un script batch :
  sbatch monjob.sbatch


rruelle@math5:/home/rruelle $ salloc -n 4
salloc: Granted job allocation 959
salloc: Waiting for resource configuration
salloc: Nodes ljad134 are ready for job
rruelle@ljad134:/home/rruelle $ hostname
ljad134

Comme on peut le voir, il convient d'utiliser la commande salloc. Ainsi 

salloc -n 4

demande à SLURM de réserver 4 cores sur un nœud de calcul et de démarrer un shell sur celui-ci. On entre alors directement sur le shell d'un nœud de calcul et on peut lancer des commandes: dans l'exemple, la commande hostname. 

ATTENTION, NE PAS CONFONDRE -n et -N. 

  • -n est équivalent à --ntasks qui est le nombre total de tâches
  • -N est équivalent à --nodes qui est le nombre minimum de noeuds à allouer à ce job.

Pour choisir une partition : 

 -p, --partition=<partition>

Pour activer le déport X :

rruelle@math5:/home/rruelle $ salloc -n 4 --x11

Par défaut, le temps d'un travail est fixé à 12h00. Pour en obtenir davantage (jusqu'à 7 jours), on peut utiliser le paramètre --time

$ salloc -n 1 --time 02:00:00

pour obtenir 2h.

$ salloc -n 1 --time 2-00:00:00

pour obtenir 2 jours. 

 

On peut ensuite travailler comme dans un environnement classique. On peut charger des modules. Exécuter ou compiler des codes etc. 

rruelle@ljad134:/home/rruelle $ module avail
----------------------------------------------------------------------------------- /srv/modules ------------------------------------------------------------------------------------
cmake-4.0.3  FreeFem-4.15-gnu-mpich  miniconda3  
--------------------------------------------------------------------------- /opt/intel/oneapi/modulefiles ---------------------------------------------------------------------------
advisor/2025.2                compiler-rt/2025.1.1  dal/latest              dnnl/3.8.1     intel_ipp_intel64/2022.1    mkl/2025.1   tbb/latest    
advisor/latest                compiler-rt/2025.2.0  debugger/2025.1.0       dnnl/latest    intel_ipp_intel64/2022.2    mkl/2025.2   umf/0.10.0    
ccl/2021.15.2                 compiler-rt/latest    debugger/2025.2.0       dpct/2025.1.0  intel_ipp_intel64/latest    mkl/latest   umf/0.11.0    
ccl/2021.16.0                 compiler/2025.1.1     debugger/latest         dpct/2025.2.0  intel_ippcp_intel64/2025.1  mpi/2021.15  umf/latest    
ccl/latest                    compiler/2025.2.0     dev-utilities/2025.1.0  dpct/latest    intel_ippcp_intel64/2025.2  mpi/2021.16  vtune/2025.4  
compiler-intel-llvm/2025.1.1  compiler/latest       dev-utilities/2025.2.0  dpl/2022.8     intel_ippcp_intel64/latest  mpi/latest   vtune/latest  
compiler-intel-llvm/2025.2.0  dal/2025.5            dev-utilities/latest    dpl/2022.9     ishmem/1.3.0                tbb/2022.1   
compiler-intel-llvm/latest    dal/2025.6            dnnl/3.7.3              dpl/latest     ishmem/latest               tbb/2022.2  
-------------------------------------------------------------------------- /usr/share/Modules/modulefiles ---------------------------------------------------------------------------
dot  module-git  module-info  modules  null  use.own  
------------------------------------------------------------------------------ /usr/share/modulefiles -------------------------------------------------------------------------------
mpi/mpich-x86_64  
Key:
modulepath

 

 

Les scripts de soumission 
La commande sbatch

 

Une autre façon de travailler avec slurm est de rédiger un script de soumission. Il s'agit en réalité d'un script shell auquel sont ajoutés quelques instructions à destination de SLURM, sous la forme de lignes commençant par #SBATCH

Voici un exemple d'un tel script : 

$ cat my_job.slurm 
#!/bin/bash

#SBATCH -n 20
#SBATCH --mail-type=begin,end
#SBATCH --mail-user=rruelle@unice.fr

# Il faut charger un module MPI
module purge
module load mpi/mpich-x86_64

time mpirun ./jacobi-mpi 700 700

Explications : 

#SBATCH -n 20

permet de réserver 20 cores. 

Les lignes : 

#SBATCH --mail-type=begin,end
#SBATCH --mail-user=rruelle@unice.fr

permettent de recevoir un mail en début et en fin d’exécution du code. 

Autres paramètres utiles : 

  • -J ou --job-name ="Nom_du_job"
  • -o ou --output ="Nom_du_fichier_de_sortie_standard"
  • -e ou --error ="Nom_du_fichier_de_sortie_d'erreur"

et, comme pour les sessions interactives, le paramètre --time permet de fixer le temps du travail (jusqu'à 7 jours)

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

permet de réserver une semaine pour un travail.

Ensuite, on charge les modules nécessaires s'il y a lieu, et on exécute le code. C'est ce que fait la commande mpirun si on lance un job MPI. 

Par défaut, la mémoire réservée pour chaque core suit la règle : quantité total de ram du nœud / nombre de core du nœuds. 

Pour la partition math5, cela donne 64 GB / 20. Soit à peu près 3 GB par core. 

Si une tâche sur un core a besoin de davantage de ram, il faut diminuer le nombre de tâches sur le nœud et allouer plus de ram. 

cela se fait avec 

#SBATCH --mem-per-cpu=6G

par exemple. 

Une fois le script finalisé, on peut soumettre le travail. 

$ sbatch job3.slurm 
Submitted batch job 963

Une fois le travail terminé, (et même en cours de travail) on peut consulter les sorties du programme dans un fichier nommé slurm-<JOB_ID>.out' par 'Une fois le travail terminé, (et même en cours de travail) on peut consulter les sorties du programme dans un fichier nommé par défaut  slurm-<JOB_ID>.out. Mais si les variables output et error sont définies dans le script, les sorties seront alors écrites dans les fichiers correspondants.

e.g. : 

$ cat slurm-963.out
[....]

 

 

 

Stockage
Espace de scratch

 

Sur chaque nœud de calcul, on a accès à son répertoire utilisateur, le homedir. C'est le repertoire contenant les données utilisateurs partagés sur l'ensemble des services. 

Il existe également un espace de stockage spécifique de type BeeGFS dans /scratch. 

Avant la première utilisation : il faut pour cela demander sa création au service informatique. 

L'avantage d'utiliser le répertoire /scratch est de ne pas être soumis à plusieurs contraintes des homedir:

  • quota
  • durée de vie des tickets kerberos (qui une fois expiré empêche la bonne continuation d'un travail - ceux-ci ayant une durée de vie de 24h renouvelable pendant une semaine)
  • ne pas saturer le lien réseau vers la baie de stockage générale. 

Une bonne pratique, par exemple, serait de prévoir une copie du code à exécuter vers le répertoire /scrath/<username>/my_job_dir/ dans le fichier .slurm puis de copier les résultats vers le homedir en fin d’exécution. 

 

Usage de conda / miniconda

 

Comme mentionné plus haut, l'usage des environnements conda est possible que ce soit en mode interactif ou en batch. 

On prendra soin de charger préalablement le module miniconda3

$ module load miniconda3

Si ensuite l'utilisation de conda reste impossible (la commande conda réclame l'usage de conda init) 

On peut simplement copier cette commande : 

eval "$(conda shell.zsh hook)"

en faisant l'hypothèse que le shell courant est zsh. Sinon, il convient de remplacer zsh par bash dans la commande ci-dessus.

 

La distribution miniforge3 est également disponible permettant par défaut l'utilisation de la commande mamba et de l'utilisation de conda-forge. Un wiki spécifique est disponible. 

 

Commandes utiles

 

# scontrol show job <JOB_ID>

Permet d'avoir des informations détaillées concernant un job

e.g. :

# scontrol show job 974
JobId=974 JobName=interactive
   UserId=rruelle(23143) GroupId=com(900) MCS_label=N/A
   Priority=4294901716 Nice=0 Account=(null) QOS=(null)
   JobState=RUNNING Reason=None Dependency=(null)
   Requeue=1 Restarts=0 BatchFlag=0 Reboot=0 ExitCode=0:0
   RunTime=00:00:17 TimeLimit=7-00:00:00 TimeMin=N/A
   SubmitTime=2025-07-07T15:27:31 EligibleTime=2025-07-07T15:27:31
   AccrueTime=Unknown
   StartTime=2025-07-07T15:27:31 EndTime=2025-07-14T15:27:31 Deadline=N/A
   SuspendTime=None SecsPreSuspend=0 LastSchedEval=2025-07-07T15:27:31 Scheduler=Main
   Partition=math5 AllocNode:Sid=localhost:85609
   ReqNodeList=(null) ExcNodeList=(null)
   NodeList=ljad134
   BatchHost=ljad134
   NumNodes=1 NumCPUs=1 NumTasks=1 CPUs/Task=1 ReqB:S:C:T=0:0:*:*
   TRES=cpu=1,mem=3200M,node=1,billing=1
   Socks/Node=* NtasksPerN:B:S:C=0:0:*:* CoreSpec=*
   MinCPUsNode=1 MinMemoryCPU=3200M MinTmpDiskNode=0
   Features=(null) DelayBoot=00:00:00
   OverSubscribe=OK Contiguous=0 Licenses=(null) Network=(null)
   Command=(null)
   WorkDir=/home/rruelle
   Power=

 

 

Métrologie

 

Un environnement de métrologie est installé sur le cluster. Il permet, pour tous les utilisateurs de se connecter sur une interface web 'Grafana', pour suivre ses travaux, leur consommations énergétiques et une estimation des émissions de CO2 en temps réel. Il permet également d'utiliser un outil de profiling temps réel. 

Il s'agit d'un ensemble de serveurs et d'outils utilisant : 

  • Grafana
  • Prometheus
  • Pyroscope
  • CEEMS - Compute Energy & Emissions Monitoring Stack
    Pile logicielle opensource utilisée par l'Idris - Jean ZAY : https://github.com/ceems-dev/ceems

Pour se connecter à ce service : 

https://math.univ-cotedazur.fr/grafana

NB : Pour activer le profiling, il faut charger le module "profiler". Il y a un overhead estimé entre 4 et 5% pour les jobs suivis. On peut donc l'activer ou non en fonction des besoins. 

 

 

Sauvegarde énergétique

 

Afin de mieux maîtriser l'impact environnemental et les coûts énergétiques associés au cluster, la politique suivante est appliquée :

un nœud de calcul non utilisé depuis 10 minutes s'éteint automatiquement. Il est automatiquement rallumé si son usage est nécessaire pour recevoir la soumission de travaux. Il est donc normal qu'un laps de temps soit nécessaire, dû à l'allumage du serveur, avant que la travail soit effectivement démarré. 

 

 

 

calcul
informatique