Aller au contenu

Guide d'utilisation du cluster Austral

Architecture

Une description matérielle du cluster Austral est disponible.

Se connecter

  • Serveurs de connexion SSH (frontales) : ssh -l votre_login austral.criann.fr
  • Serveur de connexion spécialisé au transfert de données avec l'extérieur : ssh -l votre_login austral-transfert.criann.fr
  • Serveurs de connexion VNC : les informations sont fournis lors de la réservation d'une session de visualisation

Première connexion SSH

A votre première connexion SSH vous serez invité à changer votre mot de passe en suivant les restrictions de sécurité qui vous ont été transmise lors de l'ouverture de votre compte.
Le processus est en deux étapes :

  • vous vous connectez avec votre mot de passe initial et vous avez un prompt "(current) password" auquel vous devez y saisir votre mot de passe initial
  • puis vous avez une demande, et sa confirmation, de saisie de votre nouveau mot de passe

Lorsque vous aurez changer votre mot de passe la session se fermera toute seule, c'est normal. Nous vous invitons alors de relancer la connexion SSH et vous aurez accès au système.

Firewall

Si votre structure a un firewall limitant les flux en sortie de votre site, voici les ports à ouvrir :

  • Connexions SSH (port TCP/22) vers les frontales
    • IPv4 : 195.221.22.130 (austral.criann.fr; austral-front1.criann.fr)
    • IPv4 : 195.221.22.131 (austral.criann.fr; austral-front2.criann.fr)
    • IPv4 : 195.221.22.132 (austral.criann.fr; austral-front3.criann.fr)
    • IPv4 : 195.221.22.133 (austral.criann.fr; austral-front4.criann.fr)
    • IPv4 : 195.221.22.134 (austral-transfert.criann.fr)

Gestion de vos données

Une documentation sur la gestion des données est disponible.

Suivi des consommations

Une commande est mise à disposition sur les frontales pour avoir accès à un relevé de la consommation en h.cpu : maconso

Passer de Myria à Austral

Compiler

Lire entièrement le paragraphe Compilation

Pour les raisons développées dans ce dernier : dans vos fichiers makefile, vous devez remplacer

  • icc, gcc, mpicc ou mpiicc par cc
  • icpc, g++, mpicxx ou mpiicpc par CC
  • ifort, g77, gfortran, mpif90 ou mpiifort par ftn

Les codes MPI ciblant le serveur à large mémoire (SMP) font exception à cela (voir plus bas).

Nomenclature des modules d’applications ou de bibliothèques

Sur Austral, la nomenclature des modules mentionne leur catégorie scientifique ou technique.

Par exemple, les modules pour NAMD ne se nomment plus namd/version comme sur Myria, mais atomic_simu/namd/version, les modules pour OpenFOAM ne se nomment pas openfoam/version mais cfd_fem/openfoam/version. Les modules pour PyTorch se nomment aidl/pytorch/version.

Lire le paragraphe Logiciels disponibles

Intelligence Artificielle / apprentissage profond

Lire la page dédiée au domaine IA - Deep Learning pour Austral

GPUs SMT

Le SMT (Simultaneous MultiThreading) a été activé sur le serveur c23gpu4 faisant passer le nombre de cpus disponibles de 64 à 128.

Concernant Slurm le serveur a été affecté à la partition gpu_smt. Les scripts de soumission restent similaires à ceux des autres partitions ciblant des serveurs munis de GPUs. Pour la soumission de jobs il est recommandé de demander 16 cpus par GPUs.

Dans certains cas de figure cela peut améliorer les performances des codes d'IA, en particulier lors du chargement multithreadé des données.

Un exemple complet basé sur le tutoriel mnist pour pytorch est disponible sur Austal : /soft/slurm/Modeles_scripts/pytorch-smt/

GPUs MIG

