Pure Storage : « Le stockage le plus optimal est celui qui reste le plus simple »

Lors de la récente conférence annuelle Accelerate du fabricant de baies de stockage Pure Storage, LeMagIT a pu croiser John Colgrove (en photo ci-dessus), son fondateur et gourou technique. C’est lui qui a inventé le DFM, le SSD si particulier qui équipe les baies de stockage du constructeur, dont l’intérêt réside dans une meilleure fiabilité et une capacité doublée par rapport aux SSD traditionnels.

Responsable des stratégies technologiques au sein de Pure Storage, il a souhaité dans l’interview ci-dessous recontextualiser l’intérêt des DFM au-delà de la simple haute capacité, raconter les enjeux techniques derrière les contrats avec les hyperscalers et dire pourquoi, selon lui, les fournisseurs qui réinventent la roue font fausse route.

LeMagIT : Vous tenez dans la main un des tout premiers exemplaires des prochaines DFM de 300 To. En quoi est-ce intéressant d’avoir un disque de 300 To ?

John Colgrove : Considérez la chose ainsi. Les disques durs représentent le second poste de consommation d’énergie dans un datacenter. De l’ordre de 25 à 30 % du total. Avec des DFM QLC de 300 To, nous divisons cette consommation par 10 par rapport à des disques durs qui atteignent aujourd’hui 30 To.

Peut-être même plus, car cette nouvelle génération de DFM a un débit de 3 Go par seconde, contre un maximum de 256 Mo/s par seconde sur un disque dur. Cela signifie que les transferts durent douze fois moins longtemps. Je parle bien entendu des flux continus [ceux des sauvegardes, soit l’usage des disques durs dans un datacenter, N.D.R.]. En accès aléatoires, un disque dur transférera au mieux 30 Mo/s. C’est-à-dire qu’un seul DFM peut dans ce cas remplacer 100 disques durs.  

« Nous augmentons régulièrement en capacité sans augmenter en électricité. »

Je précise que nos DFM de 300 To consomment exactement autant que nos DFM de 150 To, qui eux-mêmes consomment autant que nos DFM de 75 To. Nous augmentons régulièrement en capacité sans augmenter en électricité.

Et nous augmentons en capacité rapidement. Ce DFM de 300 To sera disponible avant la fin de l’année, un an après le DFM 150 To. Cela signifie que nous sommes à deux sauts de puces de proposer plus d’un Po par DFM. Nous allons aussi plus que quadrupler la vitesse prochainement, pour atteindre environ 14 Go/s grâce à un nouveau contrôleur de NAND.

LeMagIT : Sur les DFM, pourriez-vous aller au-delà d’un simple doublement de la capacité tous les ans ?

John Colgrove : Nous avons trouvé un moyen de mettre plus de puces de NAND par DFM, mais il reste plus intéressant pour nous d’utiliser des puces plus capacitives. Soit les fabricants parviennent à graver des circuits deux fois plus denses, soit ils empilent deux fois plus de circuits dans la même puce.

Il apparaît qu’ils vont connaître des difficultés avec ce procédé et c’est pourquoi il faudra vraisemblablement attendre plus de temps entre nos DFM de 600 To et ceux de plus de 1 Po, qu’entre nos DFM de 300 To et ceux de 600 To.

LeMagIT : Vous avez revendu votre technologie DFM à Meta. Allez-vous faire de même avec d’autres hyperscalers ?

John Colgrove : Oui, nous sommes en contact avec tous les hyperscalers. Certains attendent d’avoir validé – ou invalidé – d’autres alternatives pour remplacer leurs disques durs par des solutions à base de NAND QLC, avant de commencer à travailler avec nous. Mais cela prend de toute façon beaucoup de temps, car ce sont des contrats compliqués, qui demandent beaucoup d’adaptations de notre part.

« Certains [hyperscalers] attendent d’avoir validé (ou invalidé) d’autres alternatives pour remplacer leurs disques durs par des solutions à base de NAND QLC, avant de commencer à travailler avec nous. »

Nous avons commencé à discuter avec Meta 18 mois avant qu’ils passent la commande. Vous savez, les hyperscalers n’achètent pas des baies de stockage sur étagères, ils les fabriquent eux-mêmes à partir de pièces détachées de différents fournisseurs entre lesquels ils peuvent jongler. Cela signifie, pour commencer, que nous avons dû démontrer que nous étions capables de leur fournir des DFM qui seraient interchangeables avec n’importe quel autre support de stockage qu’ils utilisent.

