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

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

Adieu iSCSI !

Avatar de l'auteur

David Legrand

Publié dansHardware

14/09/2021
21
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).

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 2.0 Spec

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.

NVMe over Fabrics
Crédits : Micron

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.

NVMe over Fabrics
Crédits : Marvell

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.

21
Avatar de l'auteur

Écrit par David Legrand

Tiens, en parlant de ça :

Un Sébastien transformé en lapin par Flock pour imiter le Quoi de neuf Docteur des Looney Tunes

Quoi de neuf à la rédac’ #10 : nous contacter et résumé de la semaine

On est déjà à la V2 de Next ?

11:55 2
Autoportrait Sébastien

[Autoportrait] Sébastien Gavois : tribulations d’un pigiste devenu rédac’ chef

Me voilà à poil sur Internet

17:18 Next 15
Logo de StreetPress

Pourquoi le site du média StreetPress a été momentanément inaccessible

Incitation à la LCEN

16:41 Droit 9

Sommaire de l'article

Introduction

Vos SSD PCIe/NVMe accessibles depuis le réseau

NVMe 2.0 chamboule tout

NVMe/TCP : digne remplaçant d'iSCSI

Large compatibilité ou performances ?

Un Sébastien transformé en lapin par Flock pour imiter le Quoi de neuf Docteur des Looney Tunes

Quoi de neuf à la rédac’ #10 : nous contacter et résumé de la semaine

2
Autoportrait Sébastien

[Autoportrait] Sébastien Gavois : tribulations d’un pigiste devenu rédac’ chef

Next 15
Logo de StreetPress

Pourquoi le site du média StreetPress a été momentanément inaccessible

Droit 9
Amazon re:Invent

re:Invent 2023 : Amazon lance son assistant Q et plusieurs services IA, dont la génération d’images

IA 10
Un œil symbolisant l'Union européenne, et les dissensions et problèmes afférents

Le Conseil de l’UE tire un bilan du RGPD, les États membres réclament des « outils pratiques »

Droit 4

19 associations européennes de consommateurs portent plainte contre Meta

DroitSocials 13

#LeBrief : Ariane 6 l’été prochain, Nextcloud rachète Roundcube, désinformation via la pub

Chiffre et formules mathématiques sur un tableau

CVSS 4.0 : dur, dur, d’être un expert !

Sécu 7
Une tête de fusée siglée Starlink.

Starlink accessible à Gaza sous contrôle de l’administration israélienne

Web 34
Fibre optique

G-PON, XGS-PON et 50G-PON : jusqu’à 50 Gb/s en fibre optique

HardWeb 48
Photo d'un immeuble troué de part en part

Règlement sur la cyber-résilience : les instances européennes en passe de conclure un accord

DroitSécu 10
lexique IA parodie

AGI, GPAI, modèles de fondation… de quoi on parle ?

IA 7

#LeBrief : logiciels libres scientifiques, fermeture de compte Google, « fabriquer » des femmes pour l’inclusion

livre dématérialisé

Des chercheurs ont élaboré une technique d’extraction des données d’entrainement de ChatGPT

IAScience 3
Un chien avec des lunettes apprend sur une tablette

Devenir expert en sécurité informatique en 3 clics

Sécu 11
Logo ownCloud

ownCloud : faille béante dans les déploiements conteneurisés utilisant graphapi

Sécu 16
Le SoC Graviton4 d’Amazon AWS posé sur une table

Amazon re:invent : SoC Graviton4 (Arm), instance R8g et Trainium2 pour l’IA

Hard 12
Logo Comcybergend

Guéguerre des polices dans le cyber (OFAC et ComCyberMi)

Sécu 10

#LeBrief : faille 0-day dans Chrome, smartphones à Hong Kong, 25 ans de la Dreamcast

Mur d’OVHcloud à Roubaix, avec le logo OVHcloud

OVHcloud Summit 2023 : SecNumCloud, IA et Local Zones

