Systèmes de fichiers HPC : quand choisir le stockage parallèle

Un système de fichiers HPC permet aux tâches de calcul d'accéder à leurs fichiers. Un système de fichiers parallèle apporte une capacité précise : plusieurs clients peuvent lire et écrire simultanément via plusieurs serveurs de stockage. Cette capacité devient utile lorsqu'une simulation, un pipeline d'analyse ou un entraînement de modèle doit accéder à des données partagées plus vite qu'une architecture plus simple ne le permet.

Le calcul haute performance ne nécessite pas systématiquement un stockage parallèle. Une tâche exécutée sur une seule machine peut fonctionner correctement avec du NVMe local. Un cluster dont les besoins d'entrées-sorties partagées restent modérés peut utiliser NFS. Le choix dépend des accès aux données, des besoins de partage et des conséquences d'une panne.

Ce guide explique l'architecture, compare les principales options de stockage et propose une méthode pour évaluer Lustre, IBM Storage Scale, BeeGFS ou un service géré.

Le rôle d'un système de fichiers HPC

Le calcul haute performance répartit le travail entre des processeurs et, souvent, plusieurs nœuds de calcul. Ces nœuds doivent charger les données d'entrée, enregistrer les résultats et écrire des points de contrôle pour reprendre une tâche après une interruption. Le système de fichiers permet aux applications d'organiser ces fichiers et d'y accéder. Notre introduction au calcul haute performance présente le fonctionnement général du HPC.

Dans un système de fichiers partagé, les machines participantes accèdent à une arborescence commune, parfois appelée espace de noms partagé ou global. Chaque nœud n'a donc pas besoin d'une copie indépendante de tous les fichiers, même si les applications peuvent préparer des copies locales pour améliorer les performances. Le partage crée aussi de la contention : de nombreux processus peuvent solliciter les mêmes répertoires, périphériques de stockage et liaisons réseau.

Un système de fichiers parallèle répartit les entrées-sorties entre plusieurs ressources de stockage pour servir les accès simultanés. Il peut augmenter le débit cumulé, sans garantir une accélération de chaque tâche. Une application qui ouvre sans cesse de petits fichiers peut être limitée par les opérations sur les métadonnées ; une autre peut attendre un client lent ou un réseau saturé.

Examiner précisément la compatibilité POSIX

De nombreuses applications HPC utilisent des opérations classiques : ouvrir, lire, écrire et renommer des fichiers. POSIX définit des interfaces et des comportements sur lesquels ces applications peuvent s'appuyer. Une interface familière ne garantit pas tous les comportements attendus en matière de cohérence, de verrouillage ou d'accès simultané.

Le guide de Google sur les systèmes de fichiers parallèles pour le HPC distingue les interfaces POSIX de leur sémantique. Cette distinction compte lorsque plusieurs processus modifient des données partagées. Vérifiez les exigences de l'application et le comportement documenté du système, puis testez les accès réels. Réussir à monter le système de fichiers ne constitue qu'un premier contrôle de compatibilité.

La place du système de fichiers parallèle dans l'architecture HPC

Un modèle de départ utile distingue trois rôles : les clients, les services de métadonnées et les services de stockage des données. Leur mise en œuvre varie selon le produit. Un rôle ne correspond pas toujours à un serveur physique dédié.

Les clients relient les applications au stockage partagé

Un client s'exécute sur une machine qui accède au système de fichiers, généralement un nœud de calcul ou de transfert de données. Il présente le système monté aux applications et coordonne les requêtes avec les services de stockage. Le logiciel client, la compatibilité du noyau, les options de montage et la configuration réseau peuvent tous influencer le fonctionnement du déploiement.

Les services de métadonnées gèrent les informations sur les fichiers

Les métadonnées comprennent notamment les noms, les répertoires, les propriétaires, les permissions et l'emplacement du contenu des fichiers. Créer un fichier ou parcourir un répertoire peut solliciter ces services, même si l'application transfère peu d'octets.

