GlusterFS ou plus simplement gluster est un système de fichiers en espace utilisateur. Il a une forte connotation cluster ou cloud. Il existe deux types de système de fichiers de ce genre, les systèmes natifs en espace noyau comme Lustre / Ceph ou ceux utilisant l’interface FUSE. Dans la même catégorie que gluster, on retrouve MooseFS, sur lequel le magazine GMLF a réalisé un article en avril 2011.
L’intérêt des systèmes en espace utilisateur est la facilité de programmation, ainsi que le fait de s’appuyer localement sur un des systèmes de fichiers standard du noyau : ext3, ext4, XFS… Dans le cas d’un système de fichiers « clusterisé » comme gluster, chacune des partitions formant le cluster peut être formatée avec un système de fichiers différent. Il n’est pas nécessaire que ceux‐ci soient homogènes.
Avec un système de fichiers « clusterisé », il est possible d’agréger des volumes (partitions) provenant de plusieurs serveurs (NAS, SAN…), afin de ne montrer aux clients qu’un seul volume. C’est un peu la généralisation aux grappes de machines Linux (les clusters) du gestionnaire de volumes LVM que l’on trouve sur tous les serveurs Linux et qui permet (entre autres) l’agrégation de partitions.
La particularité de gluster est de ne pas s’appuyer sur un serveur de métadonnées (contrairement à pNFS et MooseFS). Tous les nœuds de la grappe sont équivalents. Il est donc particulièrement robuste aux pannes. À noter que depuis la version 3.1, gluster est distribué sous la licence libre AGPL, la [licence publique générale Affero], alors qu’il était auparavant distribué sous licence GPLv3. Ce changement de licence est évidemment conçu pour protéger le développement de gluster d’une utilisation abusive (sans retour de contribution) dans les « nuages »…
Les fonctionnalités de la 3.0
Cette version avait amené une profonde refonte dans l’interface de gluster avec l’introduction d’une commande « gluster », permettant de paramétrer le cluster de données. Finis les fichiers quasi identiques à propager dans la grappe, l’installation et le déploiement du cluster deviennent presque triviaux !
- volume distribué : un volume est distribué sur plusieurs partitions qui sont distribuées sur plusieurs machines… Les fichiers du volume sont physiquement enregistrés sur l’une des partitions. Deux fichiers d’un même dossier n’ont aucune raison d’être sur la même partition.
Plusieurs modes d’agrégation de volumes pour former le volume « clusterisé » sont possibles :
volume répliqué : un volume distribué est automatiquement répliqué n fois sur le cluster, n pouvant être 2 (raid 1), mais aussi 3 ou plus ! Ce type de volume est intéressant pour se préserver des pannes, par exemple d’une panne de baie de stockage.
volume morcelé (stripe) : chaque fichier d’un volume distribué est découpé en morceaux qui sont répartis sur les nœuds de la grappe. Ce genre de volume est intéressant lorsqu’on cherche de la performance sur des gros fichiers.
À noter que quatre opérations de base sont possibles à chaud sur tous les volumes :
- étendre (expanding) ;
- réduire (shrinking) ;
- migrer (migrating) ;
- équilibrer (rebalancing).
Ces opérations sont complémentaires, puisqu’il s’agit d’agrandir ou de diminuer la taille d’un volume, de déplacer les données d’une partition d’un volume vers une autre (changement de disque dur, par exemple). Ces opérations sont lourdes et peuvent laisser le volume dans un état peu satisfaisant du point de vue des performances. La dernière opération permet de rééquilibrer le volume en déplaçant en tâche de fond les fichiers dans les volumes ; c’est en quelque sorte une opération qui se rapproche de la défragmentation.
Quoi de neuf avec la 3.2 ?
On aurait pu s’attendre à une version 3.2 calme, après les changements réalisés dans la version 3.0. Pas du tout. Il y a plein de choses nouvelles et sympathiques dans cette version 3.2.
Géo‐réplication : l’idée est d’avoir deux sites distants, et de faire de la réplication asynchrone entre les deux sites, afin d’avoir un plan de reprise d’activité (PRA) possible. Il n’est pas nécessaire d’avoir un système de fichiers gluster sur le site secondaire, mais si les volumes de données sont importants, cela semble logique d’avoir le même format des deux côtés. À noter qu’il est possible de cascader les sites : A → B → C, ou de répliquer le site maître vers deux sites distants !
Quotas : gestion de quota par dossier permettant de limiter la taille occupée par un dossier sur un volume. En général, sur les systèmes de fichiers traditionnels, les quotas se font sur les utilisateurs ou sur les groupes (XFS a la possibilité de faire des quotas sur projet). On crée donc souvent un groupe par projet (dossier), afin d’y appliquer un quota dessus. Ce mode de gestion de quota par dossier ne devrait donc pas modifier fondamentalement la pratique des administrateurs système.
Supervision : permet d’obtenir des rapports d’utilisation et de performance. Ce genre d’informations peut être utile pour savoir, par exemple, quelles sont les données à déplacer sur des volumes plus performants.
Que manque‐t‐il à gluster ?
On a envie de dire : pas grand chose… Le principal manque, me semble‐t‐il, concerne la gestion des clichés (snapshots) permettant, entre autres, d’assurer une sauvegarde à un instant t donné.
Il serait intéressant aussi de pouvoir régler le niveau de réplication par dossier dans un volume répliqué, afin de pouvoir assurer, pour certains dossiers, un niveau plus élevé. C’est une fonctionnalité proposée dans MooseFS.
Aller plus loin
- Site Web de la version communautaire de gluster (363 clics)
- GlusterFS sur Wikipedia (612 clics)
- Le guide de l’administrateur (303 clics)
- Les notes de version (50 clics)
# Fôtes
Posté par Zarmakuizz (site web personnel) . Évalué à 6.
Problème de parenthésage.
automatiquement.
Ce n'est pas nécessaire d'avoir un gluster que sur le site secondaire ? Le que serait-il de trop ?
Pourquoi pas une virgule entre manque et me ?
Commentaire sous licence LPRAB - http://sam.zoy.org/lprab/
[^] # Re: Fôtes
Posté par Bruno Michel (site web personnel) . Évalué à 3.
Merci pour les retours. J'ai corrigé la dépêche.
[^] # Re: Fôtes
Posté par BlindMan . Évalué à 0.
GMLF => Il me semble que c'est plutôt GLMF
# Géo-réplication
Posté par maxix . Évalué à 6.
J'ai l'impression de débarquer, mais... Quelle est la différence entre réplication et géo-réplication?
[^] # Re: Géo-réplication
Posté par Sytoka Modon (site web personnel) . Évalué à 10.
La réplication est synchrone. Il s'agit de serveur maître-maître. Tu peux écrire sur n'importe lequel.
La géo-réplication est asynchrone car, s'agissant de deux sites distants, le lien ne permet d'assurer la copie en temps réel. Il faut donc écrire sur le cluster A et les données ne se retrouve sur le cluster B que quelques temps après. Ce décalage n'est pas chiffré et dépend de la liaison entre les sites.
Le cluster B n'est donc pas à utiliser en écriture.
# sans retour de contribution?
Posté par Zenitram (site web personnel) . Évalué à 3.
Sûrement pas, une licence imposant le retour de contribution serait non libre il me semble... l'AGPL impose de fournir le source à l'utilisateur dans les "nuages", pas au développeur upstream. Aucun retour de contribution n'est donc imposé. Par contre, oui, ça aide à récupérer les patchs (du moment où on est utilisateur).
Rappel : le libre, c'est pour protéger l'utilisateur, pas le développeur... Après, l’utilisateur peut offrir au développeur, ou l'utilisateur peut être le développeur, mais c'est un cas spécial hors licence.
Sinon, comment définis-tu "utilisation abusive"? Par rapport à quoi? Parce que bon, je ne vois pas trop : les développeurs offraient des droits, ils souhaitent maintenant en offrir moins, mais il n'y avait rien d'abusif à respecter le choix initial des développeurs (c'est pas comme si l'AGPL est toute fraîche de ce matin pour patcher un bug d'hier...), c'est juste un choix de politique (dans le libre, on peut aussi faire du BSD, et fermer tout n'est pas abusif, c'est un choix de laisser ou pas la possibilité)
[^] # Re: sans retour de contribution?
Posté par Sytoka Modon (site web personnel) . Évalué à 9.
Je n'ai pas le temps de jouer sur le mots ce dimanche ;-)
Avec la GPL, tu prends le code source, tu le modifie et le propose sur un nuage sans offrir le code source aux utilisateurs, on ne peux rien te reprocher.
Les développeurs de gluster, voyant bien que le produit avait un intérêt pour les nuages, ont voulu se protéger de ce genre d'utilisation. D'où le passage AGPL. certes, la remonté n'est pas upstream mais vers les utilisateurs du nuage mais en cas de problème, c'est pas ce point qui pose vraiment problème. On joue donc a ce niveau presque sur les mots.
Pour les applications web, le passage GPL vers AGPL pour les personnes qui sont dans la philosophie GPL pour leurs projets n'est pas idiot, voire même me semble intelligent.
Par exemple, combien de bout de code GPL ont été modifié par Google, Facebook, Amazon... et servent dans leurs nuages sans qu'aucun patch ne soient connu ? gluster est un projet qui n'a pas voulu cela.
[^] # Re: sans retour de contribution?
Posté par Zenitram (site web personnel) . Évalué à 0.
C'était le point : tu parles des développeurs, le libre s'adresse aux utilisateurs. C'est une sacré différence tu ne penses pas? Je voulais juste faire remarque ce point : le libre ne s’intéresse pas aux développeurs, il est la pour protéger l'utilisateur, cet amalgame amène des trucs genre "bouh Canonical c'est pas bien pour le libre ils ne contribuent pas upstream" (alors que Canonical livre le code source à l'utilisateur, but du libre).
Jouer sur les mots? Peut-être. Pour moi, c'est démonstratif de l'erreur commise par des développeurs (et des libristes) sur ce qu'est le libre.
Je n'ai pas dit le contraire. Je trouve même la chose très pertinente, c'est même la GPL qui devrait disparaître pour laisser la place qu'à l'AGPL seule si on pour but de laisser toujours la liberté à l'utilisateur. Mais bon, chacun choisit sa licence.
[^] # Re: sans retour de contribution?
Posté par Sytoka Modon (site web personnel) . Évalué à 4.
Si tu reprends ma phrase, je dis que le changement de licence est là pour protéger le développement de gluster. Je ne parle pas des développeurs ;-) Le développement d'un code est tout aussi utile aux utilisateurs qu'aux développeurs...
Bref, au final, je trouve que le terme que j'avais choisi n'est pas si mal ;-)
[^] # Re: sans retour de contribution?
Posté par Grunt . Évalué à 2.
Ben non, ils en offrent davantage, vu qu'ils garantissent, en plus, le droit d'avoir accès aux sources du logiciel, y compris s'il est fourni sous forme de service et non de binaire.
THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
# Gluster vs MooseFS ?
Posté par Frédéric Massot (site web personnel) . Évalué à 3.
L'article sur MooseFS du Linux Mag d'avril 2011 finissait par une phrase sur Gluster un peu mystérieuse, en tout cas à semer le doute sur Gluster : "La liste de diffusion (de MooseFS) comporte de plus en plus de déçus de Gluster (entre autres), qui cherchent une solution alternative et qui fonctionne".
J'ai un peu cherché sur Google des articles comparatifs ou des commentaires de personne déçus de Gluster sans vraiment trouver de retour probant.
Alors quoi, Gluster fonctionne et est performant, ou il s'agit de petits trolls entre deux systèmes de fichiers distribués concurrents ?
[^] # Re: Gluster vs MooseFS ?
Posté par klipz . Évalué à 3.
Non ce n'était pas un troll :-), juste une simple constatation. Regarde les archives de la liste moosefs-users (http://sourceforge.net/mailarchive/forum.php?forum_name=moosefs-users), tu trouveras un certains nombre de personnes qui se plaignent de GlusterFS, et qui se sont donc tournés vers MooseFS.
[^] # Re: Gluster vs MooseFS ?
Posté par ut0mt8 (site web personnel) . Évalué à 1.
Je confirme que j'ai eu des retours assez négatif de potes qui utilise glusterfs dans des gros environnements web, notamment lors du passage à la 3.2.
[^] # Re: Gluster vs MooseFS ?
Posté par Christophe Turbout . Évalué à 3.
mes tests pour voir si ça tenait ses promesses en environnement ont abouti au même résultat avec la 3.0
au passage avec la 3.0 on ne pouvait pas faire de montage d'un serveur 64 bits sur un client 32 bits
(ça a peut-être été modifié depuis)
lors du passage 3.0 à 3.1 le format de déclaration a changé avec une doc dans un état instable ...
les gros transferts se sentent sur du sata2 avec une interface gigabit sur un mode réplication
à 2 serveurs ...
je vais re-tester sur la 3.2 quand même pour voir si pour de la réplication de données non critiques
en ligne ça peut être efficace.
En même temps, mon test n'était pas optimal non plus en terme de vitesse de disque (SATA2), ni
d'infrastructure montée (il est possible de gérer conjointement un stripping qui assure de la
vitesse et une réplication pour la sécurité mais je n'avais pas assez de matos à dispo).
En même temps c'est aussi un modèle qui peut-être intéressant : un cluster de petit disque
SATA réparti sur de nombreuses machines (comme des machines étudiantes par exemple)
[^] # Re: Gluster vs MooseFS ?
Posté par Greg (site web personnel) . Évalué à 3.
J'ai eu moi aussi de très mauvaises expériences avec GlusterFS, et je peux constater avec cette dépêche que les priorités de Gluster n'ont pas changés : toujours plus de fonctionnalités, mais aucune amélioration sur la stabilité !
Stabilité en terme de bugs, oui, mais aussi en termes de performances: on a parfois des comportements bizarres et inexpliqués au niveau applicatif ! (Ces problèmes pouvant peut-être à cause de FUSE)
Ce projet est excellent pour donner de bonnes idées aux autres (MooseFS et Ceph), mais n'est tout simplement pas exploitable en prod.
Ceph a une vision contraire à Gluster: pas de FUSE, d'abord la stabilité avant les fonctionnalités. D'ailleurs sur leur site il est écrit en rouge "Ceph is under heavy development, and is not yet suitable for any uses other than benchmarking and review." et pourtant je pense que leur version même-pas-alpha est déjà bien plus stable que Gluster.
[^] # Re: Gluster vs MooseFS ?
Posté par Frédéric Massot (site web personnel) . Évalué à 1.
Est-ce que tu as eu l'occasion de tester MooseFS qui lui aussi utilise FUSE ?
Est-ce que MooseFS est plus stable ou performant que Gluster ?
[^] # Re: Gluster vs MooseFS ?
Posté par klipz . Évalué à 2.
J'ai un cluster d'environ 50 To en prod depuis plus de six mois : jamais eu le moindre plantage, ça tourne niquel, et ça sort en "pointe" 500 Mb/s sans broncher (c'est le débit max qui correspond à mon besoin actuel, ce n'est pas la limite du cluster). Pas d'expérience sur GlusterFS par contre, je ne peux donc pas comparer...
[^] # Re: Gluster vs MooseFS ?
Posté par Frédéric Massot (site web personnel) . Évalué à 1.
C'est un cluster avec MooseFS ou Ceph ?
[^] # Re: Gluster vs MooseFS ?
Posté par klipz . Évalué à 1.
On parle de MooseFS, oui. Comme l'a signalé Greg, Ceph n'est pas encore prêt pour la prod (bien que très séduisant et à surveiller de près).
[^] # Re: Gluster vs MooseFS ?
Posté par Christophe Turbout . Évalué à 1.
le problème de mooseFS c'est le serveur de meta-données ...
tu le perds tu perds tout ...
un peu chaud comme principe !
[^] # Re: Gluster vs MooseFS ?
Posté par klipz . Évalué à 1.
Hmm il faut creuser un petit peu plus ;-), ça a (heureusement) été bien pensé à la base pour que ça n'arrive pas.
C'est justement le rôle du (des) metalogger(s), de dupliquer les metadonnées au fil de l'eau (un peu comme la répli entre deux MySQL) pour ne pas en arriver à cette situation de non retour. Et si ta machine de metadonnées (mfsmaster) crashe, en deux commandes tu transformes un metalogger en master et c'est reparti. Au pire tu auras perdu les quelques infos qui n'ont pas eu le temps d'être synchronisées avant le crash.
[^] # Re: Gluster vs MooseFS ?
Posté par Christophe Turbout . Évalué à 1.
chacun son point de vue ... un truc qui me fait un hachage de mes données
avec des meta-données en les répartissant sur n machines sans que je puisse
pouvoir accéder directement à mes fichiers si ça plante, je ne suis pas fan ...
c'est pour ca que glusterfs me plaisait plus a première vue, mais il manque
des fonctionnalités ...
[^] # Re: Gluster vs MooseFS ?
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
Je trouve moi aussi dommage ce point là dans MooseFS et je brancherais bien MooseFS sur une base Riak plutôt que sur une base MySQL ;-) Riak est une base NoSQL maîetre maîetre conçu pour les nuages...
http://www.basho.com/
[^] # Re: Gluster vs MooseFS ?
Posté par Greg (site web personnel) . Évalué à 1.
Après cette mauvaise expérience, je me suis rabattu sur une toute autre config à base de SAN et de NFSv4 ... Oui, l'expérience a été mauvaise à ce point là. N'empêche qu'avec cette nouvelle config, je n'ai eu jusqu'à présent aucun problème ni de perf ni de stabilité...
# Réplication morcelée
Posté par Kerro . Évalué à 3.
J'ai regardé et testé GlusterFS il y a quelques temps, et j'ai trouvé que c'est du bien bon travail.
Je trouve qu'il manque « le truc de base »: la réplication morcelée (je ne connais pas le vrai terme), comme on trouve pour les fichiers .par2 dans les newsgroups.
Ca fait office à la fois de duplication du contenu (résistance aux pannes) et de découpage en bandes (performances). La résistance aux pannes est très forte dès qu'on dépasse les 2 ou 4 volumes habituels, pour une perte de place faible.
Le principe est qu'on ajoute un certain pourcentage de données qui permettent de retrouver ses petits s'il manque un morceau. Le pourcentage en question est réglable. Par exemple 10% permet de perdre 10% des disques sans perte de données.
# Quelles sont les performances ?
Posté par porki . Évalué à 2.
En terme de performances, je pense que c'est fortement lié à la bande-passante disponible pour rapatrier le fichier. Y a-t-il des mécanismes de compression des flux ou de "dictionnaire de caractères" (je ne connais pas le terme exact) pour augmenter la vitesse de transfert ?
Y a-t-il une latence perceptible entre le moment où l'on demande un fichier et le moment où l'on commence à le rapatrier ?
Je reconnais que j'ai abandonné au bout de quelques minutes de recherche sur le site web : flemme du we :$
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.