Configuration

Partitions

La partition est une ressource de calcul qui regroupe des nœuds dans une même entité logique définie par une ou plusieurs spécifications données (quelles soient matérielles ou liées à des ressources).

Pour obtenir un aperçu rapide des différentes partitions, on peut utiliser la commande sinfo :

% sinfo
PARTITION       AVAIL  TIMELIMIT  NODES  STATE NODELIST
htc*               up   infinite     21   idle ccwslurm[0001-0002,0005-0023]
htc_interactive    up   infinite      1   idle ccwislurm0001
gpu                up   infinite      1   idle ccwgslurm0001
gpu                up   infinite      1   down ccwgslurm0002
gpu_interactive    up   infinite      1   down ccwgislurm0001
hpc                up   infinite      2   idle ccwslurm[0003-0004]
htc_highmem        up   infinite      0    n/a

Il existe trois partitions distinctes : htc, hpc et gpu, ainsi que leurs équivalents pour les jobs interactifs : htc_interactive, hpc_interactive et gpu_interactive. Chacune de ces trois partitions correspond à l’une des trois plateformes de calcul décrites à la page concernant la plateforme de calcul.

Note

De manière simple, les jobs mono-cœur et multi-cœurs seront exécutés dans la partition htc, les jobs parallèles utilisant l’InfiniBand dans la partition hpc, et l’accès aux GPUs se fera par la partition gpu.

La commande sinfo indique également la restriction en temps pour l’exécution d’un job et les serveurs de calcul et leurs états appartenant à chacune de ces partitions.

Voici les principales options de la commande sinfo :

-a
affiche tous les serveurs de calcul
-d
affiche les serveurs de calcul hors ligne
-l
affiche la sortie dans un format long
-p <partition>
affiche les informations pour une partition spécifique

Pour afficher et consulter la configuration détaillée des partitions on utilisera scontrol :

% scontrol show partition
PartitionName=htc
   AllowGroups=ALL AllowAccounts=ALL AllowQos=ALL
   AllocNodes=ALL Default=YES QoS=N/A
   DefaultTime=NONE DisableRootJobs=YES ExclusiveUser=NO GraceTime=0 Hidden=NO
   MaxNodes=1 MaxTime=UNLIMITED MinNodes=0 LLN=NO MaxCPUsPerNode=UNLIMITED
   Nodes=ccwslurm[0001-0002,0005-0023]
   PriorityJobFactor=1 PriorityTier=1 RootOnly=NO ReqResv=NO OverSubscribe=NO
   OverTimeLimit=NONE PreemptMode=OFF
   State=UP TotalCPUs=1344 TotalNodes=21 SelectTypeParameters=NONE
   JobDefaults=(null)
   DefMemPerCPU=3000 MaxMemPerCPU=3100

   [...]
La commande donne les principales caractéristiques de ces partitions :
  • les groupes groups et comptes accounts autorisés,
  • les qualités de service associées (voir ci-dessous),
  • les ressources disponibles dans la partition,
  • les limites en terme de ressources de la partition.

Il faut distinguer la notion de groupes groups et de comptes accounts. Dans le premier cas, il s’agit du groupe tel que défini à la page intitulée Notions de laboratoire et groupe. Il correspond donc à une expérience ou une collaboration à laquelle l’utilisateur participe, et est le groupe Unix associé à l’utilisateur (groupe principal). Le compte accounts correspond à l’entité à laquelle les ressources utilisées par le job seront imputées. Il s’agira donc d’un groupe auquel l’utilisateur participe, mais qui peut être différent du groupe Unix auquel l’utilisateur est couramment associé.

Pour visualiser le compte account un utilisateur est rattaché, il suffit d’utiliser la commande :

% sacctmgr show user my_username

On peut aussi visualiser l’ensemble des comptes account auxquels un utilisateur est rattaché :

% sacctmgr show user my_username withassoc

avec my_username étant l’identifiant de l’utilisateur.

De manière générale, la commande sacctmgr permet de visualiser et de modifier l’ensemble des informations liées aux comptes accounts.

Pour plus de détails, veuillez vous référer à l’aide de la commande sacctmgr -h.

Note

Dans la pratique, à la soumission d’un job, on pourra spécifier la partition et le compte account à utiliser avec respectivement les options --partition et --account. Sans spécification particulière, Slurm optera pour la partition par défaut, i.e. htc, et le compte account principal de l’utilisateur (voir ci-dessus).

