Le Stockage Distribué Robin Favre Fabien Touvat

Le Stockage Distribué Robin Favre Fabien Touvat
Polytech’Grenoble – RICM 3ème Année Vendredi 21 Novembre 2008 Etude d’Approfondissement Réseau

Plan Systèmes distribués Stockage distribué Oceanstore project
Définition Exemples Stockage distribué Le stockage et les réseaux Les Systèmes de fichiers distribués Système P2P Oceanstore project Historique Fonctionnement Critiques et limites [ ROBIN ]

I Systèmes Distribués A) Définition
“A distributed system is a collection of independent computers that appear to the users of the system as a single computer” Distributed Operating System. A. Tanenbaum, Prentice Hall, 1994 [ ROBIN ] Traduction littéral : Un système distribué est une collection d’ordinateur indépendant qui apparait pour les utilisateurs de ce système comme une seul machine. Andrew Tanenbaum, 64 ans, Chercheur Américain, diplomé du MIT, doctorat a Berkley. Il est enseignant chercheur à Amsterdam. Il a fait de nombreuses publications et ouvrages en réseaux et système d’exploitation. Il a developpé plusieurs OS don’t MINIX (basé sur UNIX), la première version est sortie en Elle inspira Linus Torvalds pour créer Linux.

I Systèmes Distribués A) Définition
Petite échelle Grande échelle Application Supercalculateur HPC (parallélisme) Scientifiques/Industriels P2P via Internet : Calcul Stockage Avantages Nombre limité de machine sécurité, synchronisation, « simplicité » Ressources Mises à l’échelle Faible coût Inconvénients Ressources Limitées Coût élevé Sécurité synchronisation [ FABIEN ] Il y a 2 grandes familles dans les systèmes distribués : Les systèmes dit de « petite échelle », il s’agit bien souvent de clusters de machine géographiquement proche (la plupart du temps une même salle ou bâtiment) On y retrouve les supercalculateurs et autres qui sont dédiés à la réalisation de puissant calcul. Ces systèmes sont bien souvent limités en nombre ce qui est un avantages car cela permet de garantir de la sécurité, de la cohérence et de la simplicité dans le fonctionnement. Ce système présente tout de même un inconvénients : celui d’avoir des ressources limités et un coût élevé à l’achat et à la maintenance. Ces machines sont très cher, seules les grandes entreprises et certaines université peuvent s’en acheter. Les systèmes dit de « grande échelle », généralement un ensemble de machine répartie sur Internet, donc dans le monde entier. Il s’agit généralement de réseaux Pair à pair. Ils sont utilisés pour les applications de stockage distribué ou de calcul distribué comme nous allons le voir par la suite. L’avantage majeur de ce système est une possibilité de ressources et de mise à l’échelle très importante car il n’y a pas de limite à l’ajout de nouvelles machines. Les inconvénients de ce système est la sécurité puisque ce réseau est ouvert à tout le monde (confiance) et la synchronisation des échanges entre les machines.

I Systèmes Distribués B) Exemples
Projets P2P « Hybride » : Client/Serveur et utilisation P2P sur Internet. Napster [ FABIEN ] Nous allons vous décrire brièvement 2 projets bien connus de P2P. Tout d’abord qui est dédié au calcul Napster qui est dédié au stockage. Le point commun entre ces 2 projets est qu’ils fonctionnent en partie sur un modèle client/serveur et en partie sur un modèle P2P. Ces deux projets sont bien des exemples de systèmes distribués mais pas à 100%. Nous allons donc voir pourquoi.

II Stockage distribué Le réseau et le stockage
Pourquoi stocker l’information ? Archivage Disponibilité Traitement Critères de stockages FABIEN Il y a 3 principales raisons aux stockages : conserver l'information en lieu sûr pour répondre à une contrainte légale ou conventionnelle (archivage des données), rendre l'information disponible, réutiliser l'information (traitement des données). Le choix de la méthode de stockage se fait selon plusieurs critères : (voir comme un DD) 1) la fréquence d'utilisation de l'information ; 2) la criticité de l'information ; 3) la pérennité de l'information ; 4) la confidentialité de l'information ; 5)le volume d'information à stocker ; 6) le temps alloué au processus de stockage ; 7) et bien sûr, son coût. Le mot d'ordre des techniques de stockage est : plus de capacité, plus vite, plus fiable, et moins cher.