HardWeb 2
algorithmes de la CAF

Transparence, discriminations : les questions soulevées par l’algorithme de la CAF

IASociété 62

Plainte contre l’alternative paiement ou publicité comportementale de Meta

DroitIA 38
Nuage (pour le cloud) avec de la foudre

Économie de la donnée et services de cloud : l’Arcep renforce ses troupes

DroitWeb 0
De vieux ciseaux posés sur une surface en bois

Plus de 60 % des demandes de suppression reçues par Google émanent de Russie

Société 7
Une vieille boussole posée sur un plan en bois

La Commission européenne et Google proposent deux bases de données de fact-checks

DroitWeb 3

#LeBrief : des fichiers Google Drive disparaissent, FreeBSD 14, caméras camouflées, OnePlus 12

Le poing Dev – round 6

Next 151

Produits dangereux sur le web : nouvelles obligations en vue pour les marketplaces

Droit 9
consommation de l'ia

Usages et frugalité : quelle place pour les IA dans la société de demain ?

IA 12

La NASA établit une liaison laser à 16 millions de km, les essais continuent

Science 17
Concept de CPU

Semi-conducteurs : un important accord entre l’Europe et l’Inde

Hard 7

#LeBrief : PS5 Slim en France, Valeo porte plainte contre NVIDIA, pertes publicitaires X/Twitter

Un mélange entre une réunion d’Anonymous et de tête d’ampoules, pour le meilleur et le pire

651e édition des LIDD : Liens Intelligents Du Dimanche

Web 30
next n'a pas de brief le week-end

Le Brief ne travaille pas le week-end.
C'est dur, mais c'est comme ça.
Allez donc dans une forêt lointaine,
Éloignez-vous de ce clavier pour une fois !

Commentaires (21)


SomeDudeOnTheInternet Abonné
Il y a 2 ans

Quelle différences concrètes y-a-t-il entre iSCSI et Samba ? Je comprends bien que Samba fonctionne avec un couple client/serveur et des points de montage alors qu’iSCSI et NVMe-oF profitent d’une intégration plus “bas niveau” en considérant le disque comme interne, mais y a-t-il des différences au niveau des performances, de la gestion des erreurs, etc. ?



Est-ce que c’est intéressant d’utiliser ce genre de système dans un NAS maison par rapport à Samba par exemple ? (lorsque ça sera supporté à grande échelle)


David_L Abonné
Il y a 2 ans

Comme dit en intro et dans les papiers consacrés au sujet, ces deux solutions n’ont rien à voir. Via iSCSI, tu envoies des commandes SCSI à ton périphérique de stockage qui est géré en mode bloc (il est vu par le client comme un périphérique local même s’il est distant). C’est utilisé pour donner accès à un périphérique depuis un client (unique, même si du multi-accès peut être mis en place). Le formatage et l’accès aux données se fait côté client pas serveur.



Samba/CIFS c’est un protocole de partage sur le réseau en mode fichiers. Cela vient par dessus le montage du HDD/SSD, son partitionnement et le système de fichier qui se font côté serveur avec un protocole réseau spécifique et tout l’overhead que ça comporte. C’est fait pour que plusieurs personnes puissent accéder à un même espace de stockage à distance via un protocole réseau largement disponible.



Pour faire simple : dans un cas tu partages le HDD/SSD (ou une portion), dans l’autre un dossier. iSCSI ou NVMe/TCP sont intéressants quand tu as besoins de performances et de monter un périphérique dans son ensemble avec un fonctionnement presque natif. Les NAS gèrent d’ailleurs tous iSCSI depuis longtemps.


erw_da Abonné
Il y a 2 ans

iSCSI c’est du SAN, pas du NAS : la différence est que en SAN, le serveur (qu’on appelle alors TARGET) met à disposition un espace, et c’est le client (qu’on appelle initiateur) qui l’utilise comme il le veut, mets le file system qu’il veut grosso modo ça donne un périphérique de type block, comme un disque vierge, non formatté.
En NAS le serveur donne accès à un de ses systèmes de ficher locaux.


