URL: https://linuxfr.org/news/glusterfs-32-la-geo-replication Title: GlusterFS 3.2 — La géo‐réplication Authors: Sytoka Modon Date: 2011年05月06日T21:23:47+02:00 License: CC By-SA Tags: système_de_fichiers, virtualisation, cluster, gluster, glusterfs et fs Score: 42 [GlusterFS](http://fr.wikipedia.org/wiki/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](http://wiki.lustre.org/) / [Ceph](http://ceph.newdream.net/) ou ceux utilisant l’interface [FUSE](http://fr.wikipedia.org/wiki/Filesystem_in_Userspace). Dans la même catégorie que **gluster**, on retrouve [MooseFS](http://www.moosefs.org/), sur lequel le magazine [GMLF](http://www.ed-diamond.com/produit.php?ref=lmag137&id_rubrique=1&caracteristique=1-2-&caracdisp=2-3-#) 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](http://fr.wikipedia.org/wiki/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](http://www.pnfs.com/) et [MooseFS](http://www.moosefs.org/)). 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]] (_GNU Affero General Public License_), 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 »... ---- [Site Web de la version communautaire de gluster](http://www.gluster.org/) [GlusterFS sur Wikipedia](http://fr.wikipedia.org/wiki/GlusterFS) [Le guide de l’administrateur](http://gluster.com/community/documentation/index.php/Gluster_3.2_Filesystem_Administration_Guide) [Les notes de version](http://gluster.com/community/documentation/index.php/Gluster_3.2_Release_Notes) ---- # 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é](http://gluster.com/community/documentation/index.php/Gluster_3.2:_Configuring_Distributed_Volumes) : 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é](http://gluster.com/community/documentation/index.php/Gluster_3.2:_Configuring_Distributed_Replicated_Volumes) : 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)](http://gluster.com/community/documentation/index.php/Gluster_3.2:_Configuring_Distributed_Striped_Volumes) : 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](http://gluster.com/community/documentation/index.php/Gluster_3.2:_Expanding_Volumes) (_expanding_) ; * [réduire](http://gluster.com/community/documentation/index.php/Gluster_3.2:_Shrinking_Volumes) (_shrinking_) ; * [migrer](http://gluster.com/community/documentation/index.php/Gluster_3.2:_Migrating_Volumes) (_migrating_) ; * [équilibrer](http://gluster.com/community/documentation/index.php/Gluster_3.2:_Rebalancing_Volumes) (_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](http://gluster.com/community/documentation/index.php/Gluster_3.2:_Exploring_Geo-replication_Deployment_Scenarios) : 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é](http://fr.wikipedia.org/wiki/Plan_de_reprise_d'activit%C3%A9) (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](http://gluster.com/community/documentation/index.php/Gluster_3.2:_Managing_Directory_Quota) : 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](http://xfs.org/index.php/XFS_FAQ#Q:_Quota:_What.27s_project_quota.3F)). 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](http://gluster.com/community/documentation/index.php/Gluster_3.2:_Understanding_your_GlusterFS_Workload) : 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](http://fr.wikipedia.org/wiki/Gestion_par_volumes_logiques) (_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](http://www.moosefs.org/).

AltStyle によって変換されたページ (->オリジナル) /