FAQ sur le cluster

Les abonné(e)s à la liste cluster sont invité(e)s à mettre ici leurs trucs et astuces concernant l'utilisation du cluster.

La version à jour (anglaise) de cette page est disponible depuis cluster.

A - Présentation du cluster

1. Description technique du cluster

TAURUS
Taurus
Nombre de cœurs 340
Puissance crête estimée 1 TFlops
Type CPUs 50 x Intel(©) Xeon(©) E5440 - 4 cœurs à 2.83GHz
10 x AMD(©) Opteron(©) 6134 - 8 cœurs à 2.3 GHz
10 x AMD Opteron™ 4184 - 6 cœurs à 2.8 GHz
Noeud maître Bull Novascale R460
Noeud de calculs 12 x Bull Novascale R422
5 x Transtec Calleo 351
5 x Dell PowerEdge R415
Configuration mémoire 2 Go de RAM par cœur en moyenne
Mémoire totale 700 Go
Capacité disques 2,5 To
Interconnexion 2 x Gigabit Ethernet
Système d'exploitation GNU/Linux
Distribution Rocks 5.x - CentOS 5.x
Principaux logiciels Compilateurs et librairies GNU, OpenMPI, MPICH, MPICH2

2. Qui peut accéder au cluster ?

Tous les membre du LERIA peuvent accéder au cluster. Il suffit de demander la validation de son compte sur le cluster en envoyant un mail à technique (at) info.univ-angers.fr

Des comptes invités sont possibles après accord avec le laboratoire LERIA.

B - Utilisation du cluster

1. Comment se connecter au cluster ?

Les utilisateurs ne peuvent se connecter que par SSH :

ex. : ssh -Y monlogin@taurus.info-ua

et les transferts de fichiers par sftp :

ex. : sftp monlogin@taurus.info-ua

2. Comment bien débuter avec le cluster ?

SGE est un gestionnaire de ressources (job scheduler) qui permet à plusieurs utilisateurs réserver des ressources pour passer des travaux dès que ces ressources sont disponibles. Il est impératif d'utiliser SGE (Sun Grid Engine) pour soumettre des calculs au cluster. Le frontal ne doit jamais être utilisé comme nœud de calcul.

Les commandes de base sont:

  • qsub : permet de soumettre un job au cluster par l'intermédiaire d'un script shell
ex.: qsub -m bea -M $USER@univ-angers.fr test.sh
  • qlogin : permet de demander un shell interactif sur une machine du cluster (A utiliser avec 'screen' pour pouvoir récupérer ensuite le shell)
ex.: screen -d -m qlogin -m bea -M $USER@info.univ-angers.fr -now no 

⇨ Attendre le mail puis se connecter sur le nœud avec : screen -r

  • qrsh : cette commande ne semble ne pas fonctionner sur le cluster. Voir la commande qlogin.
  • qstat : affiche les jobs en cours de l'utilisateur (tous par défaut)
ex.: qstat -u moi
  • qstat-all : affiche les jobs de tous les utilisateurs
ex. : qstat-all | less
  • qhost : affiche les informations sur les nœuds du cluster.
ex.: qhost -j

3. Comment soumettre des travaux ?

Il existe 1 seule file d'attente (queue) comprenant 3 environnements parallèles spécifiques.

Cas général : all.q

Cette queue contient la totalité des nœuds de calcul du cluster et permet de lancer aussi bien des jobs interactifs que des batchs sans limitation de ressources ou de durée. C'est la destination par défaut des jobs soumis par qsub. C'est une file de type FIFO.

Utilisation : qsub test_sequentiel.sh

