Poudlard

# Configuration Scheduler

## Contexte d'exécution

### Cgroups

Les travaux (jobs) sont confinés sur les nœuds de calcul dans un environnement ([cgroups](https://en.wikipedia.org/wiki/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 [[Groupes|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 et un noeud bigmem. 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 32 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 on 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

### 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:

```conf

PriorityFlags=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