R4 · Stockage parallèle¶

Le goulot d'étranglement structurel du calcul intensif, et le sujet dont personne ne parle.


Volume	⏱ 40 h
Quand	Après R3, sur le même cluster
Prérequis	R3, les E-S POSIX (SYEX11), MPI-IO — vu dans le module PMPI23 de PRPA23
Ce que la maquette FISA donne déjà	Rien sur l'architecture du stockage. PMPI23 enseigne MPI-IO, c'est-à-dire l'API — pas ce qu'il y a dessous
Livrable	Un système de fichiers parallèle monté, mesuré, et réglé

D'où vient ce module

Son programme est celui de SYFP24 · Systèmes de fichiers parallèles (15 cours et 8 travaux pratiques), enseigné dans la formation sous statut étudiant. Aucune UE de la maquette FISA ne le couvre.

Ne dupliquez pas le chapitre du socle

Entrées-sorties et stockage traite les formats (HDF5, NetCDF, ADIOS), les E-S collectives, le benchmark IO500 et les points de reprise. Ce module-ci traite ce qui est en dessous : l'architecture des systèmes de fichiers parallèles et leur réglage. Les deux se lisent ensemble, dans cet ordre : R4 d'abord, le chapitre du socle ensuite.

Le programme à couvrir¶

Objectifs cités :

« Cette UE présente les différentes architectures des systèmes de fichiers parallèles et de leurs différences par rapports aux systèmes de fichiers distribués. Il présente aussi les technologies qui vont permettre de bâtir les systèmes du futur. Les étudiants seront en fin d'UE capables de choisir et configurer un SFP répondant aux besoins d'un cluster HPC. Le cours utilisera différents systèmes de fichiers (Lustre, GPFS, pNFS et HadoopFS) afin de mettre en avant les concepts généraux de la gestion de données au sein des grands centres de calculs et de traitement de données. »

Contenu cité : « Le module comporte 15 cours et 8 travaux pratiques », sur les sujets suivants :

la gestion de données au sein des centres de calcul ;
les systèmes distribués ;
les concepts d'un système de fichiers parallèle (SFP) et les SFP de type client/serveur (Lustre) ;
la sécurité au sein du SFP ;
la vie de la donnée au sein d'un SFP ;
les SFP de type SAN (GPFS) ;
les SFP de type standard (pNFS) ;
la tolérance aux pannes au sein d'un SFP ;
Hadoop ;
le futur des SFP.

Compétences : dix à « 2 – Maîtrise », dont conseiller des équipes de développement, de production et des utilisateurs, gérer les droits d'accès, analyser les besoins d'un client ou d'un projet.

Ce que ça vaut pour le HPC¶

Élevé, et systématiquement sous-estimé par les étudiants.

Voici pourquoi. Prenez un code de simulation qui tourne huit heures sur mille nœuds et sauvegarde son état toutes les quinze minutes. Chaque sauvegarde écrit quelques téraoctets. Si les entrées-sorties sont mal faites — chaque processus écrit son propre fichier, ou tous écrivent au même endroit —, le temps passé en écriture peut dépasser le temps de calcul. Ce n'est pas un cas d'école : c'est le motif de panne le plus fréquent des codes qui montent en échelle.

Trois raisons de prendre ce module au sérieux.

1. Le stockage est le goulot d'étranglement structurel du HPC. La puissance de calcul a augmenté beaucoup plus vite que la bande passante de stockage. Le rapport calcul/E-S des machines s'est dégradé d'un ordre de grandeur en vingt ans. Conséquence : la gestion des données est devenue le sujet central, et c'est ce que dit l'intitulé « défis pour le passage à l'exaflops » de R3 · Cluster et Slurm.

2. Le benchmark IO500 est entré dans le paysage des compétitions. Il mesure à la fois la bande passante (grandes écritures) et le débit de métadonnées (création de nombreux petits fichiers), sur un seul chiffre composite. Une équipe qui ne comprend pas la distinction entre ces deux régimes ne peut pas l'optimiser.

3. Le comportement d'un SFP est contre-intuitif. Sur Lustre, écrire dix mille petits fichiers dans un même répertoire peut être plus lent que d'écrire un seul fichier de même volume total, d'un facteur cent, parce que le serveur de métadonnées devient le goulot. Régler le striping — le nombre de serveurs d'objets sur lesquels un fichier est réparti, et la taille des bandes — change la bande passante d'un facteur dix. Ce sont des réglages d'une ligne de commande que personne ne connaît sans avoir travaillé le sujet.

