Lancer un calcul
Calculco est une plate-forme multi-utilisateurs destinée à accueillir des calculs concurrents. Il est donc impératif de se doter d'outils permettant de partager les ressources physiques (nœuds, cpu, cœurs, mémoire ...) de façon "équitable" entre les utilisateurs et d'ordonnancer les travaux de façon optimale. Nous avons choisi le gestionnaire de ressources et de tâches OAR pour cela.
OAR est un logiciel libre sous licence GPL développé par le Laboratoire d'Informatique de Grenoble. Il est complet, robuste, modulaire, évolue régulièrement et bénéficie d'un bon support. Il est utilisé, entre autres, sur la grille nationale Grid5000. |
Quelques règles et restrictions y ont été fixées, mais cela ne dispense pas d'une certaine "courtoisie" quant à l'utilisation des ressources pour que la cohabitation se passe bien.
La présentation qui est faite ici n'est pas exhaustive mais adaptée à notre plate-forme de calcul. Pour de plus amples informations, vous pouvez consulter la documentation officielle.
Voici également la vidéo de présentation d'OAR faite aux 8èmes Journées Réseaux de l'Enseignement et de la Recherche.
1. Soumission
Concrètement, comment faire lorsque vous voulez lancer un calcul (séquentiel ou parallèle) sur Calculco :
Sur le frontal calculco.univ-littoral.fr, il faut préciser les ressources dont vous avez besoin (nœud, cpu, cœurs ...), le temps de réservation et soumettre votre demande dans l'environnement d'OAR via la commande "oarsub". Cela garantit que vous serez le seul sur les ressources allouées. Les noeuds ne sont pas accessibles directement via ssh, il faut obligatoirement passer par ce mécanisme pour les utiliser. De même, aucun calcul ne devra être lancé sur le frontal, seules les compilations y sont autorisées.
Via oarsub, il existe 2 types de soumission : le mode interactif ou le mode passif (batch).
Une soumission en mode interactif vous permet une connexion immédiate à un ou plusieurs nœuds, comme une connexion ssh mais vous n'avez accès qu'aux ressources qui vous sont allouées (et bien sûr les autres n'y ont pas accès). En mode batch, votre job sera exécuté lorsque les ressources que vous avez demandées seront disponibles (sans que vous ne restiez connectés). Aussi le mode Interactif sera plutôt privilégié en mode de développements et de tests.
OAR organise ses ressources de calcul hiérarchiquement : cluster->switch->nodes->cpu->core.
Calculco est composé d'un seul cluster "orval" composé pour le moment de quelques noeuds (cf la page consacrée aux ressources matérielles) tous situés sur le switch sw1.
1.1. Mode interactif
On lance une réservation via oarsub en utilisant l'option -I
Voici quelques exemples de l'utilisation du mode interactif :
Demander un seul cœur n'importe où :
# oarsub -I
[Admission Rule] Set default walltime to 7200.
[ADMISSION RULE] Modify resource description with type constraints
OAR_JOB_ID=494
Interactive mode : waiting...
Starting...
Initialize X11 forwarding...
Connect to OAR job 494 via the node orval01
Vous êtes alors directement connecté sur le premier nœud (ici il n'y en a qu'un) sur lequel vous avez demandé des ressources.
L'ordonnanceur d'oar vous a transmis un numéro de job correspondant à l'identification de la réservation que vous venez de faire (ici 494). Des variables d'environnement commençant par "OAR_" ont été initialisées afin de relater les paramètres de cette réservation. La commande env | grep ^OAR vous donne la liste de ces variables.
# env | grep ^OAR
OAR_JOBID=494
OAR_ARRAYID=494
OARDIR=/usr/lib/oar
OAR_WORKING_DIRECTORY=/nfs/home/lisic/dverhaghe/Examples/Sequentiel
OARCONFFILE=/etc/oar/oar.conf
OAR_USER=dverhaghe
OAR_WORKDIR=/nfs/home/lisic/dverhaghe/Examples/Sequentiel
OARUSER=oar
OAR_JOB_NAME=
OAR_KEY=1
OAR_NODE_FILE=/var/lib/oar/494
OAR_RESOURCE_PROPERTIES_FILE=/var/lib/oar/494_resources
OAR_PROJECT_NAME=default
OAR_JOB_WALLTIME_SECONDS=7200
OAR_STDERR=OAR.494.stderr
OAR_ARRAY_ID=494
OAR_FILE_NODES=/var/lib/oar/494
OAR_ARRAYINDEX=1
OARXAUTHLOCATION=/usr/bin/xauth
OAR_JOB_WALLTIME=2:0:0
OAR_NODEFILE=/var/lib/oar/494
OAR_RESOURCE_FILE=/var/lib/oar/494
OAR_STDOUT=OAR.494.stdout
OARDO_USER=oar
OAR_JOB_ID=494
OAR_CPUSET=/oar/dverhaghe_494
OAR_O_WORKDIR=/nfs/home/lisic/dverhaghe/Examples/Sequentiel
OAR_ARRAY_INDEX=1
OARDO_UID=109
Vous pouvez vérifier que les données stockées dans ces variables correspondent à la sortie de la commande oarstat -fj 494 (cf rubrique oarstat). Vous pouvez maintenant lancer des tâches sur les ressources qui vous ont été attribuées sur le nœud sur lequel oar vous a connecté (nœud principal), et sur les autres (vous les trouverez dans le fichier stocké dans la variable OAR_NODEFILE) via oarsh. La fin de ces tâches ne met pas fin à la réservation.
La réservation se termine si :
- Vous mettez fin explicitement à la connexion avec le nœud principal via la commande exit.
- Vous tuez votre réservation depuis le frontal (cf rubrique oardel).
- Le temps de réservation est arrivé à échéance (voir exemple walltime)
Ici on quitte notre réservation et on libère les ressources associées avec la commande exit. On revient alors sur le frontal.
# exit
logout
Connection to orval01 closed.
Disconnected from OAR job 494
1.2. choix des ressources : quelques exemples
ATTENTION: certaines commandes ci-après, intéressantes pour illustrer le fonctionnement d'OAR, sont susceptibles de supprimer des jobs qui sont lancés depuis des heures voire des jours...En effet, certains utilisateurs sont obligés de lancer leurs travaux dans la file de travaux «besteffort» ( cf. politique de réservation). Cette file étant de priorité inférieure à toutes les autres, si votre session interactive réclame trop de ressources (ou un nœud précisément nommé, par exemple -p 'host="orvalxx"') vous risquez de supprimer des travaux "besteffort" en cours pour un simple test.
C'est pourquoi il est indispensable de vérifier la «charge» du cluster avant d'effectuer des tests, grâce aux outils de monitoring.
Pour spécifier les ressources dont vous avez besoin, il faut utiliser l'option -l avec un argument du type /la/liste/de/mes/besoins
Demander 5 cœurs n'importe où (les cœurs seront si possibles réservés sur le même cpu du même nœud)
# oarsub -I -l /core=5
Demander un nœud entier
# oarsub -I -l /nodes=1
Demander 2 cpus sur le même nœud
# oarsub -I -l /nodes=1/cpu=2
Vous pouvez également utiliser l'option -p pour spécifier une propriété spécifique (la commande oarnodes vous donne une liste des propriétés).
Demander 9 cœurs répartis sur 3 cpus différents du nœud orval13
# oarsub -I -p 'host="orval13"'
-l /cpu=3/core=3
Par défaut, si vous ne spécifier rien, les ressources vous seront attribuées pour 2 heures. Si vous désirez une autre durée, il faut utiliser le champs walltime=HH:MM:SS. Demander par exemple 4 cœurs pour une durée de 4h30 se fera de la façon suivante.
# oarsub -I -l /core=4,walltime=4:30
Attention avec l'option -l /ressources1/.../ressourcesn, il faut comprendre le / comme une multiplication :
Par exemple avec l'option -l /nodes=2/cpu=2/core=4 vous réclamez 16 coeurs (4 coeurs sur chacun des 2 processeurs de chacun des 2 noeuds qui seront utilisés).
8 cœurs sur n'importe quel nœuds sauf les nœuds équipé de GPU, ni orval28
# oarsub -I -l /core=8,walltime=4:30 -p "gpudevice ='-1' AND not host like 'orval28'"
réservation des GPUs :
2023, arrivée des GPUs sur la plateforme: ils s'insèrent dans cette hiérarchie selon le 2nd scenario décrit ici. La hiérarchie devient: cluster->switch->nodes->cpu[->gpu]->core.
3 noeuds en sont équipés: orval39 et orval40 (bi-GPU), orval41 (quadri-GPUs). La réservation d'un GPU entraîne automatiquement la réservation de tous les cœurs topologiquement associés à ce GPU. Voici quelques exemples de réservation:
un des 8 GPUs disponibles:
# oarsub -I -p "gpu > 0" -l host=1/gpu=1
deux GPUs sur le même nœuds:
# oarsub -I -p "gpu > 0" -l host=1/gpu=2
quatre GPU sur le même nœuds (donc exclusivement orval41):
# oarsub -I -p "gpu > 0" -l host=1/gpu=4
deux GPUS sur 2 nœuds différents:
# oarsub -I -p "gpu > 0" -l host=2/gpu=1
1.3. Mode batch
En mode passif, la réservation se fait via la commande oarsub -S
Cette fois, les ressources demandées, la durée du calcul, le(s) job(s) à lancer sont décrits dans un script lancé en tâche de fond. A la fin de vos travaux ou à l'échéance du walltime, les ressources seront libérées et à nouveaux disponibles pour d'autres.
Dans ce mode vous pouvez énoncer dans votre script les paramètres via des directives #OAR.
Les principales options utiles sont :
-l, --resource <LIST> | spécifie les ressources demandées pour le job | |
-n, --name=<txt> | donne un nom au job | |
-q, --queue <QUEUE> | indique la queue dans laquelle le job sera soumis | |
-p, --property "<LIST>" | permet de spécifier certaines propriétés | |
-t, --type <TYPE> | spécifie le type de job | |
--notify <TXT> | donne une méthode de notification (mail ou script) | |
-O <FILE> | spécifie le fichier qui recevra les sorties standard du job | |
-E <FILE> | spécifie le fichier qui recevra les erreurs standards du job |
Par exemple si vous voulez sur orval01, 4 cœurs de 2 cpus pour 1heure; que vous voulez appeler votre job "montest", que les sorties stdout et stderr doivent être faites dans les fichiers /scratch/monLabo/monLogin/masortie.JOB_IB.out et /scratch/monLabo/monLogin/masortie.JOB_ID.err. Le script devra alors contenir les lignes :
#OAR -l /core=4/cpu=2,walltime=1
#OAR -p host="orval10"
#OAR -n montest
#OAR -O /scratch/monLabo/monLogin/masortie.%jobid%.out
#OAR -E /scratch/monLabo/monLogin/masortie.%jobid%.err
On pourra alors lancer le script avec la commande :
# oarsub -S /chemin/vers/mon/script
ou
# oarsub -S ./monscript (dans votre répertoire courant)
C'est ce mode de fonctionnement qu'il faudra privilégier quand vous "lancerez" vos calculs une fois les phases de développement et de test terminées.
Vous trouverez des exemples de script sur le frontal dans /usr/local/oar. Il n'y a que quelques exemples, d'autres viendront.
2. Gestion des tâches
Vous disposez de plusieurs commandes en ligne dans l'environnement OAR qui vous aideront à gérer vos travaux. Les outils graphiques sont exposés dans le menu Monitoring (il faudra vous identifier).
2.1. Oarstat
Cette commande permet de visualiser l'ensemble des travaux soumis sur la plate-forme. Voici un exemple du résultat de la commande sur le frontal :
On peut voir que l'utilisateur jdehos a 2 jobs en cours. Dans le premier (n°181) il utilise 2 cœurs pour une durée de 50 heures, dans le second (n°182) il monopolise 2 autres cœurs pour une durée de 500 heures.
L'utilisateur fteytaud, utilise lui 16 cœurs (la moitié du nœud de calcul) pour une durée de 12 heures, drobilliard n'utilise qu'un seul cœur mais depuis quelque temps déjà, tandis que dverhaghe a réservé 4 cœurs en mode interactif (J=I)
Vous pouvez voir l'état des jobs (colonne S), R indique en cours et W en attente. Ici tous les jobs "tournent". Il n'y en a aucun en attente (25 cœurs sur 32 sont utilisés). Enfin, la colonne Duration nous précise depuis combien de temps les jobs sont actifs.
L'explication du mode besteffort et du karma est décrit plus loin.
Pour avoir une description plus détaillée d'un job, lancer la commande oarstat -fj sur le numéro de Job. Voici le résultat de la commande sur un script de test lancé plus tard et dont le jobId était 497 :
# oarstat -fj 497
Job_Id: 497
job_array_id = 497
job_array_index = 1
name = test
project = default
owner = dverhaghe
state = Running
wanted_resources = -l "{type = 'default'}/core=4,walltime=1:30:0"
types =
dependencies =
assigned_resources = 1+2+3+4
assigned_hostnames = orval01
queue = default
command = ./test.oar
launchingDirectory = /nfs/home/lisic/dverhaghe/Examples/Sequentiel
stdout_file = OAR.test.497.stdout
stderr_file = OAR.test.497.stderr
jobType = PASSIVE
properties = (desktop_computing = 'NO') AND drain='NO'
reservation = None
walltime = 1:30:0
submissionTime = 2015-10-11 23:00:00
startTime = 2015-10-11 23:00:02
cpuset_name = dverhaghe_497
initial_request = oarsub -S ./test.oar; #OAR -n test; #OAR -l /core=4,walltime=1:30; #OAR --notify mail:verhaghe@lisic.univ-littoral.fr
message = R=4,W=1:30:0,J=B,N=test (Karma=0.978,quota_ok)
scheduledStart = 2015-10-11 23:00:02
resubmit_job_id = 0
events = [2015-10-11 23:00:02] USER_MAIL_NOTIFICATION:[Judas] Send a mail to verhaghe@lisic.univ-littoral.fr --> RUNNING ,
L'option -s permet de voir l'état du job.
# oarstat -sj 497
497: Running
Pour avoir la liste de tous les jobs soumis par un utilisateur, utiliser l'option -u
# oarstat -u dverhaghe
Job id S User Duration System message
--------- - -------- ---------- ------------------------------------------------
497 R dverhagh 0:16:51 R=4,W=1:30:0,J=B,N=test (Karma=0.978,quota_ok)
2.2. Oardel
Cette commande permet de tuer un job.
# oardel 497
Deleting the job = 497 ...REGISTERED.
The job(s) [ 497 ] will be deleted in a near future.
Si vous gérer les checkpoints vous permettant de redémarrer à partir d'un environnement sauvegardé, oardel peut envoyer un signal pour le déclenchement du point de contrôle avant de tuer votre job.
# oardel -c -s SIGUSR2 497
Checkpointing the job 497 ...DONE.
The job 497 was notified to checkpoint itself on orval01.
exemple de programme et script OAR mettant en oeuvre un checkpoint:
La mise en œuvre des checkpoints est décrite dans le tutorial checkpoints.
Oarnodes
La commande oarnodes permet d'avoir l'ensemble des informations concernant les ressources de la plate-forme. Le résultat de la commande est particulièrement indigeste, préférez lui les outils graphiques.
l'option -s permet tout de même de vérifier rapidement l'état des ressources.
2.3. Mode connecté
Vous pouvez avoir besoin de vous connecter à un nœud utilisé dans votre réservation. Pour vérifier par exemple l'avancée de votre job en cours si des résultats sont écrits sur des disques locaux (/scratch). Utiliser alors oarsh depuis le frontal avec le JOB_ID de votre réservation pour effectuer cette connexion :
# OAR_JOB_ID=498 oarsh orval01
vous pouvez ensuite vous connecter avec oarsh sur les autres nœuds utilisés dans votre réservation (variable d'environnement $OAR_NODEFILE).
Alternativement, vous auriez pu vous connecter sur le nœud principal de la réservation depuis le frontal via la commande oarsub avec l'option -C
# oarsub -C 498
remarque: vérifier simplement usage mémoire/cpu/cœurs :
# (orval01) htop -u dverhaghe
2.4. Oarcp
En mode connecté, ou en batch, vous pouvez avoir besoin de copier des fichiers entre les nœuds de votre réservation. Oarcp permet cela.
3. Options spéciales (batch)
Certaines options d'oarsub permettent des actions particulières, les plus utiles sont décrites ci-après. Vous trouverez toutes les informations via la commande "man oarsub".
3.1. Réservation (-r)
Pour une raison ou une autre (gros calcul, être sûr d'avoir de la place ...) vous pouvez avoir besoin de planifier une réservation de ressources pour plus tard. Ceci est possible grâce à l'option -r d'oarsub, il faudra alors spécifier la date avec le format "AAAA-MM-JJ HH:MM:SS". Essayer toutefois d'éviter ce type de fonctionnement tant que possible, c'est très contraignant pour l’ordonnanceur.
3.2. Queue (-q)
Sur calculco vous disposez de 3 queues pour réserver vos ressources : besteffort, default, long
Si vous ne spécifier rien via oarsub, la réservation utilise la queue "default" (étonnant non !), sinon il faudra la préciser avec l'option -q.
La programmation des jobs même si elle se fait de façon équitable entre les utilisateurs (au karma près) est soumise à des contraintes en fonction de la queue que vous utilisez. Vous trouverez ces contraintes dans la rubrique politique de réservation.
3.3. Container
Avec OAR, en mode interactif uniquement, il est également possible de lancer une réservation à l’intérieur d'une autre plus globale.
Tout d'abord on fait une réservation de type container (par exemple 12 cœurs pour 4 heures):
# oarsub -I -t container -l /core=12,walltime=4
[ADMISSION RULE] Modify resource description with type constraints
OAR_JOB_ID=505
Interactive mode : waiting...
Starting...
Initialize X11 forwarding...
Connect to OAR job 505 via the node orval01
Ensuite depuis le frontal on peut via le type inner effectuer de nouvelles réservations dans la première (505). Exemple :
# oarsub -I -t inner=505 -l /core=4
[ADMISSION RULE] Set default walltime to 7200.
[ADMISSION RULE] Modify resource description with type constraints
OAR_JOB_ID=507
Interactive mode : waiting...
Starting...
Initialize X11 forwarding...
Connect to OAR job 507 via the node orval01
on retrouve les réservations container et inner via oarstat :
# oarstat -u dverhaghe
Job id S User Duration System message
--------- - -------- ---------- ------------------------------------------------
505 R dverhagh 0:15:31 R=12,W=4:0:0,J=I,T=container (Karma=1.047,quota_ok)
507 R dverhagh 0:06:00 R=4,W=2:0:0,J=I,T=inner (Karma=1.047,quota_ok)
3.4. Besteffort
Quand vous soumettez un job via oarsub vous avez la possibilité de spécifier un type avec l'option -t (cela a déjà été vu dans la rubrique container).
Un des types intéressants est le type besteffort. Quand vous ne spécifiez pas de queue, ni le type besteffort, votre job est programmé dans la file (queue) "default". Avec ce type elle sera insérée dans la file "besteffort".
Les jobs de ce type ont la priorité la plus basse. Ils pourront être tués par n'importe quel autre job non besteffort si ceux-ci sont en attente de ressources pour être lancés.
C'est dur bien sûr mais cela a tout de même un intérêt. Dans le mode de soumission besteffort vous êtes soumis à des contraintes plus souples (sur Calculco elles sont complètement supprimées) et vous pouvez exploiter toutes les ressources si vous le voulez. C'est intéressant lorsque vous avez par exemple de nombreuses simulations assez courtes à lancer et que la plate-forme n'est pas très utilisée.
Il existe néanmoins un moyen de relancer automatiquement un job "besteffort" qui aura été tué. Il faut pour cela conjointement spécifier les types besteffort et idempotent lors de la soumission (-t besteffort -t idempotent).
Environnement logiciel Politique de réservation