SAN SSD Linux

SAN SSD Linux - Stockage - Systèmes & Réseaux Pro

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!  
 

Reply

Marsh Posté le 06-06-2016 à 10:11:04   

Reply

Marsh Posté le 06-06-2016 à 20:17:23    

Demande à MysterieuseX de venir ici :)

Reply

Marsh Posté le 08-06-2016 à 06:50:00    


 
Salut,
 
Question,
 
C'est pour faire quoi ?
 
Tu as fait un test de 2*10 ?


---------------
Feedback:http://forum.hardware.fr/hfr/Achat [...] 3232_1.htm
Reply

Marsh Posté le 08-06-2016 à 15:45:38    

mediator3 a écrit :


 
Salut,
 
Question,
 
C'est pour faire quoi ?
 
Tu as fait un test de 2*10 ?


 
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…

Reply

Marsh Posté le 08-06-2016 à 16:26:47    

mxz_redhot 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…


 
C est pour utiliser avec quoi comme techno (je parle de la baie) ?
 
Le cluster doit faire tourner quoi comme VM ?
 


---------------
Feedback:http://forum.hardware.fr/hfr/Achat [...] 3232_1.htm
Reply

Marsh Posté le 08-06-2016 à 16:35:26    

mediator3 a écrit :


 
C est pour utiliser avec quoi comme techno (je parle de la baie) ?
 
Le cluster doit faire tourner quoi comme VM ?
 


 
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.

Reply

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

 


Ok et la techno fichier, c est quoi ?

 

C est des baies "home made", si je comprends bien ?!

Message cité 1 fois
Message édité par mediator3 le 08-06-2016 à 16:38:07

---------------
Feedback:http://forum.hardware.fr/hfr/Achat [...] 3232_1.htm
Reply

Marsh Posté le 08-06-2016 à 16:39:17    

mediator3 a écrit :


 
 
Ok et la techno fichier, c est quoi ?
 
C est des baies "home made", si je comprends bien ?!


 
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.

Message cité 1 fois
Message édité par mxz_redhot le 08-06-2016 à 16:42:25
Reply

Marsh Posté le 08-06-2016 à 16:53:21    

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


 
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 d’où le besoin de FC.
 
Rien a signaler sur la baie contenant les SSD ?
 
TLC, j’imagine les SSD ?  


---------------
Feedback:http://forum.hardware.fr/hfr/Achat [...] 3232_1.htm
Reply

Marsh Posté le 08-06-2016 à 16:59:40    

mediator3 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 d’où le besoin de FC.
 
Rien a signaler sur la baie contenant les SSD ?
 
TLC, j’imagine les SSD ?  


 
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

Message cité 1 fois
Message édité par mxz_redhot le 08-06-2016 à 17:00:04
Reply

Marsh Posté le 08-06-2016 à 16:59:40   

Reply

Marsh Posté le 08-06-2016 à 17:07:00    

mxz_redhot 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


 
 
Je pose la question car je songe à passer ou mettre en place une baie en full SSD.
 


---------------
Feedback:http://forum.hardware.fr/hfr/Achat [...] 3232_1.htm
Reply

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!

Message cité 1 fois
Message édité par mxz_redhot le 08-06-2016 à 17:10:50
Reply

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! ;)
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!


 
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.
 
 :jap:  


---------------
Feedback:http://forum.hardware.fr/hfr/Achat [...] 3232_1.htm
Reply

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.

Message cité 1 fois
Message édité par MysterieuseX le 08-06-2016 à 22:59:03
Reply

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

  

Whouaa, toi...tu y vas direct...c'est quoi cette façon d'aborder un sujet/topic... :heink:

 

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.

 

:jap:  

 



Message édité par mediator3 le 09-06-2016 à 06:21:45

---------------
Feedback:http://forum.hardware.fr/hfr/Achat [...] 3232_1.htm
Reply

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.

Reply

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)

Reply

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


 
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.

Reply

Marsh Posté le 18-06-2016 à 11:07:23    

MysterieuseX a écrit :


 
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.


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 :D bref ....)
 

Reply

Sujets relatifs:

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed