Gestion des données persistantes (complément)

Présentation au sujet: "Gestion des données persistantes (complément)"— Transcription de la présentation:

1 Gestion des données persistantes (complément)
IFSIC Master - SDR - Nov/Déc 2007 Adrien Lebre - IRISA - projet PARIS Adrien LEBRE Systèmes distribués: des réseaux aux grilles IFSIC-M2R Novembre /12

2 Sommaire Les systèmes de fichiers Les systèmes de fichiers distribués
E/S parallèles, les bibliothèques d’accès Complément sur les DFS: de Sprite à xFS Adrien LEBRE Systèmes distribués: des réseaux aux grilles IFSIC-M2R Novembre /12

3 Systèmes de fichiers distribués Etude de cas : de Sprite à xFS
Projets SPUR (1985/1993) et NoW (1993/1998) - Université Berkeley Sprite : Système d’exploitation distribué Basé sur deux idées : Un système «network-aware» (rendre transparent le réseau) Exploiter les espaces mémoires de plus en plus grand (32Mo à l’époque) Sprite FS : Espace de nommage unique (transparence de situation). Partitionné de manière transparente en domaine. Chaque nœud composé d’un espace de stockage peut contenir un ou plusieurs domaines (chaque nœud peut être client et/ou serveur) Une table de correspondance (table des « préfixes ») entre les domaines et leur situation physique est maintenue dynamiquement sur chacun des nœuds. Lors de l’accès à un fichier, si aucune entrée ne correspond au sein de la table des « préfixes », un requête de type « inondation » est transmise. La problématique des fichiers spécifiques au machine (/etc/hostname) est résolu en « privatisant » certaines ressources au sein de la table des «préfixes». Adrien LEBRE Systèmes distribués: des réseaux aux grilles IFSIC-M2R Novembre /12

4 Systèmes de fichiers distribués Etude de cas : de Sprite à xFS
Sprite FS (suite) : Sémantique de type UNIX Cache distribué (coté client, lecture + écriture retardée) et maintenu en cohérence par un serveur « stateful » (invalidation des caches afin de forcer d’éventuelles écritures). Utilisation de la mémoire vive et secondaire de l’ensemble des nœuds Serveur à « état » (tolérance au pannes) Passage à l’échelle (protocole par inondation, maintien de la table des «préfixes») Log-Structured File System, LFS (Sprite FS, Version 2, 1990) Placement physique des données journalisé : « Les performances sont obligatoirement dépendantes du matériel  minimiser les déplacements » Idée fondamentale : une unité de stockage est vue comme un « buffer » circulaire Gain de performance en écriture Le cache s’appuie sur deux idees : Cache client à la NFS, notion de temporisation. Permet d’eviter des ecritures pour les fichiers temporaires (write-behind stratégie) Utilisation d’un numéro de version, lorsque le client accède a une donnée, il vérifie aupres du serveur si la version a ete incremente si oui il recupere les changements dans l’autre il n’a rien a faire si ces données sont deja presentes dans son cache. Pour éviter les incohérences possible, un protocole d’invalidation du cache sur chaque serveur est exploitée. Lorsque des client souhaitent acceder à des informations qui sont actuellement accédées en écriture, le serveur force l’écrivain à lui renvoyer les informations. Adrien LEBRE Systèmes distribués: des réseaux aux grilles IFSIC-M2R Novembre /12

5 Systèmes de fichiers distribués Etude de cas : de Sprite à xFS
D’un FS traditionnel vers LFS (a) Traditionnel (b) Minimisant la fragmentation (c) Fusion des méta et des données Concept de « super méta-bloc » de taille inférieur au cache. (d) Structure complètement journalisé Le « super méta-bloc » est écrit de façon périodique sur le disque. Principale difficulté : Réorganisation des données lorsque le pointeur d’écriture atteint la fin du disque. Segmentation du disque, à chaque nouveau segment, le précèdent est défragmenté. (d) En cas de crash, il suffit simplement de reprendre la dernière ecriture du super méta-block et vous obtenez un état cohérent. Il est également possible de reconstruire les dernierrs changements en relisant les blocs inscrit apres. Adrien LEBRE Systèmes distribués: des réseaux aux grilles IFSIC-M2R Novembre /12

