Cluster de calcul, SGE

Acces et interactions avec le cluster MBB (tickets, création de compte...)

cluarchi

Vue d ensemble

Nous parlons ici de cluster de calcul : groupe de machines auxquelles on ne se connecte pas directement

  • Composé d'un gestionnaire de ressources et d'un ordonnanceur.
  • Organisation classique : Un noeud maitre connait tous les noeuds de calcul et surveille leur état. Il possède un système de fichier partagé à tous les noeuds de calcul pour l'accès aux fichiers des utilisateurs. Les systèmes d'exploitation des noeuds de calcul sont identiques (mêmes librairies, programmes...) mais les ressources matérielles peuvent être différentes.
  • Lors d'une soumission, il applique une stratégie de répartition de charge et des règles de priorités liées à des files d'attente pour allouer les ressources aux utilisateurs.
  • L'unité de tâche à effectuer est le JOB. Un JOB est une commande ou un script lancé sur le cluster.
  • L'unité de ressource est le SLOT souvent associé au coeur (pas la machine). Le nombre de SLOT est le nombre de "processus" simultanés possibles sur une machine.

Vocabulaire

  • noeud maitre : C'est la machine à laquelle on se connecte pour soumettre les JOBS.
  • noeud de calcul : C'est une des machines qui va travailler pour le cluster et exécuter des JOBS.
  • JOB : C'est une tâche à effectuer sur un noeud du cluster.
  • coeur : Un coeur de calcul est un coeur d'un processeur d'un noeud du cluster.
  • SLOT : Sur chaque noeud de calcul, on déclare un nombre de SLOTS qui équivaut au nombre maximum de tâches à exécuter en parallèle sur ce noeud.
  • files d'attente (queue) : Elles symbolisent un groupe de noeuds de calcul. Lorsqu'on soumet un JOB dans une file auquel on a accès, celui-ci sera lancé quand les ressources seront disponibles.

Ce découpage en queues permet par exemple de scinder le cluster selon les accès des utilisateurs (découpage politique), ou selon les caractéristiques des machines (matériel, système, logiciels...), ou sur d'autres caractéristiques/politiques (temps d'exécution autorisé, environnements disponibles, etc...)

Outils

rapide aperçu de qstat (on le verra plus tard)

MBB

