Reprise du message précédent :
nope, ça baisse là ... j'ai un caillou une pierre qui me sert de repère ...

ah ouais, pas bête  

où commence la pierre ? où finit le caillou ?

je peut pas dire, mais en l’occurrence, il/elle dépasse de plus en plus de l'eau
après caillou/pierre, tout est une histoire d’échelle ...
 

si le mec s'était appelé Caillou, imagine la tronche de Cabrel  

bonjour,

Et si le mec s’était appelé « Falaise » ou « Territoire inondable », t’imagines le malaise ?

ã mon gamin je lui fais "je suis ton père Pierre !"

à son âge, il doit pas être être assez vieux* pour la réf culturelle, ça le laisse pas un peu perplexe
 
* les archives font la grève du zèle

Il a à peine 2 ans, mais le ton et la tête que je fais le font rire

 
Sir, on en a trop  

ok j'ai rien dit  

bon, ben du coup maintenant que c'est réglé, je repars finir mes vacances en bretonie.

preums'  
 

prout !

Je@nb qui me pull en cat pro pour parler avec des noobs. C'est du grand n'importe quoi la demande de l'OP
 
http://forum.hardware.fr/hfr/syste [...] tm#t140581
 
Pop corn pour le stockage pr0n !

Plus ça viens, moins la cat pro est "pro". Bonne chance Je@nb

"L'iSCSI limite les IOPS vue que c'est du cuivre"
 
Non mais celle là, c'est la meilleure quoi quand même xD
Il aurait dit "le PCI-E limite les IOPs vue que c'est du cuivre" ç'aurait été la même chose.
Rien que son premier paragraphe est une mauvaise interprétation des données stats que sort son infra :  
-on vire les jumbo frame,  
-on vire le cache résal,  
-on passe la taille des trames IP aux environs des 192 et tu les as tes IOPS comme en natif  
 
98% du natif on va dire, avec des disques en iSCSI on a un payload de 16 bits, 20 bits en comptant les infos de protections + taille des trames IP ... Avec un bon routeur de fond qui tape au moins le million de TPS, t'es pas limité par le cuivre (avec une règle a 4Gbs/1m TPS, il pourrait sortir 250k iops sur le FS côté client, c'pas dégueu)
 
réseau SAN dédié (c'est le but, Storage Area Network : sous entend un réseau propre, a lui, voir phusiquement dédié), c'est certain qu'en 8/10 tu passe 2 blocks par trame IP, tu peux difficilement réduire la taille des trames > 4 blocks/trames est un bon compromis pour les IOPS (on retombe donc sur 4Gb/1M TPS)
 
Il a deux liens => son 802.3ad est bien configuré ? Client ? Serveur ? Routeurs ok ? Gros doute : en principe, 2x10Gb ça fait du 2Go/s peak max, a 98% sur le résal, si son infra est bien configurée il doit pouvoir passer environs 500kiops sans limitations sur l'ethernet, soit largement au dessus de se qu'une application hors clust peux passer. \o/
 
Il veux du FC8 ou FC16 ensuite, mais il a pas capté encore que FC8 c'est 6.4Gb de payload avec des trames FC carrément plus grosses (d'où le FCoE en jumbo frame et pas l'iSCSI qui lui nécessite de passer des trames ridiculement petites) et en FC16 j'en parle même pas, donc soit derrière il utilise un FS qui lui permet d'avoir un cache meta où un tiered cache (je doute qu'il ait les compétences pour ça), soit il oublie. Le FC c'est fait pour le débit avant tout et le fait que ça soit peu sensible aux bruits (=> longue distances pour des array jbod en stockage sur HDD mécanique, genre relier une tétrachiée de fujitsu eternus)

Preums à pas avoir les yeux en face des trous

io
 
MysterieuseX : sysadmin catcheuse  
 

 
 

Et tu ne penses pas que c'est un peu toi qui place la barre "un peu" haute ?

De mémoire,  les divas aiment aussi le silicone

Bonjour,

@mysterieuse: toujours curieux sur le sujet, je n'ai pas bien saisi le rapport entre fcoe et iscsi, et surtout en quoi le premier faisait passer le second ?

 
Y'a pas de rapport, le premier ne fait pas passer le second. Le premier permet juste de l'intégrer a un réseau virtu sans avoir a revoir la QoS, et permet surtout une migration seamless : tu change la pile d'exposition du san d'iSCSI vers FCoE (un peu plus compliquer que se que je viens de dire hein) et tu rebranche tes clients : ils seront paré le jour ou tu voudra passer en FC "pur". Mais c'est idiot, il y a souvent plus d'IOPS en iSCSI, du moins plus de faciliter de gérer le profil d'IOPS en iSCSI qu'en FC.

