Premiers pas en Linux

Les serveurs

Les logiciels sur le calculateur (modules)

Les logiciels sont installés à la demande des utilisateurs dans la pile de logiciels centrale et mis à disposition de l’utilisateur sous la forme de modules chargés à la demande par un utilitaire appelé lmod. Chaque module permet de modifier l’environnement de l’utilisateur pour pointer vers le logiciel+version en question.

Exemple:

[user@hpc-login1 ~]$ perl --version

This is perl 5, version 26, subversion 3 (v5.26.3) built for x86_64-linux-thread-multi

[user@hpc-login1 ~]$ module load perl
[=== Module perl/5.34.1 loaded ===]

[user@hpc-login1 ~]$ perl --version

This is perl 5, version 34, subversion 1 (v5.34.1) built for x86_64-linux-thread-multi
...

Un autre exemple avec Python

[user@hpc-login1 ~]$ python --version
-bash: python: command not found

[user@hpc-login1 ~]$ module load python
[=== Module python/3.10.6 loaded ===]

[user@hpc-login1 ~]$ python --version
Python 3.10.6

Les modules

Les catégories

Les modules sont divisés en plusieurs grandes sections listées ci-dessous.

Section	Description
Local	Quelques modules custom locaux au calculateur
Core	Les interpréteurs de base (compilateurs, python, cuda, …)
Environments	Des environnements pré-déployés avec une chaîne de dépendance locale

Pour obtenir la liste des modules disponibles il suffit d’utiliser module avail

[user@hpc-login1 ~]$ module avail
------------------------ /etc/hpc.unc.nc/modules/Local -------------------------
UNC (S,L)

------------------------- /etc/hpc.unc.nc/modules/Core -------------------------
anaconda2/2019.10    anaconda3/2022.05    autoconf/2.69    automake/1.16.5
cmake/3.24.2    cuda/10.2.89    cuda/11.7.1    cuda/11.8.0 (D)    ffmpeg/4.4.1
gcc/12.2.0    hdf5/1.10.5    openmpi/4.1.4    perl/5.34.1    python/2.7.18
python/3.9.13    python/3.10.6 (D)    sqlite/3.39.2

--------------------- /etc/hpc.unc.nc/modules/Environments ---------------------
python/3.9/cuda/11.7/cudnn/8.4/pytorch/1.12.1

Charger un module `module load`

Charger un module s’effectant simplement en utilisant la commande module load NOM.

Si certains modules dépendent d’autres modules, ceux-ci seront chargées automatiquement.

[user@hpc-login1 ~]$ module load python
[=== Module sqlite/3.39.2 loaded ===]
[=== Module python/3.10.6 loaded ===]

Afin de décharger un module, il suffit d’utiliser la commande module unload NOM ou pour réinitialiser complétement les modules chargés, on peut utiliser la commande module reset.

Chercher un module `module spider`

Si vous connaissez le nom d’un module ou d’une fonctionnalité que vous recherchez mais que le nom du module vous est encore inconnu, vous pouvez utiliser la commande module spider <terme>. Vous aurez ainsi les noms de module les plus pertinents par rapport au terme recherché.

Exemple:

[user@hpc-login1 ~]$ module spider mpi

--------------------------------------------------------------------
openmpi: openmpi/4.1.4
--------------------------------------------------------------------

    This module can be loaded directly: module load openmpi/4.1.4

    Help:
    An open source Message Passing Interface ...

Module caché

Si vous souhaitez charger un module dont la branche n’est pas encore affichée, il vous sera aussi conseillé d’utiliser module spider pour connaitre la chaine de dépendance du module en question.

[user@hpc-login1 ~]$ module load cudnn/8.2.4.15
Lmod has detected the following error:  These module(s) or extension(s) exist
but cannot be loaded as requested: "cudnn/8.2.4.15"
Try: "module spider cudnn/8.2.4.15" to see how to load the module(s).

[user@hpc-login1 ~]$ module spider cudnn/8.2.4.15

--------------------------------------------------------------------
cudnn: cudnn/8.2.4.15
--------------------------------------------------------------------

    You will need to load all module(s) on any one of the lines below
    before the "cudnn/8.2.4.15" module is available to load.

    cuda/11.7.1
    gcc/12.2.0  cuda/11.7.0

    Help:
    NVIDIA cuDNN is a GPU-accelerated library of primitives for deep neural
    networks

Ainsi pour charger cudnn/8.2.4.15 qui se trouve dans une branche avec dépendance, il vous est indiqué de:

Charger cuda/11.7.1 pour débloquer la branche correspondante
Puis charger cudnn/8.2.4.15

Les branches de dépendance

Lorsque l’on charge un module qui est une dépendance forte à une autre famille de modules, une nouvelle branche est débloquée et devient accessible. Par exemple, en chargant openmpi, on débloque la branche de modules des applications compilées avec le logiciel+version en question:

