Plan du cours. Autres modèles pour les applications réparties Introduction. Mode de travail. Introduction

Transcription

1 Plan du cours Autres modèles pour les applications réparties Introduction Notre terrain de jeu : les systèmes répartis Un rappel : le modèle dominant Client-serveur Etudes de deux autres modèles Mobilité du code Partage de données 2 Mode de travail Les 8 semaines 1. Introduction 2. Agents mobiles 3. Projets agents mobiles 4. Projets agents mobiles 5. Objets partagés 6. Projets objets partagés 7. Projets objets partagés 8. Evaluation Document écrit de synthèse Introduction 3 4

2 Plan Les systèmes répartis Principe des systèmes répartis 5 6 Pourquoi des systèmes répartis? Autres cours de Master liés : Aspects économiques Réutilisation et partage d équipements A l origine : système d impression, espace de stockage Aujourd hui : CPU (grille de calcul) Besoin d intégration Partage d applications, partage d information, partage de ressources (programmes, données, services) Travail collaboratif Besoins spécifiques Diffusions d information Haute disponibilité Réalisation de systèmes à grande capacité d évolution Grid computing (D. Caromel, J. Montagnat) Middleware for Ubiquitous Computing (JY. Tigli, S. Lavirotte) Algorithmique pour les systèmes répartis (F. Baude, O. Dalle) Peer-to-peer (O. Dalle) Et sûrement d autres Adaptation de la structure d un système à celle des applications 7 8

3 Caractérisation d une application répartie Approche application répartie = traitements coopérants sur des données réparties Méthodes et outils de modélisation Modèle d exécution coopération = communication + synchronisation modèle d exécution interface de programmation (et/ou langage) outils de développement mise en œuvre : services systèmes (pour différentes infrastructures) outils de développement middleware Services applicatifs fichiers répartis, moniteur transactionnel, accès BD,... Services systèmes communication, RPC, désignation, sécurité,... outils d administration Système d exploitation 9 10 Machines et Réseaux Un système réparti c est Conséquences Ensemble d éléments (traitement, stockage) Processeurs, mémoires, organes d E/S Système d interconnexion Intégration (vue globale uniforme) "Transparence" Défaillances locales possibles (éléments ou communication)... sans compromettre nécessairement l ensemble du système Pas de temps global, ni d état global mais Possibilité de construire un état commun (partition + duplication) Coopération à une tâche commune Redondance permettant la reprise après erreur locale La répartition ne peut pas être cachée : Conséquences négatives la panne d une machine distante inconnue peut m empêcher de travailler (si récupération non prévue) la panne du système de communication m empêche de savoir si la machine distante est arrêtée ou déconnectée Conséquences positives Offre la possibilité d augmenter la disponibilité des services et des informations par utilisation de la réplication l autonomie des utilisateurs par le fonctionnement de manière isolé (réplication / cache / ) Redondance nécessaire (matériel, traitements, données) Pour corriger les conséquences négatives Offrir les conséquence positives 11 12

4 Quelques domaines d application des systèmes répartis Besoins des applications CFAO, Ingénierie simultanée Coopération d équipes pour la conception d un produit Production coopérative de documents, partage cohérent d information Gestion intégrée des informations d'une entreprise Intégration de l existant Contrôle et organisation d activités en temps réel Système de production Centres de documentation, bibliothèques Recherche, navigation, visualisation multimédia Systèmes d aide à la formation E-Learning (LMS) Ouverture Interopérabilité, portabilité, fédération ; réutilisation de l existant Coopération, coordination, partage Vision commune cohérente d informations partagées (globalement, par groupes) Interaction en temps réel, support multimédia Transparence Accès (mobilité des usagers avec préservation de l environnement) Localisation (de l information, des services,...) Qualité de service Disponibilité, délais, coûts, qualité de perception,.. avec niveau garanti Sécurité Authentification, intégrité, confidentialité,... Evolutivité, administrabilité Reconfiguration, gestion dynamique de services Evolution historique Evolution de l architecture des systèmes répartis Année Travaux 1970 Stations de travail + serveurs, Ethernet 1980 Mémoire stable, Appel de procedure à distance Fichiers Unix répartis 1985 Micro-noyaux Serveurs de fichiers évolués 1990 Systèmes transactionnels répartis Grands systèmes intégrés 2000 Systèmes répartis à objets Travail coopératif Support système pour multimédia RPCgen, NFS Chorus, MacOS Coda Emerald, DCE Guide, CORBA Schéma de base : le modèle client-serveur Modèle primitif (messages) Modèle évolué (appel de procédure à distance) Demande de service, gestion de fichiers Serveurs coopérants Interface serveur unique Autres modèles : c est l objet de ce cours connaître les points forts / faibles avoir des éléments de comparaison 2005 Grille de calcul Globus 15 16

