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