Des millions de petits fichiers posent donc un problème différent de quelques gros fichiers occupant le même volume total. Un système doté d'une bande passante séquentielle élevée peut rencontrer des difficultés lorsque de nombreuses tâches créent, inspectent et suppriment des fichiers simultanément.

Les services de stockage gèrent le contenu des fichiers

Le contenu réside sur des ressources auxquelles les clients accèdent par le réseau. Avec une répartition en bandes, ou striping, différentes portions d'un fichier sont placées sur plusieurs cibles de stockage, éventuellement réparties entre plusieurs nœuds. Les clients peuvent ainsi transférer des portions en parallèle, selon l'application, le réseau et la configuration du stockage.

Dans l'architecture de Lustre, les serveurs et cibles de métadonnées gèrent les métadonnées, tandis que les serveurs et cibles de stockage objet servent le contenu des fichiers. Ici, « cible de stockage objet » désigne un composant de Lustre. Cela ne signifie pas que les applications utilisent une API de stockage objet S3. BeeGFS sépare également les services de métadonnées et de stockage, selon son propre modèle de déploiement.

Le striping se règle en fonction de la charge

Répartir un gros fichier partagé sur davantage de cibles peut lui permettre d'utiliser plus de ressources. Cela peut aussi augmenter le travail de coordination et solliciter davantage de cibles pour de petites opérations. Appliquer la répartition la plus large possible à tous les fichiers n'est pas un bon réglage par défaut.

Les recommandations Lustre du NERSC expliquent ce compromis. Commencez par les paramètres recommandés par l'exploitant, puis testez les modifications avec des fichiers et un nombre de processus représentatifs. Retenez la configuration dont les résultats mesurés sont meilleurs.

NVMe local, NFS, systèmes parallèles et stockage objet

Ces options répondent à des modes d'accès différents. Un même traitement peut en utiliser plusieurs et déplacer les données entre elles à des étapes définies. Notre guide des systèmes de fichiers cloud présente les choix d'architecture généraux ; la comparaison ci-dessous porte sur leur rôle dans une tâche HPC.

Le NVMe local pour les tâches exécutées sur un seul nœud

Le stockage NVMe local peut convenir aux fichiers temporaires, aux caches et aux jeux de données utilisés par une seule machine. Pour les données déjà présentes sur ce nœud, il évite un transfert par le réseau de stockage partagé. En contrepartie, un autre nœud n'accède pas automatiquement aux mêmes fichiers. Copier les données sur chaque nœud demande du temps et de l'espace.

Cette option mérite d'être évaluée lorsque les tâches traitent indépendamment des partitions de données distinctes ou réutilisent souvent un jeu de données local. Vérifiez les règles de cycle de vie du fournisseur avant de conserver l'unique copie sur un disque local. « Local », « persistant » et « sauvegardé » désignent des propriétés différentes.

NFS pour des besoins de partage plus simples

Le protocole Network File System permet de partager des fichiers sur un réseau. Il peut convenir aux logiciels, aux configurations, aux répertoires personnels et aux traitements dont les entrées-sorties partagées restent dans les capacités du service.

NFS n'est pas automatiquement inadapté au HPC. Un seuil de nombre de clients ne suffit pas à trancher : l'architecture du serveur, le réseau, les caches, la charge et les limites du service comptent aussi. Testez les besoins de simultanéité et de cohérence avant de décider de conserver ou de remplacer un déploiement NFS.

Un système parallèle pour des entrées-sorties partagées exigeantes

Le stockage parallèle devient plus pertinent lorsque de nombreux clients doivent accéder simultanément à des fichiers partagés et que les mesures montrent un ralentissement lié aux entrées-sorties. C'est le cas, par exemple, de l'écriture coordonnée de points de contrôle, de résultats de simulation utilisés par plusieurs processus ou de l'analyse d'un grand jeu de données partagé.

Cette infrastructure ajoute du travail d'exploitation : disponibilité des services, planification de la capacité, compatibilité des clients, réglages, supervision et reprise après panne. Elle se justifie lorsque le partage qu'elle permet résout un problème constaté et que l'équipe peut en assurer l'exploitation.