II Stockage distribué A) Le réseau et le stockage
Les SAN (Stockages Area Network) Très utilisé pour les data-center et HPC Liens à très haut débit iSCSI, Fiber Channel, AoE Utilisation de système de fichier distribué Les NAS (Network Attached Storage) Utilisé pour la sauvegarde Débit moyen [ ROBIN ] Il s’agit souvent de cluster de disque dur (la plupart du temps monté en RAID) monté dans une baie. Très utilisé pour les HPC (supercalculateur) et pour les serveurs dans les data center avec des liens à très haut débit. Cette technologie permet le montage de partition virtuelle, généralement géographiquement proche. Il utilise donc un système de fichier distribué appelé : Shared disk file systems (also called shared storage file systems, SAN file system or even cluster file systems) que Fabien va vous décrire juste après.

II Stockage distribué A) Le réseau et le stockage
Exemple de NFS : Network file system [ ROBIN ] Un système de fichier réseau permet de faire, sur une machine locale, le montage d’un répertoire « virtuel » où les données sont en réalité sur une machine distante. L’utilisateur accède de manière transparente à un fichier sur sa machine à l’aide de RPC procédures à distance (lecture et écriture). On l’utilise tous à l’IMA quand on se log on a notre dossier home qui est un montage NFS vers un répertoire sur Mandelbrot. Ce protocole est différent des systèmes de fichiers distribués parce qu’il s’agit en fait d’une application de type client/serveur qui permet l’accès à des fichiers à travers le réseau et ce n’est pas traité au niveau matériel contrairement à un système de fichier distribué.

II Stockage distribué B) Les systèmes de fichiers distribués
Présentation générale [ FABIEN ] 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 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. 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.

Difficultés Temps d’accès et performance R/W Cohérence des données [ FABIEN ] Difficultés des SFD : 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é. Besoin d’une cohérence forte : Donc difficile à assurer plus le système est distribué/étendu

Bien pour les réseaux locaux Non applicable aux réseaux étendus [ FABIEN ] En conclusion des SFD: Les systèmes de fichiers distribués sont bien à petite échelle. On peut en effet avoir du stockage tolérant aux pannes parce que distribué sur plusieurs serveurs, de l’équilibrage de charge Mais si on veux passer a une échelle encore plus large, le monde entier, ce n’est plus suffisant. Typiquement on ne peut pas se permettre d’avoir un serveur qui connait l’emplacement de tous les fichiers.

Pour réseau LAN et WAN AFS (OpenAFS…) DFS (évolution de NFS) CodaFS Pour cluster : GFS GPFS Lustre [ FABIEN ] Réseau : AFS Andrew File System : (Aix, Linux) utilise les caches. Pour maintenir la cohérence le serveur garde le fait que le client à mit en cache une donnée et le prévient si la donnée est modifiée DFS : accès sur la redondance, c’est un genre de nfs, l’utilisateur a un point de montage sauf que derrière on a plusieurs serveurs qui stock le contenu du dossier monté. CodaFS (Linux) NCP NetWare Core Protocol (Novell NetWare, Linux en client seul) SSHFS (tous les UNIX ?, Linux) SMB ou Server Message Block (Windows) (Linux, BSD et Mac OS X via Samba) CIFS (Evolution de SMB, supporté par Samba ainsi que par Windows 2000 et XP) Tahoe[3] (libre, distribué, chiffré et avec tolérance aux pannes, tous les UNIX, Linux, Mac OS X, Windows) Cluster : GFS2, Global file system : Linux : différent des systèmes de fichiers distribués comme AFS, Coda, ou InterMezzo parce qu'il requiert que tous les nœuds aient un accès concurrent au même périphérique de stockage (shared block device). il n'y a pas non plus de client ou de serveur, tous les nœuds d'une grappe GFS sont égaux. GPFS, General Parallel File Sytem : Linux, AIX : un système de fichier conçu pour adresser de façon unique des volumes de données dépassant le pétaoctet et répartis sur un nombre de supports physiques pouvant dépasser le millier. Lustre, Compression de Linux et de Cluster : Linux OCFS2, développé par Oracle : Linux PVFS2, Parallel Virtual FileSystem version 2 : Linux, UNIX

