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 Amaury Bouchard (site web personnel) . En réponse à la dépêche Publication de FineFS, un système de fichiers répartis. Évalué à 2.
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.