Changements et impacts liés à l'extension Jean Zay H100

Cette page vous offre un aperçu des opérations en cours dans le cadre de la mise en ordre de marche de l'extension Jean Zay H100. Les informations données ici vont donc évoluer au fil du temps et nous vous invitons à venir la consulter régulièrement.

L'extension comporte de nouvelles frontales et des nœuds de calcul ayant chacun :

• 2 processeurs Intel Xeon Platinum 8468 (48 cœurs à 2,10 GHz), soit 96 CPU
• 4 GPU Nvidia H100 SXM5 80 Go
• 512 Go de mémoire

Cette extension comporte également de nouveaux espaces disques plus volumineux et plus rapides utilisant un système de fichier Lustre. Depuis la mi-août, ils remplacent les anciens espaces disques qui utilisaient un système de fichier Spectrum Scale d'IBM. Les données enregistrées sur l'ancien système de fichier (Spectrum Scale) ont été copiées/déplacées sur le nouveau (Lustre) par l'IDRIS, pour les espaces disques HOME, WORK, ALL_CCFRWORK, STORE et ALL_CCFRSTORE. Par contre, la recopie des espaces temporaires SCRATCH et ALL_CCFRSCRATCH étaient de la responsabilité de chaque utilisateur.

Notez que la volumétrie de stockage (en octets) des espaces WORK a été augmentée à cette occasion.

Afin de pouvoir gérer plus finement le partage des ressources sur la machine, des QoS spécifiques ont été définies pour la partition A100. Si vous utilisiez explicitement les QoS “qos_gpu-t3” ou “qos_gpu-dev” dans vos soumissions de travaux ciblant cette partition, vous devrez utiliser à la place “qos_gpu_a100-t3” ou “qos_gpu_a100-dev”. La QoS “qos_gpu_a100-t3” est utilisée par défaut et peut être omise.

Les partitions CPU et V100 ne sont pas touchées par ce changement.

La documentation a été mise à jour en conséquence : http://www.idris.fr/jean-zay/gpu/jean-zay-gpu-exec_partition_slurm.html#les_qos_disponibles.

Si vous souhaitez spécifier une QoS lorsque vous utilisez le lanceur Slurm sur JupyterHub, il faudra maintenant la spécifier manuellement dans le champ “Extra #SBATCH directives”.

L'adresse IP de notre instance JupyterHub a été modifiée. Il s'agit maintenant de 130.84.132.56. Ce changement peut vous impacter si votre organisme applique un filtrage par adresse IP des connexions sortantes. Si vous rencontrez des difficultés de connexion à JupyterHub, nous vous suggérons de prendre contact avec votre service informatique en leur signalement ce changement.

Pour rappel, la plage des adresses IP utilisées pour les machines et les services de l'IDRIS est la suivante : 130.84.132.0/23. Nous recommandons d'autoriser la plage complète plutôt que des adresses IP spécifiques afin de ne pas être affecté par de futurs changements internes à notre infrastructure.

Les utilisateurs ayant déjà obtenu des heures H100 peuvent désormais les utiliser. Vous pouvez vous inspirer de l'exemple ci-dessous :

#!/bin/bash
#SBATCH --job-name=mon_travail       # nom du job
#SBATCH -A xyz@h100                  # comptabilite a utiliser, avec xyz le trigramme de votre projet
#SBATCH -C h100                      # pour cibler les noeuds H100
# Ici, reservation de 3x24=72 CPU (pour 3 taches) et de 3 GPU (1 GPU par tache) sur un seul noeud :
#SBATCH --nodes=1                    # nombre de noeud
#SBATCH --ntasks-per-node=3          # nombre de tache MPI par noeud (= ici nombre de GPU par noeud)
#SBATCH --gres=gpu:3                 # nombre de GPU par noeud (max 4 pour les noeuds H100)
# Sachant qu'ici on ne reserve qu'un seul GPU par tache (soit 1/4 des GPUs),
# l'ideal est de reserver 1/4 des CPU du noeud pour chaque tache:
#SBATCH --cpus-per-task=24           # nombre de CPU par tache (1/4 des CPUs ici)
# /!\ Attention, "multithread" fait reference a l'hyperthreading dans la terminologie Slurm
#SBATCH --hint=nomultithread         # hyperthreading desactive
 
# Pour utiliser les modules compatibles avec cette partition H100
module purge
module load arch/h100
...

Notez que les modules par défaut ne sont pas compatibles avec la partition H100. Afin de retrouver l'environnement logiciel spécifique à cette partition, vous devez charger le module “arch/h100” : http://www.idris.fr/jean-zay/cpu/jean-zay-cpu-doc_module.html#modules_compatibles_avec_la_partition_gpu_p6. Cela doit être fait dans vos scripts de soumission mais aussi dans votre terminal si vous avez besoin de compiler des codes.

Si vous n'avez pas encore d'heures H100, le responsable du projet peut faire une demande au fil de l'eau sur le portail eDARI si nécessaire.

Depuis le lundi 22 juillet 2024, les modalités d'accès au STORE ont été modifiées. Ainsi, l'accès au STORE en lecture et écriture n'est plus possible depuis les nœuds de calcul mais il reste possible depuis les nœuds de connexion et les nœuds des partitions “prepost”, “visu”, “compil” et “archive”. Nous vous invitons à modifier vos jobs si vous accédez directement à l'espace STORE depuis les nœuds de calcul. Pour vous guider, des exemples ont été ajoutés à la fin de notre documentation sur les travaux multi-étapes.