La technologie MIG (Multi-instance GPU) de NVIDIA permet de partitionner un processeur graphique A100 jusqu'à sept instances distinctes, chacune étant entièrement isolée avec sa propre mémoire à bande passante élevée, son cache spécial ainsi que des Stream Multiprocessor (SM) et tensor core (TC) dédiés.

Sur Austral, les 8 A100 d'un serveur complet ont été partitionnées afin de proposer un total de 31 devices GPUs de puissances variées :

  • 10 devices a100_1g.10gb avec 10 GB de Mémoire, 14 SM et 56 TC
  • 17 devices a100_2g.20gb avec 20 GB de Mémoire, 28 SM et 108 TC
  • 4 devices a100_3g.40gb avec 40 GB de Mémoire, 42 SM et 164 TC

Bien que leur puissance soit moindre que celle d'un A100 complet, ces devices offrent de bonnes performances pour l'entraînement de réseaux de neurones avec l'utilisation des tensor cores.

Pour utiliser l'un de ces devices dans vos calculs il faut :

  • cibler la partition hpda_mig avec l'option --partition hpda_mig de sbatch
  • préciser le type de device souhaité avec l'option --gres de sbatch :
    • --gres=gpu:a100_1g.10gb pour l'architecture a100_1g.10gb
    • --gres=gpu:a100_2g.20gb pour l'architecture a100_2g.20gb
    • --gres=gpu:a100_3g.40gb pour l'architecture a100_3g.40gb

Un exemple complet basé sur le tutoriel mnist pour pytorch est disponible sur Austal : /soft/slurm/Modeles_scripts/pytorch-mig/

Scripts d'exécution par Slurm : /soft/slurm/Modeles_scripts

Compilation

Environnement

Le CPE (Cray Programming Environment) comprend les modules de compilateurs (Gnu, Cray, Intel) et de bibliothèques MPI Cray MPICH pour le réseau Slingshot.

Dans vos fichiers makefile, vous devez remplacer (hormis pour les codes MPI ciblant le serveur à large mémoire (SMP))

  • icc, gcc, mpicc ou mpiicc par cc
  • icpc, g++, mpicxx ou mpiicpc par CC
  • ifort, g77, gfortran, mpif90 ou mpiifort par ftn

Le compilateur de Gnu est suggéré par défaut.

Le module cpe_env/gcc-milan-08.23 est pré-chargé.

Il regroupe le compilateur de Gnu (11.2.0) avec optimisations intégrées pour l’architecture des CPU AMD Milan, et la librairie MPI Cray MPICH (8.1.20).

Concrètement :

  • La commande cc correspond à gcc + Cray MPICH
  • La commande CC correspond à g++ + Cray MPICH
  • La commande ftn correspond à gfortran + Cray MPICH

Regroupements alternatifs d'environnements

Après module load cpe_env/craycc-genoa-08.23

  • cc correspond au compilateur C de Cray + Cray MPICH
  • CC correspond au compilateur C++ de Cray + Cray MPICH
  • ftn correspond au compilateur FORTRAN de Cray + Cray MPICH

avec optimisations intégrées pour l’architecture AMD Genoa.

Après module load cpe_env/icc-milan-08.23

  • cc correspond au compilateur C d'Intel + Cray MPICH
  • CC correspond au compilateur C++ d'Intel + Cray MPICH
  • ftn correspond au compilateur FORTRAN d'Intel + Cray MPICH

avec application de jeu d'instructions AVX2, compatibles avec les processeurs AMD Milan et Genoa.

Environnements les plus récents