Les deux régimes d'entrées-sorties, à retenir

Régime bande passante : peu de fichiers, très gros, écrits en gros blocs contigus. La limite est la bande passante agrégée des serveurs de données. Levier : augmenter le striping, aligner les écritures sur la taille de bande, utiliser les E-S collectives.

Régime métadonnées : beaucoup de fichiers, petits, créés, statés, ouverts, fermés. La limite est le serveur de métadonnées, qui est souvent unique. Levier : réduire le nombre de fichiers, répartir dans des sous-répertoires, éviter les ls sur un répertoire à cent mille entrées, et surtout ne pas faire un fichier par processus.

La plupart des désastres d'E-S en HPC viennent d'un code écrit pour le premier régime qui se retrouve dans le second sans que personne ne l'ait vu.

Arriver prêt¶

⏱ 8 h :

Comprendre les E-S POSIX du point de vue du coût : open, read, write, fsync, et la différence entre les flux libc tamponnés et les appels système directs. C'est du SYEX11 de première année. Mesurer le coût d'un write de 1 octet, de 4 Ko, de 1 Mo, avec et sans O_DIRECT. ⏱ 4 h.
Installer NFS entre deux machines virtuelles et mesurer la bande passante en lecture et en écriture. C'est le point de comparaison de tout le module. ⏱ 2 h.
Lire la première page de la documentation Lustre pour connaître le vocabulaire : MDS, MDT, OSS, OST, client, striping. Sans ces six sigles, les premières lectures seront opaques. ⏱ 2 h.

Le vocabulaire Lustre, à connaître avant de commencer

Sigle	Signification	Rôle
MDS	Metadata Server	Le serveur qui gère l'arborescence, les noms, les permissions
MDT	Metadata Target	Le disque où le MDS stocke ces métadonnées
OSS	Object Storage Server	Un serveur qui détient des données de fichiers
OST	Object Storage Target	Un disque géré par un OSS
Client		Le nœud de calcul qui monte le système de fichiers
*Striping*	Découpage	Un fichier est découpé en bandes réparties sur plusieurs OST

Un fichier sur Lustre est donc : une entrée de métadonnées sur le MDT, et des morceaux sur N OST. Le nombre N est le stripe count et se règle par fichier ou par répertoire avec lfs setstripe. C'est le réglage le plus rentable du système.

Ressources¶

Priorité 1¶

La documentation Lustre (doc.lustre.org, Lustre Operations Manual). Complète, et les chapitres sur l'architecture et sur le réglage des performances sont exactement au programme.
Les guides d'E-S des grands centres, qui sont les meilleurs documents pédagogiques du domaine parce qu'ils sont écrits pour des utilisateurs qui viennent de faire une bêtise :
- NERSC, Optimizing I/O performance on Lustre (docs.nersc.gov) ;
- OLCF, sur le système de fichiers de Frontier ;
- IDRIS, la documentation sur les espaces disque de Jean Zay, en français.
La documentation d'IBM Storage Scale (l'ancien GPFS), pour la comparaison avec l'architecture SAN.

Priorité 2¶

IO500 (io500.org) : le règlement du benchmark, et surtout les listes historiques. Les soumissions comportent les configurations, ce qui en fait une source d'apprentissage sur les architectures réelles.
IOR et mdtest (github.com/hpc/ior) : les deux outils de mesure de référence, respectivement pour la bande passante et pour les métadonnées. Savoir les utiliser est indispensable.
Darshan (wordpress.cels.anl.gov/darshan/) : instrumentation légère des E-S d'une application, sans recompilation. C'est l'outil qui permet de répondre à « où et comment mon code écrit-il ? » sans lire le code.
HDF5 et NetCDF : les bibliothèques de données scientifiques, avec leur mode parallèle qui s'appuie sur MPI-IO. La documentation du HDF Group sur le Parallel HDF5 est le bon point d'entrée.
ADIOS2 (Oak Ridge) : une alternative moderne, conçue pour l'échelle exascale et le streaming de données entre codes couplés. Le futur dont parle la dernière partie du programme.

Priorité 3 — pour aller plus loin¶

