Global File System


Le Système de Fichiers Global, ou GFS, est un système de fichiers partagés en environnement cluster pour Linux.

GFS, existant seulement sous IRIXà l'origine, a été porté par Sistina Software après que SGI ait mis les sources de son système de fichiers dans le domaine public.
GFS implémente des fonctionnalités d'archivage (journaling) et de récupération des données perdues consécutivement à la défaillance d'un des membres du cluster.

Les membres d'un cluster GFS partagent physiquement le même espace de stockage, au travers de solutions FibreChannel, ou encore SCSI partagé, et même au travers de solutions purement logicielles.

Le système de fichiers créé sur cet espace commun paraît local à chaque membre du cluster, et GFS se charge de la synchronisation nécessaire lors de l'accès aux données.
GFS est totalement symétrique, c'est-à-dire que les membres du cluster sont tous égaux en tout point, ce qui élimine tout point de contention potentielle, et tout point de passage obligé.

GFS utilise des technique de cache en lecture et en écriture, tout en conservant intacte la sémantique Unix relative à l'accès et à la manipulation des systèmes de fichiers.

La version courante de GFS, à l'instant où ces lignes sont écrites, est la 4.1.1, et l'auteur vous propose maintenant de passer en revue l'installation et l'utilisation d'une configuration GFS sur une configuration.

Bien sûr, comme l'introduction le mentionne, il faut posséder pour une utilisation "normale" une configuration qui n'est pas la configuration que l'on possède habituellement chez soi (Fibre Channel) et les manipulations que nous allons entreprendre sont plus à envisager dans un cadre professionnel.

La problématique dans ce cadre n'est pas tant de mettre en uvre une solution FC: c'est même plutôt simple, on connecte et ça marche, à condition d'avoir choisi la bonne interface, c'est-à-dire une interface qui possède un driver opérationnel sous Linux, mais plutôt un problème de coût: on peut considérer que c'est inabordable pour le particulier moyen.

Néanmoins, la beauté de GFS est que la solution marche du plus humble PC, avec une seul disque IDE, jusqu'aux plus grandes configurations constituées de nombreuses machines et de solutions de stockage en réseau.
Tout le monde peut donc mettre en uvre l'environnement que nous vous proposons de découvrir, mais cet avertissement est juste pour attirer l'attention du lecteur sur l'orientation professionnelle de GFS.

GFS: comment ça marche?

Les système de fichiers traditionnels implémentent un espace de nommage persistant en définissant des fichiers spéciaux établissant une correspondance entre les blocs des disques physiques et les fichiers "utilisables", c'est-à-dire les fichiers ordinaires et les répertoires.
Ces systèmes de fichiers voient les périphériques comme des périphériques locaux, c'est-à-dire non partagés entre différents calculateurs. Il n'y a donc dans ce cas pas de besoins d'établir des règles d'arbitrage quant à l'accès aux ressources.
Les efforts sur ces environnements sont orientés vers la performance, en améliorant les capacités en termes de taille et de latence des caches, et en effectuant des agrégats au niveau des fichiers, de telle sorte que les temps d'accès aux données pour l'utilisateur soient les meilleurs possibles pour tout type d'opération.

Les nouvelles technologies réseau autorisent le partage de ressources de stockage par plusieurs calculateurs.
Les systèmes de fichiers autorisant des montages simultanés et multiples d'un même système de fichiers sur de multiples calculateurs sont appelés systèmes de fichiers à disques partagés, en contraste avec les systèmes de fichiers partagés conventionnels (comme par exemple les montages SMB/Samba ou NFS), où un serveur contrôle les périphériques et est le point focal de l'ensemble des opérations d'accès aux données.

Les avantages d'un système de fichiers à disques partagés par rapport aux autres déclinaisons de systèmes de fichiers sont multiples, et plus particulièrement:

