scratch_manager: gestionnaire de mise en cache de jeux de données

J'ai eu l'occasion de développer un petit logiciel open-source pour mon travail, donc j'en profite pour partager ici.

Motivation

Sur les grappes de calculs (clusters) dédiés à l'intelligence artificielle, il y a un problème assez récurrent lié au stockage et à l'accès aux données.
Dans ces installations, on trouve généralement d'un côté une baie de stockage avec des jeux de données composés de millions de petits fichiers, et de l'autre côté les nœuds de calcul qui lisent ces fichiers.
La baie est montée sur tous les noeuds (ex: nfs, gpfs, lustre, etc.).

Quelques ordres de grandeurs et précisions :

• Une expérience (un job) travaille pendant quelques jours, et sur un jeu de données à la fois.
• Plusieurs expériences de différents utilisateurs peuvent se partager un nœud de calcul (c'est très bien géré par slurm avec des cgroups).
• Les fichiers sont assez petits (entre 100ko et 10mo), chaque jeu de données pèse entre une centaine de giga et un téra.
• Les fichiers sont lus aléatoirement, autour d'une centaine de fois chacun.

En termes de stockage, ces millions de fichiers sont déjà un problème en soi pour le système de fichier.
Pour la charge de travail, les centres de calculs adoptent plusieurs politiques avec leurs avantages et inconvénients :

Option 1: Obliger les utilisateurs à copier les données sur un disque local du nœud au début de l'expérience, puis à nettoyer à la fin. L'ennui, c'est qu'il faut répéter l'opération à chaque expérience, hors elles peuvent s’enchaîner assez fréquemment en phase de mise au point d'un modèle. D'autre part, si l'expérience plante, le nettoyage des fichiers n'est pas garanti. Enfin, différentes expériences sur un même nœud ne partagent pas le cache, on pourrait donc se retrouver avec le même jeu de données en doublon.

Option 2: Opter pour une solution de mise en cache matérielle ou logicielle, ce qui est coûteux mais transparent pour l'utilisateur.

Option 3: Imposer l'utilisation d'une base de données spécifiquement étudiée pour ce type d'usage (ex: S3 avec minio), ce qui oblige les utilisateurs à modifier leur code de chargement des données et à convertir les données.

Approche

Pour scratch_manager, la liste des objectifs était donc la suivante :

1. Regrouper les fichiers dans des archives pour que le nombre de fichiers sur la baie reste faible.
2. Garder un accès aux données via une API de filesystem posix.
3. Pas de délai pour démarrer une expérience.
4. Mise en cache transparente pour l'utilisateur.
5. Mutualiser le cache entre les expériences et aussi entre les utilisateurs.

Pour 1 et 2, l'astuce consiste à utiliser des images disques qui rassemblent les fichiers d'un jeu de données. J'ai opté pour squashfs mais de l'ext4 en lecture seule fonctionnerait aussi.
Pour 3, on monte les images stockées sur la baie afin que le contenu soit immédiatement accessibles. Bien sûr, toutes les lectures occasionnent alors de la charge de travail sur la baie de stockage.
Pour 4, on utilise un démon qui copie les images localement sur les nœuds et les monte par-dessus le premier montage. Linux gère ça très bien à chaud même s'il y a des fichiers ouverts. Après ça, les nouveaux accès pointent vers les disques locaux.
5 est résolu par le fait qu'un démon système gère ça pour tout le monde.

Voilà la nimage qui récapitule le bazar :

Détails d'implémentation

Mesure du traffic: Du fait que l'on travaille avec des images disques, le débit sur chaque jeu de donnée est accessible en consultant /proc/diskstats. Il faut juste faire le lien entre les /dev/loop* et les images.

Allocation du cache: L'optimisation des images à mettre en cache est un problème de Knapsack, j'ai honteusement copié-collé le code qui résout ça.

Démontage et suppression des images: Pour appeler umount, il faut penser à passer le flag --lazy pour attendre la fermeture des fichiers encore ouvert. Étonnamment, la suppression d'une image montée ne pose pas de problème, le fichier disparaît quand on fait un ls, mais subsiste en fait jusqu'au démontage.

Conclusion

Le projet est en ligne: https://github.com/CEA-LIST/scratch_manager
On ne va pas se mentir, c'est encore expérimental donc attention à votre hamster.

Je suis preneur de retours et de signalements de bugs bien sûr.

Commentaires :voir le flux Atomouvrir dans le navigateur