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 (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 »…

Sommaire

• Les fonctionnalités de la 3.0
• Quoi de neuf avec la 3.2 ?
• Que manque‐t‐il à gluster ?

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.