2 La hiérarchisation des données HPC permet aux centres de calcul scientifique de garder un stockage haute performance coûteux disponible pour les tâches en cours, tout en conservant des années de données de recherche sur une capacité abordable. Universités, laboratoires nationaux et instituts de recherche exploitent des clusters qui lisent et écrivent des données à des vitesses considérables, issues de simulations, de pipelines de génomique, d’imagerie et, de plus en plus, d’entraînement d’IA. Les systèmes de fichiers parallèles qui alimentent ces clusters coûtent cher au téraoctet et se remplissent vite. Sans parcours clair de l’espace scratch vers le stockage projet puis vers l’archive, les centres se retrouvent avec des systèmes de fichiers saturés, des chercheurs mécontents et des données soit perdues, soit conservées indéfiniment sur le mauvais niveau. Cet article présente les niveaux de stockage typiques du calcul scientifique, la manière dont les données circulent entre eux, le rôle du stockage objet et les politiques qui font fonctionner la hiérarchisation. Il s’adresse aux architectes du calcul scientifique et du stockage HPC. Pour la gouvernance des données de recherche, consultez research data management storage (en anglais). Les niveaux de stockage d’un centre de calcul scientifique L’espace scratch Un stockage haute performance sur système de fichiers parallèle, souvent sur flash, utilisé pour les entrées, sorties et fichiers intermédiaires des tâches actives. Le scratch est optimisé pour le débit et les performances de métadonnées. Les fichiers sont généralement purgés après une période définie, par exemple 30 à 90 jours sans accès, et ne sont pas sauvegardés. Le stockage projet Un stockage partagé pour les équipes de recherche actives, qui contient les jeux de données, le code et les résultats qui survivent aux tâches individuelles. Il peut résider sur le même système de fichiers parallèle que le scratch ou sur un niveau distinct de plus grande capacité, et il est souvent sauvegardé ou protégé par des snapshots. Les répertoires personnels Un petit stockage sauvegardé pour la configuration des utilisateurs, les scripts et les petits fichiers. L’archive ou stockage de campagne Un stockage de grande capacité pour les données qui ne font plus l’objet de calculs actifs mais doivent être conservées pendant des mois ou des années : données de projets terminés, données brutes d’instruments, résultats publiés et données conservées pour la reproductibilité. Le stockage objet et la bande sont des choix courants. La préservation Pour les données à valeur de long terme, des copies de préservation avec contrôles d’intégrité et emplacements multiples. Pourquoi la hiérarchisation compte Le coût : les systèmes de fichiers parallèles sur flash coûtent bien plus cher au téraoctet que le stockage objet ou la bande. La performance : un scratch désencombré préserve les performances de métadonnées et de débit pour les tâches en cours. La capacité : les données de recherche croissent plus vite que les budgets de stockage haute performance. La sécurité des données : le scratch n’est pas sauvegardé, les données précieuses doivent donc passer sur des niveaux protégés. La conformité : financeurs et établissements exigent que les données de recherche soient conservées et gérées. Comment les données circulent entre les niveaux Le déplacement manuel Les chercheurs copient les données avec des outils comme rsync ou des utilitaires de copie parallèle. C’est simple, mais cela dépend de la mémoire des utilisateurs, et les données restent souvent sur le scratch jusqu’à leur purge. La hiérarchisation par politiques au sein du système de fichiers De nombreux systèmes de fichiers parallèles prennent en charge des politiques qui déplacent les fichiers selon leur ancienneté, leur taille ou leurs accès vers des pools moins coûteux ou des cibles externes, en conservant un stub ou une entrée dans l’espace de noms pour que les utilisateurs voient toujours le fichier. La gestion hiérarchique du stockage (HSM) Les systèmes HSM migrent le contenu des fichiers vers un niveau d’archive, souvent la bande ou le stockage objet, et le rappellent à l’accès. Les systèmes de fichiers parallèles proposent couramment un framework HSM qui s’appuie sur des agents de déplacement de données. Le déplacement piloté par les workflows Les pipelines chargent les données depuis l’archive vers le scratch avant les tâches et réécrivent les résultats ensuite, à l’aide de gestionnaires de workflows ou d’outils de transfert. C’est courant pour les données d’instruments et l’entraînement d’IA. Le rôle du stockage objet Le stockage objet est devenu un niveau central du calcul scientifique : De la capacité à moindre coût que les systèmes de fichiers parallèles, jusqu’à de nombreux pétaoctets par ajout de nœuds. L’accès S3 pour les outils modernes, les gestionnaires de workflows, les portails de données et les frameworks d’IA. La durabilité grâce à l’erasure coding (en anglais) et à la réplication multisite. Un accès en ligne, bien plus rapide à rappeler que la bande. Le partage, les objets pouvant être partagés avec des collaborateurs via des URL présignées ou des politiques d’accès. Un modèle de service, qui permet aux centres de proposer directement du stockage S3 aux chercheurs. De nombreux centres utilisent désormais le stockage objet comme niveau de campagne et d’archive, la bande servant de copie plus profonde ou secondaire lorsqu’une conservation très longue et peu coûteuse est nécessaire. Les données d’instruments et d’IA Les instruments comme les cryo-microscopes électroniques, les séquenceurs, les microscopes à feuille de lumière et les télescopes produisent des flux continus de données qui doivent atterrir dans un emplacement fiable avant leur traitement. De nombreux centres ingèrent les données d’instruments directement sur le stockage objet ou sur un système de fichiers d’atterrissage, puis les chargent sur le scratch pour le traitement. L’entraînement d’IA ajoute de gros jeux de données relus de nombreuses fois, souvent chargés depuis le stockage objet vers un stockage rapide proche des GPU. Les politiques qui font fonctionner la hiérarchisation Des politiques de purge du scratch, clairement communiquées, avec des avertissements avant suppression. Des quotas par projet qui incitent à déplacer les données inactives vers l’archive. Des allocations d’archive par projet, payantes ou gratuites, avec des conditions de conservation claires. L’automatisation du déplacement des données selon leur ancienneté ou le statut du projet. Des exigences de métadonnées, pour que les données archivées puissent être retrouvées plus tard. Des processus de fin de projet pour décider de ce qu’il faut conserver, publier ou supprimer. Le parcours type d’un jeu de données Suivons un jeu de données dans un centre. Une équipe de recherche lance une simulation climatique qui écrit 200 To de sorties sur le scratch en une semaine. Des tâches de post-traitement les réduisent à 20 To de fichiers prêts pour l’analyse dans le stockage projet, tandis que les sorties brutes sont copiées vers l’archive sur stockage objet avec les métadonnées du projet, et la copie sur le scratch est supprimée. Au cours des mois suivants, les chercheurs interrogent les fichiers d’analyse et rechargent parfois des portions des sorties brutes sur le scratch pour de nouvelles analyses. Lors de la publication d’un article, les données sous-jacentes sont référencées dans l’entrepôt institutionnel, la copie d’archive servant les téléchargements. En fin de projet, l’équipe décide des sorties brutes à conserver selon l’exigence de conservation du financeur, et le reste est supprimé selon le calendrier prévu. À chaque étape, les données résident sur le niveau qui correspond à leur usage. Mesurer l’efficacité de la hiérarchisation Parmi les indicateurs utiles : l’utilisation du scratch et la part des fichiers non consultés depuis plus de 30 jours, la croissance du stockage projet par équipe, les volumes ingérés et rappelés depuis l’archive, le délai de rappel depuis l’archive et le nombre de demandes de support concernant des données perdues ou purgées. Les suivre dans le temps montre si les politiques et l’automatisation fonctionnent, ou si les chercheurs ont besoin de plus d’aide pour déplacer leurs données. Dimensionner les niveaux Scratch : dimensionné pour les données de travail et le débit des tâches actives, pas pour le volume total. Projet : dimensionné pour les jeux de données actifs de l’ensemble des équipes. Archive : dimensionnée pour le cumul des données sur les durées de conservation plus la croissance, ce qui en fait généralement de loin le plus grand niveau. Réseau : dimensionné pour les déplacements entre niveaux, en particulier les chargements vers et depuis le scratch. Spécificités régionales et de financement Le calcul scientifique en Europe, au Royaume-Uni, aux États-Unis et en Asie fonctionne selon des modèles de financement et des politiques de données différents. Les centres nationaux et régionaux européens servent souvent de nombreux établissements et doivent, pour certains projets, garder les données dans les frontières nationales ou européennes. Des financeurs comme Horizon Europe, les conseils de recherche britanniques et les agences américaines exigent des plans de gestion des données qui influent sur la conservation et le partage. Les niveaux d’archive doivent permettre de respecter ces obligations, y compris en matière de localisation des données. Checklist : hiérarchisation des données HPC Définissez les niveaux scratch, projet, personnel, archive et préservation ainsi que leur rôle. Fixez les politiques de purge du scratch et de quotas par projet. Utilisez le stockage objet comme niveau d’archive et de campagne évolutif. Automatisez les déplacements avec les politiques du système de fichiers, un HSM ou des workflows. Planifiez l’ingestion et le chargement des données d’instruments et d’IA. Proposez un accès S3 aux chercheurs lorsque c’est utile. Exigez des métadonnées pour les données archivées. Dimensionnez l’archive pour le cumul et la croissance. Dimensionnez les réseaux pour les chargements entre niveaux. Alignez conservation et localisation sur les exigences des financeurs. En résumé La hiérarchisation des données HPC garde le stockage haute performance rapide et abordable en plaçant les données sur le bon niveau au bon moment. Le scratch sert les tâches en cours, le stockage projet contient le travail actif et le stockage objet fournit une archive en ligne et évolutive pour tout ce qui doit être conservé, avec la bande ou des copies de préservation si nécessaire. Des politiques claires, l’automatisation et l’accès S3 intègrent la hiérarchisation au quotidien de la recherche plutôt qu’à la marge, et protègent les données de recherche bien après la fin des tâches qui les ont produites. Questions fréquentes Qu’est-ce que l’espace scratch en HPC ? Un stockage haute performance pour les données des tâches actives, généralement sur un système de fichiers parallèle, purgé après une période définie et non sauvegardé. Où doivent aller les données HPC à la fin d’un projet ? Vers un niveau d’archive, souvent un stockage objet, avec des métadonnées et une conservation alignées sur les exigences de l’établissement et des financeurs. Le stockage objet peut-il remplacer la bande pour les archives HPC ? Souvent pour l’archive principale, car il est en ligne et plus rapide à rappeler. De nombreux centres conservent la bande comme copie plus profonde ou secondaire. Comment les données passent-elles des systèmes de fichiers parallèles au stockage objet ? Par des copies manuelles, des politiques de hiérarchisation du système de fichiers, un HSM ou des chargements pilotés par les workflows. Pourquoi ne pas tout garder sur le système de fichiers parallèle ? Il coûte cher au téraoctet, et l’encombrement dégrade les performances des tâches en cours. Pour aller plus loin Hiérarchisation d’un système de fichiers parallèle vers le stockage objet Stockage des données d’instruments Services de stockage S3 universitaires Research data management storage (en anglais)
