Voici une liste de termes techniques couramment utilisés, avec leur signification dans le contexte du cluster HPC :
Cluster : Groupe de multiples ordinateurs (nœuds) interconnectés, travaillant ensemble pour effectuer des calculs intensifs. Un cluster HPC (High Performance Computing) est optimisé pour la performance et la parallélisation.
Nœud : Un serveur individuel au sein du cluster. On distingue les nœuds de calcul (destinés à exécuter les jobs) et les nœuds de login (ou nœud frontal, pour la connexion des utilisateurs et la soumission des jobs).
CPU / Cœur : Unité de base de calcul (processeur). Un nœud contient un ou plusieurs CPU physiques, chacun ayant plusieurs cœurs (units d’exécution indépendantes). Les jobs peuvent demander un certain nombre de cœurs.
GPU : Processeur graphique utilisé pour le calcul (pas pour l’affichage dans ce contexte). Certains nœuds possèdent des GPU (ex: NVIDIA Tesla) pour accélérer les calculs massivement parallèles (deep learning, simulations).
Mémoire (RAM) : Mémoire vive accessible aux CPU/GPU d’un nœud. Les jobs doivent demander la RAM nécessaire. Une consommation excessive de RAM par rapport à la demande peut entraîner l’arrêt du job (Out-Of-Memory).
Job : Tâche soumise au gestionnaire de ressources. Un job peut être un script batch ou un processus lancé via Slurm, avec des ressources allouées (cœurs, mémoire, temps, GPU…).
Scheduler / Gestionnaire de files : Logiciel orchestrant l’exécution des jobs sur le cluster en fonction des ressources disponibles et des priorités. Sur ISDM, c’est Slurm. Il place les jobs en file d’attente et les exécute en respectant les contraintes.
Slurm : (Simple Linux Utility for Resource Management) Gestionnaire de workload HPC utilisé sur le cluster. On interagit avec Slurm via des commandes comme sbatch, squeue, srun, etc., pour soumettre et contrôler les jobs.
Partition : Regroupement logique de ressources dans Slurm (aussi appelé queue). Par exemple "courte" pour jobs <2h, "longue" pour jobs jusqu’à 2 jours, "gpu" pour jobs nécessitant des GPU. Chaque partition peut avoir des limites de temps ou de nombre de nœuds.
sbatch : Commande Slurm permettant de soumettre un job batch (non interactif) à partir d’un script.
srun : Commande Slurm pour lancer un job interactif ou exécuter un binaire sur des ressources allouées (soit via salloc, soit directement avec srun qui fait allocation+exécution).
salloc : Commande Slurm pour réserver des ressources (nœud(s)) de manière interactive, en ouvrant ensuite un shell où vous pouvez lancer des tâches manuellement.
squeue : Commande affichant la liste des jobs dans la file (queue) de Slurm, et leur état (en attente, en cours…).
scancel : Commande pour annuler un job en file ou en cours d’exécution.
Job ID : Identifiant numérique unique assigné à chaque job soumis (par Slurm). Permet de suivre/contrôler un job (squeue -j <id>, scancel <id>).
ENVIRONNEMENT (logiciel) : Contexte logiciel dans lequel un job tourne (variables d’environnement, modules chargés, chemins). Configurer l’environnement de job (via modules, conda, etc.) est crucial pour que le job trouve les exécutables et librairies nécessaires.
Module : Voir Modules d’environnement – système pour charger/décharger des configurations logicielles sur le cluster (via module load nom/version). Par ex, charger un module Python met la bonne version de Python dans le PATH.
Conda : Gestionnaire d’environnements virtuels très utilisé pour Python/R. Permet d’installer des packages utilisateur dans des environnements isolés (voir section Conda).
Spack : Gestionnaire de paquets HPC permettant de compiler/installer des logiciels scientifiques avec différentes configurations, sans droits admin (voir section Spack).
Singularity / Conteneur : Technologie de virtualisation légère. Un conteneur encapsule un logiciel et son OS. Singularity permet d’exécuter des conteneurs (ex Docker) sur HPC sans privilèges (voir section Singularity).
MPI : (Message Passing Interface) Technologie de programmation pour exécuter un programme sur plusieurs nœuds en communiquant par messages. Nécessite de multiples processus (via --ntasks Slurm) et un backend (OpenMPI, MPICH… souvent fourni via modules). Utilisé pour le calcul parallèle distribué.
OpenMP : Interface de programmation pour paralléliser un programme sur plusieurs cœurs d’un même nœud (parallélisme partagé-mémoire, threads). Contrôlé par les threads, ex: OMP_NUM_THREADS. Utilisé en complément ou en alternative à MPI.
Thread : Un fil d’exécution léger (géré au sein d’un processus). Un programme multi-thread (OpenMP, Threads C++11, Java, etc.) peut utiliser plusieurs cœurs sur un nœud. Slurm considère généralement un job = un processus, pouvant lancer X threads sur X cœurs (d’où l’option --cpus-per-task).
Infiniband : Réseau haute performance utilisé entre les nœuds du cluster, offrant une latence faible et une forte bande passante, utile pour MPI et transferts rapides de données.
Scratch : Espace de stockage temporaire et de travail sur le cluster, généralement de grande capacité mais non sauvegardé. Conçu pour stocker les données massives pendant les traitements. À vider/nettoyer périodiquement.
Home : Répertoire personnel de l’utilisateur sur le cluster (souvent monté sur tous les nœuds). Espace plus restreint, sauvegardé, pour conserver code source, scripts et résultats importants (de taille raisonnable).
Quota : Limite allouée de stockage (en volume et/ou nombre de fichiers) sur un espace (home, scratch, projet). Dépasser le quota peut empêcher de créer de nouveaux fichiers ou écrire dans des fichiers existants.
GPU Computing (CUDA) : Utilisation des GPU pour du calcul. CUDA est l’API de NVIDIA. Sur cluster, utiliser un GPU requiert de spécifier --gres=gpu:<N> dans Slurm, et d’avoir le code ou les logiciels compatibles GPU (ex: TensorFlow, PyTorch, simulations accélérées).
Job array : Tableau de jobs – ensemble de jobs identiques exécutés avec des paramètres différents (index). Slurm permet de soumettre un array job avec --array. Utile pour lancer 100 simulations légèrement différentes sans écrire 100 scripts séparés.
Throughput / Débit : Performance d’ensemble (ex: nombre de jobs traités par jour, ou bande passante en I/O). On optimise le throughput en lançant des jobs en parallèle (si possible) et en évitant les goulots d’étranglement (I/O, communications).
Speedup : Accélération obtenue en parallèle. Un speedup = 4 signifie qu’avec 4 cœurs on va 4 fois plus vite qu’avec 1. Le speedup réel est souvent inférieur au nombre de cœurs à cause des overheads (loi d’Amdahl).
Interactive session : Session de travail directe sur un nœud de calcul (via salloc/srun), par opposition à un job batch où vous soumettez et récupérez le résultat plus tard. Utile pour debug ou usage exploratoire.
Scheduler policy : Règles de priorité du scheduler (peuvent inclure des quotas de fair-share par utilisateur, des priorités aux jobs courts, etc.). Cela influence l’ordre de passage des jobs en attente.
Walltime : Durée “mur” réelle écoulée. Le temps --time de Slurm est la walltime maximale autorisée pour un job.
Core-hour : Unité de consommation de ressources (1 core-hour = 1 cœur utilisé pendant 1 heure). Un job utilisant 4 cœurs pendant 2h consomme 8 core-hours. Parfois utilisé pour la facturation ou le suivi de consommation.
Cluster de calcul (HPC cluster) : un ensemble de plusieurs ordinateurs (serveurs), interconnectés via un réseau rapide, travaillant ensemble comme une seule unité de calcul haute performance. Un cluster comporte généralement des nœuds de calcul pour exécuter les tâches et des nœuds de login/gestion pour l’accès utilisateur et l’orchestration. L’objectif est de réaliser des calculs intensifs plus rapidement ou en plus grande quantité qu’avec un seul ordinateur.
Noeud : un serveur (machine physique ou virtuelle) faisant partie du cluster.
Nœud de login (ou frontal) : serveur sur lequel les utilisateurs se connectent (via SSH) pour accéder au cluster. On y prépare les tâches (scripts, compilation, etc.) mais on n’y exécute pas de calcul lourd. Exemple : io-login.isdmcluster.fr.
Nœud de calcul : serveur dédié à l’exécution des travaux soumis. Il peut y en avoir des dizaines/centaines dans un cluster. Ils n’acceptent pas de connexion directe utilisateur (sauf via un job interactif). Ils possèdent de nombreux cœurs CPU, de la RAM, et éventuellement des GPU.
Nœud de gestion ou d’admin : machine orchestrant le cluster (horaire des jobs, monitoring). Invisible pour l’utilisateur.
CPU, Coeur : le processeur central d’une machine. Un CPU moderne a plusieurs cœurs (unités d’exécution indépendantes). Sur un cluster, on parle souvent en nombre de cœurs (par ex. “16 cores” sur un nœud). Par abus de langage, on dit aussi CPU pour signifier “cœur de CPU” dans le contexte de l’allocation Slurm. Un job peut demander plusieurs cœurs pour paralléliser des calculs.
GPU : processeur graphique pouvant effectuer des calculs massivement parallèles. Certains nœuds de calcul intègrent des GPU (ex: NVIDIA Tesla) utiles pour l’IA, le calcul matriciel, etc. Slurm permet de demander des GPU (--gres=gpu:1 par ex.). Les GPU ont leur propre mémoire dédiée.
SSH (Secure Shell) : protocole réseau sécurisé permettant de se connecter à un terminal distant de manière chiffrée. On l’utilise pour se connecter au cluster (ssh username@cluster). SSH peut aussi servir à copier des fichiers (scp, sftp) et à faire du port forwarding. Nécessite un client SSH côté utilisateur (PuTTY, MobaXterm, Terminal mac/Linux).
Terminal, Shell : interface en ligne de commande pour interagir avec le système. Sur Linux, le shell par défaut est Bash. On y tape des commandes texte et on reçoit des réponses texte. Par exemple, sur le cluster, après connexion SSH on obtient un terminal bash nous permettant de lancer des programmes, naviguer dans les fichiers, etc.
Commande : instruction tapée dans le terminal. Ex : ls, cd, mkdir sont des commandes. Une commande peut avoir des options (précédées de -) et des arguments (ex: nom de fichier).
Chemin (Path) : localisation d’un fichier ou dossier dans l’arborescence.
Chemin absolu (absolut path) : part de la racine /. Ex: /home/username/data/file.txt.
Chemin relatif (relative path) : part du répertoire courant. Ex: data/file.txt (si on est déjà dans /home/username). Dans les chemins Linux, on utilise la barre oblique / pour séparer les répertoires. ~ désigne le home de l’utilisateur courant. . désigne le répertoire courant, .. le répertoire parent.
Home directory (Home) : répertoire personnel de l’utilisateur sur le cluster. C’est l’emplacement par défaut à la connexion (accessible via ~ ou /home/<user>). On y stocke ses fichiers de travail importants, ses scripts. Espace généralement limité en taille et éventuellement sauvegardé par l’admin. Ex: /home/jdupont.
Scratch : espace de stockage temporaire à haute capacité sur le cluster. Non sauvegardé, purgé automatiquement. On l’utilise pour stocker les données volumineuses durant les calculs (données d’entrée, sorties intermédiaires). Chaque utilisateur peut avoir un scratch dédié (/scratch/username) ou partagé par projet. L’accès est rapide (disque local ou système de fichiers parallèle). Les fichiers anciens y sont supprimés passé un certain délai (ex: 30 jours). D’où l’importance d’y sauvegarder ailleurs les résultats finaux.
Workspace / Espace projet : espace de stockage destiné à un projet ou un groupe, accessible aux membres du projet. Souvent persistant pendant la durée du projet, de grande taille, mais non purgé automatiquement. Permet le travail collaboratif (les fichiers appartiennent à un groupe Unix correspondant au projet). Ex: /proj/MonProjet/…. À nettoyer en fin de projet et éventuellement archiver.
Stockage local (Local storage) : disque local d’un nœud de calcul (par opposition aux stockages partagés en réseau comme home/scratch). Par ex, /tmp sur un nœud est local au nœud. Sert à stocker des fichiers temporaires pendant un job. On y accède via la variable d’environnement $TMPDIR (paramétrée par Slurm) qui pointe vers un dossier unique pour votre job. Très rapide, mais volatil (les fichiers ne sont pas conservés après le job ou redémarrage du nœud).
Slurm : gestionnaire de travaux (workload manager) utilisé par le cluster pour planifier et allouer les ressources aux jobs. Slurm gère la file d’attente et le lancement des jobs sur les nœuds de calcul. Acronyme de Simple Linux Utility for Resource Management. Il fournit des commandes utilisateur (sbatch, squeue, scancel, salloc, srun…) pour interagir avec le système de queue. Slurm permet de partager équitablement le cluster entre utilisateurs et de maximiser l’utilisation des ressources.
Job : unité de travail soumise au gestionnaire (Slurm). C’est typiquement l’exécution d’un programme ou d’un script avec des ressources allouées (CPU, RAM, durée, etc.). On distingue :
Job batch : job non-interactif, lancé via sbatch avec un script. Il s’exécute en arrière-plan et on récupère les résultats dans des fichiers de sortie.
Job interactif : session interactive obtenue via salloc/srun où l’utilisateur peut taper des commandes en direct sur le nœud de calcul.
Job array : ensemble de jobs similaires soumis en une commande (utile pour paramétrer N runs similaires). Chaque job a un ID unique (numérique) et passe par des états (PENDING, RUNNING, COMPLETED, etc.).
Ordonnanceur / Gestionnaire de file : composant de Slurm (ou autre scheduler) qui décide de l’ordre de passage des jobs et de l’affectation aux ressources. Il utilise des politiques de priorité, de quotas, etc. pour faire cohabiter les usages. À l’utilisateur, cela est visible par l’attente possible des jobs (selon la charge du cluster) et les limitations imposées (nombre de jobs concurrent, temps max, etc. définis par la politique).
Partition : sous-ensemble de nœuds dans Slurm, configuré pour un type de jobs ou d’utilisateurs. Analogue à une queue. Exemples : partition "short" (jobs ≤ 2h), partition "long" (jobs jusqu’à 2 jours), partition "gpu" (nœuds avec GPU), partition par groupe/projet. Lors de la soumission (sbatch), on peut spécifier -p <partition>. Sinon, le job va dans la partition par défaut. Les partitions peuvent avoir des priorités différentes et des limites. Il faut soumettre dans la partition appropriée pour son job (par ex, un job de 10 minutes peut aller en short pour être servi plus vite; un job nécessitant un GPU doit aller en partition gpu).
Module (Environment Module) : mécanisme permettant de charger ou décharger des modules logiciels sur le cluster. Un module correspond à un logiciel (ou une bibliothèque) installé, et contient les informations pour ajuster l’environnement (variables PATH, etc.) afin de l’utiliser. Par exemple, il peut y avoir un module “python/3.9”, “gcc/10”, “openmpi/4.0”, “matlab/R2021a” etc. L’utilisateur utilise la commande module load <module> pour modifier son environnement de travail et rendre le logiciel disponible. Cela évite les conflits de versions et permet d’accéder à une large panoplie de logiciels sans les installer soi-même.
Charge utile : en HPC, se réfère au programme ou au calcul que l’on exécute. Dans un job Slurm, c’est le code que vous lancez (votre payload). On distingue cela des commandes Slurm de soumission ou de l’environnement.
GNU Guix : gestionnaire de paquets fonctionnel permettant d’installer des logiciels de manière reproductible sans droits admin. Guix peut être utilisé sur le cluster pour installer dans son espace personnel des logiciels non fournis par les modules. Il garantit l’isolation des dépendances. Commande : guix install <paquet>.
Spack : autre gestionnaire de paquets dédié HPC. Très utilisé pour compiler et installer des logiciels scientifiques avec des options spécifiques. Permet à un utilisateur ou admin d’installer des logiciels dans un arborescence isolée. Commande : spack install <package>. On peut ensuite spack load <package> pour l’utiliser.
Conda : outil de gestion d’environnements et de paquets (initialement pour Python, R…). Permet de créer des environnements virtuels contenant des versions spécifiques de Python et librairies. Utilisé largement en data science/bioinfo. On peut installer Anaconda/Miniconda sur le cluster dans son home. Commandes clés : conda create -n envname python=3.x, conda activate envname, conda install <package>. Facilitant l’installation de modules Python sans conflit.
Singularity / Apptainer : technologie de conteneurisation adaptée au HPC. Un conteneur est une image logicielle qui embarque un OS allégé et des logiciels, permettant de reproduire un environnement. Singularity permet d’exécuter ces conteneurs sans privilèges root sur le cluster. On peut ainsi faire tourner des applications dans le même état que sur une autre machine (ex: utiliser une image Docker de TensorFlow sur le cluster via Singularity). Commande : singularity exec image.sif <commande>. Apptainer est le nouveau nom du projet (SingularityCE).
EESSI : European Environment for Scientific Software Installations. Initiative fournissant un stack logiciel pré-compilé accessible à distance (via un système de fichiers en réseau, ex: CVMFS). En chargeant un environnement EESSI, un utilisateur peut accéder à de nombreux logiciels optimisés sans les installer localement. C’est transparent via modules. Encore émergent, utilisé dans certains environnements partagés européens.
Quota : limite allouée à un utilisateur (ou groupe) en termes de stockage (et parfois de nombre de fichiers). Par exemple, quota de 100 Go sur le home. Si on dépasse, on ne peut plus écrire de fichiers. Les quotas sont mis en place pour partager équitablement les ressources disque.
Purge : suppression automatique de fichiers, notamment sur les espaces temporaires (scratch). Une politique de purge définit après combien de temps d’inutilisation un fichier est supprimé. Ex: purge 30 jours sur /scratch ⇒ tout fichier n’ayant pas été modifié depuis 30 jours est effacé. But : libérer de l’espace.
Backup (sauvegarde) : copie de secours des données, effectuée régulièrement par l’admin (ou par vous-même). Sur les clusters, le home peut être sauvegardé (permettant une restauration en cas de crash). Scratch n’est pas sauvegardé. Il est de la responsabilité de l’utilisateur de sauvegarder ses données importantes (sur un autre système ou support).
Fair-share : mécanisme de Slurm qui ajuste la priorité de vos jobs selon votre usage passé par rapport à ce qui est “équitable”. Si vous avez beaucoup utilisé le cluster récemment, vos nouveaux jobs peuvent avoir une priorité un peu réduite pour laisser la place à d’autres utilisateurs moins servis, et vice versa.
Job Array : soumission groupée de jobs similaires, avec un identifiant de tableau. Permet de lancer, par exemple, 100 jobs en une commande, chacun avec un paramètre différent (index). Slurm gère cela avec --array. Utile pour les simulations paramétriques ou traitement de multiples jeux de données en parallèle.
Latency (latence) : délai de communication sur le réseau ou les disques. Sur un cluster, le réseau entre nœuds a une faible latence (surtout s’il est Infiniband/Omnipath), mais une latence non nulle par rapport à l’accès mémoire local. Les programmes parallèles doivent en tenir compte (utiliser MPI, etc.). Pour l’utilisateur, la latence se remarque lors de l’utilisation d’applis graphiques via X11 (peut être lent).
Infiniband : technologie de réseau haute vitesse et faible latence, courante dans les clusters HPC pour connecter les nœuds de calcul entre eux et au stockage. Permet des débits élevés (40G, 100G…) utile pour MPI (calcul distribué). Transparent pour l’utilisateur final, mais c’est ce qui rend les transferts de données entre nœuds rapides.
MPI (Message Passing Interface) : bibliothèque/protocole pour le calcul parallèle distribué (multi-nœuds). Permet à des processus s’exécutant sur différents nœuds de communiquer entre eux. Si vous lancez un job multi-nœuds (par ex. 2 nœuds avec 16 cœurs chacun), généralement votre programme utilisera MPI pour se coordonner. OpenMPI, MPICH sont des implémentations. Sur cluster, on charge un module MPI et on lance avec srun (Slurm intègre le démarrage des tâches MPI).
OpenMP : autre modèle de parallélisation, pour le multi-threading sur un seul nœud (mémoire partagée). Utile si vous utilisez plusieurs cœurs d’un même nœud. Le programme gère les threads. L’utilisateur spécifie --cpus-per-task pour donner plusieurs cœurs à un processus OpenMP.
Throughput (débit) : quantité de données traitées par unité de temps. On parle de débit réseau (ex: Mo/s transférés) ou débit d’un pipeline de calcul (ex: tant d’images traitées par minute). Sur un cluster, on optimise le throughput global en parallélisant les tâches.
Interactive Session : session utilisateur interactive sur un nœud de calcul (par opposition à une soumission batch). Permet de tester ou d’exécuter manuellement des commandes dans l’environnement d’un nœud de calcul alloué. Obtenue via salloc/srun comme discuté.
Scheduler : voir Ordonnanceur. Composant planifiant les jobs.
Core hour (heure de cœur) : unité de consommation de calcul = 1 cœur CPU utilisé pendant 1 heure. Souvent utilisée pour mesurer l’utilisation totale (ex: ce job a utilisé 16 cœurs pendant 2h ⇒ 32 core-hours). Utile pour la facturation ou le suivi de conso dans certains centres.
X11 : protocole d’affichage graphique sur Unix. Le X11 forwarding permet d’afficher des applications tournant sur le cluster sur votre écran local en transférant les instructions de dessin via SSH.
Environment variable (variable d’environnement) : paire nom/valeur présente dans le shell, qui influence le comportement des programmes. Ex: $HOME (chemin du home), $PATH (liste des répertoires où chercher les exécutables), $SLURM_JOBID (défini dans un job Slurm, identifiant du job), $OMP_NUM_THREADS (utilisé par OpenMP pour définir le nombre de threads). On peut définir/exporter des variables dans son shell ou dans ses scripts.
Profil d’environnement : scripts exécutés lors de la connexion ou de l’ouverture d’un shell, pour configurer l’environnement (variables, alias, modules). Sur bash : /etc/profile (global), ~/.bash_profile (perso pour shell login), ~/.bashrc (perso pour shells interactifs non login). Important pour customiser son environnement sur le cluster (par ex. charger un module par défaut, définir PS1…).