NFS est une super techno, quand elle fonctionne. 4 ans que mon architecture NFS est en production, sans pépin. Mais quand on a un pépin, les frontaux web ramassent fort, que ce soit des NGiNX ou des serveurs Apache2....

Que faire pour garder de la haute-dispo dans ces conditions, sans révolutionner l'ensemble, bref en peu de temps sans risquer de tout casser.... hé bien merci aux développeurs qui bossent sur le kernel Linux, parce que depuis peu (en terme de temps), ils ont intégrés le module FSCACHE qui permet d'ajouter une couche de cache au dessus d'un système de fichier réseau. Tip top ! Voyons voir....

Installation et configuration

Pas de mystère, il faut partir sur un kernel assez récent et avec les modules FSCACHE d'activés:

# grep FSCACHE /boot/config-3.3.1-ez
CONFIG_FSCACHE=m
CONFIG_FSCACHE_STATS=y
# CONFIG_FSCACHE_HISTOGRAM is not set
# CONFIG_FSCACHE_DEBUG is not set
# CONFIG_FSCACHE_OBJECT_LIST is not set
CONFIG_NFS_FSCACHE=y
# CONFIG_CIFS_FSCACHE is not set
CONFIG_AFS_FSCACHE=y
# CONFIG_9P_FSCACHE is not set

Je vous laisserais dans ce cas construire votre kernel à votre sauce...

Perso, je bosse sous Debian Squeeze, l'installation se fait en quelques commandes qui parlent d'elles memes :

kadoc-05:/data/cache1# mkdir fscache
kadoc-05:/data/cache1# apt-get install cachefilesd
kadoc-05:/data/cache1# sed -i 's/#RUN/RUN/' /etc/default/cachefilesd
kadoc-05:/data/cache1# modprobe fscache

Cette partition /data/cache1 doit être monté avec l'option user_xattr, si ce n'est pas le cas ajoutez là dans votre fstab et mount -o remount.

Démarrez cachefilesd

Le reste de la magie se passe dans les options de montage des partitions que vous voulez cacher, dans mon cas les partoches nfs4 : ajouter l'option fsc aux options de montages et ... c'est terminé !

Au bout de quelques secondes d'utilisations, on voit bien que le cache est utilisé :

kadoc-05:/etc/nginx# find /data/cache1/fscache/ -type f | wc -l

76129

kadoc-05:/etc/nginx# du -hs /data/cache1/fscache/

912M    /data/cache1/fscache/

J'ai quand même fais les tests basiques avec le serveur NGiNX qui se charge de lire les documents sur NFS, en le stoppant, démontant les partitions NFSv4, le démarrant... les documents sont bien servit comme si tout fonctionnait correctement !

Le serveur en question est en prod depuis un jour, on va voir comment se passe le week-end puis j'activerais FSCache sur tous les frontaux !

Aujourd'hui, j'ai mis à jour GlusterFS sur les serveurs et les clients. Malgré que cette techno soit génial, on ne peut pas mettre à jour GlusterFS n'importe comment: il faut impérativement que les clients et les serveurs aient exactement la même version, même mineure ! Sinon, on obtient cette erreur, et le client ne se connecte pas :

SETVOLUME on remote-host failed: Version mismatch: client(2.0.0rc7) Vs server (2.0.0rc4)

Voici donc la procédure pour mettre à jour GlusterFS dans une architecture de type AFR client side, et en partant du principe que vous avez 2 serveurs.

1/ mettre à jour glusterfs sur le 1er serveur. Au restart, les clients ne pourront plus se connecter sur ce serveur. Vérifier dans les logs qu'il a bien démarré et qu'il n'y a pas eut de changement dans les paramètres.

2/ mettre à jour les clients, en arrêtant au préalable les services utilisant les montages glusterfs: il faut démonter puis remonter chaque partition pour avoir la dernière version du client. Les clients changent de serveurs au passage et se connecte au 1er serveur, qui a la même version.

3/ mettre à jour le 2ème serveur. Les clients vont automatiquement se connecter dessus.

4/ resynchroniser les données. Normalement la version 2.0 gère bien la synchro des données grâce à sa feature "self-healing". Dans le doute, on peut forcer, en faisant depuis un client connecté aux 2 nodes:

nice -20 find /glusterfs >/dev/null

That's all folks !

Présentation

• Gluster.org
• Création d'un cluster de fichiers à la fois serveur et client

Avantages

• GlusterFS est comparable à NFS, en beaucoup plus performant, plus scalable et prévu pour la haute-dispo.
• Le wiki est complet avec beaucoup de docs et de tutorials.
• L'architecture du projet permet d'empiler les fonctionnalités, on peut donc mixer les fonctionnalités pour faire du mirroring, striping, unification, read-ahead, write-behind, encryption etc.
• Automagic self-healing si un serveur tombe.
• Roadmap importantes avec plein de fonctionnalités intéressantes comme le mod apache, hot-plug de brick, interface web, etc.

Inconvénients

• Le projet est jeune.
• pas vraiment de retour d'expériences en environnement de production.
• Fonctionne en Userspace (FUSE) plutôt que dans un module kernel. Voir les implications sur les perfs.
• la doc est uniquement dans le wiki, un trac serait mieux...
• à vérifier: les données ne semble synchronisés qu'une fois lu, c'est à dire que si on écrit un fichier sur serveur B, les données sont tout de suite lisible, MAIS si on écrit d'autres fichiers sur serveur B, et qu'on ne les lit pas, ils ne sont pas synchronisés. Il faut donc forcer une lecture, par exemple:

