> DIO/ Calcul/ Grappe de calcul interne

Description générale

Présentation du service

La DIO met à la disposition des utilisateurs une grappe de calcul et de traitement de données : tycho.

L'accès à cette machine est ouvert à tous les membres de l'Observatoire néanmoins il est nécessaire d'en faire la demande. Pour cela envoyez un mail à

admin.dio@obspm.fr

Nous invitons tous les utilisateurs à lire les paragraphes ci-dessous et à suivre ces recommandations. Pour une utilisation optimale des moyens de calcul, les utilisateurs doivent soumettre leurs jobs via le système de gestionnaire de tâches SLURM (Simple Linux Utility for Resource Management).

Les utilisateurs doivent s'inscrire à la liste de diffusion mpopm (machine parallèle de l'observatoire de Paris-Meudon) pour être informé des arrêts programmés de la grappe (mise à jour système, coupure électrique...) et des mises à jour logiciels.

N'hésitez pas à nous faire part de votre avis concernant l'utilisation du système. De nouveaux logiciels seront installés sur demande.

Description et caractéristiques techniques de la grappe

La grappe est actuellement constituée de :

1 frontale : tycho

 pour l'édition, la compilation et la soumission des jobs

 pour travailler en interactif

80 noeuds :

Noeud	Nb coeurs	Processeur	Mémoire/noeud	Disque local	GPU	Mise en service	feature
tycho[01-16]	16	Intel Xeon E5-2670 à 2.60 GHz	64 Go	1,7 To		Octobre 2013	tycho2013
tycho[17-20]	16	Intel Xeon E5-2650 v2 à 2.60 GHz	64 Go	0,9 To		Juin 2014	tycho2013
tycho[21-24]	16	Intel Xeon E5-2640 v3 à 2.60 GHz	64 Go	1,7 To		Octobre 2015	tycho2015
tycho[27,28]	24	Intel Xeon E5-2690 v3 à 2.6 GHz	256 Go	1,7 To		Janvier 2016	tycho2015
tycho[29-32]	16	Intel Xeon E5-2640 v3 à 2.60 GHz	64 Go	1,7 To		Mars 2016	tycho2015
tycho[33-36]	24	Intel Xeon E5-2650 v4 à 2.20 GHz	128 Go	1,7 To		Septembre 2017	tycho2015
tycho[37-44]	16	Intel Xeon Silver 4110 à 2.10GHz	96 Go	0,7 To		Décembre 2017	tycho2015
tycho[45-48]	24	Intel Xeon Gold 5118 à 2.30GHz	128 Go	1,6 To		Décembre 2017	tycho2015
tycho[49-52]	24	Intel Xeon Gold 5118 à 2.30GHz	192 Go	1,6 To		Décembre 2017	tycho2015
tycho[53-56]	28	Intel Xeon Gold 5120 à 2.20GHz	96 Go	1,6 To		Novembre 2018	tycho2020
tycho57	16	Intel Xeon Bronze 3106 à 1.70GHz	96 Go	3.4 To	2 Tesla P40	novembre 2018	tycho2020
tycho58	24	Intel Xeon Silver 4214 à 2.20GHz	192 Go	1.7 To	3 Tesla V100-PCIE-32GB	octobre 2019	tycho2020
tycho[59-62]	32	Intel Xeon Gold 5120 à 2.30GHz	96 Go	1,6 To		Janvier 2020	tycho2020
tycho[63-66]	48	Intel Xeon Gold 5220R à 2.20GHz	192 Go	1,5 To		Juin 2020	tycho2020
tycho[67-70]	48	Intel Xeon Gold 5220R à 2.20GHz	192 Go	1,5 To		Mars 2021	tycho2021
tycho[71-74]	48	Intel Xeon Gold 5220R à 2.20GHz	192 Go	1,5 To		Mars 2022	tycho2022
tycho[75-78]	48	Intel Xeon Gold 5220R à 2.20GHz	192 Go	1,5 To		Mars 2022	tycho2022
tycho[79-82]	32	Intel Xeon Silver 4314 à 2.40GHz	256 Go	1,5 To		Octobre 2022	tycho2022

