Publication de FineFS, un système de fichiers répartis

Posté par (page perso) . Modéré par j.
Tags : aucun
16
1
août
2009
Technologie
L'entreprise FineMedia vient de mettre sous licence libre (GPL v3) son système de fichiers FineFS. Ce logiciel permet de créer facilement des clusters disques, afin de partager des données entre plusieurs serveurs.

C'est une solution simple à configurer et peu coûteuse. Les performances sont déjà bonnes, bien que FineFS ait été conçu prioritairement pour les applications Web sans contrainte temps réel forte. FineFS n'est pas un système de fichiers compatible POSIX. Les applications doivent utiliser une bibliothèque dédiée pour accéder aux données du cluster (de manière similaire à Amazon S3 ou GoogleFS).

Le système repose sur des technologies éprouvées (PHP, xinetd, crontab, fichiers écrits sur les filesystems locaux), utilisées de manière astucieuse. Le cas d'utilisation typique prévoit une majorité de lecture de fichiers par rapport aux écritures.

Les fonctionnalités proposées sont :
  • Cohérence des données. Les mêmes fichiers sont accessibles depuis toutes les machines d'un cluster.
  • Robustesse. La détection d'erreur et les mécanismes de ré-essai permettent de contourner les coupures temporaires de machines, sans perte de données. La conception totalement décentralisée supprime les "single point of failure".
  • Performance. La synchronisation de données à travers le cluster se fait à la fois de manière synchrone et asynchrone. La recopie des données permet d'accéder aux fichiers en local la plupart du temps.

FineFS permet de se passer de l'achat d'un coûteux système à base de SAN (Storage Area Network), d'avoir un système plus robuste qu'avec un simple serveur de fichier (NAS, ou Network Attached Storage), et plus simple à administrer que les systèmes de fichiers distribués existants (Coda, Ceph, POHMELFS, GlusterFS, GfarmFS...).

