Stockage : ce que l’on sait du projet secret de Dell

Ce qui existe pour l’instant au catalogue Dell : PowerScale

Pour offrir beaucoup de capacité à beaucoup de serveurs, une baie PowerScale est composée de plusieurs serveurs NAS qui disposent de leurs propres disques et qui partagent tous le même volume sur le réseau. En frontal, un switch répartit les requêtes aux protocoles NFS ou SMB qui viennent du réseau vers les nœuds.

Chaque nœud stocke sur ses propres disques une partie du volume global. Soit le nœud qui reçoit la requête dispose des données demandées et il répond directement. Soit son index lui dit que les données sont sur un autre nœud du cluster et, dans ce cas, il va les chercher via un réseau arrière, qui relie les nœuds entre eux, avant de les envoyer à la machine qui en a fait la demande.

Évidemment, pour accélérer un peu les accès et assurer la résilience, chaque nœud dispose d’un cache avec une partie des données issues des autres nœuds. Lors des écritures, chaque nœud met à jour l’index et le cache des autres nœuds.

L’intérêt de PowerScale est qu’il est très élastique : il suffit de rajouter des nœuds pour augmenter à la fois la capacité de stockage et le nombre d’instances NAS prêtes à répondre aux requêtes SMB ou NFS. Son défaut est qu’il souffre de latence, à la fois quand le nœud qui répond n’a pas les données demandées et quand il faut mettre à jour les caches dans tous les nœuds.

Ce qu’on utilise pour le stockage des clusters de calcul : un NAS parallélisé

Pour pallier ce problème de latence, il existe plusieurs solutions NAS dites « parallèles » (pNFS, Lustre, VAST, Weka...) qui fonctionnent toutes peu ou prou de la même manière. Dans ce type d’architecture, les nœuds qui répondent aux requêtes NFS (ou équivalent) ne contiennent qu’un index qui indique où se trouve la donnée recherchée. Les données en elles-mêmes logent sur des tiroirs de disques, connectés à un réseau bis (en mode bloc, accessibles via des protocoles tels que iSCSI, NVMe/TCP, NVMe/RoCE, etc.).

Lorsque la machine du réseau sait où se trouve la donnée qu’elle demande, elle va la chercher elle-même à l’adresse du tiroir de disques que lui a indiqué l’index. Lorsqu’une machine du réseau écrit une donnée, elle le signale au serveur d’index, qui lui dit où écrire la donnée et la machine du réseau l’écrit elle-même.

L’intérêt de ces NAS parallélisés est qu’il n’y a plus que des accès directs et plus de gestion des caches. C’est bien plus rapide. Et tout autant élastique, puisqu’il suffit de rajouter des tiroirs de disques pour augmenter la capacité et des serveurs d’index pour augmenter le nombre de requêtes simultanées. L’inconvénient est que les machines du réseau doivent toutes avoir un pilote et une carte réseau qui leur permet de lire ou d’écrire en mode bloc sur un réseau bis.

Pourquoi Dell a souhaité réinventer la roue

A priori, le projet Lightning sera un NAS parallélisé. Mais d’un nouveau genre, car Dell a préféré réinventer la roue plutôt qu’adopter une solution déjà existante.

« Le problème des NAS parallélisés est que les machines du réseau doivent demander où se trouve la donnée. Nous sommes plutôt partis sur une solution où les machines du réseau possèdent directement à l’index des données. Contrairement à pNFS, par exemple, vous n’avez même pas à commencer par chercher l’adresse IP du serveur qu’il faut interroger pour obtenir l’index » dit Rajesh Rajaraman.

Il ajoute que coller à un standard existant, ce qu’est pNFS, est séduisant, mais qu’il est impossible de faire évoluer rapidement un standard. Donc, pour implémenter une architecture où l’index serait stocké dans chacune des machines du réseau, autant partir d’une page blanche.

« C’est exactement pour cette raison que les supercalculateurs préfèrent utiliser des NAS parallélisés propriétaires [Weka, VAST, Lustre, NDR] plutôt que pNFS. Parce qu’ils sont livrés avec une structure de données, soit un plan du stockage sous forme de métadonnées, qui est prête à l’emploi », précise-t-il.

L’idée : travailler avec des morceaux de fichiers de différentes tailles

« Un autre point qui nous paraît important est que l’index doit pouvoir pointer vers un fichier qui est réparti entre plusieurs disques et qu’il faut parvenir à le faire avec des morceaux de fichiers de différentes tailles. Par exemple, en IA, vous voudrez plutôt utiliser des morceaux de 1 Ko, alors qu’il vaut mieux utiliser des morceaux bien plus importants en supercalcul », continue Rajesh Rajaraman, en rappelant que cette notion est absente de pNFS.

« Mais cela va même au-delà de l’application. La taille des morceaux de fichiers doit aussi tenir compte de la vitesse de cartes réseau et du nombre de disques présents dans un tiroir. Typiquement, avec une carte 200 Gbit/s, vous ne pouvez lire des données que depuis 16, voire 18 disques. Mais les tiroirs de disques en ont 24. Il faut donc un algorithme dans le système de stockage qui tienne compte de ce paramètre », ajoute-t-il.

