à Octopuce, nous gérons de plus en plus des infrastructures complexes, comprenant un grand nombre de machines virtuelles, pour permettre de garantir qu’un site web répondra même si une de ses VM est éteinte, soit pour maintenance, soit suite à une panne (ça arrive!)
Assez souvent, nous avons donc 2 serveurs web servant le même code PHP par exemple, déployé en parallèle sur 2 serveurs (appelons les web1 et web2). Or ces serveurs web reçoivent souvent des contenus soit des internautes, soit des administrateurs du site. Typiquement, des images, des photos, medias, qui doivent être ensuite rendus visibles sur le site, sans pour autant être dans leur dépôt de code source. Ces fichiers doivent donc être à la fois présents sur web1 et web2 à tout instant, tout en garantissant que si web1 ou web2 tombe, l’autre continuera à accepter de nouveaux fichiers. Comment faire ?
La première solution consiste à utiliser un dossier partagé en NFS, qui permet d’avoir un dossier (appelons-le assets/) partagé entre web1 et web2. Ainsi, si quiconque écrit sur l’un, on verra le fichier immédiatement sur l’autre. Cependant, bien que tentante, cette solution ne fait que repousser le besoin de redondance sur le serveur NFS !
Glusterfs c’est quoi ?
Arrive alors GlusterFS, programme client/serveur pour Linux qui permet de résoudre ce problème :
Glusterfs a deux parties : un Serveur Gluster installé sur un ou plusieurs serveurs, et un ou plusieurs Client Gluster qui peuvent très bien être sur la même machine que le serveur.
- Chaque Serveur Gluster est rattaché à un ou plusieurs autres serveurs appelés peers, formant une grappe (cluster en anglais) de serveurs
- On lui fournit ensuite un ou plusieurs dossiers appelés bricks dans lesquels il va stocker ses données
- On y crée ensuite un partage appelé volume en précisant quelle redondance on souhaite pour ces données. Ainsi, si on a 2 serveurs gluster et qu’on pose une redondance de 2, chaque serveur aura une copie de l’intégralité des données
- Enfin, les clients peuvent se connecter aux volumes en utilisant un des protocoles classiques, NFS ou Samba, que gluster-server sait parler, ou plus simplement le protocole gluster, que l’on peut utiliser avec un client FUSE, donc directement dans /etc/fstab
Enfin pour piloter gluster, on utilise la ligne de commande gluster suivie d’une commande (volume create, peers status etc.)
Exemple de gluster minimal
Exemple de configuration
Nous allons vous montrer comment utiliser Gluster sur Debian Jessie sur web1 et web2. On installe glusterfs-server via apt sur les machines web1 et web2 :
web1~# apt-get install glusterfs-server
Notez que cela installe rpcbind, statd et idmapds, les outils nfs-common. Vous n’avez que besoin de rpcbind, vous pouvez désactiver les 2 autres via /etc/default/nfs-common :
NEED_STATD=no NEED_IDMAPD=no
De plus, il faut disposer des ACL, les attributs Posix étendus sur les fichiers, sur votre serveur glusterfs. sur le système de fichier EXT2/3/4, il s’agit de l’option acl dans /etc/fstab comme dans l’exemple ci-dessous :
/dev/md2 /chemin/vers/un/dossier ext4 auto,noatime,discard,acl 0 0
si vous devez modifier votre fichier fstab, n’oubliez pas de remonter la partition avec
mount /chemin/vers/un/dossier -o remount,acl
Configuration réseau
Glusterfs étant un protocole réseau, on ne souhaite pas forcément laisser ce service accessible depuis l’Internet. Je recommande donc de configurer le glusterd de telle sorte qu’il n’écoute que sur vos IP et interfaces privées. Par exemple : dans /etc/glusterfs/glusterd.vol, on mettra :
option transport.rdma.bind-address 10.0.1.61 option transport.socket.bind-address 10.0.1.61 option transport.tcp.bind-address 10.0.1.61
(où 10.0.1.61 est l’IP de web1) et on redémarre glusterfsd. N’oubliez pas de le faire sur les 2 serveurs.
web1~# service glusterfs-server restart web2~# service glusterfs-server restart
Découverte sur le réseau
Ensuite, on fait découvrir le serveur 1 au serveur 2, et on vérifie qu’ils se voient bien :
web1~# gluster peer probe web2.private web1~# gluster peer status Number of Peers: 1 Hostname: web2.private Uuid: 3c849f4e-1363-4e2b-a721-af920093a446 State: Peer in Cluster (Connected)
Ajout de Bricks, création d’un Volume
Ensuite, préparez sur chaque serveur un dossier avec suffisemment de place et indiquez le à gluster :
web1~# mkdir /data web2~# mkdir /data web1~# gluster volume create monpartage replica 2 transport tcp web2:/data/monpartage web1:/data/monpartage force web1~# gluster volume start monpartage
et voilà ! votre volume est désormais accessible sur le réseau
Installation du client gluster
On installe le client glusterfs via apt :
web1~# apt-get install glusterfs-client
et on peut ensuite monter le partage très simplement :
web1~# mount web1.private:/monpartage /var/www/shared -t glusterfs -o defaults
Si vous monter de même sur web2 :
web2~# mount web2.private:/monpartage /var/www/shared -t glusterfs -o defaults
Et voilà ! À partir de maintenant, tout fichier créé, modifié, ou effacé sur /var/www/shared sur l’une de ces machines sera automatiquement et immédiatement visible à l’autre.
Faire marcher Gluster dans un LXC ?
Chez Octopuce, nous cloisonnons la plupart de nos VM avec les Containers Linux (LXC), voici comment faire marcher glusterfs-server et glusterfs-client dans un container :
Le LXC doit avoir le droit de monter des partitions (utilisation de /etc/fstab et des commandes mount et umount) et le droit de piloter le périphérique FUSE. Pour cela, on indique donc, dans le fichier config
du LXC :
Dans la liste des lxc.cap.drop, ne PAS enlever la capability sys_admin :
# lxc.cap.drop = sys_admin
Ajouter l’autorisation de gérer /dev/fuse : (les 2 lignes ci-dessous, si possible regroupée avec les autres devices.allow) :
# fuse lxc.cgroup.devices.allow = c 10:229 rwm
Enfin, dans le dossier /dev/ du rootfs de votre LXC, créez le périphérique /dev/fuse :
physical-host:~# cd /var/lib/lxc/mavm/rootfs/dev physical-host:/var/lib/lxc/mavm/rootfs/dev# mknod fuse c 10 229