6 Système de fichiers distribués Etude de cas : de Sprite à xFS
LFS, bilan : Sprite FS  amélioration des performances en lecture (cache sur chacun des noeuds) Journalisation  amélioration des performances en écriture Distribution et maintien du méta-bloc complexe et coûteuse Chaque fichier est stocké sur un unique disque  saturation/goulet d’étranglement Zebra File System (extension de LFS, 1992) Apport : répartition des données en RAID 4, Granularité des blocs (« chunk  size») : si trop importante  «hot spot » (cas des fichiers), si trop faible  surcoût latence réseau/disque (multiple accès). Mise en place d’un tampon au sein de chaque client (appelé «log»), A chaque fois que le tampon est plein, il est réparti sur les serveurs de données. Sprite est performant en lecture car l’ensemble des fichiers est stocke sur l’ensemble des nœuds. Chaque nœud a dans son cache les fichiers qu’il stocke. De meme chacun des clients peut avoir également ces données dans leur cache local. La distribution et le maintien du super méta-bloc est couteuse puisqu’il contient des informations sur l’ensemble des inodes stockés sur le disque. Il est donc souvent Assujetti a des écritures dessus (creation/destruction de données)  Comment gérer les accès concurrents ? Adrien LEBRE Systèmes distribués: des réseaux aux grilles IFSIC-M2R Novembre /12

7 Système de fichiers distribués Etude de cas : de Sprite à xFS
Zebra : utilisation de service centralisé pour maintenir en cohérence les données Adrien LEBRE Systèmes distribués: des réseaux aux grilles IFSIC-M2R Novembre /12

8 Système de fichiers distribués Etude de cas : de Sprite à xFS
Architecture du système Zebra Les clients : Lors d’une lecture, le client interroge le gestionnaire de fichiers qui lui indique le/les serveur(s) de stockage auquel(s) il est nécessaire d'accéder. Les écritures sont réalisées dans le «log» en s’appuyant sur le modèle LFS. Seules les méta-informations sont transmises au gestionnaire de fichiers et de stripes afin qu’ils évitent d’accéder aux serveurs de stockages (les « deltas »). Le gestionnaire de fichiers : Localisation des données sur les différents serveurs de stockages (à chaque fichier créé correspond un méta-fichier stocké sur le gestionnaire). Ces informations fournissent la correspondance vers les différents serveurs de stockages. Maintien de la cohérence entre les caches des clients en s’appuyant sur le modèle proposée par Sprite FS. Les serveurs de stockages : Gestion du stockage par blocs de taille fixe (stockage, récupération, identification, suppression) Le gestionnaire de stripes : Organisation des segments sur les différents serveurs de stockages, défragmentation des disques afin d’obtenir des segments libres (LFS). A chaque stripe correspond un fichier stocké au sein du gestionnaire qui indique les fragments de données encore valides au sein du stripe. Ces informations sont maintenues grâces aux «deltas». Client : Les méta transmises depuis les clients vers le gestionnaire de fichiers et de stripes sont appelés les deltas Serveur de stockage : Taille des blocs 512Ko Une operation de mise à jour des blocs a ete rajoute par la suite afin de pouvoir completer les fragments non plein (lorsqu’un client force l’ecriture d’un tampon qui n’est pas encore totalement rempli, il est intéressant qu’il puisse utiliser la place libre du fragment par la suite) Le gestionnaire de stripes : Le fichier associé s’apelle Stripe status files Adrien LEBRE Systèmes distribués: des réseaux aux grilles IFSIC-M2R Novembre /12

9 Système de fichiers distribués Etude de cas : de Sprite à xFS
Zebra, bilan : Les données sont fractionnées  équilibrage des « hot spots », tolérance Les méta-informations, Il y en a beaucoup !! Problèmes liés au point de centralisation des deux gestionnaires, La perte du gestionnaire de fichiers est critique ! Lorsqu’un serveur de stockages subit une défaillance, mode dégradé (RAID 4) Un nouveau concept dans les systèmes de fichiers distribués : Adaptation partiel de la structure du système de fichiers (possibilité d’ajouter des serveurs de stockages dynamiquement) xFS, « serverless file system» 1993, un nouveau projet: NoW (Network of Workstation, Univ. Berkeley), un nouveau système xFS : Version 1 : hiérarchisation des serveurs de méta-données Version 2 : «l’ensemble des services doit être accessible et opérationnel depuis chaque client» Zebra, Bilan : Lors d’un ajout d’un nouveau serveur de stockage, le gestionnaire de stripe va peu à peu re repartir les données sur le nouveau serveur. Indépendance à la mobilité… xFS : Version 1 : Supprimier le goulet d’etranglement, améliorer les performances Version 2 : serverless file system 1995 Adrien LEBRE Systèmes distribués: des réseaux aux grilles IFSIC-M2R Novembre /12

