Global File System

GFS a été développé à l'origine comme une partie d'une thèse à l'université du Minnesota en 1997. Il a été écrit à l'origine pour le système d'exploitation IRIX de Silicon Graphics, mais il a été porté sur Linux en 1998 car le code open source (« code source libre » en français) fournissait un meilleur environnement de développement. À la fin 1999/début 2000, il a été repris par la société Sistina Software, un temps sous la forme d'un projet open source. En 2001, Sistina a choisi de faire de GFS un produit commercial, abandonnant par la même occasion la gestion en open source.

Des développeurs tirèrent OpenGFS de la dernière version publique de GFS et l'améliorèrent pour inclure des mises à jour lui permettant de fonctionner avec OpenDLM. Mais OpenGFS et OpenDLM disparurent lorsque Red Hat acheta Sistina en décembre 2003 et sortit GFS et beaucoup de pièces d'infrastructure de cluster sous la licence GPL fin juin 2004.

Par la suite, Red Hat a financé un développement tourné vers la correction de bug et la stabilisation. Une version ultérieure, GFS2[3] est dérivée de GFS puis est incluse avec son gestionnaire de verrous distribués (le même que celui de GFS) dans Linux 2.6.19. GFS2 a été inclus dans la Red Hat Enterprise Linux 5.2 comme un simple module du noyau, pour évaluation. Avec la version 5.3, GFS2 fait maintenant partie du paquetage noyau.

En 2007, GFS fait partie des distributions Linux Fedora et CentOS. Les utilisateurs peuvent acheter une assistance commerciale pour obtenir un support total de GFS sur Red Hat Enterprise Linux. Depuis la Red Hat Enterprise Linux version 5, le support GFS est inclus dans la Red Hat Enterprise Linux sans coût supplémentaire.

La liste suivante résume quelques numéros de versions avec les caractéristiques majeures introduites :

• v1.0 (1996) seulement sur IRIX de Silicon Graphics ;
• v3.0 portage sur Linux ;
• v4 Journalisation ;
• v5 Gestionnaire de verrou redondant ;
• v6.1 (2005) DLM ;
• Linux 2.6.19 - GFS2 et DLM introduits dans le noyau Linux
• Red Hat Enterprise Linux 5.3 - GFS2 est totalement supporté pour la première fois

GFS et GFS2 ont été conçus pour fonctionner dans des environnements de type SAN (ou semblables). Bien qu'il soit possible de les utiliser comme des systèmes de fichiers pour un nœud, un SAN est nécessaire pour en obtenir toutes les fonctionnalités. Ceci peut prendre la forme d'un iSCSI, de la Fibre Channel, AoE, ou n'importe quel périphérique qui peut être présenté sous Linux comme un périphérique de type bloc partagé par un certain nombre de nœuds.

Le DLM nécessite également un réseau qui supporte IP pour communiquer. Ce peut être simplement Ethernet, mais à nouveau, il y a beaucoup d'autres solutions. Selon le choix de SAN, ce réseau peut être intégré au SAN ou non, bien qu'il soit plus normal d'avoir des réseaux séparés pour le DLM et le stockage.

La dernière nécessité est celle d'un matériel pour isoler (fencing) les éléments défaillants. C'est une exigence de l'infrastructure de grappe plus que de GFS/GFS2 proprement dit, mais c'est une exigence pour toutes les grappes. Les options usuelles incluent des interrupteurs et des télécommandes (par ex. DRAC, IPMI, ou ILO). Le mécanisme d'isolation est utilisée pour s'assurer qu'un nœud que la grappe croit hors-service ne puisse pas se remettre en marche pendant qu'un autre nœud est en train de récupérer son journal. Le mécanisme d'isolation peut également (de manière optionnelle) redémarrer le nœud hors-service une fois que la récupération est terminée.

