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

(1)

Riveill@unice.fr http://rangiroa.polytech.unice.fr

Autres modèles pour les applications réparties Introduction

Plan du cours

mise à jour septembre 2010 2



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

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

(2)

Plan



Les systèmes répartis

Principe des systèmes répartis

Pourquoi des systèmes répartis ?

 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

 Adaptation de la structure d’un système à celle des applications

Autres cours de Master liés :



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

(3)

Caractérisation d’une application répartie



application répartie = traitements coopérants sur des données réparties



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)

Approche

Services applicatifs

fichiers répartis, moniteur transactionnel, accès BD, ...

Services systèmes

communication, RPC, désignation, sécurité, ...

Système d’exploitation Machines et Réseaux outils

de développement

outils d’

administration middleware

Modèle d’exécution Méthodes et outils

de modélisation

Un système réparti c’est…



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

Conséquences

 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

(4)

Quelques domaines d’application des systèmes répartis



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)

Besoins des applications

 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

Année Travaux

1970 Stations de travail + serveurs, Ethernet 1980 Mémoire stable, Appel de procedure à distance

Fichiers Unix répartis

RPCgen, NFS

1985 Micro-noyaux Serveurs de fichiers évolués

Chorus, MacOS Coda 1990 Systèmes transactionnels répartis

Grands systèmes intégrés

Emerald, DCE

2000 Systèmes répartis à objets Travail coopératif

Support système pour multimédia

Guide, CORBA

2005 Grille de calcul Globus

Evolution de l’architecture des systèmes répartis



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

(5)

Exemple de problèmes



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.

Après le problème, les solutions…

 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

(6)

Evolution des concepts de base des systèmes répartis



Echange d’information entre site



Envoie de message



Appel de procédure à distance



Association processus – site d’exécution



Gestion des informations

Schémas de communication primitif modèle « asynchrone »



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 »



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 (http://joram.ow2.org)

 Modèle d’acteurs

Extension du modèle « asynchrone »

 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

(7)

Extension du modèle « asynchrone »

 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 »

canaux de communication

événements réactions

Processus émetteurs

Processus destinataires Nom (type)

d'événement

Le modèle dominant : communication « synchrone »



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

Site appelé (serveur) appel

emballage envoi (req., param.)

< attente >

réception (résultats) déballage retour

messages

récept.(req., param) déballage

exécution procédure emballage

envoi (résultats) Site appelant (client)

Communication physique communication logique

talon client talon serveur

Pg.

client

Pg.

serveur lib.

com.

lib.

com.

Station 2

Station 1

Le modèle « synchrone » - RPC Principe de développement

pg. source client définition interfaces (IDL) pg. source

serveur

compilateur IDL

talon client

talon serveur

Compilateur

+ ed. liens pg. exec.

client

pg. exec.

serveur compilateur

+ ed. liens bibliothèques Modèle

de panne

(8)

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

Extension au modèle « synchrone » RPC



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



RPC synchrone sur groupe (autre nom RPC diffusé, RPC parallèle)

Peut-on inventer d’autres solutions…

(9)

Evolution de la gestion de l’exécution Liaison processus-processeur (site)



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 processus



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) ^lien

migration

site1 site2

diffusion



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

(10)

Evolution de la gestion de l’exécution Liaison données-processeur (site)

 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)

 Permettre de pouvoir traiter les donner localement en l’absence de connexion

 Tolérer les pannes (réplication)

 …

site1 site2

Migration de données

 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

site1 site2

site3

Mémoire partagée / Objets partagées



Ce sera l’objet des 3 prochaines suivantes



Cours 3



TP 3 et 4

Comment choisir entre tous ces modèles

 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

 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

Facteurs de taille



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



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

Effet des facteurs de taille



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

(12)

Problèmes liés à la taille

 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é

Quelles sont les architectures possibles ?

Etude de cas – vente sur internet…

Annuaire

Acheteur 1 Acheteur 2

Magasin 1 Magasin 2 Magasin 3

Liste de

courses Demande de devis

Commande

Travail à faire



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