Stockage pour l’IA : JuiceFS conjugue les modes fichiers et objet
L’éditeur chinois Juicedata entend proposer un système de stockage qui supporte à la fois une capacité extensible à l’infini et une compatibilité directe avec toutes les applications et tous les agents de l’IA. La solution serait bien plus optimale que le récent S3 Files d’AWS.
Deux architectures se font concurrence pour stocker les données internes que les entreprises veulent soumettre à une IA : le stockage en mode objet, qui est extensible à volonté, et le stockage en mode fichier, qui est compatible avec toutes les applications et, donc, en ce qui concerne l’IA, avec tous les agents. Juicedata, une entreprise chinoise en pleine conquête du marché européen, conjugue les deux approches.
Son produit, JuiceFS, est un système de fichiers distribué, Open source, POSIX, qui repose sur un stockage objet. Qui plus est, sur n’importe quel stockage objet : MinIO ou Rados (Ceph) pour les plus connus sur site, ou AWS S3 et tous les services équivalents, en cloud.
« Le fait de stocker les données en mode objet apporte des avantages considérables par rapport à un système de fichiers ordinaire », lance Joe Zhou, l’un des principaux développeurs de la solution (en photo en haut de cet article), que LeMagIT a rencontré lors d’un récent événement IT Press Tour consacré aux acteurs qui innovent dans le domaine du stockage.
« Vous disposez d’une capacité extensible à l’infini et les lectures/écritures concurrentes sont automatiquement gérées, sans aucune contrainte. Il y a aussi le fait que les données sont immuables par défaut, ce qui signifie que vous êtes nativement protégés contre leur corruption en cas de cyberattaque », argumente-t-il.
Le stockage objet apporte aussi à JuiceFS la possibilité d’éclater en plusieurs endroits du monde le contenu d’un volume, ce que ne savent pas faire des systèmes distribués comme Lustre, GlusterFS ou encore CephFS qui sont cantonnés à leurs clusters locaux. Cette distribution géographique permet d’héberger des données au plus proche des utilisateurs, dans le cas d’une multinationale, par exemple. Elle permet aussi de faire du cloud hybride, d’autant plus qu’un même système de fichiers JuiceFS peut s’interconnecter avec différents systèmes ou services de stockage en mode objet.
Implémenter le fonctionnement des fichiers dans le mode objet
Cela dit, JuiceFS n’est pas le premier à faire reposer un système de fichiers sur un stockage en mode objet. LeMagIT avait déjà évoqué ObjectiveFS. Et en avril dernier, AWS lançait lui aussi une interface en mode fichiers pour son service de stockage objet S3 : S3 Files. Mais l’éditeur Juicedata prétend qu’il est le seul à ne pas se contenter de poser un accès POSIX par-dessus un service compatible S3.
« Le problème des produits concurrents est qu’ils ne gèrent pas vraiment le fonctionnement d’un système de fichiers. Par exemple, puisque les données sont justement immuables, si vous faites une légère modification dans un fichier, vous serez obligé de recréer une copie entière de ce fichier pour stocker sa mise à jour sur un volume objet », dit Joe Zhou. Et de préciser un point technique essentiel de JuiceFS : il ne stocke pas un objet par fichier. Il découpe d’abord le fichier en blocs de taille identique. Et chacun de ces blocs est un objet.
« Ainsi, lors d’une mise à jour, vous ne stockez qu’une nouvelle copie du bloc modifié », dit-il, en précisant que l’utilisateur peut choisir une taille fixe comprise entre 64 Ko et 4 Mo pour tous les blocs d’un volume.
En cloud, la différence de fonctionnement serait criante en matière de tarification. « AWS S3 Files repose sur le fait d’interfacer le service objet S3 derrière le service de fichiers AWS EFS. S3 est facturé 2 centimes par mois par Go. EFS, lui, est facturé dix fois plus cher. Si vos fichiers sont des vidéos de 20 Go par exemple, cela signifie que, lors de l’opération de réécriture, vous devez recopier l’intégralité des 20 Go dans EFS au tarif le plus cher, avant de renvoyer ces 20 Go vers S3 ou le contenu sera stocké en double », assure le développeur de Juicedata.
Un autre point clé de JuiceFS est qu’il sépare physiquement le contenu des fichiers de leur index. Ce dernier, présenté comme un serveur de métadonnées, est en réalité stocké dans une base de données SQL à installer sur un serveur à part.
« Encore une fois, l’avantage de procéder ainsi est d’économiser de l’espace de stockage. Quand vous déplacez tout un lot de fichiers d’un répertoire à l’autre chez nos concurrents, vous créez à chaque fois de nouvelles copies intégrales. Avec notre serveur de métadonnées séparé, nous changeons juste dans l’index le chemin POSIX vers les fichiers à montrer aux applications. Mais les données, elles, leurs blocs, ne bougent pas. Vous évitez même de générer du trafic réseau ! », s’enthousiasme-t-il.
À l’inverse, JuiceFS gère le tiering, ou la capacité de recopier les données vers un service de stockage plus lent, mais moins cher. Paradoxalement, S3 Files ne supporte pas encore cette fonctionnalité, alors qu’elle a initialement été pensée pour justement tirer parti des différents tarifs de S3 chez AWS. Si JuiceFS voit dans son moteur de métadonnées que des fichiers n’ont durablement pas été utilisés, il en crée une copie sur S3 Glacier et efface la version d’origine sur le service S3 normal. Ce dispositif fonctionne aussi avec des systèmes de stockage objet sur site.
Une version libre, une autre payante
Il existe deux versions de JuiceFS. L’une, Open Source, est librement téléchargeable depuis GitHub. L’autre, dite Enterprise Edition, est facturée selon la capacité de stockage gérée par le logiciel. Et l’une des principales différences entre les deux est justement le serveur de métadonnées.
Dans la version communautaire, l’utilisateur peut utiliser une des trois bases de données Open source suivantes : Redis, PostgreSQL ou TiKV. Dans la version commerciale, il s’agit d’une base de données spécialement écrite par Juicedata. Celle-ci est nativement conçue pour résister aux pannes. Elle est hautement disponible, ce qui nécessite d’ailleurs le déploiement de trois serveurs de métadonnées pour un bucket objet, et supporte la restauration instantanée.
Pour accéder au serveur de métadonnées et lire/écrire leurs fichiers dans le bucket objet, les serveurs et postes de travail ont besoin d’un logiciel client. JuiceFS en fournit un de type FUSE pour Linux, macOS et, dans une certaine mesure, Windows. Dans la version communautaire, ce client aménage sur sa machine hôte un cache qui lui permet de conserver sous le coude les données les plus souvent accédées. Dans la version Enterprise Edition, ce cache peut être partagé entre plusieurs clients sur un serveur local.
Enfin, la version Enterprise vient avec une fonction de réplication du système de fichiers vers un site distant, afin de minimiser la latence partout où l’entreprise utilisatrice estimera que ce sera nécessaire. Il est possible de répliquer le contenu intégral du stockage objet vers un autre stockage objet, ou de se contenter de répliquer les serveurs de métadonnées entre les sites. Dans ce second cas, les machines sur les sites distants pourraient se contenter d’un serveur de cache partagé pour accéder au jeu de documents qui les concerne.
Joe Zhou illustre ce cas d’usage avec l’exemple d’une entreprise chinoise, Minimax, qui réplique les serveurs de métadonnées sur une dizaine de ses sites géographiques pour que ses collaborateurs aient rapidement accès à des documents générés par une IA. Tandis que les données sources sont stockées juste à côté des serveurs qui les calculent grâce à leurs GPU.