II Stockage distribué C) Stockage sur P2P
P2P de partage de données : une ressource est sur une seule machine lecture seule P2P de partage d’espace de stockage : lecture / écriture sur plusieurs machines distantes [ ROBIN ] P2P de partage de données de type Napster comme on a vu, eMule, Gnuttela sont des P2P dédié au partage de données. Par principe une ressource est sur une seule machine et on peut télécharger uniquement ce fichier. Si la machine quitte le réseau, la ressource n’est plus accessible. Dans le P2P de partage de stockage on va en fait partager un espace de stockage sur sa machine aux autres membres du P2P. Et on va avoir les possibilités comme pour un SAN de lecture / écriture de fichier. Ceci permet de disposer d’une capacité de stockage très importante.

Avantages Fonctionnement à large échelle Faible coût Haute disponibilité Tolérance aux fautes [ ROBIN ] Un fonctionnement à très large échelle. Les systèmes pair-à-pair sont capable de supporter plusieurs centaines de milliers de nœuds (voire des millions) simultanément dans le réseau. Cela suggère un énorme potentiel du point de vue agrégation des capacités calculs ou des capacités de stockage. Un très faible coût. Les nœuds participants à de tels réseaux sont souvent de simples PC situés dans des bureaux. Les propriétaires de ces machines peuvent participer à une application pair-à-pair et délivrer de l'espace de stockage ou du temps de calcul. Une haute disponibilité et une excellente tolérance aux fautes. Etant donnée l'énorme espace mémoire disponible, la réplication des données peut être entreprise pour augmenter la tolérance aux fautes sur ces données. De même, en stockant des copies supplémentaires dans des caches près des nœuds demandeurs de la donnée, on améliore leur disponibilité à travers le réseau.

Inconvénients Performance des réseaux Gestion de la cohérence Dynamicité du réseau Sécurité [ FABIEN ] La performance des réseaux. La latence dans les réseaux de communications à cette échelle est très importante, surtout lorsque les messages sont relayés entre réseaux de nature différente. Les systèmes de cache améliorent le temps d'accès au données, mais introduisent de nouveaux problèmes de cohérence sur ces données. La gestion de la cohérence. Les systèmes distribués à plus petite échelle, comme les MVP, peuvent appliquer des modèles de cohérence relativement fort avec la possibilité de synchroniser tous les noeuds pour réaliser les mises à jour. Si un nombre important de copies de la donnée sont à mettre à jour, la latence au travers du réseau peut rendre cette opération particulièrement prohibitive. La dynamicité du réseau. Les systèmes pair-à-pair doivent supporter l'ajout et la suppression de noeuds dans la conguration du réseau. Les pairs sont de simples PC qui peuvent être éteint puis rallumés fréquemment ; la mise à jour des tables de routage et de localisation, la régénération du nombre de copies d'une donnée sont des opérations fréquentes que le système doit réaliser de manière transparente. La sécurité. La sécurité des données est souvent réalisée au niveau applicatif par encryptage des données. Certains systèmes prennent en compte la possible présence d'un pair malicieux dans leurs protocoles de cohérence, par exemple dans OceanStore . D'autres systèmes s'attachent à assurer l'anonymat des utilisateurs. Ces contraintes vont à l'encontre des objectifs de performance et sont à la base des mécanismes mis en oeuvre dans un système tel que Freenet

Plusieurs problématiques : Nommage, Localisation Routage tolérant aux pannes Disponibilité & Pérennité Redondance Sécurité & Confidentialité Cryptographie & Authentification Partage des ressources Equité et Cohérence des données Performance Placement, migration [ ROBIN ] Pourquoi routage tolérant aux pannes ?

Localisation 1ère génération : index centralisé [ ROBIN ] Le premier P2P était napster en 1999, Napster était en fait un P2P hybride puisque la localisation des ressources reposait sur un modèle client/serveur. Un serveur centrale indexait l’ensemble des clients connectés et leurs ressources. La localisation d’un fichier se faisait alors par une requête qui interrogeait le serveur Napster et répondait l’IP de la machine possédant la ressource. Le problème de ce système d’indexation centralisé c’est que d’une part le bon fonctionnement dépend du bon état du serveur et si le serveur tombe alors le réseau n’est plus en état de marche et d’autre part la localisation se faisait par nom donc assez limité en terme de pertinence des recherches. Napster a tout de même contribué au lancement des systèmes P2P, on a ensuite évolué vers une localisation décentralisé.