Sur les systèmes distribués sous-jacents : l'article de Ghemawat, Gobioff, Leung, « The Google File System » (SOSP 2003), qui est le texte fondateur derrière HDFS, et le théorème CAP (Brewer, puis Gilbert et Lynch). C'est le pont conceptuel entre la partie SFP et la partie Hadoop du cours.
Sur les technologies émergentes : la mémoire non volatile, les burst buffers (une couche de stockage rapide intercalée entre les nœuds et le stockage principal), DAOS (Intel, un système de stockage objet conçu pour la NVMe), et l'object storage de type S3 en HPC. Chercher « burst buffer HPC » et « DAOS storage » pour les articles de référence.
Sur les formats : l'article « Zarr » ou « Parallel I/O in Practice », et les supports du tutoriel Parallel I/O in Practice donné régulièrement à la conférence SC par Argonne et le NCSA. Les diapositives sont publiques et excellentes.

Outils à maîtriser¶

Outil	Usage
`lfs df`, `lfs getstripe`, `lfs setstripe`	Inspecter et régler le striping Lustre
`lfs quota`, `lfs find`	Quotas et recherche efficace (bien plus rapide que `find`)
IOR	Mesure de bande passante, en POSIX, MPI-IO, HDF5
mdtest	Mesure de débit de métadonnées
Darshan, `darshan-parser`, `darshan-job-summary`	Profil d'E-S d'une application
`iostat`, `iotop`, `dstat`	Surveillance locale
`strace -e trace=file`	Voir tous les appels de fichier d'un programme
`dd`, `fio`	Mesures brutes de débit
`h5dump`, `h5ls`, `ncdump`	Inspecter des fichiers HDF5 et NetCDF

Les trois commandes Lustre qui font gagner un facteur dix

# Voir comment un fichier est réparti
lfs getstripe mon_gros_fichier.h5

# Un gros fichier écrit par tous les rangs : le répartir largement
lfs setstripe -c 16 -S 4M repertoire_de_sortie/

# Beaucoup de petits fichiers : au contraire, une seule bande
lfs setstripe -c 1 repertoire_de_petits_fichiers/

La logique : répartir sur beaucoup d'OST augmente la bande passante agrégée mais coûte des métadonnées et des verrous ; c'est bon pour un gros fichier partagé, mauvais pour des milliers de petits.

Exercices¶

E1 · ★ ⏱ 2 h — Le coût de la taille de bloc. Écrire 1 Go dans un fichier par appels write successifs de taille variable : 1 octet, 4 Ko, 64 Ko, 1 Mo, 16 Mo. Mesurer le débit dans chaque cas, avec et sans fsync final. Tracer. Le passage de 1 octet à 1 Mo doit produire plusieurs ordres de grandeur.

E2 · ★★ ⏱ 3 h — Métadonnées contre bande passante. Écrire 10 Go de données de deux manières : un seul fichier de 10 Go, puis cent mille fichiers de 100 Ko. Mesurer les deux, puis mesurer aussi un ls -l et un du -sh sur le répertoire résultant. Sur un système de fichiers parallèle, l'écart sera spectaculaire. Puis supprimer les cent mille fichiers et chronométrer la suppression.

E3 · ★★ ⏱ 3 h — IOR et mdtest. Installer et utiliser IOR pour mesurer la bande passante en lecture et écriture, en mode « fichier par processus » (-F) puis en mode « fichier partagé », pour 1, 4 et 16 processus. Puis mdtest pour mesurer les créations, statistiques et suppressions de fichiers par seconde. Comparer les résultats aux valeurs annoncées par l'administrateur du système, si vous y avez accès.

E4 · ★★★ ⏱ 4 h — L'effet du striping. Sur un Lustre réel, écrire le même fichier de 20 Go avec -c 1, -c 4, -c 16 et -c -1 (toutes les OST), et avec des tailles de bande de 1 Mo et 16 Mo. Huit configurations, huit mesures. Identifier l'optimum et expliquer la forme de la courbe. Si vous n'avez pas accès à un Lustre, cet exercice est le meilleur usage possible des travaux pratiques : c'est l'exercice à faire en priorité le jour où vous obtenez un accès.

E5 · ★★★ ⏱ 4 h — Le profil d'E-S d'un code inconnu. Prendre un code de simulation que vous n'avez pas écrit, l'exécuter sous Darshan, et produire le rapport. Répondre par écrit à : combien de fichiers ouverts, quelle taille de requête médiane, quelle proportion d'accès séquentiels, quel temps passé en E-S par rapport au temps total, y a-t-il un rang qui écrit pour tous les autres ? Puis proposer deux améliorations chiffrées.