SuXiNeTTe Abonné
Il y a 2 ans

Je n’ai pas bien compris la différence qu’il peut y avoir entre le FCoe et le NVMe-oF.
Seulement la suppression des commandes liées aux plateaux ?


Soraphirot
Il y a 2 ans

pour compléter tout ce qui est dit, le choix entre iSCSI et SMB se fait selon l’utilisation finale :




  • SMB permet des connexions multiples et gère les droits utilisateurs finement. Pratique pour un partage classique mais s’en ressent niveau perfs car le serveur doit tout surveiller pour chaque fichier que l’on manipule

  • iSCSI donne un “disque dur” vide à un autre ordinateur, qui va pouvoir faire ce qu’il en veut, le serveur (target) ISCSI n’en ayant cure. De ce fait compliqué à partager mais comme le protocole envoie directement des blocs de data au lieu de fichiers les perfs explosent*.



Du coup le mieux à faire c’est :
accès réservé à un ordinateur pour déporter son stockage > iSCSI
accès partagé entre plusieurs personnes, sur des fichiers privés ou publics > SMB



*Pour donner un ordre d’idée, j’ai deux machines dont une dédiée au stockage. l’ancien partage machine-machine était en SMB/NFS et tournait à ~80Mo/s. J’ai tout refait et mis du iSCSI, ça tourne maintenant à +120Mo/s.


David_L Abonné
Il y a 2 ans

FCoE c’est pour faire passer du Fibre Channel dans un lien Ethernet (ce qu’il n’est pas à la base). NVMe-oF c’est pour faire passer des commandes NVMe sur un réseau (rien à voir entre les deux, donc). Comme dit dans l’article, NVMe-oF peut utiliser du Fibre Channel comme transport.



Pour rappel, Fibre Channel c’est un protocole réseau différent d’Ehternet (nécessitant donc du matériel dédié) pour du SAN à gros débit qui permet donc de transporter des blocs de données. Initialement c’était pour du SCSI (Fibre Channel Protocol), ou du NMVe comme évoqué ici.


fry Abonné
Il y a 2 ans

merci pour la clarification, je visualise mieux moi aussi du coup :)


vexal Abonné
Il y a 2 ans

Merci David pour cet article très complet ! top, comme toujours.
J’en profite pour dire que je suis content que la promesse d’utiliser les abonnements pour produire de vrais articles de qualité (et pas pour survoler les sujets comme les autres sites) est respectée. Merci :yes:


SomeDudeOnTheInternet Abonné
Il y a 2 ans

Merci pour l’explication :chinois:


neod Abonné
Il y a 2 ans

Soraphirot a dit:


*Pour donner un ordre d’idée, j’ai deux machines dont une dédiée au stockage. l’ancien partage machine-machine était en SMB/NFS et tournait à ~80Mo/s. J’ai tout refait et mis du iSCSI, ça tourne maintenant à +120Mo/s.




D’après mes tests sur un NAS avec des HDD, sans raid et avec un lien réseau en 1Gbps cuivre, j’avais surtout un gain au niveau débit et I/O en lecture/écritures aléatoire 4k (Q32T1) sous crystal disk mark en iSCSI par rapport a SMB.
Mon débit séquentiel était coincé au maximum du lien réseau vers 120 Mo/s , dans les deux cas.


David_L Abonné
Il y a 2 ans

Oui même en SMB/CIFS tu peux taper la limite du réseau, on le fait régulièrement. Mais effectivement c’est moins efficace sur certains aspects (de toutes façons rien que le fait d’envoyer des commandes directes au périphérique en soi…). Surtout qu’un partage réseau n’est pas géré par le système et les applications qu’un périphérique de stockage local/distant. Du coup ça ouvre aussi des portes différentes à ce niveau.