Le stockage objet pour les jeux de données et les résultats à conserver

Le stockage objet utilise des API objet. Il ne fournit pas la même interface ni les mêmes comportements qu'un système de fichiers POSIX monté. Il peut contenir les données sources, les résultats définitifs et des copies de récupération, avec un niveau de protection qui dépend du service et de sa configuration.

Les applications peuvent accéder directement aux objets, ou transférer les données vers un système de fichiers avant le calcul. Monter un compartiment objet à l'aide d'une couche de compatibilité ne le rend pas équivalent à un système de fichiers parallèle. Si vous utilisez cette approche, testez les renommages, les écritures, les caches et la compatibilité de l'application.

Évaluer Lustre, IBM Storage Scale et BeeGFS

Ces solutions permettent des accès simultanés à des fichiers partagés. Aucune ne constitue le meilleur choix dans tous les cas. Les entrées-sorties de l'application, l'environnement de déploiement, le support attendu et les compétences d'exploitation doivent guider la sélection.

Lustre

Lustre est un système de fichiers parallèle open source utilisé dans les environnements HPC. Sa séparation entre les services de métadonnées et de contenu rend leur dimensionnement important. Une évaluation doit couvrir la charge des métadonnées, le striping, les clients compatibles, la gestion des pannes et le réseau entre les clients et le stockage.

Une offre gérée peut réduire l'infrastructure à administrer. Il reste nécessaire de vérifier les clients pris en charge, les possibilités de dimensionnement, les options de disponibilité et le fonctionnement des intégrations.

IBM Storage Scale

IBM Storage Scale, qui comprend la technologie General Parallel File System connue sous le nom GPFS, fournit un accès partagé aux fichiers au sein d'un cluster. Consultez la documentation actuelle d'IBM Storage Scale pour connaître les configurations et fonctionnalités prises en charge.

Évaluez les fonctions et les licences du déploiement proposé. Toutes les configurations n'offrent pas nécessairement les mêmes mécanismes de gestion des données ou de disponibilité. La maîtrise existante de l'exploitation peut compter autant qu'un avantage dans un test de performance.

BeeGFS

BeeGFS utilise des clients, des services de métadonnées et des services de stockage qui peuvent être répartis entre plusieurs machines. Son architecture permet aussi de faire fonctionner plusieurs services sur une même machine lorsque cela convient. Ce choix de déploiement implique de réfléchir à la répartition des ressources.

Vérifiez les exigences des clients, la distribution des métadonnées, l'organisation du stockage et les mécanismes de réplication ou de reprise configurés. La redondance peut protéger contre certaines pannes ; elle ne remplace pas un plan distinct de sauvegarde et de restauration.

Séparer les règles du stockage temporaire et des données durables

Le stockage scratch est un espace de travail pour le calcul. Il peut contenir des données préparées pour une tâche, des fichiers temporaires, des résultats intermédiaires ou des points de contrôle. L'exploitant peut appliquer des quotas et des règles de suppression, sans nécessairement sauvegarder ces données. Le NERSC décrit ainsi plusieurs systèmes de fichiers selon leur usage, dont un espace scratch temporaire et un stockage de projet à plus long terme.

Ne supposez pas une durée de conservation universelle. Lisez la politique du service : quelles données sont supprimées, comment l'inactivité est mesurée, quels événements suppriment le stockage et quelles récupérations sont possibles. Un point de contrôle n'est utile que s'il survit à la panne dont vous voulez vous remettre.

Un cycle de travail pratique consiste à conserver les données de référence dans un emplacement persistant adapté, à transférer les données nécessaires vers le scratch, à exécuter la tâche, puis à recopier les résultats à conserver. Vérifiez les données transférées avant de supprimer les copies temporaires. Ces transferts font partie du temps et du coût total : ils peuvent dépasser la durée d'un calcul court.