Localisation 2ème génération : inondation [ ROBIN ] La deuxième génération de localisation , par inondation, est une recherche décentralisé. Un client qui veut effectuer une recherche va propager sa requête à ses voisins, qui vont à leur tour la propager (ceci un certain nombre de fois). Une machine qui possède une ressource correspondante à la recherche répond à l’émetteur de la requête et le téléchargement peut s’effectuer. Donc on n’a plus de serveur qui centralise les clients et les ressources, cependant on est obligé de limiter le nombre de saut pour ne pas saturer le réseau et l’insertion de nouveau client et je vous renvoi au cours de SAR où on a vu comment insérer un pair de manière « aléatoire ».

Localisation 3ème génération : DHT Structure du DHT Partitionnement des clés Structure du réseau Maintenance de la structure FABIEN Dans ces systèmes, on a des tables de hachage distribué. On associe une clé à une valeur. Typiquement un nœud est identifier par une clé et on lui associe le hachage d’un fichier Par exemple, les pairs recevront les données dont les clés sont proches de la clé du pair. En conséquence, pour retrouver une donnée, il s'agira de retrouver le pair correspondant. Ces réseaux pourront fonctionner indépendamment des réseaux physiques sous-jacents à l'aide de mécanismes de routage dépendant des clés, dit de key-based routing (KBR). Ces systèmes hautement structurés assureront la localisation de toute donnée dans réseau. On peut décomposer la structure d’un DHT en plusieurs composants principaux. On a premièrement un espace de clé, par exemple un ensemble de chaine de caractère sur 160 bit. On a un découpage de ces clé : chaque nœud possède un certain nombre de ces clés. Et une structure du réseau (anneau logique, quelconque…) Pour partitionner les clés entre les nœuds on utilise une fonction qui va définir une notion abstraite de la distance séparant 2 clés. Elle ne tient pas compte de la distance géographique ou de la latence du réseau. Donc un nœud possède une clé si il a été définit comme étant le plus proche. Par exemple pour chord, pour le nœud N38 il possède la clé K38 Structure réseau : On peut avoir des réseau structuré, comme chord qui est en anneau logique, ou des réseaux non structuré comme tapestry. Chaque nœud maintient une liste de voisins. Toutes les topologies DHT partage quelques propriétés essentielles : un nœud possède une clé k ou connait un nœud qui est plus proche de k et peut donc le joindre. Ce qui va faire la différence entre les différents DHT c’est surtout : - Comme un nœud s’insère dans le réseau (Découverte des voisins, construction table de routage) Ce qu’il se passe lorsqu’un nœud se déconnecte du réseau de manière voulue ou non

Localisation CHORD CAN KADEMLIA PASTRY TAPESTRY [ FABIEN ] Quelques exemples

Disponibilité et pérennité Données persistante  redondance des données Insertion et départ Exemple avec Chord N32 N10 N5 N20 N110 N99 N80 N60 K19 K19 [ ROBIN ] Un système de stockage implique d’avoir des données persistante. Comme une machine peut se déconnecter du réseau à tout moment, il donc faut mettre un système de redondance des données pour que les données soit en permanence disponible et qu’elles durent dans le temps, qu’elles soient pérenne. (Tolérance aux pannes) Ces deux notions semblent liées ; en améliorant la présence d'une donnée dans le système, on améliore sa persistance et la disponibilité de la donnée au sein du système. Cependant, de nombreux systèmes ne garantissent pas la persistance d'une donnée mais améliorent leur disponibilité globale. Freenet en est un parfait exemple car il fonctionne sur un modèle de cache qui augmente le nombre d'instance des données populaires ; en contrepartie il peut supprimer la totalité des copies d'une donnée si elle n'est plus utilisées si les caches sont pleins. La persistance d'une donnée est assurée dans PAST et CFS par un nœud gestionnaire qui vérifie périodiquement la vivacité des pairs qui stockent des copies. Lorsqu'un pair tombe en panne, le gestionnaire doit alors dupliquer la donnée vers un autre pair pour garder le nombre de copies au delà du seuil fixé pour cette donnée. Si le pair gestionnaire tombe en panne, un autre pair doit prendre en charge cette responsabilité et dupliquer les données qui se trouvaient sur le site d'origine. La disponibilité d'une donnée au travers du réseau est un facteur important de performance. Les techniques les plus répandues visent à multiplier les copies et à les rapprocher des sites demandeurs. Une technique habituelle consiste à utiliser un système de cache conventionnel, par exemple de type Proxy Web, qui utilise l'espace libre des pairs. Evidemment lorsque le système est sous charge, cet espace n'est plus disponible et l'accélération est Oceanstore est conceptuellement différente : on en parle après