·         La disponibilité du système de fichiers est améliorée par le fait qu'il n'y a pas de point de passage obligé (single point of failure) en ce qui concerne le calculateur. Si un ou plusieurs des calculateurs de la configuration se trouvent indisponibles, le système de fichiers et ses données restent accessibles à l'ensemble des calculateurs qui seront restés opérationnels, les disques et les données y résidant étant uniformément attachés et vus par l'absolue intégralité des calculateurs, et les données venant d'être manipulées par la ou les machines qui viennent de tomber restent accessibles et immédiatement "reprenables" par les calculateurs "survivants".
·         La répartition de charge (ou Load Balancing) se voit simplifiée par la facilité donnée aux clients d'accéder rapidement à toute partie de l'ensemble des données sur tout disque.
·         La mise en commun (Pooling) des ressources de stockage dans un seul et unique volume également disponible en tout point permet de simplifier la gestion de l'ensemble et réduit la complexité des tâches d'administration.
·         Les possibilités d'extension (Scalability) en termes de connectivité et de bande passante peuvent être réelles et simples, sans avoir à prendre en compte les limitations inhérentes à un système de fichiers basé sur un seul calculateur.

Implémentation de GFS

Il existe deux catégories de systèmes de fichiers à disques partagés:
·         Asymétrique, où les machines partagent les disques contenant des données et pas les métadonnées, ces dernières étant contrôlées par un serveur central qui assure également les fonctions de synchronisation entre les clients. Chaque client effectue donc des requêtes vers le serveur de méta-données, puis accède ensuite aux données réparties sur l'ensemble des disques partagés.

·         Symétrique, où les machines partagent des disques contenant données et métadonnées, ces mêmes métadonnées étant gérées par chaque machine accédant directement aux données. La synchronisation pour l'accès aux données entre les machines est alors assurée par un système de verrouillage (lock manager) distribué. Nouveau, brillant, innovant, moderne? Certes: DIGITAL VAXCluster/VMS + MSCP server, 1984…;-)

Utilisé également par Frangipani (voir aussi Petal), c'est cette dernière catégorie de système de fichiers qu'implémente GFS. En outre, GFS :
·         est sous GPL ;
·         utilise 64 bits "à plat" pour les fichiers et le système de fichiers ;
·         est journalisé ;
·         possède des métadonnées indépendantes des plates-formes ;
·         fonctionne inter plates-formes ;
·         implémente des inodes dynamiques ;
·         est segmenté en trois composants:
o        le network storage pool driver (Linux Logical Volume Manager) ;
o        le système de fichiers ;
o        le système de synchronisation des accès (lock manager).

Ces caractéristique font donc de GFS une solution de choix pour les serveurs de données en général, et aussi pour les clusters de calcul Beowulf.

