laurent wandrebeck a écrit 121 commentaires

sauf quand la machine est chargée comme une mule :) notre serveur de métadonnées sert aussi de chunkserver, et de machine de calcul, donc des fois, elle rame un peu.
Mais sinon, effectivement, toutes les opérations sur les métadonnées sont extrêmement rapides 99% du temps.

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

Super idée, j'étais justement en train de nager parmis les potentielles solutions de supervision afin d'enfin en déployer une au taff. Peut-être un poil trop court, mais je pense que ça résume bien l'existant. Il y'a des chances que je me tourne vers Zabbix, pour les raisons suivantes:
- C'est du tout en un, ce qui est parfait pour moi, vu que mon temps à consacrer à l'admin est limité.
- On peut utiliser PostgreSQL plutôt que se trimballer un mysql exprès pour la supervision, et ça tombe bien, on utilise PG :)

Merci encore pour la news !

Il est dorénavant inutile de vous référer à mon dépôt qui est d'ores et déjà en veille.
MooseFS est dorénavant disponible pour CentOS 3, 4 et 5, en i386 et x86_64.

Je viens d'apprendre qu'il est possible d'avoir plusieurs serveurs metalogger, sans aucune manipulation particulière.
Bien sûr ça ne permet toujours pas la HA, mais c'est mieux que rien :)

super. toujours dispo pour t'aider à la rédaction :-)

Oui MooseFS est utilisable en prod. Des déploiements allant jusqu'à 1.5Pio existent.
Chez Gemius (papa de moose), ils ont plusieurs (4 je crois) déploiements, dont le plus gros monte à 500 et quelques To, sur à peu près 70 serveurs.
Quant à Ceph, tu n'as qu'à suivre un peu la ML, voire même lire wikipedia, ou même leur site, qui précise que ce n'est pas stable :)
« Please note, however, that Ceph is still experimental and is not yet ready for use in a production environment. We have made every effort to prevent the client from crashing your system, but it is still relatively young code. The server side also has some known issues, and will need both time and testing to earn our trust. »

Le développement de MooseFS a débuté en 2005, et il a été libéré le 30 mai 2008.

Merci !
Mais je ne trouve pas comment éditer la dépêche /o\

Raid n ? Tu peux vraiment faire un équivalent de 5 ou 6 ? Ça me paraît étonnant.

Ceph a l'énorme problème de ne pas être utilisable en prod. Et pas avant une paire d'années je pense.
Son avantage c'est qu'il bénéficiera d'un excellent support, et qu'il sera rapide à n'en pas douter, de part sa présence en kernel-mode. Car le fait de passer par FUSE ne donne pas les performances les plus rapides du monde.
Mais de toutes façons, quand on atteint de « gros » volumes de données, on sait d'avance qu'il faut faire quelques concessions par rapport à un stockage local…en terme de latence à cause du passage sur le réseau au lieu du bus pci(x|e), par exemple.
Je ne saurais être plus précis sur Ceph, son état d'avancement ne correspondant pas aux critères au taff.

L'utilité de moosefs étant bien d'assurer répartition et tolérance de panne…et cette tolérance est assurée grâce à la réplication.
Je ne m'amuserais pas à agglomérer des gros volumes sans réplication, ça n'aurait pas beaucoup plus d'intérêt que d'avoir ces volumes séparés…et encore, avec des volumes séparés, tu n'as que les fichiers de la machine dans les choux qui disparaissent, ce qui n'est pas du tout gagné avec un fs réparti.
Si je me trompe, je suis prêt à lire une dépêche présentant glusterfs, avec ses modes et tout le reste. :)

Effectivement, la présence d'un serveur de métadonnées peut s'avérer un tantinet problématique. Ceci dit, un howto permettant une bascule automatique entre le master et le metalogger va être crée.
Il est aussi prévu que ce point soit amélioré directement au niveau du code, rendant caduque cette « faiblesse ».
Quant au changement de mode dont tu parles, j'avoue que cela ne me parle guère…

