6.2. Verrouillage des nœuds GFS2
Afin d'obtenir les meilleures performances d'un système de fichiers GFS2, il est important de comprendre la théorie de base de son fonctionnement. Un système de fichiers à nœud unique est mis en œuvre avec un cache, dont le but est d'éliminer la latence des accès au disque lors de l'utilisation de données fréquemment demandées. Sous Linux, le cache de page (et historiquement le cache tampon) assure cette fonction de mise en cache.
Avec GFS2, chaque nœud possède son propre cache de pages qui peut contenir une partie des données sur disque. GFS2 utilise un mécanisme de verrouillage appelé glocks (prononcé gee-locks) pour maintenir l'intégrité du cache entre les nœuds. Le sous-système glock fournit une fonction de gestion du cache qui est mise en œuvre en utilisant distributed lock manager (DLM) comme couche de communication sous-jacente.
Les verrous assurent la protection du cache par inode, de sorte qu'il existe un verrou par inode utilisé pour contrôler la couche de cache. Si ce verrou est accordé en mode partagé (DLM lock mode : PR), les données sous ce verrou peuvent être mises en cache sur un ou plusieurs nœuds en même temps, de sorte que tous les nœuds peuvent avoir un accès local aux données.
Si le glock est accordé en mode exclusif (DLM lock mode : EX), seul un nœud unique peut mettre en cache les données sous ce glock. Ce mode est utilisé par toutes les opérations qui modifient les données (comme l'appel système write ).
Si un autre nœud demande un verrou qui ne peut être accordé immédiatement, le DLM envoie un message au(x) nœud(s) qui détient(nt) actuellement les verrous bloquant la nouvelle demande pour leur demander d'abandonner leurs verrous. L'abandon des verrous peut être un processus long (par rapport à la plupart des opérations du système de fichiers). L'abandon d'un verrou partagé ne nécessite que l'invalidation du cache, ce qui est relativement rapide et proportionnel à la quantité de données mises en cache.
L'abandon d'un bloc exclusif nécessite une vidange du journal et la réécriture de toutes les données modifiées sur le disque, suivies de l'invalidation conformément au bloc partagé.
La différence entre un système de fichiers à nœud unique et GFS2 réside donc dans le fait qu'un système de fichiers à nœud unique dispose d'un seul cache et que GFS2 dispose d'un cache séparé sur chaque nœud. Dans les deux cas, le temps de latence pour accéder aux données mises en cache est du même ordre de grandeur, mais le temps de latence pour accéder aux données non mises en cache est beaucoup plus important dans GFS2 si un autre nœud a précédemment mis en cache ces mêmes données.
Les opérations telles que read (buffered), stat, et readdir ne nécessitent qu'un sas partagé. Les opérations telles que write (buffered), mkdir, rmdir, et unlink nécessitent un sas exclusif. Les opérations de lecture/écriture d'E/S directes nécessitent un sas différé si aucune allocation n'a lieu, ou un sas exclusif si l'écriture nécessite une allocation (c'est-à-dire l'extension du fichier ou le remplissage de trous).
Il en découle deux considérations principales en matière de performances. Tout d'abord, les opérations en lecture seule se parallélisent très bien au sein d'un cluster, puisqu'elles peuvent être exécutées indépendamment sur chaque nœud. Deuxièmement, les opérations nécessitant un bloc exclusif peuvent réduire les performances si plusieurs nœuds se disputent l'accès au(x) même(s) inode(s). La prise en compte de l'ensemble de travail sur chaque nœud est donc un facteur important dans les performances du système de fichiers GFS2, par exemple lorsque vous effectuez une sauvegarde du système de fichiers, comme décrit dans Sauvegarde d'un système de fichiers GFS2.
En conséquence, nous recommandons l'utilisation de l'option de montage noatime ou nodiratime avec GFS2 dans la mesure du possible, avec une préférence pour noatime lorsque l'application le permet. Cela empêche les lectures de nécessiter des verrous exclusifs pour mettre à jour l'horodatage de atime.
Pour les utilisateurs soucieux de l'efficacité de l'ensemble de travail ou de la mise en cache, GFS2 fournit des outils qui permettent de surveiller les performances d'un système de fichiers GFS2 : Performance Co-Pilot et GFS2 tracepoints.
En raison de la manière dont la mise en cache de GFS2 est mise en œuvre, les meilleures performances sont obtenues lorsque l'une ou l'autre des situations suivantes se produit :
- Un inode est utilisé en lecture seule sur tous les nœuds.
- Un inode est écrit ou modifié à partir d'un seul nœud.
Notez que l'insertion et la suppression d'entrées d'un répertoire lors de la création et de la suppression de fichiers est considérée comme une écriture sur l'inode du répertoire.
Il est possible d'enfreindre cette règle à condition de le faire relativement rarement. Ignorer cette règle trop souvent se traduira par une grave pénalité en termes de performances.
Si vous mmap() un fichier sur GFS2 avec une correspondance lecture/écriture, mais que vous ne faites que lire à partir de ce fichier, cela ne compte que comme une lecture.
Si vous ne définissez pas le paramètre noatime mount , les lectures entraîneront également des écritures pour mettre à jour les horodatages des fichiers. Nous recommandons à tous les utilisateurs de GFS2 d'effectuer le montage avec noatime, à moins qu'ils n'aient besoin de atime.