5 Exemple de problèmes Après le problème, les solutions Je vais passer en 5ème année et voudrait travailler plus tard dans le monde du jeu vidéo. Pour mettre toutes les chances de mon côté, j'ai entreprit de faire mon propre jeu pour avoir quelque chose de vraiment concret. J'aimerai faire un mode multi-joueur en ligne. Les données graphiques seront conservée du coté du client. Je voulais faire un un webservice en C# (mon jeu est codé en C# avec XNA) mais mon hébergeur ne supporte pas ce langage. Voici les 3 solutions auxquelles j ai pensé et J'aimerai savoir laquelle offre les meilleurs performances : 1. Un webservice en php hébergé sur mavenhost avec création d'une classeroom contenant les données de chaque joueur. Ces données sont modifiées par l'appel de méthode par les joueurs et à chaque tour de boucle, ce webservice envoie aux joueurs toutes les données nécessaire. Cette solution dépend-elle du nombre de joueurs? Et, quelle pourrait être probablement la limite du nombre de joueurs? 2. Les données sont directement récupérées et envoyées à partir d'une base de données hébergée sur mavenhost. Sachant que chaque appel se fait 60 fois par secondes, cette méthode me semble peu souple et surtout peuperformante 3. Enfin, celle qui me semble la plus efficace. Un joueur se porte comme serveur (temporaire) lors de la création d'une partie. Ainsi, cette méthode dépend entièrement de la connexion du joueur. Mais on peut imaginer que avec les modems d'aujourd'hui et surtout la faible taille des données que cette solution pourrait être la plus performante La solution? Voila, si vous avez d'autres solutions, je suis preneur ou si vous avez des questions quelconque, n'hésitez pas. Quelles peuvent être les critères de choix? 1. Identication des services à offrir 2. Identification d un modèle d architecture 3. Identification des principaux coûts (nbre de message, tailles des messages, ) 4. Choix d une technologie Evolution des concepts de base 19 20

