Stargate est le cluster de calcul de haute performance du centre de calcul du LERIA. Il s'agit d'un ensemble de 27 serveurs de calcul comptabilisant 700 cœurs CPU et 3 GPU. Nous disposons également d'un stockage haute performance beegfs distribué sur 5 serveurs de stockage. L'ensemble de ces serveurs sont connectés entre eux via un réseau redondant à très haut débit et à très faible latence. Les services indispensables au bon fonctionnement de notre cluster de calcul sont hébergés sur le pool proxmox de notre centre de calcul. Nous avons choisi Debian comme système d'exploitation pour tout nos serveurs et slurm pour notre logiciel de soumission de job.

Par ordre de priorité suivante:

1. Tous les membres et membres associés du laboratoire LERIA,
2. Les enseignants chercheurs de l'Université d'Angers s'ils ont eu l'autorisation préalable du directeur du LERIA,
3. Des chercheurs invités s'ils ont eu l'autorisation préalable du directeur du LERIA.

• Pour obtenir l'accès au cluster, il suffit de demander l'activation de son compte en envoyant un email à technique (at) info.univ-angers.fr

Voir aussi Stockage des données

L'architecture logicielle de soumissions de taches s’appuie sur l'outil Slurm. Slurm est un système de planification et de gestion de grappes open source, tolérant aux pannes et extrêmement évolutif, conçu pour les clusters Linux. Au sens de Slurm, les nœuds (serveurs) de calculs sont nommés nodes, et ces nœuds sont regroupés en famille appelée partition (qui n'ont rien à voir avec la notion de partition qui segmente un périphérique de stockage de masse)

Notre cluster dispose de 5 partitions nommées :

• gpu
• intel-E5-2695
• ram
• amd
• std

Chacune de ces partitions contient des nœuds.

Les nœuds de calcul fonctionnent avec un système d'exploitation debian stable. Vous pouvez trouvez la liste des logiciels installés dans la section listes des logiciels installés pour le calcul haute performance.

Veuillez effectuer une demande à technique [at] info.univ-angers.fr pour obtenir les informations de connexion au cluster.

Slurm (Simple Linux Utility for Ressource Management) est un planificateur (scheduler) de tâches. Slurm détermine où et quand sont distribués les calculs sur les différents nœuds de calcul en fonction:

• de la charge actuelle de ces serveurs de calcul (CPU, Ram, …)
• de l'historique des utilisateurs (notion de fairshare, un utilisateur utilisant peu le cluster sera prioritaire par rapport à un utilisateur utilisant beaucoup le cluster)

Il est fortement conseillé de lire cette documentation avant d'aller plus loin.

Une fois connecté, vous pouvez taper la commande sinfo qui vous renseignera sur les partitions disponibles et leurs nœuds associés :

username_ENT@stargate:$ sinfo
PARTITION      AVAIL  TIMELIMIT  NODES  STATE NODELIST
gpu                 up 14-00:00:0      2   idle star[242,254]
intel-E5-2695       up 14-00:00:0      1   idle star245
amd-opteron-4184    up 14-00:00:0      5   idle star[190-194]
std*                up 14-00:00:0      6   idle star[190-194,245]
ram                 up 14-00:00:0      1   idle star243
username_ent@stargate:~$

Il existe principalement deux façons de soumettre des jobs à Slurm :

• Exécution interactive, (via la commande srun).
• Exécution en mode batch, (via la commande sbatch).

L'exécution en mode batch est présentée plus loin dans ce wiki.

Afin de soumettre un job à slurm, il suffit de préfixer le nom de l'exécutable avec la commande srun.

Afin de bien comprendre la différence entre un processus pris en charge par l'os de stargate et un processus pris en charge par slurm, on pourra par exemple taper les deux commandes suivantes:

username_ENT@stargate:~$ hostname
stargate
username_ENT@stargate:~$ srun hostname
star245
username_ENT@stargate:~$

Pour la première commande, le retour de hostname donne stargate alors que la seconde commande srun hostname renvoie star245. star245 correspond au nom de la machine qui a été désignée dynamiquement par slurm pour l'exécution de la commande hostname.

On pourra aussi taper les commandes srun free -h ou bien srun cat /proc/cpu_info afin d'en savoir plus sur les nœuds d'une partition.

Chaque fois que l'exécution d'une tache est réclamée à slurm, celui-ci la place dans un fil d'exécution aussi appelé queue. La commande squeue vous permet de connaître la liste des taches en cours de traitements. C'est un peu l'équivalent de la commande GNU/linux ps aux ou ps -efl mais pour les jobs du cluster plutôt que les processus. On pourra tester cette commande en lançant par exemple d'un coté srun sleep infinity &. Pendant l'exécution de cette tache, la commande squeue donnera :

username_ENT@stargate:~$ squeue 
           JOBID PARTITION     NAME     USER ST       TIME  NODES NODELIST(REASON)
             278 intel-E5-     sleep username  R       0:07      1 star245

Il est possible de tuer cette tache via la commande scancel avec comme argument l'identifiant du job

username_ENT@stargate:~$ scancel 278
username_ENT@stargate:~$ srun: Force Terminated job 332
srun: Job step aborted: Waiting up to 32 seconds for job step to finish.
slurmstepd: error: *** STEP 332.0 ON star245 CANCELLED AT 2018-11-27T11:42:06 ***
srun: error: star245: task 0: Terminated

[1]+  Termine 143             srun sleep infinity
username_ENT@stargate:~$

Pour aller plus loin, vous pouvez regardez cette série de vidéo de présentation et d'introduction à slurm (en 8 parties):

<html> <center> <iframe width=“500” height=“281” src=“https://www.youtube.com/embed/NH_Fb7X6Db0?list=PLZfwi0jHMBxB-Bd0u1lTT5r0C3RHUPLj-” frameborder=“0” allow=“autoplay; encrypted-media” allowfullscreen></iframe> </center> </html>

Vous trouverez ici la documentation officielle de slurm.

La machine Stargate n'est pas un nœud de calcul: c'est un nœud à partir duquel vous soumettez vos calculs sur des nœuds de calcul. On dit que stargate est un nœud maître. Par conséquent, on compilera les codes sources sur les nœuds de calcul en préfixant la compilation avec la commande srun.

Regardons le fichier suivant nommé main.cpp :

#include <iostream>
 
int main() {
    std::cout<<"Hello world!"<<std::endl;
    return 0;
}

On pourra le compiler en utilisant un des nœuds de la partition intel-E5-2695 via la commande :

username_ENT@stargate:~$ srun --partition=intel-E5-2695 g++ -Wall main.cpp hello

username_ENT@stargate:~$ srun g++ -Wall main.cpp hello

Finalement, on pourra exécuter ce programme fraichement compilé avec

user@stargate:~$ srun -p intel-E5-2695 ./hello

La plupart du temps, une exécution interactive ne vous intéressera pas, vous préférerez et vous devez utiliser la soumission d'un job en mode batch (traitement par lot). L’exécution interactive peut-être intéressante pour la compilation ou pour du “débuguage”.

• C'est dans ce mode que l'on utilise un cluster de calcul pour l'exécution de ses processus
• Vous devez rédiger un script de soumission, celui ci contient 2 sections:
  • Les ressources que vous souhaitez utiliser
    • Les variables destinés à slurm sont précédées par #SBATCH
  • Les commandes nécessaires pour exécuter le programme

#!/bin/bash
# hello.slurm
#SBATCH --job-name=hello
#SBATCH --output=hello.out
#SBATCH --error=hello.err
#SBATCH --mail-type=end
#SBATCH --mail-user=user@univ-angers.fr
#SBATCH --nodes=1
#SBATCH --ntasks-per-node=1
#SBATCH --partition=intel-E5-2695
/path/to/hello && sleep 5

user@stargate:~$ sbatch hello.slurm     # Soumission du job
user@stargate:~$ squeue                 # Place et état des jobs dans la queue de soumission
user@stargate:~$ cat hello.out          # Affiche ce qu'aurait affiché la sortie standard en mode interactif (resp. hello.err pour la sortie d'erreur)

Très souvent, on souhaite exécuter un seul et même programme pour un ensemble de fichier ou un ensemble de parametres, dans ce cas, il y a 2 solutions à privilégier:

• Utiliser un array job (facile à utiliser, c'est la solution à privilégier).
• Utiliser les steps job (plus complexe à mettre en œuvre).

Slurm est un planificateur de tâches. La planification est un problème d'optimisation difficile et gourmand en ressources. Il est beaucoup plus facile pour un planificateur de planifier des jobs dont il connaît:

• sa durée
• les ressources à utiliser (CPU, Mémoire)

De fait, il a été définit des ressources par défaut:

• la durée d'un job est de 20 minutes
• la mémoire disponible par CPU est de 200 Mo

Il est tout a fait possible de surcharger ces valeurs par défaut avec les options –mem-per-cpu et –time. Toutefois,

Voir aussi politique d'utilisation et stockage des données.

Par défaut le quota d'espace disque est limité à 50Go. Vous pouvez facilement savoir quels sont les fichiers qui vous prennent le plus de place grâce à la commande:

user@stargate ~ # ncdu

Voir aussi architecture globale.

• Le cluster de calcul utilise un pool de serveurs de stockages distribués beegfs . Ce stockage beegfs est indépendant des serveurs de calcul. Cette zone de stockage est accessible naturellement dans l’arborescence de n'importe quel nœud de calcul sous /home/$USER. Étant donné que ce stockage est distant, toute lecture/écriture dans votre home est dépendante du réseau. Notre stockage Beegfs et le réseau sous-jacent sont très performant, mais pour certains traitement lourd, vous gagneriez peut-être à vous servir des disques locaux des serveurs de calcul. Pour ce faire, vous pouvez utiliser le répertoire /local_working_directory des serveurs de calculs. Ce répertoire fonctionne de la même manière que /tmp à la différence que les données sont persistante en cas de redémarrage du serveur.

• Si vous souhaitez créer des groupes, merci d'envoyer un email à technique.info [at] listes.univ-angers.fr avec le nom du groupe et les utilisateurs associés.

• Pour rappel, par défaut, les droits de votre home sont définis à 755, donc tout le monde peut lire et exécuter vos données.

Vous devriez commencer par lire la documentation officielle. Cette page présente des cas d'utilisations intéressants.

Si vous avez un grand nombre de fichier ou de parametres à traiter avec un seul exécutable, vous devez utiliser un array job.

C'est facile à mettre en œuvre, il suffit de rajouter l'option –array à notre script batch:

Il est facile d'utiliser les array jobs pour faire des test paramétrique. C'est à dire, utiliser le même exécutable, éventuellement sur un même fichier, mais en faisant varier un paramètre en options de l’exécutable. Pour cela, si les paramètres sont contigus ou régulier, on utilisera un batch comme celui-ci:

#!/bin/bash
#SBATCH -J Job_parametre_régulier
#SBATCH -N 1
#SBATCH --ntasks-per-node=1
#SBATCH -t 10:00:00
#SBATCH --array=0-9     
#SBATCH -p intel-E5-2670
#SBATCH -o %A-%a.out
#SBATCH -e %A-%a.err
#SBATCH --mail-type=end,fail
#SBATCH --mail-user=username@univ-angers.fr
/path/to/exec --optionParamExec $SLURM_ARRAY_TASK_ID 

L'options –array peut prendre des syntaxes particulières, pour des valeurs irrégulières ou pour des sauts de valeurs:

# Valeurs irrégulières 0,3,7,11,35,359
--array=0,3,7,11,35,359
 
# Valeur séparé par des sauts de +2: 1, 3, 5 et 7
--array=1-7:2

Il est courant de devoir exécuter un programme de nombreuses fois sur de nombreuses instances (benchmark).

Soit l'arborescence suivante:

job_name
├── error
├── instances
│   ├── bench1.txt
│   ├── bench2.txt
│   └── bench3.txt
├── job_name_exec
├── output
└── submit_instances_dir.slurm

Il est facile d'utiliser un array job pour exécuter job_name_exec sur l'ensemble des fichiers à traiter dans le répertoire instances. Il suffit d'éxécuter la commande suivante:

mkdir error output 2>/dev/null || sbatch --job-name=$(basename $PWD) --array=0-$(($(ls -1 instances|wc -l)-1)) submit_instances_dir.slurm

avec le batch submit_instances_dir.slurm suivant:

#!/bin/bash
 
#SBATCH --mail-type=END,FAIL
#SBATCH --mail-user=YOUR-EMAIL
#SBATCH -o output/%A-%a
#SBATCH -e error/%A-%a
 
#INSTANCES IS ARRAY OF INSTANCE FILE
INSTANCES=(instances/*)
 
./job_name_exec ${INSTANCES[$SLURM_ARRAY_TASK_ID]}

Parfois il faut lancer plusieurs fois l'exécution sur une instance en modifiant la graine qui permet de générer des nombres aléatoire.

Soit l'arborescence suivante:

job_name
├── error
├── instances
│   ├── bench1.txt
│   ├── bench2.txt
│   └── bench3.txt
├── job_name_exec
├── output
├── submit_instances_dir_with_seed.slurm
└── submit.sh

Il suffit d’exécuter la commande suivante:

./submit.sh

avec le fichier submit.sh suivant (pensez à modifier la variable NB_SEED):

#!/bin/bash
 
readonly NB_SEED=50
 
for instance in $(ls instances)
do
  sbatch --output output/${instance}_%A-%a --error error/${instance}_%A-%a --array 0-${NB_SEED} submit_instances_dir_with_seed.slurm instances/${instance}
done
exit 0

et le batch submit_instances_dir_with_seed.slurm suivant:

#!/bin/bash
#SBATCH --mail-type=END,FAIL
#SBATCH --mail-user=YOUR-EMAIL
 
echo "####### INSTANCE: ${1}"
echo "####### SEED NUMBER: ${SLURM_ARRAY_TASK_ID}"
echo
srun echo nomApplication ${1} ${SLURM_ARRAY_TASK_ID}

Avec cette méthode, la variable SLURM_ARRAY_TASK_ID contient la graine. Et vous soumettez autant de array job que ce qu'il y a d'instance dans le répertoire instance. Vous retrouvez facilement vos sortie qui sont nommées comme ceci:

output/nom_instance-ID_job-graine 

Vous pouvez déterminer des dépendances entre jobs via l'options –depend de sbatch:

# Attendre que certains du job array soient terminés
sbatch --depend=after:123_4 my.job
sbatch --depend=afterok:123_4:123_8 my.job2
 
# Attendre que tout un job soit terminé
sbatch --depend=afterany:123 my.job
 
# Attendre que tout un job array soit terminé avec succès
sbatch --depend=afterok:123 my.job

Vous pouvez également voir cette page

Vous pouvez utiliser les steps jobs pour des exécutions multiples et variées.

Les steps jobs:

• permettent de découper un job en plusieurs tâches
• sont créés en préfixant la commande du programme à exécuter par la commande Slurm “srun”
• peuvent s'exécuter séquentiellement ou parallèlement

Chaque steps peut utiliser n tâches (task) sur N noeuds de calculs (options -n et -N de srun). Une task a cpus-per-task CPU à sa disposition, et il y a ntasks allouée par étape (step).

#SBATCH --job-name=nameOfJob  	                        # Nom du Job
#SBATCH --cpus-per-task=1		                # Allocation de 1 CPUs par task
#SBATCH --ntasks=2			                # Nombre de tâches (tasks) : 2
 
#SBATCH --mail-type=END	                                # Notification par email de la
#SBATCH --mail-user=username@univ-angers.fr	        # fin de l’exécution du job.
 
# Step de 2 Tasks
srun before.sh
 
# 2 Step en parallèle (grâce à &): task1 et task2 s’exécute en parallèle. Il n'y a qu'une seule task par Step (option -n1)
srun -n1 -N1 /path/to/task1 -threads $SLURM_CPUS_PER_TASK &
srun -n1 -N1 /path/to/task2 -threads $SLURM_CPUS_PER_TASK &
 
# On attend la fin de task1 et task2 avant d'excuter la dernière étape after.sh
wait
 
srun after.sh

Récupéré d'ici

# Boucle sur les éléments d'un tableau (ici des fichiers) :
files=('file1' 'file2' 'file3' ...)
for f in "${files[@]}"; do
	# Adaptez "-n1" et "-N1" en fonction de vos besoins
	srun -n1 -N1 [...] "$f" &
done
 
# Boucle sur les fichiers d'un répertoire :
while read f; do
	# Adaptez "-n1" et "-N1" en fonction de vos besoins
	srun -n1 -N1 [...] "$f" &
done < <(ls "/path/to/files/")
# Utilisez "ls -R" ou "find" pour un parcours récursif des dossiers
 
# Lecture ligne par ligne d'un fichier :
while read line; do
	# Adaptez "-n1" et "-N1" en fonction de vos besoins
	srun -n1 -N1 [...] "$line" &
done <"/path/to/file"

Il suffit d'ajouter l'option –cpus-per-task et d'exporter la variable OMP_NUM_THREADS

#!/bin/bash
# openmp_exec.slurm
#SBATCH --job-name=hello
#SBATCH --output=openmp_exec.out
#SBATCH --error=openmp_exec.err
#SBATCH --mail-type=end
#SBATCH --mail-user=user@univ-angers.fr
#SBATCH --nodes=1
#SBATCH --ntasks-per-node=1
#SBATCH --partition=intel-E5-2695
 
#SBATCH --cpus-per-task=20
 
export OMP_NUM_THREADS=20
 
/path/to/openmp_exec

Par défaut, il est impossible de se connecter en ssh directement sur les nœuds de calcul. Cependant, si c'est justifié, nous pouvons facilement faire des exceptions si celles ci sont temporaires. Dans ce cas, merci de faire une demande explicite à technique [at] info.univ-angers.fr

Les utilisateurs ayant un accès en ssh doivent être abonnés à la liste calcul-hpc-leria-no-slurm-mode@listes.univ-angers.fr. Pour s'inscrire à cette liste de diffusion, il suffit d'envoyer un mail à sympa@listes.univ-angers.fr avec pour objet: subscribe calcul-hpc-leria-no-slurm-mode Nom Prénom

Règle par défaut: on ne lance pas un calcul sur un serveur sur lequel tourne déjà un calcul d'un autre utilisateur, même si celui-ci n'utilise pas toute les ressources. Exception pour les processus boinc. Ces processus se mettent en pause lorsque vous exécutez vos calculs.

La commande htop vous permet de savoir qui calcule avec quelles ressources et depuis combien de temps.

Si vous avez un doute, contactez l'utilisateur qui calcule directement par email ou via la liste calcul-hpc-leria-no-slurm-mode@listes.univ-angers.fr

Des cartes GPU sont présentent sur les noeuds star{242,253,254}:

• star242: P100
• star253: 2*k20m
• star254: 2*k20m

Actuellement, c'est la version 9.1 de cuda-sdk-toolkit qui est installé.

Ces nœuds sont pour l'instant hors des listes de soumissions de slurm (bien que la partition gpu existe déjà). Pour pouvoir vous en servir, merci d'en faire la demande explicite à technique [at] info.univ-angers.fr

Le leria dispose d'un nœud composé de 1,5 To de ram, il s'agit de star243.

Ce nœud est accesible par soumissions via slurm (partition ram). Pour pouvoir vous en servir, merci d'en faire la demande explicite à technique [at] info.univ-angers.fr

Le Leria a une licence académique pour le logicielle Cplex.

Le chemin pour la bibliothèque Cplex est le chemin par défaut /opt/ibm/ILOG/CPLEX_Studio129 (version 12.9)

La commande conda activate <env_name>, permettant d'activer un environnement conda n'est pas utilisable avec slurm. À la place, il faut utiliser au début du script de lancement :

source ./anaconda3/bin/activate <env_name>

Il sera peut être également nécessaire de mettre à jour les variables d'environnement et d'initialiser conda sur le noeud de calcul :

source .bashrc
conda init bash

L'environnement restera alors actif d'une exécution à une autre. Pour le désactiver, il faudra utiliser :

source ./anaconda3/bin/deactivate

• Comment savoir quelles sont les ressources d'une partition, exemple avec la partition std:

user@stargate~# scontrol show Partition std

• Que signifie “Some of your processes may have been killed by the cgroup out-of-memory handler” ?

Vous avez dépassé la limite de mémoire que vous avez fixé ou celle par défaut (paramètre –mem-per-cpu)

• Comment obtenir un prompt shell interactif dans un nœud de calcul de votre partition par défaut ?

user@stargate~# salloc

srun -n1 -N1 --mem-per-cpu=0 --pty --preserve-env --cpu-bind=no --mpi=none $SHELL

• Comment obtenir un prompt shell interactif dans un nœud de calcul spécifique ?

user@stargate~# srun -w NODE_NAME -n1 -N1 --pty bash -i 
user@NODE_NAME~#

• Comment puis je citer les ressources du LERIA dans mes rédactions scientifiques ?

Vous pouvez utiliser l'entrée misc de bibtex suivante pour citer le cluster de calcul dans vos publications:

@Misc{HPC_LERIA,
    title = {High Performance Computing Cluster of LERIA},
    year = {2018},
    note = {slurm/debian cluster of 27 nodes(700 logical CPU, 2 nvidia GPU tesla k20m, 1 nvidia P100 GPU), 120TB of beegfs scratch storage}
  }

• Lorsque je soumet mes jobs, j'ai le message d'erreur suivant:

srun: error: Unable to allocate resources: Requested node configuration is not available

Cela signifie surement que vous essayez d'utiliser un noeud sans avoir spécifier la partition dans laquelle il se trouve. Vous devez utiliser l'option -p ou –partition suivi du nom de la partition dans laquelle se trouve le noeud. Pour avoir cette information, vous pouvez faire:

user@stargate# scontrol show node NODE_NAME|grep Partitions

• automake
• bison
• boinc-client
• bowtie2
• build-essential
• cmake
• flex
• freeglut3
• freeglut3-dev
• g++
• g++-8
• g++-7
• g++-6
• git
• glibc-doc
• glibc-source
• gnuplot
• libglpk-dev
• libgmp-dev
• liblapack3
• liblapack-dev
• liblas3
• liblas-dev
• libtool
• libopenblas-base
• maven
• nasm
• openjdk-8-jdk-headless
• r-base
• r-base-dev
• regina-rexx
• samtools
• screen
• strace
• subversion
• swiprolog
• tmux
• valgrind
• valgrind-dbg
• valgrind-mpi

• keras
• scikit-learn
• tensorflow
• tensorflow-gpu # Sur nœuds gpu

• libglu1-mesa-dev
• libx11-dev
• libxi-dev
• libxmu-dev
• libgl1-mesa-dev
• linux-source
• linux-headers
• linux-image
• nvidia-cuda-toolkit

Peut-être un programme est il manquant dans les liste ci dessus. Dans ce cas, 5 options s'offrent à vous:

• Faire une demande à technique [at] info.univ-angers.fr du/des logiciels que vous souhaitez installer
• Faire vous même l'installation via pip, pip2 ou pip3
• Faire vous même l'installation via conda: téléchargement et installation
• Faire vous même l'installation en compilant les sources dans votre home_directory

Pour les liens ci dessous, vous devrez vous authentifier avec votre login et mot de passe ldap (idem ENT).

https://grafana.leria.univ-angers.fr/d/_0Bh3sxiz/vue-densemble-du-cluster

https://grafana.leria.univ-angers.fr/d/000000007/noeuds-du-cluster

Remerciements