Logiciels et accès

Tous les noeuds de calcul sont d'un point de vue système parfaitement identiques. Si les logiciels scientifiques dont vous avez besoin ne sont pas encore disponibles sur ces machines, signalez-le mail à la DIO (admin.dio@obspm.fr). Nous vous demandons de ne pas installer de logiciel dans votre espace de stockage personnel.

L'utilisation de cette grappe est possible pour toute personne ayant un compte durable DIO (c'est-à-dire dans l'annuaire LDAP commun, utilisé aussi pour la messagerie et l'accès sans-fil).

Il est possible d'y accéder (depuis l'intérieur du réseau de l'Observatoire) par les outils ssh, avec donc le même identifiant de login et le même mot de passe que pour la messagerie ou l'accès sans-fil. Pour cela utilisez, par exemple, la commande suivante :

ssh -X tycho.obspm.fr

Pour le transfert de fichiers, depuis votre poste de travail vers ces machines, ou vice et versa, vous pouvez utiliser des outils comme scp, sftp ou rsync.

Espace de stockage

Chaque utilisateur possède des espaces de stockage :

/obs/son_login

sauvegarde une fois par jour, en rotation sur 14 occurrences
à utiliser pour y mettre les fichiers produits par l'utilisateur lui-même : fichiers bureautiques, programmes, scripts, etc... En bref tout ce qui n'est pas reproductible par calcul ou traitement, et qui a beaucoup de valeur
quota de 30 Go

/data/son_login

sauvegarde une fois par semaine, en rotation sur 4 occurrences
à utiliser pour y mettre les données consolidées avant ou après calcul et traitement ; autrement dit des choses qui ne bougent pas forcément beaucoup une fois qu'elles existent, mais qui ont de la valeur, car produit d'un long traitement
quota de 60 Go (augmentable sur demande motivée)

/poubelle/son_login :

pas de sauvegarde
suppression après 120 jours des fichiers non modifiés
à utiliser pour des grosses manipulations de fichiers temporaires : désarchivage/archivage, transfert avec d'autres machines extérieures à la DIO, fichiers intermédiaires dans une série de traitements, etc.
autrement dit, un gros passe-plats et espace tampon
pas de quota

/scratch/son_login :

pas de sauvegarde
les fichiers datant de plus de 20 jours sont régulièrement effacés
espace non partagé entre les serveurs de calcul
à utiliser sans réserve pour les fichiers temporaires créés lors de l'exécution d'un calcul
pas de quota, mais demande de déplacement à la fin du job, de manière à laisser ces espaces libres pour les calculs à venir des collègues

/scratch2/son_login :

espace partagé entre les noeuds Tycho, à la différence de /scratch
pas de sauvegarde
les fichiers datant de plus de 20 jours sont régulièrement effacés
à utiliser sans réserve pour les fichiers temporaires créés lors de l'exécution d'un calcul
pas de quota, mais demande de déplacement à la fin du job, de manière à laisser ces espaces libres pour les calculs à venir des collègues

Nous attirons votre attention sur le fait que l'espace $HOME (= /obs/login) est sauvé une fois par jour : aussi si vous l'utilisez pour des fichiers interméiaires liés à des calculs, cela pénalise gravement le système de sauvegarde qui va enregistrer tous ces fichiers et toutes leurs variations.

