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
)
- IPv4 :
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
oumpiicc
parcc
icpc
,g++
,mpicxx
oumpiicpc
parCC
ifort
,g77
,gfortran
,mpif90
oumpiifort
parftn
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
oumpiicc
parcc
icpc
,g++
,mpicxx
oumpiicpc
parCC
ifort
,g77
,gfortran
,mpif90
oumpiifort
parftn
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 MPICHCC
correspond au compilateur C++ de Cray + Cray MPICHftn
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 MPICHCC
correspond au compilateur C++ d'Intel + Cray MPICHftn
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
etftn --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 modulecpe_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 modulecpe_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
oumodule 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 modulesdata/hdf5/1.12.0-serial-szip_gcc
oudata/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 commandesmodule show data/hdf5/1.12.0-serial-szip_gcc
oumodule 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 modulemath/mkl/2023.0.0/lp64/blas-lapack_gcc
(charger ce module, puis inclure dans vos fichiers makefile les variables dont la commandemodule 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 (commandenvcc
). - 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 compilationcc
/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
-
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
oujob_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 :
- soumettre un premier job avec l'option
--exclusive=user
:sbatch --exclusive=user script01.sl
- lorsque ce 1er job est en cours d'exécution (running) identifier le nom du serveur sur lequel le job s'exécute
- 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.