10 Système de fichiers distribués Etude de cas : de Sprite à xFS
xFS, architecture : Accès aux caches distants en priorité (cache coopératif). Distribution des gestionnaires sur plusieurs nœuds. Chaque nœud peut agir comme un client, un gestionnaire de stockage, de fichiers et de nettoyage. Distribution du gestionnaire de fichiers et de stripes : Un gestionnaire gère un sous groupe d’identifiants (un ensemble d’inodes). La table des préfixes dynamique du modèle Sprite FS devient statique. Lorsqu’un client souhaite accéder à une ressource, il regarde dans sa table afin de déterminer le gestionnaire en charge. Modèle du «premier écrivain» pour la création (possibilité de mettre en œuvre un méthode dite de ré-attribution permettant de re-équilibrer la table des préfixes). Même approche pour les stripes, chacune des unités maintient les segments qu’elle a écrits et réorganise les informations sur les blocs «valides» le cas échéant. Adaptation complète de la structure : Ajout et suppression de serveurs de stockages (répartis en sous groupe) Approche similaire à du RAID 1+4 («parallélisation» de l’écriture de plusieurs stripes) En cas de défaillance, le sous-groupe atteint bascule dans un mode dit «obsolète» (seules les lectures sont autorisées). Le gestionnaire de stripe va peu à peu transférer les données vers les sous-groupes qualifiés d’actuels. Lors de la remise en état du sous-groupe « obsolète », il n’est plus utile de recalculer les données via le XOR. Distribution : Les fichiers crées se voyent attribuer un numéro d’inode disponible dans la table local (approche du premier écrivain). L’idee prinicpale pour la distribution des gestionnaires de stripes repose sur le fait que généralement l’ecrivain est toujours le meme. Nous verrons que par la suite et dans les programmes parallèles cela n’est toujours pas vrai (programme MPI). Une solution possible consisterait à attribuer la gestion des stripes à celles des métas. Les changements seraient transmis comme pour Zebra via les deltas. Chaque unités maintiendrait les stripes a jour des inodes qui leurs sont rattachees. Adaptation : Dans chaque sous groupe, il y a un disque de parité. Adrien LEBRE Systèmes distribués: des réseaux aux grilles IFSIC-M2R Novembre /12

11 Système de fichiers distribués Etude de cas : de Sprite à xFS
xFS, bilan : Suppression des « SPOFS » (services totalement distribués). Tolérant aux pannes et hautement disponible Dynamicité dans la structure du système de fichiers  La sécurité n’est jamais été abordée ! Il est « facile » de corrompre une structure (les logs) et «crasher» de manière irrévocable le système de fichiers  encapsulation du système xFS dans une boite noire (via NFS par exemple). Performance ? Une version sous Solaris (1997) Le projet NoW s’est terminé en 1998. Adrien LEBRE Systèmes distribués: des réseaux aux grilles IFSIC-M2R Novembre /12

12 Systèmes de fichiers distribués Références (rappel)
De Sprite à XFS « The sprite network operating system » par J. Ousterhout, A. Cherenson, F. Douglis, M. Nelson at B. Welch. Paru dans IEEE Computer en 1998 « Beating the I/O bottleneck: A case oor log-structured file systems  » par J. Ousterhout et F. Douglis. Paru dans un rapport de recherche de l’université de Berkeley en 1992. « The Zebra Striped Network File System » par J. Hartman et J. Ousterhout. Paru dans High Performance Mass Storage and Parallel I/O: Technologies and Applications en 1993. « Serverless network file systems » par T. E. Anderson, M. D. Dahlin, J. M. Neefe, D. A. Patterson, D. S. Roseli et R. Y. Wang. Paru dans un rapport de recherche de l’université de Berkeley en 1995. Adrien LEBRE Systèmes distribués: des réseaux aux grilles IFSIC-M2R Novembre /12