Les startups redoublent d’imagination pour concrétiser le stockage NVMe

Les avantages du NVMe

Proposer une nouvelle technologie nécessite de savoir aller au-delà des contraintes existantes, sans quoi il n’y a pas de véritable optimisation. Plusieurs fournisseurs se sont contentés d’équiper leurs baies SAN historiques d’unités NVMe, mais ces solutions restent très en deçà des possibilités offertes par le protocole.

Typiquement, les unités NVMe supportent un grand nombre d’entrées-sorties en parallèle, alors que le SCSI des baies de stockage ne véhicule qu’un flux par disque SAS ou SATA.

De même, le protocole NVMe permet d’adresser directement les octets dans les modules de mémoire persistante, dont les Optane d’Intel, alors qu’un système de stockage classique passe par des blocs.

Les défis à relever

Le premier défi pour un système de stockage NVMe est de parvenir à véhiculer les bons signaux au niveau des contrôleurs qui assurent les communications entre les serveurs et les baies de disques.

Le travail d’un tel contrôleur est de faire correspondre les dénominations logiques des ressources que voient les serveurs (un LUN, un système de fichiers...) avec les bons supports physiques au sein de la baie de stockage. Le contrôleur traite aussi les métadonnées sur lesquelles reposent des services propres au stockage, comme la déduplication, la compression ou encore les snapshots. A cause de tout ceci, le contrôleur surcharge les flux de données et équivaut à un goulet d'étranglement.

Un second défi est de paralléliser les accès vers un maximum d’unités NVMe. Encore une fois, le protocole SAS utilisé d’ordinaire à l’intérieur des baies ne gère qu’un seul accès à la fois par disque ou par enchainement de disques, ce qui limite les performances globales du système.

Par ailleurs, installer un grand nombre d’unités NVMe dans une seule machine est en soi un problème : celles-ci s’installant sur les slots PCIe de la machine, leur nombre possible est de fait plus limité que celui des disques SAS. Cette contrainte est contournée par l’arrivée de capacités de plusieurs téraoctets par unité. 

Les fournisseurs ont mis en œuvre plusieurs techniques pour relever ces défis.

1^ère solution : éliminer le contrôleur

Puisque le contrôleur représente un goulet d'étranglement, certains fournisseurs ont tout simplement décidé de le supprimer. L’enjeu est double : non seulement éviter la superposition de couches qui brident le débit, mais aussi permettre aux serveurs de parler aux disques à la manière plus optimale du NVMe.  

Ce type d’architecture, dit désagrégé, a été implémenté par les startups Apeiron et E8 Storage. Sans contrôleur, celles-ci ont dû trouver une parade pour bénéficier tout de même des fonctions de déduplication, de compression et de snapshots.

Dans le cas de E8, les métadonnées liées à ces fonctions sont stockées sur un serveur séparé. Les hôtes y accèdent et exécutent eux-mêmes les algorithmes adéquats. A terme, E8 prévoit de confier ce travail aux cartes réseau capables de faire du RDMA-over-Ethernet. 

L'appliance de stockage 2U ADS1000 d'Apeiron reconnaît quant à elle déjà les serveurs équipés de cartes réseau spécialisées et elle leur permet de dialoguer directement avec les unités de stockage installées dans son châssis 2U. Il n’y pas ici de serveur annexe ; toutes les fonctions liées au stockage doivent être exécutées côté serveurs. Néanmoins, cela n’entraîne que de 2 à 3 microsecondes de latence supplémentaire.

2^nde solution : faire du Scale-out

Une autre solution, implémentée par les startups Vexata et Pavilion Data, consiste à éliminer les goulets d’étranglement en démultipliant les composants de la baie de stockage.

Chez Vexata, l’architecture est conçue pour augmenter de manière indépendante le nombre de connecteurs à l’extérieur de la baie et la quantité de ressources de stockage à l’intérieur. Les contrôleurs d'E/S frontaux (IOC) se connectent aux modules de stockage (ESM) via un fond de panier Ethernet. Les métadonnées qui indiquent comment utiliser les ressources de stockage sont cette fois-ci conservées à la fois dans la mémoire des contrôleurs frontaux et sur les modules de stockage eux-mêmes. De fait, pour accroître les capacités et/ou les performances, il devient possible d’ajouter plus de modules de stockage, plus de contrôleurs frontaux ou plus des deux à la fois.

Pavilion Data a lui aussi conçu une architecture qui rappelle celle des switches réseau. Ici, le châssis 4U accueille de 2 à 20 contrôleurs et jusqu'à 72 SSD NVMe. Chaque contrôleur fournit quatre connecteurs hôte 100GbE. Comme précédemment, les performances s’augmentent en ajoutant des contrôleurs en frontal et/ou des unités de stockage en interne. Les métadonnées sont quant à elles traitées par deux cartes internes (redondantes) spécialisées.

3^ème solution : passer par du Software-Defined

D’autres startups, comme Excelero et WekaIO, ne cherchent pas à innover sur le matériel mais sur le logiciel. En adoptant une approche Software-Defined, leurs solutions peuvent être implémentées à la fois sur des infrastructures hyperconvergées, sur des baies de stockage dédiées, voire en cloud public.

La solution NVMesh d’Excelero implémente NVMe-over-Fabrics via un protocole propriétaire appelé RDDA. Alors que RDMA se contente de connecter des serveurs ensemble et de leur fournir un accès plus direct depuis leur mémoire, RDDA va plus loin et rend les périphériques de stockage NVMe accessibles sur le réseau, sans solliciter le processeur du serveur cible. Au final la solution est particulièrement évolutive.

Matrix de WekaIO est un système de fichiers scale-out déployé sur un cluster de serveurs. Matrix supporte des milliers de nœuds et des milliards de fichiers. Il établit surtout une communication directe entre les supports NVMe et les cartes réseau en contournant en grande partie les fonctions d’entrées-sorties de Linux.

Si les applications pensent voir un système de fichiers local, les données sont bel et bien distribuées et protégées au travers des nœuds à l'aide d’un système d’erasure-coding propriétaire appelé DDP (Distributed Data Protection).

Matrix peut s’exécuter depuis un cloud public (AWS, pour l’instant) sur des instances virtuelles configurées pour prendre en charge le stockage NVMe ou SSD local.

Les prochains développements

Les systèmes dont nous avons parlé ici reposent sur les réseaux Ethernet/RDMA, InfiniBand ou encore Fibre Channel qui relient des baies de stockage à des serveurs d’applications.

NVMe/TCP, qui sera vraisemblablement la prochaine évolution de NVMe-over-Fabrics, devrait permettre de déployer un stockage très rapide depuis des matériels plus basiques.

Toutes les technologies liées au NVMe allant en se démocratisant, le nombre de startups dédiées à ce domaine est susceptible d’exploser dans les mois à venir.