Kioxia parle du futur du stockage, le PCIe 5.0 n’est pas le plus intéressant

EBOF FTW

Kioxia parle du futur du stockage, le PCIe 5.0 n'est pas le plus intéressant

Le 24 septembre 2021 à 13h49

Commentaires (19)

Vous devez être abonné pour pouvoir commenter.

Abonnez-vous
votre avatar

Là-dessus il faut en effet se méfier :




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.


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)

votre avatar

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.

votre avatar

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 ?

votre avatar

Prends un oDroid h2+

votre avatar

(reply:60169:Cqoicebordel) Si c’est pas un NAS c’est quoi ? :keskidit: C’est déjà l’option la moins chère comparée à un SAN.


votre avatar

patos a dit:


Prends un oDroid h2+


… ça revient au NAS.




Soraphirot a dit:


Si c’est pas un NAS c’est quoi ? :keskidit: C’est déjà l’option la moins chère comparée à un SAN.


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.

votre avatar

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.

votre avatar

D’où ma demande originale :




Cqoicebordel a dit:


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 ?


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.

votre avatar

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à.

votre avatar

Cqoicebordel a dit:


… ça revient au NAS.


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.




Soraphirot a dit:


Je vois pas pourquoi les NAS devraient être plus cher que les SAN, justement.


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).




Cqoicebordel a dit:


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.


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).




Soraphirot a dit:


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.


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 ?)




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.


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 :D

votre avatar

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)




David_L a dit:


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).


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.

votre avatar

David_L a dit:



Si, il y a même un marché pour ça[…]


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.

votre avatar

patos a dit:


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.


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.

votre avatar

David_L a dit:


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.


Ç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.

votre avatar

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).

votre avatar

Cqoicebordel a dit:


Je pige pas pourquoi ça serait beaucoup plus cher d’avoir du RJ45


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).

votre avatar

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 ?

votre avatar

Soraphirot a dit:


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).


(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.

votre avatar

Cqoicebordel a dit:


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.


Parce que, encore une fois, il faut de la puissance pour interfacer et gérer autant de disques.




Cqoicebordel a dit:


Mais pourquoi pas se servir de IP comme bus ?


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).

Kioxia parle du futur du stockage, le PCIe 5.0 n’est pas le plus intéressant

  • Des détails sur le FL6 à double port et basse latence

  • Après CD7, cap sur le PCIe 5.0

  • Le dessert ? L'EBOF

Fermer