find /mnt/rep -type f -exec head -n 1 {} \;
ou, plus efficace :
find /mnt/rep -type f -mtime -1 -exec head -c 1 {} > /dev/null \;

Dans le prochain billet: l'installation.

Actuellement, pour les sessions, nous utilisons un gros serveur et MySQL avec des tables en HEAP pour stocker les sessions. Problème, ces tables ne supportent pas les types BLOB et TEXT, ce qui implique d'utilise un champ VARCHAR, limité à 255 caractères, on atteint très vite cette limite.

Je suis donc à la recherche d'alternatives, sachant qu'on va stocker plus d'informations pour éviter au maximum les cookies, et que les performances requises sont importantes: aujourd'hui environ 2000 requêtes de sessions / secondes, demain ce sera bien pire à cause du web 2.0.

MySQL Cluster

MySQL n'est pas encore sortie en version stable en 5.1, version nécéssaire pour avoir un MySQL Cluster. Avec tous les problèmes que l'on rencontre avec 5.1 (enfin, uniquement les nouvelles fonctionnalités), le temps de mise en oeuvre, le coût des serveurs, cette solution est fortement compromise. D'autant plus que MySQL n'utilise pas sa propre solution pour ses propres besoins...

Zend Cluster

Alléchant sur le papier, mais beaucoup trop cher ! Ils vont devoir s'aligner pour espérer continuer à en vendre...

memcached

http://www.danga.com/memcached/

Comme stipulé à plusieurs endroits dans la doc, memcached est un serveur de cache avant tout. Ce qui veut dire perte de données en cas d'arrêt du démon. Il a été prévu pour faire du cache, et le fait d'ailleurs très bien. Son modèle cluster est orienté scalability et pas du tout redondance ni failover. Admettons que nous avons 3 serveurs memcached en cluster, A B et C. A chaque requête PHP en écriture (ajout, remplacement d'une session), le client se connecte à tous les serveurs, créé une clef en fonction de ces serveurs, et choisis un des serveurs: B. Seul B aura la valeur pour cette clef. La requête suivante, en lecture, veut lire cette clef, le client PHP se connecte aux 3 serveurs, génère la clef, et va chercher la valeur sur B. Très bien, on répartie la charge sur ces 3 serveurs, et la mémoire n'est pas gaspillé car les données ne sont pas duppliqué. Ainsi, si B tombe, on perd uniquement les données de sessions de ce serveur, on déconnecte donc seulement 1/3 des utilisateurs. Seulement voilà, c'est pas aussi beau. Si un noeud tombe, la liste des serveurs dans le pool change, et le client va regénérer toutes les clefs !! En d'autre terme, si un noeud tombe, on perd tout le cache ! On se retrouve donc avec autant de POF (Point Of Failure) que de serveurs. Dropped.

memcachedb

http://memcachedb.org/

Reprenant le moteur de memcached, le principe est différent, et cette fois le but n'est pas de faire du cache mais de stocker des données persistentes. En mode cluster, on a un fonctionnement identique à MySQL: un noeud est maitre, les autres noeuds répliquent et peuvent être accédé en lecture. Les performances sont là, leur benchmark indique atteindre 20000 écritures / secondes, et 45000 lectures / secondes, ce qui est amplement suffisant. Mais le principe du single master to many slaves est genant: il m'arrive régulièrement de retirer un serveur de la production, pour le mettre à jour, le restaurer, ou en cas de problèmes hardware... et si c'est le master qui a un problème ? on doit créer un autre master, et changer la config des slaves afin qu'ils répliquent leurs données depuis un autre master ! Dropped.

Sharedance

http://sharedance.pureftpd.org/

Ce logiciel a été créé pour cet usage et uniquement pour cet usage. Tout comme memcached, il excèle dans son travail. Tous les commentaires que j'ai pu trouvé sur le net en font l'éloge, et surtout on retrouve tout le temps "Ca n'a jamais planté". Un utilisateur atteint 200Mbps x 2 sur un seul serveur, époustouflant ! C'est la solution quasiment idéal... et oui, le soucis, c'est que c'est un SPOF ! Si ce serveur tombe, on n'a plus de sessions. Alors on pourrait implémenter un 2ème serveur avec Heartbeat, mais ce 2ème serveur n'aurait pas les données, en cas de crash on déconnecte alors tout le monde. Sharedance reste pour l'instant la meilleur solution, même si je ne l'ai pas encore testée, ça ne saurait tardé. Il manquerait une réplication type DRBD sur une partition tmpfs, pour allier performance et failover.

mcache

http://www.mohawksoft.org/?q=node/8

mcache semble le produit idéal, sur le papier. Il stock les données en ram et les copie (si besoin) sur disque régulièrement, possède un garbage collector pour supprimer les sessions périmées, et fonctionne en environnement distribué: un mcache par serveur PHP. Il faut que je le mette en place avec plusieurs noeuds, et vérifier les points suivants : si un noeud tombe, que se passe t'il ? Il faut aussi valider les performances.

Je vais donc créer plusieurs images Xen 32bits afin de tester mcache, et en parallèle tester sharedance. La suite aux prochains billets !