Cohérence et équité Il faut assurer que les données soient cohérente Plusieurs modèles ayant une cohérence plus ou moins fortes Cohérence forte Cohérence faible [ ROBIN ] Traditionnellement on dit que la mémoire est cohérente si la valeur retournée par une opération de lecture d'une donnée correspond toujours à la dernière valeur écrite de cette même donnée (cohérence forte). Il existe des modèles de cohérence plus faibles qui permettent l'implémentation de protocoles moins coûteux en nombre et en taille des messages, en imposant en contrepartie plus de contraintes au programmeur. Un exemple de cohérence faible : La cohérence à la libération ou eager release consistency (ERC) . Ce modèle utilise un verrou pour bloquer une ressource sur un nœud lors d’une demande d’écriture. Une fois l’opération terminée, le verrou est libérée et la mise à jour se propage alors vers les autres nœuds qui possèdent une copie de la ressource. On a donc une cohérence uniquement entre le nœud modifié et l’utilisateur mais pas avec les autres copies qui peuvent faire l’objet de modification pendant ce temps. On verra comment oceanstore fonctionne.

Optimisation Données mise en cache Déplacement de données proactive Equilibrage de charge Introspection [ FABIEN ] Les données peuvent être mise en cache sur des machines pour améliorer leur accès. Ca rejoint l’idée de la disponibilité des données évoqué précédemment. L'équilibrage de charge est un problème difficile lorsque l'on ne fait pas l'hypothèse que les pairs disposent du même espace partagé. Donc on a des systèmes comme CFS qui disperse des blocs de taille constantes. Ou alors on disperse des données de taille uniforme au quel cas il faut un gestionnaire capable de savoir ou stocker l’information. La dispersion des copies par l'utilisation d'un codage de redondance. La duplication des copies a été évoquée precedement pour le système PAST; cette méthode améliore la disponibilité d'une donnée en la rapprochant des demandeurs. Une autre technique est discutée dans OceanStore et évoquée sous le nom de Deep Archival Storage qui permet de disperser la donnée en plusieurs fragments à travers le réseau. L’introspection : C’est la capacité d'un programme à examiner son propre état. Typiquement les évènements de la couche localisation sont pris en compte par exemple pour discerner les composantes fortement connexes du réseau, typiquement des grappes, ou bien pour détecter les données dépendantes.

Plusieurs projets actuel : OceanStore (Berkeley) CFS (MIT) PAST (Rice) PASTA (Microsoft) Farsite (Microsoft) InterMemory (NEC) Ivy (MIT) PlanetP (Rutger U.) Mnemosyne (sprintlab) Clique (HP) Mammoth (BC U) Ficus (UCLA) Tornado (Tsing Hua U.) [ FABIEN ] Il existe de nombreux projets de recherche dédiés au Stockage en P2P. On retrouve des Universités comme Berkeley, le MIT, UCLA, Tsing Hua University et des Industriels tel que NEC et Microsoft.

III Ocean Store Project A) Historique
John Kubiatowicz 1999 University of California, Berkeley 30 personnes 14 étudiants 15 profs et externes Open Source, Licence BSD (Pond) But du projet [ ROBIN ] L’initiateur et meneur de ce projet est John Kubiatowicz . Il est enseignant-chercheur à L’université Berkeley en Californie. Il est spécialisé en OS, sécurité, parallélisme et système distribué. Ce projet a débuté en 1999. Environ 30 personnes travail sur ce projet, 14 étudiants et 15 autres enseignant-chercheur et des industriels. Le programme est en Open Source, le site fournit les explications de compilation, d’installations et d’utilisation. Pond est le nom de la version prototype qui est proposé. Ce projet est actuellement le plus important et le plus performant en ce qui concerne le stockage distribué et nous allons voir les raisons de ce succès.

III Ocean Store Project B) Fonctionnement
Hypothèses Localisation par DHT Disponibilité Modèle de cohérence Sécurité [ ROBIN ] Les développeurs d’OceanStore définissent leur système comme un espace de stockage persistent à l’échelle mondiale. Un stockage cohérent, hautement disponible et durable. « OceanStore is a global-scale persistent data store. A consistent, highly-available, and durable storage »

