|
Global File System Ne doit pas être confondu avec Google File System.   Cet article ne cite pas suffisamment ses sources (). Si vous disposez d'ouvrages ou d'articles de référence ou si vous connaissez des sites web de qualité traitant du thème abordé ici, merci de compléter l'article en donnant les références utiles à sa vérifiabilité et en les liant à la section « Notes et références ».
En pratique : Quelles sources sont attendues ? Comment ajouter mes sources ?
 Pour les articles homonymes, voir GFS.
Global File System (GFS) (Système de fichiers global) est un système de fichiers partagé conçu pour une grappe d'ordinateurs Linux ou IRIX. GFS et GFS2 sont différents des systèmes de fichiers distribués comme AFS, Coda, ou InterMezzo parce qu'ils permettent à tous les nœuds un accès direct concurrent au même périphérique de stockage de type bloc. De plus, GFS et GFS2 peuvent également être utilisés comme un système de fichiers local. GFS ne possède pas de mode déconnecté, il n'y a pas de client ou de serveur. Tous les nœuds d'une grappe GFS sont égaux. L'utilisation de GFS dans une grappe d'ordinateurs nécessite un matériel qui permet l'accès aux données partagées, et un gestionnaire de verrous (lock manager) pour contrôler l'accès aux données. Le gestionnaire de verrou est un module séparé, par conséquent GFS et GFS2 peuvent utiliser un gestionnaire de verrous distribués (Distributed Lock Manager, DLM) pour les configurations en grappe et le gestionnaire de verrous "nolock" pour les systèmes de fichiers locaux. Les versions plus anciennes de GFS supportent également GULM, un gestionnaire de verrous fondé sur un serveur et qui implémente la redondance par basculement. GFS et GFS2 sont des logiciels libres, distribués sous licence GPL[1],[2]. HistoireGFS 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 et sortit GFS et beaucoup de pièces d'infrastructure de cluster sous la licence GPL fin . 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 :
MatérielGFS 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. Différences avec un système de fichiers localBien 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'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. JournalisationGFS 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 GFS2 supporte également le mode GFS2 ne supporte pas encore le mode 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. Compatibilité et méta-système de fichiers GFS2GFS2 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 :
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 ( 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. Notes et références
Voir aussiArticles connexesLiens externes
Bibliographie Cette section est vide, insuffisamment détaillée ou incomplète. Votre aide est la bienvenue ! Comment faire ? |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Portal di Ensiklopedia Dunia
