NVMe-over-Fabrics (NVMe-oF) : partagez vos SSD NVMe sur le réseau
Adieu iSCSI !
Le 14 septembre 2021 à 09h36
6 min
Hardware
Hardware
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.
NVMe-over-Fabrics (NVMe-oF) : partagez vos SSD NVMe sur le réseau
-
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 ?
Commentaires (21)
Vous devez être abonné pour pouvoir commenter.
Déjà abonné ? Se connecter
Abonnez-vousLe 14/09/2021 à 10h29
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)
Le 14/09/2021 à 10h49
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.
Le 14/09/2021 à 11h14
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.
Le 14/09/2021 à 11h44
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 ?
Le 14/09/2021 à 11h46
pour compléter tout ce qui est dit, le choix entre iSCSI et SMB se fait selon l’utilisation finale :
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.
Le 14/09/2021 à 11h47
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.
Le 14/09/2021 à 12h09
merci pour la clarification, je visualise mieux moi aussi du coup :)
Le 14/09/2021 à 12h23
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
Le 14/09/2021 à 12h26
Merci pour l’explication
Le 14/09/2021 à 16h20
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.
Le 14/09/2021 à 16h41
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.
Le 15/09/2021 à 06h57
[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é.
Le 15/09/2021 à 07h43
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
Le 15/09/2021 à 08h34
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.
Le 15/09/2021 à 08h36
2010 pour NFSv4.1. Ce n’est pas si vieux.
Le 15/09/2021 à 09h31
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…
Le 15/09/2021 à 11h58
C’était sur de l’ESX 6.5, DS1513+ puis DS2015xs, je dirais il y a environ 3-4 ans de mémoire.
Le 15/09/2021 à 17h11
très intéressant, et les commentaires apportent aussi pas mal d’infos. Merci à tous
Le 16/09/2021 à 19h27
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
Le 17/09/2021 à 04h01
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.
Le 17/09/2021 à 06h18
Par rapport au commentaire de “@erw_da” ? Peut-être oui
Après tout cela se mélange, on a bien du NAS+SAN (fonctionnalités SMB/iSCSI donc) dans Windows Server 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 !