[user@hpc-login1 ~]$ module load openmpi/4.1.4
[=== Module openmpi/4.1.4 loaded ===]
[user@hpc-login1 ~]$ module avail

------------- /etc/hpc.unc.nc/modules/MPI/gcc/8.5.0/openmpi/4.1.4 -------------
cfdem/5.x    hdf5/1.12.2 (D)    openfoam/5.x    openfoam/2206 (D)

------------------------ /etc/hpc.unc.nc/modules/Local -------------------------
UNC (S,L)

------------------------- /etc/hpc.unc.nc/modules/Core -------------------------
....

Deviennent maintenant disponible différentes versions d’OpenFoam compilées avec openmpi/4.1.4.

Les environnements virtuels Python

TODO

Le gestionnaire de charge/Pannificateur (SLURM)

Le gestionnaire de ressources, et plannicateur, a pour but de plannifier et exécuter les tâches/calculs sur un calculateur. Son rôle est de rechercher et d’assigner les ressources disponibles aux différents calculs qui lui sont soumis. Les calculs sont au fur et à mesure ajouter à la file d’attente, SLURM décide ensuite en fonction des ressources disponibles et d’autres facteurs sur quel serveur la tâche va rouler. Cette tâche est appelée un job.

Les types de jobs

SLURM accepte 2 types de jobs: * Le job en batch * Le job interactif

Job en batch

Le calcul en batch est le type de job à privilégier sur un calculateur car il permet d’ajouter son script à la file d’attente sans attendre que les ressources soient disponibles et d’obtenir la sortie du calcul dans son répertoire de travail (output).

Afin de soumettre un calcul en batch, on utilise la commande sbatch <nom_du_script>.

Exemple

$ sbatch monscript.sh
sbatch: Submitted batch job 65541

Un script pour un job en batch se présente comme suit:

#!/bin/bash
# Le shell à utiliser doit toujours être la 1ère ligne

# Les directives de soumission pour SLURM commencent ensuite par "#SBATCH" :

#SBATCH --job-name=mon_calcul
#SBATCH --mail-type=BEGIN,END
#SBATCH --partition=cpu
#SBATCH --nodes=1
#SBATCH --cpus-per-task=4
#SBATCH --mem=64G
#SBATCH --time=1:00:00

# Les différentes directives à exécuter sont insérées ensuite:

echo "Je roule sur le noeud $HOSTNAME"
sleep 60

Il existe de nombreuses directives de soumission pour SLURM dont la plupart sont communes aux jobs en batch et interactifs dont les plus importantes sont réunies dans le tableau ci-après.

Job interactif

TODO

Les directives de soumission

Pour un job en batch ou en interactif, les ressources demandées sont spécifiées sur la ligne de commande accolée à la commande sbatch/salloc (ou au début du script en batch). Les plus courramment utilisées sont réunies dans le tableau ci-dessous et la liste complète peut être consultée sur la page officielle des commandes SLURM: sbatch / salloc.

Directive	Description
–cpus-per-task=<X> -c 4	Nombre de coeurs
–mem=<size>[units] –mem=64	Ram
–gres=gpu:X –gres=gpu:v100:1	Gpu
-t, –time=HH:MM:SS	Temps maximum
–partition=cpu/gpu	En fonction du type de calcul demandé (automatique)
–output=fichier.log	Fichier contenant tout l’output du calcul. Si absent, défaut vers slurm-<jobid>.out

Les commandes à connaitre

Les commandes les plus couramment utilisées pour interagir avec SLURM sont réunies dans le tableau ci-dessous et certaines sont détaillées dans les sections suivantes:

Commande	Description
sinfo sinfo -l sinfo -N -l	Etat des noeuds, des partitions
squeue squeue -u mon_username squeue -j jobid squeue -p partition	Etat de la file d’attente
sbatch sbatch -ressources mon_script.sh	Soumette un job en batch
salloc salloc -ressources	Lancer un job interactive
scancel scancel jobid	Annuler un job
scontrol scontrol show jobid -dd scontrol show node	Information détaillée sur les noeuds/jobs

La queue de calcul

Chaque job soumis est ajouté à la queue de calcul de SLURM qui définit la place du calcul dans la file d’attente suivant différents facteurs comme les ressources demandées et votre utilisation effective.

Afin d’afficher l’état de la queue de calcul on utilise la commande squeue

Les types de noeud/partition

Afin d’orienter les jobs vers les noeuds possédant les ressources les plus adéquates sans bloquer l’utilisation d’autres ressources spécificiques, les noeuds sont répartis en partition qui sont des queues de calcul séparées.

Note

Le calculateur ne possédant que 2 noeuds: un noeud CPU et un noeud GPU, la sélection de la partition est automatique et il n’est pas nécessaire de la spécifier dans les ressources.

Le fichier de sortie (`output`)

slurm-<job id>.out