MooseFS, système de fichier réparti à tolérance de panne

Posté par (page perso) . Modéré par tuiu pol.
Tags : aucun
21
24
juin
2010
Technologie
MooseFS est un système de fichiers distribué méconnu regorgeant de qualités.

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.
  • # Souvenirs

    Posté par (page perso) . Évalué à 4.

    Cette dépêche me rappelle un journal où on apprenait qu'un FS distribue (faute volontaire) c'était... un FS qui distribue.
    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 (page perso) . Évalué à 5.

      Bah (sans avoir regardé les pages wikipédia) à priori un système de fichier non distribué n'existe que sur un seul volume physique à la fois, ou même si existe sur plusieurs volumes physiques (cas LVM), il n'existe que sur la même machine. Un système distribué est lui réparti sur plusieurs serveurs (et communique via un réseau quelconque) mais n'est vu que comme une unité logique. C'est adapté aux clusters, on regroupe plusieurs serveurs pour faire une énorme unité de stockage qui "s'autogère" via une couhe supérieur au "block device". C'est impossible sur des systèmes de fichiers non distribué (on peut faire de la réplication de fs 'standard' par contre, avec drbd par exemple). En distribué il y'a ocfs2 ou gfs (mais qui en plus permettent l'accès concurent je crois).
      Je dis ptêtre une énorme connerie, mais j'ai toujours compris les fs distribués comme ça.
      • [^] # Re: Souvenirs

        Posté par (page perso) . Évalué à 4.

        Putain on peut pas s'éditer ! :-)

        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 (page perso) . Évalué à 3.

          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.
    • [^] # Re: Souvenirs

      Posté par (page perso) . Évalué à 5.

      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.
      • [^] # Re: Souvenirs

        Posté par (page perso) . Évalué à 3.

        Je ne sais pas si je mérite des explications plus pointues, j'ai peur de faire semblant de comprendre :)
        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.

    Mynd you, møøseFS bites Kan be pretty nasti...

    OK, you should sack me, I guess. Néanmoins comment ne pas y voir une référence quelque part ?
  • # GlusterFS

    Posté par (page perso) . Évalué à 5.

    Dans le même genre, il y a glusterfs qui me semble plus complet et qui a l'avantage de ne pas avoir de noeud maître !

    http://www.gluster.org/
    • [^] # Re: GlusterFS

      Posté par (page perso) . Évalué à 3.

      Essaye d'installer et de configurer un système GlusterFS
      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 (page perso) . Évalué à 4.

        Essaye d'installer et de configurer un système GlusterFS
        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 (page perso) . Évalué à 4.

          Je rajouterais qu'il n'y a pas de serveur de méta-données avec glusterfs et rien que cela, c'est un énorme stress en moins qui vaut bien le coup de passer 5mn de plus sur la configuration.

          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 (page perso) . Évalué à 2.

            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…
      • [^] # Re: GlusterFS

        Posté par (page perso) . Évalué à 2.

        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 :)
    • [^] # Re: GlusterFS

      Posté par (page perso) . Évalué à 1.

      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.
      • [^] # Re: GlusterFS

        Posté par (page perso) . Évalué à 2.

        Franchement, ça dépend de l'architecture que tu as créé avec, et la réplication n'est qu'une option.
        • [^] # Re: GlusterFS

          Posté par (page perso) . Évalué à 1.

          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. :)
          • [^] # Re: GlusterFS

            Posté par (page perso) . Évalué à 3.

            En fait avec glusterfs, ça marche un peu (avec des trucs en plus) comme les disques en RAID.

            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)
  • # ceph

    Posté par . Évalué à 1.

    et par rapport a ceph qui est intégré au noyau me semble, quel avantages/inconvénients? Parcequ'on avait testé GlusterFS c'etait archi simple mais un peu lent, peut etre à cause de FUSE? (ou pas?)
    • [^] # Re: ceph

      Posté par (page perso) . Évalué à 1.

      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.
      • [^] # Re: ceph

        Posté par . Évalué à 1.

        > Ceph a l'énorme problème de ne pas être utilisable en prod. Et pas avant une paire d'années je pense.

        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 (page perso) . Évalué à 5.

          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. »
  • # Petites corrections

    Posté par . Évalué à 2.

    Dépêche de qualité sur un produit très intéressant.

    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é...)
  • # Précisions et corrections pour la dépêche.

    Posté par (page perso) . Évalué à 1.

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

    Posté par . Évalué à 3.

    Me goure-je ou cela ressemble comme 2 gouttes d'eau à XtreemFS ?

    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 . Évalué à 3.

      C'est un peu le même genre, oui. Mais de ce que j'en avais lu, le fonctionnement de XtreemFS est plus "basique" (au niveau du système de réplication) que CEPH ou MooseFS qui répondait exactement à mon besoin... mais j'avoue ne jamais avoir testé XtreemFS du coup, je me suis concentré sur MooseFS.

      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).
  • # À propos du metalogger

    Posté par (page perso) . Évalué à 2.

    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 :)
  • # MooseFS a été intégré dans RPMForge

    Posté par (page perso) . Évalué à 2.

    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.

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.