Qualité de service

La qualité de service, ou QoS (pour Quality Of Service), est une règle associée à une partition ou à un job qui permet de l’altérer. Elle peut par exemple modifier la priorité d’un job, ou en limiter les ressources allouées. La commande utilisée ci-dessous scontrol show partitions permettra de visualiser les QoS autorisées sur une partition.

Une QoS peut aussi être directement affectée à un job via l’option --qos :

% sbatch --qos=flash my_script.sh

Afin de lister les QoS disponibles, on pourra utiliser de nouveau la commande sacctmgr :

% sacctmgr show qos format=Name,Priority,MaxWall,MaxSubmitPU
      Name   Priority     MaxWall MaxSubmitPU
---------- ---------- ----------- -----------
    normal          0  7-00:00:00
     flash         50    01:00:00          10

Ici, on a restreint la sortie aux seuls champs nom, priorité, durée d’exécution et limite maximale de jobs soumis par utilisateur via l’option format.

La QoS normal est appliquée par défaut à tous les jobs. Elle en limite donc la durée d’exécution à 7 jours maximum. La QoS flash, quant à elle, limite ce temps d’exécution à 1 heure, mais augmente sa priorité, donc sa mise en exécution. Elle sera à privilégier pour effectuer des tests courts pour lesquels on souhaite avoir un résultat rapide. Le nombre de jobs simultanés utilisant cette QoS est toutefois limité à 10 par utilisateur.

Ressources

Gestion du nombre de cœurs et de la mémoire

Sans spécification particulière à la soumission, le nombre de cœurs alloué au job sera de 1, et la mémoire associée de 3G. Ce rapport entre le nombre de cœurs et la mémoire sera conservé par Slurm.

Premier exemple :

% sbatch -n 2 --mem 4G my_script.sh

Slurm allouera 2 cœurs CPUs, et 6 GB de mémoire (2 x 3 GB).

Second exemple :

%sbatch -n 2 --mem 8G my_script.sh

Slurm allouera ici 9 GB de mémoire (3 x 3 GB) et donc 3 cœurs CPU.

Les ressources cœurs CPU et mémoire disponibles seront limitées par les spécifications des serveurs de calcul. Pour la partition par défaut, i.e. htc, on ne pourra donc demander plus de 64 cœurs CPU ou 192 GB de mémoire.

Note

Il n’est pas nécessaire d’indiquer à la fois la mémoire et le nombre de cœurs CPU requis. Il suffit de spécifier la ressource qui fixera la valeur de la seconde.

Important

Dans le cas des GPUs, Slurm allouera 8GB par cœur CPU.

Utilisation de logiciels soumis à licence

Il est nécessaire de déclarer à la soumission les systèmes de stockage accédés par vos jobs, ainsi que les éventuelles licences logicielles utilisées. Cette déclaration se fait en utilisant l’option -L de la commande sbatch :

% sbatch -L sps my_script.sh

Les principales ressources de stockage à déclarer sont : dcache, hpss, irods, mysql, oracle, sps, xrootd ; pour les ressources de licenses, on a principalement : idl, matlab.

Pour la liste exhaustive des ressources accessibles par la déclaration, veuillez vous référer à la page dédiée.

Afin de vérifier le nombre de licences utilisées, on utilisera la commande scontrol :

% scontrol show lic

On peut aussi spécifier une licence spécifique :

% scontrol show lic cvmfs
LicenseName=cvmfs
Total=97000 Used=0 Free=97000 Reserved=0 Remote=no

Exemples de soumission de différents types de jobs

Script de soumission

Il est possible de spécifier des options de soumission directement dans le script my_python_script.sh via la directive #SBATCH :

#!/bin/bash
#SBATCH --job-name=serial_job_test    # Job name
#SBATCH --mail-type=END,FAIL          # Mail events (NONE, BEGIN, END, FAIL, ALL)
#SBATCH --mail-user=alice@ufl.edu     # Where to send mail
#SBATCH --ntasks=1                    # Run on a single CPU
#SBATCH --mem=1gb                     # Job memory request
#SBATCH --time=00:05:00               # Time limit hrs:min:sec
#SBATCH --output=serial_test_%j.log   # Standard output and error log

module load python
python my_python_script.py

