Journal : Peerfuse, filesystem distribué
Posté par Romain Bignon (Jabber id, page perso, ) le 01 mai 2008
Peerfuse est un système de fichier distribué pair à pair écrit en C++ avec la bibliothèque FUSE et initié il y a quelques mois.
Le projet, dont une description peut être lue ici, a pas mal avancé et une version 0.1 va paraître d'ici quelques jours.
Bien évidemment, beaucoup reste à faire, la release a pour unique but de présenter à la communauté les bases d'un projet qui est déjà fonctionnel mais limité.
Vous pouvez voir ici les fonctionnalités actuellement implémentées, et ici une description de nos premiers essais sur internet du projet.
C'est un projet assez novateur et dont les tentatives similaires (mais n'ayant pas le tiers des fonctionnalités que nous proposons) sont toutes tombées à l'eau. Je pense que les développeurs de Peerfuse ont la volonté suffisante pour que ça ne soit pas le cas avec ce projet.
Si vous êtes intéressé par ce projet, que ça soit en tant que contributeur ou même en tant qu'utilisateur, vous pouvez trouver quelques informations sur le site, http://peerfuse.org, ainsi que sur le salon IRC dédié au projet, #peerfuse@freenode.
En outre, les développeurs et divers futurs contributeurs ont prévu de boire un verre vendredi 2 mai à 19h00 au Dock's café (Paris XIXe, un plan d'accès se trouve sur leur site) afin d'échanger sur le projet autour d'une bonne bière. N'hésitez pas à passer.
Le projet, dont une description peut être lue ici, a pas mal avancé et une version 0.1 va paraître d'ici quelques jours.
Bien évidemment, beaucoup reste à faire, la release a pour unique but de présenter à la communauté les bases d'un projet qui est déjà fonctionnel mais limité.
Vous pouvez voir ici les fonctionnalités actuellement implémentées, et ici une description de nos premiers essais sur internet du projet.
C'est un projet assez novateur et dont les tentatives similaires (mais n'ayant pas le tiers des fonctionnalités que nous proposons) sont toutes tombées à l'eau. Je pense que les développeurs de Peerfuse ont la volonté suffisante pour que ça ne soit pas le cas avec ce projet.
Si vous êtes intéressé par ce projet, que ça soit en tant que contributeur ou même en tant qu'utilisateur, vous pouvez trouver quelques informations sur le site, http://peerfuse.org, ainsi que sur le salon IRC dédié au projet, #peerfuse@freenode.
En outre, les développeurs et divers futurs contributeurs ont prévu de boire un verre vendredi 2 mai à 19h00 au Dock's café (Paris XIXe, un plan d'accès se trouve sur leur site) afin d'échanger sur le projet autour d'une bonne bière. N'hésitez pas à passer.
> Lire le journal (18 commentaires, moyenne: 3,3).
Vous avez demandé le commentaire #927726.
Run by 
Cette page a été générée par Templeet en 0.0489s (dont 0.0043 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Algo ?
Il y a un endroit ou l'on peut voir les algo utilisés pour répartir les données et pour les retrouver ? C'est les 2 trucs les plus dures à faire quand il y a 10 000 noeuds au système. (d'ailleurs cela me fait penser que l'inria avait mis au point un programme de copie distribuée utilisée par la Clic de Mandriva dans le but mettre à jour un cluster de façon p2p pour ne pas tuer le serveur de fichier).
[^]Re: Algo ?
La répartition des données est actuellement simple : le premier pair qui met un fichier sur le réseau le possède, puis après chaque pair qui récupère ce fichier (en tentant de le lire ou en faisant un cp, par exemple) le partagera lui aussi.
Par la suite, il y aura un système de création de redondance automatique. C'est à dire que pour éviter que la disponibilité d'un fichier repose sur un seul pair tant que personne ne l'a récupéré, au moment de la création de celui-ci, quelques pairs le récupèreront automatiquement et le stockeront dans leur cache.
Pour retrouver les fichiers, nous utilisons (sur peerfuse-net) un système de distribution de l'arbre. C'est à dire que pour chaque fichier, il y a des pairs responsables. Connaître les responsables passe en gros par un hash du path du fichier, utilisé dans une formule pour retrouver les IDs à partir de la liste triée. Cela implique malheureusement un changement de responsables lorsqu'un pair joint ou quitte le réseau, et ainsi que les anciens responsables envoient les messages de mise à jour aux nouveaux responsables. Note que des optimisations sont possibles mais non effectuées encore.
Tu trouveras plus d'informations (et l'algorithme) là dessus ici : https://anonymous:@piggledy.org/svn/peerfuse/trunk/doc/proto(...) (pass vide, et rédigé à la rache).
Cela dit, encore une fois le projet est en plein cours de développement, si tu as des idées/suggestions, n'hésite pas :)
[^]Re: Algo ?
Comment tu gères un "ls" ? Le programme essait de choper un noeud "responsable" mais comment le trouve-t-il ?
Concernant les algo de répartition, vous utilisez du basique, cela va être chaud pour gérer les reconnections. D'ailleurs, si vous gériez un minimum de version du fichier, cela permettrait de garder en mémoire le fichier le plus rescent tout en conservant une copie en cas d'erreur.
Au niveau répartition de fichier,je connais 4 méthodes:
- centralisé, type NFS et votre cas, ou les données sont localisé en un seul endroit. Très efficace si il y a beaucoup d'écriture par rapport au lecture (donc "r" faible qui est le nombre de lecture pour une écriture) avec beaucoup de noeud y accédant, il faut évidement que le nombre global de pair soit faible sinon, tout s'écroule.
- migration, en gros, un écrivain, récupère le fichier et devient son propriétaire, c'est très efficace si il y a peu de noeud qui y accède en simultané. (par définition, un /home devrait être gérer comme cela)
Les 2 autres type utilisent la réplication, la différence concerne la gestion des écritures
- read replication, implique une invalidation des autres copies. C'est efficace avec beaucoup de pair qui écrivent peu.
- write replication, implique un broadcast des modifications à toutes les copies. C'est efficace avec peu de pairs qui écrivent beaucoup.
Typiquement, aucun des 4 algo est mieux que les autres cela dépend du nombre de pair, du taux d'écriture, du coût de transfert d'un message par rapport à la taille du fichier.
Si tu veux gérer plusieurs copies, le read replication est pas mal, mais je pense qu'il faut limiter le nombre de copie et utiliser un peu de migration, sinon la gestion des metadonnées devient horrible.
Pour retrouver les objets en cas de migration, les anciens propriétaires conservent l'adresse du nouveau propriétaires, ils peuvent ainsi gérer des indirections.
Et d'ailleurs gères-tu de la même façon une ISO de 4Go et un fichier de conf de 4Ko ? Il serait peut-être intéressant de jouer avec des "morceaux" histoire de mutualiser la bande passante.
[^]Re: Algo ?
Sur pf-net:
En gros, les fichiers sont gérés à partir d'un hash sur le nom de fichier. Quand on fait un ls on prend le hash du nom de fichier et ça nous donne la liste des peers ayant les infos sur ce fichier (contenu du répertoire, quels peers possèdent le contenu du fichier ...). Cette méthode permet d'économiser de la bande passante et aussi donne une certaine réactivité quand on fait un ls ;)
Sur pf-lan:
Chaque peer connait en permanence le contenu des dossiers, les modifications sont synchrones et broadcastées.
Pour les datas, c'est commun aux 2 fs:
Dans pf-0.1, le fichier est récupéré au moment de la lecture, la copie est gardée en cache. Lorsque quelqu'un modifie le fichier toute les copies existantes sont invalidées.
Dans pf-0.2, lorsque le cache est plein on le vide, avec migration de fichier sur une autre machine si nécessaire. (donc oui sur la 0.1, le cache explose si on n'y fait pas attention :)
Ca c'est le fonctionnement de base, un peu plus tard on pourra définir un taux de redondance sur le réseau qui propagera les modifications sur un fichier, et on rajoutera surement des fonctions de prefetch... et plein de bonnes choses sont encore à définir pour le version suivantes :)
[^]Re: Algo ?
Cela semble pouvoir devenir vraiment interrescant !
Par définition, le cache à une taille fixe, et cela doit rester un cache, c'est à dire que l'on compte dessus pour des raisons de performances et non pour conserver l'information. En gros, il faut pouvoir le détruire.
Sinon, la différence entre net et lan, c'est la bande passante disponible et le nombre de pair, pourquoi ne pas avoir fusionner les 2, et prendre en compte ce paramètre pour choisir la stratégie de diffusion ?
Si j'ai bien compris le système tous les pairs contiennent les meta-données ? En fait, tous les pairs se connaissent tous en entre eux. Cela ne limite pas la taille du réseau possible ?
[^]Re: Algo ?
En fait le cache porte mal son nom, car il sert à la fois de cache et à stocker les données. La raison c'est que à partir du moment où on a des données dans le cache ça parrait naturel de pouvoir les redistribuer immédiatement. Et ça permet aussi de simplifier la configuration du démon.
A l'utilisation, la différence entre pflan et pfnet se fait essentiellement sur la gestion des permissions : pflan distribue des fichiers en utilisant les permissions UNIX de la machine (un user avec un même UID accède aux mêmes fichiers depuis toute les machines), pfnet gère les permissions à partir du certificat passé au démon, càd un démon égal un utilisateur (la gestion des groupes ne se fait donc pas avec /etc/group, mais avec des commandes spécifiques pfnet). Une autre différence majeur entre pfnet et pflan se situe au niveau du réseau, pflan demande à ce que tout les peers puisse se connecter les uns aux autres, alors que pfnet implémente un routage des messages en utilisant d'autres peers comme passerelle (pour gérer les utilisateurs derrière des routeurs NAT).
Pour la gestion des méta-données, les peers stockent toutes les méta-données sur pflan. Ce n'est pas le cas sur pfnet, car un peer n'a pas accès à tout les fichiers. Dans les 2 cas tout les peers se connaissent les un les autres (y'a bcp de broadcast dans pflan, mais pas dans pfnet).
On n'a pas vraiment étudié les limitations, ce n'est pas encore prioritaire ;)
Voilà, maintenant que tu connais tout les détails de l'implémentation, je t'invite à venir contribuer sur peerfuse ! :)
Bref, passe sur #peerfuse@freenode.net si tu veux tester ou si t'as d'autres questions.