[Projet] Le stockage distribué avec GlusterFS

GlusterFS Header

Cet article est le premier d’une longue série portant sur la réalisation de mon projet de fin d’année, que je vous présente ici. Je commence donc par la partie stockage de l’infrastructure, et après avoir posé la question sur le forum de linuxfr.org, mon choix s’est porté vers GlusterFS.

Voici donc comment j’ai configuré tout cela !

Mais d’abord GlusterFs c’est quoi ?

GlusterFS est un outil qui va nous permettre d’agréger du stockage d’un grand nombre de serveurs pour ne créer qu’un seul lecteur virtuel, offrant potentiellement d’énormes quantités de gigaoctets, que nous allons pouvoir monter en toute simplicité sur des clients. GlusterFS est capable de gérer des millions de téraoctets pour des milliers de clients ! On devrait être tranquille pour notre minuscule projet…

Un point de montage unique... (Source)

Un point de montage unique… (Source)

Comme tout système de fichiers distribués qui se respecte, GlusterFS fonctionne sur des volumes de type bloc (disque, RAID, LVM…), offre des options de redondance de données ou de géo-réplication et gère les accès concurrents. Pour couronner le tout il est vraiment très simple à installer et administrer…

Théoriquement le débit de données augmente au fur et à mesure que nous ajoutons des serveurs à notre cluster… Et bien sachez que Gluster gère aisément plusieurs milliers de clients sur le même lien (Gigabit évidemment) car il utilise des connections TCP/IP et InfiniBand RDMA. C’est donc un outil tout indiqué pour le stockage de petite ou de grande dimension, puisqu’il gère de manière intelligente la répartition de charge, la réplication des données et les métadonnées, rendant votre serveur hautement disponible et résistant à toutes les pannes !

Ce que nous allons mettre en place

Le but ici est de mettre en place le cluster situé en haut à gauche du schéma global du projet. On va partir sur un cluster à deux nœuds (pour des questions de ressources limitées) basé sur des machines Debian 7.2 Stable. 1Go de mémoire vive (minimum requis pour Gluster) et 4 cartes réseaux sont affectées aux deux machines afin d’assurer une redondance optimale.

Question stockage, nous allons exporter un volume RAID5 constitué de trois disques de 10Go chacun (on est sur du POC donc pas la peine de prévoir gros), toujours dans un souci de tolérance aux pannes. Schéma :

Cliquez sur l'image pour agrandir le schéma

Cliquez pour agrandir le schéma

Préparation des hôtes

Alors évidemment si vous n’êtes là que pour GlusterFS, vous pouvez zapper cette partie qui est très spécifique à mon projet.

Configuration du réseau

Après avoir installé Debian 7.2 Stable, je m’attaque à la configuration réseau. J’ai quatre cartes réseau sur ma machine, que je vais grouper deux par deux. Le premier agrégat (bond0) sera dédié au trafic vers et depuis les clients (dans mon cas un cluster Apache) et le deuxième agrégat sera réservé au trafic de réplication des données, gérée par Gluster.

Je ne reviens pas sur ifenslave dont j’ai déjà amplement parlé, sachez néanmoins que la documentation de GlusterFS recommande d’utiliser le mode 6, ou balance-alb. Enfin, il est aussi conseillé d’utiliser des Jumbo Frames car la réplication de nos données va générer un fort trafic.

Configuration du stockage

Là aussi je reste sur une technologie simple puisque le volume RAID5 exporté par GlusterFS est un raid logiciel géré par mdadm. Pour se rafraîchir la mémoire :

apt-get --no-install-recommends install mdadm
mdadm --create /dev/md0 --level=5 --assume-clean --raid-devices=3 /dev/sdb1 /dev/sdc1 /dev/sdd1

N’oubliez pas de préparer vos partitions en les marquant du drapeau « Raid Linux auto » ! Une fois mon RAID prêt, je le formate en XFS :

apt-get install xfsprogs
mkfs.xfs /dev/md0

Je monte le volume et j’ajoute la petite ligne qui va bien dans /etc/fstab pour ne plus avoir à m’en soucier :

mount /dev/md0 /srv/gluster
# Volume RAID5
/dev/md0        /srv/gluster    xfs     defaults        0       1

Autres

Comme je travaille sur des machines virtuelles VMware, je n’oublie pas les indispensables VMware Tools !

Installation et configuration de GlusterFS

Installation de GlusterFS

Normalement les paquets sont dans les dépôts 🙂 Ils sont à installer sur tous les nœuds du cluster.

apt-get install glusterfs-server

Toutes les dépendances sont automatiquement installées, je pense notamment à FUSE, très utilisé par Gluster.

Configuration du pare-feu (préparation des briques)

Chaque nœud va « exporter » un dossier, appelé brique, au sein de notre cluster qui va combiner plusieurs briques pour former un « entrepôt de données », que les clients verront comme un seul volume géant. C’est ce volume géant qu’ils pourront monter comme un disque classique !

