Configuration du gestionnaire de jobs

Principe de fonctionnement

Sur Vision, PBS (version 20.1) (documentation : PBSUserGuide2020.1 ) est utilisé pour gérer les files d'attente sur l'ensemble de la machine. PbsPro est un système distribué qui permet de gérer des files d'attente de calculs en répartissant la charge sur les ressources disponibles sur un calculateur. L'ensemble des calculs sera ainsi géré et distribué en fonction des ressources demandées par rapport aux ressources disponibles, et d'autre part suivant la politique d'attribution des ressources.

Ces ressources sont disponibles suivant des files définies en fonction des ressources demandées pour une simulation.
La soumission d'une simulation se fait sur la base de commandes définies dans un script de soumission lancé ensuite par la commande qsub. Plusieurs types de langages de script peuvent être utilisés (shell unix, perl, python). Les paramètres du script peuvent être soumis directement lors de l'appel de la commande, ou dans le script ::

    [homer@thor ~]# cat myscript.sh
    #!/bin/sh
    #PBS -l walltime=1:00:00 
    #PBS -N testjob
    #PBS -l select=mem:32gb:ncpus=24
    #PBS -j oe

    ./my_application 

    [homer@vision ~]# qsub myscript.sh

PBS fonctionne pour l'attribution des ressources sur la notion de chunk, correspondant à un ensemble de ressources défini comme une unité. Dans le cas de Vision, la première unité de calcul peut être vue comme une carte mère de la machine. Les demandes d'*unité* de calcul se font par l'option ::

    qsub -l select=[N:][chunk specification][+[N:]chunk specification] my_script.pbs

    #PBS -l  select=[N:][chunk specification][+[N:]chunk specification] 

Configuration Scheduler

Contexte d'exécution

cgroups

Les travaux (jobs) sont confinés sur la machine dans un environnement (cgroups) qui empêche leurs processus de consommer plus de ressources CPU que ce qui a été demandé par l'utilisateur. Par exemple, si on a réservé 2 cœurs sur un nœud, les processus lancés lors de ce job ne pourront pas consommer plus que la puissance de calcul des 2 cœurs alloués. La même approche est utilisée sur la quantité de mémoire.

ref : https://forge.univ-poitiers.fr/projects/calculateur-vision/wiki/Architecture_du_calculateur#Cpuset

Durée du job

L'utilisateur doit spécifier la durée attendue (walltime) de son job au moment où il le soumet. Lors de l'exécution, le temps du job est décompté.
Si le job continue de tourner au delà de la durée demandée, celui-ci est détruit par le gestionnaire de job. Il n'y a pas de possibilité la durée walltime une fois que le job a démarré, mais on peut effectuer une modification tant que le job est en attente.

Cette contrainte permet au scheduler de planifier l'allocation des ressources.

Durée par défaut: Si l'utilisateur ne spécifie pas de durée walltime pour son job, le système lui affecte la durée par défaut pour les différentes files.

Files d'attente

Le système de gestion des travaux possède plusieurs types files (queue) d'attente:

  • calcul_big : Pour les jobs relativement courts et demandant des ressources importantes (voir plus loin)
  • calcul_small : Pour les jobs relativement longs et demandant des ressources modérées
  • gpuq: permet d'accéder aux cartes gpu pour réaliser des traitement intensifs de calculs (4 cartes réservées pour le calcul)
  • visuq : permet d'accéder aux cartes gpu pour réaliser la visualisation déportée (4 cartes réservées pour la visualisation)
  • interq : permet d'utiliser la machine pour des traitements interactifs ne demandant pas de ressources gpu

Limites des jobs

Afin d'être éligibles à l'exécution, les jobs doivent satisfaire certaines contraintes (3 max par utilisateur en run quelque soit la file) ;

[homer@vision]$ pbs_queue
=====================================================================================================
     Queue        Max       MaxRun    MaxRun  MaxQueued MaxQueued Priority  Current  Running  Queued
               Walltime     /user    forall     /user    forall             Jobs     Jobs     Jobs
=====================================================================================================
     workq   50:00:00      3         0         0         0        20         0         0         0
     visuq   24:00:00      0         0         0         0        140        0         0         0
     gpuq    40:00:00      0         0         0         0        140        0         0         0
    default     --         0         0         0         0         -         0         0         0
  calcul_small90:00:00      0         0         0         0        80         1         1         0
    interq   24:00:00      0         0         0         0        140        0         0         0
  calcul_big 48:00:00      0         0         0         0        120        0         0         0
Sorting Jobs policy use : 3*queue_priority+2*eligible_time/3600+custom_prio
Max queued per user  : 20
Max run per user  : 3
Max cpus per user : 188
Max gpus per user : 4

Walltime la durée maximale du job

  • visuq : walltime max 24h ; gpu max = 4 ; mem max = 768 Gb
  • gpuq : walltime max 40h ; gpu max = 4 ; mem max = 768 Gb
  • interq : walltime max 24h ; mem max = 768gb
  • calcul_small : walltime max 90h ; ncpus max = 48 ; mem max = 1000gb
  • calcul_big : walltime max 48h ; ncpus max = 168 ; mem max =1.5 To

Détermination de la priorité entre jobs

Le calcul de la priorité entre les jobs prend en compte plusieurs facteurs.

Formula

Les calculs sont triés en fonction d'une formule prenant en compte la priorité des files, du temps d'attente dans la file ;

Sorting Jobs policy use : 3*queue_priority+2*eligible_time/3600+custom_prio + 50*fairshare_factor

Fairshare Scheduling

Le Fairshare scheduling est un système qui enregistre la consommation des ressources par les jobs selon un ensemble d'intervalles de temps. Cette comptabilité est ensuite utilisée pour favoriser les jobs des utilisateurs qui on moins consommé.

Sur Vision, seule la consommation personnelle de l'utilisateur rentre en ligne de compte. Tous les utilisateurs sont initialement égaux par rapport au Fairshare.

Backfilling

Quand les jobs de plus grande priorité ne peuvent être exécutés immédiatement alors que certaines ressources sont disponibles (par exemple, le job de plus grande priorité requiert 96 processeurs alors que seuls 24 sont libres), le scheduler peut placer un job de plus faible priorité si son exécution ne retarde pas les autres.

Starving jobs

Quand les jobs sont en attente de ressources pendant un temps "important" (dans notre cas), ils passent dans un mode prioritaire qui va augmenter leurs priorités