Etude de la volatilité dans un système de stockage P2P Fabio Picconi – LIP6.

Slides:



Advertisements
Présentations similaires
Création de la base du SI Idée de départ : créer plusieurs couches de données avec chacune un intérêt propre et indépendante. Chaque couche doit pouvoir.
Advertisements

Les T.I.C. au service de l’organisation du directeur
La Couche Réseau.
10/31/02 Leïla Merghem - LIP6 Une approche Multi-Agents pour la Simulation de Réseaux de Télécommunications Leïla Merghem (LIP 6) Dominique Gaïti (LIP.
Modèle des jeux et des mécanismes
Détecteurs de fautes pour réseaux dynamiques P. Sens, L. Arantes, M. Bouillaguet Projet REGAL.
Gabriel Antoniu IRISA / INRIA Rennes
(Routing Information Protocol)
CLUSTERING Grappe d'ordinateurs.
26/03/2017 Fonctionnement d ’un cluster sous AIX grâce à HACMP : High Availability Cluster Multi-Processing Raphaël Bosc, IR5.
Stockage dans DIET Groupe de travail du 16 décembre 2002.
13 - Plate-forme logicielle Cisco IOS
Module 7 : Résolution de noms NetBIOS à l'aide du service WINS
Jean-François Deverge, Sébastien Monnet
Karel Heurtefeux1, Fabrice Valois2
CLUB DES UTILISATEURS FRANCOPHONES STAR- APIC Ville de Liège – Halle aux Viandes 24 et 25 novembre 2010 Bénéfices de la migration vers Elyx.
Système de stockage réseaux NAS - SAN
A.B.S.. Plan Avant-propos Plan Avant-propos Problèmes existants.
Ajouts, corrections et modifications de fiches en ligne. Description générale de la fonctionnalité Lorsque des corrections de fiches dans un envoi original.
Systèmes distribués C. Delporte-Gallet (ESIEE-IGM)
Le stockage magnétique
Auto-organisation dans les réseaux ad hoc
Amélioration de la sécurité des données à l'aide de SQL Server 2005
ADR Active and Dynamic Routing. Plan Introduction au routage Les réseaux actifs Les agents Mise à jour des matrices de routage Architecture du routage.
Module 16 : Implémentation de serveurs Windows 2000
Noyau persistant en réseaux pair-à-pair Comment relier la taille à la durée de vie V. Gramoli, A-M. Kermarrec, A. Mostéfaoui, M. Raynal, B. Sericola.
Atomicité Transactions Atomiques Recouvrement à Base de Journal
Réunion DataGraal Janvier 2003 Grenoble
Configuration de Windows Server 2008 Active Directory
1. SITE WEB DU SERVICE INFORMATIQUE DU RECTORAT
Les fichiers indexés (Les B-arbres)
Structures de données IFT-2000
Numéro dimmatriculation scolaire de lOntario Connexion à lapplication du NISO Ce que vous devez connaître : Les exigences techniques La sécurité est.
Gestion de Fichiers Tri Interne Efficace et Tri Externe.
Architecture des systèmes pair-à-pair de gestion de données Gabriel Antoniu Projet PARIS IRISA/INRIA.
Stockage dans les systèmes Pair à Pair
- La commutation de niveau 5- - La commutation de niveau 5 - Option RIO 2003 – FP04 Fabien DAGOMMER Fernando LUIS.
CEDCOM architecture haute performance pour des applications “big data” Tanguy Raynaud Projet CEDAR.
La réplication dans les réseaux mobiles ad hoc
Cours 5 Le modèle de référence.
Modèles et protocoles de cohérence des données en environnement volatil Grid Data Service IRISA (Rennes), LIP (Lyon) et LIP6 (Paris) Loïc Cudennec Superviseurs.
Le changement, c’est maintenant ! A la rentrée 2012, VOTEZ ENT.
1/13 Sécurité dans Pastis Fabio Picconi LIP6 13 février 2004 ACI MD Grid Data Services (GDS)
Nicolas DEWEZ Cyrille JOSSELIN Tuteur: Thierry DELOT Conception d’une application de partage de fichiers Projet IUP3 GMI - Valenciennes Jeudi, 23 mars.
Jean-Michel BUSCA et Pierre SENS
GDS – 17/02/061 Gestion de la volatilité dans un système de stockage P2P F. Picconi, P. Sens Regal (LIP6 / INRIA) ACI Masses de Données.
Initiation à la conception des systèmes d'informations
GDS : Grid Data Service Gabriel Antoniu IRISA / INRIA Rennes Réunion de lancement du projet GDS de l’ACI Masses de Données 22 septembre 2003.
1 Détection et tolérance aux fautes dans JuxMem Sébastien Monnet IRISA / PARIS Lyon, 05/12/2003.
Dominique LAURENT Patrick SEGUELA
Outil d’observation d’un réseau pair-à-pair Fabio Picconi – LIP6.
1 Premières études sur la gestion de la volatilité dans Pastis Fabio Picconi Réunion GDS – 19/11/2004.
Utilisation de Modelnet dans le cluster de SRC Fabio Picconi – LIP6.
ACI Masses de Données Bilan GDS Regal (LIP6 / INRIA)
COMPARAISON ENTRE GNUTELLA ET FREENET
Un service de partage de données pour DIET : GDS basé sur JuxMem Mathieu Jan Projet PARIS Lyon, 5 décembre 2003.
GDS : Grid Data Service Etat de l’avancement Gabriel Antoniu Réunion GDS, Lyon, 17 février 2006 IRISA, Rennes ACI Masses de Données.
Ingénierie des réseaux
SONDe: Service à densité auto-organisante tolérant la charge Vincent Gramoli (INRIA) Erwan Le Merrer (INRIA) Anne-Marie Kermarrec (INRIA) Didier Neveux.
Direction générale des technologies de l’information et de la communication (DGTIC) Scénario pédagogique – WebDépôt Création d’un dépôt de travaux assurant.
Simulation de traces réelles d’E/S disque de PC. Jalil Boukhobza, Claude Timsit Perpignan le 06/10/2006.
Persistance de noyau dans les systèmes dynamiques à grande échelle
1 UMLV  FICHIERS Mémoire de masse découpée en blocs Fichier :liste chaînée de blocs, ou arbre de blocs (répertoires - fichiers)‏ Bloc d’éléments Bloc.
Structures de données avancées : Principales structures de fichiers
Structures de données avancées : Arbres B+ avec expansion partielle D. E ZEGOUR Institut National d ’Informatique.
Projet GDS de l’ACI MD Projet PARIS IRISA, Rennes.
L. Gurret – M. Herve – P. Mignon – J. Prarioz. Introduction  Dernière étape d’analyse  Cahier des charges, spécifications et conception orientée objet.
Memoire.
Raison d'être de la structure de fichiers : Les premiers travaux : Début des années 1960 : En 1963 : Près de 10 ans plus tard... (à peu près 1973) : Durant.
Barry Callebaut Canada Inc.
Transcription de la présentation:

Etude de la volatilité dans un système de stockage P2P Fabio Picconi – LIP6

Motivation Problème de la volatilité (churn) dans les réseaux pair-à-pair toujours pas résolu Couches de routage tolérantes à la volatilité (Bamboo, MSPastry), mais question encore ouverte concernant la couche DHT Etude des effets de la volatilité des nœuds d’une DHT à blocs modifiables

Plan Réplication dans PAST Limitations du protocole de maintenance Solutions Evaluation

Placement des répliques (PAST) 04F2 3A B BB2 AC78 C52A E25A 73AB 8971 put( 8959, block ) 0-root 2-root 1-root Facteur de réplication k = 3 Clef = 8959

Placement des répliques (PAST) 04F2 3A B BB2 AC78 C52A E25A 73AB 8971 Facteur de réplication k = 3 Clef = 8959 Le nœud 8954 se déconnecte Le nœud 8909 doit remplacer le nœud 8954

Protocole de maintenance (PAST) Chaque noeud A émet une requête toutes les 10 minutes à tous ses voisins logiques. envoyer_requete() { pour chaque voisin logique V envoyer liste de clefs stockées localement à V attendre la réponse de V ajouter les clefs retournées par V à la liste de clefs à régénérer } recevoir_requete() { recevoir la liste de clefs stockées par A répondre à A avec toutes les clefs stockées localement qu’il devrait stocker, mais qu’il ne possède pas }

Protocole de maintenance (PAST) Blocs Blocs Blocs requête 8955 réponse 8956, 8959 get( 8956 ) get( 8959 )

Limitations Réactivité : jusqu’à 10 minutes pour détecter la perte d’une réplique Cohérence : la réplique est régénérée à partir de n’importe quel autre réplique (pas forcément à jour) Simplicité : pas de distinction entre blocs mutables et immutables Inefficacité : l’arrivé d’un nouveau noeud produit l’effacement des répliques du noeud sortant du replica set (nécessaire pour éviter plus de k répliques vivantes en meme temps)

Solutions Réactivité : augmenter la fréquence des requêtes envoyées aux voisins (10 minutes  1 minute). Traffic toujours négligeable par rapport au transfer des blocs. Cohérence : utilisation de quorums de lecture et écriture – Nombre de répliques = 3f + 1 – Quorum d’écriture = 2f + 1 – Quorum de lecture = 2f +1 – Ecriture et lecture forment une intersection d’au moins 1 réplique correcte

Solutions Facteur de réplication k = 10 f = 3 Quorum : 2f + 1 = 7 Ecriture Lecture

Solutions Facteur de réplication k = 10 f = 3 Quorum : 2f + 1 = 7 Ecriture Lecture Nœuds byzantins (roll-back) Nœuds très lents Replique correcte (numéro de version plus élevé) Nœuds pas à jour

Solutions Problème : un bloc mutable devient inaccessible en lecture s’il y a moins de 2f+1 répliques vivantes. Situation bloquante : le bloc ne peut plus être régénéré, même si plusieurs répliques existent Priorité à la réplication de bloc mutables – Un noeud va régénérer des blocs immutables seulement après avoir fini de régénérer tous les blocs mutables

Evaluation Modification de FreePastry : – Quorums d’écriture et lecture dans tout accès aux blocs mutables – Réduction de l’intervalle de maintenance de 10 minutes à 1 minute – Priorité à la régénération des blocs mutables

Evaluation Tests : – DHT de 50 noeuds stoquant 400 fichiers de 1 Mo Environ blocs, ou 100 Mo par noeud de la DHT ( k = 11 ) – Emulation liens ADSL (10 mbps downstr, 1 mbps upstr) – Latences entre 10 et 250 ms. – Arrivée de nouveaux noeuds selon un processus de Poisson (même effet que le départ de noeuds existants)

Priorité à la régéneration de blocs mutables

Taille des fetch queue (blocs mutables et immutables)

Arrivée simultanée de 50 nouveaux noeuds

Conclusions Algorithme de réplication original pas adapté à une DHT stoquant des blocs mutables et immutables Utilisation des quorums pour éviter la régéneration d’anciennes versions d’un bloc mutable Priorité aux blocs mutables pour éviter des blocs «perdus» Problème ouvert : l’arrivée simultanée d’un grand nombre de noeuds produit la perte de blocs

Future work Eviter l’effacement des répliques lors de l’arrivée de nouveaux nœuds Concevoir un système qui distingue les noeuds «stables» de ceux «instables» Proposer un mécanisme d’incitations (incentives) pour motiver les utilisateurs à rester en ligne

Questions ?