Les systèmes de fichiers - Direction technique Eau, mer et fleuves
Transcription
Les systèmes de fichiers - Direction technique Eau, mer et fleuves
Les systèmes de fichiers Contexte La première version du cluster est constituée d'un noeud maître possédant deux disques durs de 120 Go chacun et de dix noeuds de calcul avec un disque dur de 80 Go. Le système d'exploitation installé sur les noeuds de calcul occupe très peu de place en comparaison de celle disponible, mais des disques durs de plus faible capacité n'étaient plus disponibles au moment de l'achat des unités centrales. Pour être plus précis, le système installé sur les noeuds de calcul occupe moins d'un gigaoctet. Il faut rajouter les trois partitions de swap (2Go chacune) et la place pour une marge confortable en terme de place. Ce qui fait que l'on dispose de plus de 62 Go par noeud, soit un total de 620 Go qui reste inutilisé. En raison de la dispersion de cette ressource sur plusieurs machines indépendantes (mais reliées par un réseau haut débit), sa mise à la disposition pour l'utilisateur (pour un but qui n'est pas encore défini) n'est pas chose facile. Surtout si l'on souhaite, comme c'est notre cas, que cet accès soit le plus transparent possible pour lui. Le but de cette page est de voir les moyens existant à l'heure actuelle répondant à cette problématique. Montage réseau par NFS Une première solution est d'installer un serveur NFS sur chaque noeud et, à partir du noeud maître (le seul qui est normalement accessible par les utilisateurs), monter chacun des partages mis à la disposition par les différents noeuds. Cette solution présente l'avantage d'utiliser NFS, protocole de partage de fichier très largement répandu, dont la mise en place est aisée et d'un emploi relativement simple. Mais ses désavantages sont nombreux. La plupart est due au système de montage des partages réseaux dans l'arborescence du client. Chaque partage doit avoir son propre répertoire. Ce qui, dans notre cas de figure, correspond à avoir un répertoire distinct par noeud du cluster. Ce qui a comme conséquence : Une répartition inefficace des données sur l'ensemble des disques : c'est à la charge de l'utilisateur (ou de l'administrateur) de choisir le répertoire, et donc la machine, où mettre les données. Ce qui entraîne un déséquilibre de la charge. Comme les répertoires sont indépendants, il y a autant d'espace de nom et d'espace de stockage que de répertoires. C'est à dire qu'il n'y a pas de gestion d'ensemble de la répartition des données et des identifiants des fichiers (qui peuvent être leur nom, par exemple). La recherche des données par l'utilisateur est plus complexe. En effet, sauf si on met en place une politique de classement rigoureuse et respectée par tous, l'utilisateur, a priori, ne sait pas où se trouve la donnée qu'il recherche. L'ajout d'un disque supplémentaire à ce système, qui revient à ajouter un nouveau répertoire, pose également des problèmes en terme d'administration. A chaque ajout il faut redéfinir la politique de classement, déplacer les données en conséquence et en informer les utilisateurs. Les systèmes de fichiers distribués Présentation générale Le but recherché par l'ensemble des systèmes de fichiers distribués est de permettre l'agrégation d'espaces de stockage situés sur des machines différentes de façon la plus transparente possible pour l'utilisateur. Autrement dit, l'accès aux fichiers doit se faire de même manière que l'accès à un fichier, les commandes standards (ls, cp, rm, mv, ...) doivent avoir le même comportement. Cela suppose que le système puisse connaître l'emplacement physique des données, c'est à dire sur quels serveurs le fichier se trouve. Un fichier peut être stocké sur plusieurs serveurs en même temps si il Conception d'un système à haute performance – Les systèmes de fichiers 1/4 Copyright © CETMEF 2004 y a du stripping (le fichier est découpé en morceaux qui sont placés sur différents serveurs) ou de la redondance. C'est pourquoi, dans tous les systèmes rencontrés il y a un serveur gérant ce que l'on appelle les métadonnées décrivant chaque fichier. Dans ces métadonnées, on trouve le nom, l'emplacement dans l'arborescence, l'emplacement physique, le propriétaire, les droits, les dates d'accès et de dernière modification ainsi que toutes les données internes nécessaires au bon fonctionnement du système de fichier. Une instance de ce serveur est nécessaire par groupe de serveur faisant partie de la même unité de stockage. Ces données sont inscrites sur l'une des partitions de la machine hébergeant le serveur dans un format propre au système. Lors de l'accès à un fichier, une fois que le système connaît le serveur à interroger pour accéder au contenu grâce aux métadonnées, il faut qu'il envoie une requête en direction de ce serveur. La requête arrive alors sur un autre type de serveur qui est responsable de la gestion des fichiers locaux partagés. C'est ce serveur qui écrit ou lit physiquement les données sur le support de stockage. La grande majorité des systèmes de fichiers sont sur ce modèle, le serveur de métadonnées pouvant être découpé en plusieurs serveurs distincts selon la complexité du système. Les difficultés dues à la répartition des données L'une des difficultés principales que doivent résoudre au mieux les systèmes de fichiers est le temps d'accès aux fichiers et les performances de lectures/écritures. Les données ne sont plus directement accessibles sur l'un des disques durs locaux, mais il faut passer par tout un mécanisme de recherche sur un réseau qui présente des performances en terme de débit et de latence beaucoup plus faible que pour un disque dur local et le cache mémoire associé. Afin de palier à cela, certains systèmes mettent en place des systèmes de cache, où les données lues et écrites sont tout d'abord stockées sur l'un des disques du client. Ce qui rend plus rapide les accès ultérieurs. A partir du moment où plusieurs clients peuvent modifier un même fichier en même temps, se pose le problème de la cohérence des données. En effet, sans mécanisme de protection, c'est la modification apportée par le dernier client à sauvegarder ses données qui sera pris en compte. Cela n'est bien sur pas souhaitable. Pour cela, les différents systèmes de fichiers apportent des solutions qui dépendent des particularités de chacun. Mais dans la plupart des cas, c'est un système de verrou qui est mis en place. Ce système peut être plus ou moins complexe, surtout si un système de cache local à chaque client est implémenté. OpenAFS AFS est un système de fichiers distribués dont le projet a débuté à l'université Carnegie Mellon et est supporté par Transpac Corporation (maintenant "IBM Pittsburgh Labs"). IBM a fait une copie des sources et les a rendues disponibles. Cette copie s'appelle OpenAFS. Le site web du projet se trouve à l'adresse http://www.openafs.org. Le stockage des données grâce à OpenAFS repose sur les notions de Cells et de Volumes. Les Cells sont des ensembles de serveurs regroupés en unités indépendantes. Les différentes cells peuvent se trouver sur le même réseau physique mais être administrées de manières différentes. Un client ne peut être rattaché qu'à une cell à un instant donné et il verra l'ensemble des fichiers qui sont partagés au sein de cet cell. Le volume est l'unité de base du stockage. C'est une unité de stockage qui contient un ensemble de fichiers ayant un rapport entre eux et qui les garde ensemble sur une même partition. Les volumes peuvent varier en taille mais, par définition, ont une taille inférieure à celle d'une partition. Dans une arborescence de fichiers d'OpenAFS, un volume peut se voir comme un point de montage d'une partition. Par exemple, le répertoire "HOME" d'un utilisateur UNIX peut être vu comme un volume. OpenAFS permet la réplication des données sur les différents serveurs, mais cette réplication se fait au niveau des volumes. Un volume peut être stocké sur plusieurs serveurs en même temps, une copie étant Conception d'un système à haute performance – Les systèmes de fichiers 2/4 Copyright © CETMEF 2004 en accès complet (lecture/écriture), les autres étant accessibles seulement en lecture et mis à jours automatiquement en cas de modification du volume en accès complet. Il n'est pas possible faire de la réplication fichier par fichier. C'est un système qui est résistant aux pannes, d'une part grâce au système de réplication et au fait qu'en l'absence de l'un des serveurs (pour toutes les raisons possibles : panne de réseaux, panne matérielle, ...) le système dans son ensemble continue à fonctionner, seules les données contenues sur les serveurs défaillants sont inaccessibles. Afin d'augmenter les performances du système, OpenAFS propose un mécanisme de mise en cache et de vérification de sa cohérence pour la lecture et l'écriture. Ce cache est soit situé dans la mémoire centrale du client soit sur un disque dur. La sécurité des accès aux fichiers repose sur une authentification de l'utilisateur et des ACL ("Access Control List"). Les ACL permettent un réglage plus fin que l'habituelle gestion des droits UNIX (propriétaire, groupe, tout le monde). Ces ACL peuvent être appliqués sur les fichiers ou les répertoires. L'architecture logiciel d'OpenAFS est complexe. Chaque serveur à un rôle bien précis, et comme OpenAFS offre beaucoup de possibilités, le nombre de serveurs à mettre en place est important. Voici la liste de ces serveurs : • • • • • • • • • File Server : gestion des entrés/sorties sur les fichiers Basic OverSeer Server (BOS Server) : vérification de la bonne marche des autres serveurs (lancement, terminaison, ...) Authentification Server : gestion de l'authentification de l'utilisateur Protection Server : gestion des ACL Volume Server : gestion des volumes (création, suppression, déplacement, ...) Volume Location Server : permet de retrouver sur quel serveur est situé un volume Update server : maintient à jour la version des serveurs Backup server : permet la sauvegarde complète du système de fichier Cache Manager : serveur spécifique au client, il maintient à jour le cache du client en fonction des requêtes de ce dernier Chaque serveur à sa propre configuration, ce qui rend la mise en place d'un système avec OpenAFS très complexe. Coda Coda est développé depuis 1987 au CMU. Il est basé sur AFS. Le site web du projet se trouve à l'adresse http://www.coda.cs.cmu.edu. Coda est une évolution d'AFS, il reprend beaucoup de ses principes : gestion par volumes, cell, réplication, ACL... Il ajout la gestion des opérations en mode déconnecté. C'est à dire qu'un client peut rapatrier sur son poste les fichiers dont il a besoin, se déconnecter du réseau et continuer à travailler normalement sur ses fichiers. Quand la connexion sera rétablie, Coda se chargera de mettre à jour les fichiers, en gérant aux mieux (ou en demandant à l'utilisateur) les éventuels conflits qui peuvent apparaître. L'écriture retardée est aussi une nouveauté de Coda par rapport à AFS, cela permet de retarder l'écriture d'une modification sur un fichier afin de pouvoir les regrouper et ainsi optimiser les performances. Pour gérer les cas "déconnectés", lorsqu'un utilisateur accède à un fichier, il ne travaille pas directement sur le contenu du fichier stocké sur l'un des serveurs, mais sur une copie locale du fichier qui a été mise dans un cache (une partition dédiée ou un fichier) lors du premier accès. Ce qui signifie qu'il faut prévoir un cache suffisamment grand pour contenir tous les fichiers qui peuvent être ouvert à un instant t par un client. L'architecture de Coda a été simplifiée par rapport à celle d'OpenAFS, en plus du module noyau interceptant les appels systèmes sur les fichiers partagés, il y a uniquement deux serveurs. "Venus", sur le client, qui sert de gestionnaire de cache et Vice, sur le serveur, qui prend en charge la gestion des fichiers. Conception d'un système à haute performance – Les systèmes de fichiers 3/4 Copyright © CETMEF 2004 InterMezzo InterMezzo est grandement inspiré de Coda, mais entièrement repenser. Le site du projet se trouve à l'adresse http://www.inter-mezzo.org. InterMezzo est une évolution de Coda, il reprend les mêmes principes de fonctionnement (cell, volume, cache persistant, réplication, ...). Son premier but est la gestion du mode "déconnecté". Il faut voir InterMezzo comme un réservoir de stockage où les clients viennent prendre les données dont ils ont besoin, les modifient localement et les remettent ensuite. Il repose sur un système de fichier journalisé existant (ext3, JFS, ReiserFS, ...), un module noyau et un serveur (marchant à la fois sur les serveurs et les clients) "InterSync" qui synchronise les données présentes en cache chez les clients et sur les serveurs. Pvfs Pvfs signifie "Parallel Virtual FileSystem", le but du projet est d'explorer le design, l'implémentation et l'utilisation d'entrés/sorties parallèles. PVFS sert à la fois comme plate-forme pour la recherche sur les entrés/sorties parallèles et comme un système de fichiers distribués. Le site du projet est situé à l'adresse http://www.parl.clemson.edu/pvfs. Les principaux objectifs de la conception de PVFS sont de fournir une bande passante importante pour les accès concurrents en lecture et écriture sur un même fichier, la transparence pour l'utilisateur, la robustesse, la stabilité et la facilité de l'installation. Il n'y a pas de notion de volume dans PVFS, l'espace de nom est uniforme. Il repose sur trois serveurs. Le premier, "mgr", sert à la gestion des métadonnées, "iod", traite les requêtes d'entrés/sorties provenant des clients et le dernier qui est soit pvfsd soit kpvfsd (le premier s'exécute en mode utilisateur, l'autre en mode noyau) s'exécute sur le client et prend en charge la requête de ce dernier. Il y a aussi un module noyau qui intercepte les appels systèmes sur les fichiers partagés et les transmet au serveur pvfsd. A la différence des systèmes précédents, PVFS n'a pas de système de redondance ou de cache. Il n'est donc pas résistant à la perte d'un des serveurs et il n'y aura pas d'améliorations des performances en cas d'accès à répétition aux même données. Cependant, sa mise en place est relativement simple. Par contre, un bug présent dans la version actuelle (la 1.6.2) bloque le système du client si tous les serveurs sont pleins et que l'ajout de données ne sont pas possibles. Le problème a été signalé aux développeurs et devrait être corrigé dans les prochaines versions. Conclusion Par cette étude rapide de différents systèmes de fichiers distribués, on peut constater que ce concept est encore à l'état d'étude et de recherche. Le temps de cette étude étant limité, les systèmes les plus complexes (OpenAFS par exemple) n'ont pas pu être étudiés correctement principalement à cause de leur mise en place demandant de comprendre en détails leur fonctionnement interne. C'est pourquoi, en l'état actuel des choses, il a été décidé de réserver la place disponible sur chacun des noeuds dans une partition bien définie, mais elle restera pour l'instant non accessible en attendant de trouver une meilleure solution. Conception d'un système à haute performance – Les systèmes de fichiers 4/4 Copyright © CETMEF 2004