Architectures distribuées de gestion de données

Architectures distribuées de gestion de données Dan VODISLAV Université de Cergy-Pontoise Master Informatique M2

Plan Applications de gestion de données réparties sur le web Principes de la répartition Utilisation des services web Exemple de système Architectures pair-à-pair Principes, classification Exemples de systèmes pair-à-pair Page 2

Architectures distribuées de gestion de données Intégration de données architectures distribuées Les sources = serveurs de données, le médiateur = client Médiateur = serveur de données, l application = client Médiateur = architecture distribuée très simple Un client, plusieurs serveurs Les sources: seules des fonctionnalités d interrogation de données En principe, on pourrait avoir: Des rôles mélangés client/serveur pour les sites architectures distribuées pair à pair Des sites qui offrent d autres services sur les données que l interrogation et qui collaborent applications réparties de gestion de données basés sur ces services Page 3

Médiateur, pair-à-pair, réparti M P S S S S P P P P Médiateur Pair à pair services P P P P P Réparti Page 4

Applications réparties Applications réparties Généralisées même en entreprise (traditionnellement centralisées) Accès à plusieurs ressources / applications individuelles Séparation entre «clients» et «serveurs» Architectures 1-tier : centralisé 2-tiers: un serveur, n clients (client - serveur) 3-tiers: m serveurs, n clients (avec middleware) N-tiers: spécifique à la diffusion sur le web Ex: serveurs web avec architecture 3-tiers + clients web Clients n-tiers serveurs (n+1) - tiers Page 5

Architectures Client Niveau «présentation» Niveau «application» Client Niveau «présentation»... Niveau «application» Client Niveau «présentation»......... Niveau «application» Niveau «gestion données» Niveau «gestion données» Serveur Niveau «gestion données» Serveur Middleware...... 1-tier 2-tiers 3-tiers Page 6

Communication Application répartie «Tiers» qui réalisent des traitements Communication entre «tiers» Moyens de communication traditionnels Middleware RPC («Remote Procedure Call»): appel de fonctions à distance Moniteurs transactionnels («TP monitors»): bases de données «Object brokers»: RPC en orienté-objet (ex. CORBA, DCOM) Moniteurs d objets («object monitors»): «object broker» + «TP monitor» Middleware orienté-messages: asynchronisme, files d attente EAI («Enterprise Application Integration») Communication entre systèmes plus hétérogènes (ex. entre systèmes 3-tiers) Ex: WebSphere MQ, BEA WebLogic Integration, webmethods, etc. Visent souvent aussi des aspects «workflow» (séquence de traitements) Page 7

Services web Sur le web: contraintes qui n apparaissent dans les environnements d entreprise Contrôle limité sur les sites Débit faible Clients légers Interaction, présentation moins riches (HTML) Objectif: réaliser des applications distribuées (architectures k-tiers) avec les contraintes imposées par le web services web Page 8

Caractéristiques des services web Demande de service adressée par un client à un serveur Appel d une fonction distante Utilise les protocoles web: TCP/IP, HTTP Données transportées sur le web Généralement du texte (HTTP: pages HTML) Services web texte en format XML Format d échange flexible Standardisation Services web: évolution des architectures Architectures distribuées classiques web RPC, RMI, CORBA, DCOM HTTP, XML, services Web «homme-machine» web «machine-machine» Page 9

Web «machine-machine» Web dynamique «homme-machine» HTML + HTTP + scripts Scripts: tâches exécutées par un serveur web HTML: contenu généré dynamiquement par les scripts HTTP: utilisation «manuelle» à travers un navigateur web Interface informelle Paramètres de type texte Résultat: HTML Web «machine-machine» XML + SOAP + code Code: programme/fonction appelé à distance XML: format d échange général SOAP: utilisation par des programmes (automatique) Interface formalisée (WSDL) Paramètres et résultat typés XML Schema Page 10