Bien que le but de GFS/GFS2 est d'être aussi similaire que possible à un système de fichiers local, il y a de nombreuses différences dont il faut être conscient. Certaines sont dues aux interfaces existantes des systèmes de fichiers, qui n'autorisent pas à passer des informations sur la grappe, et d'autres sont dues à la difficulté qu'il y a à implémenter efficacement les systèmes de fichier partagés par une grappe. Voici quelques-unes de ces différences :

• L'appel système flock() de GFS/GFS2 n'est pas interruptible par un signal ;
• La commande F_GETLK de l'appel système fcntl() retourne, s'il est impossible de poser un verrou, le PID de n'importe quel processus ayant un verrou bloquant sur le fichier. Puisqu'on est sur une architecture en grappe, ce PID peut être celui d'un processus sur n'importe lequel des nœuds sur lequel le système de fichiers est monté. Le but de cette interface est de permettre d'envoyer un signal au processus bloquant, et cela n'est évidemment plus possible ;
• Les baux ne sont pas supportés avec le module de verrou (pour grappe) lock_dlm, mais ils le sont quand ils sont utilisés sur un système de fichiers local ;
• FIEMAP est supporté uniquement par GFS2 ;
• inotify fonctionne sur la base du "même nœud", mais son utilisation n'est pas recommandée (mais pourrait être supportée à l'avenir)
• L'appel système splice() est supporté uniquement par GFS2.

L'autre différence principale, celle qui est partagée par tous les systèmes de fichiers semblables pour grappe, est que le mécanisme de contrôle de cache, connu sous le nom de glocks (prononcer : Ji-locks) pour GFS/GFS2, a un effet sur l'ensemble de la grappe. Chaque Inode du système de fichiers se voit associer deux glocks. L'un (appelé iopen glock) est seulement utilisé pour garder la trace de quel processus a ouvert l'inode. L'autre, le glock de l'inode, contrôle le cache associé à cet inode. Un glock a quatre états, UN (unlocked, non verrouillé), SH (shared, partagé - un verrou en lecture), DF (deferred, différé - un verrou en lecture incompatible avec SH) et EX (exclusive, exclusif). Chacun de ces quatre modes correspond directement à un mode de verrouillage du DLM.

Pour garantir la cohérence des données et métadonnées dans la grappe, certaines contraintes sont mises en place. Quand le glock est en mode EX, l'inode est autorisé à mettre des données en cache, mais aussi des métadonnées (qui peuvent être « sales », c'est-à-dire en attente d'être réécrites sur le système de fichiers). En mode SH, l'inode est autorisé à mettre des données en cache, mais aussi des métadonnées, qui ne doivent pas être sales. En mode DF, l'inode n'est autorisé qu'à mettre des métadonnées en cache, et à nouveau elles ne doivent pas être sales. Le mode DF n'est utilisé que pour les E/S directes (c'est-à-dire qui contournent le cache du système d'exploitation en utilisant un cache spécifique). En mode UN, l'inode ne doit pas mettre de métadonnées en cache.

Le verrou EX est utilisé pour que les opérations qui modifient les données ou métadonnées d'un inode n'interfèrent pas entre elles. Cela signifie que certaines opérations, comme la création ou suppression de fichiers du "même" répertoire ou écrire sur le "même" fichier devraient, en général, être limitées à un nœud dans la grappe. Évidemment, réaliser ces opérations depuis des nœuds différents va fonctionner comme on l'espère, mais comme il est nécessaire de vider les caches fréquemment, cela ne sera pas très efficient.

La question la plus souvent posée sur la performance de GFS/GFS2 est : pourquoi la performance peut-elle être faible pour les serveurs de mail. Il devrait être relativement évident, d'après ce qui précède, que la solution consiste à diviser le spool de mail en répertoires séparés et d'essayer de faire (autant que possible) que chaque nœud lise et écrive dans un ensemble de répertoires privés.