Comme les nœuds ont besoin d’échanger des informations entre eux, il va falloir ouvrir quelques ports, à savoir :

  • Le 111 / UDP ET TCP
  • Le 24007 / TCP
  • Le 24008 / TCP
  • Et un port supplémentaire par brique en partant du 24009 / TCP

Avec iptables cela devrait donner un truc comme :

iptables -I INPUT -m state --state NEW -m tcp -p tcp --dport 24007:24010 -j ACCEPT
iptables -I INPUT -m state --state NEW -m tcp -p tcp --dport 111 -j ACCEPT
iptables -I INPUT -m state --state NEW -m udp -p udp --dport 111 -j ACCEPT
service iptables save
service iptables restart

Note : je n’ai pas utilisé de pare-feu sur ma machine donc je n’ai pas testé cette configuration…

On va pouvoir démarrer le daemon Gluster sur tous nos nœuds, avant de passer à la création du cluster !

service glusterfs-server start

Mise en place du cluster

Gluster se configure à partir d’un nœud et peu importe lequel puisque la configuration est automatiquement propagée sur le reste du cluster. Un peu comme Corosync / Pacemaker finalement… Je propose de se connecter en root sur le premier noeud. Nous allons utiliser les outils gluster pour instaurer une confiance entre les machines.

gluster peer probe 10.1.0.12
Probe successful

Si votre fichier hosts est correctement rempli sur vos serveurs vous pouvez utiliser leur nom au lieu de leur adresse. Quoiqu’il en soit la commande suivante devrait vous apporter quelques informations :

gluster peer status
Number of Peers: 1
 
Hostname: 10.1.0.12
Uuid: 443e4b4d-bc63-4af0-b878-d5b5407b87b4
State: Peer in Cluster (Connected)

Inutile de dire à votre machine de faire confiance à elle-même. Si jamais vous avez fait une erreur, vous pouvez retirer un nœud avec la commande :

gluster peer detach <IP>

Construction de « l’entrepôt de données »

L’étape suivante consiste tout simplement à indiquer à GlusterFS quels dossiers (briques) nous souhaitons exporter. Dans mon cas j’utilise le dossier /srv/gluster sur lequel j’ai monté mes RAID5. Il est conseillé d’utiliser des volumes formatés en XFS, mais Gluster doit pouvoir fonctionner avec de l’ext3, de l’ext4 ou n’importe qu’elle autre système de fichier compatible avec la famille de standards POSIX.

Je répète que le matériel utilisé pour le stockage importe peu. Je veux dire par là que mon /srv/gluster aurait très bien pu être un SAN, un simple disque ou même un EBS Amazon ! Pour créer le volume gluster intitulé gfsvol1 :

gluster volume create gfsvol replica 2 GFS-01:/srv/gluster GFS-02:/srv/gluster
Creation of volume gfsvol has been successful. Please start the volume to access data.

Cette commande permet de créer un volume sur lequel les données sont dupliquées une fois. Une donnée A est donc copiée sur mes deux nœuds, afin de répondre à mes besoins de haute-disponibilité. Pour obtenir des informations sur votre volume, vous pouvez utiliser :

gluster volume info
 
Volume Name: gfsvol
Type: Replicate
Status: Created
Number of Bricks: 2
Transport-type: tcp
Bricks:
Brick1: 10.1.0.11:/srv/gluster
Brick2: 10.1.0.12:/srv/gluster

STOP ! Que signifie ce charabia ?!

  • Volume Name correspond au nom de notre volume, ici gfsvol1.
  • Type indique le type de volume utilisé. Il en existe 7 afin de répondre à presque tous les besoins et « distributed » est celui utilisé par défaut. Cela signifie qu’un fichier sera aléatoirement « distribué » sur l’une des bricks. Comme je souhaite faire de la haute-disponibilité de données je me suis plutôt orienté vers du « replicated ».
  • Status nous affiche l’état du volume. Ici il est créé mais pas démarré
  • Vient ensuite le nombre total de briques dans le cluster, ici 2.
  • Le type de transport utilisé (TCP par défaut, mais vous pouvez utiliser RDMA si vous en avez les capacités) et la liste des briques.

Il ne nous reste plus qu’à démarrer le volume :

gluster volume start gfsvol
Starting volume gfsvol has been successful
gluster volume info         
 
Volume Name: gfsvol
Type: Replicate
Status: Started
Number of Bricks: 2
Transport-type: tcp
Bricks:
Brick1: 10.1.0.11:/srv/gluster
Brick2: 10.1.0.12:/srv/gluster

"Status" est bien passé à "Started".

Nous voilà donc avec un espace de stockage redondé qui sera normalement capable de gérer les accès concurrents générés par les futurs clusters Apache et saura répondre aux besoins de tolérance de panne et de haute disponibilité de l’application développée dans le cadre de mon projet de fin d’année. Dans le prochain article sur GlusterFS, nous verront comment connecter nos premier clients en utilisant le client natif Gluster. Mais avant il y a un cluster Apache / PHP Actif / Actif à mettre en place !


Sources :

Cet article vous a plu ? Partagez-le sur les réseaux sociaux !

Twitter Facebook Google Plus email