Stockage : la startup TLC se lance pour promouvoir Lustre

La startup des développeurs originaux de Lustre

Accessoirement, l’équipe de TLC compte bien participer aux développements futurs de Lustre. C’était d’ailleurs l’activité principale de son équipe quand elle était encore salariée de DDN. Et même avant cela. Le directeur technique Andreas Dilger (à gauche sur la photo en haut de cet article) est de l’aventure Lustre depuis ses débuts, en 2001.

À cette époque, des chercheurs décident de donner une carrière commerciale au système de fichiers pour clusters de serveurs qu’ils ont mis au point à l’université de Carnegie Mellon ; c’est le lancement de la startup Cluster File Systems (CFS). Après un certain succès dans des centres de recherche affiliés au ministère de l’énergie étatsunien, Sun Microsystems décide de racheter CFS en 2006, puis Sun se fait à son tour racheter par Oracle en 2010.

Ce dernier se désintéresse de Lustre et laisse carte blanche à des entreprises tierces pour le développer. C’est à ce moment qu’Andreas Dilger quitte Oracle pour fonder une nouvelle startup, Whamcloud, au sein de laquelle il compte façonner la suite du système.

C’est aussi à ce moment que plusieurs acteurs impliqués dans les supercalculateurs décident de fonder le consortium OpenSFS dans le seul but de mettre une version 2 de Lustre en Open source et d’encadrer son développement. Depuis lors, plusieurs entreprises contribuent chacune de leur côté à faire évoluer telle ou telle partie de Lustre.

En 2012, Intel récupère Whamcloud. Son équipe se scinde en deux : celle d’Andreas Dilger continue de plancher sur Lustre, l’autre développe le système DAOS. Puis, en 2018, DDN rachète à Intel l’équipe en charge de Lustre.

La raison pour laquelle l’équipe de TLC ne travaille plus pour DDN n’est pas claire. Officiellement, Peter Jones et Andreas Dilger auraient fondé la startup afin qu’il subsiste des développements neutres de toutes les velléités économiques des grandes marques citées au début de cet article. On n’en saura pas plus.

Lustre vs pNFS

La jeune startup américaine a tout à prouver en ce qui concerne sa capacité à épauler des intégrateurs de clusters d’IA de l’autre côté de l’Atlantique. Elle a néanmoins des connexions avec le CEA, qui utilise lui aussi Lustre. Mais sa présentation devant la presse aura toutefois eu le mérite de repositionner Lustre face à un concurrent qui fait bien plus parler de lui, dans le tout-venant des entreprises intéressées par les clusters d’IA : pNFS.

Tous les systèmes de stockage destinés aux clusters de serveurs doivent gérer les accès parallèles des nœuds de calcul vers leurs données de travail. Dans les solutions que les entreprises utilisent d’ordinaire, c’est un switch réseau qui se charge de répartir les communications entre plusieurs serveurs NAS qui partagent tous le même volume de données, lequel est physiquement stocké sur un cluster de baies de disques, en mode bloc, ou objet.

Cette architecture appuie son efficacité sur la réplication des mêmes données entre plusieurs baies de disques, pour favoriser des communications parallèles de bout en bout. Mais au-delà d’une certaine intensité dans les communications, les serveurs NAS se retrouvent submergés entre les requêtes entrantes et l’envoi sur le réseau des données précédemment demandées. Le problème est que la conversion d’un nom de fichier en adresses de blocs de données ou en références d’objets, plus la validation des droits utilisateurs, demandent autant de temps de calcul que faire voyager des données entre les disques et les machines du réseau.

Pour pallier ce problème qui se manifeste dès qu’on effectue des calculs intensifs, parmi lesquels l’entraînement des IA, Lustre et pNFS séparent les deux opérations. Ici, des serveurs de métadonnées reçoivent les requêtes des machines de calcul et y répondent, non pas en revoyant les fichiers demandés, mais en indiquant où leurs données se trouvent sur les baies de disques. À charge, alors, aux machines de calcul d’aller lire ou écrire les données voulues à l’adresse exactement indiquée.

« Le protocole pNFS ne fait rien de plus. C’est-à-dire qu’il fonctionne bien tant que les machines de calcul n’accèdent pas au même fichier en même temps. Lustre, lui, gère des copies parallèles de répertoires entiers. Par ailleurs, Lustre a la capacité de déplacer un fichier – ou même une partie d’un fichier – sur des médias plus rapides, s’il constate que ces données-là sont accédées par des machines plus rapides que les autres », explique Andreas Dilger, en précisant qu’il est possible de mixer dans un même cluster de stockage des disques durs économiques et des SSD NVMe très rapides.

Sous Lustre, la machine cliente se voit attribuer un espace de stockage virtuel, physiquement situé sur les disques les plus disponibles, pour faire tous ses travaux de lecture/écriture. Les baies de disques qui stockent les données ont par ailleurs un minimum d’intelligence, pour savoir calquer des espaces virtuels avec des espaces physiques. En tâche de fond, les serveurs de métadonnées conservent une trace de toutes les opérations et peuvent réassembler un fichier de manière cohérente malgré des écritures parallèles.

Autre avantage de Lustre par rapport à pNFS, il suffit d’une requête pour savoir où se trouve l’intégralité du fichier à lire ou écrire. Ce défaut est plus exactement dû au système de fichiers sous-jacent (Ceph, ZFS...) où chaque entrée dans un répertoire ne peut pointer que vers une taille maximale de données, générant des entrées supplémentaires au-delà.