6 Evolution des concepts de base des systèmes répartis Schémas de communication primitif modèle «asynchrone» Echange d information entre site Envoie de message Appel de procédure à distance Association processus site d exécution Gestion des informations Communication asynchrone : Désignation directe du récepteur : processus Désignation indirecte du récepteur : portes liaison dynamique récepteurs multiples "équivalents» Peu structurant (cf. goto dans les langages de programmation) Outils de développement peu évolués et de bas niveau send(m,p) m p recv(p):m recv(p):m Schémas de communication primitif modèle «asynchrone» Extension du modèle «asynchrone» Exemples Utilisation d UDP ou TCP (interface socket sur le niveau transport) primitives de communication élémentaires ("envoyer", recevoir") : Utilisé dans Architecture de type micro-noyau : Chorus, Mach Environnement de programmation parallèle : PVM, MPI Intergiciel à message (MOM) : JMS Attention la plupart des implémentations de JMS nécessitent tout JEE Solution open source : Joram ( Modèle d acteurs Communication de groupe groupe : ensemble de récipiendaires identifiés par un nom unique gestion dynamique du groupe : arrivée/départ de membres différentes politiques de service dans le groupe : 1/N, N/N mise en œuvre : utilisation possible de IP multicast exemple : Isis, Horus, Ensemble (Cornell university) applications : tolérance aux fautes (gestion de la réplication), travail coopératif Communication anonyme désignation associative : les récipiendaires d'un message sont identifiés par leurs propriétés et pas par leur nom propriété : attribut du message ou identificateur externe indépendance entre émetteur et récepteurs 23 24

7 Extension du modèle «asynchrone» Le modèle dominant : communication «synchrone» Processus émetteurs 25 Communication événementielle concepts de base : événements, réactions (traitements associés à l occurrence d un événement) principe d attachement : association dynamique entre un nom d événement et une réaction communication anonyme : indépendance entre l émetteur et les consommateurs d un événement Deux modes «push» / «pull» Nom (type) d'événement événements canaux de communication Processus réactions destinataires 26 appel de procédure à distance Meilleure structuration : passage du goto à l appel de procédure serveur identifié statiquement ou déterminé dynamiquememt Extension objet (appel de méthode) Exemples RPCgen (travaux d origine) Corba Java RMI.Net Remoting Web Service f(param) exécution de f Le modèle «synchrone» - RPC Architecture Le modèle «synchrone» - RPC Principe de développement Site appelant (client) Site appelé (serveur) Modèle de panne 27 appel Pg. client retour emballage envoi (req., param.) < attente > réception (résultats) déballage talon client lib. com. messages lib. com. Communication physique communication logique récept.(req., param) déballage emballage envoi (résultats) talon serveur exécution procédure Pg. serveur 28 pg. source client définition interfaces (IDL) pg. source serveur Station 2 compilateur IDL talon client talon serveur Compilateur + ed. liens bibliothèques compilateur + ed. liens Station 1 pg. exec. client pg. exec. serveur

8 Extension au modèle «synchrone» RPC Extension au modèle «synchrone» RPC RPC One-way Le client n attend pas de réponse du serveur pourquoi le faire attendre? Dans ce modèle le client continu son activité après avoir appelé le serveur Exemple : Corba oneway RPC Asynchrone Le client n utilise pas immédiatement la réponse du serveur, il peut continuer son activité après avoir appelé le serveur Problème : comment récupéré les résultats Solution : utilisation d un futur - une structure de donnée (un objet) permettant de récupérer des résultats Futur explicite : Les structures de données sont définies par le client avant l appel (le serveur les connaait et y dépose les résultats). Exemple : mécanisme du callback en.net, d une boite aux lettre en ACT++ BAL := factorielle.calculfact(n) ; resultat := BAL.prelever() Futur implicite : La lecture de la structure de donnée résultat bloque le client s'il accède à la réponse et que celle-ci n'est pas parvenue Exemple : Resultat := factorielle.calculfact(n) Extension au modèle «synchrone» RPC Peut-on inventer d autres solutions RPC synchrone sur groupe (autre nom RPC diffusé, RPC parallèle) 31 32

9 Evolution de la gestion de l exécution Liaison processus-processeur (site) Migration de processus Liaison «statique» entre un processus et son site d exécution Et si on remet en cause ce principe? Association dynamique Migration de processus Usuellement l émetteur, le destinataire d un message ne se déplace pas Migration de l émetteur : agents mobiles Migration du serveur Plein de problèmes nouveaux Quand? Comment? Ou? site1 site2 Migration de l émetteur (agent mobile) Généralement vers le site du serveur A des moments privilégié (migration faible) à tout instant (migration forte) Objectifs : favoriser les échanges locaux Migration du récepteur Généralement pour faire de la régulation de charge, arrêter le site pour maintenance Objectifs : améliorer le temps de réponse Migration de processus Problèmes Transfert du code/données du processus Transfert du contexte du processus Utilisation de ressources ou d informations liées à un site Récupération des messages reçus pendant transfert Extension : diffusion de processus Activité multi-sites (il reste une trace sur le site origine) site1 migration diffusion lien site2 Mise en œuvre de la migration à l aide d agents mobile Ce sera l objet des 3 prochaines semaines Cours 2 : Pourquoi? Comment? Quelle plate-forme TP 1 et 2 Découverte d une plate-forme rudimentaire Extension de la plate-forme Utilisation dans un exemple 35 36

10 Evolution de la gestion de l exécution Liaison données-processeur (site) Migration de données Liaison «statique» entre des données et leur site Usuellement les données ne se déplacent pas C est le flot d exécution qui vient à elle Exemple dans le cadre des architecture client-serveur clients serveurs) : Serveur SQL Site Web Et si on remet en cause ce principe? Association dynamique Migration de données Pourquoi? Favoriser les échanges locaux (cache) site1 site2 Permettre de pouvoir traiter les donner localement en l absence de connexion Tolérer les pannes (réplication) Il ne reste par de copie sur le site d origine Motivations Répartition de la charge Amélioration du temps de réponse local Problèmes Localisation de la données Il reste une copie de la donnée sur le site d origine Motivations Répartition de la charge Amélioration du temps de réponse local Réplication de données Tolérances aux pannes Problèmes Gestion de la cohérence entre réplicats Reprise après pannes site3 site1 site1 site2 site3 site Mémoire partagée / Objets partagées Comment choisir entre tous ces modèles Ce sera l objet des 3 prochaines suivantes Cours 3 TP 3 et 4 A vous de jouer Semaine 8 Objet de l évaluation Sur un exemple donné il faudra motiver votre choix à partir des éléments donnés en cours. En précisant les hypothèses En décrivant l architecture et sa mise en œuvre et en justifiant Performance Facteur d échelle Tolérance aux pannes Mode déconnecté Etc. En décrivant dans la mise en œuvre comment vous avez traiter ou non les problèmes liés : À la concurrence À la protection À la sécurité Àux pannes Etc