Mais surtout, à l'égal de seulement certains très grands Unix propriétaires, à l'avenir hélas de plus en plus incertain (minute de silence à la mémoire de l'infortuné Alpha), GFS permet de créer des clusters à racine partagée, ce qui offre des possibilités énormes en termes d'administration. Bien que cette fonctionnalité ne soit pas encore finalisée (à ne pas mettre en production), les progrès sont rapides et l'avancement à surveiller de près.


Les composants du GFS

·         Le pool driver est un pilote de volumes logiques pour les éléments de stockage attachés au travers d'un réseau. Il permet de combiner plusieurs disques en un seul et unique espace de stockage. Il prend en charge les changements d'identifiant des disques causés par les modifications réseau. Un espace de stockage peu être segmenté en sous-espaces.
·         Le système de fichiers est un système de fichiers local, hautes performances, avec un système de synchronisation inter-calculateurs. En cas de démontage du système de synchronisation, GFS forme alors un système de fichiers 100% local totalement opérationnel.
·         Les inodes dynamiques permettent de ne pas avoir de tables pré-allouées. Chaque inode est un bloc du système de fichiers et il est donc possible de créer autant d'inodes qu'il y a de blocs disponibles. Il est possible de stocker de petits volumes à l'intérieur même de l'espace consommé par l'inode, tandis que les répertoires de taille plus importante sont manipulés par une technique nommée "extensible hashing", offrant de meilleurs temps d'accès que les algorithmes en B-tree, mais plus consommatrice d'espace.
·         La structure intégralement 64 bits "à plat" du système de fichiers offre des arbres d'accès aux métadonées d'égale hauteur mais qui savent s'adapter à la taille des fichiers, et donne la possibilité de créer des espace de stockage quasi illimités.
·         L'indépendance des métadonnées à l'égard des plates-formes (ces mêmes métadonnées sont codées dans un format universel). La problématique de gestion des formats de données propres aux différentes architectures (little ou big endian) est gérée.
·         Le buffer cache de Linux est écrit en supposant qu'à tout instant une seule machine est en train de modifier les données, et les routines GFS effectuent les vérifications sur l'ensemble des caches lecture et écriture des machines, en faisant les invalidations si nécessaire.
·         Le niveau d'abstraction d'architecture est effectué à deux niveaux:
o        VFS to GFS, par un code commun, compilé pour chaque plate forme ;
o        GFS to buffer cache, par des bibliothèques.
·         La synchronisation est effectuée à de multiples niveaux:
o        Le G-lock qui est implémenté au niveau du système de fichiers, et qui gère la synchronisation des caches. Le G-lock est ré-entrant et gère les cas de verrouillage mutuellement exclusif (deadlocks) en utilisant un espace libre (sparse area) de gestion des verrous. Ces verrous peuvent avoir trois états distincts:
§         Non acquis (Not Held), c'est-à-dire que la machine ne possède pas le lock et qu'il n'y a pas de données incohérentes dans les caches.
§         Acquis (Held), la machine possède le lock, mais ce dernier peut être libéré étant donné qu'aucun process ne l'utilise et qu'il n'y a pas de données incohérentes dans les caches.
§         Verrouillé (Locked), la machine possède le lock, et soit un process référence le lock, ou soit il existe une incohérence de données. Ce lock ne pourra être relâché qu'après passage en état "Acquis" par cette même machine.
o        Les modules de synchronisation qui offrent des mécanismes d'intercommunication interchangeables entre clients, destinés à assurer l'échange des verrous (callbacks) et à créer un espace virtuel d'échange et d'enregistrement des membres du cluster, par exemple sur le scénario suivant:
§         Le client 1 tient le verrou (locked).
§         Le client 2 cherche à l'acquérir.
§         Le message de refus contient l'identifiant du détenteur actuel du verrou (client 1).
§         Le client 2 demande alors au client 1 de relâcher le verrou.
§         Le client 1 termine ses tâches, synchronise ses données et relâche alors le verrou (Held).
§         Le client 2 peut alors acquérir le verrou (Held).
o        Les protocoles de locking implémentés à ce jour sont soit nolock, c'est-à-dire des verrous virtuels pour les systèmes de fichiers locaux, ou memexp. Dans le futur, le protocole DLM sera le protocole de verrouillage implémenté.
·         Mécanisme de régénération (recovery)
o        Bien qu'implémenté sous GFS, un FSCK (filesystem check) est difficilement acceptable dans l'environnement typique d'une solution GFS, en raison de sa lenteur, proportionnelle à la taille du système de fichiers à régénérer, et à cause de la nécessité de mettre le système de fichiers hors ligne pendant toute la durée de l'opération.
o        La journalisation apporte une solution à ces problèmes, en offrant d'une part un temps de régénération proportionnel à l'activité précédemment existante sur le système de fichiers et d'autre part en autorisant la régénération en ligne.
·         Comment implémenter efficacement un mécanisme de régénération?
o        Le partage d'un même journal par de multiples clients est complexe, donc long et inefficace.
o        La solution est donc que chaque client possède son propre journal, protégé par un lock acquis lors du montage du système de fichiers, et relâché au démontage, quel qu'il soit, c'est-à-dire même en cas de crash. Chacun de ces journaux aura intérêt à se trouver sur un disque différent afin de garantir un parallélisme efficace lors de la régénération, et devra bien sûr être disponible pour l'ensemble des membres du cluster.
o        Les entrées dans le journal sont constituées de métadonnées modifiées lors des opérations, et chaque entrée possède un ou plusieurs G-locks associés.
o        La journalisation est asynchrone, ce qui entraîne l'agrégation de multiples entrées dans le journal en mémoire, et ces entrées sont écrites sur les disques (commit) de façon asynchrone. Les buffers contenant les métadonnées pour une entrée de journal sont verrouillés en mémoire (pas de purge possible) jusqu'à ce que l'entrée du journal soit écrite (commit). Alors, et seulement alors, les entrées en mémoire peuvent être purgées.
o        Les transactions n'ayant pas de G-lock ou d'inodes en commun sont indépendantes et peuvent être écrites sur les disques dans un ordre quelconque, tandis que les changements de nom des répertoires sont rassemblés sous un verrou commun et dédié. Enfin, toute transaction interdépendante d'autres entraîne systématiquement toutes ses "partenaires" vers l'écriture.
o        La régénération peut être initialisée sous deux conditions distinctes:
§         L'expiration d'un lock afin de ne pas permettre à un client de lire des données laissées par un autre client dans un état potentiellement inconsistant. Dans le futur, GFS devant fonctionner avec DLM, cette fonctionnalité ne sera pas implémentée et laissée au module de verrouillage.
§         Le lancement explicite d'une opération de régénération, à l'occasion d'une opération de montage afin de vérifier le journal de la machine arrivante, ou alors lors de la détection de la disparition d'une machine par le gestionnaire des verrous. Dans tous les cas, l'identifiant du journal de la machine disparue est passé au thread chargé de gérer la régénération, qui commence alors en invalidant de façon sûre la machine disparue, puis en acquérant le verrou posé sur le journal en question.
§         Mais pourquoi "achever le cheval"? Tout simplement parce qu'un client peut apparaître comme disparu au gestionnaire des verrous, en manquant par exemple un message de synchronisation, et être toujours présent, zombie écrivant tranquillement ses données que d'autres tentent de régénérer … «You fool, Carter is dead…»
·         La machine A se fige (hang).
·         Le lock tenu par la machine A expire.
·         La machine B décide de déclarer A indisponible, libère le lock et entreprend de lancer la régénération des données.
·         La machine A sort de son "hang" et recommence son écriture, "pensant" qu'elle possède toujours le lock.
·         "Bon, ben, quand c'est qui qu'a fait le dernier backup et où qu'y l'a mis ?" lourd silence, ou rire hystérique, au choix….
§         Mais tout ceci n'est pas arrivé, le bon Dr Van Helsing (machine B) ayant définitivement réglé le sort du vilain non-mort (machine A) au moyen d'une mise hors tension ou d'un reset réseau, la régénération peut commencer:
·         Acquisition du lock de transaction en mode exclusif, afin de garantir la non modification des métadonnées.
·         Localiser les zones actives du journal.
·         Pour chaque entrée valide de métadonnées dans le log, remplacer l'entrée. Chaque métadonnée possède un identifiant codé sur 64 bits, incrémenté à chaque écriture dans le journal, ce qui permet de détecter si une métadonnée a été modifiée depuis son dernier enregistrement dans le journal, et la modification n'est faite que si l'identifiant possède une valeur supérieure à la valeur enregistrée dans le journal.
·         Marquer le journal "régénéré", réinitialiser les verrous expirés pour le client disparu et relâcher le verrou posé sur le journal.

Comment mettre en uvre une solution GFS?

Maintenant que les principes de fonctionnement interne de GFS ont été exposés, nous allons voir comment il est possible de mettre en place GFS dans un environnement.

Il y a de multiples façons de mettre en place une telle solution, mais avec au moins les éléments suivants:
·         Une ou plusieurs machines (Alpha ou Intel) sous Linux avec soit un kernel 2.2.19 ou 2.4.5. D'autres versions de kernel peuvent fonctionner avec GFS, mais sans aucune garantie.
·         Une glibc 2.1.2 pour le support 64 bits.
·         Un système de stockage partagé (SCSI parallèle ou Fibre Channel), ou à défaut un serveur de blocs en réseau (gnbd, nbd).
·         Une implémentation DMEP sur les systèmes de stockage, ou serveur de verrous sous IP memexpd. Il existe de façon native dans les sources de GFS une implémentation logicielle de DMEP.


Voici quelques configurations possibles:
·         La solution "idéale", avec des périphériques de stockage partagés. Hélas, il vous faudra attendre avant d'espérer pouvoir implémenter cette solution, en raison de l'absence d'équipements FibreChannel implémentant des fonctionnalités DMEP.
·         GFS sur un cluster de machines avec du stockage FibreChannel et un serveur DMEP: une bonne solution, cependant impactée par la perte des capacités de résilience de GFS en raison de la mise à disposition par un seul chemin réseau d'un serveur memexpd. Pour mettre en uvre cette solution, utilisant une alimentation contrôlée par réseau et des agents tueurs installés sur chaque machine, avec bien évidemment les kernels patchés GFS et les outils associés sur chaque n ud, il vous faudra comme hardware:

o        1 serveur de verrous en réseau memexpd.
o        4 serveurs de données avec des contrôleurs FibreChannel.
o        1 baie RAID FibreChannel, avec une toute petite partition dédiée.
o        1 Hub FibreChannel.
o        1 alimentation pilotée en réseau (associée aux agents tueurs) sur laquelle seront connectés les quatre serveurs de données.

Pour les n uds serveurs de données, on supposera le driver FibreChannel déjà chargé, et les partitions existantes sur la baie RAID visibles. On chargera ensuite sur chacun de ces mêmes serveurs les modules memexp et gfs. Il nous restera à créer deux fichiers pool, l'un pour le système de fichiers et l'autre pour la configuration GFS.

Les pools seront effectivement créés à partir des descriptions contenues dans ces deux fichiers, et ensuite chargés sur chaque membre du cluster. L'on pourra alors créer les systèmes de fichiers, et puis créer le CIDEV (Cluster Information DEVice), sur le pool défini précédemment dans la petite partition réservée.

L'ensemble de la configuration GFS sera stockée dans le CIDEV. Les agents tueurs seront alors démarrés sur chaque n ud serveur de données, et le process memexpd sera lancé sur la machine dédiée à cet effet.

C'est fini, il n'y a plus qu'à monter sur chaque n ud serveur de données les systèmes de fichiers nouvellement crées sur les points de montage de votre choix.

·         La meilleure solution avec un équipement de stockage partageable et implémentant DMEP en hardware.

·         Comment obtenir une configuration GFS opérationnelle, mais au détriment de la performance. C'est une configuration de test, ou la configuration "du pauvre", puisqu'il suffit d'un réseau IP.

Nous allons cependant aussi nous attarder un peu sur cette configuration, car c'est celle que le plus grand nombre de lecteurs sera en mesure de tester.

Une machine sera serveur, et les deux autres seront clients.

La machine serveur supportera l'ensemble des fonctions cluster, à savoir le serveur de verrous memexpd et le gestionnaire de communication gnbd. Cette machine possédera tout l'espace de stockage, avec une petite partition dédiée aux données de configuration et d'état du cluster (CIDEV) et tout le reste exporté vers les clients. Les machines client monteront le système de fichiers GFS.

Avant de commencer les étapes qui vont suivre, il est bien évident que la mise en uvre de GFS sur chaque machine aura dû être achevée avec succès.

Les démons serveur et client seront démarrés sur les machines respectives, et automatiquement, les clients acquerront les GNDB exportés. Les exports devront donc être vus dès le lancement des clients (avec bien sûr le serveur préalablement lancé).

Les GNDB étant identiques sur l'ensemble des machines, il n'est dans ce cas pas nécessaire de créer de pool, dont le but premier est de fournir une unicité de nommage, indispensable pour les disques SCSI partagés. De plus, cet exemple suppose un seul disque, et à nouveau le pool n'est pas requis, les capacités d'agrégation ne s'avérant pas applicables dans ce cas.

·         La configuration la plus simple, ou GFS se résume à un système de fichiers journalisé fiable.


Intallation de GFS

Il faut se procurer les packages ou les sources de GFS, et installer ou construire cet environnement. Il existe des packages pour les distributions RedHat et Debian, qui permettent d'effectuer l'installation sans douleur, c'est-à-dire sans avoir à patcher le kernel manuellement.

La construction de GFS à partir des sources implique de récupérer la bonne version de kernel à partir de kernel.org, d'appliquer les patches, et de reconstruire ensuite son kernel, puis de lancer le make pour construire les quelques outils nécessaires autour de GFS.

Conclusion

Il reste de nombreuses choses à découvrir dans GFS, en particulier autour des outils gravitant autour des structures internes du cluster, des possibilités de redimensionnement dynamique des pools, et de la mise en place de solutions de tolérance aux pannes.
Mais le but de cet article est de faire connaître au plus grand nombre qu'il existe, parmi d'autres solutions de stockage cluster (PVFS en particulier), la possibilité pour tous de mettre en uvre de tels environnements, et de donner le goût et l'envie de les essayer et, pourquoi pas, les garder.


Accréditations

Les illustrations ont été chargées à partir du site de développement de GFS (voir Bookmarks ci-dessous), et cet article est basé sur l'excellent GFS-Howto ainsi que les présentations au format PDF, disponibles à la même source.

Liens

http://www2.linuxjournal.com/cgi-bin/frames.pl/articles/linux_review/0035.html
http://www.sistina.com/gfs/



Christophe Le Cannellier
Saint Paul Research Labs
sprl@wanadoo.fr

<include sprl_logo.gif>