E6 · ★★★★ ⏱ 6 h — HDF5 parallèle. Reprendre le stencil 2D MPI de PRPA23 et écrire sa sortie en Parallel HDF5 : un fichier unique, chaque rang écrivant sa sous-grille dans le bon hyperslab, avec métadonnées. Comparer, pour 16 rangs et une grille de \(8192^2\), avec les trois autres stratégies (fichier par rang, rassemblement sur le rang 0, MPI-IO brut). Mesurer aussi le temps de relecture par un nombre différent de processus — c'est le test qui distingue un format utilisable d'un format jetable.

Projet¶

Projet R4 · Le diagnostic et la réparation d'un code d'E-S

⏱ 30 h · ★★★★

Sujet. Prendre un code de simulation réel et open source qui écrit beaucoup de données, diagnostiquer son comportement d'E-S, et l'améliorer.

Candidats intéressants, tous libres : un code de dynamique moléculaire (LAMMPS, GROMACS), un code de mécanique des fluides (OpenFOAM, qui est notoirement mauvais en E-S parce qu'il écrit un répertoire par pas de temps et par processus), ou un code d'éléments finis (Code_Saturne, français, développé par EDF).

Les six étapes :

Faire tourner le code à une échelle modeste et mesurer la répartition du temps entre calcul, communication et E-S.
Profiler les E-S avec Darshan : nombre de fichiers, tailles de requête, motifs d'accès, déséquilibre entre rangs.
Identifier le régime : bande passante ou métadonnées ? La réponse détermine tout le reste.
Formuler une hypothèse chiffrée : « si je passe de N fichiers à 1 fichier partagé avec un striping de 8, je devrais gagner un facteur X ». Justifier le X par un modèle, avant de mesurer.
Implémenter et mesurer. L'écart entre la prédiction et la mesure est la partie la plus instructive du projet.
Rédiger un rapport de huit pages, dans le style d'un rapport d'expertise : contexte, mesures, diagnostic, action, résultat, limites.

Pourquoi ce projet. C'est le métier. Un ingénieur HPC en centre de calcul passe une partie de son temps à faire exactement cela pour des utilisateurs qui se plaignent que « la machine est lente ». Et si le code est libre, votre correctif peut être proposé en amont — ce qui est le meilleur objet possible dans un CV.

Erreurs fréquentes¶

Six fautes d'entrées-sorties

Un fichier par processus. Fonctionne à 16 rangs, devient un désastre à 10 000. C'est l'antipatron numéro un, et il est partout.
Tout rassembler sur le rang 0. L'autre extrême : correct en nombre de fichiers, mais le rang 0 devient un goulot et la mémoire ne suffit pas à grande échelle.
Écrire en ASCII. Trois à cinq fois plus volumineux, dix à cinquante fois plus lent, et perte de précision. Voir R2 · Programmation scientifique.
Des requêtes trop petites. Un write de 100 octets par ligne de résultat plutôt qu'un tampon de 1 Mo écrit d'un coup. Facteur mille.
Ignorer le striping. Laisser la valeur par défaut, souvent -c 1, sur un fichier de 100 Go écrit par 1 000 rangs : la bande passante est limitée à un seul serveur d'objets.
Mesurer une E-S sans vider le cache. La seconde lecture d'un fichier est servie par le cache de page et paraît infiniment rapide. Pour une mesure honnête : sync && echo 3 > /proc/sys/vm/drop_caches, ou utiliser un fichier beaucoup plus gros que la mémoire, ou O_DIRECT.

Où ce module s'insère¶

Se relie à	Comment
R3 · Cluster et Slurm	Le support : il faut un cluster pour monter un système de fichiers parallèle
PRPA23, module PMPI23	MPI-IO est l'API ; ce module explique pourquoi elle gagne
Entrées-sorties et stockage	La couche au-dessus : formats, IO500, points de reprise
R2 · Programmation scientifique	Les données que la chaîne produit, et leur coût
BADO23 (S3 FISA, tronc commun)	Le seul recouvrement FISA : HadoopFS et la philosophie big data, à contraster avec Lustre

À retenir¶

R4 en trois phrases

La puissance de calcul a augmenté beaucoup plus vite que la bande passante de stockage : les entrées-sorties sont devenues le goulot structurel, et la maquette FISA n'en dit rien. Les deux notions qui rapportent immédiatement sont la distinction régime bande passante / régime métadonnées et le réglage du striping — deux réglages d'une ligne de commande qui font des facteurs dix. Le geste à acquérir : ne jamais écrire un fichier par processus.

Retour : le programme de reconstitution.