Hypothèses Infrastructure « untrusted » Bande passante conséquente L’utilisation poussée du cache Résolution de conflit au niveau applicatif [ ROBIN ] Dans ce cas la on pourrait traduire par « non-sécurisé » dans le sens où n’importe qui à accès au réseau puisqu’on est sur Internet. Les clients disposent de liens haut débit en temps d’accès et débit de transfert suffisant. Le système va chercher à faire des copies en cache où il veut et quand il veut. La résolution de conflit de cohérence se fera au niveau applicatif. Principle Party: There is one organization that is financially responsible for the integrity of your data Mostly Well-Connected: Data producers and consumers are connected to a high-bandwidth network most of the time Exploit multicast for quicker consistency when possible Promiscuous Caching: Data may be cached anywhere, anytime Operations Interface with Conflict Resolution: Applications employ an operations-oriented interface, rather than a file-systems interface Coherence is centered around conflict resolution

Tapestry Système développé à Berkeley pour les besoin d’Oceanstore. Espace de clé est grand (2^160) Clé en hexadécimal : « 3ABB » [ FABIEN ] .. Voyons un peu plus en détail comme ça marche

Tapestry : table des voisins Chaque noeud connait au moins un noeud de chaque niveau [ FABIEN ] Si on prend exemple d’un nœud dont l’ID est Bla bla

Tapestry : Routage Exemple : 7642  6531 [ FABIEN ] Table de routage avec des voisins

Tapestry : Localisation/publication Chaque objet est associé à un nœud racine Le nœud racine est le nœud où on a noeudID = GUID [ FABIEN ] Chaque objet est associé à un nœud racine (le plus proche) On peux avoir plusieurs nœuds possédant le même objet. Voyons en détail comment marche la publication

Tapestry : Localisation/publication [ FABIEN ] Lorsqu’un nœud veux publier un objet, il va en informer le nœud racine de l’objet (en orange).

Tapestry : Localisation/publication [ FABIEN ] Il va donc passer par plusieurs nœuds avant d’atteindre le nœud racine

Tapestry : Localisation/publication [ FABIEN ] Ces nœuds vont conserver un pointeur vers le nœud qui a publié la ressource

Tapestry : Localisation/publication [ FABIEN ] et lorsqu’ils auront une requête pour cette ressource il pourront la router directement. Cela permet d’équilibrer la charge et de trouver plus rapidement une ressource. [a mettre dans la diapo suivante]La gestion des copies dans OceanStore est basé sur l'introspection du système. Cela permet d'améliorer la migration des données en groupant leur transfert directement vers les pairs d'une même grappe, améliorant la disponibilité de ces données pour tous les sites de la grappe.

Disponibilité Redondance :Deep Archival Storage Replica float Fragment code Système de Gestion des Versions (SVN) [ ROBIN ] OceanStore assure une haute disponibilité des données. Pour ce faire le système va faire de nombreuses copies : des copies complètes du fichier appelés Replica float et des copies partielles appelés Fragment code. Les nœuds possédant une copie complète vont également tenir à jour les différentes versions du fichier. Cela permet de faire des restauration de fichier à des instants données tel des snapshots.

Disponibilité [ ROBIN ] Comme on peut le voir sur ce schéma on ici 3 nœuds qui possèdent la ressource complète ainsi que les versions précédentes et un journal des conflits. On va avoir également des copies partielles pour accroitre la redondance.

