Ce compilateur traduit le « bytecode » Gambas en langage C pendant l’exécution, et utilise ensuite le compilateur du système (gcc ou clang) pour obtenir le code machine final.
Plutôt que d'appeler un compilateur externe, est-ce que vous avez envisagé d'utiliser la bibliothèque du compilateur TinyCC (libtcc) ? Il produit du code moins optimisé que GCC/LLVM, mais il compile beaucoup plus vite, ce qui est parfait pour une compilation JIT. Et ça évite une dépendance avec un programme externe.
Peut-être que Gambas a besoin de produire du code C++ et non pas du code C (notamment pour Qt) ? Si c'est le cas, je comprendrais que TinyCC ne soit pas utilisable.
Suite aux demandes et remarques en commentaire, Arkiv supporte maintenant la sauvegarde binaire de bases de données MySQL par xtrabackup. Il est possible de configurer des sauvegardes complètes et des sauvegardes incrémentales.
N'hésitez pas à tester et à me faire des retours via la buglist ou par email.
PS : Plus anecdotique, j'ai aussi ajouté le support de syslog.
Le --single-transaction, ça fonctionne uniquement lorsque tu est en full-InnoDB. Sinon, ton dump ne va pas être consistent.
Oui, bien sûr. Tu as encore des tables en MyISAM, toi ? Quel intérêt ?
Bon, je vais regarder tout ça de près. Merci à tous pour vos conseils et liens.
Comme je l'ai déjà dit, le but reste quand même de garder un code simple et clair, pas de faire un machine énorme qui répond à tous les besoins. L'utilisation de mysqldump est facile (je pense que toutes les distribs l'installent dès qu'on installe un client MySQL), c'est pour ça que je l'ai ajoutée (et aussi parce que − comme on me l'a fait remarquer − Arkiv est en concurrence avec Backup-Manager, qui gère mysqldump).
Mais je comprends bien l'intérêt :)
Petites question à mon tour :
1. Comment faites-vous vos sauvegardes actuellement ?
2. Est-ce que Arkiv vous serait utile, et n'y a-t-il vraiment que la sauvegarde par xtrabackup qui manque ? (et dans ce cas, pourquoi ne pas commencer par lancer xtrabackup avant Arkiv dans la crontab ?)
Non, justement. Comme je l'ai indiqué dans un précédent commentaire, j'ai écrit un article de blog sur la question. Il est possible de ne pas verrouiller les tables, et de faire le dump dans une transaction pour être sûr de ne pas récupérer des données qui ont changé pendant la durée du dump. C'est d'ailleurs expliqué dans le lien que tu as fourni.
Et pour ce qui est des caches MySQL qui se retrouvent à être utilisés pour mysqldump au lieu d'être remplis de données utiles pour les traitements "normaux" de la base, la solution est de mettre en place une réplication maître-esclave et de faire les sauvegardes sur l'esclave.
Mais je comprends aussi que s'il existe un outil plus performant, ce serait idiot de ne pas le supporter :)
Toutefois ce serait une erreur de ne pas supporter mysqldump, qui a l'avantage d'être quasi-toujours là. Et accessoirement, puisque quelqu'un comparaît avec Backup-Manager, il faut bien dire que lui aussi passe par mysqldump (oui, je sais que backup-manager peut sauvegarder les données de n'importe quel programme en passant par un “pipe”, mais ce n'est plus du «out-of-the-box»).
Et pour être complet :
- Backup-manager peut sauvegarder des fichiers de manière incrémentale, avec que Arkiv fait toujours des sauvegardes complètes. [1]
- Backup-manager peut sauvegarder spécifiquement les données de serveurs Subversion ou celles de programmes qui sont "pipés".
- Backup-manager est capable d'envoyer les sauvegardes par SCP, FTP ou rsync, et peut aussi graver des CD/DVD. Arkiv se contente d'Amazon S3 et Amazon Glacier.
- Backup-manager peut encrypter les données avec GPG, alors que Arkiv utilise OpenSSL.
[1] : C'est un choix de ma part. Je préfère avoir des sauvegardes complètes car elles sont plus faciles à restaurer (une seule archive à déployer, plutôt que de déployer la dernière archive complète plus toutes les archives incrémentales sauvegardées depuis). Ça peut évidemment faire stocker plus de données, mais avec une gestion fine des purges − comme le permet Skriv − je pense qu'on s'y retrouve largement.
Je te pose la même question qu'aux autres qui m'ont fait une demande similaire : Est-ce que tu aurais des liens qui documenteraient les limitations de mysqldump ? Ça m'intéresse évidemment.
Le code est découpé en fonctions et assez bien commenté, donc il est plutôt facile à maintenir. Je n'ai pas séparé le script en deux pour une bonne raison : En shell, il est impossible de savoir de manière sûre à 100% le chemin du script qui s'exécute (cf. http://mywiki.wooledge.org/BashFAQ/028). Du coup, il devient très compliqué d'inclure des fichiers sans imposer l'installation du programme dans une arborescence fixe (solution utilisée par backup-manager, par exemple). Je tiens à ce que le programme soit utilisable par n'importe quel utilisateur sans qu'il n'ait été d'abord installé par le root. Et il y a certaines parties du code qui sont mutualisées (notamment la gestion du formatage ANSI).
Pour les défaut de mysqldump, est-ce que tu as des liens à ce sujet ? Comme je l'ai déjà dit dans un commentaire précédent, je n'ai jamais été face à une volumétrie telle que cet outil pouvait poser problème (et pourtant, j'ai fait pas mal de sauvegardes en production sur des bases assez conséquentes ces 15 dernières années).
Comme je le dis sur mon article de blog (en lien dans la dépêche), j'ai utilisé backup-manager pendant les 10 dernières années grosso modo.
Ce que Arkiv fait et que backup-manager ne fait pas :
- Possibilité de choisir la fréquence de sauvegarde, que ce soit plusieurs fois par jour (jusqu'à toutes les heures) ou pas tous les jours, alors que backup-manager est fait pour sauvegarder une fois par jour uniquement.
- Peut archiver les données à long-terme sur Amazon Glacier (en plus de les archiver à moyen-terme sur Amazon S3, comme backup-manager).
- Gère des politiques de purge complexes (cf. l'exemple donné dans la dépêche), alors que backup-manager efface tous les fichiers après un certain délai (et que en local, pas sur Amazon S3).
- Aide à la création du fichier de configuration.
- Fichiers de logs plus faciles à lire (c'est subjectif, je sais, mais un effort a été fait là-dessus).
Je ne sais pas pour les toutes dernières version de backup-manager, mais celle que j'utilisais n'était pas compatible avec les datacenters Amazon les plus récents (celui de Londres par exemple), qui ne sont pas compatibles avec les anciennes versions de l'API.
Je ne sais pas ce que tu veux dire quand tu parles de contrepartie. Il n'y a pas de limite au volume. C'est sûr que si tu as de grosses bases de données et/ou des fichiers volumineux, la sauvegarde risque de prendre du temps. Mais c'est difficile de faire autrement. Comme il est possible d'exécuter plusieurs instances d'Arkiv en parallèle, avec des fichiers de configuration différent, on peut imaginer faire des sauvegardes séparées pour que les données les plus légères soient archivées plus fréquemment.
Le dump de la base se fait dans une transaction, donc il n'y a pas besoin de mettre quoi que ce soit en pause à la condition que les tables soient toutes en InnoDB. La chose est détaillée dans un article de mon blog.
Ensuite, il est possible de mettre en place une stratégie de réplication maître-esclave, pour que la sauvegarde des bases se fasse sur un esclave (afin de ne pas impacter le serveur maître, que ce soit en consommation CPU ou mémoire). Il est aussi possible d'utiliser les logs binaires ; c'est alors une sauvegarde classique de fichier. Mais il vaut quand même mieux avoir un dump complet de temps en temps.
Pour la question du partitionnement des tables, c'est quelque chose que je n'ai jamais vu mis en œuvre uniquement pour la sauvegarde (je l'ai déjà vu pour faire du sharding par exemple). Sur quel genre de volumétrie as-tu eu besoin de faire ça ?
Les seules limites pour le moment concernent Amazon :
- Les fichiers peuvent faire jusqu'à 5 TO sur Amazon S3 (source)
- Les fichiers peuvent faire jusqu'à 40 TO sur Amazon Glacier (source)
Je ferai peut-être une évolution pour découper les fichiers dont la taille est supérieure à ces limites. Je n'en ai personnellement pas le besoin, donc si ça peut être utile à quelqu'un, ce serait bien de me faire signe :)
Effectivement, le mot «encrypter» existe en français, mais pas «encryption»…
On reparlera de LibreSSL quand ce sera intégré dans les dépôts de toutes les principales distributions, hein. En attendant, l'utilisation d'OpenSSL ne pose strictement aucun problème. On peut faire plus simple, c'est vrai, mais dans le cadre qui concerne Arkiv (encrypter des données en utilisant une clé symétrique) il n'y a rien de compliqué, et c'est bien documenté dans le README.
La question aurait plutôt pu être pourquoi OpenSSL plutôt que OpenPGP/GnuPG. La réponse : parce que je connais mieux.
Je viens d'ajouter une fonctionnalité d'encryption. Les données peuvent maintenant être cryptées en utilisant OpenSSL (algorithme AES 256 bits), aussi bien pour les fichiers stockés en local que pour ceux enregistrés sur Amazon S3 et Amazon Glacier.
Il est possible d'utiliser une clé générée préalablement ou de fournir une passphrase.
Dans l'appel à commentaires de l'AFNOR, il est possible de faire des suggestions. Voilà ce que j'ai écrit au sujet de leur proposition de nouveau clavier Azerty :
Garder les caractères ç, ù, $, " accessibles sans combinaison de touches.
Rendre les caractères µ, | accessibles via une combinaison de 3 touches.
Le caractère arobase (@) devrait être accessible sans combinaison de touche, ou au pire en appuyant sur la touche Majuscule (et non pas AltGr).
Le caractère multiplication (×) devrait être proche du caractère division (÷). Les deux devraient être sur la même touche (l'un accessible avec la combinaison AltGr et l'autre avec Maj+AlGr) ou sur deux touches adjacentes.
Pour faciliter le développement informatique, il faudrait garder les caractères {, }, [, ] accessibles via une combinaison de 2 touches, mais en les regroupant sur le clavier ({ et } l'un à-côté de l'autre ; [ et ] l'un à-côté de l'autre).
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'.
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à...
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.
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)...
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.
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.
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.
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.
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).
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.
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, ...).
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.
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).
# Concernant le compilateur JIT
Posté par Amaury Bouchard (site web personnel) . En réponse à la dépêche Sortie de Gambas 3.12. Évalué à 4.
Dans la dépêche il est écrit :
Plutôt que d'appeler un compilateur externe, est-ce que vous avez envisagé d'utiliser la bibliothèque du compilateur TinyCC (libtcc) ? Il produit du code moins optimisé que GCC/LLVM, mais il compile beaucoup plus vite, ce qui est parfait pour une compilation JIT. Et ça évite une dépendance avec un programme externe.
Peut-être que Gambas a besoin de produire du code C++ et non pas du code C (notamment pour Qt) ? Si c'est le cas, je comprendrais que TinyCC ne soit pas utilisable.
# Support de xtrabackup
Posté par Amaury Bouchard (site web personnel) . En réponse à la dépêche Arkiv : Sauvegarde de fichiers et bases MySQL + archivage sur Amazon S3 et Amazon Glacier. Évalué à 2.
Suite aux demandes et remarques en commentaire, Arkiv supporte maintenant la sauvegarde binaire de bases de données MySQL par xtrabackup. Il est possible de configurer des sauvegardes complètes et des sauvegardes incrémentales.
N'hésitez pas à tester et à me faire des retours via la buglist ou par email.
PS : Plus anecdotique, j'ai aussi ajouté le support de syslog.
[^] # Re: Petite suggestion
Posté par Amaury Bouchard (site web personnel) . En réponse à la dépêche Arkiv : Sauvegarde de fichiers et bases MySQL + archivage sur Amazon S3 et Amazon Glacier. Évalué à 1.
Oui, bien sûr. Tu as encore des tables en MyISAM, toi ? Quel intérêt ?
Bon, je vais regarder tout ça de près. Merci à tous pour vos conseils et liens.
Comme je l'ai déjà dit, le but reste quand même de garder un code simple et clair, pas de faire un machine énorme qui répond à tous les besoins. L'utilisation de mysqldump est facile (je pense que toutes les distribs l'installent dès qu'on installe un client MySQL), c'est pour ça que je l'ai ajoutée (et aussi parce que − comme on me l'a fait remarquer − Arkiv est en concurrence avec Backup-Manager, qui gère mysqldump).
Mais je comprends bien l'intérêt :)
Petites question à mon tour :
1. Comment faites-vous vos sauvegardes actuellement ?
2. Est-ce que Arkiv vous serait utile, et n'y a-t-il vraiment que la sauvegarde par xtrabackup qui manque ? (et dans ce cas, pourquoi ne pas commencer par lancer xtrabackup avant Arkiv dans la crontab ?)
Merci
[^] # Re: Petite suggestion
Posté par Amaury Bouchard (site web personnel) . En réponse à la dépêche Arkiv : Sauvegarde de fichiers et bases MySQL + archivage sur Amazon S3 et Amazon Glacier. Évalué à 1.
Non, justement. Comme je l'ai indiqué dans un précédent commentaire, j'ai écrit un article de blog sur la question. Il est possible de ne pas verrouiller les tables, et de faire le dump dans une transaction pour être sûr de ne pas récupérer des données qui ont changé pendant la durée du dump. C'est d'ailleurs expliqué dans le lien que tu as fourni.
Et pour ce qui est des caches MySQL qui se retrouvent à être utilisés pour mysqldump au lieu d'être remplis de données utiles pour les traitements "normaux" de la base, la solution est de mettre en place une réplication maître-esclave et de faire les sauvegardes sur l'esclave.
Mais je comprends aussi que s'il existe un outil plus performant, ce serait idiot de ne pas le supporter :)
Toutefois ce serait une erreur de ne pas supporter mysqldump, qui a l'avantage d'être quasi-toujours là. Et accessoirement, puisque quelqu'un comparaît avec Backup-Manager, il faut bien dire que lui aussi passe par mysqldump (oui, je sais que backup-manager peut sauvegarder les données de n'importe quel programme en passant par un “pipe”, mais ce n'est plus du «out-of-the-box»).
[^] # Re: backup-manager
Posté par Amaury Bouchard (site web personnel) . En réponse à la dépêche Arkiv : Sauvegarde de fichiers et bases MySQL + archivage sur Amazon S3 et Amazon Glacier. Évalué à 3.
Et pour être complet :
- Backup-manager peut sauvegarder des fichiers de manière incrémentale, avec que Arkiv fait toujours des sauvegardes complètes. [1]
- Backup-manager peut sauvegarder spécifiquement les données de serveurs Subversion ou celles de programmes qui sont "pipés".
- Backup-manager est capable d'envoyer les sauvegardes par SCP, FTP ou rsync, et peut aussi graver des CD/DVD. Arkiv se contente d'Amazon S3 et Amazon Glacier.
- Backup-manager peut encrypter les données avec GPG, alors que Arkiv utilise OpenSSL.
[1] : C'est un choix de ma part. Je préfère avoir des sauvegardes complètes car elles sont plus faciles à restaurer (une seule archive à déployer, plutôt que de déployer la dernière archive complète plus toutes les archives incrémentales sauvegardées depuis). Ça peut évidemment faire stocker plus de données, mais avec une gestion fine des purges − comme le permet Skriv − je pense qu'on s'y retrouve largement.
[^] # Re: Petite suggestion
Posté par Amaury Bouchard (site web personnel) . En réponse à la dépêche Arkiv : Sauvegarde de fichiers et bases MySQL + archivage sur Amazon S3 et Amazon Glacier. Évalué à 1.
C'est envisageable.
Je te pose la même question qu'aux autres qui m'ont fait une demande similaire : Est-ce que tu aurais des liens qui documenteraient les limitations de mysqldump ? Ça m'intéresse évidemment.
[^] # Re: Information sur le volume cible
Posté par Amaury Bouchard (site web personnel) . En réponse à la dépêche Arkiv : Sauvegarde de fichiers et bases MySQL + archivage sur Amazon S3 et Amazon Glacier. Évalué à 1.
Le code est découpé en fonctions et assez bien commenté, donc il est plutôt facile à maintenir. Je n'ai pas séparé le script en deux pour une bonne raison : En shell, il est impossible de savoir de manière sûre à 100% le chemin du script qui s'exécute (cf. http://mywiki.wooledge.org/BashFAQ/028). Du coup, il devient très compliqué d'inclure des fichiers sans imposer l'installation du programme dans une arborescence fixe (solution utilisée par backup-manager, par exemple). Je tiens à ce que le programme soit utilisable par n'importe quel utilisateur sans qu'il n'ait été d'abord installé par le root. Et il y a certaines parties du code qui sont mutualisées (notamment la gestion du formatage ANSI).
Pour les défaut de mysqldump, est-ce que tu as des liens à ce sujet ? Comme je l'ai déjà dit dans un commentaire précédent, je n'ai jamais été face à une volumétrie telle que cet outil pouvait poser problème (et pourtant, j'ai fait pas mal de sauvegardes en production sur des bases assez conséquentes ces 15 dernières années).
[^] # Re: backup-manager
Posté par Amaury Bouchard (site web personnel) . En réponse à la dépêche Arkiv : Sauvegarde de fichiers et bases MySQL + archivage sur Amazon S3 et Amazon Glacier. Évalué à 3.
Comme je le dis sur mon article de blog (en lien dans la dépêche), j'ai utilisé backup-manager pendant les 10 dernières années grosso modo.
Ce que Arkiv fait et que backup-manager ne fait pas :
- Possibilité de choisir la fréquence de sauvegarde, que ce soit plusieurs fois par jour (jusqu'à toutes les heures) ou pas tous les jours, alors que backup-manager est fait pour sauvegarder une fois par jour uniquement.
- Peut archiver les données à long-terme sur Amazon Glacier (en plus de les archiver à moyen-terme sur Amazon S3, comme backup-manager).
- Gère des politiques de purge complexes (cf. l'exemple donné dans la dépêche), alors que backup-manager efface tous les fichiers après un certain délai (et que en local, pas sur Amazon S3).
- Aide à la création du fichier de configuration.
- Fichiers de logs plus faciles à lire (c'est subjectif, je sais, mais un effort a été fait là-dessus).
Je ne sais pas pour les toutes dernières version de backup-manager, mais celle que j'utilisais n'était pas compatible avec les datacenters Amazon les plus récents (celui de Londres par exemple), qui ne sont pas compatibles avec les anciennes versions de l'API.
[^] # Re: Information sur le volume cible
Posté par Amaury Bouchard (site web personnel) . En réponse à la dépêche Arkiv : Sauvegarde de fichiers et bases MySQL + archivage sur Amazon S3 et Amazon Glacier. Évalué à 3.
Merci pour les remerciements :)
Je ne sais pas ce que tu veux dire quand tu parles de contrepartie. Il n'y a pas de limite au volume. C'est sûr que si tu as de grosses bases de données et/ou des fichiers volumineux, la sauvegarde risque de prendre du temps. Mais c'est difficile de faire autrement. Comme il est possible d'exécuter plusieurs instances d'Arkiv en parallèle, avec des fichiers de configuration différent, on peut imaginer faire des sauvegardes séparées pour que les données les plus légères soient archivées plus fréquemment.
Le dump de la base se fait dans une transaction, donc il n'y a pas besoin de mettre quoi que ce soit en pause à la condition que les tables soient toutes en InnoDB. La chose est détaillée dans un article de mon blog.
Ensuite, il est possible de mettre en place une stratégie de réplication maître-esclave, pour que la sauvegarde des bases se fasse sur un esclave (afin de ne pas impacter le serveur maître, que ce soit en consommation CPU ou mémoire). Il est aussi possible d'utiliser les logs binaires ; c'est alors une sauvegarde classique de fichier. Mais il vaut quand même mieux avoir un dump complet de temps en temps.
Pour la question du partitionnement des tables, c'est quelque chose que je n'ai jamais vu mis en œuvre uniquement pour la sauvegarde (je l'ai déjà vu pour faire du sharding par exemple). Sur quel genre de volumétrie as-tu eu besoin de faire ça ?
Les seules limites pour le moment concernent Amazon :
- Les fichiers peuvent faire jusqu'à 5 TO sur Amazon S3 (source)
- Les fichiers peuvent faire jusqu'à 40 TO sur Amazon Glacier (source)
Je ferai peut-être une évolution pour découper les fichiers dont la taille est supérieure à ces limites. Je n'en ai personnellement pas le besoin, donc si ça peut être utile à quelqu'un, ce serait bien de me faire signe :)
[^] # Re: Encryption
Posté par Amaury Bouchard (site web personnel) . En réponse à la dépêche Arkiv : Sauvegarde de fichiers et bases MySQL + archivage sur Amazon S3 et Amazon Glacier. Évalué à 5.
Effectivement, le mot «encrypter» existe en français, mais pas «encryption»…
On reparlera de LibreSSL quand ce sera intégré dans les dépôts de toutes les principales distributions, hein. En attendant, l'utilisation d'OpenSSL ne pose strictement aucun problème. On peut faire plus simple, c'est vrai, mais dans le cadre qui concerne Arkiv (encrypter des données en utilisant une clé symétrique) il n'y a rien de compliqué, et c'est bien documenté dans le README.
La question aurait plutôt pu être pourquoi OpenSSL plutôt que OpenPGP/GnuPG. La réponse : parce que je connais mieux.
# Encryption
Posté par Amaury Bouchard (site web personnel) . En réponse à la dépêche Arkiv : Sauvegarde de fichiers et bases MySQL + archivage sur Amazon S3 et Amazon Glacier. Évalué à 5.
Je viens d'ajouter une fonctionnalité d'encryption. Les données peuvent maintenant être cryptées en utilisant OpenSSL (algorithme AES 256 bits), aussi bien pour les fichiers stockés en local que pour ceux enregistrés sur Amazon S3 et Amazon Glacier.
Il est possible d'utiliser une clé générée préalablement ou de fournir une passphrase.
# Commentaire sur le site de l'AFNOR
Posté par Amaury Bouchard (site web personnel) . En réponse à la dépêche Vers une norme AFNOR pour le clavier français. Évalué à 2.
Dans l'appel à commentaires de l'AFNOR, il est possible de faire des suggestions. Voilà ce que j'ai écrit au sujet de leur proposition de nouveau clavier Azerty :
Certains caractères disponibles directement avec les claviers Azerty actuels auraient besoin à l'avenir d'un combinaison de touches : ç, ù, $, "
À l'inverse, d'autres caractères peu utilisés se retrouveraient facilement accessibles : µ, |
Cela amène à déplacer certains caractères de manière non logique. Ainsi, le caractère © (disponible actuellement sous Linux avec AltGr + C) se retrouve associé à la touche X, et le caractère æ (AltGr + A) se retrouverait associé à la touche Z.
Le caractère arobase (@) est très utilisé de nos jours, et ne devrait plus être accessible avec une combinaison de touches.
Garder les caractères ç, ù, $, " accessibles sans combinaison de touches.
Rendre les caractères µ, | accessibles via une combinaison de 3 touches.
Le caractère arobase (@) devrait être accessible sans combinaison de touche, ou au pire en appuyant sur la touche Majuscule (et non pas AltGr).
Le caractère multiplication (×) devrait être proche du caractère division (÷). Les deux devraient être sur la même touche (l'un accessible avec la combinaison AltGr et l'autre avec Maj+AlGr) ou sur deux touches adjacentes.
Pour faciliter le développement informatique, il faudrait garder les caractères {, }, [, ] accessibles via une combinaison de 2 touches, mais en les regroupant sur le clavier ({ et } l'un à-côté de l'autre ; [ et ] l'un à-côté de l'autre).
[^] # 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.
;-)
[^] # 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.
[^] # 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.
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 Amaury Bouchard (site web personnel) . En réponse à la dépêche Publication de FineFS, un système de fichiers répartis. É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.
[^] # 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.
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 Amaury Bouchard (site web personnel) . En réponse à la dépêche Publication de FineFS, un système de fichiers répartis. É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 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.
[^] # 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é à 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 Amaury Bouchard (site web personnel) . En réponse à la dépêche Publication de FineFS, un système de fichiers répartis. É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 Amaury Bouchard (site web personnel) . En réponse à la dépêche Publication de FineFS, un système de fichiers répartis. É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 Amaury Bouchard (site web personnel) . En réponse à la dépêche Publication de FineFS, un système de fichiers répartis. É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 Amaury Bouchard (site web personnel) . En réponse à la dépêche Publication de FineFS, un système de fichiers répartis. É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 Amaury Bouchard (site web personnel) . En réponse à la dépêche Publication de FineFS, un système de fichiers répartis. É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).