Dans cet exemple simple, on met en place un environnement Python via modules afin d’exécuter le programme Python my_python_script.py. L’ensemble des options de sbatch sont passées via des directives #SBATCH, et ce script pourra simplement être soumis comme suit :

% sbatch my_script.sh

Job mono-cœur

La soumission d’un job monocœur se fait simplement avec la commande suivante :

% sbatch my_script.sh

Le job sera alors exécuté dans la partition définie par défaut, i.e. htc et avec la QoS par défaut, i.e. normal.

Si l’on souhaite accèder à une ressource nécessitant la déclaration, on utilisera l’option -L :

% sbatch -L sps my_script.sh

Job multi-cœurs

La soumission d’un job multi-cœurs se fait comme précédemment, mais en précisant le nombre de cœurs requis à la ligne de commande :

% sbatch -n 8 my_script.sh
-n <nombre>
spécifie le nombre d’itérations (ici, -n 8 indique que le code sera exécuté 8 fois)

Job interactif

La soumission d’un job interactif se fait via la commande srun et l’on doit préciser la partition adéquate.

Soumission d’un job interactif de type mono-cœur ou multi-cœurs :

% srun -p htc_interactive --pty bash -i

Soumission d’un job interactif de type GPU :

% srun -p gpu_interactive --gres=gpu:1 --pty bash -i

ou, si l’on souhaite préciser le type de GPU requis :

Nvidia V100

% srun -p gpu_interactive --gres=gpu:v100:1 --pty bash -i

Nvidia K80

% srun -p gpu_interactive --gres=gpu:k80:1 --pty bash -i

Avec les options :

-p
sélectionne la partition
--gres
permet de spécifier l’utilisation d’une ressource GPU, et de la définir.
--pty
autorise l’interactivité avec la session ouverte (voir note précédente).

Afin de quitter sa session interactive, il faut faire :

% exit

Job parallèle (MPI)

Il s’agit de jobs qui exécutent des opérations en parallèle, possiblement sur des serveurs de calcul différents, en utilisant une interface de type MPI à travers une connectique InfiniBand. Il faut préciser la partition hpc :

% sbatch -p hpc -n 8 -N 2 my_script.sh
-N <nombre>
spécifie le nombre de serveurs de calcul requis

Note

Dans le cas où le nombre de serveurs de calcul (option -N) est 1, il n’est pas nécessaire de l’indiquer, ni de spécifier la partition.

Job GPU

Ce sont des jobs qui s’exécutent sur des serveurs de calcul équipés de GPUs. Ils peuvent être multi-cœurs, parallèles, et interactifs. La soumission de tels jobs doit se faire sur la partition dédiée, i.e. gpu :

% sbatch -p gpu --gres=gpu:1 my_script.sh

ou encore :

Nvidia V100

% sbatch -p gpu --gres=gpu:v100:1 my_script.sh

Nvidia K80

% sbatch -p gpu --gres=gpu:k80:1 my_script.sh

Deux types de GPUs sont disponibles au CC-IN2P3, les K80s identifiés par le mot clé k80, et les V100s par le mot clé v100 :

--gres=gpu:k80:1
--gres=gpu:v100:1

Ici, on demande l’allocation d’un seul GPU, mais il est possible d’en utiliser plusieurs.

Note

Sans préciser le type de GPU requis, i.e. k80 ou v100, Slurm fera une allocation sur le premier GPU disponible. Il est donc recommandé de préciser le type à privilégier à la soumission.

Enchaînement de jobs

Il est possible d’utiliser la notion de dépendance de Slurm pour bâtir un enchaînement (pipeline) de jobs basé sur la réalisation de conditions spécifiques :

% sbatch --dependency=<type:job_id[:job_id][,type:job_id[:job_id]]> my_script.sh

Avec les types de dépendances suivants :

after:jobid[:jobid...]
exécution possible après qu’un ou plusieurs jobs donnés (identifiés par leurs identifiants) aient été démarrés
afterany:jobid[:jobid...]
exécution possible après qu’un ou plusieurs jobs donnés soient terminés
afternotok:jobid[:jobid...]
exécution possible après qu’un ou plusieurs jobs donnés aient échoués
afterok:jobid[:jobid...]
exécution possible après qu’un ou plusieurs jobs donnés se soient terminés avec succès (code retour de 0)
singleton
exécution possible après que tous les jobs d’un même nom appartenant au même utilisateur se soient terminés.

Un exemple de construction d’un tel pipeline est donné sur cette page.