Configuration Scheduler¶

Contexte d'exécution¶

Cgroups¶

Les travaux (jobs) sont confinés sur les nœuds de calcul 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.

Ceci permet une allocation partagée des nœuds de calcul. Plusieurs jobs peuvent donc cohabiter sur une même machine avec une relative garantie de disponibilité des ressources

Accès aux nœuds de calcul¶

En raison du besoin de confiner les jobs dans un cgroup, la connexion directe (par ssh) aux nœuds de calcul est interdite aux utilisateurs.

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 système. Il n'y a pas de moyen de rallonger la durée walltime une fois que le job a démarré.

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 de 1 heure.

Files d'attente¶

Le système de gestion des travaux possède plusieurs types files d'attente ou partitions :

• groupe : une file d'attente par groupe primaire d'utilisateurs. Pour les jobs relativement courts (voir plus loin)
• longq : tous les jobs plus longs sont aiguillés dans cette file. Cette partition contient tous les noeuds compute. Contrairement aux partitions groupe, les jobs de la partition longq subissent un certain nombre de restrictions:
  • nombre maximum de jobs running: 15
  • nombre maximum de jobs running par utilisateur: 2

Limites des jobs¶

Afin d'être éligibles à l'exécution, les jobs doivent satisfaire certaines contraintes:

• Walltime la durée maximale du job
  • Walltime < 48 heures (2 jours), le job est dirigé vers la partition groupe de l'utilisateur
  • Walltime < 240 heures (10 jours), le job est dirigé vers longq
• procs*hours: il s'agit du temps total réservé pour tous les processeurs alloués au job (nb cœurs x temps d'exécution)
  • procs*Walltime < 768 heures (correspond à 2 jours sur 16 cœurs ou 10 jours sur 3 cœurs)

Limites sur un ensemble jobs¶

Le nombre de ressources allouées en même temps à un utilisateur est limité. La somme des produits nombre de cœurs par durée walltime de chaque job en cours d'exécution est limitée à un certain nombre d'heures pour un même utilisateur. Les jobs qui dépassent cette limite sont simplement mis en attente même si des ressources sont disponibles. Ceci permet d'éviter qu'un utilisateur ne réserve une grande part de la machine pour un temps trop long.

La limite configurée sur Poudlard est de 7680 heures.

Détermination de la priorité entre jobs¶

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

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 ont moins consommé.

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

L'utilisateur intéressé pourra consulter la documentation officielle du plugin de priorités Slurm: https://slurm.schedmd.com/priority_multifactor.html#fairshare et l'algorithme utilisé: https://slurm.schedmd.com/classic_fair_share.html .

Prise en compte de la taille du job¶

Sur Poudlard, le scheduler de Slurm est configuré avec les options suivantes, qui accordent une meilleure priorité aux jobs demandant beaucoup de cœurs:

PriorityFlags=NO_FAIR_TREE,SMALL_RELATIVE_TO_TIME
PriorityFavorSmall=NO

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 100 processeurs alors que seuls 50 sont libres), le scheduler peut placer un job de plus faible priorité si son exécution ne retarde pas les autres.

• bf_max_job_test = 50 - nombre de jobs candidats pour le backfilling
• bf_max_job_user = 5 - nombre de jobs par utilisateur candidats pour le backfilling