Durabilité, disponibilité et sauvegarde répondent à des exigences distinctes. Un stockage qui survit à la panne d'un disque peut tout de même subir une interruption. La réplication peut propager une suppression accidentelle. Prévoyez la récupération après une panne matérielle, une erreur de manipulation ou la perte de l'environnement de travail.

Mesurer les performances d'un système de fichiers HPC

Commencez par l'application et sa phase d'entrées-sorties la plus lente. Le débit maximal annoncé sur une page produit ne permet pas de prévoir le comportement d'une charge mixte dans votre configuration.

• Débit : volume d'octets transférés par seconde, mesuré séparément en lecture et en écriture avec le nombre de clients nécessaire.
• IOPS : nombre d'opérations d'entrées-sorties par seconde, à interpréter avec la taille des requêtes et le mode d'accès.
• Opérations de métadonnées : cadence des créations, recherches et suppressions de fichiers.
• Latence : durée des opérations, y compris les plus lentes, qui peuvent retarder des tâches synchronisées.
• Durée totale de la tâche : temps comprenant les transferts préparatoires, le calcul, les points de contrôle et la copie des résultats à conserver.

Consignez la taille et le nombre de fichiers, les accès séquentiels ou aléatoires, la proportion de lectures et d'écritures et la simultanéité. Distinguez plusieurs processus écrivant dans un même fichier de processus écrivant chacun dans leur propre fichier. Un test du premier cas ne valide pas le second.

Utiliser IOR et mdtest en complément de l'application

IOR et mdtest mesurent des aspects différents. IOR évalue les entrées-sorties parallèles avec plusieurs interfaces et modes d'accès. Mdtest mesure les performances des métadonnées selon différentes structures de répertoires. Aucun ne remplace l'exécution d'une application représentative.

Préparez un protocole limité comprenant une mesure de référence, une charge cible réaliste et un cas de forte sollicitation. Reproduisez le nombre de clients et l'organisation des fichiers prévus. Précisez si les données proviennent du cache, choisissez des jeux de données adaptés au test et répétez les mesures pour observer leur variabilité. Consignez les paramètres et les charges concurrentes afin de pouvoir comparer les résultats.

Exécutez ensuite les phases exigeantes de l'application : chargement des données, écriture de points de contrôle, reprise et enregistrement des résultats. Si l'application reste lente malgré un bon test synthétique, examinez ses accès aux données avant d'acheter davantage de capacité.

Un débit élevé et une faible latence sont des objectifs distincts

La liaison entre les clients et le stockage peut limiter les performances avant les disques. Examinez la bande passante, la contention, la topologie et les protocoles pris en charge. Un stockage plus rapide ne compense pas une liaison réseau déjà saturée.

Lorsque l'application le permet, limiter les ouvertures inutiles ou regrouper de petits enregistrements dans un format de fichier adapté peut améliorer les entrées-sorties. Les recommandations du NERSC abordent ces pratiques. Les modifications doivent préserver le fonctionnement des lectures et des mises à jour : regrouper les fichiers sans analyse peut créer un autre goulot d'étranglement.

Tester les accès simultanés pour la simulation et l'IA

Pour une simulation, un test important peut consister à faire écrire un point de contrôle à tous les nœuds de calcul en même temps. Pour l'apprentissage automatique, il peut s'agir de nombreux processus lisant les données d'entraînement pendant qu'une autre tâche écrit ses résultats. Les modes d'accès diffèrent, même si le système de fichiers HPC est identique.

Pour un entraînement de modèle, distinguez le temps de lecture des fichiers du temps consacré au décodage et à la préparation des échantillons. Un système de fichiers parallèle plus rapide ne supprimera pas un blocage lié au prétraitement. Si les lectures répétées bénéficient d'un cache local, incluez son remplissage et l'espace supplémentaire dans la comparaison.

Dimensionner la capacité et la reprise, au-delà de la vitesse

