Stockage : Enakta propose une version clé en main du puissant DAOS

Un système léger qui tient intégralement en RAM

Dans le principe, une instance de DAOS fonctionne sur chaque nœud de stockage. Pour se connecter à ce nœud seul ou à tout un cluster de nœuds DAOS, une machine cliente (typiquement un serveur de calcul) exécute d’ordinaire elle-même la bibliothèque de fonctions LibDAOS.

Avec Enakta Data Platform, les machines clientes n’ont plus besoin de cette bibliothèque puisqu’elles communiquent via des protocoles standards. De fait, LibDAOS va plutôt loger sur chaque nœud de stockage, entre le système DAOS et le service de partage.

Enakta Data Platform présente l’ensemble sous la forme d’une image ISO bootable (y compris en réseau, via le protocole PXE), basée sur un Linux de Suse (SLES) suffisamment allégé pour tenir intégralement en mémoire. Chacun des protocoles de partage comme chaque module de DAOS fonctionne depuis un container autonome, au format générique OCI.

« Notez que nous n’utilisons pas Kubernetes. Personne ne devrait avoir besoin de Kubernetes pour faire fonctionner un système de stockage. Nous utilisons le gestionnaire de containers Podman, qui est bien plus léger. C’est le mot d’ordre de notre solution : nous tâchons de garder Enakta Data Platform aussi simple et aussi contrôlable que possible. C’est ce qui nous permet de déployer un cluster de 144 nœuds de stockage en seulement 45 minutes », glisse Denis Nuja.

Cette conception en containers est importante, car elle permet justement de distribuer un partage global sur plusieurs serveurs exécutant DAOS, de sorte à bâtir un cluster de stockage très performant.

Différentes approches pour le fonctionnement en cluster

Dans un cluster, chaque nœud DAOS possède une partie des données. Lorsque les serveurs de calcul veulent accéder au stockage, ils ne voient sur le réseau qu’un volume partagé, dont le nom est référencé dans les DNS du réseau avec l’adresse IP de chacun des nœuds. Les serveurs de calcul envoient au nom inscrit dans le DNS une requête en lecture ou en écriture. Au milieu du chemin, un switch réseau qui répartit les accès entre tous les nœuds redirige la requête vers un nœud au hasard dont l’adresse IP appartient au nom DNS du volume.

Si, en lecture, le container du protocole interrogé s’aperçoit que le nœud sur lequel il tourne n’a pas la donnée demandée, il sait en revanche où elle se trouve. Il communique alors avec le nœud possédant cette donnée et lui demande de répondre à la requête.

Mais il y a des variantes selon le cas d’usage. Si le cluster ne partage ses contenus qu’en S3, alors le switch du milieu est de préférence remplacé par une passerelle S3 qui connaît l’emplacement de toutes les données dans le cluster et va directement orienter la requête d’un serveur de calcul vers le bon nœud de stockage. La passerelle S3 est en l’occurrence un serveur qui exécute la bibliothèque d’accès LibDAOS et sur laquelle est greffée le container de partage en mode S3 d’Enakta Labs.

Si l’on est dans le cas d’un supercalculateur où chaque serveur de calcul héberge lui-même la bibliothèque LibDAOS, alors c’est cette bibliothèque – et plus exactement son extension de gestion des fichiers, LibDFS – qui connaît l’emplacement de chaque fichier dans le cluster. Là, la question de la répartition de charge ne se pose pas.

« Même pour le partage SMB, nous pouvons aussi trouver une optimisation. Par exemple, dans ce protocole, il s’avère qu’une requête peut être envoyée à seize nœuds de stockage en même temps. Personne ne le fait, car cela pose un problème de cohérence de cache entre les nœuds. Sauf que DAOS n’utilise pas de cache. C’est un axe de développement intéressant pour gagner en vitesse via du parallélisme et nous allons essayer de développer quelque chose autour de cela », dit Denis Nuja.

Il concède qu’entre un partage depuis les nœuds de stockage, un partage au niveau d’une passerelle intermédiaire, ou directement un agent d’accès sur la machine cliente, la dernière solution reste a priori la plus performante.

La bonne pratique : multiplier des nœuds de stockage très simples

Sur le plan matériel, Denis Nuja explique que les nœuds de stockage type sur lesquels s’exécute Enakta Data Platform ont un processeur, une ou deux cartes réseau et de six à huit SSD NVMe. « Nous ne mettons pas beaucoup de SSD NVMe par nœud, pour ne pas surcharger les bus PCIe », indique le fondateur d’Enakta Labs.

« Le fait est que deux serveurs monoprocesseurs avec six SSD NVMe chacun coûtent le même prix qu’un serveur à double processeur avec douze SSD NVMe. Mais il vaut mieux avoir plus de nœuds pour répartir les données et ainsi mieux résister aux pannes. » DAOS, comme les autres systèmes de stockage en cluster, distribue des blocs de données redondants sur les nœuds. Ce sont autant de copies de secours en cas d’incident.

« Donc un nœud correspond à une configuration très simple. Mais je dois dire une chose : nous préférons que le processeur soit un Intel plutôt qu’un AMD. Par leur design, les processeurs AMD ont plus de latence mémoire que les Intel quand, comme nous, vous faites communiquer tous les composants tout le temps entre eux (NVMe, RAM, processeur) », dit-il.

Demain, NFS en 400 Gbit/s

À terme, sans doute un peu avant l’été 2026, Enakta Data Platform devrait aussi proposer le protocole de partage NFS, en version 4.2. Alors que cette version de NFS supporte la déclinaison pNFS conçue pour gérer elle-même un stockage distribué sur plusieurs nœuds, Denis Nuja confie ne pas spécialement vouloir en tenir compte, du moins dans un premier temps.

« Nous n’avons pas besoin de pNFS, car le fonctionnement de DAOS en cluster peut s’en passer. Mais surtout, nous contenter d’utiliser un partage NFS de base, nous permet d’appliquer la même logique de cluster à tous les protocoles. Cela signifie que nous pouvons partager le même contenu en cluster sous tous les protocoles – SMB, S3, NFS, PyTorch – en même temps », argumente le fondateur d’Enakta Labs.

Avec pNFS, les requêtes seraient reçues par un nœud d’index qui répondrait au serveur de calcul d’aller chercher lui-même les données sur le bon nœud de stockage. Ce n’est pas nécessairement plus rapide qu’un autre processus de partage et ça ne correspond surtout au fonctionnement d’aucun autre protocole.

Un autre avantage de la dernière version 1.3 est qu’elle supporte des cartes réseau 400 Gbit/s, que celles-ci soient équipées de contrôleurs Nvidia (ConnectX) comme Broadcom (Thor). Enakta Data Platform gère surtout les communications en RoCE de ces cartes. RoCE est une évolution du réseau Ethernet capable d’envoyer les paquets de données en rafale, sans perte, directement vers la mémoire des serveurs de calcul. A priori, ni SMB, ni S3 ne sauront tirer profit de RoCE. En revanche, NFS et les supercalculateurs embarquant des logiciels compilés pour libDAOS seront compatibles.