Avantages des services web Flexibilité Indépendance du langage et du système Données XML Interopérabilité dans des environnements distribués Interfaces formalisées Communication entre services, composition Automatisation Adaptés à la communication sur le web Protocoles web bien connus et acceptés (HTTP, SMTP, ) Invocation à travers des pare-feux (à la différence de CORBA) Page 11

Services et données Gestion de données sur le web Web passif: chaque site fournit ses données sur demande Web actif: des applications indépendantes sur chaque site échangent des données à travers des services web Web passif Web actif Page 12

Exemple: ActiveXML ActiveXML (AXML) Modèle de gestion de l information distribuée basé sur XML et les services web Langage déclaratif pour décrire des documents actifs Infrastructure pour supporter ce modèle/langage dans un environnement pair-à-pair Historique Développé à l INRIA (équipe Gemo) à partir de 2001 Open source depuis 2004 Enrichi périodiquement de nouveaux modules A la base de l entrepôt P2P KadoP Page 13

AXML: principes Idée de base Données: documents XML Une partie des données peut changer dans le temps ne pas la représenter explicitement, mais par un appel de service web Document AXML = document XML + appel de services web Données «intensionnelles» Une partie des données est explicite, l autre partie est implicite, décrite par une «formule» (moyen de l acquérir en cas de besoin) «Formule» = appel de service web Données dynamiques Si la partie implicite provient d autres sources de données un même document AXML pourra fournir un contenu différent à des moments différents, suivant les changements Page 14

Exemple Document AXML (syntaxe simplifiée) Service web: foot.com, opération: getmatch, paramètres: équipe, année <worldcup year="2006"> <axml:sc>foot.com/getmatch("fra", "2006")</axml:sc> </worldcup> Résultat <worldcup year="2006"> <axml:sc>foot.com/getmatch("fra", "2006")</axml:sc> <match id="1" location="stuttgart" date="13 Juin"> <equipe id="fra" score="0"/> <equipe id="sui" score="0"/> </match> <match id="5" location="francfort" date="01 Juillet"> <equipe id="bra" score="0"/> <equipe id="fra" score="1"/> </match> </worldcup> Page 15

Architecture logique Page 16

Pair AXML Rôles d un pair AXML Entrepôt de documents AXML Client de services web offerts par d autres pairs Serveur de services web définis au-dessus de l entrepôt local Gestion de Documents Actifs Activation de SC Exécution de SC Mise à jour de résultat Gestion de Services Publication Évaluation Services continus Interrogation Gestion de la Persistance Gestion de l entrepôt Lectures écritures physiques Page 17

Architecture physique AXML peer AXML peer XOQL processor query AXML engine AXML SOAP AXML AXML peer read read update consults SOAP wrapper WSDL service descriptions XML SOAP service AXML store service call service result AXML SOAP client Page 18

Architectures P2P Pair-à-pair (P2P) Architecture distribuée Ressources distribuées sur un ensemble de machines (pairs) Collaboration pour réaliser une fonction d une manière décentralisée On s intéresse surtout à la gestion de données Pas de distinction entre clients et serveurs Avantages: Performances: pas de serveur centralisé, distribution des traitements Autonomie: chaque pair a le contrôle de ses données, connexions ad-hoc Passage à l échelle: distribution de la charge, réplication des données Dynamique: système ouvert, gestion dynamique de la composition du réseau Uniformité: meilleur support pour anonymat et la confidentialité Difficultés: Coût de la communication Cohérence et qualité des données Page 19

P2P et client-serveur serveur clients pairs Client-serveur P2P Page 20

Pair Nœud dans un réseau P2P Client et serveur Peut communiquer avec ses pairs Rôles Client: demande des services au réseau P2P Serveur: offre des services au réseau P2P Routeur: achemine des demandes de services dans le réseau Page 21

