Les serveurs interactifs (connexion, espaces disques, modules)
Le cluster de calcul (qsub, PBS, jobs interactifs, suivi des jobs)
Accès au cluster de calcul
La soumission de traitement au cluster de calcul est gérée par le gestionnaire Torque. Torque fournit à la fois un gestionnaire de ressources qui permet de contrôler la charge de chacun des noeuds du cluster, un gestionnaire de batch qui est chargé de transmettre les traitements soumis par les utilisateurs, et un ordonnanceur (Maui) qui permet de programmer l’exécution des traitements sur chacun des noeuds en fonction des ressources disponibles. L’accès au cluster se fait depuis les serveurs interactifs (camelot, loholt1 et 2, ciclad et ciclad2) à travers le gestionnaire de batch grâce à la commande qsub. Le gestionnaire de batch gère ensuite l’exécution des jobs sur un noeud de calcul ou un autre.
Tous les espaces disques utilisateurs et données sont visibles du cluster.
1- Les files ou queues d’éxécution :
Des files (ou queues) ont été configurées pour la soumission des jobs en fonction de la durée des calculs. Si un job dépasse le temps maximum alloué à la file d’exécution, il est automatiquement tué par le gestionnaire de batch.
Pour accéder à la liste des queues d’éxécution : qstat -q
Pour connaître toutes la caractéristiques d’une queue : qstat -Qf nomDeLaQueue Exemple : qstat -Qf std
Par défaut, si le nom de la queue n’est pas précisée, le job sera lancé sur la queue « std ». La limite du temps d’exécution de cette queue est 6h CPU.
2- La soumission des jobs avec la commande qsub
Le job soumis doit être un script Shell, Perl, Python, etc. Pas un binaire. L’utilisateur doit préciser les ressources nécessaires pour l’exécution de son job (memoire, temps d’exécution mamimum, nombre de cpu …). Il faut ajuster au mieux les ressources nécessaires par job car elles seront réservées pour son exécution et ne seront donc plus disponibles pour les autres utilisateurs.
qsub -j oe : joint les fichiers erreur et sortie standard en un seul
qsub -k oe : garder les sorties standard et d’erreur (exemple : qsub -j oe -k oe job.sh : cette commande permet de suivre en temps réel les sorties de job et d’en enregistrer les traces dans un fichier)
qsub -l <ressource = XX> : requiert une ressource particulière (exemple : qsub -l mem=128mb job.sh–> requiert 128 mb de mémoire disponibles)
qsub -l mem=10gb -l vmem=12gb toto.sh : utilisation 10gb de mémoire et 12gb de mémoire vistuelle
qsub -l walltime=20:00:00 : utilisera 20h de « walltime
qsub -v variable_name=variable_value : pour passer des variables au script (exemple : qsub -v var= »toto » : définit la variable var et l’initialise à la valeur toto
3-Un premier exemple pour débuter
4-Les variables d’environnement PBS
Des directives d’exécution du job peuvent être mises directement dans le script en utilisant une ligne commançant par #PBS.
Exemple : le fichier my_shell_script contient les lignes suivantes :
#!/bin/bash
#PBS -q week
Soumission : qsub my_shell_script
est équivalent à : « qsub -q week my_shell_script » si l’instruction PBS n’était pas dans le script.
Lien vers un exemple de script plus complet : example.pbs
Soumission : qsub -v filename= »data.dat » example.pbs
Fichier de sortie : Un seul fichier example.out est créé dans le répertoire $HOME de l’utilisateur, contenant les sorties standards et les erreurs éventuelles du programme a.out
La liste des ressources pouvant être demandées est donnée dans le man de pbs_resources
Les variables d’environnements utilisable dans un script :
Quand un job est soumis au gestionnaire de batch, un certain nombre de variables sont introduites dans l’environnement d’exécution du job, et peuvent être utilisées dans le shell-script. Ces variables sont :
| Variable | Description |
| PBS_JOBNAME | user specified jobname |
| PBS_O_WORKDIR | job’s submission directory |
| PBS_ENVIRONMENT | N/A |
| PBS_TASKNUM | number of tasks requested |
| PBS_O_HOME | home directory of submitting user |
| PBS_MOMPORT | active port for mom daemon |
| PBS_O_LOGNAME | name of submitting user |
| PBS_O_LANG | language variable for job |
| PBS_JOBCOOKIE | job cookie |
| PBS_NODENUM | node offset number |
| PBS_O_SHELL | script shell |
| PBS_JOBID | unique pbs job id |
| PBS_O_HOST | host on which job script is currently running |
| PBS_QUEUE | job queue |
| PBS_NODEFILE | file containing line delimited list on nodes allocated to the job |
| PBS_O_PATH | path variable used to locate executables within job script |
5-Lancer un job interactif :
qsub -IVX : L’option -I indique à qsub de commencer un job interactif. L’option -X permet de transmettre l’environnement graphique ou « forwarder le DISPLAY ».
Par exemple la commande : qsub -IVX -l walltime=00:30:00,nodes=2:ppn=2
exécutera un job interactif avec un walltime de 30 minutes, en utilisant 2 noeuds et deux processeurs par noeud. Après cette commande, il faut attendre que Torque démarre le job. Comme pour tout job géré par Torque, un job interactif doit attendre qu’une queue comprenant le nombre de noeuds requis se libère. Une fois que le job est démarré, qsub retourne « ready ». Vous êtes alors logué sur un des noeuds de calcul, et vous pouvez lancer vos programmes en mode interactif. Une fois que vos travaux sont finis, vous pouvez utiliser la commande exit pour terminer votre session qsub.
Le mode interactif reste disponible tant que vous ne dépassez pas le walltime de la queue d’exécution ou celui que vous avez indiqué au lancement de qsub.
6 -La Surveillance des jobs
qstat ou showq : liste l’ensemble des jobs du cluster
qstat -a : liste l’ensemble des jobs du cluster avec plus d’information
qstat -n : liste les noeuds utilisés par les jobs
qstat -u username : liste des jobs pour un utilisateur
7- Etat du cluster
check-cluster : état du cluster
pbsnodes -a : état de chaque noeud du cluster
pbsnodes -l : liste des noeuds hors service
8- Pour aller plus loin :
Documentation Torque : http://www.adaptivecomputing.com/support/documentation-index/torque-resource-manager-documentation/
Documentation Maui : http://docs.adaptivecomputing.com/maui/a.gcommandoverview.php