Et si les SSD d'entreprise destinés à être mis sur le réseau intégraient directement un contrôleur Ethernet ? C'est le pari fait par Kioxia qui s'est associé avec Marvell et Foxconn, séduisant NVIDIA au passage.
La tendance à la mise sur le réseau des périphériques de stockage NVMe est de plus en plus présente dans le monde de l'entreprise. Si le secteur se prépare à cette approche de « désagrégation » ces dernières années, il est en pleine ébullition depuis quelques mois. Chacun y va de sa solution miracle, promettant performances et faible latence.
Kioxia à fond sur l'EBOF avec Marvell
Nous avons déjà évoqué le chemin choisi par Kioxia : celui des EBOF (Ethernet Bunch of Flash), qui consiste à produire des SSD directement équipés de contrôleurs réseau. Ainsi, aucun CPU ou composant central n'est nécessaire. Une approche qui devrait finir par rejoindre la tendance au Computational Storage (du calcul directement au sein du SSD).
Le constructeur vient ainsi d'officialiser ses SSD EM6 au sein de sa gamme Enterprise. Dual Port, certifiés GPUDirectStorage, ils exploitent un contrôleur Marvell 88SN2400 afin de proposer une interface à 25 Gb/s. Une solution sur laquelle l'entreprise travaille depuis plusieurs années. Elle la présentait déjà dans une vidéo en 2018 :
Ces SSD sont pensés pour être connectés au sein de baies spéciales, intégrant directement un switch pouvant interconnecter jusqu'à 24 SSD à 600 Gb/s. Ils sont au format 2,5" (15 mm), compatibles avec les révisions 1.1/1.4 de la norme NVMe, le protocole RoCEv2 (RDMA over Converged Ethernet) avec une endurance de 1 écriture complète par jour (1 DWPD) pour une capacité de 3 840 Go ou 7 680 Go.
Plateforme technique : Foxconn à la manœuvre
Ils sont désormais disponibles, proposés par Ingrasys (Foxconn) dans sa plateforme ES2000. Elle est au format 2U (838,2 mm de profondeur) et comporte 24 baies 2,5" (SFF-9639). Elle peut également accueillir des SSD NVMe U.2 avec un contrôleur 88SN2400 comme les E6 de Kioxia ou E3.S avec un contrôleur 88SN3400. Un module pour 48x SSD au format E1.S avec l'un ou l'autre de ces contrôleurs NVMe-oF est aussi proposé.
Qu'Intel se rassure, la partie réseau reste tout de même basée sur un processeur Atom C3538 et 8 Go de DDR4-2133, accompagnant un switch Marvell 98EX5630, le tout fonctionnant sous ONIE/SONiC. Le panneau arrière compte 2x 6 uplinks QSFP28/56 (jusqu'à 200 Gb/s), deux RJ45 à 1 Gb/s, deux autres pour le debug et deux USB 3.0.
Le tout pèse 29 kg SSD compris, avec une alimentation redondante (1+1) de 1 600 watts (80Plus Platinum) et six ventilateurs 40 x 56 mm par switch pour le refroidissement. Le tarif de l'ensemble n'a pas été précisé. Reste maintenant à convaincre les clients que cette solution est plus intéressante que d'autres déjà sur le marché.
EOBF : techniquement intéressant, mais commercialement ?
En effet, ce n'est pas la première fois que l'on voit des SSD s'essayer à intégrer directement le réseau, ce qui n'a pas convaincu jusqu'à lors. Il faut en effet que les économies faites d'un côté ne se retrouvent pas engouffrées dans la multiplication des contrôleurs, le client s'enfermant pour le moment dans un écosystème limité.
Certains pourraient ainsi préférer continuer à miser sur des SSD plus génériques, qu'ils peuvent utiliser dans une plateforme ou une autre au gré de l'évolution de leurs besoins. Le marché tranchera.
Commentaires (6)
#1
Toujours la question de la redondance qui me pose question sur ce genre de solution. Est-ce qu’on fait bêtement du mirroring sur la partie réseaux pour que les données soit en “RAID1”… le RAID0 on s’en fou un peu sur du SSD mais pour les grosses volumétrie en cumulant plusieurs SSD (RAID à parité), ça marche plus avec ce que je disais avant. Ou alors on s’en fiche et on passe sur du E3.S ou E1.L avec des grosses capacité par SSD…
#2
C’est soit du Raid Rien (JBOD), soit du Raid 1, soit du Raid 6:
#3
Ça c’est le tiering qui est géré côté hyperviseur ou la solution vSAN. Mais avant ça ya un généralement un contrôleur qui distribue ses volumes logiques (enfin c’est le cas dans les petites infra que je j’utilise). Comment ont créer un volume logique quand tes disques utilisent directement scsi/nvmeof alors que c’est sensé être l’etape d’après ?
Je sais pas si je suis plus clair ?
#4
Le principe du NVMe-oF c’est de partager en mode bloc sur le réseau. Du coup tu partages le périphérique en tant que tel (voir les articles sur le sujet) qui est vu comme du stockage local et tu gères ta redondance & co côté client. Je sais qu’iSCSI dans les NAS et ses LUN ont fait pas mal de mal à cette notion mais l’idée de départ ce n’est pas de monter un RAID côté serveur puis de le partager, sinon on perd tout l’intérêt du protocole natif.
Cela doit être possible aussi en NVMe-oF néanmoins (puisque les versions récentes du protocole permet de scinder le SSD via les namespaces), on verra comment cette solution sera implémentée côté logiciel.
#5
J’imagine que ça été réfléchi de toute façon oui. Je suis peu être aussi un peu bloqué sur des mécaniques “old school” alors qu’il existe d’autres architectures certainement. Je m’arrête un peu vite sur esxi qui est pas capable de gérer des disques.
C’est la mention brunch of flash qui me rendais perplexe. Mais c’est vrai qu’en y réfléchissant, dans le cas ou on a un gros besoin d’IO en frontal comme dans le web ça match mieux. Peu de mouvement de données et load balancé à gogo… Si tout crash on s’en fou si on a plusieurs serveurs. Et ça coûterait moins cher puisqu’on a pas de “perte” de disque lors de la configuration d’un RAID. On restaure le backup et ça roule.
Ou pas, si la gestion se fait après. Ça me donne envie de faire des stages un peu partout juste pour voir les différentes techno utilisé ici et là, pourquoi, etc…
#6
Prend l’exemple d’un stockage objet type S3, la redondance de la donnée est en général géré par ton erasure coding, ta disponibilité par le nombre de périphériques/serveurs, t’as pas besoin de gérer ça au niveau de ton partitionnement. Et tu peux backuper ailleurs pour ne pas dépendre du bon fonctionnement de ton S3 ou restaurer s’il tombe en rade