Caractéristiques P2P Décentralisation Centralisation: goulot d étranglement, manque de fiabilité Autonomie et relative symétrie des pairs Passage à l échelle Division du traitement, du stockage, de la bande passante entre pairs Limitations: parallélisme limité, rapport calcul/communication Autonomie des pairs: stockage, exécution, appartenance, connexion (topologie) Disponibilité Le système fonctionne même en cas de déconnexion d un pair Réplication disponibilité d une donnée même si le pair qui la stocke sort du réseau Performance: calcul, stockage, communication Techniques: réplication, caching, organisation du réseau Technique particulière: groupement sémantique de l information Auto-configuration: adaptation aux entrées/sorties du réseau Baisse des coûts: accès aux ressources des autres Confidentialité : source, destinataire, réciproque Équité: l offre et la consommation des ressources doit rester équitable Page 22

Classification Selon la topologie du réseau Graphe aléatoire, étoile, arbre, grille, etc. Selon le niveau de décentralisation Centralisé: un pair central a une fonction privilégiée (Napster) Hybride: une partie des pairs (super-pairs) jouent un rôle particulier Pur: tous les pairs ont les mêmes fonctionnalités Selon la structuration du réseau Non-structuré: pas de critère de répartition des données sur les pairs Localisation: demande aux voisins («flooding»), temps non garanti Faiblement structuré: groupement des pairs par caractéristiques communes («clustering») Répartition et localisation par groupe, temps partiellement garanti Structuré: répartition précise des données (ex. par hachage) Localisation rapide, temps garanti Page 23

Niveaux d abstraction Niveau réseau Problème: nature dynamique du réseau Niveau localisation et routage Localisation de ressources et de pairs, centralisée ou distribuée Optimisation de la communication entre pairs Niveau gestion Gestion des ressources locales Robustesse: réplication Sécurité: problème difficile en P2P Niveau services Services globaux: gestion meta-données, messages, planification, ressources P2P Niveau application Page 24

Applications P2P Communication et collaboration Communication directe entre pairs: chat, messagerie, téléphonie Chat/Irc, MSN Instant Messenger, Jabber, Skype Calcul distribué Répartition de parties d un calcul entre pairs Seti@home, genome@home Support aux applications web Allégement de charge d un serveur (Coral), protection contre attaques Systèmes de bases de données Bases de données distribuées: PIER, Piazza, KadoP, Edutella Distribution de contenu Échange de fichiers, publication et stockage La plupart des systèmes actuels: Napster, Kazaa, Chord, CAN, Page 25

Types de systèmes P2P Calcul distribué : SETI@Home Non structurés Centralisé: Napster Distribué: Gnutella Structurés Tables de hachage distribuées (DHT): Chord, CAN Topologie hybride en arbre: MediaPeer Page 26

Calcul distribué Partage de CPU et des données à traiter On le place plus souvent dans la catégorie «grille de calcul» SETI@home : «Search for Extraterrestrial Intelligence» But: découvrir des signaux radio en provenance de l espace Distribution de fichiers de données à traiter (350K/jour) Page 27

Réseau P2P non structuré centralisé Napster : répertoire centralisé Étapes: 1. Les clients publient sur le serveur la liste des noms de leurs fichiers 2. Le client qui cherche un fichier demande au serveur 3. Le serveur répond avec une liste de clients 4. Parmi les pairs cible, le client qui a fait la requête détecte par un «ping» le pair le plus proche 5. Le client télécharge directement le fichier en provenance du pair choisi Page 28

