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 video 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 ritchie.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 “ritchie” composé pour le moment de 35 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 chimay01

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.

(chimay01)# env | grep ^OAR
OAR_JOBID=494
OAR_ARRAYID=494
OARDIR=/usr/lib/oar
OAR_WORKING_DIRECTORY=/nfs/home/scosi/azebluze/Examples/Sequentiel
OARCONFFILE=/etc/oar/oar.conf
OAR_USER=azebluze
OAR_WORKDIR=/nfs/home/scosi/azebluze/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/azebluze_494
OAR_O_WORKDIR=/nfs/home/scosi/azebluze/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

Ici on quitte notre réservation et on libère les ressources associées avec la commande [exit]. On revient alors sur le frontal.

(chimay01)# exit
logout
Connection to chimay01 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=“chimayxx”’) 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, ou , en ligne de commande le script oarstatmon.py:

# oarstatmon.py

Nœud    | État     | Cœurs Libres / Total | GPUs Libres / Total 
------------------------------------------------------------------------------
chimay01| Alive    | 0/48                 | -                   
chimay02| Alive    | 0/48                 | -                   
...     |   ...    | ...                  |
chimay31 | Alive    | 96/96               | 2/2 
chimay32 | Alive    | 48/96               | 1/2 
chimay33 | Alive    | 72/96               | 3/4 
chimay34 | Alive    | 32/32               | 4/4 
chimay35 | Alive    | 77/144              | 1/2

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 chimay28

# oarsub -I -p 'host="chimay28"' -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]{style=“color: #993300;”}. 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 chimay28

# oarsub -I -l /core=8,walltime=4:30 -p "gpudevice ='-1' AND not host like 'chimay28'"

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. **

5 noeuds en sont équipés: chimay31 à chimay35. 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 chimay33 ou 34):

# 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

un GPU sur chimayXY (préciser lequel: 31,…35):

# oarsub -I -p "gpu > 0 AND host='chimayXY'" -l host=1/gpu=1

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 spécifie les ressources demandées pour le job -n, –name= donne un nom au job -q, –queue indique la queue dans laquelle le job sera soumis -p, –property “” permet de spécifier certaines propriétés -t, –type spécifie le type de job –notify donne une méthode de notification (mail ou script) -O spécifie le fichier qui recevra les sorties standard du job -E spécifie le fichier qui recevra les erreurs standards du job

Par exemple si vous voulez sur chimay01, 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 /nodes=1/cpu=2/core=4,walltime=1
#OAR -p host="chimay10"
#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.

Le script doit être exécutable : [chmod u+x monscript]

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 azebluze 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.

[]{#oarstat_fj}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 = azebluze
        state = Running
        wanted_resources = -l "{type = 'default'}/core=4,walltime=1:30:0" 
        types = 
        dependencies = 
        assigned_resources = 1+2+3+4
        assigned_hostnames = chimay01
        queue = default
        command = ./test.oar
        launchingDirectory = /nfs/home/scosi/azebluze/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 = azebluze_497
        initial_request = oarsub -S ./test.oar; #OAR -n test; #OAR -l /core=4,walltime=1:30; #OAR --notify mail:azebluze@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 azebluze@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 azebluze
    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 chimay01.

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 chimay01

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 :

# (chimay01) htop -u azebluze

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]{style=“color: #993300;”}, 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 chimay01

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 chimay01

on retrouve les réservations container et inner via oarstat :

    # oarstat -u azebluze
    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).