Gestion des données sur la baie de disques¶
Les chemins, les quotas, les conseils et commandes pour gérer au mieux ses données de calcul sur Austral
Introduction¶
Les données du calculateur Austral sont stockées sur une baie de disques accessible sur l'ensemble du cluster grâce à un système de fichiers Lustre. La baie est composée d'un pool flash
de 1Po de stockage en technologie de flash et d'un pool disk
de 1Po de stockage en technologie disques rotatifs mécaniques. Les performances mesurées lors de la livraison sont de 283 Go/s en lecture et 163 Go/s en écriture pour l'espace par défaut (pool flash).
A la saturation de l'espace flash
, les données sont automatiquement migrées sur l'espace disk
moins performant.
Ces deux espaces forment un système de fichiers unique présenté sur les nœuds du calculateur Austral, de manière transparente pour les utilisateurs.
Rôles des arborescences :
/home
contient les dossiers d'accueil des utilisateurs./dlocal
contient les dossiers temporaires des calculs (/dlocal/run
) et certains dossiers de calcul permanents (/dlocal/home
) quand le besoin est qualifié./soft
contient les logiciels mis à disposition par le CRIANN
Attention : aucune sauvegarde n'est effectuée sur les données utilisateurs. Pensez à rapatrier vos codes et vos données dans vos laboratoires.
Les quotas¶
Afin d'éviter une saturation de la baie de disque en volumétrie et en nombre d'inodes, il a été mis en place des quotas à deux niveaux :
- par identifiant sur la totalité de la baie de disques
- volumétrie : quota strict de 30To
- nombre d'inodes (lié au nombre de fichiers) : quota strict de 5M
- par arborescence indépendamment du propriétaire des fichiers
/home/projet_id/identifiant
: quota pour l'instant informatif mais qui sera prochainement limité, sur le dossier d'accueil de l'utilisateur/home/projet_id/PARTAGE
: quota informatif sur le dossier PARTAGE associé au projet- (optionnel)
/dlocal/home/projet_id
: quota informatif sans limitation. Cas particulier pour certains projets
Ces quotas peuvent être adaptés sur demande justifiée après du support (support@criann.fr).
Ménage dans /dlocal/run¶
Le CRIANN a fait le choix de décaler la suppression automatique des dossiers temporaires (/dlocal/run/<jobid>
). Cela permet d'enchaîner plusieurs calculs dans ce dossier.
Actuellement, un script automatique supprime ces dossiers temporaires non modifiés depuis 60 jours. Seuls les dossiers présents dans /dlocal/run/<jobid>
sont supprimés : le script ne touche pas aux arborescences /home
ou /dlocal/home/<jobid>
.
Un développement est en cours pour reproduire le script que vous connaissiez sur Myria : effacement des dossiers temporaires de /dlocal/run 40 jours après la fin du calcul.
Nous vous recommandons de ne pas laisser de fichiers à conserver dans ces arborescences sous peine de les voir disparaître.
Si vous générez un grand nombre de fichiers lors de vos calculs, surveillez votre consommation d'inodes :
- supprimer vos données de
/dlocal/run/<jobid>
au fur et à mesure. - archivez certaines arborescences avec la commande
tar
: une archive = 1 fichier
L'archivage permet aussi de simplifier et optimiser les transferts réseaux, notamment pour le rapatriement de vos données sur vos espaces de stockage dans vos laboratoires.
Cas particulier : OpenFoam¶
En fonction du paramétrage, les solveurs parallèles d'OpenFOAM peuvent fortement solliciter le système de fichiers parallèles d'Austral, en écrivant un tout petit fichier pour chaque tâche MPI à chaque pas de temps, ou fréquemment, et pour chaque variable. Le nombre de fichiers ainsi généré peut être très élevé.
Les post-traitements peuvent alors solliciter fortement le système de fichiers parallèle en relisant tous ces petits fichiers.
Pour rappel : le système de fichiers Lustre est optimisé pour les gros fichiers.
Bonne pratique : utilisation d'objets fonctionnels pour créer des images de post-traitement de sous-ensembles de données :
https://doc.openfoam.com/2306/tools/post-processing/function-objects/
En outre, le format de fichier agrégé (collated
) a été introduit dans OpenFOAM, dans lequel les données de chaque champ (et maille) décomposé sont agrégées dans un fichier unique qui est écrit (et lu) sur le processeur principal. Les fichiers sont stockés dans un répertoire unique appelé pocessors.
L’option -fileHandler collated
est disponible pour les lignes de commande de decomposePar
et des solveurs parallèles.
Voir par exemple « File input/output in parallel » sur :
https://doc.cfd.direct/openfoam/user-guide-v11/running-applications-parallel
et la page :
https://www.openfoam.com/news/main-news/openfoam-v1712/parallel
Volumétrie utilisée¶
Les commandes Lustre
étant complexes, le Criann a mis un place un script permettant un affichage simplifié et synthétique : cri_quota
Syntaxe : cri_quota
-h
: aide en ligne indiquant des options avancées
$ cri_quota
Quota information for user user_name (member of primary group project_id) : 2024-06-04 11:58:46
p.s: user and group types: across the whole storage
+------+----------------------------+---------+--------+----------+----------+-----------+-----------+-----------+------------+------------+-------------+
| type | name | blk_pct | used | blk_soft | blk_hard | blk_grace | inode_pct | files | inode_soft | inode_hard | inode_grace |
+------+----------------------------+---------+--------+----------+----------+-----------+-----------+-----------+------------+------------+-------------+
| user | user_name | 0.298% | 91.46G | 30T | 30T | - | 1.3% | 195 414 | 5 000 000 | 5 100 000 | - |
| path | /home/project_id/PARTAGE | - | 15.12T | - | - | - | - | 2 946 756 | - | - | - |
| path | /home/project_id/user_name | - | 27.35G | - | - | - | - | 147 056 | - | - | - |
+------+----------------------------+---------+--------+----------+----------+-----------+-----------+-----------+------------+------------+-------------+
Il reste possible d'interroger Lustre directement avec la commande lfs quota
. Pour plus d'informations sur cette commande consulter le manuel : man lfs-quota
Localisation des fichiers (pool)¶
L'espace par défaut est le pool flash
. En cas de remplissage important de la baie de disques, les fichiers les plus volumineux seront déplacés vers le pool disk
.
La commande lfs getstripe
permet de connaître le pool utilisé par un fichier.
Si vous constatez qu'un de vos fichiers a été migré sur le pool disk
, pour le repositionner dans le pool flash, il suffit de le recopier dans le même dossier, de supprimer l'ancien et de renommer le nouveau au nom d'origine.
Le stripping¶
La baie de stockage est composée de plusieurs serveurs de données. Le stripping correspond à la répartition de données des fichiers sur ces différents serveurs. Il permet également de définir une taille de blocs lors
Ce paragraphe et les commandes liée au striping seront plus détaillés dans les prochains mois. En cas de problème de performance, contactez le support (support@criann.fr).
Astuces et commandes utiles¶
Liste des dossiers temporaires pour un utilisateur¶
Liste des calculs dans une partition¶
Liste des calculs soumis dans la partition hpda entre le 1/10/2023 et le 15/10/2023
Vous pouvez rajouter l'option -l
pour afficher plus d'informations.
Nombre de fichiers dans une arborescence¶
Pour connaître le nombre de fichiers dans une arborescence :
Recommandations¶
Dans les scripts de soumission...
Le rapatriement des données s'effectue avec une commande mv
. Ne la remplacez surtout pas par un cp
, qui duplique les données et qui peut être très longue à s'exécuter.
Intérêt des gros fichiers
Si vous développez, privilégiez les fichiers volumineux avec des formats de type HDF5 plutôt qu'une multitude de petits fichiers. Vous gagnerez en performances sur les clusters de calcul.
Surveillance des quotas
Si vous générez un très grand nombre de fichiers, surveillez votre quota : vous pouvez l'afficher automatiquement lors de la connexion, via un ajout approprié dans votre fichier ~/.bash_profile
.
Versionning
Nous vous encourageons fortement à utiliser les outils de versioning de vos établissements, tel que GIT. Renseignez-vous auprès de vos DSI.
Le client git
est installé sur les frontales, sans chargement de module.