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).
Aller plus loin
- FineFS (63 clics)
- Groupe de discussion (13 clics)
# GlusterFS ?
Posté par Octplane (site web personnel) . Évalué à 8.
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 Sytoka Modon (site web personnel) . Évalué à 6.
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 Amaury Bouchard (site web personnel) . Évalué à 4.
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 Amaury Bouchard (site web personnel) . Évalué à 2.
;-)
[^] # Re: GlusterFS ?
Posté par Antoine . Évalué à 2.
[^] # Tahoe
Posté par Sytoka Modon (site web personnel) . Évalué à 4.
http://allmydata.org/trac/tahoe
Qu'elle est la particularité de FineFS par rapport à Tahoe ?
[^] # Re: Tahoe
Posté par Amaury Bouchard (site web personnel) . Évalué à 6.
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 usbplug . Évalué à 4.
Bof, j'en reste au bon vieux Cloudstore.
[^] # Re: GlusterFS ?
Posté par Amaury Bouchard (site web personnel) . Évalué à 2.
Cloudstore est plutôt utilisé par des programmes basés sur le paradigme map-reduce, non ?
[^] # Re: GlusterFS ?
Posté par Amaury Bouchard (site web personnel) . Évalué à 6.
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 Nicolas Boulay (site web personnel) . Évalué à 4.
"La première sécurité est la liberté"
[^] # Re: GlusterFS ?
Posté par Amaury Bouchard (site web personnel) . Évalué à 3.
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 Nicolas Boulay (site web personnel) . Évalué à 4.
"La première sécurité est la liberté"
[^] # Re: GlusterFS ?
Posté par Amaury Bouchard (site web personnel) . Évalué à 2.
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 Nicolas Boulay (site web personnel) . Évalué à 4.
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 Amaury Bouchard (site web personnel) . Évalué à 3.
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 Nicolas Boulay (site web personnel) . Évalué à 2.
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 Amaury Bouchard (site web personnel) . Évalué à 4.
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 Nicolas Boulay (site web personnel) . Évalué à 2.
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 Amaury Bouchard (site web personnel) . Évalué à 4.
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 Nicolas Boulay (site web personnel) . Évalué à 2.
"La première sécurité est la liberté"
[^] # Re: GlusterFS ?
Posté par Amaury Bouchard (site web personnel) . Évalué à 3.
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 Nicolas Boulay (site web personnel) . Évalué à 2.
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 Amaury Bouchard (site web personnel) . É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.
[^] # Re: GlusterFS ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
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 Amaury Bouchard (site web personnel) . Évalué à 2.
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 Nicolas Boulay (site web personnel) . Évalué à 2.
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 Amaury Bouchard (site web personnel) . Évalué à 2.
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 Nicolas Boulay (site web personnel) . Évalué à 1.
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 Amaury Bouchard (site web personnel) . Évalué à 2.
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 Nicolas Boulay (site web personnel) . Évalué à 2.
"La première sécurité est la liberté"
[^] # Re: GlusterFS ?
Posté par Amaury Bouchard (site web personnel) . Évalué à 2.
[^] # Re: GlusterFS ?
Posté par Étienne . Évalué à 1.
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 Amaury Bouchard (site web personnel) . Évalué à 2.
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 Damien Thébault . Évalué à 10.
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.
[^] # Re: Cohérence
Posté par Amaury Bouchard (site web personnel) . Évalué à 1.
# Configuration des noeuds
Posté par Sytoka Modon (site web personnel) . Évalué à 6.
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 Amaury Bouchard (site web personnel) . Évalué à 2.
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 Sytoka Modon (site web personnel) . Évalué à 2.
[^] # Re: Configuration des noeuds
Posté par Amaury Bouchard (site web personnel) . Évalué à 1.
# Applications Web sans contrainte temps réel forte!?
Posté par Christophe Nowicki (site web personnel) . Évalué à 5.
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 Amaury Bouchard (site web personnel) . Évalué à 2.
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 à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.