FineFS, système de fichiers redondé

J'ai lancé depuis quelques temps un projet dans mon entreprise, que nous venons de publier sous licence libre. Il s'agit d'un système de fichiers répliqué du nom de FineFS.

Je vais en parler ici parce qu'il s'agit d'un projet intéressant d'un point de vue technique, sur lequel les esprits imaginatifs peuvent venir s'éclater avec nous. Mais aussi parce qu'à travers ce projet, je veux vous présenter l'univers des systèmes répartis/distribués/redondés et des bases de données à très haute disponibilité - que tout directeur technique doit connaître un minimum.

Présentation du projet

Le but de ce projet est de faciliter la création de cluster-disque. Lorsque vous avez plusieurs serveurs qui doivent accéder aux mêmes fichiers, il est toujours délicat de mettre en place une architecture satisfaisante sans dépenser des sommes folles. Et pourtant, la moindre infrastructure Web présente plusieurs serveurs frontaux, qui doivent délivrer des contenus (images, vidéos, musiques) communs. Sans compter que ces différents serveurs doivent aussi pouvoir enregistrer de nouveaux fichiers, qui doivent être accessibles à toutes les autres machines.

Il existe plusieurs moyens de mettre des fichiers à dispositions de plusieurs serveurs :

• Installer un NAS, c'est-à-dire un serveur de fichiers. Mais si ce serveur tombe en panne, plus aucun fichier n'est accessible.
• Installer un SAN, qui prend souvent la forme d'une baie de stockage redondée. Mais les prix de ce genre d'installation grimpent très vite.
• Utiliser un service externe, comme Amazon S3, qui prend en charge les aspects complexes de la gestion des fichiers. C'est souvent une solution satisfaisante pour du Web, mais qui peut induire des latences dans les accès aux fichiers, et des coûts inutiles.
• Mettre en place un système de fichiers réparti, redondé et/ou distribué.

C'est dans cette dernière catégorie que se place FineFS. Il existe déjà des solutions qui s'emploient à résoudre ce besoin, qu'on peut répartir en 5 groupes :

• Les systèmes basés sur le modèle des bases de données : Dynamo, Cassandra, ...
• Les systèmes utilisant un serveur centralisé : MooseFS, Lustre, DRBD, Chirp, GfarmFS, ...
• Ceux basés sur l'exploitation d'un SAN : GFS, OpenGFS, QFS, GPFS, OCFShttp://en.wikipedia.org/wiki/OCFS, ...
• Ceux qui ne sont pas des vrais systèmes répartis mais peuvent remplir le même genre d'usages : Peerfuse, ChironFS, PersistentFS (basé sur S3), MogileFS, ...
• Les systèmes de fichier distribués et/ou répartis : GlusterFS, ZFS, POHMELFS, Cloudstore, Ceph, Coda, ...

La plupart présentent toutefois des inconvénients majeurs par rapports à nos besoins qui sont sommes toute assez simples. Soit les fonctionnalités ne sont pas celles qu'on attend, soit le coût d'installation ou de maintenance semble exagéré.

Choix techniques

La philosophie initiale de FineFS se rapproche un peu de celle de MogileFS. Ce n'est pas un système de fichiers au sens habituel du terme (comprendre compatible POSIX), mais une infrastructure logicielle qui permet de partager des fichiers entre plusieurs machines. Par contre, la réalisation technique est complètement différente.

Quelques contraintes ont guidé les choix techniques :

• La lecture de fichiers doit être la plus rapide possible => on recopie les fichiers en local sur tous les serveurs.
• La cohérence des données est importante, mais sans contrainte de temps réel => on utilise le paradigme de l'eventual consistency.
• Le système doit être simple et rapide à développer et bien s'intégrer dans un environnement orienté Web => le fonctionnement repose sur des outils standards, stables et connus (xinetd, crontab), le développement est fait en PHP.

La réalisation technique est en partie inspirée des principes de Dynamo et Cassandra, des bases de données créées respectivement par Amazon et Facebook.
Pour faire simple, les serveurs (ou "noeuds") d'un cluster sont placés dans une boucle au sein de laquelle chaque serveur réplique ses données vers le serveur suivant. Mais le danger est alors qu'un fichier un peu gros prenne beaucoup de temps à faire le tour de la boucle. C'est pour cela que nous avons mis en place une stratégie de réplication en 2 temps :

1. Dès la création (ou la mise-à-jour, l'effacement, le renommage) d'un fichier, un petit message fait les tour du cluster pour prévenir rapidement tous les noeuds.
2. De manière asynchrone, un programme s'exécute sur chaque noeud, pour copier vers le noeud suivant le contenu des nouveau fichiers.

Pour en savoir plus

Je vous conseille d'aller jeter un oeil sur les liens suivants :

• Le site du projet, hébergé sur Google Code.
• Le groupe de discussion consacré aux logiciels libres de FineMedia.
• L'annonce sur LinuxFR, dans laquelle vous pourrez trouver des échanges de commentaires assez intéressants.

N'hésitez pas à participer, soit sur le groupe de discussion, soit en testant le logiciel, soit en proposant des amélioration de code.
Et si vous cherchez un poste intéressant en développement web, au sein duquel vous aurez des responsabilité sur FineFS, contactez moi !

Et le futur ?

Nous avons de nombreuses idées d'améliorations pour FineFS. Nous n'en sommes qu'aux prémisses de ce projet. Pour commencer, nous allons travailler sur la souplesse d'administration, pour faciliter l'ajout de noeuds à un cluster, ou la création de passerelles entre les clusters. Ensuite, nous allons permettre l'utilisation de noeuds "partiels", qui ne contiennent pas l'intégralité des données du cluster, mais qui gardent en cache les fichiers les plus demandés.

Une des pistes d'amélioration les plus intéressantes sera la possibilité de rechercher des fichiers à partir de leurs méta-données et non pas uniquement par leur nom. Les fichiers peuvent déjà comporter des méta-données, des informations textuelles simples sous forme de paires clé-valeur. Permettre de de faire des recherches sur ces données permettrait de se passer de bases de données relationnelles dans certains cas, ce qui pourrait accélerer les applications. À ce sujet, je vous suggère d'aller lire l'article Is the relational database doomed. Il présente assez bien pourquoi les bases de données non relationnelles reviennent à la mode, principalement sur les grosses architectures Web de "cloud-computing".