Clusters LIP6

Le cluster Convergence est composé d'une frontale et de dix nœuds de calcul :

Machine	Modèle	Mémoire	Processeurs	Cœurs	GPUs
front	DELL PowerEdge R650xs	125 Go	2 x Intel Xeon Silver 4310	24 cœurs / 48 threads @ 2.10 GHz
node01	DELL PowerEdge XE8545	2 To	2 x AMD EPYC 7543	64 cœurs / 128 threads @ 2.80 GHz	4 x NVIDIA A100 80Go SXM
node[02-06]	DELL PowerEdge R750xa	2 To	2 x Intel Xeon Gold 6330	56 cœurs / 112 threads @ 2.00 GHz	4 x NVIDIA A100 80Go PCIe
node[07-10]	DELL PowerEdge R750xa	1 To	2 x Intel Xeon Gold 6330	56 cœurs / 112 threads @ 2.00 GHz	4 x NVIDIA A100 80Go PCIe

Sur chaque nœud, 4 cœurs (8 threads) et 4 Go de RAM sont réservés pour le système et slurm.

Par défaut, lorsqu’on réserve un GPU, slurm réserve également 4 cœurs (8 threads) et 64 Go de RAM.

MIG est utilisé pour partitionner les GPUs A100 80 Go en plusieurs GPUs plus petits. Les nœuds du cluster proposent chacun :

2 x GPU MIG 80 Go correspondant à un GPU complet (pour slurm : a100_7g.80gb)
4 x GPU MIG 40 Go (pour slurm : a100_3g.40gb)

Il est obligatoire de préciser le type de GPU voulu dans les réservations slurm.

Le /home (300 To) est hébergé sur front (baie DELL ME5084 - SAS 12 Gb - 28 x HDD 16 To) et exporté en NFS vers les nœuds de calcul.

Chaque nœud de calcul dispose d'un stockage local monté dans /scratch (1.6 To sur NVME).

L'accès à la frontale du cluster se fait par un lien ethernet 10 Gb/s.

La frontale et les nœuds de calcul sont interconnectés par un réseau Infiniband 200 Gb/s (Mellanox QM8700).

L’accès à Convergence se fait par une connexion ssh sur la frontale du cluster (front.convergence.lip6.fr).

Les membres du LIP6 ont automatiquement accès à Convergence.

Les utilisateurs hors LIP6 peuvent faire une demande pour avoir un compte à convergence@lip6.fr.