L'idée sous-jacente est d'appliquer une politique de stockage et de sauvegarde adéquate aux données suivant leur nature. Plus nous pourrons « optimiser » cela, plus nous pourrons offrir de la ressource (taille de l'espace, performances, fréquence de sauvegarde, nombre de versions dans le temps, durée de conservation), là où c'est utile. Car énormément d'espace avec beaucoup de sauvegardes n'est pas possible. D'où le besoin de classifier.

Aussi merci par avance à chaque utilisateur pour bien répartir ses fichiers, souvent actuellement exclusivement dans son $HOME, entre ces différents espaces.

Statistiques d'utilisation de la grappe

Vous pouvez voir en temps réel l'utilisation de la grappe.

Gestion des variables d'environnement

La modification des variables d'environnement pour l'accès aux compilateurs est gérée par l'alias module du shell bash.

Lors de la connexion sur la frontale aucun module n'est chargé. Chaque utilisateur doit charger les modules et les versions souhaités. Il est possible de charger des modules par défaut en ajoutant la commande : module load {module_name}/{version} au fichier $HOME/.profile.

Remarque : toute modification faite sur le .profile nécessite de se déconnecter de la frontale pour sa prise en compte.

Les commandes suivantes sont disponibles :

module avail : affiche les modules disponibles
module whatis : affiche les modules disponible avec un résumé
module list : affiche les modules chargés dans le shell courant
module load module1 [module2] [...] : permet de charger des modules
module unload module1 : permet d'annuler la modification des variables d'environnement effectuée par le chargement du module module1
module purge : annule toutes les modifications apportées aux variables d'environnement par les précédent chargements

Le gestionnaire de tâches SLURM

Pour une répartition optimale des jobs que vous aurez à exécuter sur la grappe de calcul tycho, nous utilisons le système de gestion de tâches SLURM (Simple Linux Utility for Resource Management). Ce système permet une utilisation optimale des noeud/processeurs disponibles. Ce système de batch a été organisé en plusieurs queues de soumission. Dans un premier temps chaque utilisateur est limité à 156 tâches, ensuite nous ajusterons les limites par queues.

Définition des queues

6 queues publiques qui peuvent être utilisées par l'ensemble des utilisateurs, la queue par défaut est la queue short :

Partition	temps maximum en min	Nb noeuds maximum	Noeud
maup(Mise Au Point)	5	1	tycho[01-04,06-24,27-52,57,59-82]
short	60	4	tycho[03-04,06-16,53-82]
medium	1440	4	tycho[01-04,06-24,26-32,53-56,59-82]
long	7200	4	tycho[01-02,04,06-15,17-24,27-48,57,59-82]
verylong	21600	4	tycho[01-02,04,06-11,17-24,27-32,67-82]
interactif	21600	1	tycho05
low	21600	4	tycho[03-04,06-16,67-82]

10 queues dédiées à des projets, les membres du laboratoire/projet sont prioritaire sur les noeuds qui leur sont dédiés :

Partition	temps maximum en min	Nb noeuds maximum	Noeud
gaia	21600	8	tycho[02,21,33-36,49-52,65,79-82]
gaiaservice	21600	4	tycho[02,21,49-52,65,79-82]
grace	21600	1	tycho57
minerva	21600	1	tycho58
mis	21600	1	tycho[01,22-24,37-44,68,70,75-76]
misservice	21600	2	tycho[01,22,68,70]
mosaic	21600	1	tycho[29-32,63-64]
padc_medium	21600	1	tycho[66,75-78]
padc_verylong	21600	1	tycho[66,75-78]
pegase	21600	1	tycho[71-72]
plato	21600	1	tycho[27-28,67,69]
skybot	21600	4	tycho[17-20]
virage	21600	5	tycho[45-48]

Rq : les partitions [gaia,mis]service sont plus prioritaires que les partitions gaia,mis dont elles préemptent les jobs.

1 queue dédiée aux utilisateurs de la bibliothèque NAG :

nag : maximum 15j, le noeud nag-serveur.

Les jobs non prioritaires qui s'exécutent sur les noeud dédiés aux queues gaia, mis, skybot, grace, virage, plato, mosaic, minerva, padc ou pegase sont susceptibles d'être préemptés (le job de basse priorité est mis en sommeil ---et en swap--- pour laisser la place au job prioritaire.)

Les jobs en cours d'exécution qui ont été soumis sur la partition 'low' sont susceptibles d'être préemptés par les jobs des autres partitions.

En-tête des scripts de soumission SLURM

La grappe de calcul étant hétérogène il est important de bien définir les ressources nécessaire pour que le gestionnaire de tâches répartisse au mieux les jobs. Pour cela il est indispensable de définir ces directives SLURM en en-tête :

#!/bin/bash
#SBATCH --job-name=MonProg  {Nom du programme}
#SBATCH --nodes=2 --ntasks-per-node=16 {Le nombre de noeud et de coeurs/noeud}
#SBATCH --time=120 {Le temps en minute}
#SBATCH --partition=medium {La file d'attente}
#SBATCH --mail-user=prenom.nom@obspm.fr
#SBATCH --mail-type=ALL
#SBATCH --mem=1gb {la mémoire globale, au maximum 61Gb}
#SBATCH --tmp=10gb {l'espace disque pour des fichiers stockés temporairement sur /scratch}

Rq : la directive --tmp fait référence à la taille réelle du disque scratch et non à la taille disponible.

Des exemples de scripts de soumission sont disponible dans le répertoire /shared/apps/slurm/exemples

Script de soumission d'un job MPI

Voici un script typique qui réserve 2 noeuds avec 1Gb de mémoire pour 120 mn sur la queue medium :

#!/bin/bash
#SBATCH --job-name=MonProg
#SBATCH --nodes=2 --ntasks-per-node=16
#SBATCH --time=120
#SBATCH --partition=medium
#SBATCH --mem=1gb

## Définir le répertoire scratch et recopier les fichiers nécessaires à l'exécution
SCRATCH=/scratch/$USER/run.${SLURM_JOBID}
srun --ntasks=$SLURM_JOB_NUM_NODES mkdir -p $SCRATCH
cd $SCRATCH
srun --ntasks=$SLURM_JOB_NUM_NODES cp /obs/$USER/MonProg .
srun --ntasks=$SLURM_JOB_NUM_NODES cp /data/$USER/MesDonnees .

mpiexec ./MonProg > MonProg.out

srun --ntasks=$SLURM_JOB_NUM_NODES mv MesResultats /data/$USER
cd ${SLURM_SUBMIT_DIR}
mv ${SCRATCH}/MonProg.out .
srun --ntasks=$SLURM_JOB_NUM_NODES rm -rf ${SCRATCH}

exit 0

Script de soumission d'un job openMP

Voici un script typique :

#!/bin/bash
#SBATCH --job-name=MonProg
#SBATCH --nodes=1 --ntasks-per-node=16
#SBATCH --time=120
#SBATCH --partition=medium
#SBATCH --mem=1gb

## Définir le répertoire scratch et recopier les fichiers nécessaires à l'exécution
SCRATCH=/scratch/$USER/run.${SLURM_JOBID}
mkdir -p $SCRATCH
cd $SCRATCH
cp /obs/$USER/MonProg.f90 .
cp /data/$USER/MesDonnees .

ifort -openmp MonProg.f90 -o MonProg
export OMP_NUM_THREADS=16
./MonProg > MonProg.out

mv MesResultats /data/$USER
cd ${SLURM_SUBMIT_DIR}
mv ${SCRATCH}/MonProg.out .
rm -rf ${SCRATCH}

exit 0

Le nombre maximum de threads par noeud est de 16.

Soumission d'un tableau de tâches (ARRAY_TASKS)

Les ARRAY_TASKS permettent de lancer et de gérer une collection de jobs similaires, par exemple dans le cas d'un même programme analysant des sources différentes, ou initialisés avec différents fichiers de configuration.

Soumission

Pour lancer un ARRAY_TASKS il faut utiliser la commande sbatch --array=0-16 tache.slurm. Ceci aura pour effet de générer des variables d'environnement supplémentaire, notamment SLURM_ARRAY_TASK_ID et SLURM_ARRAY_JOB_ID :

SLURM_ARRAY_JOB_ID contient l'identifiant du tableau de tâche (identique pour toutes les taches de ce tableau)
SLURM_ARRAY_TASK_ID contient le numéro de la tâche courante.

L'option `--array`

L'option --array=0-16 présente plusieurs options :

--array=0-7:2 lancera les taches de 0 à 7 avec un pas de 2
--array=0-7%2 lancera les taches de 0 à 7 et empêchera l'exécution simultanée de plus de 2 tâches.

Nom des fichiers

Pour nommer les fichiers de sortie des jobs d'ARRAY_TASKS, il est possible d'utiliser %A et % a

%A : valeur de SLURM_ARRAY_JOB_ID
%a : valeur de SLURM_ARRAY_TASK_ID.

email

L'utilisation de tous les mots clés de l'option --mail fonctionne. Il ne s'applique cependant qu'au SLURM_ARRAY_JOB_ID. L'ajout de l'option ARRAY_TASKS appliquera l'ensemble des autres mots clés utilisés (BEGIN, ALL, END...) à chacune des tâches.

Exemple de tableau de tâches

La façon la plus simple d'utiliser un SLURM_ARRAY_JOB est de déclarer un tableau de paramètres et d'appeler chaque valeur avec SLURM_ARRAY_TASK_ID.

#!/bin/bash
#SBATCH --job-name=jobarray
#SBATCH --time=01:00:00
#SBATCH --nodes=1 --ntasks-per-node=2
#SBATCH --partition=short
#SBATCH --mem=40gb 
#SBATCH --mail-user=clement.hottier@obspm.fr
#SBATCH --output=slurm-jobarray-%A_%a.out
#SBATCH --mail-type=ALL
#SBATCH --array=0-7%4

initarray=("init0" "init1" "init2" "init3" "init4" "init5" "init6") 

SCRATCH=/scratch/$USER/run.$SLURM_ARRAY_JOB_ID.$SLURM_ARRAY_TASK_ID
mkdir $SCRATCH

./monprog --init ${initarray[$SLURM_ARRAY_TASK_ID]} --scratch $SCRATCH

rm -rf $SCRATCH

Le script précédent lancera l'exécutable monprog sur tous les fichiers init.

$> sbatch jobarray.slurm
Submitted batch job 25289
$> squeue -j 25289
             JOBID PARTITION     NAME     USER ST       TIME  NODES NODELIST(REASON)
       25290_[4-7]     short     chottier PD            0:00      1 (Priority)
       25290_0         short     chottier R             0:05      1 tycho04
       25290_1         short     chottier R             0:05      1 tycho04
       25290_2         short     chottier R             0:05      1 tycho04
       25290_3         short     chottier R             0:05      1 tycho04

contrôle des SLURM_ARRAY_JOB

Toutes les fonctionnalités de scontrol et scancel peuvent être utilisées :

sur tout les SLURM_ARRAY_JOB : scontrol update --job=25290
sur une seule tâche : scontrol update --job=25290_2
sur une sélection de tâches : scontrol update --job=25290_[1-4,7] (s'applique sur 1, 2, 3, 4 et 7)

Soumission d'un job "finisher"

Il est possible de soumettre un job qui ne se lancera qu'après la fin de l'exécution du SLURM_ARRAY_JOB : sbatch --depend=aftercondition:jobid(s) finisher.slurm. Le job finisher ne se lancera que lorsque la condition aftercondition sera réalisée.

Plusieurs aftercondition sont possibles :

after : satisfait quand toutes les tâches sont lancées
afterok : satisfait quand toutes les tâches sont achevées sans erreurs
afterany : satisfait quand toutes les tâches sont achevées
afternotok : satisfait quand toutes les tâches sont achevées, et qu'au moins une ait produit une erreur.

On peut ainsi spécifier un job finisher pour tout le SLURM_ARRAY_JOB

sbatch --depend=afterok:25290 finisher.slurm

mais aussi pour un job spécifique :

sbatch --depend=afterok:25290_5

Enfin on peut aussi lancer un réparateur

sbatch --depend=afternotok:25290 execfixer.slurm

Soumission d'un job utilisant IDL

Nous avons un nombre limité de jetons IDL (cf Nombre de licences). Pour utiliser le moins de jeton un utilisateur doit soumettre tous ses jobs faisant appel à IDL sur un même noeud. Pour cela il faut utiliser la commande idl.slurm.sh, cette commande renvoie le nom du noeud ou l'utilisateur doit soumettre son job. Si l'utilisateur n'utilise pas encore de jeton IDL, le nom du noeud sera le noeud qui a le plus de processeurs disponible au cas ou l'utilisateur voudrait soumettre un ou plusieurs autres jobs. S'il utilise déjà un jeton IDL, la commande va regarder si on peut soumettre un autre job sur le même noeud. Le résultat de la commande dépend du nombre de processeurs, de la taille mémoire et de la partition demandés. Quand il n'y a plus de noeud disponible, la commande renvoie 1.

Par exemple, je souhaite soumettre un job sur 4 proc avec 0.5 Go dans la partition medium :

tycho :~> idl.slurm.sh 4 0.5 medium
tycho03

La commande a vérifié que j'utilisais déjà un jeton IDL et qu'il restait suffisamment d'espace pour mon job. Je dois donc ajouter dans l'en-tête de mon script

#SBATCH --nodelist=tycho03

Travail interactif

Réservation d'un coeur sur le noeud interactif et exécution de Mathematica

  module load mathematica
  salloc -t 04:00:00 -p interactif -J mathematica srun --x11 mathematica

Réservation d'un coeur sur un le noeud interactif et exécution de Matlab

  module load matlab
  salloc -t 04:00:00 -p interactif -J matlab srun --pty --x11 matlab

Réservation d'un coeur sur le noeud interactif et ouverture d'une session sur ce noeud

  salloc [-t tempsMinute] [-J NomJob] -p interactif srun --pty bash
  ou
  salloc [-t tempsMinute] [-J NomJob] -p interactif srun --x11 xterm

Réservation d'un coeur et ouverture d'une session sur nag-serveur pour la compilation des bibliothèques NAG

  salloc [-t tempsMinute] [-J NomJob] -p nag srun --pty bash
  ou
  salloc [-t tempsMinute] [-J NomJob] -p nag srun --x11 xterm

Attention : la version actuelle de slurm ne permet pas d'utiliser l'option --x11. Il faut exécuter srun --pty bash pour réserver les ressources nécessaires et ensuite se connecter sur le noeud interactif : ssh -X interactif

Soumission d'un job utilisant le GPU

Il faut réserver un GPU en précisant l'option :

#SBATCH --gres=gpu:1

Les commandes de base

sbatch : soumission d'un job

  tycho:~$ sbatch MonProg.slurm
  Submitted batch job 381

Option : -x pour exclure des noeuds, par exemple les noeuds qui peuvent être préemptés

    tycho:~$ sbatch -x tycho[01-02,17-20] MonProg.slurm

ou dans le script :

    #SBATCH --exclude=tycho[01-02,17-20]

Une autre façon d'exclure les noeuds sur lequels la préemption peut avoir lieu :

    #SBATCH --constraint=public

Pour faire tourner un job sur type de noeud particulier :

    #SBATCH --constraint=tycho2013

scancel : destruction d'un job
```
  tycho:~$ scancel 381
```
scancel : destruction de tous ses jobs
```
  tycho:~$ scancel -u $USER
```

squeue : suivi d'un job

  tycho:~$ squeue 
  JOBID    PARTITION     NAME     USER  ST       TIME  NODES NODELIST(REASON)
    381         long  MonProg marchand   R 2-23:49:59      2 tycho[03-04]
    475       medium     Test vaillant   R      23:18      1 tycho06
    473       medium  MonProg marchand  PD       0:00      1 (resources)

sacct : récapitulatif des jobs sur une période

Par exemple afficher certains paramètres de tous les jobs soumis après le 1er Mars 2014 :

    tycho:~$ sacct -S 2014-03-01 -o jobid,user,nodelist,state
       JobID     User      NodeList     State
    -------- -------- ------------- ---------
      245    marchand       tycho03   TIMEOUT
      245.0                 tycho03 CANCELLED
      286    vaillant       tycho05 COMPLETED
      286.0                 tycho05 COMPLETED
      381    marchand  tycho[03-04]   RUNNING
      475    vaillant       tycho06   RUNNING
      473    marchand None assigned   PENDING

Pour connaitre la liste des paramètres :

    tycho:~$ sacct -helpformat

scontrol : visualisation et modification d'un job

  tycho:~$ scontrol show job {jobid}
  tycho:~$ scontrol update JobID={jobid} TimeLimit=10:00:00

sview : interface graphique qui permet de voir l'état général du système

Liste des variables d'environnement définies par SLURM lors de l'exécution d'un job :

SLURM_CHECKPOINT_IMAGE_DIR=/home/$USER/MonRep
SLURM_CPUS_ON_NODE=16
SLURMD_NODENAME=tycho03
SLURM_GTIDS=0
SLURM_JOB_CPUS_PER_NODE=16(x2)
SLURM_JOB_ID=381
SLURM_JOBID=381
SLURM_JOB_NAME=MonProg
SLURM_JOB_NODELIST=tycho[03-04]
SLURM_JOB_NUM_NODES=2
SLURM_LOCALID=0
SLURM_MEM_PER_NODE=1024
SLURM_NNODES=2
SLURM_NODEID=0
SLURM_NODELIST=tycho[03-04]
SLURM_NPROCS=32
SLURM_NTASKS=32
SLURM_PRIO_PROCESS=0
SLURM_PROCID=0
SLURM_SUBMIT_DIR=/home/$USER/MonRep
SLURM_TASK_PID=25434
SLURM_TASKS_PER_NODE=16(x2)
SLURM_TOPOLOGY_ADDR_PATTERN=node
SLURM_TOPOLOGY_ADDR=tycho03

Commandes de gestion de l'espace /scratch

L'espace /scratch est local à chaque noeud.

A la fin du script, les données de scratch doivent être recopiées sur une des zones partagées (obs, data ou poubelle) puis être effacées de l'espace /scratch de chacuns des noeuds alloués à l'exécution du job.

En cas d'interruption du job (dépassement de la limite de temps par exemple) des données vont rester sur les noeuds et il faudra retrouver les noeuds sur lesquels elles sont restées et les effacer en se connectant par ssh sur chacun des noeuds. Des utilitaires sont là pour vous aider :

scratch_ls : liste le contenu de /scratch/$USER sur tous les noeuds
scratch_du : affiche l'espace occupé par /scratch/$USER sur tous les noeuds
scratch_rm tycho[90-92,95] : efface le contenu de /scratch/$USER sur les noeuds tycho90 à tycho92 et tycho95
scratch_rm -a : efface le contenu de /scratch/$USER sur tous les noeuds. Il faut s'assurer auparavant que vous n'avez aucun job en cours d'exécution.

Ces commandes utilisent le shell distribué pdsh pour executer une commande sur tout ou partie des noeuds. Par exemple :

Lister le contenu d'un répertoire sur tous les noeuds :

pdsh -a ls -l /scratch/$USER
Idem mais avec une meilleure présentation :

pdsh -a ls -l /scratch/$USER | dshbak

Remarque : Il est normal que ces commandes affichent un message d'erreur lorsqu'elles se connectent à des noeuds éteints par slurm.