FineMedia est une startup parisienne ; FineFS est à la base de son système de gestion de médias (qui sera bientôt mis sous licence libre à son tour).
  • # GlusterFS ?

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

    Pour avoir installé GlusterFS sur un petit cluster pour faire un gros disque réseau, je ne suis pas d'accord avec ce qui est dit sur le site:

    It is possible to set up a distributed filesystem, like Coda, Ceph, POHMELFS, GlusterFS, GfarmFS, ... But these systems may have some technical restrictions or different design goals (like computing grid), and they are hard to install and maintain.


    Je comprends qu'il faille _vendre_ FineFS, mais dire que GlusterFS est difficile à installer et maintenir (le cluster de semi-prod que j'utilise mélange stable, old stable et old-old stable Debian, le tout avec bonheur...), c'est un peu fort à mon goût.

    Enfin, d'après ce que j'ai cru comprendre, FineFS est plutôt une librairie d'accès à un filesystem qu'un FS à lui tout seul (pas POSIX ?)...
    • [^] # Re: GlusterFS ?

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

      Je suis d'accord avec toi. Lorsque je lis PHP et ensuite que ce n'est pas POSIX, je trouve les comparatifs quand même plus qu'osés...

      Maintenant, pour être vraiment généralisable, il faut pouvoir monter le système de fichier et le tester de manière classique. Sinon, cela restera un produit de niche.
      • [^] # Re: GlusterFS ?

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

        FineFS n'est pas POSIX parce que ce n'est pas une nécessité. L'exemple de MogileFS est cité dans un autre commentaire ; il n'est pas POSIX non plus, et ça ne l'empêche pas de remplir son rôle.

        Si la compatibilité POSIX devient un élément important, on verra pour le développement d'un driver FUSE.

        FineFS ne se destine pas à être généraliste, mais à répondre à un certain besoin de la meilleure manière possible. Le fait qu'il soit écrit en PHP a permis un développement rapide, pour une diminution des performances extrêmement faible par rapport à ce à quoi nous nous attendions.
      • [^] # Re: GlusterFS ?

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

        Ah, au fait, Tahoe est écrit en Python, et MogileFS en Perl...

        ;-)
        • [^] # Re: GlusterFS ?

          Posté par . Évalué à 2.

          L'un au moins de ces deux langages est beaucoup plus rigoureux (et a un jeu de bibliothèques beaucoup plus fourni) que PHP.
    • [^] # Tahoe

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

      En fait, cela me fait plus penser à Tahoe

      http://allmydata.org/trac/tahoe

      Qu'elle est la particularité de FineFS par rapport à Tahoe ?
      • [^] # Re: Tahoe

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

        Tahoe est très intéressant, mais ses buts sont différents. La volonté de préserver les données du regard des administrateurs système les a amené à créer un système très fort du point de vue cryptographique.

        L'un des postulats de départ de FineFS est que le cluster s'exécute dans un environnement non hostile. Il n'y a pas de gestion de droits utilisateur, et encore moins d'encryption des données. Cela conduit à un code plus simple.

        Un élément important de la conception de FineFS a été la volonté de réduire au maximum les communications réseau. Les données sont accessibles en local la plupart du temps. Et si l'utilisateur qui accède aux données est le même que celui qui gère le noeud FineFS local, il n'y a même pas d'ouverture de socket. Le but est de réduire au maximum les latences d'accès aux fichiers.

        Dans le cas d'un frontal web (qui est le cas d'utilisation typique de FineFS), la livraison d'un fichier statique se fait directement depuis le disque local, sans transfert réseau ni recopie de données en mémoire - en tout cas, sans plus de recopie que celles faites en interne par PHP quand on fait un readfile().
    • [^] # Re: GlusterFS ?

      Posté par . Évalué à 4.

      Oui apparemment ce n'est pas un filesystem, mais plutôt quelque chose comme MogileFS.

      Bof, j'en reste au bon vieux Cloudstore.
      • [^] # Re: GlusterFS ?

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

        Effectivement, la démarche de FineFS se rapproche de celle de MogileFS. Mais il y a quelques différences de conception, la principale étant que MogileFS nécessite une base de données centralisée (et monter une architecture MogileFS redondée au niveau de la base de données est d'un seul coup bien plus complexe).

        Cloudstore est plutôt utilisé par des programmes basés sur le paradigme map-reduce, non ?
    • [^] # Re: GlusterFS ?

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

      Je comprends qu'on puisse se dire que FineFS n'est pas en compétition directe avec les autres systèmes que j'ai cité. Mais si on regarde l'utilisation concrète qu'on en fait, on se rend compte qu'il peut être utilisé dans certains des cas où GlusterFS pourrait être utilisé, mais aussi dans les cas où Amazon S3 est utilisé. Il n'y a pas qu'un seul type de solution acceptable pour répondre au besoin.

      GlusterFS est un système qui fonctionne très bien. Mais dans la mesure où les serveurs mettent à disposition leur espace de manière assez simple, la complexité est déportée sur les clients, qui doivent maintenir la cohérence des données à travers le cluster. Les données transitent par le réseau, ce qui incite à l'employer sur des infrastructures assez complexes, sur de très gros clusters connectés en Infiniband - même si, je le repète, GlusterFS fonctionne très bien sur des architectures plus communes.

      FineFS est plus simple dans sa conception, et ne vise pas des architectures aussi importantes. L'utilisation typique est le cluster de frontaux web, sur lesquels on peut stocker les données en local pour éviter de faire passer les données sur le réseau. Et sur ce type de cluster, il fonctionne vraiment bien.

      Accessoirement, FineFS permet d'associer des méta-données aux fichiers stockés, sans pour autant passer par un serveur central. Et contrairement à GlusterFS, c'est un système répliqué uniquement (et non réparti).
      • [^] # Re: GlusterFS ?

        Posté par . Évalué à 4.

        Cela ressemble un poil à memcache ?

        "La première sécurité est la liberté"

        • [^] # Re: GlusterFS ?

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

          Non, pas du tout. Pour commencer, memcache sert à stocker des données sous forme de clé-valeur, pas une arborescence de fichiers binaires. Les buts visés par FineFS se rapprochent plutôt de ceux visés par MogileFS (par les mêmes créateurs que memcache).

          Au niveau technologique, les données de memcache ne sont pas répliqués, mais réparties. Lorsqu'on a plusieurs serveurs memcache, chaque client va calculer automatiquement sur quel serveur il va aller la stocker ou la récupérer. Si un serveur tombe, la donnée est perdue, mais ce n'est pas un problème (une donnée mise en cache doit pouvoir être recalculée sans trop d'effort, on perd juste ponctuellement le gain de vitesse du cache).
          • [^] # Re: GlusterFS ?

            Posté par . Évalué à 4.

            Quel genre d'api vous utiliser ? Une sorte de sémantique proche de celle du web ? (genre un fichier est un bloc complet et il n'y a pas lock, de seek ou autre ?)

            "La première sécurité est la liberté"

            • [^] # Re: GlusterFS ?

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

              Effectivement, les fichiers sont accédés en entier. L'approche de FineFS est de servir rapidement des fichiers de taille raisonnable. Il ne se destine pas à gérer des fichiers de plusieurs centaines de megas (même si c'est faisable) ou de plusieurs gigas ; d'autres filesystems orientés data-grid sont plus efficaces pour cela.

              Le cas d'utilisation typique, je le rappelle, est la ferme de serveurs web. Chaque serveur est susceptible d'ajouter de nouveaux fichiers (par exemple des images, des musiques, des vidéos), qui seront ensuite accédés par n'importe quel autre serveur (soit pour modification, soit pour envoyer le fichier à un utilisateur). L'idée est d'accéder rapidement à des fichiers complets, pas de permettre des accès sur des portions de fichiers ; pas de lock, pas de seek.

              L'API complète, avec des exemples d'utilisation, est disponible dans la documentation : http://code.google.com/p/finefs/wiki/CodePhp
              • [^] # Re: GlusterFS ?

                Posté par . Évalué à 4.

                Ok, vous dégagez tous les truc pas simple POSIX. Pourquoi pas.

                Est-ce que vous gérez l'atomicité de remplacement de fichier ? Genre un nouveau fichier est écrit, si un autre fichier cherche à le lire, il aura le précédent ou le nouveau, mais pas une erreur ou un truc mélanger ou tronqué.

                Est-ce que vous gérez un système d'envois en "2 bandes" ? En gros, est-ce que le système de fichier pourrait envoyer directement un fichier à un client sans repasser par un serveur web ? Je me suis toujours demandé comme faire une réponse en utilisant 2 machines, sans repasser par la 1er et sans proxy.

                "La première sécurité est la liberté"

                • [^] # Re: GlusterFS ?

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

                  Je ne suis pas certain de comprendre ta deuxième question. Un client ne passe pas par un serveur Web pour récupérer un fichier, FineFS a son propre protocole. Je ne peux que conseiller d'aller faire un tour sur le site du projet, il y a des exemples qui expliquent comment fonctionne FineFS.

                  Pour répondre au reste, on ne cherche pas à faire plus qu'un système de fichier habituel. Si tu as deux processus qui lisent et écrivent dans le même fichier au même moment sur une partition Ext3, tu risques d'avoir quelques surprises. Je sais que c'est justement pour cela que les filesystems offrent le lock, mais très sincèrement je n'ai pas vu beaucoup d'applications Web qui en avaient l'utilité. Il y a beaucoup plus à gagner de faire un système simple et très efficace, quitte à laisser les cas très particuliers être gérés par les applications en utilisant des systèmes supplémentaires (sémaphore, système de file d'attente partagée, base de données, ...).
                  • [^] # Re: GlusterFS ?

                    Posté par . Évalué à 2.

                    En gros, le client peut y accéder directement.

                    Concernant l'atomicité, je pensais à un fichier modifié (modif d'une image par exemple), relus immédiatement (affichage). Tu veux dans ce cas la nouvelle image ou l'ancienne, mais pas un truc entre les 2. Ici, cela n'est pas gênant mais imagine une sauvegarde qui aurait un "bout d'image".

                    C'est pas vraiment une histoire de lock, si ton système ne donne pas la possibilité de connaitre l'état des données, c'est difficile à faire au niveau applicatif (le plus simple est de retourner la vieille version tant que la nouvelle n'est pas complètement dans le système)

                    "La première sécurité est la liberté"

                    • [^] # Re: GlusterFS ?

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

                      OK, je vois ce que tu veux dire.

                      En fait, FineFS est à la fois (plus ou moins) synchrone et (totalement) asynchrone. C'est bien expliqué sur le site du projet. Lorsqu'un fichier est créé, ou mis à jour, la nouvelle version du fichier est immédiatement disponible en local ; c'est assez logique.
                      Là où ça se complique, c'est sur les autres machines du cluster. Mais FineFS repose sur un découpage en 2 étapes. Je m'explique.

                      Quand un fichier est mis à jour, une information est envoyée au serveur suivant du cluster, qui la transmet au serveur suivant, qui la transmet au serveur suivant, etc. Cette information fait très vite le tour du cluster (c'est un paquet de moins de 150 octets en moyenne). Dès qu'un noeud reçoit cette information, il met à jour sa connaissance du fichier, et efface sa version locale du fichier binaire.

                      En fait, lorsque quelqu'un réclame le fichier sur un serveur (autre que le serveur d'origine qui a reçu la nouvelle version du fichier), il existe 3 cas possibles :
                      1) L'information de mise-à-jour n'a pas encore été reçue (cas plus théorique que pratique). Dans ce cas, le fichier binaire n'a pas encore été effacé, et c'est la version précédente du fichier qui est délivrée depuis le disque local.
                      2) L'information de mise-à-jour a été reçue, le fichier binaire local a été effacé, mais les mécanismes de réplication asynchrone n'ont pas encore ramené en local la nouvelle version du fichier. Dans ce cas, FineFS va récupérer le fichier auprès de son serveur d'origine, l'enregistrer en local, et le délivrer à l'application qui le demandait.
                      3) L'information de mise-à-jour a été reçue, et la réplication a déjà amené le nouveau binaire jusqu'au serveur. Dans ce cas, la dernière version du fichier est directement délivrée à l'application.

                      Donc il n'y a pas de problème de cohérence de données. Pour les applications visées, on peut se satisfaire de savoir qu'on a toujours la dernière ou l'avant-dernière version d'un fichier ; sachant que les cas où on va récupérer l'avant-dernière version sont globalement rares.

                      Quand je dis que FineFS est plus-ou-moins-synchrone, c'est parce qu'une écriture n'est pas bloquante : on n'attend pas que tous les noeuds reçoivent l'information pour dire que l'écriture est réussie. Mais on peut considérer que l'écriture ne sera connue de l'ensemble du cluster que lorsque le message d'information en aura fait le tour (ce qui est très rapide vu la légèreté de ce message).

                      Cf. Eventually Consistent : http://www.allthingsdistributed.com/2008/12/eventually_consi(...)

                      Et quand je dis que FineFS est aussi totalement asynchrone, c'est que la recopie des données d'un serveur à un autre peut se faire de 2 façons : soit par le mécanisme de réplication, soit à la demande lorsqu'une machine demande un fichier qui n'est pas disponible en local.
                      • [^] # Re: GlusterFS ?

                        Posté par . Évalué à 2.

                        Ok, vous êtes en replication en écriture. A priori, si le taux de lecture est très fort, c'est un bon système.

                        Par contre, dans le cas d'écriture fréquente, c'est pas forcément le top. Vous devriez laisser la possibilité de désactiver la réplication asynchrone pour certain fichier/répertoire souvent mis à jour. J'imagine qu'avec les appli web, cela deviendra de plus en plus fréquent.

                        "La première sécurité est la liberté"

                        • [^] # Re: GlusterFS ?

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

                          Nous avons effectivement fait le choix d'optimiser les lectures, ce qui tient debout pour des applications web. Il faut voir que sur la plupart des architectures Web, c'est le trafic externe qui coûte, pas le trafic interne.

                          Il est complètement illusoire de faire un système qui fonctionne à la perfection aussi bien en écriture qu'en lecture, sur des petits fichiers comme sur des gros ensembles de données, qui soit à la fois distribué et réparti, avec une charge CPU proche du zéro, une consommation réseau pratiquement nulle,et une latence inférieure à celle d'un disque SSD.

                          Désactiver la réplication asynchrone n'est absolument pas à l'ordre du jour. Cela permettrait juste de réduire une partie du trafic réseau, mais on risquerait la perte de données. Non, cela va complètement à l'encontre des buts de FineFS.

                          Ce serait comme demander au GoogleFS (je parle du filesystem utilisé en interne dans les datacenters de Google, pas du montage de GMail) d'être efficace sur des petits fichiers, alors qu'il a été conçu pour des fichiers pesant des centaines de mégas voire des gigas. Ou de demander à la base Dynamo d'Amazon de gérer les données de manière relationnelle, alors que son but est justement de ne pas être relationnel pour gagner en performance.
                          • [^] # Re: GlusterFS ?

                            Posté par . Évalué à 2.

                            En plus simple, tu veux dire que tu perds la réplication.

                            "La première sécurité est la liberté"

                            • [^] # Re: GlusterFS ?

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

                              Ta suggestion était 'Vous devriez laisser la possibilité de désactiver la réplication asynchrone'.

                              Donc oui, en plus simple, si on désactive la réplication, on perd possiblement la réplication ;-)

                              En fait, en désactivant la réplication asynchrone, on ne repose plus que sur les demandes de fichiers pour répliquer les données. Par exemple, disons que le serveur A contient le fichier X ; si le serveur B a besoin du fichier X, il va le réclamer à A. Mais si A tombe en panne avant que B n'ait eu besoin du fichier, et qu'on avait désactivé la réplication qui aurait copié automatiquement le fichier de A vers B, ce fichier est perdu. Ce n'est pas une bonne idée.
                              • [^] # Re: GlusterFS ?

                                Posté par . Évalué à 2.

                                Disons que dans un fort taux d'écriture sur un cluster de 10 machines, tu passes ton temps à te refiler le fichier. Avec simplement l'information d'invalidation, tu ne va chercher le fichier que si il est demandé.

                                Pour garder la réplication, une triple copie suffit pas la peine d'inonder le cluster (cela pourrait se faire avec un TTL si il y a une topologie anneau).

                                Je faisais la différence entre la réplication d'écriture en vue d'augmenter le potentiel de lecture (ce que vous faite) devant la réplication en lecture qui ne fait que propager un message d'invalidation plus léger que le fichier à transmettre.

                                Si vous voulez aussi de la réplication, il n'y a pas besoin de faire la copie totale.

                                Un fichier ayant beaucoup d'écriture pourrait être l'information de session avec sauvegarde de l'état précédent.

                                "La première sécurité est la liberté"

                                • [^] # Re: GlusterFS ?

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

                                  Oui, c'est évidemment une question que nous nous sommes posé durant la conception de FineFS. Mais cela reste un choix pleinement assumé.

                                  S'il fallait résumer les buts de FineFS, on pourrait les simplifier à seulement 2 points : être rapide en lecture, et garder un code le plus simple possible.

                                  Gérer le nombre de recopies d'un fichier complexifie les choses de manière exponentielle. Non seulement il faut savoir où est présent un fichier, mais il faut être capable de gérer les réplications supplémentaires quand une machine tombe.

                                  Encore une fois, FineFS ne se destine pas à recopier à l'identique des concepts déjà développés dans d'autres systèmes. Il y a des cas où il vaudra mieux utiliser GlusterFS, Lustre, Peerfuse, ChironFS, Coda, Ceph, ZFS, ... Ce ne sont pas les solutions qui manquent.
                                  Notre problématique est de réduire au maximum les latences d'accès aux fichiers. Cela veut donc dire qu'il faut réduire les lectures sur le réseau. On ne peut pas se contenter de réduire les écritures réseau, car le résultat direct est une augmentation des lectures réseau.

                                  Nos axes d'amélioration passent d'ailleurs plutôt sur la mise en place de noeuds ayant un cache qui ne contient qu'une partie des données du cluster. Mais là aussi, cela a un coût : il faut compter le nombre d'accès à chaque fichier, pour savoir lesquels on peut effacer quand on commence à manquer de place en cache pour ajouter un nouveau fichier. On peut se dire que c'est un calcul insignifiant, mais c'est pourtant impactant vis-à-vis de nos objectifs de performance.

                                  On peut aussi faire un calcul très simple (peut-être un peu simpliste, mais bref). Imaginons un cluster de 9 machines. On ajoute un nouveau fichier sur le cluster.
                                  En écriture :
                                  - FineFS : Le fichier sera copié de la 1ère machine à la 2ème, puis de la 2ème à la 3ème, et ainsi de suite. (total : 9 copies réseau)
                                  - Ta proposition : Le fichier sera copié sur 3 machines. (total : 3 copies réseau)
                                  En lecture :
                                  - FineFS : Lecture en local. C'est simple et rapide, quelque soit le nombre de lectures sur le fichier.
                                  - Ta proposition : Il y a 1 chance sur 3 que le fichier soit présent en local. Si on fait 2 lectures du fichier, on a 1 chance sur 9 de l'avoir en local. Avec 3 lectures on passe à 1 chance sur 27 en moyenne.

                                  Si on se dit que le rapport moyen est effectivement de 3 lectures pour une écriture (et sincèrement, sur du Web, il y a beaucoup plus de lectures pour une écriture), ça nous donne :
                                  - FineFS : 9 copies réseau + 3 lectures locales.
                                  - Ta proposition : 3 copies réseau (initiales) + 26 copies réseau (au moment des lectures) + 1 lecture locale.

                                  Je sais bien qu'il est impensable de mettre en place ce genre d'architecture sans penser à utiliser un cache local. Le calcul complet fait intervenir la taille moyenne d'un fichier et la taille moyenne des caches sur chaque machine. Mais je voulais pointer du doigt que toute solution technique a forcément des inconvénients. Les choix de conception de FineFS ont été murement réfléchis.

                                  Enfin, tu donnes l'exemple d'un fichier qui pourrait contenir des informations de session. Il y a vraiment des gens qui stockent leurs données de session dans des fichiers ? Une base de données me semble plus indiquée. Mais même en imaginant qu'on veuille utiliser FineFS pour cela, on aurait intérêt à utiliser les méta-données associées aux fichiers ; ainsi, ces informations seraient disponibles très rapidement sur les noeuds du cluster.
                                  • [^] # Re: GlusterFS ?

                                    Posté par . Évalué à 2.

                                    Concernant l'utilisation d'un cache, j'y crois moyen. L'exemple de google où toutes les machines sont identiques prouvent que c'est possible.

                                    J'imagine que FineFS est utilisé sur les serveurs web également en front-end pour être toujours en accès fichiers local.

                                    Quel serait l'intérêt d'un cache ? Si ce n'est rajouter une couche à FineFS pour simuler un comportement différent dans certain cas.

                                    Autant gérer un cache RAM au niveau de FineFS, non ? (voir s'arranger pour que linux dessous fasse le boulot). Par exemple, toutes les méta données pourraient toujours être présente en RAM.

                                    "La première sécurité est la liberté"

                                    • [^] # Re: GlusterFS ?

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

                                      L'intérêt du cache serait de ne pas obliger toutes les machines du cluster à stocker l'intégralité des données. Ainsi, on pourrait imaginer un cluster où certaines machines ont de très gros disques et stockent toutes les données, pendant que les autres machines - qui ont des disques de taille plus raisonnable - stockent en local les fichiers les plus utilisés.
                                      C'est assez évident pour une infrastructure dans laquelle les serveurs frontaux (qui ont besoin des fichiers) ont rarement des disques de plusieurs téra-octets, alors que l'ensemble du cluster est susceptible de stocker des téras au final. C'est plus efficace, toujours dans l'optique de lire en local les fichiers dont on va avoir besoin le plus souvent.

                                      Maintenant, je suis d'accord que ça va complexifier le code de FineFS. Mais c'est moins complexe à gérer qu'un système où les fichiers ne sont répliqués que sur certaines machines (ta proposition précédente).
                                      Donc, on codera sûrement un jour ce système de cache, mais en séparant intelligemment le code, pour ne pas charger la partie qui gère le cache si on n'en a pas besoin.

                                      On ne va pas gérer un cache RAM. Pour commencer, FineFS est sans état. Même le démon n'est pas chargé en mémoire de manière continuelle (il est lancé par xinetd). Ensuite, ça complexifierait le code inutilement ; même le jour où on voudra stocker les méta-données dans une base de données, on le fera sûrement en utilisant SQLite plutôt qu'en gardant les infos en RAM.
                                      Parce que garder un cache en RAM, c'est plus facile à dire qu'à faire de manière stable et efficace. Il faut mettre en place de la communication inter-processus, avec de la mémoire partagée ou un démon local sur lequel il faut se connecter (et hop, encore une ouverture de socket en plus !). Non, le gain est trop faible et hypothétique pour se lancer là-dedans.
                                      • [^] # Re: GlusterFS ?

                                        Posté par . Évalué à 2.

                                        Si tu sépares les types de machines, tu diminuent la complexité du SW en complexifiant la topologie du hardware. A la limite, gères cela dans FineFS pour que l'ajout/disparition de noeud soit facile.

                                        Pour le cache en local, tu peux toujours faire tourner localement un memcache :)

                                        "La première sécurité est la liberté"

                                        • [^] # Re: GlusterFS ?

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

                                          Non, c'est l'inverse : Si on ajoute la gestion de 2 types de machines (les noeuds globaux et les noeuds avec cache), cela va augmenter la complexité du software (des cas supplémentaires à gérer) pour diminuer les prérequis sur le hardware (pas besoin que toutes les machines aient des disques assez gros pour contenir toutes les données du cluster).

                                          C'est une question complètement décorrélée de la problématique de l'ajout/suppression de machines à chaud, qui reste compliquée qu'il y ait un seul type de noeuds ou deux.

                                          Pour le reste, on a sérieusement pensé à memcache (on l'utilise déjà pour le cache des applis web). Mais au final, c'était une fausse bonne idée : la récupération d'un fichier de moins de 200 octets n'est pas drastiquement plus rapide via memcache qu'en le lisant sur le disque. Il y a des couches logicielles en plus, des ouvertures de sockets, des copies de données... sans parler du fait de devoir gérer les éventuels problèmes de connexion sinon on risque d'avoir tout le système qui tombe (ou simplement qui ralentit) parce que memcache est en rade.

                                          Même si ça s'éloigne des buts de FineFS, il serait intéressant (d'un point de vue théorique) de stocker les méta-données dans une base de données (je donnais l'exemple de SQLite, dont la philosophie s'accorde bien à celle de FineFS). Ainsi, il serait possible de rechercher des fichiers à partir de leurs méta-données, et non pas simplement récupérer des méta-données à partir du nom de fichier.
                                          Cela permettrait d'avoir un système de données non relationnel (cf. Dynamo d'Amazon ou Cassandra de Facebook) qui resterait très performant même sur un très grand nombre de serveurs. Bon, je reste quand même persuadé que sur une architecture classique cela n'a pas un grand intérêt par rapport à une base de données traditionnelle (toutes les applis web utilisent un MySQL/Postgresql/Oracle quelque part)...
                                          • [^] # Re: GlusterFS ?

                                            Posté par . Évalué à 1.

                                            Même si ça s'éloigne des buts de FineFS, il serait intéressant (d'un point de vue théorique) de stocker les méta-données dans une base de données (je donnais l'exemple de SQLite, dont la philosophie s'accorde bien à celle de FineFS).

                                            Je croyais que tu voulais des perf ? Les meta donnés ne sont pas des ACL ?

                                            Bon, je reste quand même persuadé que sur une architecture classique cela n'a pas un grand intérêt par rapport à une base de données traditionnelle (toutes les applis web utilisent un MySQL/Postgresql/Oracle quelque part)...

                                            Les perfs ? :) Elle sont franchement bof pour la plus part des sites web. Cela me rappelle la remarque de Google lors d'une conf avec des journaux papiers: "il est plus rapide de lire vos journaux papiers" sous-entendu "tellement vos site sont lents".

                                            "La première sécurité est la liberté"

                                            • [^] # Re: GlusterFS ?

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

                                              Oui, c'était juste une digression, pour partager mes réflexions avec vous ;-)
                                              Le but premier de FineFS est (et restera) d'accéder rapidement à des fichiers statiques.

                                              Il n'empêche que les méta-données sont librement utilisables par les applications. Notre couche de gestion des médias (qui devrait bientôt passer sous licence libre) utilise les méta-données pour stocker les informations de type ACL (accès publique ou privé), les durées de mise en cache (côté client) et les types MIME. Mais les applications peuvent ajouter les métas dont elles ont besoin.

                                              Alors oui, un système de gestion de données non relationnelles peut apporter des performances intéressantes. Mais ce n'est pas une orientation courante dans le développement d'applis web.

                                              Bref, on est en train de s'éloigner du sujet, là...
                                              • [^] # Re: GlusterFS ?

                                                Posté par . Évalué à 2.

                                                Vous n'utilisez pas le système d'ACL de Linux pour vos méta-données ? Cela doit être pourtant très performant.

                                                "La première sécurité est la liberté"

                                                • [^] # Re: GlusterFS ?

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

                                                  Non. Toujours dans l'optique de «faisons simple et éprouvé», il est plus facile d'administrer le cluster quand on peut voir les fichiers de méta-données en faisant un simple 'ls' ou 'tree', et quand on peut voir les méta-données en faisant un simple 'more'.
                      • [^] # Re: GlusterFS ?

                        Posté par . Évalué à 1.

                        2) L'information de mise-à-jour a été reçue, le fichier binaire local a été effacé, mais les mécanismes de réplication asynchrone n'ont pas encore ramené en local la nouvelle version du fichier. Dans ce cas, FineFS va récupérer le fichier auprès de son serveur d'origine, l'enregistrer en local, et le délivrer à l'application qui le demandait.

                        Et que se passe-t-il si le fichier est à nouveau en train d'être modifié par le serveur d'origine au moment où l'on souhaite le récupérer ? C'est à dire un scénario comme ceci :

                        - serveur1 commence à modifier le fichier
                        - serveur1 a fini de modifier le fichier
                        - serveur 1 envoie une notification de modification
                        - serveur2 a besoin du fichier
                        - serveur1 recommence à modifier le fichier
                        - serveur2 récupère le fichier
                        - serveur1 a fini de modifier le fichier


                        Quelle version serveur2 récupère-t-il ? Et surtout est-ce qu'il récupère un fichier cohérent.

                        Étienne
                        • [^] # Re: GlusterFS ?

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

                          Très bon exemple, qui correspond à la partie sur laquelle je suis en train de travailler en ce moment ! ;-)

                          Tel que le code existe pour le moment (version 0.3.0, donc instable), le serveur 2 récupérera le fichier en cours de modification (donc incomplet). Pour reprendre un exemple que j'ai déjà cité, c'est exactement ce qui se passera si tu as un programme qui lit un fichier sur un filesystem Ext3 local, alors qu'un autre programme est en train d'écrire dedans. C'est au niveau applicatif qu'il faut gérer cette possibilité (lock sur le fichier, sémaphore, ...).

                          Mais la version stable de FineFS permettra d'avoir toujours un état cohérent. Dans ton exemple, le serveur 2 récupérera alors la première version du fichier. La nouvelle version ne sera disponible qu'une fois l'écriture terminée.
  • # Cohérence

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

    Rien qu'à lire la phrase en français, je dirais qu'il y a un anglisisme utilisé, "Consistance des données." devrais sûrement être "Cohérence des données.".

    Après avoir regardé le lien, effectivement la VO dit "Data consistency.", ce qu'on peut traduire par "Cohérence des données.", c'est à dire que les données sont identiques partout.

    Ça ne retire rien à l'article, mais j'aime bien être précis.
  • # Configuration des noeuds

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

    Sur la page suivante, on voit une config

    http://code.google.com/p/finefs/wiki/InstallationInstruction(...)

    C'est un peu pénible d'avoir un fichier différent pour chaque noeud. Cela signifie que ce fichier ne peut pas être déployés brut de brut.

    Le serveur ne pourrait-il pas détecter que peers[]=arnold, c'est lui même et transformer cette ligne en local=arnold ?
    • [^] # Re: Configuration des noeuds

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

      Je comprends que cela puisse sembler pénible. Mais sur un cluster de quelques noeuds, ce n'est pas trop gênant, et c'est ce qu'il y a de plus facile à comprendre et à développer. Parce que recopier la même liste sur tous les noeuds soulevait des problèmes inutiles (recalculer systématiquement où le serveur local se situe dans la boucle de machines, par exemple).

      Par contre, nous réfléchissons à développer un serveur de configuration, qui enverra aux différents noeuds les informations dont ils ont besoin pour s'insérer correctement dans le cluster. Il n'y aurait ainsi qu'une seule configuration à maintenir, ce qui faciliterait le travail d'administration. Si ce serveur spécial tombait en panne, cela n'empêcherait pas le cluster de fonctionner. Nous travaillons dessus.
      • [^] # Re: Configuration des noeuds

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

        cfengine est ton amis ;-)
        • [^] # Re: Configuration des noeuds

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

          Non, parce que ce serveur de configuration aura aussi des fonctionnalités supplémentaires. Par exemple, lorsqu'on voudra ajouter un noeud supplémentaire dans un cluster (fonctionnalité actuellement impossible à chaud), ce noeud avertira le serveur de conf de sa présence, qui pourra redistribuer l'information aux serveurs actifs.
  • # Applications Web sans contrainte temps réel forte!?

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

    Meuuuuh, je sais pas vous mais pour moi cette phrase ne veut rien dire :

    Système Temps réel = système qui délivrer des résultats exacts et dans des délais imposés.

    C'est quoi une Application Web avec contraintes temps réel forte? Une application web qui donne l'heure? ;-)
    • [^] # Re: Applications Web sans contrainte temps réel forte!?

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

      Le sens de la phrase est de dire que FineFS a été développé prioritairement pour des applications Web, donc pour des applications qui n'ont pas de contraintes temps réel fortes.

      A contrario, une application avec des contraintes temps réel fortes ferait mieux de se tourner vers un système utilisant des données centralisées (MooseFS, Chirp, Lustre, GfarmFS). Parce qu'il existe un risque théorique qu'une donnée créée sur une machine soit demandée quasi-immédiatement sur une autre machine du cluster, alors que celle-ci n'a même pas encore reçu l'information d'existence du fichier.

      En pratique, c'est un cas qui ne pourrait arriver qu'avec un très gros cluster (dépasser la centaine de machines) qui ne serait pas en Ethernet gigabit, ou si un noeud du cluster était ponctuellement tellement chargé que cela induirait des latences sur tout le cluster.

Suivre le flux des commentaires

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