La commande qstat affiche tous les travaux (en cours ou en attente d'exécution).

4. Comment limiter l'utilisation des ressources ?

On doit limiter l'utilisation des ressources d'un job (mémoire vive, espace disque, …) :

  • par simple courtoisie envers les autres utilisateurs,
  • pour blinder ses jobs en cas de comportement anormal,
  • pour ne pas commencer un job sur un nœud où d'autres jobs monopolisent déjà beaucoup de ressources.
L'argument à utiliser pour limiter les ressources est '-l' :
ex1.: qsub -l h_vmem=2G test.sh
ex2.: qsub -l h_vmem=1G,mem_free=800M test.sh
ex3.: qsub -l h_fsize=10M test.sh

La ressource h_vmem représente la limite maximum de mémoire pouvant être utilisée, mem_free est la mémoire minimum disponible nécessaire pour lancer le job et h_fsize est la taille maximum d'un fichier produit par le job.

Pour obtenir de l'aide spécifique:
man 5 complex

Pour voir la liste des ressources disponibles :

qconf -sc

5. Comment ne pas monopoliser toutes les ressources : Les environnements parallèles

Il existe 3 environnements parallèles visant à partager au mieux les ressources du cluster entre les différents types de travaux :

  • param : pour les tests paramétriques

Cet environnement spécifique demande à SGE d'essayer de remplir chaque nœud avant d'assigner des jobs a un autre nœud. De plus, le nombre de slots (=cœurs) étant limité aux 3/4 de l'ensemble (soit 250 au 9/11/2012), cet environnement permet de ne pas “bloquer” complètement la file FIFO avec un très grand nombres de jobs et, ainsi, de laisser passer des travaux soumis hors de cet environnement même s'ils sont arrivés postérieurement.

:!: Le paramètre indiquant le nombre de slots par job requis devrait, sauf exceptions, toujours être égal à 1 (1 cœur / job) :!:

Utilisation : qsub -pe param 1 test_param.sh
  • threaded : pour les jobs nécessitant la réservation d'un nœud complet (benchs, multi-threads, …)

Cet environnement restreint le job à rester sur un seul nœud permettant ainsi la réservation d'un nœud complet pour le job soumis si le paramètre indiquant le nombre de slots par job est égal à 8 (8 cœurs = 1 nœud).

:!: Le paramètre indiquant le nombre de slots par job ne peut être supérieur à 8 :!:

Utilisations : qsub -pe threaded 8 test_bench.sh
               qrsh -pe threaded 8
  • mpi : pour les jobs parallèles

Cet environnement sert pour les jobs parallèles utilisant plusieurs nœuds à la fois (ie. à mémoire distribuée).

Utilisations : qsub -pe mpi 16 test_mpi.sh

6. Comment choisir le type des processeurs (Intel Xeon 2.83Ghz, AMD Opteron 2.3Ghz ou AMD Opteron 2.8Ghz) ?

Par défaut, les travaux sont exécutés dès qu'une ressource suffisante est disponible. Cependant, il est possible de demander un type de processeurs particuliers en utilisant les groupes qui ont été définis parmi les nœuds de calculs :

  • Pour les processeurs Intel Xeon™ E5440 @ 2.83GHz (192 cores) :
 qsub -q "*@@intel-E5440" test.sh
  • Pour les processeurs AMD Opteron™ 6134 @ 2.3GHz (80 cores) :
 qsub -q "*@@amd-6134" test.sh
  • Pour les processeurs AMD Opteron™ 4184 @ 2.8GHz :
 qsub -q "*@@amd-4184" test.sh

7. BENCHMARKS / TESTS : Comment demander la réservation d'un nœud complet

  • Pour un noeud Intel E5440 - 8 cœurs @ 2,83Ghz :
  screen -d -m qlogin -q "*@@intel-E5440" -pe threaded 8 -m bea -M $USER@info.univ-angers.fr -now no

⇨ Attendre le mail puis se connecter sur le nœud avec : screen -r

  • Pour un noeud AMD 6134 - 16 cœurs @ 2,3Ghz :
  screen -d -m qlogin -q "*@@amd-6134" -pe threaded 16 -m bea -M $USER@info.univ-angers.fr -now no

⇨ Attendre le mail puis se connecter sur le nœud avec : screen -r

  • Pour un noeud AMD 4184 - 12 cœurs @ 2,8Ghz :
  screen -d -m qlogin -q "*@@amd-4184" -pe threaded 12 -m bea -M $USER@info.univ-angers.fr -now no

⇨ Attendre le mail puis se connecter sur le nœud avec : screen -r

Dans le cadre de benchmarks, pensez à recopier vos données et binaires dans /tmp avant d'exécuter votre code afin de vous isoler du réseau dont les performances dépendent fortement de l'activité sur les autres nœuds.

8. Comment supprimer un ou plusieurs jobs ?

qdel -f <num_job1> <num_job2> ... <num_jobn>
  • Pour supprimer tous mes travaux :
qdel -f -u $USER

9. Les Array Jobs

Un Array Job est un job devant être exécuté de multiples fois, par exemple lors d'un test paramétrique. Ainsi, SGE lance exactement le même script, la seule différence entre les runs étant la variable d'environnement $SGE_TASK_ID. Cette variable peut, par exemple, être utilisée comme graine d'un générateur de nombres pseudo-aléatoires ou correspondre au numéro d'une instance ou encore d'une combinaison pré-générée de paramètres que le script ira chercher dans un fichier.

Un array job est soumis en utilisant le paramètre '-t' :

ex.: qsub -t 1-100 test.sh

Cette commande lancera 100 fois le script test.sh avec à chaque fois une valeur différente de $SGE_TASK_ID {1, …, 100}.

On peut souhaiter n'utiliser le script que toutes les N fois :

ex.: qsub -t 1000-1400:100 test.sh

Cette commande lancera 5 fois le script test.sh avec à chaque fois une valeur différente de $SGE_TASK_ID {1000, 1100, 1200, 1300, 1400}.

Avantages par rapport à l'envoi de centaines de jobs individuels :

  • Un array job permet d'avoir un affichage plus concis de la file d'attente puisque l'ensemble des tâches non-exécutées d'un array job n'occupe qu'une ligne lors d'un affichage qstat.
  • La suppression de toutes les tâches d'un array job se fait en utilisant le nom/identifiant du job (qdel JOB) et la suppression d'une seule tâche spécifique en utilisant son numéro (qdel JOB.TASKID). Il est donc plus facile de faire des suppressions sélectives si les premiers résultats montrent que le job ne fonctionne pas comme prévu.

10. Comment définir des dépendances entre jobs ?

Il peut arriver d'avoir besoin des résultats d'un job pour en lancer un autre. On peut bien sûr exécuter le premier job, attendre qu'il termine, puis lancer le second en fonction du résultat obtenu. Ou alors on peut utiliser les dépendances pour soumettre les deux jobs en même temps ; le second job ne s'exécutant que lorsque le premier sera terminé.

qsub -N etape1 test1.sh
qsub -hold_jid etape1 -N etape2 test2.sh

Dans l'exemple ci-dessus, les jobs etape1 et etape2 sont soumis à la file d'attente. etape1 s'exécutera dès que possible mais l'argument -hold_jid etape1 force à attendre que etape1 soit terminée avant d'exécuter etape2.

Cela fonctionne aussi avec les array jobs. Cela peut être utile par exemple pour agréger en un seul fichier tous les petits fichiers produits par un array job.

qsub -pe param 1 -N monjob -t 1-50 test.sh
qsub -hold_jid monjob -N analyse analyse.sh

Ici le job analyse s'exécutera seulement à l'issue des 50 tests paramétriques dont monjob est constitué.

Exemple : Compresser les fichiers produits par des jobs

Si vous lancez beaucoup de jobs qui produisent beaucoup de résultats, il peut être judicieux de compresser les fichiers produits afin de ne pas utiliser trop d'espace sur le disque.

Il nous faut donc un script qui lance les jobs produisant les résultats et qui fini par un job qui attend que les jobs précédents soient terminés pour compresser puis supprimer les fichiers générés.

On aura donc un script principal submit.sh :

#!/bin/bash                                                   
                                                             
# Création d'une chaîne représentant un groupe de jobs.       
# Cette chaîne préfixera le nom de chaque job de ce groupe.   
group="g1"                                                    
                                                              
# Soumission des jobs                                         
qsub -N ${group}job1 job1.sh                   
qsub -N ${group}job2 job2.sh       
# etc  
                                                       
# Soumission du job qui va traiter les fichiers produits
qsub -N postprocessing -hold_jid ${group}* postproc.sh $group 

et un script de post-traitement postproc.sh :

#!/bin/bash 
#$ -cwd                                                       
                                                              
# Le seul paramètre est le nom du groupe
group=$1                                                      
                                                              
tar -czf archive_${group}.tar.gz ${group}*                    
rm ${group}*  

11. Scripts

Au lieu de passer des paramètres dans la commande qsub, il est possible, et souvent plus pratique, de les insérer dans le script exécuté par qsub. Dans le script les lignes contenant des paramètres, ou directives, sont préfixées par #$.

Vous trouverez dans l'archive qsub_template.zip un script modèle avec une version commentée en français et une autre en anglais. Ce script contient un nombre de directives utiles dont celles sur cette page et quelques autres. Vous êtes encouragé à utiliser ce script et à le modifier selon vos besoins.

12. Comment savoir si le cluster est disponible ?

L'activité du cluster est visible en temps-réel depuis le réseau interne sur l'interface Ganglia

13. Que faire en cas de problème ?

Regarder dans le fichier d'erreur généré qui est de la forme <nom_du_job>.exxxxx

Vérifier que le chemin /opt/gridengine/bin/lx26-amd64 est bien en tête de la variable d'environnement $PATH

Faire attention à la gestion de la mémoire dans vos programmes…

Penser également à utiliser la liste de diffusion cluster qui regroupe les l'ensemble des utilisateurs du cluster ainsi que l'équipe technique chargée de son administration.

14. Où trouver de la documentation ?

C - Historique du Cluster (Changelog)

Année Version Distribution (OS) Nombre et type de CPUs Puissance de calculs estimée
2003 1.0 Alinka Raisin 30 x Intel Pentium-4 2.4 144 GFlops
2006 1.1 Rocks cluster 4.3 30 x Intel Pentium-4 2.4 144 GFlops
2008 2.0 Rocks cluster 5.0 50 x Intel Xeon-4Cores 2.8 1680 GFlops
2010 2.1 Rocks cluster 5.3 50 x Intel Xeon-4Cores 2.8 + 10 x AMD Opteron-8Cores 2.3Ghz 2200 GFlops
2012 2.2 Rocks cluster 5.4 50 x Intel Xeon-4Cores 2.8 + 10 x AMD opteron-6Cores 2.8Ghz 2200 GFlops
faq/cluster_fr_old.txt · Dernière modification: 16/12/2014 09:17 par De Germain Frantz
CC Attribution-Noncommercial-Share Alike 4.0 International
Driven by DokuWiki Recent changes RSS feed Valid CSS Valid XHTML 1.0