Le cluster MBB possède 360 coeurs et environ 2To de RAM répartis sur 23 machines/noeuds (au 02/12/2015).

  • Comment y accéder ? :

    • SSH : accès à un terminal distant et copie de fichiers (restrictions, le service SSH est accessible depuis l'intérieur de l'université (dont VPN). Pour autoriser une IP supplémentaire il faut passer par le système de tickets). La file d'attente utilisable par les utilisateurs SSH est cemeb.q.
    • WEB : site web pour utilisation basiques des outils que nous avons interfacé http://mbb.univ-montp2.fr
  • Comment sont gérées les données ?

    • Les données des utilisateurs sont sur des NAS, c'est à dire sur des machines dédiées à la gestion de gros espaces de stockage accessibles par le réseau.
    • Le home directory de chaque utilisateur est monté sur tous les noeuds. De cette manière, du point de vue d'un JOB (sur un noeud de calcul), les chemins sont identiques à ceux du noeud maitre. Les homes des utilisateurs sont tous sur un des NAS A DEFINIR de la plateforme. Ils sont montés par NFS.
    • QUOTA : Le quota par défaut est de 70 Go. Il peut être augmenté si un utilisateur a des besoins particuliers et en fait la demande.
    • Si le traitement effectué fait beaucoup d'accès disque, il peut être utile de déplacer les données et d'écrire les résultats sur un système de fichier local au noeud pour améliorer les performances. Le système de fichier partagé entre les noeuds est forcément moins performant qu'un système de fichier local. Pour travailler en local sur un noeud on peut utiliser /tmp mais il est à la charge de l'utilisateur de nettoyer ce dossier par la suite. La manière la plus propre et conventionnelle de travailler en local est le $TMPDIR. Cette variable contient le chemin absolu vers un dossier qui n'existe que pendant la durée du JOB. ATTENTION il ne faut pas oublier de récupérer les fichiers produits dans ce TMPDIR car il seront effacés à la fin du JOB.
      cp -r $TMPDIR/* $HOME/mes_resultats/
      

Par exemple, il est possible d'utiliser /export/scrach comme $TMPDIR sur les noeuds de calcul, qui est une partition locale à chaque noeud, séparée du reste.

Accès SSH et utilisation basique

L'accès SSH est restreint par un pare feu. Il est possible d'accéder au cluster depuis le réseau de l'UM2. Pour un accès extérieur, vous pouvez vous connecter au VPN de l'université ou nous pouvons autoriser une adresse ou une plage d'adresses IP (déjà ouvert pour le CEFE). Pour demander l'autorisation, passez par le système de tickets : http://kimura.univ-montp2.fr/aide/index.php?a=add .

Linux

Sous GNU/Linux, un client SSH est déjà présent. Il permet de se connecter à un terminal distant et de transférer des fichiers du client vers le serveur et inversement.

Connexion au cluster par SSH

On accède au cluster de la manière suivante (après avoir fait une demande compte):

ssh username@162.38.181.18

# ou bien

ssh username@cluster-mbb.mbb.univ-montp2.fr

Si on se connecte avec l'option '-CX' ou '-CY', on peut lancer des programmes graphiques sur le cluster et ils seront affichés localement. Voici un exemple avec le visionneur d'image "Eye of gnome" qui s'appelle avec la commande "eog":

ssh -CX USER@162.38.181.18
eog ./images/image.png

eog va bien s'exécuter sur le cluster et ouvrir une image présente sur le cluster mais son affichage s'effectuera sur votre machine cliente.

Transfert de fichier par SSH

On peut copier des données dans son home du cluster depuis sa machine personnelle:

scp -r dossier_a_copier  username@162.38.181.18:CHEMIN

CHEMIN peut être un chemin absolu ou relatif, il est alors relatif à $HOME qui est "/home/username".

Une fois un résultat obtenu, on peut récupérer les résultats :

scp -r username@162.38.181.18:CHEMIN_RESULTATS  ./

Il est également possible d'utiliser sftp.

transfert de fichier avec rsync

Pour aller plus loin, l'outil rsync apporte un tas de fonctionnalités intéressantes dans le domaine du transfert de données.

On peut par exemple :

  • reprendre une copie interrompue avec l'option --partial.
  • compresser pendant le transfert
  • faire de la copie incrémentale (transférer uniquement ce qui n'est pas présent sur l'emplacement cible)
  • ...

Voila une documentation en français sur rsync: http://doc.ubuntu-fr.org/rsync

Windows

Sous windows, on peut utiliser le client SSH putty et filezilla ou winscp comme client SFTP pour le transfert de fichiers.

  • En cas de problème: http://kimura.univ-montp2.fr . Helpdesk => Nouvelle demande
  • UN PROBLEME CLASSIQUE est celui des retours à la ligne dans les fichiers texte qui sont différents sous Windows et les autres systèmes. On peut trouver des solutions en cherchant autour de dos2unix qui est un programme de conversion ou en cherchant sur le web autour des termes "CRLF" ou "retour chariot linux windows". On peut afficher les caractères invisibles sous Linux avec la commande "cat -vt mon_fichier" (les retours à la ligne Windows qui ne doivent pas apparaître en fin de ligne c'est ^M, sinon il faut convertir le fichier avec dos2unix).

Soumission de job

Ce qui est abordé dans ce paragraphe est détaillé et expliqué dans le dernier chapitre (SGE en détail).

Soumission normale

Une fois connecté en SSH sur le noeud maître, on peut soumettre des JOBS avec la commande qsub.

Les options basiques sont les suivantes :

  • -N pour donner un nom au JOB
  • -cwd IMPORTANT pour que le JOB s'exécute dans le même dossier que celui de la soumission
  • -q IMPORTANT c'est la file d'attente dans laquelle on soumet
  • -l IMPORTANT h_rt HH:MM:SS pour définir la durée maximum du job (il est possible de mettre des valeurs très élevées si on n'a aucune idée de la durée maximum)
  • -b y : on écrit à la suite de cette option la commande que l'on veut lancer (mettre des guillemets si la commande contient des espaces)

Soumission de job interactif

Etant donné que le noeud maître du cluster ne dispose pas de tous les programmes/outils installés sur les noeuds de calcul, on peut difficilement tester le bon fonctionnement d'un script directement à partir d'une connexion sur le noeud maître. SGE permet de soumettre un job spécial qui offre une session interactive sur le noeud de calcul qui accepte ce job.

qrsh est la commande à lancer sur le noeud maitre qui permet de lancer ce type de job. Une fois qrsh lancé, si le cluster est suffisamment libre pour accepter ce job, on se retrouve sur un noeud de calcul avec la possibilité de lancer des commandes dans le même environnement qu'un job normal.

Voici un exemple où l'utilisateur "robert" se trouve sur sa machine personnelle, se connecte sur le noeud maître du cluster mbb puis lance un "qrsh" pour ensuite se trouver dans un job sur un noeud de calcul.

robert@lamachinederobert:~$  ssh robert@162.38.181.18
robert@cluster-mbb:~$  qrsh
robert@@compute-0-19:~$  module load R-3.2.0
robert@@compute-0-19:~$  R

R version 3.2.0 (2015-04-16) -- "Full of Ingredients"
...

Une fois dans ce job interactif, robert peut lancer R, par exemple, qui n'est pas installé sur le noeud maître.

On constate également l'utilisation de module qui permet de charger différentes versions/environnements d'un logiciel Voir chapitre plus bas.

Editer sur le cluster

  • nano est un éditeur en ligne de commande très basique, il ne dispose pas d'historique et donc de fonction d'annulation.
  • vim est un éditeur très complet et puissant en ligne de commande. Il nécessite un temps d'apprentissage. Il permet de faire de la sélection par colonnes, des onglets, de lancer des commandes sur une sélection (...), et bien plus.
  • ssh -CX permet d'exécuter des programmes graphiques sur le cluster mais en les voyant en local. On peut donc utiliser n'importe quel éditeur graphique disponible sur le cluster (gedit, par exemple).

Quotas et limites

Chaque utilisateur sur le cluster a un quota d'utilisation disque de 70 Go.

Le nombre maximum de jobs, tout état confondus (en attente ou en cours d'exécution), est de 100.

La file d'attente par défaut est cemeb.q qui dispose de 88 slots. La queue cemeb20.q complète cemeb.q avec 80 coeurs supplémentaires.

Exercices interactions avec le cluster

Les comptes seront déjà créés avec les informations d'inscription à la formation.

  • connexion au cluster, creation de son sous-dossier exercice, transfert des données par scp, différence entre qrsh et ssh
ssh user@162.38.181.18
mkdir exercice1.1
cd exercice1.1
exit

Pour télécharger un fichier à partir d'une adresse HTTP depuis le terminal, vous pouvez utiliser la commande wget. Téléchargez le fichier http://mbb.univ-montp2.fr/MBB/uploads/data.zip sur votre machine locale puis sur le cluster à travers une connexion ssh.

wget http://mbb.univ-montp2.fr/MBB/uploads/data.zip

Pour transférer un fichier ou un dossier, on peut utiliser la commande scp qui effectue une copie par SSH.

scp -r ./exo1/* user@162.38.181.18:exercice1.1/
  • Si vous êtes sous windows : Téléchargez cette archive sur votre ordinateur : http://mbb.univ-montp2.fr/MBB/uploads/data.zip . Ensuite, transférez cette archive vers votre répertoire personnel sur le cluster avec filezilla ou winscp. Les paramètres de connexion sont les suivants :
    • serveur, hôte, machine : 162.38.181.18
    • port : 22
    • protocole : SFTP ou SCP
    • login : votre nom d'utilisateur fourni par mail avant la formation
    • mot de passe : votre mot de passe
  • Extraire l'archive dans un terminal avec la commande "unzip data.zip". Cela va créer un dossier data dans le dossier courant.

Logiciels sur le cluster

Organisation des logiciels

Logiciels sur le système

Beaucoup de logiciels sont installés sur le système des noeuds de calcul. Voir page listant les outils : http://kimura.univ-montp2.fr/calcul_isem/2011/05/programmes-installes-sur-le-cluster/

Pour vérifier facilement l'existence d'un logiciel sur les noeuds de calcul on aura besoin de qrsh. Ce programme, exécuté depuis le noeud maitre, va soumettre un JOB qui fournira à l'utilisateur un shell à l'intérieur du JOB. On se retrouve dans un contexte d'exécution de JOB mais avec la possibilité d'intéragir manuellement:

ssh username@cluster1.mbb.univ-montp2.fr
qrsh
blas<TAB> <TAB>

On peut donc essayer n'importe qu'elle commande dans le contexte d'un noeud de calcul et vérifier son comportement pour améliorer l'élaboration des futurs scripts à soumettre.

Logiciels dans /share/apps/bin

Certains logiciels sont disponibles dans le dossier /share/apps/bin qui est partagé à destination de tous les noeuds. C'est le cas de versions spécifiques et différentes de celle du système (comme samtools 1.18) mais aussi de multiples versions majeures d'un logiciel (comme raxml 7 et 8).

Logiciels dans son home

Si le logiciel qu'on souhaite utiliser n'est pas disponible, on peut le copier dans son home. Attention, si on utilise un binaire dynamique, il se peut que les librairies auxquelles il fait appel ne soient pas présentes sur le système des noeuds. il faut alors se débrouiller pour transporter les librairies avec le binaire ou bien le compiler en statique pour le rendre indépendant.

Utilisation de module pour changer de version

Sur les noeuds de calcul, plusieurs versions de certains logiciels sont présentes. La commande module permet de changer les variables d'environnement pour utiliser une version spécifique d'un logiciel par défaut.

La commande module permet de choisir une version du logiciel. Avec cette commande , on peut, par exemple, choisir la version de python (2.7 ou 3.3), de R (3.0.3, 3.1.3 ou 3.2.0).

Pour sélectionner R 3.2.0:

# à faire sur un noeud de calcul
module load R-3.2.0

Pour voir la liste des modules disponibles:

module avail

# ou encore utilisez la complétion en tapant la touche tabulation à la fin de la ligne suivante :
module load

Cas d'utilisation

Essayez d'installer le package blavaan sur un noeud de calcul en utilisant la version par defaut de R.

Le package blavaan disponible par le CRAN, nécessite R en version 3.1.0 au minimum.

Modifiez la version de R avec module et essayez à nouveau.

Cas particuliers

On peut aussi demander son installation: http://kimura.univ-montp2.fr/aide/index.php?a=add&catid=22

Dans certains cas, par exemple /share/apps/bin/paleomix (un pipeline de traitement NGS) ou IRAP, une préparation est nécessaire au lancement du logiciel. Bien souvent, un fichier README est disponible dans le dossier du programme.

Packages R

Savoir si un package R est présent

Depuis l'an dernier, nous avons fait le choix de n'installer plus aucun package R de manière générique. En effet, la quantité de packages rendaient cette solution intenable sur la durée (dépendance entre les versions, etc...). Vous devez donc l'installer vous-même dans votre home (voir ci-dessous).

Vous pouvez cependant demander de l'aide pour installer un package récalcitrant (ex: si ce dernier a des dépendances systèmes):

Quelques modules sont tout de même globalement présents dans

/share/apps/bin/R/R-$version/lib64/R/library

Installer un package R dans son home

R n'est pas installé sur le noeud maître et il ne faut rien effectuer sur le noeud maitre DONC :

qrsh
module load R-3.2.0
R
install.packages('mon_super_package')

va installer dans le home (qui est partagé entre les noeuds). On pourra donc ensuite utiliser ce package R sur tous les noeuds de calcul qui correspond à la version 3.2.0 de R.

Pour la gestion des dépendances, il vaut mieux utiliser install.packages plutôt que R CMD INSTALL.

Modules python

savoir si un module python est present

Un "module python" n'a rien à voir avec la commande module utilisée précédemment.

python
# puis une fois dans la console python :
import MODULE

Comment demander l'installation ? => http://kimura.univ-montp2.fr/aide/index.php?a=add&catid=22

Installer un module python dans son home :

Sur cette page sont listées les différentes méthodes pour installer un module python dans son HOME : https://my.bluehost.com/cgi/help/530

Exercices (logiciels sur le cluster)

  • lister le contenu de /share/apps/bin
ls /share/apps/bin
  • recherche de soft dans /share/apps/bin avec

    find /share/apps/bin -iname "*raxml*"
    
  • installation et utilisation d'un package R (abc par exemple) dans le dossier home

qrsh
R
library("ape")
install.packages("ape")
  • modification du PATH pour binaires dans le home
export PATH=$PATH:/home/username

SGE en détail

http://manuals.bioinformatics.ucr.edu/home/hpc

Monitoring

# voir les infos détaillées d'un job :
qstat -j JOBID

# voir la liste des jobs de tous les utilisateurs
qstat -u \*

# affiche la liste des noeuds de calculs et des jobs qui leur sont affectés
qstat -f

# restreint l'affichage à une file d'attente
qstat -q queue_name

Quelques commandes pour visualiser la configuration:

  • du cluster (qhost, qhost -j, qhost -l num_proc=8, qhost -l mem_total=8G )
  • des queues
    • qstat -f
    • qconf -sconf affiche toute la config (max_u_jobs ...)(man sge_conf pour les détails)
    • qconf -sq cemeb.q afficher la configuration de la queue cemeb.q (h_rt ...)(man queue_conf)
    • qconf -spl affichier la liste de tous les environnements parallèles (PE)
    • qconf -sp mpich afficher la configuration de l'environnement // (PE) mpich
  • qstat -s r (liste des jobs qui tournent) qstat -s p (liste les jobs en attente) ...
  • qmon (nécessite une connexion ssh avec le paramètre -X)
  • Vérifier combien y a t-il de queues et ce qui les différencie (qconf -sql afficher la liste de toutes les queues; qhost -q pour lister les hôtes qui hébergent ces queues)
  • qacct

Soumission

A la soumission, on doit préciser quelques informations par le biais d'options et aussi la commande à exécuter. Lorsque le JOB est terminé, on peut consulter les éventuels fichiers de résultat et les sorties (erreur et standard).

  • options importantes :
    • -l h_rt : le temps maximum estimé pour la durée du job
    • -cwd : le job sera exécuté dans le dossier courant au moment de la soumission
    • -b yes/no : permet de spécifier si on soumet une commande ([y]es) ou un script ([n]o)
    • -V : le contexte, donc toutes les variables d'environnement, seront conservées dans le job
  • options moins importantes :
    • -pe multithread8 2-8 : l'environnement parallèle (facultatif) pour soumettre des jobs multithreadés (ici, on demande entre 2 et 8 SLOTS)
    • -j y : fusionner la sortie d'erreur et la sortie standard en un seul fichier
    • -l hostname=HOST : permet de demander explicitement d'affecter le job soumis à une machine
    • -sync yes : si cette option est spécifiée, qsub ne rendra la main qu'à la fin de l'exécution du job
  • les sorties : Dès le lancement d'un job, on peut observer ce qui est produit dans STDOUT et STDERR dans des fichiers portant le nom du JOB suivi du numero de JOB. Le nom d'un fichier de sortie ressemble à : JOBNAME.oJOBID

Exemple de soumission simple :

qsub -N "exemple" -cwd -b y "echo 'je suis vivant'"

Une fois que ce job a été exécuté, vous devriez trouver les fichiers de sortie dans le dossier depuis lequel vous l'avez lancé. Ces fichiers portent le nom du job (exemple dans ce cas là) suivi de ".o" pour la sortie standard ou ".e" pour la sortie d'erreur et enfin le JOB ID. Dans notre exemple, si mon JOB ID était le 12345, j'aurais deux fichiers :

  • exemple.o12345 qui contiendrait "je suis vivant"
  • exemple.e12345 qui serait vide

Exemple de soumission plus complet :

qsub -j y -N "job_name" -sync y -q cemeb.q  -cwd -V -b y -l h_rt=00:10:00 "program input"

L'option -j y va mettre la sortie d'erreur dans le même fichier que la sortie standard.

Scripts SGE

Nous venons de voir le lancement de jobs simples avec toutes les options en ligne de commande suivi d'une commande. Il existe une deuxième manière de soumettre des jobs: les scripts SGE.

Pour effectuer plusieurs commandes dans un job, on peut lancer un script SGE à la place d'une commande BASH. Un script SGE est écrit en BASH. On peut y inclure des options de qsub pour outrepasser celles données dans la ligne de commande de soumission.

Quels sont les avantages à utiliser un script SGE ?

  • Les variables d'environnement SGE: https://secure.um.edu.mt/itservices/gridwiki/doku.php/sge_environment_variables
    • NSLOTS : nombre de slots réels alloués
    • TMPDIR : chemin vers le répertoire temporaire sur le système de fichier local
    • JOB_NAME
  • Un script sge est réutilisable plus facilement puisqu'il inclue des options. Il sera plus facile de répéter un script que de rechercher la bonne ligne de lancement dans son historique de commandes.

Voici un exemple de script SGE qui outrepasse les options -S, -cwd, -N et -j.

#!/bin/bash
#$ -S /bin/bash
#$ -cwd
#$ -N mon_job
#$ -j y

cmd1
cmd2

Ce script sera appelé de la sorte:

qsub monscript.sge

NB: vous avez un exemple de fichier que vous pouvez copier puis réutiliser en l'adaptant dans votre home du cluster : general_qsub_file.sh

Arrêter un job

La commande qdel permet de tuer un job, qu'il soit en file d'attente ou en cours d'exécution. Elle prend en paramètre un ou plusieurs JOB_ID obtenus au préalable avec qstat.

qstat

job-ID  prior   name       user         state submit/start at     queue                          slots ja-task-ID
-----------------------------------------------------------------------------------------------------------------
 208972 0.00000 example    jveyssier    qw    11/23/2015 12:47:12                                    1

Pour tuer ce job :

qdel 208972

Dépendances entre jobs

On peut spécifier l'identifiant d'un job à attendre à la soumission. Dans l'exemple suivant, le job soumis ne se lancera que quand le job 666 sera terminé:

qsub -hold_jid 666 job.sge

L'utilisation de l'option -sync y à un qsub permet également d'attendre la fin d'un job avant d'enchainer d'autres actions.

Les array jobs

Un array job est un job qui va se répéter un certain nombre de fois. Par exemple:

#!/bin/bash

#$ -cwd
#$ -S /bin/bash

#$ -t 1-1000

program input-$SGE_TASK_ID > result-$SGE_TASK_ID

-> va soumettre un job qui lance "program" avec comme paramètre la chaine input-1 puis un autre job qui lance "program" avec comme paramètre input-2, etc(...), jusqu'à input-1000.

presque identique à lancer plein de fois le même job. Les avantages :

Utiliser R avec SGE

Exemple de code R (somme.R):

args<-commandArgs(TRUE);
debut = as.numeric(args[1]);
fin = as.numeric(args[2]);
vect = seq(debut, fin);
cat(sum(vect),"\n");

Exemple de script SGE (submit_somme.sge):

#!/bin/bash
#$ -S /bin/bash
#$ -cwd
#$ -j y

#R CMD BATCH --slave "--args $1 $2" somme.R $3
Rscript somme.R $1 $2 > $3

Lancer avec SGE pour faire la somme des entiers de 1 à 10 et les stocker dans le fichier resu.txt

 qsub submit_somme.sge 1 10 resu.txt

R en multicoeur

http://kimura.univ-montp2.fr/calcul_isem/2013/11/parallelisation-avec-r-sur-le-cluster/

ou

R en multicoeur avec le package parallel (mclapply)

http://www.rforge.net/doc/packages/multicore/mclapply.html

Exercices SGE

  • une tache :
    • lancer qsub directement, par exemple :
qsub -N petit_job -b y "sleep 200"
  • Après la soumission de ce job, vérifiez régulièrement l'état de ce job avec la commande qstat.

  • écrire le script "script1.sge" suivant :

#!/bin/bash
#$ -S /bin/bash
#$ -cwd
#$ -N script_exercice_1

sleep 200
  • Lancez le de cette manière :
qsub -cwd -N mon_super_script script1.sge
  • Avec qstat, vérifiez le nom du job ainsi soumis. Quelle option a été prise en compte ? Celle de la ligne de commande ou bien celle de l'intérieur du script ?

plusieurs taches, script bash qui lance plusieurs qsub :

  • Ecrivez un script bash qui effectue les lignes suivantes :
qsub -cwd -N premier_sleep -b y "sleep 200"
qsub -cwd -N second_sleep -b y "sleep 200"
qsub -cwd -N troisieme_sleep -b y "sleep 200"
  • Observez ensuite l'état des jobs avec la commande qstat. Les jobs sont-ils lancés simultanément ? Sont-ils lancés sur la même machine ?

script SGE qui fait un array de job :

  • Lancez le script SGE suivant :
#!/bin/bash
#$ -cwd
#$ -N mon_array
#$ -t 1-5

echo "je suis la tache $SGE_TASK_ID de l'ARRAY de JOB"
sleep 200
  • Observez l'état de ce JOB avec qstat. Observez le résultat de chaque tâche de l'ARRAY avec la commande cat.

Soumission de programmes existants :

tar xvf ./random_mean.tar.gz

Cela va créer le dossier random_mean.

  • Déplacez-vous à l'intérieur de ce dossier.

random.pl un programme qui génère de manière aléatoire un certain nombre de nombre entiers et les places dans un fichier de sortie. Il s'utilise de la sorte :

./random.pl   NB_NOMBRES   FICHIER_DE_SORTIE
  • Soumettre un appel à ce programme via SGE en commande en ligne :
qsub -cwd -b y "./random 100 numbers.txt"

On peut donner des paramètres à un script SGE. Le script SGE nommé random.sge s'utilise de la même manière que random.pl mais il doit être soumis. Il faut donc taper :

qsub random.sge 100 numbers.txt

Le programme calc_mean.pl prend en entrée un fichier de valeurs entières (issu du prog random) et calcule la moyenne. Il s'utilise de cette manière :

./calc_mean input_file output_file
  • Soumettre via SGE directement un appel à calc_mean.pl en prenant comme entrée un des fichiers de nombre aléatoires précédemment généré.

  • Soumettre le script SGE calc_mean.sge . Il prend les mêmes paramètres que calc_mean.pl

  • Modifiez calc_mean.sge pour utiliser la variable $TMPDIR et faire en sorte que le résultat de calc_mean.pl soit écrit dans $TMPDIR/ et ensuite copié dans votre HOME.

chain_rand_and_calc.sh est un script de soumission enchaînant les deux programmes (random puis calc_mean sur la sortie du random). Il s'utilise de cette manière :

./chain_rand_and_calc.sh   NB_NOMBRE  FICHIER_NOMBRES   FICHIER_MOYENNE
  • Soumettez un appel à ce script par SGE.
  • Exercices supplémentaires

    • lancement d'un job en précisant un environnement multicore et en déclarant nombre de slots requis (2 coeurs par exemple)

    • utiliser un environnement multicore pour soumettre un job qui demande un nombre variable de slots et faire afficher le nombre de slots effectivement alloués par SGE (variable $NSLOTS) à l'intérieur du job.