11 Techniques utiles pour la construction de systèmes répartis Facteurs de taille Duplication pour augmenter disponibilité Exploiter les informations invariantes Délais de garde time out (incertitude sur état distant ou système de communication) Caches pour exploiter la localité de référence Utilisation d indications (si valide, gain de temps ; sinon, détection assurée) combinaison des 2 derniers : indicateurs en cache Utilisation d un mécanisme standard d appel distant appel synchrone + parallélisme local Compromis entre donnée locale (dupliquée) et cohérence On peut parfois travailler sur des données non à jour Ne faire confiance qu aux machines physiquement protégées Utilisation d algorithmes repartis standard (prouvés) En particulier dans la diffusion (fiable), les consensus Qu est ce qu un grand système réparti? Nombre d entités Nombre de composants (machines, réseaux,...) Nombre d utilisateurs Nombre (taille, complexité) des informations conservées Etendue géographique Nombre d organisations responsables Facteurs de taille Effet des facteurs de taille Propriétés recherchées : capacité de croissance algorithmes (localisation, recherche d information, communication) maîtrise de la complexité Toute recherche de solution doit reposer sur la connaissance des qualités de l algorithme (même évalué de manière sommaire) Sur la connaissance de la taille du problème à résoudre Une solution peut être excellente pour une taille donnée et catastrophique pour une autre situation Toujours «calibrer» le problème et sa solution Propriétés (globales) du système influencées par la taille La composition instantanée du système n est pas connue Les informations ne sont pas cohérentes Le système est hétérogène Il y a au moins un sous-système en panne ou inaccessible Les entités (machines, usagers, informations) sont mobiles Le système évolue en permanence 43 44

12 Problèmes liés à la taille Quelles sont les architectures possibles? Désignation Décentralisation du service ; abandon des identificateurs universels Usage intensif des caches Réorganisation de l espace des noms Maîtrise des perfomances quantitatives et qualitatives Débits, temps de réponse, etc ; qualité de service Disponibilité Réplication des composants critiques Sécurité Petit nombre de composants critiques Authentification par cryptographie ; capacités Administration Complexité, hétérogénéité Etude de cas vente sur internet Travail à faire Annuaire Magasin 1 Magasin 2 Magasin 3 Liste de courses Demande de devis Commande Acheteur 1 Acheteur 2 Pour la semaine prochaine Etre au point sur le RPC (Java RMI en particulier) Former un binôme Définir une grille de comparaison qui va permettre de comparer les solution Appliquer la grille pour les solutions S intéresser plus aux modèles qu aux choix d une technologie Un même modèle peut être mis en œuvre par plusieurs technologies Envoie de message sans diffusion Envoie de message avec diffusion Les clients sont les acheteurs / les services sont les magasins Les clients sont les magasins / les serveurs sont les clients 47 48