C'est assez difficile à chiffrer, puisque rarement seul à utiliser le FS...je peux te donner des chiffres à la louche constatés sur notre parc:
en écriture, une 30aine de mo/sec
en lecture, une 50aine. http://www.moosefs.org/moosefs-faq.html#average
je pense (et espère un peu j'avoue) que lorsque nous recevrons notre 9ième chunkserver (pareil que la conf citée plus bas mais en version 36 disques) le FS ramera moins en charge de part une meilleure répartition des I/O.
Les écritures sont assez pénalisantes (réplication). Et oubliez mfs si vous travaillez sur des petits fichiers, il n'est pas fait pour, ça vous coutera cher en place, et les perfs seront mauvaises. Voyez plutôt du côté de GlusterFS ?
Je peux te dire qu'une 15aine de codes de calcul qui lisent chacun dans les 400/500mo, et qui en écrivent chacun 200mo font que le FS rame. Tu attends plusieurs secondes le résultat d'un ls. Mais ça ne se vautre pas :)
Une machine type est un 2U, 6 ou 8 cœurs à 2ghz (opteron), 8/16/32go de ram, avec une 3ware 9650 et 12 disques sata 2to 5400rpm, reliée en gbps avec jumbo frames (mtu 7200 à cause de quelques vieilles cartes realtek de brin qui trainent encore pour ne pas les nommer). Je ne déclare pour condor que le nombre de cœurs - 2 et la RAM - 2 ou 3 go histoire d'éviter de (trop) faire swapper les machines, afin de laisser le process chunkserver s'épanouir aussi :)
Quant à la tolérance de panne, elle est dûe à la réplication des données, pas à FUSE en tant que tel.
Un jour, quand tout ça sera production-ready, je passerais en btrfs et utiliserais ceph.
J'ai le temps de voir venir :D
[^] # Re: Ca chiffre à?
Posté par laurent wandrebeck (site web personnel) . En réponse au journal Quelles solutions adopter pour améliorer un parc existant ? La suite !. Évalué à 2.
C'est assez difficile à chiffrer, puisque rarement seul à utiliser le FS...je peux te donner des chiffres à la louche constatés sur notre parc:
en écriture, une 30aine de mo/sec
en lecture, une 50aine.
http://www.moosefs.org/moosefs-faq.html#average
je pense (et espère un peu j'avoue) que lorsque nous recevrons notre 9ième chunkserver (pareil que la conf citée plus bas mais en version 36 disques) le FS ramera moins en charge de part une meilleure répartition des I/O.
Les écritures sont assez pénalisantes (réplication). Et oubliez mfs si vous travaillez sur des petits fichiers, il n'est pas fait pour, ça vous coutera cher en place, et les perfs seront mauvaises. Voyez plutôt du côté de GlusterFS ?
Je peux te dire qu'une 15aine de codes de calcul qui lisent chacun dans les 400/500mo, et qui en écrivent chacun 200mo font que le FS rame. Tu attends plusieurs secondes le résultat d'un ls. Mais ça ne se vautre pas :)
Une machine type est un 2U, 6 ou 8 cœurs à 2ghz (opteron), 8/16/32go de ram, avec une 3ware 9650 et 12 disques sata 2to 5400rpm, reliée en gbps avec jumbo frames (mtu 7200 à cause de quelques vieilles cartes realtek de brin qui trainent encore pour ne pas les nommer). Je ne déclare pour condor que le nombre de cœurs - 2 et la RAM - 2 ou 3 go histoire d'éviter de (trop) faire swapper les machines, afin de laisser le process chunkserver s'épanouir aussi :)
Quant à la tolérance de panne, elle est dûe à la réplication des données, pas à FUSE en tant que tel.
Un jour, quand tout ça sera production-ready, je passerais en btrfs et utiliserais ceph.
J'ai le temps de voir venir :D