Ok c'est bien ce qu'il me semblait aussi,même si je ne suis pas d'accord avec toi sur les conclusions ... Une approximation de noob sur un topic de noob
Au final fcoe est une idée lumineuse qui ne décollera pas uniquement parce que arrivée trop tard, alors que le san est mort en entreprise ( paix à son âme et à tous ceux qui en font leurs choux gras )

 
Tu peux développer

Hors domaines spécifiques, qui vont se concentrer de plus en plus, la majorité du secteur va se retourner vers un monde de présentation en mode fichier et abandonner le mode bloc, bien trop complexe et onéreux par rapport au gain apporté.... ( ou un mode bloc tellement virtualisé qu'il n'en sera plus vraiment un ... )
Le buzz de l'hyperconvergence n'est que la traduction marketing de cette tendance et Citrix, pour te répondre, a intérêt à sortir rapidement une intégration rapide de son rachat de melio ...
Le Fcoe c'était génial sur papier, mais l'investissement technique est trop lourd, et la masse critique diminue trop pour en justifier le coût de l'investissement, dommage ...

Je constate que chez les PME, le SAN est inexistant de toute façon

Par contre, le fichier est très présent, en général SMB (MS) ou NFS chez des plus Linuxiens.

D'ailleurs c'est pas pour rien que XenServer 7 fonctionne avec des storage SMB justement

Le seul truc pas top c'est les perfs parfois, mais ça peut s'équilibrer par un ZFS qui compresse. Dans des environnements de PME j'entends

Et même sans ça, pour voir de la grosse différence de perfs quand t'a pas besoin de 10k IOPS, faut se lever tôt (non MystX, je parle chez des petits, pas des pétroliers )

 
Je suis d'accord hein, les besoins@250k IOPS sur un stockage sont ... Rare.
 
@trictrac : l'iSCSI permet de gérer le profil d'IOPS en fonction du réseau qui le supporte, et c'est souvent de l'ethernet > La connerie c'est d'avoir une QoS d'envoie d'une trame complète et l'iSCSI ne permet pas de remplir une trame complète de 1280 (si t'envoie 1Kio), tu perd des IOPS. Alors maintenant, les disques dur peuvent gérer des block size plus importantes (2/4/8k) mais tu reste sur de l'iSCSI, soit du 16bits : le protocole ne peut pas envoyer plus grand > tu stack par 4 ou 8 et tu fait une QoS pour envoyer 192 bits/trames (en comptant l'encodage en 8/10 et l'encapsulation IP) > tu retrouve des IOPS proche du natif, encore faut-il que le routeur ait une grosse capacité en termes de TPS.
Le FC permet d'envoyer des block size natives des disques dur (2/4/8K) donc moins de pertes d'encodage au niveau des contrôleurs mais est gourmand niveau ressources processeur (FCoE : a moins d'avoir une carte acceleratrice qui coute la peau des fesses, c'est le proc qui doit gérer la pile de conversion et @2Gio, faut la sortir la capacité de calcul et avoir les lignes PCI-E qui vont bien derrière dans tout les cas) : c'est plus difficile d'avoir un profil d'IOPS géré au petits oignons : tu doit avoir une QoS adaptée ET une machine qui va bien.
 
Pour le reste : on s'oriente vers des solutions hybride de toutes façons, a base de FS adaptés en mode logiciel. Pour les perfs, tout dépend du noeud d'exposition, mais avec une couche type lustre ou SMB/NFS récente, on arrive facilement a scaler au dessus de 80% du natif (IOPS et débit) : même en big data/pétro/clust c'est jbod en DAS sur des gros noeuds ZFS/Lustre/Gluster/NFS

io    
 
 
On en apprend des trucs ici  

ca fait mal de lire tes trucs au réveil, mal de tête assuré

 
on dit IOPS ici

http://xkcd.com/1692/

Quoi ? T'as craché dans ton IOPS ?

Debout les campeurs et haut les cœurs !
---
Preum's.

PLOP !

o/