En vrac :
- Le code est distribué sous GPLv3 ;
- Il utilise FUSE et fonctionne en espace utilisateur ;
- Il dispose d'une poubelle automatique à durée de rétention modifiable à souhait ;
- Il est très simple à déployer et administrer : comptez une heure, lecture de la documentation comprise pour avoir un serveur maître et quatre serveurs de données fonctionnels ;
- Compatible POSIX, il ne requiert aucune modification des programmes pour pouvoir y accéder ;
- L'ajout de machines pour agrandir l'espace disponible est d'une simplicité enfantine ;
- Vous choisissez le nombre de réplicas que vous désirez, par fichier ou par répertoire, pour la tolérance de panne, avec une seule commande, le tout à chaud…
Le développement de MooseFS a débuté en 2005, et il a été libéré le 30 mai 2008. MooseFS est un système de fichiers méconnu regorgeant de qualités :
Un peu d'histoire. Une société polonaise a, pour ses besoins internes, développé (en C) un système de fichiers réparti et à tolérance de panne. Il a fini par être libéré (sous l'impulsion seule de la société semble-t-il), sous licence GPLv3, en décembre 2009.
Reposant sur l'utilisation de FUSE, le système de fichier est compatible POSIX et ne nécessite aucune adaptation des programmes pour pouvoir l'utiliser ! Il est donc fonctionnel sous tous les systèmes disposant de FUSE (GNU/Linux, *BSD…).
C'est stable ! Le plus gros déploiement connu monte à 1.5 Pio, ce qui n'est pas tout à fait négligeable. D'autres déploiements existent, et sont tous de l'ordre de la dizaine ou centaine de Tio.
Il est très simple d'assurer une réplication de vos données par une simple commande :
mfssetgoal GOAL fichier ou chemin
Un simple -r pour la récursivité vous permet d'appliquer cette valeur de manière… récursive, comme son nom l'indique. Le tout est géré de manière transparente, avec le système de fichier monté et en production. La hausse, mais aussi bien sûr la baisse du nombre de réplicas sont gérées.
Le système est réparti : les fichiers sont découpés en paquets de 64 Mio et distribués sur les machines dites « chunkserver », ou encore serveurs de données. Les fichiers inférieurs à cette taille ne sont, bien entendu, pas concernés par cette découpe.
MooseFS tolère les pannes : si, et seulement si (en toute logique), vous avez indiqué un « but » (voir réplication des données un peu plus haut) supérieur à 1 pour vos fichiers, la disparition d'un serveur de données ne gênera pas la disponibilité des données. Bien sûr, cela a un coût en matière de place, mais la disponibilité à un prix.
Il est aussi tout à fait possible d'agrandir le volume. Il suffit d'ajouter une ou des machines, de les configurer en tant que serveur de données (installation, dix secondes via apt-get ou yum, configuration, deux lignes à changer, trente secondes, lancement du service compris, vous en avez pour une minute !). Le serveur maître les détectera, et la répartition des données vers les nouveaux arrivés débutera sans que vous deviez intervenir !
Un système de poubelle à durée de rétention configurable est disponible par défaut. Tout fichier supprimé s'y retrouve tant que la durée de rétention n'est pas dépassée. Fini les rm malheureux sur des données non sauvegardées (ou dont la récupération est un calvaire).
Enfin, un serveur en Python permet de visualiser aisément et rapidement l'état du volume, la charge des serveurs, etc.
Bien sûr, tout n'est pas si parfait.
Il n'existe pas (encore) de procédure simple pour assurer la haute disponibilité du système de fichier. En effet, un serveur maître se doit d'être présent pour permettre les montages et l'accès aux données. Si le maître tombe, les fichiers ne sont plus accessibles.
Un serveur dit « metalogger » peut être mis en place. Il recueille tous les événements du système de fichier et peut permettre, si le maître est vraiment mal en point (perte de ses metadada, ou de son historique), de lui faire rejouer les logs pour que le volume reste cohérent.
La documentation est légère, tout comme les commentaires dans le code. À noter qu'il est prévu l'implémentation d'un algorithme permettant d'obtenir l'équivalent de quatre réplicas des données pour le coût physique de deux. Pour le moment, un fichier avec un « goal » de 3 prendra 3 fois sa taille d'origine (peu ou prou). Enfin, un canal IRC, #moosefs est ouvert depuis peu sur freenode, où vous êtes bien entendu les bienvenus.
Aller plus loin
- Site officiel de MooseFS (271 clics)
- Liste de diffusion (26 clics)
- Dépôt CentOS (39 clics)
# Souvenirs
Posté par Zarmakuizz (site web personnel) . Évalué à 4.
http://linuxfr.org/~zaurus/29424.html
Du coup je me suis demandé ce que c'était un système de fichiers distribués, par rapport à un système de fichiers tout court (ou non distribués, pourquoi pas). Le problème de la page française de Wikipédia est d'être très courte, et la page anglaise a recours à tellement de termes qu'on peut pas trop faire semblant de comprendre...
Apparemment dans un système de fichiers non distribués (cas classique ?), tout passe par le serveur (intermédiaire, plus lent toussa). Dans un système de fichiers distribués, des clients peuvent écrire directement dessus sans passer par l'intermédiaire dudit serveur (plus rapide donc, mais il doit y avoir des lacunes par rapport au non distribué). Est-ce que j'ai bon ?
Commentaire sous licence LPRAB - http://sam.zoy.org/lprab/
[^] # Re: Souvenirs
Posté par Guillaume Chanaud (site web personnel) . Évalué à 5.
Je dis ptêtre une énorme connerie, mais j'ai toujours compris les fs distribués comme ça.
[^] # Re: Souvenirs
Posté par Guillaume Chanaud (site web personnel) . Évalué à 4.
En fait je vois ça comme un gros RAID réseau, on travaille au niveau block (et non pas au niveau fichier comme NFS ou CIFS) et on agrège plusieurs ressources (on peut étendre la capacité du volume, ou alors utilisé l'espace ajouté pour répliquer etc...(RAID 0/1/5 etc..)
[^] # Re: Souvenirs
Posté par laurent wandrebeck (site web personnel) . Évalué à 3.
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.
[^] # Re: Souvenirs
Posté par laurent wandrebeck (site web personnel) . Évalué à 5.
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.
[^] # Re: Souvenirs
Posté par Zarmakuizz (site web personnel) . Évalué à 3.
J'ai vu ton journal sur les besoins d'une PME qui traite des images satellites, je vois mieux à quoi ça peut servir de mettre en commun l'espace disque de plusieurs machines.
Commentaire sous licence LPRAB - http://sam.zoy.org/lprab/
# A møøseFS bit my sister once...
Posté par ステファン . Évalué à -2.
OK, you should sack me, I guess. Néanmoins comment ne pas y voir une référence quelque part ?
[^] # Re: A møøseFS bit my sister once...
Posté par Édouard Siha . Évalué à 3.
[^] # Re: A møøseFS bit my sister once...
Posté par Zarmakuizz (site web personnel) . Évalué à 2.
Commentaire sous licence LPRAB - http://sam.zoy.org/lprab/
[^] # Re: A møøseFS bit my sister once...
Posté par zerkman (site web personnel) . Évalué à 5.
# GlusterFS
Posté par Sytoka Modon (site web personnel) . Évalué à 5.
http://www.gluster.org/
[^] # Re: GlusterFS
Posté par zaurus (site web personnel) . Évalué à 3.
et tu vas comprendre un des problèmes de pleins
de systèmes de fichiers distribués:
c'est assez voire très complique et ça peut demander
une charge d'administration système colossale!
Ce MooseFS a l'air très intéressant.
Ça le serait encore plus si on peut l'installer
et l'exécuter _complètement_ depuis l'espace utilisateur
(aucun RPM/deb a installer "system-wide").
Ainsi, un simple utilisateur de cluster pourrait
s'en servir même si le cluster n'est pas équipé
d'un FS distribué.
Voir même, un utilisateur avec des comptes sur
différentes machines Unix s'installe son propre
FS distribue pour ses besoins...
Ça m'intéresserait d'intégrer un FS distribué dans PAR
(cf. http://savannah.nongnu.org/projects/par/) mais je
ne veux pas dépendre de quoi que ce soit qui ne peut
pas s'installer et s'exécuter seulement depuis l'espace
utilisateur (inacceptable pour moi de dépendre d'un truc qui
nécessite les droits d'administrateur).
Bravo Laurent d'avoir dégote ce MooseFS, tes utilisateurs
vont être contents je pense. ;)
Le seul bémol pour MooseFS que je vois: si ce truc nécessite
des droits root pour etre installé, c'est dommage qu'ils utilisent
FUSE. Je crois que passer par FUSE ajoute des copies de données supplémentaires
(par rapport a un FS directement supporte par le noyau).
Ça m'intéresse qu'on m'explique si je me trompe d'ailleurs.
[^] # Re: GlusterFS
Posté par Corentin Chary (site web personnel) . Évalué à 4.
et tu vas comprendre un des problèmes de pleins
de systèmes de fichiers distribués:
c'est assez voire très complique et ça peut demander
une charge d'administration système colossale!
Heu .. franchement GlusterFS, c'est tout ce qu'il y'a de plus simple, une fois le fichier de conf fait (la syntaxe est claire, il y'a des exemples partouts), il suffit de le copier sur tout les noeuds, et de lancer les trucs !
En plus, c'est vachement flexible, et tu peux vraiment faire ce que tu veux.
Et pour ceux qui veulent encore plus simple, ils fournissent un truc avec une interface graphique (web), afin de créer facilement des noeuds dans des VM.
[^] # Re: GlusterFS
Posté par Sytoka Modon (site web personnel) . Évalué à 4.
Glusterfs a beaucoup de choix de mode de fonctionnement. Il faut un peu savoir ce que l'on veut avant de choisir le mode. Je ne pense pas qu'on puisse passer d'un mode à un autre et c'est que je ferais comme critique car ce n'est pas toujours facile de changer de mode car on ne manipule pas aussi facilement que cela des centaines de Téra !
[^] # Re: GlusterFS
Posté par laurent wandrebeck (site web personnel) . Évalué à 2.
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…
[^] # Re: GlusterFS
Posté par laurent wandrebeck (site web personnel) . Évalué à 2.
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 :)
[^] # Re: GlusterFS
Posté par laurent wandrebeck (site web personnel) . Évalué à 1.
Mais je connais assez mal glusterfs, peut-être me trompe-je.
[^] # Re: GlusterFS
Posté par Corentin Chary (site web personnel) . Évalué à 2.
[^] # Re: GlusterFS
Posté par laurent wandrebeck (site web personnel) . Évalué à 1.
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. :)
[^] # Re: GlusterFS
Posté par Corentin Chary (site web personnel) . Évalué à 3.
Tu peux faire du RAID 0, du RAID 1, RAID n, RAID 1+0, RAID 0+1, etc ...
C'est vrai qu'une dêpéche présentant glusterfs serait cool .. là tout de suite, j'ai pas le temps.
Au passage, pour ceux qui utilisent glusterfs: http://git.iksaif.net/?p=glusterfs.git;a=summary mon arbre git avec:
- un plugin de chiffrement du réseau
- des fixs pour les locks (pas franchement rebasé sur la dernière version, ne marche probablement plus)
[^] # Re: GlusterFS
Posté par laurent wandrebeck (site web personnel) . Évalué à 1.
[^] # Re: GlusterFS
Posté par Corentin Chary (site web personnel) . Évalué à 2.
# ceph
Posté par madko (site web personnel) . Évalué à 1.
[^] # Re: ceph
Posté par laurent wandrebeck (site web personnel) . Évalué à 1.
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.
[^] # Re: ceph
Posté par Mathieu Segaud . Évalué à 1.
pkoi ? enfin, mooseFS est utilisable en prod, lui ?
non, parce que les arguments d'autorité, ça va 5 minutes pour parler de ce bidule. mais à un moment, faut être sérieux, et coller de vrais arguments derrière les affirmations très péremptoires qui émaillent cette discussion sur un FS qui me semble encore plus inconnu que Ceph ;)
[^] # Re: ceph
Posté par laurent wandrebeck (site web personnel) . Évalué à 5.
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. »
# Petites corrections
Posté par Davy Defaud . Évalué à 2.
Cependant, il subsiste quelques fautes qui ont échappé à la relecture :
s/système de fichier/système de fichiers/
s/Les fichiers inférieurs à cette taille ne sont bien entendu pas concernés/Les fichiers inférieurs à cette taille ne sont, bien entendu, pas concernés/
s/évènements/événements/ (pour les puristes uniquement, puisque évènement est également accepté...)
[^] # Re: Petites corrections
Posté par laurent wandrebeck (site web personnel) . Évalué à 2.
Mais je ne trouve pas comment éditer la dépêche /o\
[^] # Re: Petites corrections
Posté par Davy Defaud . Évalué à 2.
# Précisions et corrections pour la dépêche.
Posté par laurent wandrebeck (site web personnel) . Évalué à 1.
# et XtreemFS ?
Posté par Lionel Capt . Évalué à 3.
http://www.xtreemfs.org/
Parce que là, avec un commission européenne en soutien et un site Web plutôt bien fourni en documentation, on est quand même plus tenté d'y confier ses données. Je suis d'ailleurs très intéressé à tout retour d'informations sur ce système de fichiers.
[^] # Re: et XtreemFS ?
Posté par klipz . Évalué à 3.
Concernant MooseFS justement, j'ai un petit cluster de 20 To en prod depuis quelques jours, ça semble très très intéressant et prometteur (coucou Laurent, oui je vais bientôt faire le tutoriel pour le HA du mfsmaster).
[^] # Re: et XtreemFS ?
Posté par laurent wandrebeck (site web personnel) . Évalué à 2.
# À propos du metalogger
Posté par laurent wandrebeck (site web personnel) . Évalué à 2.
Bien sûr ça ne permet toujours pas la HA, mais c'est mieux que rien :)
# MooseFS a été intégré dans RPMForge
Posté par laurent wandrebeck (site web personnel) . Évalué à 2.
MooseFS est dorénavant disponible pour CentOS 3, 4 et 5, en i386 et x86_64.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.