Réseau P2P non structuré distribué Gnutella Chaque pair gère ses données Chaque pair connaît une liste de voisins Requêtes: vers les voisins («flooding») propagées dans un voisinage de rayon limité Joindre le réseau: message «Ping» vers un ensemble de pairs trouvés dans une base de données (http://gnutellahosts.com) Les pairs envoyent un message «Pong» en retour, avec infos sur eux-mêmes et propagent le message «Ping» vers leurs voisins Propriétés Très robuste Ne trouve pas toutes les réponses Page 29

Requêtes Gnutella Page 30

Réseaux P2P structurées Tables de hachage distribuées «Distributed Hash Tables» (DHT) Généralisation des tables de hachage Chaque donnée est identifiée par une clé Index par hachage Entrée = couple (clé, valeur) Position de l entrée dans la table: h (clé) Fonction de hachage h : distribution uniforme dans la table Hachage distribué h (clé) pair sur lequel le couple clé-valeur sera placé Distribution uniforme des valeurs sur les pairs du réseau Sur un pair: table de hachage locale Fonction h : pour placer et retrouver une valeur dans le réseau Page 31

Tables de hachage distribuées Commandes Put (clé, valeur) Lookup (clé) valeur Fonctionnement Un pair veut publier/retrouver une donnée v, caractérisée par une clé k Il calcule l adresse du pair qui doit stocker v, à l aide de la fonction de hachage h (la même pour tous les pairs!) appliquée à k Il se connecte au pair cible pour transférer/récupérer la donnée v Mécanisme général de localisation de ressources distribuées Le modèle clé-valeur est adapté à une large classe d applications On peut répartir des données ou des index Distribuer un index : garder le contrôle sur les données Pour un index: la valeur = adresse (liste d adresses) de données Page 32

Chord Table de hachage distribuée Clés: pour les données et pour les pairs (adresse IP) Fonction de hachage sur m bits valeurs dans l intervalle [0..2 m -1] Espace de hachage ([0..2 m -1]) organisé logiquement en anneau Convention Quand on parle de clé k ou d identifiant de pair id, on parle de leur correspondant (par la fonction de hachage) dans l espace d adressage Les pairs : au maximum 2 m Divisent l espace d adressage en intervalles Clé k distribuée sur succ(k) succ(k) = le pair dont l identifiant est le premier >= k pred(k) = le pair dont l identifiant est le premier < k Pour chaque pair on peut définir son successeur et son prédécesseur Page 33

Chord: exemple 6 X identifiant noeud clé 7 0 1 1 succ(1) = 1 6 succ(6)= 0 6 Anneau d identifiants 2 2 succ(2) = 3 5 4 3 2 Page 34

Chord: recherche naïve Recherche d une clé k adressée à un pair d identifiant p lookup(k) Si k est stockée par le pair p il la retourne Chaque pair connaît son successeur Si k n est pas sur p il transmet la requête à son successeur Le pair qui a la clé transmet la réponse directement à celui qui a fait la requête Problème: recherche en O(n) n = nombre de pairs Trop de communication Page 35

Chord: recherche optimisée Utilisation de tables de routage «fingers» Pair p, table de taille m Entrée i = adresse pair succ(p+2 i-1 ) Entrée i = i ème «finger» de p finger table For. start 0+2 0 0+2 1 0+2 2 1 2 4 succ. 1 3 0 keys 6 7 0 1 finger table For. start 1+2 0 1+2 1 1+2 2 2 3 5 succ. 3 3 0 keys 1 6 5 4 3 2 finger table For. start 3+2 0 3+2 1 3+2 2 4 5 7 succ. 0 0 0 keys 2 Page 36

Chord: recherche optimisée (suite) lookup(k) sur un pair p Chaque nœud connaît ses successeurs en puissances de 2 sur l anneau On prend dans la table «finger» l entrée la plus proche avant k p + 2 i est le plus proche possible de k, sans le dépasser Au pire on tombe à moitié de l intervalle [p, k] On continue avec le nouveau pair Dichotomie Recherche en O(log n) Exemple m = 6 (N0 N63) lookup(54) sur N8 Page 37

Chord: ajout et retrait d un pair Ajout pair p S = succ(p) est trouvé (par lookup(p)) et le pointeur succ de p est initialisé à S Les clés <= p de S sont déplacées sur p Le pointeur succ de pred(p) est mis à p Retrait d un pair p Ses clés déplacées vers succ(p) Le pointeur succ de pred(p) est mis à succ(p) Processus de stabilisation Processus indépendant qui s exécute périodiquement et maintient la cohérence du réseau Mise à jour des tables «finger» Mise à jour des pointeurs «succ» en cas de panne d un pair Seuls des pointeurs «succ» corrects garantissent le fonctionnement correct Maintien d une liste de plusieurs successeurs (pas seulement le premier) Page 38

Chord: conclusions Recherche rapide, en log(n) Algorithmes simples et robustes Fiabilité par maintenance des successeurs (liste) Résistance en cas de panne d un pair Combinée avec de la réplication sur les voisins Coût de maintenance Déplacement de clés Calcul et maintenance de successeurs Processus de stabilisation Problème: mapper l anneau virtuel sur le réseau réel Prise en compte de la distance réseau Page 39

CAN Table de hachage distribuée Espace de hachage: espace d-dimensionnel en coordonnées cartésiennes Voisinage entre les zones extrêmes sur chaque axe (tore) L espace est divisé entre les pairs: chaque pair a une zone bien déterminée Division par dichotomie sur un axe Fonction de hachage uniforme clé espace d-dimensionnel Routage Chaque pair a des voisins (ceux des zones voisines) Il connaît sa zone (peut décider si une clé lui revient ou non) et ses voisins lookup(k) sur pair p: Si k est dans la zone de p trouvée Sinon, parmi les voisins de p, un seul est le plus proche de la zone de k! Routage de lookup(k) vers ce voisin et recherche récursive Page 40

CAN : exemple dans un espace 2D Page 41

CAN : ajout et retrait d un pair Ajout d un pair Choix aléatoire d un point P dans l espace Recherche de la zone et du pair X qui est responsable du point P Division de la zone de X selon l un des axes Affectation d une des moitiés au nouveau pair et transfert des clés Création de la liste de voisins du nouveau pair à partir des voisins de X Pour chaque voisin du nouveau pair (dont X), mise à jour de la liste de voisins pour tenir compte du nouveau pair Retrait d un pair Un des voisins prend en charge la zone désertée et les clés Mise à jour des voisinages Page 42

CAN: performances Routage pour lookup d dimensions, n zones (pairs) O(d * n 1/d ) Ex. d = 2 O(2 n) Taille table routage pour chaque pair: 2d (indépendant de n) Avantage Si un pair dans le chemin est en panne, un nouveau chemin optimal existe Adaptation automatique en choisissant le meilleur voisin disponible Comparaison avec Chord Moins bien en temps de routage Meilleure localité plus flexible, moins d information de routage Page 43

Réseau P2P structuré hybride MediaPeer (lab. PRISM, Versailles) Sources qui publient des chemins fournis par la source Chemins XML, chemins d ontologie Requêtes basées sur des chemins retrouver les sources qui fournissent les chemins de la requête Architecture hybride Super-pairs: stockent l index de chemins global Topologie réseau super-pairs: arbre Pairs simples: stockent les données proprement dites Page 44

MediaPeer : topologie d arbre Super-pair «feuille» Indexe les chemins fournis par les pairs simples attachés Super-pair «interne» Union (optimisée) des chemins indexés par ses fils Index Patricia trié à précision variable Requête Adressée au super-pair parent Routage ascendant jusqu à la racine Routage descendant possible à partir d un nœud interne Équilibrage de charge Éclatement super-pairs trop chargés Panne d un super-pair Chemins alternatifs de routage pair simple super-pair Page 45

MediaPeer: conclusions Avantages Recherche efficace, routage rapide Passage à l échelle: éclatement nœuds trop chargés Réorganisation rapide en cas de panne Inconvénients Racine trop chargée Alternative Organiser les super-pairs en DHT PathFinder Page 46