SAN SSD Linux - Stockage - Systèmes & Réseaux Pro
Marsh Posté le 08-06-2016 à 06:50:00
Salut,
Question,
C'est pour faire quoi ?
Tu as fait un test de 2*10 ?
Marsh Posté le 08-06-2016 à 15:45:38
mediator3 a écrit : |
Hello,
C'est pour faire une baie SSD collée au cul d'un cluster vCenter.
J'ai déjà 5/6 baies collées en ISCSI et une montée par un pote en FC… Mais il a pas le temps de passer pour me montrer comment faire le FC…
Pour le test en 2x10, j'avais fais ça à l'époque pour les mécaniques, mais vu que la baie sera uniquement avec du SSD, on aura de meilleurs IOPS et une meilleure latence en FC8 ou FC16…
Marsh Posté le 08-06-2016 à 16:26:47
mxz_redhot a écrit : |
C est pour utiliser avec quoi comme techno (je parle de la baie) ?
Le cluster doit faire tourner quoi comme VM ?
Marsh Posté le 08-06-2016 à 16:35:26
mediator3 a écrit : |
Mes hyperviseurs sont linkés en double attachement en FC8 à un Switch FC, ainsi qu'avec 4 liens 10Gig/+1 lien Management.
Ce sont des bi-xeon 2x8coeurs (16th) sur du 256Go de RAM.
Les baies de stoackage sont des serveurs montés avec du i7 ou du Xeon, 32/64 ou 128Go de ram (selon la capacité de stockage).
Ils ont des cartes FC8 et du 10Gig.
Sur le cluster, on a tout type de VM, y compris du SGBD.
Marsh Posté le 08-06-2016 à 16:36:52
mxz_redhot a écrit : Mes hyperviseurs sont linkés en double attachement en FC8 à un Switch FC, ainsi qu'avec 4 liens 10Gig/+1 lien Management. Les baies de stoackage sont des serveurs montés avec du i7 ou du Xeon, 32/64 ou 128Go de ram (selon la capacité de stockage). Sur le cluster, on a tout type de VM, y compris du SGBD. |
Ok et la techno fichier, c est quoi ?
C est des baies "home made", si je comprends bien ?!
Marsh Posté le 08-06-2016 à 16:39:17
mediator3 a écrit : |
A l'heure actuelle, les serveurs de stockages tournent en ext4. J'hésitais à passer en btrfs.
Oui, totalement, on avait du Infotrend et du HP, mais on a laissé tomber, les mecs sont vraiment cons la plupart du temps, et en plus de ça, ça permet de s'éclater.
PS: On a commencé à en mettre en prod il y a 1 an et demi, et honnêtement, ça tourne bien. 2 ans pour la baie en SSD Fiber, celle montée par un pote.
Marsh Posté le 08-06-2016 à 16:53:21
mxz_redhot a écrit : |
Ah ok, je pensais plutôt a un cluster de stockage, comme CEPH ou Gluster qui effectivement, sature très bien des liens 10Gb d’où le besoin de FC.
Rien a signaler sur la baie contenant les SSD ?
TLC, j’imagine les SSD ?
Marsh Posté le 08-06-2016 à 16:59:40
mediator3 a écrit : |
Le premier RAID SSD est en MLC (Intel DC S3700 480GB), Le second, celui en test est monté avec 8 SSD Samsung 850 PRO 2TB (TLC).
La baie tourne au ralenti. Elle a de la pêche à revendre…
Pour cela que je voulais tester le FC
Marsh Posté le 08-06-2016 à 17:07:00
mxz_redhot a écrit : |
Je pose la question car je songe à passer ou mettre en place une baie en full SSD.
Marsh Posté le 08-06-2016 à 17:10:10
Je t'invite à passer en MP, ou à me passer un coup de fil si tu veux des détails sur ce que j'ai vu tester/bencher/mettre en prod, comme ça je pourrais peut-être t'aider dans ton choix!
En tout cas, à mes yeux, pour les SSD, FC oblige, le 10Gig est pas vraiment au top. Par contre, pour des méca, je trouve que c'est correct avec du 10Gig.
EDIT: Je pourrais éventuellement aussi te filer des graphs de monitoring des baies!
Marsh Posté le 08-06-2016 à 17:13:44
mxz_redhot a écrit : Je t'invite à passer en MP, ou à me passer un coup de fil si tu veux des détails sur ce que j'ai vu tester/bencher/mettre en prod, comme ça je pourrais peut-être t'aider dans ton choix! |
Thx, je veux bien le max d'infos.
Je te laisse dans la journée mon mail pour tes infos et si le besoin est la, je te tel si t'es up.
Marsh Posté le 08-06-2016 à 22:56:38
Heing ? Je@nb c'pas bien de me pull sur un topical de newbies
Que ça soit du FC, du cuivre ou du pigeon powered clusters, le problème pour les IOPS n'est pas la techno mais la capacité de traitement des bus internes aux noeuds (saturation du PCI-E, DMI/QPI ? Accélération des traitements FS via µc/gating, type de cartes raid ?) et la capacité du réseau sur laquelle l'infra tourne (réseaux virtuels, réseau physique propre, prio, QoS ?)
Ensuite, vous confondez couche stockage et couche d'exposition : le noeud de stockage ne verra qu'une stack de stockage raw, rarement du stockage sur FS directement (et souvent du jbod array) et exposera le stockage via un connecteur logique type lustre/gluster (I.E : drivers sur le client si on parle de windows, support du FS Dans le kernel pour Linux/BSD, module pour MacOS)
Sans une couche d'accel dédiée, ton SSD ne fera jamais de cache ou de tiered sur ton infra, ça sera juste un serveur posé comme ça (autant passer tout tes disques en SSD TLC entreprise grade type intel DC a ce tarif)
Le FC a des bons débits mais il a clairement des problèmes de latences. L'élément qu'il te manque c'est FCoE (Fiber Channel over Ethernet) qui permet de faire passer de l'iSCSI (le natif en FC, c'est caca, a moins d'avoir un contact chez mellanox qui te sort les firmwares et les modules kernels qui vont bien/drivers pour windows qui vont bien)
Sinon, tu branche directement tes baies en FC sur ton node et tu passe en infiniband avec une couche over ethernet sur ton exposition et là, t'aura se qu'il te faut.
Pour le manque de débit en FC : attention, le PtP ne supporte pas le teaming, il te faut un fabric (qui coûte un bras)
Bref, manque des gros trous dans le cahier des charges. Et manque de technique pour décrire se que tu souhaite faire.
Edit : Petit ajout technique : vue la volumétrie de laquelle tu parle, a ce niveau ça fait longtemps que je serais passée a un FS partagé pour simplifier l'admin.
Marsh Posté le 09-06-2016 à 06:21:07
MysterieuseX a écrit : Heing ? Je@nb c'pas bien de me pull sur un topical de newbies Que ça soit du FC, du cuivre ou du pigeon powered clusters, le problème pour les IOPS n'est pas la techno mais la capacité de traitement des bus internes aux noeuds (saturation du PCI-E, DMI/QPI ? Accélération des traitements FS via µc/gating, type de cartes raid ?) et la capacité du réseau sur laquelle l'infra tourne (réseaux virtuels, réseau physique propre, prio, QoS ?) Ensuite, vous confondez couche stockage et couche d'exposition : le noeud de stockage ne verra qu'une stack de stockage raw, rarement du stockage sur FS directement (et souvent du jbod array) et exposera le stockage via un connecteur logique type lustre/gluster (I.E : drivers sur le client si on parle de windows, support du FS Dans le kernel pour Linux/BSD, module pour MacOS) Sans une couche d'accel dédiée, ton SSD ne fera jamais de cache ou de tiered sur ton infra, ça sera juste un serveur posé comme ça (autant passer tout tes disques en SSD TLC entreprise grade type intel DC a ce tarif) Le FC a des bons débits mais il a clairement des problèmes de latences. L'élément qu'il te manque c'est FCoE (Fiber Channel over Ethernet) qui permet de faire passer de l'iSCSI (le natif en FC, c'est caca, a moins d'avoir un contact chez mellanox qui te sort les firmwares et les modules kernels qui vont bien/drivers pour windows qui vont bien) Pour le manque de débit en FC : attention, le PtP ne supporte pas le teaming, il te faut un fabric (qui coûte un bras) Bref, manque des gros trous dans le cahier des charges. Et manque de technique pour décrire se que tu souhaite faire. Edit : Petit ajout technique : vue la volumétrie de laquelle tu parle, a ce niveau ça fait longtemps que je serais passée a un FS partagé pour simplifier l'admin. |
Whouaa, toi...tu y vas direct...c'est quoi cette façon d'aborder un sujet/topic...
Maintenant ou vois-tu qu'il a confusion entre couche stock et expo "vous confondez couche stockage et couche d'exposition" ?
"le problème pour les IOPS n'est pas la techno mais la capacité de traitement des bus internes aux noeuds..." = yes
"noeud de stockage ne verra qu'une stack de stockage raw" = effectivement.
Pour le reste, je ne suis pas expert en FC.
Va falloir apprendre a prendre du recule quand tu interviens dans un post, quand on ne précise pas certains aspects "techniques" ça ne suppose pas qu'on les ignore.
Marsh Posté le 09-06-2016 à 20:20:57
Ben, oui, c'est parce que les personnes qui parlent d'un sujet, sans en maîtriser les tenants et les aboutissants, ça m'exaspère.
On ne sait pas comment sont montés ses SSD dans la machine : sur une carte PCI-E qui date de plus de 4 ans, elle sera en version PCI-E 1.0 > 1Gb/ligne. Si elle est sur un bus x4 > 2GiB. Premier bottleneck dans son infra.
Il raconte une grosse bêtise sur la comparaison FC/iSCSI. Bien trop souvent dans les infra de maintenant on néglige le routeur de fond et on colle tout en réseaux virtuels sur le même réseau physique. L'iSCSI est en 8/10 et envoie des block size de 16 bits. La taille mini d'une trame ethernet c'est 192. La QoS sur le réseau en physique ne peut être a la fois optimisée pour des trames réseau classique et a la fois pour du réseau stockage : première opti avant de changer de techno c'est déjà de splitter. Ça coûte moins cher et ça économise du temps de réflexion que de revoir tout une infra pour y intégrer un cache tiered.
Sachant qu'on conseille de passer 4 blocks/trame, 1M TPS te permet d'avoir 250k IOPS et 16Gb/2GiB. En investissant un peu, un routeur qui va bien tape dans les 100M TPS. Je laisse faire le calcul : le bottleneck est très loin d'être l'iSCSI.
Avant de mettre en place une infra FC, on commence souvent par passer par du FCoE, qui permet de mettre en place la QoS et d'intégrer le fabric au réseau actuel sans pour autant devoir revoir l'infra (jumbo frames etc ...), passer directement sur du FC sans maitriser c'est une hérésie. De plus sa description des débits est pour une baie DAS. Pas pour un fonctionnement du FC dans le cadre d'un SAN.
Marsh Posté le 16-06-2016 à 12:45:42
whouah lire que le fc pose des pb de latence ... ca me trou le luc,
surtout que toutes les AFA du monde sont quasi toute utilisés avec des fabric FC justement seule fabric permettant d'avoir la plus petite latence (jusqu'à l'avénement de nvme dans une fabric dans un futur proche)
pour le teaming sur Fc ca n'existe pas on mets généralement deux fabric en place pour assurer la redondance et on présente le même target par les deux fabric il faut donc un gestionnaire de multipath sur le client. On peut le faire également avec un seul switch fc mais tu perds la redondance
il te faut donc configurer ta baie home made en mode target
http://linux-iscsi.org/wiki/Fibre_Channel
ensuite tu dois faire le zoning sur le switch fc (c'est quoi brocade , cisco ? autre) pour associer le wwn target (ta baie) avec le wwn initiator (le hba de ton serveur client)
ensuite exporter le lun sur ta baie etc .. et enfin lancer la découverte scsi sur ton client , ensuite sur ton esx tu peux gérer le multipathing (fixed, RR etc... je conseille roundrobin du coup)
Marsh Posté le 17-06-2016 à 04:04:06
raviere a écrit : whouah lire que le fc pose des pb de latence ... ca me trou le luc, |
FC vs IB ? Fine tuning sur ethernet avec routeurs a 100M PPS ? La latence en FC est fixe a 700ns/opération, et la négo a internode n'est pas négociable. Si ton fabric est limité a 256, 16 op/canal, avec des tailles de 2k (soit 16 blocs de 16 frames de 2k) l'addition peut très vite monter sur les temps d'attentes par node (même si la latence globale est inférieure, la latence au node sera plus élevée si la charge est de 100%)
A l'opposé le principal défaut de l'iSCSI, où du FCoE, c'est la latence des adaptateurs, mais elle peut et doit être offload AVANT de penser a passer sur du FC. Un ASIC dédié a l'offload et tu peu passer en dessous des 50µs du FC. Sachant que tu peut descendre bien plus bas sur le réseau (200ns/op sur l'ethernet, VS 700 pour le FC), oui je l'affirme le FC à plus de latence sur une charge de 100% => Vue comme il présente son problème, il cherche a monter son réseau pour avoir sa charge a 100%, et pas a 70%.
Et si on compare a l'IB qui a carrément du kernel offload en natif (chose que ne peut pas avoir le FC, l'iSCSI, les ASIC coûtent assez cher) on parle de 25µs dans l'adaptateur et d'un réseau sous les 100ns. Toujours convaincu que le FC propose la plus faible latence existante ?
NVMe over FC ou over n'importe quoi, reste une solution d'offload par l'intermédiaire d'un protocole. Si tu tune ton réseau sous-jacent en conséquence, le FC aura toujours ses bottleneck de négo internode, et du temps incomprésible par opération a 700ns. Deal with it, si le ack/send est pas complet en FC, t'aura des perfs de merde, et sur un réseau a 100% de charge, ben non, désolée, ça marche pas.
Marsh Posté le 18-06-2016 à 11:07:23
MysterieuseX a écrit : |
ouais choux et carotte en fait bon j'en reste là ... et je confirme t'a pas bien lancé une affirmation sans contexte donc bof bof. Enfin bon la plus grosse c'est de sortir que la latence en fc est fixe (c'est le maximum de latence pour du local switching bref ....)
Marsh Posté le 06-06-2016 à 10:11:04
Hello!
Bon, je m'en remet à vous pour savoir si l'un de vous pourrait m'aider, me diriger!
Je cherche à mettre en place un SAN en Fibre Channel. En iSCSI, aucun soucis, je sais comment faire, j'ai fais des targets ISCSI sur du 16x6TB, 16x8TB, mais là je monte un array RAID en 60 sur 8 disques SSD 2TB, grosso merdo, on atteint facilement 1,5-2Go/s en débit brut sorti du RAID…
Le problème est lié aux IOPS, l'iSCSI limite les IOPS car c'est via du cuivre, même en 2x10Gb/s…
Donc ma question; Quelqu'un a déjà mis en place un SAN FC sous un linux, que ce soit du ubuntu/debian/centos/fedo, honnêtement, n'importe. Et aurait une doc afin de pouvoir moi aussi le mettre en place. Car c'est vraiment fouillis je trouve…
Merci d'avance!