> 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.

Une présentation de la grappe tycho et de son utilisation à été faite (support de présentation)

Description et caractéristiques techniques du 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
    
  • 16 nœuds : tycho[01-16] (Octobre 2013) (feature=tycho2013)

     16 coeurs, Intel Xeon E5-2670 à 2.60 GHz
    
     64 Go de mémoire/nœuds
    
     1,7 To d'espace disque local
    
  • 4 nœuds : tycho[17-20] (Juin 2014) (feature=tycho2013)

     16 coeurs, Intel Xeon E5-2650 v2 à 2.60 GHz
    
     64 Go de mémoire/nœuds
    
     0,9 To d'espace disque local
    
  • 4 nœuds : tycho[21-24] (Octobre 2015) (feature=tycho2015)

     16 coeurs, Intel Xeon E5-2640 v3 à 2.60 GHz
    
     64 Go de mémoire/nœud
    
     1,7 To d'espace disque local
    
  • 4 nœuds : tycho[29-32] (Mars 2016) (feature=tycho2015)

     16 coeurs, Intel Xeon E5-2640 v3 à 2.60 GHz
    
     64 Go de mémoire/nœud
    
     1,7 To d'espace disque local
    
  • 4 nœuds : tycho[33-36] (Septembre 2017) (feature=tycho2015)

     24 coeurs, Intel Xeon E5-2650 v4 à 2.20 GHz
    
     128 Go de mémoire/nœud
    
     1,6 To d'espace disque local
    
  • 8 nœuds : tycho[37-44] (Décembre 2017) (feature=tycho2015)

     16 coeurs, Intel Xeon Silver 4110 à 2.10GHz
    
     96 Go de mémoire/nœud
    
     0,7 To d'espace disque local
    
  • 4 nœuds : tycho[45-48] (Décembre 2017) (feature=tycho2015)

     24 coeurs, Intel Xeon Gold 5118 à 2.30GHz
    
     128 Go de mémoire/nœud
    
     1,6 To d'espace disque local
    
  • 4 nœuds : tycho[49-52] (Décembre 2017) (feature=tycho2015)

     24 coeurs, Intel Xeon Gold 5118 à 2.30GHz
    
     192 Go de mémoire/nœud
    
     1,6 To d'espace disque local (public)
    
     6,7 To d'espace disque local (pour gaia)
    
  • 4 nœuds : tycho[53-56] (Novembre 2018) (feature=tycho2015)

     28 coeurs, Intel Xeon Gold 5120 à 2.20GHz
    
     96 Go de mémoire/nœud
    
     1,6 To d'espace disque local (public)
    
  • 1 nœud : tycho25 (Juillet 2015) (feature=tycho2015)

     16 coeurs, Intel Xeon E5-2667 v3 à 3.2 GHz
    
     96 Go de mémoire
    
     3,6 To d'espace disque local
    
     1 GPU Tesla K20Xm
    
  • 1 nœud : tycho26 (Octobre 2015) (feature=tycho2015)

     16 coeurs, Intel Xeon E5-2667 v3 à 3.2 GHz
    
     64 Go de mémoire
    
     1,7 To d'espace disque local
    
  • 2 nœud : tycho[27,28] (Janvier 2016) (feature=tycho2015)

     24 coeurs, Intel Xeon E5-2690 v3 à 2.6 GHz
    
     256 Go de mémoire/nœud
    
     1,7 To d'espace disque local
    

Logiciels et accès

Tous les nœuds 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

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édiaires 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, le fichier $HOME/.profile charge les modules suivants : intel, openmpi et jdk.

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 nœuds/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 :

  • maup (Mise AU Point) : maximum 5', sur tous les nœuds sauf les nœuds réservés ;
  • short : maximum 1h, sur les nœuds tycho[03-16,53-56], par défaut ;
  • medium : maximum 1j, sur les nœuds tycho[01-24,26-32,53-56] ;
  • long : maximum 5j, sur les nœuds tycho[01-02,04-15,17-48] ;
  • verylong : maximum 15j, sur les nœuds tycho[01-02,04-11,17-32] ;
  • low : maximum 15j, sur les nœuds tycho[03-16].

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

  • gaia : maximum 15j, les nœuds tycho[02,21,33-36,49-52] ;
  • gaiaservice : maximum 15j, les nœuds tycho[02,21,49-52], plus prioritaires que la partition gaia dont elle préempte les jobs ;
  • mis : maximum 15j, les nœud tycho[01,22,23,24,37-44];
  • misservice : maximum 15j, le nœud tycho[01,22], plus prioritaire que la partition mis dont elle préempte les jobs ;
  • skybot : maximum 15j, les nœuds tycho[17-20].
  • grace : maximum 15j, le nœud tycho25.
  • virage : maximum 15j, le nœud tycho26.
  • plato : maximum 15j, les nœuds tycho[27,28].
  • mosaic : maximum 15j, les nœuds tycho[29-32].

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

  • nag : maximum 15j, le nœud nag-serveur.

Les jobs non prioritaires qui s'exécutent sur les nœuds dédiés aux queues gaia, mis, skybot, grace, virage, plato ou mosaic sont susceptible 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 --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 nœuds 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 nœud est de 16.

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 nœud. 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 un des nœuds et exécution de Mathematica

      salloc -t 04:00:00 -p medium -J mathematica srun --x11 mathematica
    
  • Réservation d'un coeur sur un des nœuds et exécution de Matlab

      salloc -t 04:00:00 -p medium -J matlab srun --pty --x11 matlab
    
  • Réservation d'un coeur sur un des nœuds et ouverture d'une session sur ce noeud

      salloc [-t tempsMinute] [-J NomJob] -p [partition] srun --pty bash
      ou
      salloc [-t tempsMinute] [-J NomJob] -p [partition] 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
    

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és 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.

Accès à l'IDRIS

L'accès aux serveurs de l'IDRIS est possible depuis tycho.obspm.fr

Statistiques d'utilisation

Statistiques pour l'année 2018, temps d'attente par partition

Statistiques pour l'année 2017

Statistiques pour l'année 2016

Statistiques pour l'année 2015

Statistiques pour l'année 2014

Statistiques pour l'année 2013