Modèle de cohérence Mise à jour : [ FABIEN ] Le modèle de cohérence appliqué dans OceanStore compte sur la non concurrence des écritures, aucune synchronisation n'étant offerte. Ainsi, lorsqu'une collision est détectée, la mise à jour peut tout simplement être annulée avant son application. Certains pairs du syst ème peuvent utiliser un modèle de cohérence encore plus optimiste en appliquant sans vérication sur un éventuel ordre causal les mises à jours sur leur copie locale. Le parcours d’une mise à jour dans OceanStore. La figure (a) montre qu'après avoir créé un chier de mise à jour, le client C2 l'envoie vers l'une des copies primaires ainsi que vers les possesseurs de copies secondaires connues par le site. Illustré par la figure (b), pendant qu'un consensus sur l'ordre des applications des mises-à-jour est réalisé par les pairs primaires, les pairs disposant des copies secondaires propagent la mise à jour et peuvent décider de l'appliquer en négligeant tout ordre. En (c), le consensus une fois réalisé par les pairs primaires, la mise à jour est propagée avec une estampille définissant l'ordre dans laquelle la mise à jour doit être appliquée. Les pairs des copies secondaires sont les sites qui ne participent pas au consensus. Ils reçoivent les mises-à-jour estampillées d'un ordre total de la part des pairs primaires pour cette donnée. Ils peuvent donc appliquer en toute sécurité la mise à jour. Le protocole de consensus d'une mise à jour peut être long et, comme le montre la figure, les pairs secondaires peuvent décider d'appliquer les mises à jour au plus tôt, ce qui est le comportement par défaut dans OceanStore. Cependant, le pair peut recevoir une mise à jour estampillée montrant que sa copie de la donnée est corrompue. Il faut alors reconstruire une donnée cohérente. Ce modèle fonctionne bien lorsqu'il n'y a pas trop d'écritures concurrentes sur une donn ée. Les pairs désirant une meilleure garantie de la cohérence de leurs données doivent attendre que les primary replicas leur ait diffusé les mises à jour validées.

Sécurité Cryptage avec RSA Lecteurs possèdent la clé Auteurs authentifiés Fichiers et opérations cryptés [ ROBIN ] Pour la sécurité OceanStore utilise RSA un cryptage à algo asymétrique à clé publique pour assurer la confidentialité et l’authentification. Gestion d’une liste de lecteurs autorisées qui possèdent la clé. Gestion d’une liste par fichier des auteurs autorisés par authentification.

III Ocean Store Project C) Critiques et limites
Utilisation de Tapestry Limites : Partie centralisée Hypothèses [ ROBIN ] Tapestry à l’avantage de connaitre la topologie du réseau comme on a pu le voir avec le protocole de routage donc les requêtes ne parcours pas de chemin inutiles pour atteindre une machine. On va avoir des performances similaire à Chord en terme de temps de recherche à savoir O(n). Et bien sûr comme c’est une DHT on est décentralisé. Néanmoins Tapestry présente le défaut de mal supporter les changements de topologie, l’ajout et le départ de nœud à des intervalles aléatoires est plus compliqué que pour Chord. OceanStore présente quelques limites : On a dit que pour les mise à jour oceanstore utilisait des primary tier, or les noeuds du primary tier doivent être hautement disponibles et fortement connectes, et dans l'esprit des concepteurs d'OceanStore, ces noeuds sont des serveurs dédies, congrues et maintenus par des fournisseurs de services payant. Aussi, OceanStore n'est pas vraiment adapte a une communauté d'utilisateurs souhaitant utiliser un système indépendant de toute autorité centrale. OceanStore fait plusieurs hypothèses notamment que les machines ont des liens haut débit « suffisant », donc …. ???

Références Bibliographie Webographie
Olivier SOYEZ, 2002, La RIA, Système de Stockage Pair à Pair Sébastien VARETTE, 2005, Introduction aux Systèmes distribués Jean-François Deverge, 2003, IRISA, Systèmes distribués de partage de données S. Rhea, P. Eaton, D. Geels, H. Weatherspoon, B. Zhao, and J. Kubiatowicz. 2003, Pond: the OceanStore Prototype Franck CAPELLO, 2005, INRIA, P2P : Développement récents et Perspectives Arvind Krishnamurthy, 2003, Fall, Tapestry Wrapup Webographie et [ ROBIN ] [ FABIEN ]

Merci pour votre attention
Avez-vous des questions ?

Recherche de ressources Architecture client-serveur
Annexes Architecture Centralisée vers Décentralisée Technologie Ressources Recherche de ressources Recherche de pairs Multi-source Architecture client-serveur centralisé non Napster (1999) décentralisé Direct Connect (?) eDonkey (2003) semi-centralisé oui Kademlia (?)

Le Stockage Distribué Robin Favre Fabien Touvat

Présentations similaires

Présentation au sujet: "Le Stockage Distribué Robin Favre Fabien Touvat"— Transcription de la présentation:

Présentations similaires

Notre projet

Feed-back

Entrer

S'autoriser via un réseau social:

Le Stockage Distribué Robin Favre Fabien Touvat

Présentations similaires

Présentation au sujet: "Le Stockage Distribué Robin Favre Fabien Touvat"— Transcription de la présentation:

Présentations similaires

Notre projet

Feed-back