NVMe-over-Fabrics (NVMe-oF) : partagez vos SSD NVMe sur le réseau

Cela fait près de 20 ans qu'iSCSI existe, permettant d'accéder à un périphérique de stockage sur le réseau et de l'utiliser comme s'il était interne à la machine. Mais avec la montée en puissance des SSD et la généralisation des modèles PCIe, NVMe-oF le remplace peu à peu. Un mouvement accéléré par l'utilisation de TCP.

Lorsque l'on veut partager des données au sein d'un réseau local, on utilise un serveur NAS ou SAN. Ils peuvent exploiter différents protocoles, pour un accès sous la forme de stockage en blocs, fichiers ou objets.

Vos SSD PCIe/NVMe accessibles depuis le réseau

Si ce dernier est le plus flexible et le plus simple à prendre en main par les développeurs, le premier est le plus performant, tant en débit qu'en latence. Historiquement, il est mis en œuvre via iSCSI, qui encapsule des commandes SCSI dans un flux TCP/IP. Une solution efficace mais pensée pour des disques durs (HDD).

• DAS, NAS, SAN, stockage en blocs, fichiers ou objets : qu'est-ce que ça signifie ?
• Comment déporter le stockage de votre PC sur un NAS via iSCSI

Depuis 2011, les SSD exploitant une connectique PCI Express (Carte fille, M.2, U.2, etc.) ont droit à protocole spécifique : NVMe. Conçu pour profiter au maximum des performances de la flash NAND, il est débarrassé des commandes relatives aux HDD. Il a également été décliné pour un accès distant à travers la norme NVMe-over-Fabrics (NVMe-oF), initiée en 2014 et finalisée en 2016. Et elle aussi se répand désormais grâce à TCP.

NVMe 2.0 chamboule tout

Son principe est simple : permettre l'accès à des périphériques de stockage NVMe non pas via un lien PCIe mais réseau (fabric). Et donc des câbles de plusieurs dizaines ou centaines de mètres, des kilomètres ou même via Internet. 

Comme dans le cas d'iSCSI, elle permet de déporter le stockage dans un serveur, tout en l'utilisant comme un périphérique local, avec une latence de quelques dizaines de micro-secondes... et un débit pouvant atteindre plusieurs dizaines de Go/s. Des constructeurs se sont d'ailleurs spécialisés dans de telles solutions, assez coûteuses.

En cinq ans, cette norme a rapidement évolué, notamment pour être exploitée à travers différents « transports » nécessitant en général des cartes réseau et/ou switchs spécifiques, qu'il s'agisse du Fibre Channel (FC), ou Remote Direct Memory Access (RDMA). Outre la compatibilité avec InfiniBand, ce dernier a été décliné pour être plus facilement accessible via, RoCE (RDMA over Converged Ethernet) ou iWarp (Internet Wide Area RDMA Protocol).

Une pléthore qui a poussé le consortium NVMe au changement. Dans la version 2.0 de la norme, NVMe-oF n'est plus un complément à la « spec » de base. Tout ce qui touche au transport a été segmenté : PCIe, RDMA et TCP. Il en est de même pour l'interface de gestion ou les commandes (NVM, Key-Value, Zoned Namespace).

NVMe/TCP : digne remplaçant d'iSCSI

Si chaque implémentation de NVMe-oF dispose de ses avantages et ses inconvénients, aucun n'est largement exploitable. Dans un billet de blog publié en février 2019, Marvell indiquait ainsi que selon ses estimations, sur les 12 millions de cartes réseau à 10 Gb/s dans les datacenters de l'époque, moins de 5 % pouvaient exploiter RDMA.

En effet, même avec iWarp qui est le plus permissif, RDMA reste nécessaire. Une fonctionnalité qui n'est présente que sur une partie des cartes réseau du marché et pas toujours activé. C'est pour cela que le consortium et ses partenaires ont travaillé à une autre implémentation débarrassée de toute contrainte : NVMe sur TCP.

Cette fois, n'importe quelle machine est compatible. Il suffit de disposer de modules spécifiques actifs au sein du noyau Linux et de la couche logicielle qui va avec. Finalisée fin 2018, elle a rapidement fait l'objet d'une intégration native (depuis la branche 5.0). Mais on commence seulement à voir des distributions activer les modules par défaut.

Si on le trouve dans des appliances professionnelles, via des systèmes comme LightsOS ou HyperOS, il n'est pour le moment pas intégré aux NAS d'ASUSTOR, QNAP ou Synology, pas plus qu'à FreeNAS. Une absence d'autant plus étonnante qu'ils peuvent tout à fait se reposer principalement sur du stockage SSD.

Ce serait ainsi une manière intéressante de se démarquer de la concurrence. Même constat pour Windows. Pour le moment, Microsoft n'a pas intégré d'outil supportant nativement NVMe-oF en général ou NVMe/TCP en particulier.

Large compatibilité ou performances ?

La gestion se veut en partie similaire à iSCSI, qui était pour rappel une implémentation de SCSI sur TCP. Les IQN sont remplacés par des NQN (NVMe Qualified Name) pour désigner l'adresse des « targets », avec des méthodes d'accès et de découverte similaires. NVMe/TCP a l'inconvénient de son avantage : comme tout est géré de manière logicielle, le CPU doit encaisser la charge (là où il est contourné par RDMA, dont c'est le principe).

Mais en pratique, le niveau de débit et de latence proposés convient à la majorité des usages visés, bien qu'en retrait par rapport aux autres solutions. Ainsi, les implémentations via RDMA ou Fibre Channel de NVMe-oF répondent plutôt à des besoins spécifiques où la performance est critique, où le coût n'est pas le critère principal. NVMe/TCP permet pour sa part une implémentation plus générale et flexible, bien que moins performante.

Un « coût » à payer préférable pour beaucoup à celui du matériel compatible exigé par FC ou RDMA. Ceux qui cherchant des optimisations peuvent se tourner vers le Storage Performance Developer Kit (SPDK) d'Intel, un pilote dans l'espace utilisateur améliorant la gestion du stockage sur ses plateformes. Le constructeur met aussi en avant ses Application Device Queues (ADQ) pour booster les performances et réduire la variabilité de la latence.

Dans la suite de ce dossier, nous vous expliquerons comment partager un SSD sur votre réseau local à travers NVMe/TCP et profiter de connexions rapides et basse latence avec de la fibre, à 10 Gb/s ou même 25 Gb/s.