Opérations en cours liées à 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. Ils remplaceront à terme les anciens espaces disques qui utilisent un système de fichier Spectrum Scale d'IBM.

La mise en ordre de marche nécessite que les données actuellement enregistrées sur l'ancien système de fichier (Spectrum Scale) soient copiées/déplacées sur le nouveau (Lustre). Vous retrouverez à terme les espaces disques habituels (HOME, WORK, ALL_CCFRWORK, SCRATCH, ALL_CCFRSCRATCH, STORE, ALL_CCFRSTORE) sur le nouveau système de fichier.

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

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/...

Jusqu'à fin août, il restera possible d'accéder en lecture seule à l'ancien espace STORE en utilisant la variable d'environnement $OLDSTORE. Cette modalité d'accès sera même à privilégier dans les semaines qui suivront l'opération de migration. En effet, les données du nouveau STORE seront alors uniquement disponibles sur bandes magnétiques ce qui pourra très fortement ralentir l'accès aux données (jusqu'à plusieurs heures), le temps de repeupler le cache sur disques rotatifs avec les données les plus récemment utilisées.

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 reste accessible en lecture seule jusqu'au 10 septembre via la variable d'environnement OLDSCRATCH (et ses variantes) afin de permettre la recopie des éventuelles données non migrées.

La variable d'environnement NEWSCRATCH 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/...
 
# référence l'ancien SCRATCH sur le filesystem Spectrum Scale
$ echo $OLDSCRATCH
/gpfsscratch/rech/...
 
# Copie d'un répertoire de l'ancien SCRATCH vers le nouveau.
$ cp -rp $OLDSCRATCH/DIR $SCRATCH/.
 
# Copie via rsync
$ rsync --human-readable --recursive --links --perms --times -v $OLDSCRATCH/DIR $SCRATCH/.

Pensez à utiliser des travaux soumis sur les partitions archive ou prepost si les quantités de données à transférer sont importantes :

copie_donnees.slurm

#SBATCH --job-name=copie      # nom du travail
#SBATCH --partition=archive   # on utilise la partition "archive" ou "prepost" qui a accès au STORE
#SBATCH --ntasks=1            # on a un travail séquentiel
#SBATCH --hint=nomultithread  # 1 processus MPI par coeur physique (pas d'hyperthreading)
#SBATCH --time=20:00:00       # temps d execution maximum demande (HH:MM:SS)
#SBATCH --output=%x_%j.out    # fichier de sortie et d'erreur (%x = nom du travail, %j = numéro du travail)
# Si vous disposez de plusieurs projets ou de plusieurs types d'heures,
# vous devez spécifier la comptabilité à utiliser même si les heures ne
# seront pas décomptées pour les partitions "archive" et "prepost".
##SBATCH --account=...
 
# Copie vers l'ancien SCRATCH selon la méthode de votre choix
cp -rp $OLDSCRATCH/DIR $SCRATCH/.
# Ou via rsync
$ rsync --human-readable --recursive --links --perms --times -v $OLDSCRATCH/DIR $SCRATCH/.

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/...