Exécuter des jobs

Les infrastructures de calcul et le stockage associé sont partagés entre tous les utilisateurs. Le partage de ces ressources est géré par un gestionnaire de ressources qui va se charger de répartir les calculs d’utilisateurs de façon optimale sur la machine en prenant en compte les besoins de chaque calcul (nombre de coeurs, nombre de noeuds, GPU, mémoire, temps du calcul …).

Ce type d’outil est indispensable sur toute machine de calcul, vous ne pourrez pas exécuter vos calculs indépendamment du gestionnaire de ressources.

Règles d’utilisation des clusters

Les infrastructures de calcul sont co-financés par des projets collectifs spécifiques et par des projets scientifiques qui acceptent la mutualisation de leur ressource. Concernant leur utilisation, il y a des règles de base et des règles qui concernent les co-financements qui ont été fait par certains projets.

Règles communes

  • Le partage des ressources est assuré par le gestionnaire OAR qui implémente un ordonnancement FIFO avec Fairsharing. Le fairsharing tente d’assurer un partage équitable entre les utilisateurs en donnant la priorité aux utilisateurs qui ont le moins calculé sur une fenêtre de temps glissante réglée à 3 mois. L’indice de fairsharing se traduit par le karma qui est une donnée affichée par la commande oarstat. Plus cet indice est élevé, plus cela signifie que l’utilisateur a consommé des heures de calcul et moins il sera prioritaire par rapport à un utilisateur au karma plus faible.

  • Le temps maximum absolu des jobs est limité. Ceci pour 2 raisons:

    • Permettre au fairsharing d’être efficace en évitant des blocages de la machine par quelques utilisateurs sur des périodes trop longues.
    • Les noeuds de calcul n’étant pas sur un réseau électrique secouru, les jobs ne doivent pas durer trop longtemps pour éviter des pertes catastrophiques de résultats de calcul.

Le temps CPU correspond au nombre de coeurs du job multiplié par le temps total du job (**walltime) : cpu-time = number_of_cores * walltime

Cas du cluster Froggy Le temps maximum absolu des jobs sur Froggy est de 4 jours. Il correspond à 8192 heures de temps CPU et donc à 4 heures sur 2048 coeurs. A titre d’exemple, un job de 1024 coeurs peut durer jusqu’à 8 heures.

Cas du cluster Dahu Le temps maximum absolu des jobs sur Dahu est de 2 jours. La différence avec Froggy s’explique par la taille de la machine.

  • Le nombre de jobs séquentiels est limité à 50 sauf si ils sont lancés depuis la grille de calcul.

  • Les jobs interactifs sont limités à 12h maximum.

Froggy et Dahu étant des machines de calcul parallèle équipées de réseau de calcul performant (et couteux!), elles sont en priorité destinée au calcul parallèle. Les jobs classiques prennent de 64 à 1024 coeurs et durent plus de 30 minutes. Les petits travaux séquentiels (ne prenant qu’un seul coeur) sont tolérés mais ils ne doivent pas être trop courts et trop nombreux : de trop nombreux jobs courts (moins de 10 minutes) vont surcharger le gestionnaire des ressources et entraîner une mauvaise efficacité du supercalculateur. Pour les jobs séquentiels, il vous est très préférable d’utiliser la grille de calcul CIGRI.

Règles spécifiques à certains projets

  • Le karma (indice de fairsharing) de certains utilisateurs est pondéré lorsqu’ils font partie d’un projet qui a contribué à l’achat de ressources. L’idée est d’accorder un avantage en heures de calcul à ces projets, à la hauteur de leur participation financière.

  • Cas du cluster Luke : Certains noeuds particuliers ont été financés par certains projets ou certaines équipes. Dans ce cas, une queue particulière est créee pour les utilisateurs concernés afin qu’ils soient toujours prioritaires sur ces noeuds particuliers.

Challenges

Dans certains cas, il peut être nécessaire d’exécuter des jobs beaucoup plus importants, mais comme les machines de calcul et en particulier Dahu est partagé par de nombreux utilisateurs, une telle utilisation est considérée comme un “challenge” et doit être validée par le COMité des Utilisateurs de GRICAD, afin qu’elle soit programmée et que tous les utilisateurs soient avertis. Si vous pensez être dans le cas “challenge”, veuillez décrire votre projet à sos-calcul-gricad@univ-grenoble-alpes.fr.

Du bon usage des infrastructures calcul et stockage

  • Ne pas surcharger les frontales, tester les jobs sur les noeuds du bac à sable
  • Effacer les fichiers inutilisés, en particulier dans le scratch
  • Ne pas mettre un walltime exagérément grand : plus le walltime est bien estimé, plus le scheduling sera efficace
  • Ne pas prendre un noeud complet si un faible nombre de coeurs et un montant de mémoire équivalent à ce faible nombre de coeur suffisent

Il est formellement interdit de lancer des jobs directement sur les noeuds de login (frontales). Vous devez soumettre vos jobs via le gestionnaire de ressources OAR afin qu’ils soient exécutés sur les noeuds de calcul.