Red Hat Training

A Red Hat training course is available for Red Hat Enterprise Linux

1.4. GFS2 Node Locking

Afin d'obtenir la meilleure performance possible d'un système de fichier GFS2, il est trèsimportant de comprendre la théorie de base de son fonctionnement. Un système de fichiers à nœud simple est installé le long d'un cache. L'objet estd'éliminer le temps de latence d'accès au disque lorsque vous utilisez des données fréquemment demandées.Dans Linux, le cache de page (et historiquement le cache des tampons) fournit cettefonction de mise en cache.
Avec GFS2. chaque nœud a son propre cache de page qui peut contenir certaines portions des données sur-disque. GFS2 utilise le mécanisme de verrouillage nommé glocks (qui se prononce J-Lok) pour conserver l'intégrité du cache entre les nœuds. Le sous-système glock fournit une fonction de gestion de cache qui repose sur DLM distributed lock manager (gestionnaire du verrouillage distribué) , en tant que couche de communication sous-jacente.
Les glocks garantissent une protection pour le cache sur la base-inode, donc il y a un verrou par inode qui est utilisé pour contrôler la couche de mise en cache. Si le glock est octroyé en mode partagé (mode de verrouillage DLM), alors les données qui se trouvent sous ce glock pourront être mises en cache sur un ou plusieurs nœuds à la fois, de façon à ce que les nœuds puissent avoir un accès local aux données.
Si le glock est octroyé en mode exclusif (mode de verrouillage DLM : EX), alors un seul nœud peut mettre les données en cache sous ce glock. Ce mode est utilisé par toutes les opérations qui modifient les données (comme write d'appel de système).
Si un autre nœud demande un glock qui ne peut pas être octroyé immédiatement, alors le DLM enverra un message au nœud ou aux nœuds qui contiennent actuellement les glocks bloquant la nouvelle demande, pour leur demander d'abandonner leurs verrous. Abandonner les glocks peut être un long processus (aux standards de la plupart les opérations de systèmes de fichiers). Pour abandonner un glock partagé, vous devrez simplement invalider le cache, ce qui est relativement rapide proportionnellement à la quantité de données mises en cache.
Pour abandonner un glock exclusif, vous devrez vider un journal, et inscrire à nouveau toutes les données modifiées dans le disque, suivies par l'invalidation comme pour le glock partagé.
La différence entre un système de fichiers à nœud simple et GFS2, c'est qu'un système de fichiers à nœud simple ne possède qu'un seul cache et GFS2 possède un cache séparé sur chaque nœud. Dans les deux cas, la latence d'accès aux données mises en cache est du même ordre de magnitude, mais la latence pour accéder à des données non mises en cache est bien plus élevée dans GFS2 si un autre nœud a déjà mis ces mêmes données en cache.

Note

Compte tenue la façon dont la mise en cache GFS2 opère, on obtient de meilleurs résultats avec une des actions suivantes :
  • L'inode est utilisée en mode lecture seulement dans tous les nœuds.
  • Une inode est écrite ou modifiée à partir d'un seul nœud uniquement.
Notez que l'insertion ou la suppression d'entrées d'un répertoire pendant la création d'un fichier comptent comme une écriture sur l'inode du répertoire.
Il est possible de ne pas respecter cette règle si ce n'est pas trop fréquemment. Si vous ignorez cette règle, la performance s'en ressentira.
Si vous mmap() un fichier sur GFS2 avec un mappage lecture/écriture, mais que vous ne faîtes que de lire, cela ne comptera uniquement que comme une lecture. Mais sur GFS, cela compte en tant qu'écriture, donc GFS2 est bien plus adaptable avec la commande mmap() I/O.
Si vous n'installez pas les paramètres noatime mount, alors les lectures vont également résulter en écritures pour mettre les horodatages de fichiers à jour. Nous recommandons que tous les utilisateurs GFS2 montent leurs fichiers avec noatime à moins que pour des raisons particulières, vous ayez besoin de atime.

1.4.1. Réglage de la performance avec GFS2

Il est normalement possible d'altérer la façon dont une application, qui peut causer des problèmes, stocke ses données pour obtenir un avantage considérable de performance.
Un serveur email est un exemple typique d'application compliquée qui peut causer problème. Ils sont souvent situés dans un répertoire spool qui contient des fichiers pour chaque utilisateur (mbox), ou avec un répertoire pour chaque utilisateur contenant un fichier pour chaque message (maildir). Quand les requêtes arrivent par IMAP, l'arrangement idéal est de donner à chaque utilisateur une affinité à un nœud particulier. Ainsi, les requêtes d'affichage ou de suppression de messages email seront plutôt servies par le cache sur ce nœud en particulier. Évidemment, si ce nœud échoue, alors la session pourra être redémarrée sur un nœud différent.
Quand le courrier arrive par SMTP, alors les nœuds individuels sont configurés pour pouvoir faire passer le courrier d'un utilisateur à un nœud particulier par défaut. Si le nœud par défaut n'est pas activé, alors le message sera sauvegardé directement dans le pool de courrier de l'utilisateur par le nœud récipient. Ce concept est destiné à conserver certains groupes de fichiers en cache sur un seul nœud normalement, mais de permettre un accès direct en cas d'échec.
Cette configuration permet la meilleure utilisation possible du cache de page de GSF2, et rendent les échecs transparents dans l'application, soit en imap ou en smtp.
La sauvegarde est souvent problématique. Si possible, il est largement préférable de sauvegarder les charges de travail de chaque nœud directement plutôt du nœud qui met en cache ce groupe d'inodes particulier. Si vous possédez un script de sauvegarde qui exécute à un moment précis, et que ce moment semble coïncider avec une Spike dans le temps de réponse d'une application s'exécutant sur GFS2, alors, il y a une bonne chance que le cluster ne profite pas efficacement du cache de page.
De toute évidence, si vous êtes dans la position (enviable) de pouvoir stopper l'application pour pouvoir faire une sauvegarde, alors ce ne sera pas un problème. Mais, si la sauvegarde n'est exécutée que sur un seul nœud, alors une fois complétée, une grande portion du système sera mis en cache sur ce nœud, accompagné d'un pénalité de performance pour les accès ultérieurs d'autres nœuds. Cela peut être mitigé, dans une certaine mesure, si vous mettez le cache de page VFS dans le nœud de sauvegarde après que la sauvegarde soit terminée, à l'aide de la commande suivante : 
echo -n 3 >/proc/sys/vm/drop_caches
Ce n'est cependant pas une solution aussi satisfaisante que de faire attention à ce que la charge de travail de chaque nœud soit partagée, en lecture à travers le cluster, ou accessible largement à partir d'un simple nœud.