Lorsque l'on parle de stockage, pour particuliers ou entreprises, il est toujours tentant de s'arrêter aux promesses de débits fous, toujours plus élevés... même s'ils ne sont pas vérifiés en pratique et qu'ils sont loin d'être l'essentiel. Les dernières annonces de Kioxia illustrent bien ce prisme d'analyse parfois limité.
Née de la scission de l'activité de flash NAND de Toshiba, Kioxia est une société active qui propose régulièrement des solutions performantes et innovantes. Ces dernières semaines, elle s'est fait remarquer, non pas pour son annonce de nouvelles clés USB de 128 Go ou de microSD de 1 To mais ses produits destinés aux datacenters.
À l'occasion du China Flash Market Summit, elle a d'ailleurs exposé sa vision du futur du stockage. Beaucoup ont relevé la mention du PCIe 5.0, qui arrive chez Intel avec Alder Lake et Sapphire Rapids, mais aussi chez AMD à travers Zen 4. Il faut dire que la promesse est un débit de 15 Go/s et que la « Tech » aime les gros chiffres.
Mais en réalité, c'était loin d'être le plus intéressant. Tout d'abord parce qu'il y a déjà eu plusieurs annonces de solutions PCIe 5.0 pour SSD (souvent de classe entreprise) et que l'on attend pour le moment de pouvoir tester des produits concrètement. Ensuite parce que Kioxia avait bien d'autres choses à montrer que ce simple « score ».
Des détails sur le FL6 à double port et basse latence
Il y a quelques semaines, la société présentait ses SSD FL6 au format 2,5" exploitant la norme PCIe 4.0 x4 (NVMe 1.4) mais surtout de la XL-Flash qui doit lui permettre de « combler l’écart entre la DRAM et les disques SSD TLC et rendre les applications sensibles à la latence plus rapides ». Une sorte de réponse à l'Optane d'Intel, donc.
En réalité, elle utilise simplement des puces 3D (BiCS) SLC, avec un seul bit écrit par cellule, ce qui lui garantit une bonne endurance (60 DWPD) avec une faible latence et des capacités entre 800 Go et 3,2 To. Les performances étaient vantées, mais pas détaillées. Ces modèles sont équipés d'un double port natif pour assurer un certain niveau de résilience et peuvent être utilisés via NVMe-oF. Ils ont une certification FIPS 140-2 et du chiffrement (SED).
Lors du China Flash Market Summit, on a eu plus d'informations sur ce produit. Kioxia le positionne bien au niveau de 3D Xpoint (Optane) au niveau de la latence, réduite d'un tiers par rapport à un SSD TLC classique selon le constructeur. Malheureusement, peu de chiffres sont donnés. On apprend ainsi seulement que dans le test TPC-C ou PostgreSQL, le nombre de transactions par minute opéré est légèrement en retrait.
Quid du temps de réponse ou des IOPS dans différentes situations ? Rien n'a été publié à ce sujet. On a par contre droit à des chiffres par rapport à un SSD CM6 classique de la marque (TLC) avec une latence réduite de deux tiers (passant en lecture de 90 µs à 29 µs) et un nombre de IOPS multiplié par 2,35 en écriture (merci la SLC).
Pour rappel, Optane annonce de son côté des latences de l'ordre de la dizaine de microsecondes avec un SSD Optane pour datacenter comme le P4800X et en dixièmes de microsecondes pour ses modules Optane DC Persistent Memory.
Après CD7, cap sur le PCIe 5.0
Kioxia a également parlé de ses prochains SSD pour datacenter, les CD7 (PCIe 4.0 x4, NVMe 1.4) devant remplacer les actuels CD6. Ils sont au format 2,5" (15 mm, U.2). Leur capacité variera de 960 à 15 360 Go avec une endurance de 1,3 DWPD, contre 1 DWPD pour la gamme équivalente actuelle (CD6-R). Elle pouvait néanmoins grimper à 3 DWPD sur des capacités de 800 à 12 800 Go. Est-ce que cela sera également proposé ici ? Impossible à dire pour le moment.
Les améliorations semblent surtout du côté du contrôleur et du firmware puisque les puces utilisées sont toujours de la 3D NAND TLC de 96 couches avec des performances annoncées comme améliorées en écriture aléatoire. Selon les chiffres diffusés cela semble bien être là que les gains se trouvent, même si la latence est aussi réduite en lecture.
Le prochain modèle (CD8) sera à base de PCIe 5.0 et améliorera l'ensemble des résultats. Mais il reste à voir si ce qu'il en sera avec un produit finalisé et testé dans des conditions indépendantes. Aucune date de sortie n'est évoquée.
Le dessert ? L'EBOF
Reste une slide à côté de laquelle beaucoup semble être passé : celle évoquant le premier SSD au monde à disposer d'une interface NVMe-oF (Ethernet) native. En effet, jusque là il existait des solutions complémentaires, disposant de contrôleurs spécifiques, pour utiliser des SSD NVMe dans un environnement Ethernet Bunch of Flash (EBOF).
L'objectif est, contrairement au Just Bunch of Flash (JBOF) de relier des SSD NVMe directement à un switch réseau (placé dans le serveur) plutôt qu'à travers leurs interfaces PCIe et des cartes réseau à base de DPU pour faire le lien avec d'autres. Micron, Marvell et Koxia proposent déjà des solutions de ce genre, en partenariat avec Ingrasys-Foxconn.
Koxia veut aller plus loin en plaçant le port réseau et le contrôleur nativement sur chaque SSD. Une connectique 1x ou 2x 25 Gb/s peut être proposée, dans un format 2,5" (15 mm) avec des capacités de 4 et 8 To. Le protocole retenu est RoCE v2. Ainsi, 6 ports 100 Gb/s permettent la connexion de 24 SSD à 25 Gb/s.
Une solution sur laquelle la société travaille depuis maintenant plusieurs années, qu'elle avait encore évoquée en septembre et qui a de quoi simplifier les architectures de stockage « désagrégé » selon le constructeur. Mais cet aspect tout intégré augmente le coût de chaque SSD, en cas de remplacement et la dépendance au constructeur.
Il faudra donc voir si les différents acteurs du marché sont preneurs ou se tournent vers d'autres solutions. On peut aussi se demander si de telles initiatives pourraient voir le jour en NVMe/TCP sur des produits plus accessibles.
Commentaires (19)
#1
Là-dessus il faut en effet se méfier :
Je me souviens de l’époque où chez EMC² sur les baies CX4-XXX c’était des disques avec l’interface FC directement dessus. Le prix était exorbitant et ça n’a pas survécu aux disques SAS qui avaient les mêmes perfs et qui malgré leur nouveauté étaient moins chers. Sur la génération suivante, hop, disparus les disques FC (je dois encore en avoir un ou deux en stocks, et c’est inutilisables contrairement aux SAS qui après un changement de taille de blocs fonctionnent parfaitement même avec une pauvre carte PERC H310 flashée LSI dans un NAS HomeMade)
#2
C’est le jeu auxquels jouent tous les constructeurs. Ils développent des choses, ça prend des années et une fois sur le marché la sauce prend… ou pas (pour de bonnes raisons ou non). La tendance actuelle va vers le DPU, la tentative EBOF permet de s’en passer mais ce sera le ratio perf/cout/flexibilité qui décidera sans doute du succès ou non (et des critères sans doute moins rationnels comme toujours).
Maintenant la tendance existe, elle est intéressante d’un point de vue technique.
#3
On pourrait avoir la même chose pour les disques durs classiques, sans que ça devienne un “NAS” et que ça coûte un bras ?
#4
Prends un oDroid h2+
#5
#6
… ça revient au NAS.
Je vois pas pourquoi les NAS devraient être plus cher que les SAN, justement. Là où un NAS est sensé être indépendant, et est en gros un mini PC, moi tout ce que je veux, c’est pouvoir brancher des disques sur le réseau et c’est tout. Pas besoin d’avoir un CPU, juste un ASIC qui gère ethernet et les disques.
#7
Et ensuite tu te réveilles.
Soit tu prends un Pi/J et tu le codes toi-même, soit tu fais avec ce que le marché te propose. Ton tout-cuit excentrique n’existe pas.
#8
D’où ma demande originale :
Et pourquoi c’est excentrique, si on le fait pour des SSD ? Le faire pour des HDD n’est pas si différent.
Bref. Le marché ne le propose pas, mais peut-être qu’il devrait.
#9
je dit justement qu’un NAS est moins cher qu’un SAN. C’est le sens de ma phrase.
On ne le fait pas pour les SSD. Il faut gérer les couches réseaux, les protocoles pour gérer les DD, les protocoles pour communiquer avec d’autre appareils. Un Raspberry est déjà le strict minimum pour remplir ces conditions pour des disques durs alors partager des SSD qui débitent plusieurs Go/s c’est grosse bécane minimum.
Et comme on l’a dit dans les commentaire d’un autre article déporter un stockage sur un ASIC & cie n’a aucun intérêt. Pour les pro ça n’apporte aucun avantage comme regrouper les périphériques ou assurer une couche de redondance. Ca n’intéressera pas le grand public non plus car ça n’apporte rien de plus qu’un DD branché en interne mais avec une configuration plus complexe.
C’est joli pour la perf technique mais ça s’arrête là.
#10
Spoiler : si tu prends un périphérique de stockage et que tu le partages sur le réseau, c’est du SAN qqsoit la forme. Au final tu auras un contrôleur qui fait tourner un système pour gérer le partage quelle que soit la solution retenue ;) Et il faut pouvoir encaisser le débit/IOPS.
Attention : NAS/SAN, ça n’est pas une question de prix. Tout dépend de ce qui est partagé et comment c’est géré. Ce que l’on appelle communément “NAS” sont des serveurs qui intègrent à la fois des fonctionnalités de NAS et de SAN (via iSCSI par exemple).
On le fait pour des SSD Entreprise à 4 To ou plus parce que c’est “indolore” au regard du prix du SSD, du serveur qui embarque le tout et son interconnexion à 600G. Mais au niveau d’un usage personnel et d’un particulier, c’est un SAN minaturisé et le surcoût serait sans doute prohibitif.
Pourquoi des SSD plutôt que des HDD ? Parce que c’est la demande du marché d’avoir du gros débit en block storage, et du HDD ce n’est pas du gros débit. Et on maitrise déjà bien les SAN HDD iSCSI (mais s’il y a une demande pour une version plus directe, elle n’est pas impossible à imaginer).
Si, il y a même un marché pour ça, voir le papier sur les EBOF. On le déporte aussi sur la carte réseau de plus en plus avec les DPU (on parle de cartes réseau à 2000 euros pour info), qui est une autre approche moins figée dans la programmation. On ne sait pas encore ce qui sera le plus adopté par le marché, même si les DPU ont l’avantage de pouvoir gérer plein de truc (c’est aussi leur problème; s’ils traitent plein de trucs, auront-ils la ressource pour gérer comme il faut le stockage, ne faut il pas déporter ce besoin ailleurs et au plus près du périphérique ?)
Tout dépend toujours de la définition de grand public. Si tu proposes un boîtier avec un SSD à brancher sur le réseau et à monter comme bon te semble, ça intéressera du monde, mais sur le fond, ceux qui sont intéressés voudront le faire avec plusieurs SSD, et donc on en revient à une forme de SAN.
La question c’est : pourquoi on a pas plus de SAN à petit prix sur le marché ? La réponse est sans doute que les vendeurs de NAS vendent principalement du logiciel et que du SAN c’est “simple”, donc peu valorisable (hors d’un besoin spécifique en entreprise) et moins facile que du SMB pour Michu.
Mais bon, si demain quelqu’un fait un OS avec un Linux minimal et juste une interface web pour iSCSI/NVMe-oF, je suis sûr que ça aura du succès
#11
NAS: Network Attached Storage.
Que tu veuilles un NAS basique pour faire ce que tu souhaites, soit. Mais si tu veux faire du stockage réseau sans NAS, t’as rien compris. C’est la définition même du stockage réseau.
Donc je réitère mon propos: tu prends un Celeron J, tu y attaches tes disques et tu les partages en iSCSI si t’as pas envie de t’emmerder, en NVMe-oF avec une fabric en RJ si t’as envie de t’emmerder (techno éprouvée et documentée vs nouveauté plus complexe à mettre en oeuvre)
Je me permets de ne pas être d’accord.
La différence entre NAS et SAN est que ce ne sont pas la même chose: un SAN est un réseau interconnectable alors qu’un NAS fait partie d’un réseau: les SANs sont auto-redondants (au moins double contrôleurs, avec un canal interne privilégié et des backends multipoints qu’ils soient NVMe, SAS ou SATA). Chacun de ces contrôleurs est un NAS par définition.
#12
J’m’a emballé et j’suis resté sur l’idée du 1 support = 1 ASIC de l’autre sujet. Parce que oui à partir du moment où tu regroupes tes stockages ça prend tout son sens.
#13
On est d’accord sur le fait que NAS et SAN sont des éléments différents, par contre tu leur prête à mon avis des caractéristiques qui sont communes sans être obligatoires.
Le principe du SAN c’est d’exposer le stockage brut, qui sera monté et formaté sur le client, là où le NAS gère le système de fichiers et utilise un protocole de partage réseau. Que le SAN soit redondant ou non, double port ou non, etc. c’est une caractéristique possible pas ce qui le compose en tant que tel.
#14
Ça. Exactement.
J’ai pas besoin de troute-mille services, de transcodage video, de gestion de RAID, de serveurs web, de SMB… et qui coûtent 1500€ dès que tu veux mettre plus de 4 disques.
Tout ce que je veux, c’est remplacer le port SATA par un port RJ45 (ou 8P8C pour être précis). Y’a des boîtiers USB pour disques durs à 15€. Je pige pas pourquoi ça serait beaucoup plus cher d’avoir du RJ45, surtout que pour des HDD, pas besoin de 10G. Après tu les colles au cul d’un switch à 30 balles, et c’est fini. Tu t’en sors avec un surcoût par disque à maxi 50€ (et plutôt de l’ordre de 30€).
Tu joues sur les mots. Dans ces cas là, un SAN, c’est aussi un NAS. Bref.
#15
Parce qu’un port RJ45 ça n’est pas exploitable en l’état, il faut une couche logicielle/réseau pour toute la gestion (de la stack iSCSI par exemple) et ça n’est pas un truc qu’on gère avec un micro-contrôleur. Mais ce serait intéressant de voir déjà une solution de type RPi avec une connexion NVMe pour un partage sur réseau et voir le niveau de perf (qui peut consommer pas mal de CPU sans offload).
#16
Parce que l’USB est un bus, la communication entre le périphérique et l’hôte ne change pas radicalement entre être en interne ou USB. L’ethernet implique un paramétrage de l’interface pour pouvoir dialoguer, un dialogue avec la machine cliente, une étape pour transformer l’instruction iSCSI/NVMe-oF (dans le meilleur des cas, un partage classique à la SMB/NFS va induire plus d’overhead et demander un véritable OS pour gérer les droits) en instruction SATA/NVMe et vice-versa. Multiplier tout ça par la quantité d’I/O qu’il faut gérer.
Un Raspberry Pi 4 est juste en terme de performance pour ce rôle à cause de diverses limitations : réseau interfacé via USB 3 (jusqu’au 3 c’était de l’USB 2, ça plafonnait à 300Mbs), pas de SATA donc ajout d’un adaptateur USB et processeur léger pour tant d’I/O.
Dernier point : regarde le prix d’un boitier USB pour 4 disques : 150€ en moyenne. un NAS 4 baies ça commence à 300€ (et à ce prix t’as même du 2.5G).
#17
Justement. Je suis surpris que ce soit pas géré par un micro-controlleur. LwIP n’a besoin que quelques dizaines de Ko de rom et de ram pour implémenter la stack TCP/IP, largement à la porté d’un microcontroller. Et côté stack iSCSI, si c’est juste encapsulé dans IP, y’a pas grand chose à faire de plus.
Tout en sachant que AoE (ATA over Ethernet) permet de faire ça encore plus simplement.
Bref, je pige pas pourquoi c’est pas plus développé.
Comme dis plus haut, y’a des microcontrollers qui gèrent parfaitement IP. C’est pas là où ça coince. Et effectivement, dès que l’on passe du côté NFS/SMB, il faut un OS, et donc un CPU, et donc un NAS.
Mais pourquoi pas se servir de IP comme bus ? Comme l’USB le ferait. Qu’est-ce qui coince, sachant que c’est pas la pile TCP/IP ?
Du logiciel côté client. Bien sûr. Mais au delà de ça ?
#18
(shit, double post, désolé, j’avais oublié ce point)
C’est exactement mon problème. Je vais me diriger vers un boitier USB. Parce que 300 € pour un NAS, c’est le grand minimum. Et quand tu regardes pour plus de baies, la différence de prix est encore plus hallucinante.
Mais ça fait chier d’utiliser de l’USB pour tant de disques. C’est pas la solution idéale, c’est la raison de ma question initiale.
Bref.
#19
Parce que, encore une fois, il faut de la puissance pour interfacer et gérer autant de disques.
Parce que le principe du protocole IP ne le permet pas. Un bus permet de limiter au maximum l’overhead, le processeur discutant en direct avec le périphérique sans encapsulation. L’IP implique obligatoirement une encapsulation de ce que tu transmets, une vérification de l’information reçue (hors de question de fonctionner en UDP pour ça, tu corromprais ton disque au bout d’une minute) et un retour pour indiquer si tout s’est bien passé. De fait on ne peut pas passer directement dedans un protocole qui doit fonctionner sans overhead ou latence, on est obligé de passer par d’autres et donc se farcir tout le supplément de puissance que cela demande.
En fait la solution qui correspond le plus à ça c’est le Fibre Channel. Ça fonctionne en série, ça peut passer du protocole IP mais c’est surtout pensé pour passer directement du SCSI (et NVMe maintenant). Mais c’est pas du tout le même budget, parce que plutôt dirigé aux grosses entreprises et surtout à mon avis parce que le matériel doit être irréprochable pour garantir la sûreté de l’information qui passe (là où l’IP est moins regardant car y’a une vérification logicielle via TCP).