6.4. Optimisation des performances avec GFS2
Il est généralement possible de modifier la manière dont une application gênante stocke ses données afin d'obtenir un avantage considérable en termes de performances.
Un exemple typique d'application problématique est un serveur de courrier électronique. Ceux-ci sont souvent organisés avec un répertoire spool contenant des fichiers pour chaque utilisateur (mbox), ou avec un répertoire pour chaque utilisateur contenant un fichier pour chaque message (maildir). Lorsque les demandes arrivent par IMAP, l'idéal est de donner à chaque utilisateur une affinité avec un nœud particulier. De cette manière, les demandes de consultation et de suppression de messages électroniques seront généralement traitées à partir du cache de ce nœud. Évidemment, si ce nœud tombe en panne, la session peut être redémarrée sur un autre nœud.
Lorsque le courrier arrive par SMTP, les nœuds individuels peuvent être configurés de manière à transmettre par défaut le courrier d'un utilisateur donné à un nœud particulier. Si le nœud par défaut n'est pas en place, le message peut être enregistré directement dans le spool de l'utilisateur par le nœud de réception. Là encore, cette conception vise à conserver des ensembles particuliers de fichiers en cache sur un seul nœud dans le cas normal, mais à permettre un accès direct en cas de défaillance d'un nœud.
Cette configuration permet d'utiliser au mieux le cache de pages de GFS2 et rend les défaillances transparentes pour l'application, qu'il s'agisse de imap ou de smtp.
La sauvegarde est souvent un autre point délicat. Encore une fois, si cela est possible, il est largement préférable de sauvegarder l'ensemble de travail de chaque nœud directement à partir du nœud qui met en cache cet ensemble particulier d'inodes. Si vous avez un script de sauvegarde qui s'exécute à intervalles réguliers et qui semble coïncider avec un pic dans le temps de réponse d'une application fonctionnant sur GFS2, il y a de fortes chances que le cluster n'utilise pas le cache de pages de la manière la plus efficace possible.
Évidemment, si vous êtes en mesure d'arrêter l'application pour effectuer une sauvegarde, cela ne posera pas de problème. En revanche, si une sauvegarde est exécutée à partir d'un seul nœud, une fois qu'elle est terminée, une grande partie du système de fichiers sera mise en cache sur ce nœud, ce qui pénalisera les performances pour les accès ultérieurs à partir d'autres nœuds. Ce problème peut être atténué dans une certaine mesure en supprimant le cache de page VFS sur le nœud de sauvegarde une fois la sauvegarde terminée à l'aide de la commande suivante :
echo -n 3 >/proc/sys/vm/drop_caches
Toutefois, cette solution n'est pas aussi bonne que celle qui consiste à s'assurer que l'ensemble de travail de chaque nœud est soit partagé, soit principalement en lecture seule dans la grappe, soit accessible en grande partie à partir d'un seul nœud.
