Comprendre NVMe-over-TCP, le stockage SAN NVMe le plus simple
Parmi les différents portages du protocole NVMe à l’échelle des infrastructures de stockage SAN, cette déclinaison utilise directement les très connus et peu chers réseaux TCP/IP.
NVMe-over-TCP, ou NVMe/TCP, est la déclinaison la plus récente du protocole NVMe-over-Fabrics, alias NVMe-oF. Sa particularité est d’embarquer des commandes NVMe dans des paquets TCP/IP tout ce qu’il y a de plus standard.
Toutes les versions de NVMe-over-Fabrics permettent aux serveurs et aux baies SAN de communiquer via des commandes NVMe, bien plus adaptées aux unités de stockage Flash que les commandes SCSI, conçues pour les disques durs. NVMe-over-TCP transfère ces commandes sur le réseau physique Ethernet, comme NVMe-over-RoCE. Mais à la différence de ce dernier, les administrateurs n’ont pas ici à configurer de manière spéciale les switches et les cartes réseau des serveurs.
Avantages et inconvénients
NVMe-over-TCP se présente donc comme l’une des solutions les plus économiques, puisque les infrastructures Ethernet sont moins chères que celles du Fiber Channel utilisées en NVMe-over-FC, et la plus simple à mettre en œuvre, d’autant que les réseaux TCP/IP sont largement maîtrisés.
Accessoirement, NVMe-over-TCP étant naturellement routable, les serveurs et leurs baies de stockage peuvent communiquer au travers d’un réseau d’entreprise déjà en place, sans nécessiter de switches dédiés. Cela est même possible au travers d’Internet, pour enregistrer ou lire des données sur un stockage situé ailleurs, typiquement sur site de secours. Ou au siège d’une entreprise, si le serveur se trouve dans une succursale.
Malgré ces avantages, NVMe-over-TCP souffre aussi d’inconvénients. Le plus important est qu’il sollicite la puissance de calcul du serveur, laquelle n’est donc plus entièrement disponible pour exécuter les applications courantes. Parmi les opérations de TCP gourmandes en ressources processeurs, citons le calcul du code de parité (checksum) de chaque paquet.
Un autre inconvénient est qu’il induit plus de latence dans les transferts que les autres protocoles NVMe-over-Fabrics. Ce problème est dû notamment à la nécessité de maintenir plusieurs copies des données dans les flux pour contourner la perte des paquets au niveau du routage. Selon plusieurs tests de performance, une liaison NVMe-over-TCP affiche ainsi une latence plus importante de 10 à 80 microsecondes par rapport à une liaison NVMe-over-RoCE sur une même communication.
Ces problèmes de latence dépendent fortement de l’implémentation du protocole et du type de données transférées. Les analystes s’attendent ainsi à voir la latence se réduire au fur et à mesure que des fournisseurs implémenteront le protocole en imaginant de nouvelles optimisations.
Précisons d’ailleurs que la spécification de NVMe-over-TCP décrit une implémentation logicielle, qui se greffe sur la pile TCP/IP du système d’exploitation du serveur ou du contrôleur de la baie. Cela dit, il est techniquement possible d’implémenter NVMe-over-TCP dans des accélérateurs matériels.
Comment fonctionne NVMe-over-TCP
Techniquement, TCP sert à définir la manière dont les données doivent être encapsulées dans des paquets, afin qu’il soit possible de les transférer via des liens Ethernet entre un serveur et le contrôleur d’une baie de disque.
Le protocole envoie ensuite ces paquets au destinataire, où il assemble à nouveau l’information. Cette mécanique assure que toutes les données sont correctement transmises.
TCP fonctionne de concert avec IP, l’Internet Protocol, qui définit comment sont adressés et routés les paquets. Au final, NVMe-over-TCP est compatible avec absolument tous les réseaux TCP/IP, Internet compris.
Par convention, un réseau TCP/IP est divisé en quatre couches : applicative, transport, réseau et physique. La couche applicative correspond aux commandes NVMe, celle de transport à TCP, celle du réseau à IP et la couche physique à Ethernet.
En pratique, le serveur ouvre la connexion vers le contrôleur de la baie en lui envoyant une requête. Lorsque le contrôleur répond, la communication est établie. Le serveur envoie ensuite un PDU, un Protocol Data Unit, qui définit une structure pour le transfert des données (des paquets d’une certaine taille, composés selon un certain format), mais aussi pour contrôler le déroulement de ce transfert (une numérotation des paquets envoyés en file indienne) et obtenir des informations sur son statut (certaines étiquettes de contrôle dans chaque paquet). Le contrôleur envoie à son tour un PDU pour indiquer au serveur de quelle manière il lui expédiera des données en retour.
Dans les communications NVMe-over-TCP, il existe plusieurs types de PDU avec des informations propres au protocole et à son format de messages et de file indienne. Par ailleurs, chaque communication a toujours de flux de données : l’un pour envoyer les données, l’autre pour confirmer que l’échange s’est bien passé.
Les principaux fournisseurs : Lightbits Labs et Solarflare Communications
Les deux premiers fournisseurs à avoir implémenté NVMe-over-TCP dans leurs solutions sont Lightbits Labs et Solarflare Communications.
Lightbits Labs a choisi ce protocole, car il lui permet de proposer une solution de stockage élastique, où il suffit d’ajouter des tiroirs de disques à l’envi pour augmenter la capacité, sans néanmoins perdre en performances à chaque ajout d’un nouveau bloc. Et, avantage essentiel, ces blocs de stockage peuvent se situer à n’importe quel endroit du datacenter, sans que cela impacte le trafic réseau.
La solution de Solarflare offre les mêmes bénéfices que celle de Lightbits, mais le fournisseur produit sa propre carte accélératrice pour compenser les problèmes de latence et travaille avec SuperMicro pour proposer des appliances clés en main.