Suite à la mise à jour de février 2024 et des suivantes, les modules initiaux de compilation cpe_env/*.08.23 ont été conservés et restent supportés par la nouvelle configuration d’Austral (le module pré - chargé à la connexion est resté le même que précédemment : cpe_env/gcc-milan-08.23).

Les modules de février 2024 cpe_env/*.02.24 et d'août 2024 cpe_env/*.08.24 (voir module avail cpe_env) fournissent des versions plus récentes de compilateur ou de bibliothèque MPI ou de bibliothèque scientifique (cray-libsci). Les développeurs qui souhaiteraient re-compiler leurs applications avec ces environnements, doivent nous contacter s’ils emploient des bibliothèques externes partagées (autres que cray-hdf5, cray-fftw, cray-libsci) car nous devrons compiler ces bibliothèques avec ces nouveaux compilateurs.

Commandes utiles

  • cc --version, CC --version et ftn --version rappellent le compilateur (Gnu, Cray ou Intel) et sa version auxquels ces wrappers correspondent.
  • man gcc, man g++, man gfortran, man craycc, man crayCC, man crayftn, man icx, man ifort pour la documentation d'options de compilation.

Remarque

  • Les serveurs fins (purement CPU) d’Austral ont un CPU de génération Genoa, la plus récente d’AMD lors de l'ouverture d’Austral (septembre 2023). Les compilateur de Gnu version 10 à 12 intègrent l'option pour l'architecture précédente Milan (-march=znver3, automatiquement appliquée sous l'environnement du module cpe_env/gcc-milan-08.23). Cette architecture Milan est d'ailleurs celle des CPU des serveurs HPDA et GPGPU d'Austral. Compte tenu d’une compatibilité ascendante, un code compilé pour l’architecture Milan fonctionne sur l’architecture Genoa.
  • Le compilateur de Cray supporte l'option d'optimisation -march=znver4 pour Genoa, automatiquement appliquée sous l'environnement du module cpe_env/craycc-genoa-08.23.

Bibliothèques scientifiques directement intégrées au CPE (Cray Programming Environment)

  • HDF5 s'active par la commande module load cray-hdf5 ou module load cray-hdf5-parallel
  • FFTW (séquentielle, threadée ou MPI) s'actvie par la commande module load cray-fftw
  • BLAS, LAPACK et SCALAPACK sont activées par le module cray-libsci qui est pré - chargé à la connexion sur Austral

À condition que cc / CC / ftn soient utilisés, le chargement de ces modules cray-* permet la prise en compte de ces librairies lors de vos compilations, sans aucun ajout dans vos fichiers makefile.

Remarques :

  • Les modules cray-hdf5 fournissent des versions de HDF5 qui n’ont pas toutes les fonctions optionnelles de cette bibliothèque. En particulier, pour la compression de format szip utiliser l’un des modules data/hdf5/1.12.0-serial-szip_gcc ou data/hdf5/1.14.1-parallel-szip_gcc (dans ce cas, vos fichiers makefile devront être complétés par vos soins, par les variables dont les commandes module show data/hdf5/1.12.0-serial-szip_gcc ou module show data/hdf5/1.14.1-parallel-szip_gcc fournissent le nom).

  • Si une fonction d'algèbre linéaire n'est pas fournie par cray-libsci, essayer les versions Gnu du standard MKL par le module math/mkl/2023.0.0/lp64/blas-lapack_gcc (charger ce module, puis inclure dans vos fichiers makefile les variables dont la commande module show math/mkl/2023.0.0/lp64/blas-lapack_gcc fournit le nom).

Codes GPU

  • Le module nvhpc-byo-compiler/22.7 fournit le toolkit de NVIDIA comprenant CUDA 11.7 (commande nvcc).
  • Le module nvhpc/22.7 active en plus les compilateurs de NVIDIA (nvc / nvc++ / nvfortran), utiles pour leur support des directives OpenACC et OpenMP target de programmation pour GPU.

Codes ciblant le serveur à large mémoire (SMP)

  • Un code séquentiel ou multi-threads devant être exécuté sur le serveur SMP peut être compilé sous l'un des environnements de modules cpe_env mentionnés ci-dessus, avec les commandes de compilation cc / CC / ftn

  • La bibliothèque MPI supportée et optimisée pour le serveur SMP n'est pas Cray MPICH, mais HPE MPI. Un code MPI ciblant ce serveur SMP doit alors être compilé après exécution des commandes suivantes

    module purge
    module load hpe_env/mpt/2.29-gcc11
    module list
    
  • utiliser des commandes de compilation mpicc / mpicxx / mpif90 (correspondant à gcc / g++ / gfortran + HPE MPI)

  • ajouter explicitement dans les fichiers makfile l'option d'optimisation -march=cooperlake pour l'architecture Intel Cooper Lake de ce serveur SMP
  • si des bibliothèques extérieures faisant appel à MPI (comme par exemple la version MPI de HDF5 ou de FFTW) sont requises pour votre application, contacter support@criann.fr pour demander leur installation car elles devront être compilées avec HPE MPI

Environnement de soumission (Slurm)

La soumission des travaux se fait par la suite logicielle Slurm.

Le répertoire /soft/slurm/Modeles_scripts contient des modèles de scripts de soumission.

  • Pour les travaux ciblant le serveur à large mémoire (SMP), se référer aux modèles job_SMP_serial.sl, job_SMP_Mutli-threads.sl ou job_SMP_MPI.sl (qui conseillent la directive --hint nomultithread)

Commandes

Ce tableau fournit les commandes utiles pour la soumission des travaux.

Action Commande
Caractéristiques des partitions (classes) sinfo
Soumettre un travail sbatch script_soumission.sl
Lister l'ensemble des travaux squeue
Lister ses propres travaux squeue -u login
Affichage des caractéristiques d'un travail scontrol show job job_id
Prévision d'horaire de passage d'un travail en file d'attente squeue --start --job job_id
Vérification de la syntaxe et prévision d'horaire de passage d'un travail sans le soumettre sbatch --test-only script_soumission.sl
Prévision d'horaire de passage de ses propres travaux squeue -u login --start
Tuer un travail scancel job_id

Les partitions (classes de soumission)

Partitions pour architectures spécifiques

Partition Durée maximale Nœuds disponibles Limites par calcul
gpu 48 h 5 nœuds AMD Rome avec 8 GPUs Ampere A100 80GB NVLink4 2 nœuds (16 GPU, 256 cœurs CPU, 2x492000 MB de mémoire)
hpda 72 h 4 nœuds AMD Rome avec 8 GPUs Ampere A100 80GB NVLink4 1 nœud (8 GPU, 256 cœurs CPU, 492000 MB de mémoire)
gpu_all 48 h les nœuds des partitions gpu et hpda 2 nœuds (16 GPU, 256 cœurs CPU, 2x492000 MB de mémoire)
gpu_smt 48 h 1 nœud AMD Rome SMT avec 8 GPUs Ampere A100 80GB NVLink4 1 nœud (8 GPU, 128 cœurs CPU, 492000 MB de mémoire) Voir paragraphe sur les serveurs gpus smt
hpda_mig 72 h 1 nœud AMD Rome SMT avec 8 GPUs Ampere A100 80GB NVLink4 Voir paragraphe sur les MIG
smplarge 3 h le nœud à large mémoire (SMP) 1 nœud (224cœurs CPU, 6092000 MB de mémoire)
smplong 72 h le nœud à large mémoire (SMP) ½ nœud (112 cœurs CPU, 3046000 MB de mémoire)

Le nombre de GPU max utilisés par un utilisateur sur les partitions gpu + gpu_all + hpda est de 16 GPU et 128 cœurs en semaine et 32GPU et 256 cœurs pendant le week-end (du vendredi 17h au dimande 20h).

Partitions pour calculs parallèles

Un nœud comprend 192 cœurs AMD Genoa et 714 GB de mémoire (DDR5) disponible pour les applications (#SBATCH--mem 714gb ou #SBATCH --mem 732000 au maximum pour la demande de mémoire par nœud).

Partition Durée maximale Nœuds disponibles Limites par calcul
debug 30 min 124 nœuds Genoa 2 nœuds
2tcourt 12 h 124 nœuds Genoa 44 nœuds
tcourt 24 h 120 nœuds Genoa 22 nœuds
tcourt_intra 24 h 30 nœuds Genoa 1 nœud
court 48 h 40 nœuds Genoa 6 nœuds
long 100 h 24 nœuds Genoa 2 nœuds
tlong 300 h 12 nœuds Genoa 1 nœud

Le nombre de cœurs max utilisés par un utilisateur sur les partitions parallèles est de 4224 cœurs ou 22 nœuds en semaine et 8448 cœurs ou 44 nœuds pendant le week-end (du vendredi 17h au dimande 20h).

Usage exclusif d'un serveur

  • L'option --exclusive réserve l'intégralité d'un nœud pour le job. Cela permet de s'assurer qu'aucun autre job ne tournera sur le nœud utilisé durant le calcul.
  • L'option --exclusive=user permet le partage des serveurs entre différents jobs d'un même utilisateur.

Afin d'exécuter plusieurs jobs sur un seul et même serveur vous pouvez appliquer la méthode suivante :

  1. soumettre un premier job avec l'option --exclusive=user :
    • sbatch --exclusive=user script01.sl
  2. lorsque ce 1er job est en cours d'exécution (running) identifier le nom du serveur sur lequel le job s'exécute
  3. soumettre les jobs suivants avec l'option --exclusive=user en ciblant le nœud sur lequel le 1er job est en cours d'exécution à l'aide de l'option -w :
    • sbatch --exclusive=user -w <nodename> script02.sl

Un exemple de script bash automatisant cette méthode est disponible sur Austral à l'emplacement suivant : /soft/slurm/Modeles_scripts/exclusive_user

Bilan en fin de calcul

Slurm génère un fichier .o (standart output) et .e (standart error). Nous vous suggérons fortement de consulter le fichier .e.
Les chemins et noms de ces deux fichiers sont paramétrables dans le script de soumission (voir fichiers d'exemples).

Nous complétons le fichier .o par un rapport de consommation du calcul extraite avec la commande sacct. Vous y retrouvez en autre la consommation horaire, les ressources mémoire demandées et utilisées, les noeuds réservées.

Plus de détails sur la page Rapport de consommation.

Logiciels disponibles

Les commandes suivantes sont utiles pour rechercher les applications disponibles.

  • Modules scientifiques
    • module avail aidl
    • module avail atom
    • module avail bio
    • module avail cfd_fem
    • module avail math
    • module avail climate
    • module avail data
    • module avail mesh
    • module avail couplers
  • Environnements
    • module avail py_env
    • module avail cpe_env
    • module avail tools/

Le nom d’un module peut aussi être recherché à partir du nom de l’application (exemples : module avail python, module avail anaconda, module avail gromacs).

Pour une application mise en production par le Criann, le script de soumission par Slurm qui est fourni (dans /soft/slurm/Modeles_scripts si elle est partagée) applique la commande de chargement de son module.

Suivi de la consommation horaire

À partir des frontales, la commande maconso affiche votre consommation ainsi que celle du projet. Si vous êtes responsable de projet ou responsable adjoint maconso -u indique le détail pour tous les comptes.

Ces informations sont également accessibles au format JSON dans le fichier ~/.acct.json.

Les consommations sont actualisées toutes les nuits.

Calcul de la comptabilité horaire

Le calcul des heures sur Austral se base sur les ressources réservées par les calculs dans Slurm :

  • 1 calcul 56 cœurs de 3h : 56 x 3 = 168h
  • 1 calcul intra-noeud 56 cœurs de 3h en mode --exclusif sur un serveur "fin" (192 cœurs) : 192 x 3 = 576h

Plus d'information sur la page Rapport de consommation.


Dernière mise à jour: 11 octobre 2024 09:02:20