Slurm¶

Cet article est une introduction à Slurm, l'ordonnanceur de travaux (jobs). Vous trouverez les recettes pratiques pour commencer à travailler et des informations importantes sur la configuration du cluster.

Avant-propos¶

Sur un cluster de calcul, vous ne travaillez pas comme sur votre PC personnel. Vous ne pouvez pas lancer un programme inter-actif qui utiliserait immédiatement les ressources du cluster.

Pour exécuter un programme, vous devez le soumettre à l’ordonnanceur (scheduler). Le logiciel utilisé comme ordonnanceur sur notre cluster est slurm. Il exécutera votre travail (job) en différé, quand les ressources (CPU, mémoire, etc.) demandées par votre travail seront disponibles “quelque part” dans le cluster, sur un des nœuds dédiés aux calculs.

Débuter avec Slurm¶

Vous pouvez consulter l'article concernant le cluster CURTA.

Les informations sont globalement identiques, sauf pour les sections "Lancer des jobs MPI" et "Partitionnement du cluster", plus d'autres subtilités notées ci-après.

Soyez notamment attentif aux points suivants :

• Slurm restreint les ressources disponibles sur les nœuds de calcul aux ressources que vous avez demandé. Dit autrement, si vous demandez 2 cœurs et 1 GPU, votre job ne verra pas plus de CPU ou de GPU
• Si votre programme commence à utiliser plus de mémoire que la quantité demandée dans le job, il sera tué par Slurm
• Si votre job dure plus longtemps que demandé dans la réservation, il sera également tué par Slurm

Partitionnement du cluster, limites, GPU¶

Le cluster CALI v3 possède plusieurs partitions :

• gpu-h100 pour réaliser un calcul avec GPU H100
• gpu-l40 pour réaliser un calcul avec GPU L40
• gpu-gtx1080 pour réaliser un calcul avec GPU GTX 1080 Ti
• cpu pour réaliser un calcul sans GPU
• gold-* : partitions "privatives", permettant aux labos ayant financé certains équipements d'avoir un usage prioritaire sur leurs machines

Partitions gpu*¶

Informations :

• Quand vous voulez utiliser une (ou plusieurs) GPU, votre réservation doit comporter une option --gres gpu:N avec N le nombre de GPU voulues - Merci de bien avoir à l'esprit la configuration matérielle du cluster pour ne pas faire une demande impossible à satisfaire !
• Notez que l'option --gpus disponible dans SLURM n'est pas acceptée (pour diverses raisons techniques), vous devez utiliser --gres gpu:...
• Lorsque vous demandez plusieurs nœuds de calcul (option -N ou --nodes), la réservation de GPU sera appliquée sur chaque noeud. Dit autrement --nodes 2 --gres gpu:1 demande une réservation de 2 nœuds, chacun avec une GPU

Limites :

• Nombre de nœuds maximum par job : 2
• Durée maximale d'un job (temps écoulé) : 1 jour
• Les jobs lancés sur gpu-gtx1080 peuvent être pré-emptés, c'est-à-dire stoppés et remis en queue, pour des jobs des partitions "gold*" -- En effet, les noeuds ont été financés par des labos, qui restent prioritaires sur leurs équipements.

Partition cpu¶

Le cluster étant prioritairement conçu pour des calculs GPU, vous pouvez aussi lancer des calculs sans GPU ... mais :

• votre job sera moins prioritaire que ceux de gpu*
• les ressources disponibles sont limitées - les jobs de cpu ne peuvent pas prendre tout le cluster (96 coeurs par utilisateur à un moment donné, 24 coeurs par noeud)
• s'il y a trop de jobs mis en gpu*, des jobs de cpu seront stoppés pour laisser de la place aux calculs GPU (principe de pré-emption)

Limites :

• Nombre de nœuds maximum par job : 2
• Durée maximale d'un job (temps écoulé) : 1 jour
• Pré-emption possible par les jobs des partitions gpu* et gold-*

Partitions gold-*¶

Les partitions gold-* sont visibles et utilisables par les laboratoires qui ont financé certains équipements. Si des ressources sont en cours d'utilisation sur ces équipements, la pré-emption pourra se déclencher, si besoin, pour placer les jobs des partitions gold-*

Pour voir si vous avez accès à une partition gold*, listez simplement les partitions et leur utilisation avec la commande sinfo.

Limites :

• Les partitions gold-* ne sont pas soumises aux mêmes limites
  • 30 jours maximum pour un job
  • pas de limitation des ressources
• Le lancement d'un calcul en partition "gold*" ne sera pas compté ensuite lors du calcul de priorité pour déterminer quel job en attente sera exécuté (facteur d'usage nul)

Demander des "features"¶

Vous avez certainement noté (voir la page de description matérielle) que le cluster est hétérogène, avec des nœuds de calcul assez différents (en dehors même du type de GPU).

Le choix de la partition sera le premier critère pour demander des ressources spécifiques. Mais au sein d'une partition, vous pouvez utiliser les features pour préciser le placement voulu :

• Les features sont déclarés par nœud, pour les caractériser - Voir la page de description matérielle
• Lors de la soumission du job, utilisez les options --constraint ou --prefer pour exiger ou demander préférentiellement des nœuds ayant une ou plusieurs features. Voir les pages de manuel pour plus d'information (man sbatch)

Etant donné les caractéristiques de notre cluster, cette possibilité est avant tout à utiliser pour le placement des jobs CPU. Par exemple, si vous voulez obligatoirement des nœuds avec accès au réseau haute performance "RoCE" pour un calcul MPI distribué en partition cpu :

--partition cpu --constraint=net_roce

Bien entendu, vous ne pouvez pas "mixer" les features et partition comme vous le souhaitez, il faut que leur combinaison corresponde à des ressources matériellement disponibles dans le cluster.

Lancer des jobs MPI¶

Voir article sur MPI