GFS et GFS2 sont tous les deux des systèmes de fichiers journalisés et GFS2 supporte un ensemble de modes de journalisation similaire à celui d'ext3. Dans le mode data=writeback, seules les métadonnées sont journalisées. C'est le seul mode supporté par GFS. Il est toutefois possible d'activer la journalisation sur les données individuelles d'un fichier, mais seulement quand il a pour taille zéro. Les fichiers journalisés dans GFS souffrent d'un certain nombre de restrictions, comme l'absence de support pour les appels système mmap ou sendfile. Ils utilisent également un format de disque différent des fichiers réguliers. Il existe également un attribut « inherit-journal » qui, lorsqu'il est placé sur un répertoire, met à tous les fichiers (resp. sous-répertoires) créés dans ce répertoire le drapeau « journal » (resp. « inherit-journal »). Cela peut être utilisé à la place de l'option de montage data=journal, qu'ext3 supporte (mais pas GFS/GFS2).

GFS2 supporte également le mode data=ordered, qui est similaire à data=writeback, excepté le fait que les données sales sont synchronisées avant la fin de chaque vidage du journal. Cela assure que les blocs qui ont été ajoutés à un inode auront leur contenu écrit sur le disque avant que les métadonnées soient mises à jour pour enregistrer la nouvelle taille et ainsi éviter l'apparition de blocs non-initialisés dans un fichier, si un node est hors-service. Le mode de journalisation par défaut est data=ordered, pour correspondre au mode par défaut d'ext3.

GFS2 ne supporte pas encore le mode data=journal, mais il utilise (à la différence de GFS) le même format de disque pour les fichiers réguliers et les fichiers journalisés, et il supporte les mêmes attributs "journal" et "inherit-journal". GFS2 relâche également les restrictions sur le moment où un fichier peut voir changer son attribut "journal" : n'importe quand, tant que le fichier n'est pas ouvert (encore une fois, comme ext3).

Pour des raisons de performance, chaque nœud en GFS et GFS2 a son propre journal. Dans GFS, les journaux sont des domaines de disque (disk extents), dans GF2 ce sont juste des fichiers réguliers. Le nombre de nœuds qui peuvent monter le système de fichiers simultanément est limité par le nombre de journaux disponibles.

GFS2 a été conçu pour que l'évolution depuis GFS soit une procédure simple. Pour cela, la plupart des structures de disque sont restées les mêmes que sur GFS, y compris l'ordre grand-boutien des octets. Il y a cependant quelques différences :

• GFS2 possède un "méta système de fichiers" à travers lequel les systèmes de fichiers sont accessibles ;
• GFS2 utilise le même format pour les fichiers journalisés et réguliers ;
• GFS2 utilise les fichiers réguliers (du système) pour les journaux, alors que GFS utilise des domaines (extents) ;
• GFS2 à quelques autres systèmes de fichiers "per_node" ;
• La structure des inode est (très légèrement) différente ;
• La structure des blocs d'indirection est légèrement différente.

Les systèmes de journalisation de GFS et GFS2 ne sont pas compatibles l'un avec l'autre. L'évolution est possible en utilisant un outil (gfs2_convert) qui est lancé sur les systèmes de fichiers (à froid) pour mettre à jour les métadonnées. Quelques blocs sont mis de côté dans les journaux de GFS pour créer des fichiers per_node (très petits) nécessaires à GFS2 durant le process de mise à jour. La plupart des données reste en place.

Le "méta système de fichiers" de GFS2 n'est pas un système de fichiers de plein droit, mais une racine alternative du système de fichiers principal. Cependant, il se comporte comme un système de fichiers "normal", avec pour contenu les différents fichiers système utilisés par GFS2, et normalement les utilisateurs n'ont aucun besoin d'y jeter ne serait-ce qu'un œil. Les utilitaires de GFS2 montent et démontent le méta système de fichiers à la demande, en coulisses.

• (en) Cet article est partiellement ou en totalité issu de l’article de Wikipédia en anglais intitulé « Global File System » (voir la liste des auteurs).