Arona Abonné
Il y a 2 ans

[3615 Ma vie]
Sur les Synology au boulot, on a basculé de iSCSI vers des partages NFS pour justement gagner en performance… (on était passé de ~40Mo/s à du 80-100Mo/s). Apparemment la couche de gestion iSCSI sur les Synology étaient vraiment bof il y a quelques années. Ils auraient bossé dessus depuis mais on a pas retenté.


David_L Abonné
Il y a 2 ans

C’est étonnant parce que j’ai plutôt de bonnes perfs en iSCSI. Après sans précisions sur les modèles ou la période, difficile de voir ce qu’il en est. Après NFS est pratique, mais c’est pas le protocole le plus récent :transpi:


Mace8419
Il y a 2 ans

Pas seulement sur Synology.
j’avais fait un montage iSCSI (en 2010) sur des disques durs en RAID5 sur un NAS HPE de mémoire.
Ca permettait d’activer la compression Windows sur des fichiers binaires qui permettait de gagner pas mal de volumétrie.
En revanche, on avait aussi des erreurs d’écriture lors d’accès aléatoires et on jamais su pourquoi.
Bref, en revenant à un montage SMB classique, plus de souci, et perf identiques.


alex.d. Abonné
Il y a 2 ans

David_L a dit:


Après NFS est pratique, mais c’est pas le protocole le plus récent :transpi:




2010 pour NFSv4.1. Ce n’est pas si vieux.


Fab'z Abonné
Il y a 2 ans

C’était vrai pendant un temps je crois. Le SCSI était mal géré, surtout avec des jumbo frames. Mais c’était il y a au moins 5 ans je dirais.



Depuis j’ai bien réussi à attendre les chiffres annoncés par Syno avec un 1621+.



Il ont forcément corrigé le soucis, maintenant que certains de leurs modèles sont des baies SAN avant d’être des NAS. Enfin en théorie…


Arona Abonné
Il y a 2 ans

(reply:60025:Fab’z)




C’était sur de l’ESX 6.5, DS1513+ puis DS2015xs, je dirais il y a environ 3-4 ans de mémoire.


paskal441
Il y a 2 ans

très intéressant, et les commentaires apportent aussi pas mal d’infos. Merci à tous


Ribibi Abonné
Il y a 2 ans

Oui, enfin, bon… Un NAS a aussi la possibilité de proposer un espace iSCSI dédié, pour des données non partagées !! Je dispose de cela depuis longtemps sur des serveurs de virtualisation pour du backup de VM par exemple.
Et idem chez moi, mes VM sont posée sur mon QNAP en SCSI, qui dispose de stockages en SSD/SATA.



Après, les SAN haut-de-gammes ont aussi la possibilité de gérer des espaces de données partagées comme des NAS, avec des algorithmes de gestion des données dédiés.



Ces matériels ne sont plus aussi cloisonnés en fonctionnalités qu’en 1995 ;p


David_L Abonné
Il y a 2 ans

Tu confonds les produits qu’on appelle communément NAS et SAN avec les fonctions NAS et SAN semble-t-il. Quand tu prends un produits QNAP/Synology et que tu y utilises iSCSI, tu fais du SAN. Quand tu utilises SMB/CIFS, tu fais du NAS. Comme dit, la différence fondamentale est le type de partage (bloc/fichiers) entre ces deux protocoles, et donc l’endroit où est géré le système de fichiers.


Ribibi Abonné
Il y a 2 ans

Par rapport au commentaire de “@erw_da” ? Peut-être oui :windu:
Après tout cela se mélange, on a bien du NAS+SAN (fonctionnalités SMB/iSCSI donc) dans Windows Server :mad2: C’est bien plus léger en fonctions, on est d’accord.
Pas user friendly pour des partages massifs entre utilisateurs, mais pour du backup, ça passe très bien !:yes: