Configuration Scheduler

Contexte d'exécution

cpusets

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

On pourra regretter que cette fonctionnalité ne puisse pas permettre le même confinement pour la RAM, les I/Os, etc...

accès aux nœuds de calcul

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

Il y a donc plusieurs cas d'utilisation qui nécessitent des précautions spéciales décrites dans les cas d'utilisation de Torque+MAUI
  • jobs parallèles basés sur la librairie Intel/MPI
  • besoin de se connecter quand même aux nœuds alloués à un job (pour surveiller in-situ l'exécution d'un calcul, par exemple)

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:
  • queue default: la file d'attente de routage qui dirige les jobs vers les autres files en fonction de la politique décrite plus loin
  • queue groupe: une file d'attente par groupe primaire d'utilisateurs. Pour les jobs relativement courts (voir plus loin)
  • queue longq: tous les jobs plus longs sont aiguillés dans cette file. Contrairement aux queues groupe, les jobs de la queue longq subissent un certain nombre de restrictions
    • nombre maximum de jobs running: 100
    • nombre maximum de jobs running par utilisateur: 10
  • queue test: permet d'accéder aux machines de la partition test (utiliser "qsub -q test")
  • queue visu: permet d'accéder aux nœuds de visualisation déportée (voir la documentation: Visualisation_déportée)

Limites des jobs

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

  • Walltime la durée maximale du job
    • Walltime < 120 heures (5 jours), le job est dirigé vers la queue groupe de l'utilisateur
    • Walltime < 720 heures (30 jours), le job est dirigé vers longq
    • Walltime < 24 heures (1 jour) pour la file d'attente visu
  • 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 < 5760 heures (correspond à 5 jours sur 48 cœurs ou 30 jours sur 8 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.

Les limites de cette sorte sont:
  • 25000 heures quand la machine est chargée (limite soft)
  • 50000 heures quand la machine a des ressources disponibles (limite hard)

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

La priorité d'un job est modifiée par la différence entre une cible (target) et la consommation effectuée sur l'ensemble des intervalles de comptabilité. Voir: http://www.adaptivecomputing.com/resources/docs/maui/5.1.2priorityfactors.php

  • FSINTERVAL = 24:00:00 - nombre d'heures par intervalle
  • FDEPTH = 28 - nombre d'intervalles pris en compte
  • FSDECAY = 0.95 - facteur de réduction du poids des intervalles en fonction de leur ancienneté
  • FSWEIGHT = 1 - poids relatif du Faishare par rapport aux autres facteurs

Consommation par utilisateur

  • FSUSERWEIGHT = 10 - poids relatif du Fairshare par utilisateur
  • FSTARGET (user) = 10 - pourcentage de consommation cible

Consommation par groupe

  • FSGROUPWEIGHT = 10 - poids relatif du Fairshare par groupe
  • FSTARGET (group) = 30 - pourcentage de consommation cible

XFactor

Le Facteur d'expansion augmente la priorité d'un job proportionnellement au temps passé en file d'attente divisé par la durée demandée pour le job. (XFACTOR = 1 + QUEUETIME / MAX ( XFMINWCLIMIT, WALLCLOCKLIMIT )). les temps QUEUETIME et WALLCLOCKLIMIT sont exprimés en heures.

  • XFACTORWEIGHT = 10 - poids relatif du XFactor par rapport aux autres facteurs
  • XFMINWCLIMIT = 1 - durée minimale de job prise en compte

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.

  • BACKFILLDEPTH = 128 - nombre de jobs candidats pour le backfilling

Calcul-bis.sci (1,329 ko) Ramses Didjou Demasse, 29/02/2016 09:45