Dans le cadre de nos articles sur NVMe-oF nous avons vu comment partager un SSD PCIe sur le réseau local. Mais peut-on y accéder via un simple Raspberry Pi et NVMe/TCP ? Nous avons tenté notre chance.
Si le protocole iSCSI est connu et répandu, il est peu à peu remplacé dans les entreprises par le NVMe-over-Fabrics (NVMe-oF). La montée en puissance du NVMe/TCP facilite encore un peu plus les choses, permettant de mettre à disposition un SSD PCIe à travers un réseau sans nécessiter le moindre matériel spécifique. C'est accessible à tous.
NVMe/TCP sur un Rapberry Pi : parce que pourquoi pas ?
Comme nous l'avons vu dans un précédent article, on peut ainsi créer une solution client/serveur assez simplement, les distributions Linux grand public gérant désormais nativement une telle fonctionnalité. Mais est-ce qu'il est possible de pousser le processus à l'extrême pour par exemple compléter le stockage réduit d'un simple Raspberry Pi ?
Pour le savoir, nous avons tenté de lui adjoindre plusieurs SSD PCIe à travers le réseau.
Pour nos tests, nous avons utilisé un Raspberry Pi 400, tout d'abord installé sous Raspbery Pi OS. Comme on pouvait s'y attendre, les modules NVMe/TCP n'étaient pas présents au sein du noyau, obligeant à une compilation spécifique. Nous avons donc opté pour une autre solution : y installer Ubuntu 21.04 Desktop (64 bits).
Cette fois, sans surprise, les modules étaient bien présents :
davlgd@Pi400:~$ cat /boot/config-`uname -r` | grep NVME_
CONFIG_NVME_CORE=y
# CONFIG_NVME_MULTIPATH is not set
CONFIG_NVME_HWMON=y
CONFIG_NVME_FABRICS=m
CONFIG_NVME_RDMA=m
CONFIG_NVME_FC=m
CONFIG_NVME_TCP=m
CONFIG_NVME_TARGET=m
CONFIG_NVME_TARGET_PASSTHRU=y
CONFIG_NVME_TARGET_LOOP=m
CONFIG_NVME_TARGET_RDMA=m
CONFIG_NVME_TARGET_FC=m
# CONFIG_NVME_TARGET_FCLOOP is not set
CONFIG_NVME_TARGET_TCP=m
Ajouter des SSD NVMe en quelques minutes
Nous avons donc simplement installé les outils NVMe :
sudo apt update && sudo apt install nvme-cli
On peut alors découvrir ceux proposés par les deux serveurs NVMe de notre réseau :
sudo modprobe nvme
sudo modprobe nvme-tcp
sudo nvme discover -t tcp -a 192.168.0.42 -s 4420
sudo nvme discover -t tcp -a 192.168.0.82 -s 4420
Puis ajouter les trois SSD qu'ils mettent à notre disposition :
sudo nvme connect -t tcp -a 192.168.0.42 -s 4420 -n nvme.server.0n1
sudo nvme connect -t tcp -a 192.168.0.82 -s 4420 -n nvme.server.1n1
sudo nvme connect -t tcp -a 192.168.0.82 -s 4420 -n nvme.server.2n1
Ils sont alors accessibles via l'outil de gestion des disques. On peut les formater, les monter et pourquoi pas les monter en RAID. Même s'ils sont issus de serveurs différents. L'avantage d'une telle solution, c'est que si un serveur est défaillant, c'est comme si un ou plusieurs membres du RAID l'étaient, on peut donc assurer un certain niveau de protection et de redondance à travers différents serveurs.
3 SSD PCIe dans un Raspberry Pi 400, c'est possible (via TCP)
Quelles performances ?
Bien entendu, un Raspberry Pi, même de dernière génération, limite le débit à 1 Gb/s. Mais c'est souvent mieux que la carte microSD interne par exemple. Dans notre cas on obtient le résultat suivant avec ioping sans cache (-D) :
ioping -s 16M -c 16 -D .
15 requests completed in 5.50 s, 240 MiB read, 2 iops, 43.6 MiB/s
Si l'on fait le même test avec un Crucial P5 Plus de 500 Go via NVMe/TCP :
sudo ioping -s 16M -c 16 -D /dev/nvme0n1
15 requests completed in 2.60 s, 240 MiB read, 5 iops, 92.4 MiB/s
Bien entendu, on aura de meilleurs débits avec un SSD PCIe dans un boîtier USB 3.x, mais on sera alors limité par le nombre de ports, cela augmentera la consommation locale du Raspberry Pi et on n'aura pas la même souplesse pour la création de gros volumes RAID par exemple. N'oubliez d'ailleurs pas que l'accès TCP ne se limite pas forcément au réseau local, on peut aussi le faire via Internet (pensez alors à utiliser un chiffrement TLS).
Un test du temps d'accès (ioping -R) nous donne le résultat suivant :
- Carte SD locale : 431.7 µs
- SSD NVMe/TCP : 500.1 µs
Commentaires (38)
#1
mwahaha, j’adore ce genre de test assez improbable, merci David :)
maintenant la question, est-ce qu’un pi (4) peut faire office de serveur en lui collant 2 ssd en usb ?
sauf que l’utilité du nvme-of c’est de regrouper sur une seule machine les disque de plusieurs clients différents et chacun sera isolé des autres, ça permet pas d’avoir plusieurs clients qui accèdent au même disque (en résumé de ce que j’en ai compris) donc l’utilité d’avoir un pi en tant que serveur me semble discutable, ou en tout cas je vois pas de cas d’utilisation pour lequel ce serait la solution parfaite :s
#2
C’est de l’USB, donc non ;) Après ça doit être possible de bidouiller ça en iSCSI ou NVMe/TCP quand même, m’enfin on perf l’intérêt du côté “commandes envoyées en direct via TCP” (mais il y a des solutions d’USB/TCP de mémoire).
Méfions nous de ce genre de formule
C’est du block storage, donc le principe c’est un serveur partage un périphérique sur le réseau et des clients s’y connectent. Tehniquement, tu peux avoir plusieurs clients qui montent un même périphérique NVMe-oF, mais en cas de conflit… il faudrait que je regarde dans le détail s’il y a des mécaniques pour éviter les soucis (comme cela peut exister avec iSCSI), mais ce n’est pas l’usage idéal.
#3
Pas mal de problème en USB sur les RPI selon les chip UAS sur les boitiers/adaptateurs malheureusement …
#4
Du coup le Pi400 avec une carte réseaux usb 2,5Gb/s ou 5Gb/s ça donne quoi? :)
#5
J’ai une petite question sur le cas d’usage du nvme-of.
Le partage de périphérique se faire directement? C’est à dire, 1 SSD nvme = 1 partage?
Ou on peut faire un partage en raidx?
De même peut-on découper un SSD en sous-volume pour un partage 1 SSD = N partage?
Super articles en tout cas, je connaissait pas nvme-of, c’est sympa comme techno, merci! :)
#6
effectivement ma formule était un peu à l’emporte pièce
donc “l’un des gros point fort du nvme-of c’est qu’il permet de concentrer les périph’ de stockage sur une seule machine pour avoir une densité de stockage importante et donc une efficacité énergétique plus intéressante, tout en permettant d’avoir des clients légers avec quand même un espace de stockage important”
yep, ça m’étonne pas qu’il puisse être possible dans l’absolu que plusieurs clients utilisent le même périphérique, et ça m’étonne encore moins qu’il y ait de grandes chances de corruption XD
yep trouver un bon boitier qui fonctionne parfaitement c’est pas forcément simple car la puce sata (ou pcie) vers usb n’est pas toujours indiquée :(
un truc assez simple à constater c’est le smart, si on peut pas lire les infos smart d’un disque usb sous linux, c’est mauvais signe, du moins c’est ce que je regarde (ça veut pas dire que si on lit le smart tout va bien, mais au moins la puce est reconnue et certaines commandes standard peuvent passer)
#7
ça va 2,5x plus vite ;)
Je peux répondre aux questions, mais il faudrait un minimum lire les articles pour éviter de tout me faire répéter, là tout ce qui est demandé est déjà traité dans les sujets NVMe/TCP
Oui, c’est le principe du block storage
Oui, comme montré dans cet article
Ca n’a pas de sens, le RAID se fait par dessus le périphérique. Comme dit dans l’article, on peut monter un RAID depuis des SSD auxquels on se connecte en NVMe/TCP
On appelle ça créeer différentes partitions ;) Si tu veux partager de manière indépendante différents volumes d’un même périphérique comme on le fait en iSCSI via les LUN je n’ai pas creusé le sujet
#8
Les ports USB sont liés à un bus PCI-Express Gen2 sur 2 lignes donc maximum 4Gbps.
Donc avec un adaptateur 2.5 GBe, ça marche, mais 2 adapteurs ou 1 @5Gbps, ça sera limité.
Source: https://www.raspberrypi.org/blog/raspberry-pi-4-on-sale-now-from-35/
#9
et
Il me semble que la façon la plus adapté à ce besoin soit le “Multi-Tenancy” des espaces de noms NVMe : https://nvmexpress.org/resources/nvm-express-technology-features/nvme-namespaces/
#10
Oui je connaissais les limites. Sachant que si on prend l’adaptateur Qnap QNA-UC5G1T 5Gbp/s il est aussi limité par sa conception en USB 3.1 Gen1 5Gb/s. lien
Ce qui est bien c’est qu’on dépasse tranquillement le 1Gbp/s par contre quand on arrive sur du multi-gig il faut que les postes interconnectés suivent au niveaux des performances. Et puis les contraintes de protocoles choisis/imposés selon les usages diminuent les performances atteintes lors de tests!
J’aurais bien fait les tests mais il me manquent des disques nvme et surtout une carte mère/fille permettant de placer plus que 2 nvme dans le poste!
#11
Oui, quand le SSD le gère
Oui et le support Linux des adaptateurs USB/Multi-Gig est pas toujours fameux. Mais ne vous inquiétez pas, on parle bientôt de solutions à plus de 1 Gb/s
#12
C’est pour quand ???
#13
When it’s done ;)
#14
Il n’y a pas moyen de faire ce type de montage avec un composant moins chère qu’un Raspberry Pi, comme un arduino, et de faire un raid via le réseau avec des SSD connecté presque en direct sur le réseau ?
#15
euh, le “moins cher qu’un pi”, c’est pour le “serveur” qui va contenir le vrai ssd, ou pour le “client” qui doit l’utiliser ?
dans les 2 cas, je vois pas quel composant moins cher qu’un pi est capable de traiter un système de fichier, sans parler de la puissance nécessaire pour gérer le débit du ssd (y’a des “shield arduino” pour écrire sur carte sd, mais question débit un ssd en nvme-of ne sera jamais exploité à sa juste valeur, d’où mon interrogation)
#16
Pour le côté serveur de fichier : le serveur n’a pas grand chose à traiter, juste de la sécurité + la gestion des données en direct si j’ai bien compris l’intérêt du protocole.
On pourrait imaginer plusieurs SSD sur plusieurs serveur très bas coût, connecté à un réseau et monté en RAID pour augmenter les performances, avec seulement le client en 10G ethernet, les serveurs seulement en 1G ethernet.
J’ai cherché un peu et il semblerait que ça existe pour l’industrie, mais est-ce qu’on peut avoir la même chose pour particulier en bidouillant, comme le thème du dossier ??
#17
Merci de la réponse
Je faisait pas mal le parallèle dans ma tête avec les partages ISCSI ou les raid hardware avec un block device directement monté. Du coup je me suis un peu tout embrouillé dans ma tête.
Par contre les info qu’a remonté NSACloudBackup sont intéressante, si on peut faire du multi-tenancy sur un seul SSD ça ouvre la voie à des systèmes bien pratique. Encore faut-il que ce soit supporté comme tu le dit.
Pour l’instant on est un peu limité à des utilisation du type X client léger pour une session ou du read-only, je n’y vois pas trop d’intérêt pour un usage perso/homelab.
#18
Bah déporter du stockage en 10G par exemple sans les contraintes du iSCSI (qui n’est pas trop fait pour du NVMe) et profiter à plein des SSD. Comme j’ai pu mettre sur Twitter j’ai par exemple monté des SSD PCIe en RAID dans mon Proxmox sur le serveur (25G) qui n’avait pas de SSD internes (juste deux HDD SAS). Après l’outil est là : si on en a besoin tant mieux, sinon c’est pas grave
#19
ok pour le serveur donc
je préférais être sûr de ce que tu disais :)
j’ai de sérieux doutes sur l’existence de puces adaptées : faut quand même gérer un minimum de sécurité comme tu l’indiquais, bien plus costaud qu’un arduino sur ce point (déjà que je suis pas certain qu’un esp8266 s’en sorte avec du ssl …), donc lui faire gérer en plus du transfert de données >= 1Gb/s …
rien que des boîtiers usb3 qui n’ont pas à gérer la partie ethernet / sécurité sont facilement à 30€ …
techniquement ça doit être faisable, avec en prime du poe :p, mais je doute sérieusement que ce soit trouvable “pas cher” (au pif si un tel montage ultra réduit se trouve ça va être un truc de niche vendu au prix de 2 ou 3 pi :s)
edit : aération :)
#20
C’est surtout que NVMe/TCP, tout est software et côté CPU, donc il faut pouvoir encaisser. Certaines cartes réseau offload TCP, Intel a SPDK pour mieux gérer la charge, mais ça n’est pas anodin côté serveur.
#21
Je pensais que tout étais du côté du client, et pas du serveur, j’ai mal compris ?
Pour un boitier USB3, c’est bien pour un SSD mais si on veut faire du RAID c’est plus compliqué de trouver des boitiers avec beaucoup de disque possible…
#22
Tu as du TCP (et donc de la charge) des deux côtés, forcément. Mais là on parlait d’un appareil minimal pour partager des SSD NVMe, je précisais que le CPU utilisé ne pouvait pas être trop léger.
Des boîtiers avec plein d’emplacements et du réseau ça existe : SAN et NAS
Mais pour le moment, les constructeurs sont assez frileux sur NVMe/TCP (et préfèrent Fibre Channel sur le pro parce que ça vend des composants assez chers, c’est toujours ça de gagné 
). Mais ça viendra, forcément.
#23
Ça existe et ça s’appelle un NAS. Ça ne sera jamais moins cher qu’un Raspberry Pi car on est déjà limite niveau performance avec ce genre d’appareil donc un arduino je pense qu’on peut rêver.
En vrai je ne vois aucun intérêt à proposer un produit si limité. Les professionnels qui veulent faire du NVMe-oF ou iSCSI le font pour :
Une solution à minima ne leur apporterait rien de tout ça. Reste le grand public, là encore pourquoi faire ? Ces protocoles ne sont pas pensé pour leur utilisation :
Il reste l’option du bidouilleur pour prouver que c’est faisable. Mouif.
#24
Je pensais naïvement à des disques à brancher en direct sur de l’ethernet, avec une possibilité d’upgrade et de mise à jour assez simple, sans avoir besoin d’un boitier de NAS délirant. Ça permettrais de faire séparer la partie calcul/outil de la partie stockage sur un NAS, je trouve l’idée pas mal.
Je vais regarder ce qui peut supporter une pile TCP en très faible puissance/consommation
#25
Disons que ça n’existe jamais “branché en direct sur”. Quand tu as un SSD M.2 dans un boîtier USB il y a un composant pour gérer la conversion de protocole. Ici c’est la même chose. Après on peut espérer voir des constructeurs plancher sur une puce NVMe/TCP hardware (c’est le rôle des TPU dans le domaine du réseau), mais ça n’est pas franchement de la puce à 0.5$ pour du boîtier ultra compact.
Ce que tu évoques c’est ce que l’on appelle la désagrégation du stockage dans les datacenters, avec effectivement une séparation stockage/compute. Mais on est loin d’un truc anodin. Rien que dans le cas de la solution de Kalray que j’évoquais ce matin, on parle de traiter 2 MIOPS et 12 Go/s pour du réeau 2x 100G, on ne fait pas ça avec un RPi, un arduino ou un contrôleur cheap consommant 1W.
PS : un NAS est déjà fait pour séparer le stockage du reste. Les constructeur leur font calculer des trucs pour justifier des modèles coûteux, mais ce n’est pas leur rôle au départ, c’est la tendance à l’hyperconvergence qui a poussé vers ça, on en revient justement avec les solutions de désagrégation.
#26
Oui, sauf que les NAS faibles puissances ont des limites fortes en termes de disques dur, si le but est juste de partager sur le réseau des dossiers c’est mort… ou il faut passer par un boitier usb multi-disque, ce qui rajoute aussi une couche.
#27
Et aussi parce-que le FC c’est perf, fiable, robuste et simple à exploiter et que malgré le ticket d’entrée un peu plus élevé, on s’y retrouve vite. D’ailleurs, à voir si le NVMe/TCP suit le même chemin ou pas que le FCoE dont tout le monde disait que c’était l’avenir et… ben dont plus personne ne veut quasiment
Le seul défaut du FC, c’est que la gestion est vraiment pas géniale côté Proxmox, Xen, etc (ce dernier s’en sort à peu près mais bon, on est très loin de VMware Vsphere pour ça).
D’ailleurs, si tu veux te monter un SAN avec pas mal de protocoles ‘exotiques’ si on peut dire, je te conseille ESOS (https://www.esos-project.com/). C’est moche, pas super intuitif mais c’est le seul où j’ai pu construire un réseau full FC correct et qui tienne la route pour du Labs !
#28
Je comprends pas le “limites fortes en termes de disques durs”
Comme dit dans le dossier dédié, c’est vrai et faux à la fois. Disons que ça dépend du besoin. Quand tu te moques de la facture, c’est le bon choix. Sinon tu vas voir ailleurs (c’est aussi pour ça que RoCE/iWarp ont été créés d’ailleurs, puis NVMe/TCP).
L’avantage de /TCP c’est d’ailleurs de pouvoir migrer une infrastructure existante sans avoir à tout changer. Et les constructeurs de NAS pourraient proposer du NVMe/FC ou /TCP selon l’équipement, mais ne misent que sur le premier. C’est peut être aussi que leur intérêt est ailleurs ;)
C’est surtout que RoCE a plus d’avantages que FCoE pour le but visé non ?
#29
Le mécanisme n’existe pas en iscsi. C’est le système d’accès qui gère la collocation du stockage entre plusieurs hôtes. Sous vmware, c’est le système de fichiers de la partition qui gère, sous Windows c’est le rôle clustering avec le csvfs (si je ne me trompe pas dans l’acronyme) etc.
#30
Je me demande d’ailleurs ce que ça donne avec des cartes réseaux rdma. Je sais qu’il peut y avoir des gains de cons avec ces cartes quand on fait du stockage partagé (coucou Windows storage spaces direct)
#31
Je veux dire en terme de nombre de disque dur intégré dans le NAS :
Lorsque j’avais cherché je n’ai pas trouvé de NAS peu puissant avec plein de disque dur possible, et si possible pour pas trop chère.
La je verrais comme idée une séparation entre le nombre de SSD et la puissance du NAS.
#32
Parce que gérer plusieurs disques durs en même temps demande justement de la puissance, pour pouvoir gérer correctement la quantité d’I/O qu’est amené à supporter ce genre de solution.
#33
haha à la fin de l’article en voyant “le premier SSD au monde à disposer d’une interface NVMe-oF (Ethernet) native” je me suis dit que ça tombait pile sur nos échanges
mais après j’ai vu “On peut aussi se demander si de telles initiatives pourraient voir le jour en NVMe/TCP” et j’ai percuté que j’avais pas bien lu :s
#34
Oui après attention ce sont des SSD pour datacenter. Un SSD de ce type + contrôleur RoCE v2 25G pour une connexion dans une baie 600G, ça va vite coûter le prix d’un PC grand public complet ;) Rien que les cartes avec DPU de NVIDIA c’est dans les 2K$ pour rappel (et y’a pas les SSD
)
#35
C’est sûr que si tu as déjà une infrastructure correcte en TCP cela peut-être un avantage, après il faut voir l’ancienneté du matériel et s’il va tenir ce que l’on peut attendre d’un réseau stockage basé sur le NVMe. Je viens de regarder et la différence de prix (je me suis basé sur quelques tarifs publics pour du Cisco en Nexus 5x et 9x et sur du Brocade en 65xx et G6xx) n’est plus si énorme que ça même en comptant les HBAs. C’est donc un choix pragmatique à faire selon l’Infra dispo on peut dire ;)
Pour le RoCE/iWarp que je ne connaissais pas plus que ça, j’ai regardé et en effet c’est pas mal du tout mais à priori, la v1 du RoCE semble avoir moins de chances de prendre et la v2 est un dérivé de l’Infiniband de ce que j’en ai compris, très bonne techno souvent oubliée (et surtout utilisée en backbone des équipements grâce à ses perfs) mais qui nécessite des équipements adéquats à priori ! (D’ailleurs, toute la partie ‘TCP/IP’ est supprimée sur la v2 pour éviter latences et autres complications)
Quelques articles que tu as déjà dû voir mais au cas où ;)
https://www.mellanox.com/related-docs/whitepapers/WP_RoCE_vs_iWARP.pdf
https://www.networkcomputing.com/data-centers/nvme-over-fabrics-fibre-channel-vs-rdma
Là on est d’accord, c’est sans commune mesure je dirai surtout quand l’infra et les besoins commencent à devenir ‘sérieux’ !
#36
C’est utilisable d’avoir 2 pc et faire un montage croisée avec un disque distant et un local montée en raid1 ? L’intérêt serait d’avoir des PC multiroles et de la redondance.
#37
Tu peux la refaire, j’ai rien compris ?
#38
Techniquement faire un raid avec un disque local et un distant fonctionne (quoique je me demande si la différence de latence ne risque pas de poser problème) mais pour ton idée ça ne fonctionnera pas. La machine serveur n’a pas accès au contenu du disque qu’elle partage vu que toute la logique de gestion du disque est déléguée à la machine cliente. Dans ton plan une seule machine aura accès à tout le stockage et la deuxième à rien.
Si tu veux avoir deux machines redondantes avec le même stockage, il faut alors 3 machines. Un serveur qui fournira le stockage (un on appelle ça un SAN) et tes deux machines clientes qui font tourner leurs services. C’est d’ailleurs comme ça que fonctionne la redondance pour les hyperviseurs, tous ont accès au stockage partagé du SAN et lorsqu’une machine ne répond plus une seconde prend la main sur les VM qui tournaient.