L’accès aux ressources de calcul se fait au travers de la centrale de réservation slurm (voir https://slurm.schedmd.com/) :

obtenir des informations sur le cluster : sinfo

La commande sinfo permet de :

lister les partitions (files d’attente) :
```
root@front:~# sinfo -O "partition:13,available:8,nodelist:18,defaulttime:13,time:13,nodeai:10"
PARTITION    AVAIL   NODELIST          DEFAULTTIME  TIMELIMIT NODES(A/I)
convergence* up      node[01-10]       1:00:00      30-00:00:00  1/9
```
Détail de la sortie : afficher le détail
- la partition convergence est celle par défaut (*)
- elle est utilisable (up)
- elle contient 10 nœuds (node[01-10])
- par défaut une réservation est limitée à une heure (1:00:00)
- la durée maximale d'une réservation est de 30 jours (30-00:00:00)
- actuellement, il y a un nœud actif et neuf autres inactifs (A/I)

lister les nœuds de calcul :

root@front:~# sinfo -p convergence --Node -O "nodelist:13,features:8,socketcorethread:8,cpusstate:15,memory:8,allocmem:10,gres:60,gresused:60,statelong:20,reason:20"
NODELIST AVAIL_FEATURES S:C:T  CPUS(A/I/O/T) MEMORY  ALLOCMEM GRES                                            GRES_USED                                             STATE REASON              
node01   intel          2:28:2 0/112/0/112   2048000 0        gpu:a100_7g.80gb:2,gpu:a100_3g.40gb:4           gpu:a100_7g.80gb:0,gpu:a100_3g.40gb:0                 idle~ none                
node02   intel          2:28:2 0/112/0/112   2048000 0        gpu:a100_7g.80gb:2,gpu:a100_3g.40gb:4           gpu:a100_7g.80gb:0,gpu:a100_3g.40gb:0                 idle~ none                
node03   intel          2:28:2 0/112/0/112   2048000 0        gpu:a100_7g.80gb:2,gpu:a100_3g.40gb:4           gpu:a100_7g.80gb:0,gpu:a100_3g.40gb:0                 idle~ none                
node04   intel          2:28:2 0/112/0/112   2048000 0        gpu:a100_7g.80gb:2,gpu:a100_3g.40gb:4           gpu:a100_7g.80gb:0,gpu:a100_3g.40gb:0                 idle~ none                
node05   intel          2:28:2 0/112/0/112   2048000 0        gpu:a100_7g.80gb:2,gpu:a100_3g.40gb:4           gpu:a100_7g.80gb:0,gpu:a100_3g.40gb:0                 idle~ none                
node06   intel          2:28:2 0/112/0/112   1024000 0        gpu:a100_7g.80gb:2,gpu:a100_3g.40gb:4           gpu:a100_7g.80gb:0,gpu:a100_3g.40gb:0                 idle~ none                
node07   intel          2:28:2 0/112/0/112   1024000 0        gpu:a100_7g.80gb:2,gpu:a100_3g.40gb:4           gpu:a100_7g.80gb:0,gpu:a100_3g.40gb:0                 idle~ none                
node08   intel          2:28:2 0/112/0/112   1024000 0        gpu:a100_7g.80gb:2,gpu:a100_3g.40gb:4           gpu:a100_7g.80gb:0,gpu:a100_3g.40gb:0                 idle~ none                
node09   intel          2:28:2 0/112/0/112   1024000 0        gpu:a100_7g.80gb:2,gpu:a100_3g.40gb:4           gpu:a100_7g.80gb:0,gpu:a100_3g.40gb:0                 idle~ none                
node10   amd            2:32:2 16/112/0/128  2048000 524288   gpu:a100_7g.80gb:2(S:0),gpu:a100_3g.40gb:4(S:1) gpu:a100_7g.80gb:0(IDX:N/A),gpu:a100_3g.40gb:1(IDX:2) mixed none

Détail de la sortie : afficher le détail

les machines node[01-09] proposent la feature intel
la machines node10 propose la feature amd
les machines node[01-09] disposent de 2 processeurs ayant chacun 28 cœurs ayant chacun 2 threads (2:28:2)
la machine node10 dispose de 2 processeurs ayant chacun 32 cœurs ayant chacun 2 threads (2:32:2)
actuellement sur node[01-9], il y a 0 threads réservés, 112 disponibles, 0 dans un autre état (???) sur un total de 112 (0/112/0/112)
actuellement sur node10, il y a 16 threads réservés, 112 disponibles, 0 dans un autre état sur un total de 128 (16/112/0/128)
les machines node[01-5] et node10 disposent de 2048000 Mo de RAM
les machines node[06-9] disposent de 1024000 Mo de RAM
actuellement sur node[01-9], 0 Mo de RAM sont attribués
actuellement sur node10, 524288 Mo de RAM sont attribués
les machines disposent de 2 GPUs MIG 80 Go (gpu:a100_7g.80gb:2) et de 4 GPUs MIG 40 Go (gpu:a100_3g.40gb:4)
actuellement sur node[01-9], il n'y a aucun GPU utilisé (gpu:a100_7g.80gb:0,gpu:a100_3g.40gb:0)
actuellement sur node10, il y a 0 GPU MIG 80 Go utilisé et 1 GPU MIG 40 Go utilisé (gpu:a100_7g.80gb:0(IDX:N/A),gpu:a100_3g.40gb:1(IDX:2))
actuellement node[01-9] ne font rien (idle) et sont éteints électriquement par le module d'économie d'énergie (~)
actuellement node10 est en mode mixed (avec des ressources réservées mais avec encore des ressources réservables)
actuellement, aucune des machines n'est en erreur (none)

obtenir des informations sur les jobs :
- afficher la file d'attente : squeue
  La commande squeue permet de lister les jobs en cours et de récupérer leurs identifiants.
```
root@front:~# squeue
JOBID PARTITION NAME USER ST TIME  NODES NODELIST(REASON)
   68 convergen test leroux R  28:06     1   node10
```
  Détail de la sortie : il y a un job ayant l'id 68 et le nom test, lancé par l'utilisateur leroux qui est en cours (R pour Running) depuis 28 minutes 06 secondes et qui utilise des ressources sur node10 (voir la page de manuel de squeue pour les différents états).
- obtenir plus d'informations sur un job : sacct
  La commande sacct permet d'afficher les détails d'un job.
```
root@front:~# sacct -j 68 --format="JobID,JobName,User,Account,NodeList,AllocTres%80,Start,End,State,Reason" -X
JobID JobName User   Account NodeList                                                 AllocTRES               Start     End   State Reason 
----- ------- ------ ------- -------- --------------------------------------------------------- ------------------- ------- ------- ------ 
68       test leroux lip6      node10 billing=16,cpu=16,gres/gpu:a100_3g.40gb=1,mem=512G,node=1 2023-04-19T15:31:12 Unknown RUNNING   None
```
  Détail de la sortie :
  - le job ayant l'id 68 et le nom test a été lancé par l'utilisateur leroux dans le compte lip6
  - les ressources allouées à ce job sont 16 threads (cpu=16), 512 Go de RAM (mem=512G), 1 GPU MIG 40 Go (gres/gpu:a100_3g.40gb=1) sur un nœud (node=1) ici node10
  - le job a démarré à le 2023-04-19 à 15:31:12 et est toujours en cours d'exécution (RUNNING)
réserver des ressources :
- en mode interactif : salloc
  La commande salloc peut être utilisée pour obtenir une session interactive. On obtient par défaut un shell sur la frontale à partir duquel on peut lancer des commandes srun sur les ressources réservées. La fermeture du shell entraine la fin de la réservation.
```
leroux@front:~$ salloc --nodes=2 --gpus-per-node=a100_3g.40gb:1 --time=60
salloc: Granted job allocation 60
salloc: Waiting for resource configuration
salloc: Nodes node[01,10] are ready for job

leroux@front:~$ srun nvidia-smi -L
GPU 0: NVIDIA A100 80GB PCIe (UUID: GPU-6bfd077d-a528-62e5-5ffd-f5ccf9e5a557)
  MIG 3g.40gb     Device  0: (UUID: MIG-a5a1e127-c156-5892-ae71-8518fcd84332)
GPU 0: NVIDIA A100-SXM4-80GB (UUID: GPU-b90dfade-11bc-8d5b-321b-9f6f6284b497)
  MIG 3g.40gb     Device  0: (UUID: MIG-81ca0f5d-30f9-5a88-9f4a-1cec8fd84f6c)

leroux@front:~$ srun hostname
node10
node01

leroux@front:~$ exit
salloc: Relinquishing job allocation 60
salloc: Job allocation 60 has been revoked.
leroux@front:~$
```
  L'option --x11 de salloc permet d'activer la prise en charge du déport d'affichage d'application graphique par slurm (il faut utiliser l'option -X de ssh pour la connection à la frontale).
  
  L'option --no-shell de salloc permet de réserver des ressources sans avoir à conserver un shell ouvert sur la frontale pendant toute la durée de la réservation. L'accès aux ressources se fera alors avec l'option --jobid de srun ou directement par ssh.
  
  Les utilisateurs peuvent se connecter par ssh aux nœuds de calcul sur lesquels des ressources leur ont été réservées par salloc.
- en mode non interactif : sbatch
  La commande sbatch peut être utilisée pour soumettre un script qui sera exécuté de façon non interactive. Les directives #SBATCH en début de script servent à configurer la réservation.
  
  Exemple de script sbatch :
```
leroux@front:~$ cat batch1.sh
#!/bin/bash

#SBATCH --job-name=exemple
#SBATCH --nodes=1
#SBATCH --constraint=amd
#SBATCH --cpus-per-task=16
#SBATCH --mem=512G
#SBATCH --gpus=a100_3g.40gb:1
#SBATCH --time=5
#SBATCH --mail-type=ALL
#SBATCH --output=%x-%j.out
#SBATCH --error=%x-%j.err

nvidia-smi -L
sleep 300

leroux@front:~$ sbatch batch1.sh
Submitted batch job 20

leroux@front:~$ cat exemple-20.out
GPU 0: NVIDIA A100-SXM4-80GB (UUID: GPU-b90dfade-11bc-8d5b-321b-9f6f6284b497)
  MIG 3g.40gb     Device  0: (UUID: MIG-81ca0f5d-30f9-5a88-9f4a-1cec8fd84f6c)
```
  Lorsqu’on réserve des ressources sur plusieurs nœuds de calcul, le script soumis avec sbatch est exécuté sur le premier nœud de calcul.
  
  slurm définit de nombreuses variables d’environnement ‘SLURM_*’ qui peuvent être utilisées dans les scripts :
  - SLURM_JOB_NAME : nom du job
  - SLURM_JOBID : numéro du job
  - SLURM_STEPID : numéro du step (une invocation de srun correspond à un step dans le job)
  - SLURM_JOB_NODELIST : listes des nœuds sur lesquels des ressources ont été allouées au job
  - SLURM_NODEID : identifiant du nœud
  Les utilisateurs peuvent se connecter par ssh aux nœuds de calcul sur lesquels des ressources leur ont été réservées par sbatch.
- en mode exclusif (un nœud complet) : --exclusive
  
  L'option --exclusive peut être utilisée avec salloc ou sbatch pour réserver un nœud complet.
  
  Dans ce cas, tous les CPUs et les GPUs de la machine sont accessibles pour l'utilisateur.
  
  Pour avoir accès à toute la mémoire de la machine, il faut également rajouter l'option --mem=0.
- utilisation des contraintes : --constraint
  
  L'option --constraint= peut être utilisée avec salloc ou sbatch pour choisir plus finement les caractéristiques des nœuds à réserver.
  
  Cette option permet de sélectionner les nœuds en fonction des features qu'ils exposent (voir la sortie de sinfo).
  
  Il est par exemple possible de choisir entre un processeur Intel (--constraint=intel) ou un processeur AMD (--constraint=amd).
utiliser les ressources :
- par slurm : srun
  La commande srun permet de lancer une commande en parallèle sur les nœuds sur lesquels des ressources ont été allouées à un job lancé par salloc ou sbatch.
  
  Dans un job, chaque appel à srun correspond à un step.
  
  La commande srun hérite des directives de réservation de salloc ou sbatch.
```
leroux@front:~$ cat batch3.sh
#!/bin/bash

#SBATCH --job-name=exemple
#SBATCH --nodes=2
#SBATCH --gpus-per-node=a100_3g.40gb:1
#SBATCH --time=1
#SBATCH --mail-type=ALL
#SBATCH --output=%x-%j.out
#SBATCH --error=%x-%j.err

srun hostname
srun nvidia-smi -L

leroux@front:~$ sbatch batch3.sh
Submitted batch job 24

leroux@front:~$ cat exemple-24.out
node01
node10
GPU 0: NVIDIA A100 80GB PCIe (UUID: GPU-6bfd077d-a528-62e5-5ffd-f5ccf9e5a557)
  MIG 3g.40gb     Device  0: (UUID: MIG-a5a1e127-c156-5892-ae71-8518fcd84332)
GPU 0: NVIDIA A100-SXM4-80GB (UUID: GPU-b90dfade-11bc-8d5b-321b-9f6f6284b497)
  MIG 3g.40gb     Device  0: (UUID: MIG-81ca0f5d-30f9-5a88-9f4a-1cec8fd84f6c)
```
  Un appel à srun est bloquant. Il faut attendre que la commande lancée par srun soit achevée sur les différents nœuds pour passer à la commande suivante. On peut utiliser le & du shell pour lancer des srun en parallèle. Dans ce cas, il faut indiquer à srun les ressources que chaque tâche va utiliser pour que slurm accepte de les lancer en parallèle.
```
#!/bin/bash

#SBATCH --nodes=2
#SBATCH --gpus-per-node=a100_3g.40gb:3
#SBATCH --time=5
#SBATCH --verbose

srun -n2 -c8 --gpus-per-node=a100_3g.40gb:1 bash tache1.sh &
srun -n2 -c8 --gpus-per-node=a100_3g.40gb:1 bash tache2.sh &
srun -n2 -c8 --gpus-per-node=a100_3g.40gb:1 bash tache3.sh

wait
```
- directement : ssh
  Les utilisateurs peuvent se connecter en ssh sur les nœuds de calcul sur lesquels ils ont des ressources allouées pour un job lancé par salloc ou sbatch. Leur session ssh est restreinte aux ressources allouées à leur job.
  
  Les nœuds de calcul n'étant pas directement accessibles depuis internet, il faut faire un rebond par la frontale front :
```
ssh -J front.convergence.lip6.fr node01.convergence.lip6.fr
```
interrompre un job : scancel
La commande scancel permet d’interrompre un job :
```
leroux@front:~# scancel 177
```

module

La commande module permet de configurer votre environnement pour utiliser certaines versions de logiciel :

lister les modules disponibles :

leroux@front:~$ module avail
----------------------------------- /etc/environment-modules/modules ---------------------------------------------
cuda/11.0  cuda/11.1  maple/2019.0  maple/2020.0  mathematica/12.1  matlab/R2019b  matlab/R2020a  python/anaconda3

charger un module :

leroux@front:~$ module load cuda/11.1 python/anaconda3

lister les modules chargés :

leroux@front:~$ module list
Currently Loaded Modulefiles:
 1) cuda/11.1   2) python/anaconda3