Même s'ils sont tous les deux simples, moosefs l'est davantage :)
Exemple vite fait:
Fichier de config du maitre utilisé pour les tests ici:
WORKING_USER = mfs (oui oui, un simple utilisateur)
DATA_PATH = /data/mfs
le fichier mfsexports.cfg
10.0.0.0-10.0.0.5 /test rw,maproot=nobody,password=test
les machines qui ont le droit de monter, les droits, et on peut demander un pass pour le montage…
le processus maître sur la machine maître:
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
mfs 12979 2.6 1.6 85776 67976 ? S< 09:20 0:00 /usr/sbin/mfsmaster start
sur le metalogger:
le fichier de config:
WORKING_USER = mfs
MASTER_HOST = mfsmaster
Le processus:
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
mfs 3735 0.0 0.0 16780 1160 ? S< Jun07 2:17 /usr/sbin/mfsmetalogger start
enfin un chunkserver:
e fichier de config:
WORKING_USER = mfs
MASTER_HOST = mfsmaster
le fichier d'export:
/mnt/mfs
Le processus:
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
mfs 6591 0.8 0.2 113472 5560 ? S<l Jun16 110:21 /usr/sbin/mfschunkserver start

Et c'est tout !
Et pour monter le volume, mfsmount /là/où/tu/veux -H mfsmaster

Quant à ton problème d'installation et de droits root, je n'ai pas testé, mais il doit être possible en toute logique de pouvoir l'utiliser sans devoir recourir à root. Tout tourne en espace utilisateur…
J'ai fais le repo et le paquet RPM dans le simple but de me faciliter le déploiement.
Jettes-y un œil plus précisément, tu ne regretteras pas :)

Et le désavantage, si je ne m'abuse, qu'il faut prévoir des serveurs dédiés pour la réplication. Du coup c'est un peu plus rigide que de simplement ajouter une machine pour augmenter l'espace dispo sans avoir à se préoccuper de la partie réplication.
Mais je connais assez mal glusterfs, peut-être me trompe-je.

Ce n'est pas vraiment un gros raid réseau, puisque des modes tels que 0 ou 5 n'existent pas. En tout cas je n'en ai pas trouvés.
C'est plutôt du raid 1, même si ce n'est pas rigoureusement exact. Il n'y a pas de réplication au secteur près comme dans le raid, mais au chunk près (64 mio donc). Et en plus, tu ne décides pas sur quelles machines vont les chunks dupliqués, c'est MooseFS qui s'en charge. Dans le cas du raid, c'est limité par les disques. Ici, les chunks peuvent être sur des machines différentes, qu'ils soient redondants (goal≥2) ou non.

Par n'est pas un système de fichier réparti, mais un répartiteur de processus sur un ensemble de machines (je raccourcis pour éviter de tomber un peu trop dans la technique), c'est un tantinet différent.
MooseFS est un système de fichier qui se répartit sur des machines.
Je peux faire plus long par mail si tu veux des éclaircissements.

Si quelqu'un a les moyens de filmer tout ça et de le mettre à disposition, je suis preneur :)
(Paris est un peu loin…)
Merci !

Ah oui, Redmine…que j'ai aussi connu grâce à GLMF. Sauf que nous n'avons pas de serveur ROR.
Non pas que je sois contre, mais installer le bousin pour un seul soft ne me ravit guère. Et nous ne passerons probablement jamais au dév en ruby (ce qui est dommage, car sans vouloir rentrer dans le troll, je trouve ruby bien plus agréable et cohérent, mais il manque assez cruellement de librairies absolument nécessaires pour nous).

Fort bien, ça va beaucoup vous faciliter la tâche pour vous détacher de My.
C'est peut-être prévu depuis longtemps, mais une rapide recherche sur ton site n'a rien rapporté, du coup j'en avais déduis que ce n'était pas à l'ordre du jour. J'avais tort, et c'est tant mieux :)

Effectivement ce genre de « détails » seraient les bienvenus.

Ça m'avait l'air tentant, jusqu'à ce que tu précises que cela ne supporte que svn…et nous utilisons git au boulot.
Je vois aussi qu'il ne supporte que Mysql…et nous utilisons PostgreSQL.
Ceci dit, la version 0.9.3 va se pencher sur le support d'autres VCS visiblement ( http://codingteam.net/project/codingteam/bugs/show/287 ).
Avec un peu de chance, le support de PostgreSQL arrivera un jour…mais ça n'a pas encore l'air prévu. Dommage.

hmmm on dirait bien que la compilation ne s'est pas faite en mode debug, comme le montre #6 0xbfffc1d4 in ?? ()
même chose mais avec un make clean avant le make ?

Concernant la rédaction de scénario, il paraît (jamais eu le temps de m'y pencher) que http://celtx.com/ serait une bonne aide.

Actuellement, la machine de backup des homes ne fait que ça. Les réplications sont des fonctionnalités que je veux lui ajouter, donc pas de mélange des genres :)

OAR a l'air tout à fait sympathique, je vais m'y pencher plus en profondeur.
Cela ne semble pas régler le problème des différents volumes de données, mais je n'ai pas encore lu grand-chose.

Merci !