Il a donc fallu que nous adaptions notre offre pour que nos DFM puissent s’insérer simplement dans leurs serveurs de stockage, qui utilisent d’ordinaire des disques durs ou des SSD classiques. En termes de connectique, il n’y a pas de problème, nos DFM s’insèrent sur des connecteurs NVMe standards.

La particularité de notre solution est qu’elle est pilotée par notre OS Purity, qui gère l’emplacement des bits dans les cellules NAND. Eux, en revanche, utilisent leur Linux. Nous avons donc mis au point une version des pilotes de nos DFM qui fonctionne depuis l’espace utilisateur de Linux, sans rien changer au noyau Linux et qui fonctionne par-dessus n’importe quel Linux qu’ils peuvent utiliser. Ils ont ainsi la garantie que nos DFM continueront de fonctionner chaque fois qu’ils appliquent des patches de sécurité à leur OS. 

Ensuite, ils utilisent une certaine télémétrie et certaines règles, pour contrôler leurs équipements, auxquelles nous avons dû nous adapter. Par exemple, quand un DFM a du mal à communiquer sur le bus PCIe, notre pilote le redémarre. Plus question de faire cela ici. Nous devons communiquer à leur télémétrie le problème du DFM et leur donner les clés pour qu’ils activent la fonction qu’ils souhaitent.

LeMagIT : Ce travail de développement pour Meta a-t-il servi à améliorer l’OS Purity sur vos baies ?

John Colgrove : Non. La plupart des fonctions qui gèrent les DFM s’exécutent déjà depuis l’espace utilisateur de Purity [qui est aussi un Linux, N.D.R.]. Et celles qui n’y sont pas – les pilotes réseau, l’orchestration temps réel – ont vocation à rester au niveau du noyau de Purity.

Et puis (même nos baies partagent donc les mêmes fonctions DFM que celles de Meta), elles sont conçues pour des besoins radicalement différents des leurs. Nos baies sont conçues pour répondre aux problématiques des entreprises. Eux ont des problématiques d’hyperscalers.

LeMagIT : Concernant le stockage pour l’IA, Dell (avec son projet Lightning) et d’autres (Weka, DDN, Vast...) réinventent la manière de communiquer avec les baies. Pourquoi vous en tenez-vous au standard pNFS ?

John Colgrove : Selon nous, il ne sert à rien de chercher à aller au-delà des standards – pNFS, RoCE v2 et Ultra Ethernet, en l’occurrence. Car, en matière de performances, nous n’irons de toute façon jamais plus vite que l’élément matériel le plus lent dans la chaîne.

Par exemple, aujourd’hui, vous pouvez mettre dans une baie une quarantaine de DFM avec un débit individuel de 3 Go/s [soit un cumul de 120 Go/s] qui vont consommer 80 canaux PCIe par contrôleur. Nos clients utilisent généralement huit cartes réseau 100 Gbit/s (10 Go/s par carte réseau) qui consomment 16 canaux PCIe, soit 96 canaux PCIe, ce qui est le maximum, pour un débit vers le réseau de 80 Go/s.
Quand nous multiplierons par quatre la performance des DFM et que nos utilisateurs adopteront des cartes réseau en 400 Gbit/s qui consomment individuellement quatre canaux PCIe 5.0, nous serons contraints aux mêmes limites du nombre de canaux PCIe insuffisants pour transporter toute la bande passante disponible.

« Selon nous, stocker les données sous forme de paires clé-valeur peut sans doute fluidifier les accès au niveau du système hôte, mais, derrière, la NAND doit toujours effacer et réorganiser des blocs de taille unique. »

LeMagIT : Et concernant l’amélioration du système Purity. Que pensez-vous de l’approche du système DAOS qui consiste à ne plus écrire les données par blocs uniformes, mais par couples clé-valeur de différentes tailles ?

John Colgrove : Chaque année, 1 % des SSD sur le marché tombe en panne, à cause de bugs dans le logiciel qui les pilote. Et ces bugs sont d’autant plus nombreux que ce logiciel est complexe. Selon nous, stocker les données sous forme de paires clé-valeur peut sans doute fluidifier les accès au niveau du système hôte, mais, derrière, la NAND doit toujours effacer et réorganiser des blocs de taille unique. Donc vous rajoutez une couche de complexité pour passer de l’un à l’autre et votre taux de panne annuel va grimper à 2 %.

C’est absolument contraire à notre objectif qui est de 0,125 % de panne par DFM par an. Et pour y parvenir, nous nous efforçons de garder nos algorithmes d’écriture les plus simples possibles.