Document ID: /fineweb-2-swissfilter-quality_10-filterrobots/filtered/07153.jsonl.gz/891

par Martin Ouwehand, SIC-Exploitation
Pour toutes ces raisons, il est temps de passer à l'âge de l'informatique distribuée intégrée, où ce genre de détails est caché à l'usager, où l'utilisation du réseau est implicite au lieu d'être trop souvent explicite, comme au stade précédent. L'utilisateur de moyens informatiques doit avoir comme interlocuteur un système mieux intégré, fait de l'union du réseau et des machines qui y sont connectées, et non pas de quelques ordinateurs plus ou moins proches et qui sont accessoirement connectés entre eux par le réseau. Il doit pouvoir se connecter (en entrant son mot de passe), une fois pour toutes, au réseau dans son ensemble, et non pas, comme c'est grosso modo le cas actuellement, successivement à chaque machine dont il requiert un service dans le cours de son travail.
C'est pour résoudre les difficultés mentionnées que l'OSF (Open Software Foundation), un consortium de constructeurs informatiques et d'institutions académiques, s'est mise au travail dés 1991 pour développer DCE (Distributed Computing Environment), un ensemble complet d'utilitaires, de librairies de routines et de nouvelles fonctionnalités des systèmes d'exploitation offrant à l'usager une vue unifiée d'une cellule, c'est-à-dire, dans le terminologie de l'OSF, un réseau d'ordinateurs tel que celui de l'École.
DCE est structuré en couches: des services de base sont offerts à partir desquels sont construits des services aux fonctionnalités plus riches. Parmi les services de bases mentionnons les:
DCE fonctionne selon le modèle client/serveur: l'usager ayant besoin d'une ressource quelconque sur le réseau va interagir avec des process clients de sa station de travail qui vont demander à des serveurs de fournir différents services afin de satisfaire la requête de l'usager. Pour prendre un exemple concret, supposons qu'on veuille accéder à un fichier résidant sur une autre machine (serveur de fichiers). De multiples dialogues vont alors s'établir entre la machine cliente où doivent parvenir ces données et divers serveurs, afin tour à tour de localiser le serveur de fichiers où réside ce fichier (interrogation d'un serveur d'interface avec le CDS), de vérifier les droits d'accès à ces données (interrogation d'un serveur de sécurité) et enfin de contacter divers process du serveur de fichiers qui vont assurer le transfert des données vers la machine cliente.
Enfin, DCE offre la possibilité pour la plupart des serveurs d'exister à plusieurs exemplaires, afin d'assurer résilience et adaptation à la taille de la cellule. Si l'un des exemplaires devient inaccessible (à cause d'une panne de l'ordinateur où il s'exécute), les clients consulteront un autre exemplaire, ceci permettant donc d'assurer une continuité du service. Deuxièmement, si de trop nombreux clients requièrent un service particulier, surchargeant ainsi le serveur fournissant ce service, on pourra augmenter le nombre de machines assurant ce service pour l'adapter à la taille de la cellule (load-balancing).
Le Distributed File Service (DFS) est un service complexe basé sur les services de base de DCE et qui offrira de nombreuses fonctionnalités intéressantes. Il est sans doute appelé à remplacer dans un proche avenir NFS. Comme ce dernier, il s'agit d'un système de fichiers distribué, c'est à dire un système permettant d'accéder à une arborescence de fichiers ne résidant pas sur la machine locale mais sur d'autres machines du réseau (les serveurs de fichiers) tout en utilisant la même syntaxe que pour accéder au système de fichiers local. Qu'il s'agisse de fichiers locaux ou de fichiers accédés à travers le réseau, les requêtes auprès du système d'exploitation telles que open(), read() ou chdir() sont fonctionnellement équivalentes.
DFS offre par contre un espace de noms uniforme pour tous les fichiers distribués sur les divers serveurs de fichiers de la cellule, ce qui n'est pas le cas de NFS. Spécifiquement, on signale à la machine locale qu'on désire accéder par DFS à un fichier se trouvant ailleurs sur le réseau en l'invoquant avec un nom formé comme suit: /:/dir/fichier. La séquence initiale <</:>> est caractéristique des fichiers mis à disposition à travers DFS. En outre, ce nom sera le même pour un même fichier, quelle que soit la machine cliente à partir de laquelle on y accédera (une autre différence avec NFS). Ainsi cette syntaxe cache à l'utilisateur l'emplacement exact du fichier sur le réseau, un renseignement dont il n'a en effet que faire. Cela va même plus loin: <</:>> est en fait un alias pour <</.../epfl.ch/fs>>, la racine de l'arborescence des fichiers DFS de la cellule locale, celle de l'EPFL. D'autres cellules DCE ailleurs dans le monde sont accessibles selon la même syntaxe (si les bonnes dispositions sont prises, notamment au niveau de la gestion des droits d'accès entre cellules), de telle manière que la commande suivante affichera un fichier résidant à l'ETHZ sur l'écran d'un utilisateur de la cellule locale de l'EPFL:
more /.../ethz.ch/fs/dir/fichier
ou même, de manière équivalente:
cd /.../ethz.ch/fs/dir
more fichier
Deuxième différence entre DFS et NFS: plusieurs serveurs DFS peuvent collaborer entre eux pour mettre à disposition des clients diverses parties de l'arborescence uniforme dont on vient de parler, alors que chaque serveur NFS est comme une île qui ne peut distribuer à ses clients que ses partitions locales. Ceci permet en outre à DFS d'offrir deux fonctionnalités très intéressantes: la redondance et l'équilibrage de la charge (load-balancing). Des branches de l'arborescence uniforme de DFS (connues sous le nom de filesets dans la terminologie DFS) qui sont souvent accédées (elles contiennent par exemple un logiciel très populaire) peuvent exister en plusieurs copies sur divers serveurs. Chaque client ira chercher ces données sur le serveur le plus proche de lui, ce qui va bien sûr répartir la charge sur le réseau de manière plus équilibrée. En outre, si un de ces serveurs tombe en panne, ses clients trouveront toujours les données les intéressant sur l'un des autres serveurs disposant d'une copie du fileset en question (DFS offre donc aussi cette possibilité de résistance à la panne). Finalement, s'il se trouve qu'un serveur est soumis à une plus grosse charge que d'autres, il est possible de transférer certains des filesets dont il a la responsabilité vers d'autres serveurs moins chargés, mais de telle manière que les fichiers de ces filesets restent accessibles aux clients durant ce transfert: les clients s'adressent à un serveur spécifique chargé de rechercher l'emplacement des fichiers sur les serveurs DFS. C'est là une nouvelle possibilité d'équilibrer la charge.
Dernière différence importante: l'utilisation d'un cache local au client pour y stocker les fichiers récemment accédés. Les concepteurs de DFS sont partis de la constatation que la plupart du temps, les usagers travaillent de manière répétée sur un nombre restreint de fichiers (par exemple dans une suite de cycles édition/compilation/correction/exécution). Si ces fichiers se trouvent dans l'arborescence DFS, cela vaut donc la peine de les transférer du serveur vers le client à la première utilisation et de laisser par la suite l'utilisateur se servir de cette copie locale, le but étant bien sûr de jouir de meilleurs temps d'accès aux données de ce fichier. Plus tard, un process spécifique de DFS est chargé de mettre à jour la version résidant sur le serveur. En cas d'accès concurrent de plusieurs utilisateurs à un même fichier ce système de cache implique, pour garder une vue cohérente de ce fichier, toute une gestion de droit de modification, de répercussion des modifications vers les copies du fichier dans les caches des divers clients, etc. Ceci se fait par un système de tickets délivrés et vérifiés par les divers process clients et serveurs constituant DFS. Par comparaison, dans la version originale de NFS, le client ne garde pas le souvenir des transactions précédentes et lorsqu'un usager accède deux fois de suite, à quelques secondes d'intervalle, au même fichier résidant sur un serveur, ce fichier sera entièrement transféré deux fois. Si entre-temps le fichier n' a pas été modifié, on peut considérer que le deuxième transfert était inutile. Il est à noter toutefois qu'il existe une version plus récente de NFS implémentant aussi l'utilisation d'un cache sur le client.
DFS est basé de manière extensive sur le modèle client/serveur, se servant d'un <<tissu>> extrêmement complexe de process clients et serveurs dialoguant entre eux. Nous pouvons en mentionner quelques uns: le serveur de localisation (qui sait sur quel serveur se trouve quel fichier), le gestionnaire de tickets (utilisés pour contrôler la synchronisation des diverses copies des fichiers dans les caches des clients), le serveur de sécurité (qui gère les droits d'accès et de modification des fichiers), le serveur de temps (pour contrôler la durée de validité des tickets et des dates de modification des fichiers), les gestionnaires de cache des clients (qui savent quels fichiers ont une copie valide dans le cache), l'exporter (par lequel les serveurs annoncent la disponibilité de leurs filesets), etc.
Nous sommes très intéressés par les fonctionnalités qu'offre DFS et nous pensons qu'à moyen terme ce système contribuera à implémenter à l'École une hiérarchie mieux intégrée et plus équilibrée de serveurs de fichiers d'Instituts, de Département, que viendrait seconder le serveur Nestor. Dans cette philosophie, ce dernier serait bien adapté a la tâche de machine de backup, à travers DMF (Data Migration Facility), son utilitaire d'archivage automatisé interagissant avec le robot STK monteur de cartouches. Le silo de ce robot a une capacité d'environ 9000 cartouches, qui pourront dans le courant de l'année prochaine accueillir chacune prés de 20 Gigabytes de données (technologie D-3).
Mais la complexité de DFS demande une approche progressive: dans un premier temps, un groupe de volontaires doit acquérir le savoir-faire nécessaire avec des configurations de test de petite taille, après quoi pourra être envisager la mise en route de DFS en grandeur réelle à l'échelle de quelques Instituts ou Départements pilotes avant finalement d'installer DFS dans tous les Départements intéressés. Il s'agit là d'un travail de longue haleine, s'étendant sans doute sur deux ans ou plus. Mentionnons à titre d'encouragement que prés de nous, l'ETHZ a déjà plusieurs mois d'expérience avec AFS (Andrew File System), le précurseur de DFS. De même, l'université de Stuttgart, un site tout à fait comparable au nôtre, est également en train d'adopter DFS, après quelques années d'utilisation d'AFS.
article paru dans le Flash informatique no 8 du 25 octobre1994