décharger un module :
```
leroux@front:~$ module unload cuda
```
décharger tous les modules :
```
leroux@front:~$ module purge
```

maple, mathematica, matlab

Grâce aux licences campus Sorbonne Université, les logiciels maple, mathematica et matlab sont utilisables sur le cluster via la commande module.
anaconda

L'outil conda, accessible par le module python/anaconda3, vous permet de gérer vos environnements python.

conda nécessite une initialisation de votre shell. La commande conda init peut être utilisée pour modifier de façon permanente votre .bashrc afin que votre shell soit automatiquement initialisé pour conda dans vos sessions interactives. Les scripts exécutés par slurm n'étant pas exécutés dans une session interactive, il est nécessaire d'initialiser votre shell avec la commande eval "$(conda shell.bash hook)" (voir l'exemple pour jupyter).

La documentation de conda est accessible sur le site officiel.

jupyter

Utilisation de jupyter :

création d'un environnement anaconda :
```
leroux@front:~$ conda create -n myenv
```

installation de jupyter notebook :

leroux@front:~$ conda install -n myenv notebook

exemple de script sbatch :

#!/bin/bash

#SBATCH --job-name=test_jupyter
#SBATCH --nodes=1
#SBATCH --gpus-per-node=a100_3g.40gb:1
#SBATCH --time=60
#SBATCH --mail-type=ALL
#SBATCH --output=%x-%j.out
#SBATCH --error=%x-%j.err

module purge                        # Nettoyage de l'environnement
module load python/anaconda3        # Chargement du module anaconda3
eval "$(conda shell.bash hook)"     # Initialisation du shell pour conda
conda activate myenv                # Activation de votre environnement python
jupyter notebook                    # Démarrage de jupyter

après quelques instants, l'url du notebook peut être récupérée dans les logs du job

cat test_jupyter-226.err
...
    or http://127.0.0.1:8888/?token=97c4066cee8dcc55cb40b7311bcf1240cb503a6872c88038
...

mise en place d'un tunnel ssh vers le port du notebook entre le poste utilisateur et le nœud de calcul :
```
ssh -J front.convergence.lip6.fr -L 8888:localhost:8888 node01.convergence.lip6.fr
```

tensorflow
Installation de tensorflow :
```
conda create -n tensorflow_env
conda install -n tensorflow_env tensorflow-gpu
```
L'installation de tensorflow par anaconda vient avec sa propre pile CUDA. Il est préférable de ne pas charger une autre pile en parallèle via module pour éviter d'éventuels conflits entre les deux piles CUDA.
pytorch
Installation de pytorch :
```
conda create -n pytorch_env
conda install -n pytorch_env pytorch torchvision -c pytorch
```
L'installation de pytorch par anaconda vient avec sa propre pile CUDA. Il est préférable de ne pas charger une autre pile en parallèle via module pour éviter d'éventuels conflits entre les deux piles CUDA.

container

Le cluster Convergence permet de lancer des containers type docker sur les nœuds de calcul par l'utilisation du plugin pyxis qui lui même utilise enroot.

Exemple de script sbatch :

#!/bin/bash -x

#SBATCH --job-name=test
#SBATCH --nodes=1
#SBATCH --gpus=a100_3g.40gb:1
#SBATCH --container-image nvcr.io\#nvidia/pytorch:23.04-py3
#SBATCH --container-mount-home
#SBATCH --time=60
#SBATCH --mail-type=ALL
#SBATCH --output=%x-%j.out
#SBATCH --error=%x-%j.err

hostname
python -c "import torch; print(torch.cuda.is_available()); print(torch.cuda.device_count()); print(torch.cuda.get_device_name())"
echo "" > /tmp/jupyter_notebook_config.py                        # Le fichier de configuration par défaut génère des URLs fausses
jupyter notebook --config=/tmp/jupyter_notebook_config.py

Les commandes du script s'exécutent dans le container définit par l'option --container-image.

Le home de l'utilisateur peut être monté dans le container en précisant l'option --container-mount-home.

Le GPU réservé est visible dans le container.

Il est possible d'obtenir un shell dans le container :

# On récupère le PID
leroux@node10:~$ ps aux|grep leroux
leroux        3435  0.2  0.0   5784  3268 ?        S    14:25   0:00 /bin/bash -x /var/spool/slurmd/job00128/slurm_script
leroux        5838  2.8  0.0 808204 105396 ?       Sl   14:30   0:01 /usr/bin/python /usr/local/bin/jupyter-notebook
root        5961  0.0  0.0  46596 12436 ?        Ss   14:30   0:00 sshd: leroux [priv]
leroux        6001  0.1  0.0  46596  8960 ?        S    14:30   0:00 sshd: leroux@pts/0
leroux        6002  0.0  0.0  18004  5844 pts/0    Ss   14:30   0:00 -bash
leroux        6065  0.0  0.0  19160  3612 pts/0    R+   14:31   0:00 ps aux
leroux        6066  0.0  0.0   6608  2260 pts/0    S+   14:31   0:00 grep --color=auto leroux

# On lance un shell dans le container
leroux@node10:~$ enroot exec 5838 bash

# Un test avec la version de pytorch fourni par le container
leroux@node10:/workspace$ python -c "import torch; print(torch.cuda.is_available()); print(torch.cuda.device_count()); print(torch.cuda.get_device_name())"
True
1
NVIDIA A100-SXM4-80GB MIG 3g.40gb

# On sort du container
leroux@node10:/workspace$ exit

Vous pouvez envoyer toutes vos demandes concernant le cluster Convergence par mail à l'adresse convergence@lip6.fr.

Pour recevoir les nouvelles concernant Convergence, vous devez vous inscrire à la liste de diffusion convergence-news@listes.lip6.fr. Les utilisateurs hors LIP6 sont automatiquement ajoutés à cette liste à la création de leur compte.

Clusters du LIP6

Convergence

Description matérielle

Stockage

Réseau

Accès au cluster

Utilisation du cluster

Logiciels

Contact