Publié le 13 février 2012, mis a jour le 20 mars 2024
Introduction à Grid Engine
<table_des_matieres379>
SGE remplace le système de batch LSF.
Sun Grid Engine (GE ou SGE) est un système batch avec répartition automatique de charge sur un cluster de calcul. SGE est un logiciel d’origine SUN mis à la disposition de la communauté Open Source, la licence étant reconnue par la Free Software Foundation et l’Open Source Initiative ; Pour en savoir plus :
http://gridengine.sunsource.net
Le but de ce document est de présenter à l’utilisateur les principales commandes et options. L’utilisateur saura soumettre des jobs, suivre leur exécution, et les arrêter éventuellement. Il n’est pas exhaustif et doit être considéré comme une première aide à la mise en œuvre.
SGE peut être utilisé dans le cas présent comme un portail d’entrée de soumission de travaux et de répartition de charge sur le cluster du centre, en fonction des ressources demandées par l’utilisateur et disponibles sur les éléments de la grille de calcul ; par exemple : parallélisme sur x processeurs (MPI, OpenMP)...
Le répertoire courant de chaque utilisateur est vu de manière identique par l’ensemble des noeuds constituant les clusters.
Important : le job de soumission doit être en principe un fichier script exécutable (chmod u+x mon-script
) (qui lancera le binaire ou l’application).
Nous vous rappelons que l’exécution d’une commande en mode interactif ne peut dépasser 3 heures cpu sur les machines opteron du centre ; seul le système batch (ici SGE) permet d’exécuter des travaux dépassant 3 heures de calcul.
Ces options par défaut peuvent être modifiées par l’utilisateur dans une certaine mesure.
Elles peuvent être de différentes natures : architecture (type de processeur), séquentielles ou parallèles, machines réservées par certains laboratoires, taille mémoire...
Nom | Description | Durée max | Nombre de slots max |
---|---|---|---|
3d | travaux nécessitant un rendu graphique par GPU (lancer avec 3dsub ) |
12 heures | 2 |
batch | travaux séquentiels ou parallèles (mémoire partagée ou distribuée) | 21 jours (sauf part000-part091 : limite à 48 heures) | 600 |
gpu | travaux séquentiels ou parallèles (mémoire partagée uniquement) nécessitant un GPU | 7 jours (sauf webern07 : limite à 2 heures) | 2 (sauf webern07 : limite à 1) |
interactif | travaux intéractifs (lancer avec qlogin -q interactif ) |
4 heures | 4 |
transfer | copie de données entre l’/archive et le /work |
7 jours | 4 |
uv | travaux séquentiels ou parallèles nécessitant des ressources de mémoire importante | 21 jours | 92 |
Ce chapitre donne la liste des commandes les plus fréquemment utilisées, ainsi que leurs principales options.
Pour soumettre un job dans le cas particulier de notre cluster, on doit se connecter sur une machine interactive Linux (par exemple krenekxx).
Important : le job à exécuter doit être en principe un fichier script ! Ne pas oublier le :
Cas général
Le premier argument trouvé par qsub qui n’est pas une option est considéré comme le nom de la commande à soumettre, et tout le reste de la ligne comme des arguments de cette commande.
Si aucune commande à exécuter n’est spécifiée sur la ligne de commande, qsub lit son entrée standard. Les fonctionnalités de qsub sont accessibles en interface graphique à travers qmon.
Syntaxe :
Exemples
En géneral on aura :
– soumission du script ; ce job s’exécutera sur une machine quelconque ; il faudra être sûr que toutes les ressources nécessaires sont disponibles quelque soit toutes les machines. Il n’y a pas de file d’attente par défaut.
Cas particulier de Gaussian parallèle
C’est une exécution en mémoire partagée ; nous n’avons pas la possibilité à ce jour de faire tourner Gaussian en mémoire distribuée (via Linda). Le fichier Default.route doit contenir -P- 2 ou -P- 4
En exigeant N processeurs le job s’executera sur une machine ayant 2 ou 4 processeurs ; (N= 2 ou 4, doit être cohérent avec la valeur du fichier Default.route). Le fichier mon_job.exe contient le nom du fichier de données Gaussian (suffixé par .com par défaut) : attention aux confusions.
Une particularité : le job, s’il trouve les ressources nécessaires (au moins 2 processeurs libres sur 1 noeud de calcul) s’exécutera sur la partie séquentielle ou sur la partie parallèle du cluster sans distinction.
Cas particulier de MPI et Infiniband
Exécution en mémoire distribuée via le réseau Infiniband et la bibliothèque MPI.
input-data est un fichier d’entrée de données et mon-prog.com est un script qui contient les commandes de lancement du binaire ( la version compilée du programme).
Rappel : pour compiler un programme MPI la commande suivante est à utiliser : mpif90
ou mpif77 (options) -o mon-prog mon-prog.<sc>f
Cas particulier de Jaguar séquentiel
Le fichier jag.com contient ce qui suit :
jag.in est le fichier contenant votre procédure Jaguar ; le mot clef -WAIT est important pour l’exécution en batch.
La commande de lancement en batch sera :
Cas particulier de Gamess séquentiel
La commande est :
Cas particulier de Gamess parallèle
La commande est :
Cas particulier de Mathematica
On se constitue un fichier factx.txt contenant les directives Mathematica par exemple :
et un fichier mathem.com contenant :
La soumission se fait depuis une machine krenekXX par :
Attention : il faut utiliser bmathematica pour le lancement de Mathematica dans le cas du batch !
Attention : le fichier factx.txt doit impérativement finir par la commande quit sinon le job ne se termine pas !
C’est une façon un peu différente de soumettre ses travaux. On peut se créer un script contenant les différents paramètres et soumettre ce script par la commande :
Le fichier mon-script pourrait avoir le contenu suivant à titre d’exemple :
Dans l’exemple ci-dessus, on demande l’exécution de mon-prog, les résultats de la sortie standard étant placé dans le fichier result.out, l’identificateur de job étant zirconium. Bien d’autres paramètres peuvent être utilisé. Attention par contre à la modification de mon-script pendant l’exécution du job ; le fichier result.out est en principe écrit en "append". Des arguments peuvent être passés au programme.
C’est la commande qstat ; voir aussi man qstat
qstat
: état des jobs en coursqstat -f
: état du clusterqstat -g t
: état complet des jobs parallèlesqstat -s z
: historique des jobsLa commande qstat2
particulière au centre de calcul permet une visualisation triée par user, date, queue ou jobid.
Voir aussi la commande status
: pour en savoir plus, status -h
La commande qjob2
permet d’avoir la liste des jobs pour un utilisateur ou des informations sur le job parallèle d’un utilisateur ; c’est particulièrement utile pour avoir une liste ordonnée et cohérente des machines utilisées par un job parallèle.
qjob2 -u user
: liste des jobs d’un utilisateurqjob2 -j jobid
: détails sur les machines utilisées par un job parallèleLes options de la commande qstat -s xx
sont les suivantes
qsub -a
)C’est la commande qdel jobnum
; on obtient le jobnum via la commande qstat
; voir aussi man qdel
C’est la commande qhost
; voir aussi man qhost
C’est la commande qqueues
avec les paramètres -a, -l, -q queue, -h host.
C’est la commande qgroups
avec les paramètres -a, -l, -g group, -h host.
qmon
vous permettra de réaliser en mode graphique toutes les commandes décrites ci-avant.
Une cartographie de la charge du cluster de calcul GE est accessible via un navigateur à l’adresse :
http://krenek2000.u-bourgogne.fr/clustermap