Le stockage HPC doit accueillir les tâches simultanées, les fichiers intermédiaires et les points de contrôle, en plus du jeu de données initial. Estimez le volume de travail maximal et conservez la marge recommandée par l'exploitant. Vérifiez aussi les limites du nombre de fichiers : disposer d'octets libres ne signifie pas que le stockage des métadonnées peut accueillir un nombre illimité de fichiers.

Demandez comment les performances évoluent lorsque des nœuds de calcul et de stockage sont ajoutés. Testez la capacité à évoluer avec la charge prévue, plutôt que de l'extrapoler à partir d'un seul serveur. En production, documentez les éventuels points uniques de défaillance et testez la procédure de reprise prise en charge. Les copies supplémentaires et les services de secours ont aussi un coût en capacité et en exploitation.

Valider aussi les besoins HPC dans le cloud

Des services gérés comme Amazon FSx for Lustre, Azure Managed Lustre et Google Cloud Managed Lustre permettent de déléguer une partie de l'exploitation. Comparez les configurations réellement déployables : emplacement, accès des clients, capacité, débit, options de reprise et transferts de données.

Une intégration au stockage objet peut faciliter les transferts d'entrée et de sortie, sans garantir la copie immédiate de chaque modification vers un compartiment. Lisez les règles d'import et d'export. Définissez qui lance les transferts, comment leur achèvement est vérifié et quelles données restent après la suppression du système de fichiers.

Chez Hivenet, distinguez les options documentées. La FAQ Compute, disponible en anglais, décrit le stockage SSD NVMe rattaché à l'hôte de l'instance et les conséquences de la suppression d'une instance. Ce stockage local ne fournit pas, à lui seul, un système de fichiers parallèle partagé.

La page stockage de Hivenet présente séparément le stockage objet compatible S3 et oriente les demandes de stockage réseau et HPC vers l'équipe commerciale. Confirmez l'architecture proposée, l'interface de fichiers, la persistance, les performances et le support pour votre usage. Les informations publiques ne permettent pas de conclure à l'existence d'une offre Lustre gérée en libre-service.

Questions fréquentes sur les systèmes de fichiers HPC

Chaque cluster HPC a-t-il besoin d'un système de fichiers parallèle ?

Non. Des tâches indépendantes peuvent utiliser un stockage local, et des besoins de partage modérés peuvent être satisfaits par NFS. Le stockage parallèle mérite une évaluation lorsque les entrées-sorties partagées simultanées constituent une limite mesurée ou une capacité nécessaire à l'application.

Les systèmes de fichiers distribués sont-ils toujours parallèles ?

Les termes se recoupent, mais décrivent des aspects différents. « Distribué » désigne des composants ou des données répartis entre plusieurs machines. « Parallèle » met l'accent sur les entrées-sorties simultanées entre les ressources de stockage. Vérifiez l'architecture et le comportement réels plutôt que de vous fier au nom.

Le stockage objet peut-il remplacer Lustre ou BeeGFS ?

Il ne peut les remplacer que si les exigences d'accès de l'application le permettent. Une application conçue pour des API objet peut se passer de stockage POSIX partagé. Un logiciel qui dépend d'accès simultanés aux fichiers et d'une sémantique précise nécessite une couche compatible ou une modification de l'application, suivie de tests.

Un système de fichiers plus rapide accélérera-t-il une tâche lente ?

Seulement si le stockage constitue une limite pertinente. Mesurez le temps d'attente lié aux entrées, aux points de contrôle et aux sorties. Le traitement CPU, l'utilisation des accélérateurs, la communication entre processus ou le code de l'application peuvent être les facteurs dominants.

Décider à partir d'une charge représentative

Décrivez d'abord les besoins d'accès partagé, puis mesurez les phases pendant lesquelles la tâche attend. Sélectionnez l'architecture de stockage la moins complexe qui répond à ces exigences et testez-la avec l'organisation des données et la simultanéité prévues.

Avant de vous engager, exigez une réponse à deux questions d'exploitation : où se trouvent les données de référence, et comment l'équipe reprendra-t-elle une tâche après une panne ? Un bon débit n'a d'intérêt que si le traitement complet peut être exploité et rétabli.