Ce changement est dû au fait que la volumétrie du cache du STORE (sur disques rotatifs) sera diminuée au profit de la volumétrie du WORK. Nous ne pourrons plus garantir la redondance des données du STORE à la fois sur bandes magnétiques et sur disques rotatifs, comme c'était le cas jusqu'à présent. La présence de la donnée sur disques rotatifs permet une lecture/écriture relativement rapide de celle-ci. Avec la diminution de la volumétrie du cache, dans certains cas, la donnée pourra n'être stockée que sur bande magnétique (avec deux copies sur des bandes différentes pour garantir la redondance de donnée) ce qui dégraderait fortement les temps d'accès à la donnée et par conséquent les performances de vos calculs en cas d'accès direct au STORE.

Pour rappel, le STORE est un espace dédié au stockage pérenne de données archivées.

L'IDRIS s'est chargé de recopier les données stockées dans les HOME, WORK, ALL_CCFRWORK, STORE et ALL_CCFRSTORE.

ATTENTION : nous n'avons fait que de simples copies ce qui peut entraîner des dysfonctionnements de vos exécutions, notamment si vous utilisez des liens symboliques (comme ceux que nous recommandons de faire pour les environnements Python personnels par exemple). En effet, ceux-ci ne sont plus valides car les chemins des nouveaux répertoires sont différents des anciens.

La migration des HOME est terminée depuis la maintenance du 30 juillet 2024. Nous vous invitons à vérifier vos scripts pour corriger les éventuels chemins codés en dur. Tout chemin de la forme /gpfs7kw/linkhome/… doit devenir /linkhome/… ou, si possible, être remplacé par l'usage de la variable d'environnement $HOME. Si vous utilisez des liens symboliques comme ceux que nous recommandons de faire pour les environnements Python personnels, veuillez les refaire pour prendre en compte les nouveaux chemins d'accès aux nouveaux repertoires.

La migration des espaces WORK est terminé depuis le 13 août 2024. Les QoS “qos_cpu-t4” et “qos_gpu-t4” permettant l'exécution des travaux de plus de 20h sont à nouveau fonctionnelles.

Remarque : Le chemin absolu des espaces WORK a changé à l'occasion de la migration (voir la nouvelle valeur de la variable $WORK) mais pour simplifier la transition, des liens ont été mis en place de sorte à ce que les anciens chemins absolus restent fonctionnels au moins dans un premier temps. Maintenant que la migration effectuée, nous vous invitons à modifier les éventuels chemins de la forme /gpfswork/… ou /gpfsdswork/projects/… qui pourraient apparaître dans vos scripts (si possible en les remplaçant par l'usage de la variable d'environnement $WORK) ou dans vos liens symboliques pour ne plus utiliser les anciens repertoires.

Concernant le STORE, la migration a été finalisée le 25 juillet 2024, la variable $STORE habituelle référence désormais le nouveau système de fichier Lustre. Une variable $OLDSTORE a été créée pour référencer l'espace sur l'ancien système de fichier Spectrum Scale.

# référence le STORE sur le filesystem Lustre
$ echo $STORE
/lustre/fsstor/projects/rech/...
 
# référence l'ancien STORE en lecture seule sur le filesystem Spectrum Scale
$ echo $OLDSTORE
/gpfsstore/rech/...

ATTENTION : l'accès en lecture seule à l'ancien espace STORE via la variable d'environnement $OLDSTORE sera supprimé fin novembre 2024. La variable $OLDSTORE ne sera alors plus définie. Notez que, l'accès au $STORE en lecture et écriture n'est pas possible depuis les nœuds de calcul mais uniquement depuis les nœuds de connexion et les nœuds des partitions “prepost”, “visu”, “compil” et “archive”. Nous vous invitons à modifier vos jobs si vous accédez directement à l'espace OLDSTORE depuis les nœuds de calcul. Pour vous guider, des exemples d'enchaînements de jobs ont été ajoutés à la fin de notre documentation sur les travaux multi-étapes.

Depuis le mardi 3 septembre 2024, la variable d'environnement SCRATCH (et ses variantes comme ALL_CCFRSCRATCH) pointe vers le nouvel espace SCRATCH Lustre. L'ancien espace SCRATCH Spectrum Scale n'est plus accessible.

La variable d'environnement NEWSCRATCH (et ses variantes comme ALL_CCFRNEWSCRATCH) disparaîtra à terme et nous vous encourageons donc à la remplacer par SCRATCH dès maintenant.

# référence le nouveau SCRATCH sur le filesystem Lustre
$ echo $SCRATCH
/lustre/fsn1/projects/rech/...

Attention, si vous avez dans votre répertoire HOME des répertoires tel que $HOME/.local, $HOME/.conda pointant via des liens symboliques vers l'ancien WORK de la forme /gpfswork/…, il faut changer ces liens vers le nouveau WORK de la forme /lustre/fswork/….

$ cd $HOME
# Ici .local est un lien sur l'ancien WORK
$ ls -al .local
 ...  .local -> /gpfswork/... 
# Supprime le lien
$ unlink .local 
# Recree le lien avec la variable $WORK qui reference le nouveau WORK 
$ ln -s $WORK/.local $HOME 
# Lien sur le nouveau WORK
$ ls -al .local
 ...  .local -> /lustre/fswork/...