Parmi les complexités à prendre en compte, il y a le fait de gérer des écritures simultanées de plusieurs GPU vers un même fichier. Le fait de travailler sur des morceaux de fichiers et non plus des fichiers entiers, permettrait de verrouiller seulement une petite partie de données le temps qu’une écriture se termine. Cela signifie que deux GPU pourraient écrire en même temps un fichier à partir du moment où ils n’écrivent pas le même morceau.

« Sans cela, vous seriez obligé de mettre la seconde écriture dans un cache, pour rassembler ensuite les deux autres écritures. Mais le cache coûte beaucoup en latence dans ce scénario. Dans Projet Lightning, il n’y a aucun cache », assure Rajesh Rajaraman.

La solution : un système de fichiers exécuté sur les serveurs de calcul

Plus Rajesh Rajaraman dévoile des détails, plus il apparaît que l’essentiel de la logique du système de stockage sera incarné par un système de fichiers complet installé sur chaque machine cliente. Alors qu’en pNFS il s’agit juste d’un pilote d’accès en mode bloc greffé au protocole NFS du système hôte.

« Côté client, nous avons en effet développé un système de fichiers POSIX qui expose localement les contenus du stockage distant aux applications. Normalement, vous devez passer par la couche Fuse de Linux pour greffer votre propre système de fichier à l’OS d’une machine. Mais Fuse pose des contraintes vis-à-vis de ce que j’ai décrit plus haut. Alors, avec Nvidia et d’autres, nous avons réimplémenté Fuse à notre manière, sous la forme d’un pilote à installer sur la machine cliente. »

« C’est-à-dire que, côté client, il n’y a plus aucune notion de monter localement un volume ou plusieurs volumes qui se trouvent sur un ou plusieurs serveurs NAS distants. Il n’y a pas non plus de notion de périphérique en mode bloc que l’on formate en ext4 ou ext3. Le système d’exploitation a accès à notre système de fichier. Point. Tout le reste, l’optimisation des accès, l’emplacement des données, c’est notre cuisine interne », assure le directeur technique de Dell.

La description que donne Rajesh Rajaraman fait furieusement penser à DAOS. Pour assurer un haut niveau de performances, ce système de stockage, initialement développé par Intel et désormais Open source, fonctionne également avec des morceaux de données de taille variable et monte sur la machine cliente un système de fichiers qui contourne Lustre.  

« Nous avons effectivement travaillé avec les gens de DAOS. Cependant, DAOS et Project Lightning sont deux développements différents. Eux se focalisent sur l’intégration directe de leur stockage avec des applications. Nous, nous poussons bien plus loin que n’importe qui le fonctionnement du système de fichiers. Project Lightning optimise les accès en temps réel selon la nature des données et des requêtes. »

De simples tiroirs de disques accédés en mode bloc par les serveurs de calcul

Reste à savoir à quoi ressemblera la baie de stockage du Projet Lightning. « Justement : elle n’aura absolument rien de particulier », répond Rajesh Rajaraman !

« Il s’agira pour ainsi dire de simples tiroirs de disques directement reliés en mode bloc, via un switch réseau, aux serveurs de calcul qui, eux, posséderont tout le système de fichier. Alors, bien entendu, il y aura tout de même une sorte de SDS [Software-Defined Storage] au niveau du switch. Mais c’est uniquement pour l’aspect convergence. Pour que tous les disques soient accessibles à tous les serveurs de calcul comme s’il s’agissait d’un seul périphérique SAN. Et pour poser des verrous sur les morceaux en cours d’écriture », précise-t-il.

Cette architecture permet selon lui de faire simplement du RDMA. Idéalement avec, de part et d’autre, des cartes réseau RoCE ou Ultra-Ethernet qui autorisent des communications en rafale, sans perte de paquets ni congestion.

« Quitte à avoir des cartes réseau intelligentes avec un DPU, nous aurions pu confier toute l’exécution de notre système de fichiers à ce DPU. Mais nous ne le faisons pas pour deux raisons. La première est qu’une carte réseau, comme la BlueField-3 de Nvidia, n’a pas assez de mémoire. Qui plus est, sa mémoire n’est pas assez rapide pour les accès intensifs de notre système de fichiers. »

« La seconde raison est que, parce que nous implémentons une optimisation des accès par type de données, tandis que le DPU va typiquement être utilisé pour décoder des trames et exécuter des règles de sécurité, il faudrait ajouter une couche de virtualisation au niveau du DPU. Nous l’avons testé avec Nvidia et cela ruine les performances », raconte le directeur technique.

Il admet que, à date, le projet Lightning ne fonctionne que sur des serveurs de calcul Nvidia, c’est-à-dire avec des GPU et des cartes réseau de cette marque.

« Le projet Lightning repose beaucoup sur la gestion des fichiers par Cuda, la plateforme logicielle qui accompagne le matériel de Nvidia. Pour autant, la beauté d’une solution de stockage uniquement logicielle réside dans la facilité à l’adapter à tous les matériels. Nous travaillons en ce moment avec Broadcom, qui fournit des puces réseau UltraEthernet capables de faire du RDMA avec d’autres GPU », conclut-il.