SynerGeek.fr Informatique & Veille Technologique
Il y a déjà quelques temps, j’avais écrit un article sur le logiciel glusterfs.
GlusterFS est un logiciel libre de système de fichiers distribué en parallèle, capable de monter jusqu’à plusieurs pétaoctet.
GlusterFS est un système de fichiers de cluster/réseaux. GlusterFS est livré avec deux éléments, un serveur et un client.
Le serveur de stockage (ou chaque serveur d’un cluster) fait tourner glusterfsd et les clients utilisent la commande mount ou glusterfs client pour monter les systèmes de fichiers servis, en utilisant FUSE.
GlusterFS repose sur un modèle client-serveur. Les Serveurs sont typiquement déployés comme des «briques de stockage», chaque serveur exécutant un daemon glusterfsd qui exporte un système de fichier local comme un «volume». Le processus client glusterfs, qui se connecte aux serveurs avec un protocole spécifique (implémenté au-dessus de TCP/IP, InfiniBand ou SDP), regroupe les volumes distants en un unique volume. Le volume résultant est alors monté par l’hôte client par un mécanisme FUSE. Les applications traitant des nombreuses entrées/sorties peuvent aussi utiliser la bibliothèque client libglusterfs pour se connecter directement à des serveurs et exécuter les traducteurs de façon interne sans avoir à passer par le système de fichier et le sur-débit induit par FUSE.
La plupart des fonctionnalités de GlusterFS sont implémentées comme traducteurs, incluant :
- Duplication et Réplication par fichier
- Partage de charge par fichier
- Gestion des pannes
- Ordonnancement et Cache disque
- Quotas
Le serveur GlusterFS server est conçu très simplement: il exporte un système de fichier existant comme tel, laissant aux traducteurs côtés clients de structurer l’espace. Les clients eux-mêmes sont sans état, ne communiquent pas entre eux, et sont sensés disposer de configurations de traducteurs cohérents entre eux. Cela peut poser des problèmes, mais permet à GlusterFS de monter jusqu’à plusieurs peta-octets sur du matériel habituel en évitant les goulots d’étranglements qui affectent normalement les systèmes de fichiers distribués plus stricts.
(http://fr.wikipedia.org/wiki/GlusterFS)
Voici comment réaliser un système de fichier distribué sur 4 serveurs. Une redondance de 2 est requise pour chaque données (équivalent à un RAID1).
Les commandes ont été réalisées sous CENTOS 5 (en réalité, une VM HyperV ) . Pour simplifier mes propos, je pars du principe qu’aucun pare-feu n’est actif (IPtables/SELinux). Je travaille en root.
Installation de GlusterFS sous CentOS 5
1 ./ Installation des prérequis
yum -y install openssh-server wget fuse fuse-libs openib libibverbs
2./ Téléchargement de GlusterFS
wget http://download.gluster.com/pub/gluster/glusterfs/3.1/LATEST/CentOS/glusterfs-core-3.1.3-1.x86_64.rpm
wget http://download.gluster.com/pub/gluster/glusterfs/3.1/LATEST/CentOS/glusterfs-fuse-3.1.3-1.x86_64.rpm
wget http://download.gluster.com/pub/gluster/glusterfs/3.1/LATEST/CentOS/glusterfs-rdma-3.1.3-1.x86_64.rpm
wget http://download.gluster.com/pub/gluster/glusterfs/3.1/LATEST/CentOS/glusterfs-debuginfo-3.1.3-1.x86_64.rpm
3./ Installation de GlusterFS
rpm -Uvh glusterfs-core-3.1.3-1.x86_64.rpm
rpm -Uvh glusterfs-fuse-3.1.3-1.x86_64.rpm
rpm -Uvh glusterfs-rdma-3.1.3-1.x86_64.rpm
rpm -Uvh glusterfs-debuginfo-3.1.3-1.x86_64.rpm
4./ Démarrage du service GlusterFS
chkconfig glusterd on
/etc/init.d/glusterd start
5./ Création d’un repertoire local où seront sauvegardes les infos du cluster de stockage GlusterFS
mkdir /glusterlocal
Les quatre étapes ci-dessus sont à réaliser sur chacun des nœuds GlusterFS (192.168.1.1, 192.168.1.2, 192.168.1.3, 192.168.1.4, 192.168.1.5)
6./ Connexion aux différents nœuds GlusterFS depuis 192.168.1.1
gluster peer probe 192.168.1.2
gluster peer probe 192.168.1.3
gluster peer probe 192.168.1.4
gluster peer probe 192.168.1.5
gluster peer status
7./ Création d’un système de fichier « test-volume »
gluster volume create test-volume replica 2 transport tcp 192.168.1.2:/glusterlocal 192.168.1.3:/glusterlocal 192.168.1.4:/glusterlocal 192.168.1.5:/glusterlocal
gluster volume start test-volume
gluster volume info test-volume
8./ Créer un point de montage pour « test-volume » sur 192.168.1.1
mkdir /gluster
9./ Monter le système de fichier distribué
mount -t glusterfs 192.168.1.2:/test-volume /gluster
Plus d’info : http://www.gluster.com/community/documentation/index.php/Gluster_3.1_Filesystem_Administration_Guide
Bonsoir,
Article intéressant, je vais le mettre en place prochainement dans le cadre d’un pra.
Il existe 2 modes: replication (master /master) ou les x noeuds son accessible en écriture et un mode geo-replication ou la nous somme en (master/slave) les slaves n’etant pas accessible en écriture.
Y’a t’il des retours d’expérience dans le cas master/master entre deux noeuds geographiquement eloigné et si la liaison entre les deux venait a tomber ?
Les deux noeuds toujours accessible en ecriture pourrait se retrouver au moment du rétablissement de la liaison avec une incohérence sur des fichiers modifiés différemment des deux cotés comment cela se passe t’il dans ce cas ?
Merci pour vos retour d’expérience et au passage excellent article 🙂
oui drbd + nfs si tu recherches un simple mirroir “over lan”
Je prépare une article là dessus d’ailleurs
a+
Vous conseillez plutôt DRBD que GlusterFS ??
En effet GlusterFS est facilement installable/configurable comparé à DRBD.
Mais question performances j’ai l’impression que GlusterFS n’est pas tip top…
NFS+DRBD restent peut être la meilleur solution pour du HA ?!
Mettre un SGBD sur Gluster, je suis curieux d’avoir votre retour d’expérience.
J’ai installé GlusterFS 3.0.5 en production pour une application d’éditique produisant 40000 fichiers par jour, pour un total d’à peu près 200 Mo.
Aucun problème depuis Octobre 2010.
Je l’ai aussi installé pour héberger (hors production) des VM KVM et pour disposer du live migration. Résultat: perte d’un seul paquet ping lors de la migration de la VM d’un serveur à l’autre. Les performances restent correctes.
Pour avoir de bonnes performances, il ne faut pas sous estimer le hardware. Les deux installations que j’évoque ont été réalisées sur des Dell PowerEdge R610 avec des processeurs Intel E5520.
Je m’aprête à tester la version 3.1 de Gluster et à me doter d’outillage pour mesurer les performances IO de manière précise. Cela permettrai de se prononcer sur l’hébergement de services plus critiques, comme un SGBDR, par exemple.
Si vous avez des suggestions à propos d’outils de perfs IO n’hésitez pas, je partagerai les résultats des tests.
Mon expérience est que GlusterFS est sur le papier l’offre la plus simple à installer et à utiliser.
Il est, dans mon métier, un concurrent des solutions Moose, Lustre & co et du “serveur d’espace de stockage” historique NFS.
Dans les faits, la surcouche FUSE, non intégré dans la plupart des noyaux et plus ou moins bien supporter par les distributions (bien par RH et mal par Debian), apporte plus de problèmes que de solutions, notamment en terme de perfs sur les IO.
Pour arranger les choses, il faudrait que les lib glusterfs soient intégrées au noyau.
Dans ce cas, quelle serait l’utilisation d’une telle technologie ?
Sauvegarde en mode hébergé ? Plateforme de sites web ? …
On ne peux pas comparer NFS et Glusterfs (ou tout autres système de fichiers distribués).
De toute façon, en terme de concentration de machines virtuelles, le problèmes se sont les IO disques.
L’impact de tel ou tel système de fichiers sera minime s’il n’y a pas le nombre de disques physiques pour donner la puissance de traitement en lecture/écriture requise.
Quand le nombre de VM augmente et qu’il n’existe plus de infrastructure matérielle suffisante pour stocker tous les disque dans une même enceinte, il faut passer à une architecture de stockage distribuée – c’est à dire que l’espace de stockage est répartie entre plusieurs baies de stockage. Fini le NFS!
GlusterFS a attiré mon attention car il est extrêmement simple à mettre en oeuvre – il tourne notamment dans le USERSPACE (fuse). C’est probablement là une des raisons probable de son éventuel manque de performance (là encore, je n’ai pas fait de tests de prod à grande échelle).
L’autre différence de GLusterFS est qu’il ne dépends d’un serveur de gestion des métadata centralisé – dans la théorie ceci est un grand avantage en terme de performance lors de la montée en charge.
Je suis curieux d’avoir le retour d’expérience d’utilisateurs ayant essayé MooseFs , Lustre, Ceph…
Sur une Debian, les performances brutes de GlusterFS post-installation sont inférieures à un mauvais serveur NFS…
Ce n’est pas très engagent.
Je n’ai jamais mis le produit en prod mais il est clair que les performances que j’ai relevé étaient très modestes.
D’un autre coté, je comprends la logique qui veux plus on met de noeuds en “stripe”, meilleures sont les performances. A ce titre, glusterfs est intéressant car il ne repose pas sur un noeud central pour stocker les métadata.
Peux-être que yacine de Alyseo qui lit parfois ces colonnes et qui commerciale GlusterStor aura-t-il un retour d’expérience à nous faire partager?
J’ai relevé dans le dernier LinuxMag des propos très critique à propos de GlusterFs (mais ils ne sont guère explicites)
Non effectivement vous n’en avez pas parlé mais c’est ce que la société derrière GlusterFS essaie de vendre.
De lojn GlusterFS fait rêver de par ses possibilités annoncés mais j’ai peur qu’en réalité il soit réservé à des cas d’usage particuliers (je pense en particulier à du stockage de fichiers quasi statiques : photos, videos, logs)
Je ne pense pas avoir parlé de support d’exploitation pour des VM.
Effectivement, les performances ne seraient vraiment pas au rendez-vous.
Et question performance cela donne quoi par rapport à d’autres solutions (ext3 sur disque local, nfs, drbd) ?
Je suis assez sceptique quand je lis qu’il serait possible de stocker des machines virtuelles sur ce type de système de fichier.