Distributed Systems

Processes
Chapter 3

1
 Crédits de cours/diapositives
Remarque : toutes les présentations de cours sont basées
sur celles développées par Andrew S. Tanenbaum et
Maarten van Steen. Ils accompagnent leur manuel
"Distributed Systems: Principles and Paradigms" (1ère &
2ème éditions).
http://www.prenhall.com/divisions/esm/app/author_tane
nbaum/custom/dist_sys_1e/index.html
Et ajouts apportés par Paul Barry dans le cours CW046-4
: Systèmes distribués
http://glasnost.itcarlow.ie/~barryp/net4.html
2
 Processes - Processus
• La communication a lieu entre les processus .
• Mais qu'est-ce qu'un processus ? « Un programme
en cours d'exécution ».
• Systèmes d'exploitation traditionnels : concernés par
la gestion et l'ordonnancement « local » des processus.
• Systèmes distribués modernes : un certain nombre
d'autres questions sont d'égale importance.
• Il existe trois grands domaines d'études :
– Threads et virtualisation au sein des clients/serveurs
– Migration de processus et de code
3 – Agents logiciels
 Introduction aux Threads
• Les systèmes d'exploitation modernes fournissent des
« processeurs virtuels » dans lesquels les programmes
s'exécutent.
• Un environnement d'exécution de programmes est
documenté dans la table des processus et un PID lui
est attribué .
• Pour atteindre des performances acceptables dans les
systèmes distribués, s'appuyer sur l'idée d'un processus
du système d'exploitation n'est souvent pas suffisant –
une granularité plus fine est requise.
• La solution : Threading
4
 Problèmes avec les processus
• La création et la gestion de processus sont généralement
considérées comme une tâche coûteuse (appel système fork).
• Il n'est pas facile de s'assurer que tous les processus coexistent
pacifiquement sur le système (car la transparence de la
concurrence a un prix).
• Les threads peuvent être considérés comme une "exécution
d'une partie d'un programme (dans l'espace utilisateur)".
• Plutôt que de rendre le système d'exploitation responsable de la
transparence de la concurrence, il appartient à l' application
individuelle de gérer la création et la planification de chaque
thread.

5
 Implications importantes
• Deux implications importantes :
– Les applications threadées s'exécutent souvent plus
rapidement que les applications non threadées (car les
changements de contexte entre le noyau et l'espace
utilisateur sont évités).
– Les applications threadées sont plus difficiles à développer
(bien que des conceptions simples et propres puissent aider
ici).
• De plus, l'hypothèse est que l'environnement de
développement fournit une bibliothèque de threads
que les développeurs peuvent utiliser (la plupart des
environnements modernes le font).
6
 Utilisation des threads dans les systèmes
non distribués

Changement de contexte à la suite de l'IPC

7
 Implémentation des threads

Combinaison de processus légers au niveau du Kernel - noyau et

les threads au niveau utilisateur
8
 Threads dans les systèmes non distribués
• Avantages :
– Le blocage peut être évité
– Excellente prise en charge des systèmes
multiprocesseurs (chacun exécutant son propre
thread).
– Des changements de contexte coûteux peuvent être
évités.
– Pour certaines classes d'applications, la conception
et la mise en œuvre sont considérablement
facilitées.
9
 Threads dans les systèmes distribués
• Caractéristique importante : un appel
bloquant dans un thread n'entraîne pas
le blocage de l'ensemble du processus.
• Cela conduit à la caractéristique clé des threads
dans les systèmes distribués :
– « Nous pouvons désormais exprimer les
communications sous la forme de plusieurs
connexions logiques en même temps (par
opposition à un seul processus de blocage
séquentiel). »
10
 Exemple : Clients et serveurs MT
• Client multi-threadé : pour atteindre des niveaux
de performances perçues acceptables , il est souvent
nécessaire de masquer les latences de communication.
• Par conséquent, il existe une exigence pour démarrer
les communications tout en faisant autre chose.
• Exemple : navigateurs Web modernes.
• Cela conduit à la notion de « flux de données vraiment
parallèles » arrivant à une application cliente multi-
thread.

11
 Exemple : serveurs MT
• Bien que le threading soit utile sur les clients, il
est beaucoup plus utile dans les serveurs de
systèmes distribués.
• L'idée principale est d'exploiter le parallélisme
pour atteindre des performances élevées.
• Une conception typique consiste à organiser le
serveur en un seul « répartiteur » avec plusieurs
« travailleurs » threadés, comme illustré au
verso.
12
 Serveurs multithread (1)

Un serveur multithread organisé selon un modèle

13 répartiteur/travailleur
 Serveurs multithread (2)

Trois façons de construire un serveur

14
 Le rôle de la virtualisation dans les
systèmes distribués

• Organisation générale entre un programme, une interface et un

système
• Organisation générale de la virtualisation du système A au dessus
15 du système B
 Architectures de machines virtuelles (1)
• Il existe des interfaces à différents niveaux.
• Une interface entre le matériel et le logiciel,
constituée d'instructions machine
– qui peut être invoqué par n'importe quel
programme.
• Une interface entre le matériel et le logiciel,
constituée d'instructions machine
– qui ne peut être invoqué que par des programmes
privilégiés, comme un système d'exploitation.
16
 Architectures de machines virtuelles (2)
• Interface constituée d'appels système proposés
par un système d'exploitation.
• Une interface composée d'appels à la
bibliothèque
– formant généralement ce que l'on appelle une
interface de programmation d'applications (API).
– Dans de nombreux cas, les appels système
susmentionnés sont masqués par une API.

17
 Architectures de machines virtuelles (3)

Diverses interfaces offertes par les systèmes informatiques

18
 Architectures de machines virtuelles (4)

(a) Une machine virtuelle de processus, avec plusieurs

instances de combinaisons (application, exécution)
19
 La machine virtuelle Java

20
 Architectures de machines virtuelles (5)

(b) Un moniteur de machine virtuelle (VMM), avec

plusieurs instances de combinaisons (applications,
21 système d'exploitation).
 Types de VMM/Hypervisors

A type 1 hypervisor. (b) A type 2 hypervisor )a(

22
 VMware Architecture

23
 En savoir plus sur les clients
• Qu'est-ce qu'un client ?
• Définition : "Un programme qui interagit avec
un utilisateur humain et un serveur distant."
• En règle générale, l'utilisateur interagit avec le
client via une interface graphique.
• Bien sûr, les clients ne se limitent pas à fournir
une interface utilisateur. Rappelez-vous les
niveaux à plusieurs layers de l'architecture
client/serveur d'avant…
24
 Generic Client/Server Environment

25
 Generic Client/Server Architecture

26
 Client/Server Architecture for Database Applications

27
 Role of Middleware in Client/Server Architecture

28
 Interfaces utilisateur en réseau (1)

29 (a) Une application en réseau avec son propre protocole

 Interfaces utilisateur en réseau (2)

(b) Une solution générale pour permettre l'accès

30 aux applications distantes
 Example: The X Window System

31
The basic organization of the X Window System
 Logiciel côté client pour la transparence de
la distribution

Réplication transparente d'un serveur

32 en utilisant une solution côté client
 En savoir plus sur les serveurs
• Qu'est-ce qu'un serveur ?
• Définition : « Un processus qui met en œuvre
un service spécifique pour le compte d' un
ensemble de clients ».
• En règle générale, les serveurs sont organisés
pour faire l'une des deux choses suivantes :
• Attendre
• Service
– … attendez … service … attendez … service …
33 attendez …
 Serveurs : itératifs et simultanés
• Itératif : le serveur traite la requête, puis renvoie les
résultats au client ; toute nouvelle requête client doit
attendre la fin de la requête précédente (également
utile pour considérer ce type de serveur
comme séquentiel ).
• Concurrent : le serveur ne gère pas lui-même la
requête ; un thread ou un sous-processus distinct gère
la demande et renvoie tous les résultats au client ; le
serveur est alors libre de servir immédiatement le
client suivant (c'est-à-dire qu'il n'y a pas d'attente, car
les demandes de service sont traitées en parallèle ).
34
 États » du serveur «
• Serveurs sans état – aucune information n'est conservée sur
les « connexions » actuelles au serveur. Le Web est l'exemple
classique d'un service sans état . Comme on peut l'imaginer, ce
type de serveur est facile à mettre en œuvre.
• Serveurs avec état – les informations sont conservées sur les
« connexions » actuelles au serveur. Serveurs de fichiers
avancés, où les copies d'un fichier peuvent être mises à jour «
localement », puis appliquées au serveur principal (car il
connaît l'état des choses) - plus difficile à mettre en œuvre.
• Mais que se passe-t-il si quelque chose se bloque ? (plus à ce
sujet plus tard).

35
 ? »Problème : identifier les « end-points

• Comment les clients savent quel point final (ou

port) pour contacter un serveur? Comment font-
ils « lier » à un serveur?
– Points finaux affectés statiquement (IANA).
– Points d'extrémité attribués dynamiquement (DCE).
– Une variante populaire :
• le « super-serveur » (inetd sous UNIX).

36
 Problèmes de conception généraux (1)

(a) Liaison client-serveur à l'aide d'un Daemon

37
 Problèmes de conception généraux (2)

38 (b) Liaison client-serveur à l'aide d'un superserveur

 Un type spécial: Object Servers
• Un serveur conçu pour prendre en charge les
objets distribués.
• Ne fournit pas de service spécifique.
• Fournit une fonction par laquelle les objets
peuvent être appelés à distance par des clients
non locaux.
• Par conséquent, les serveurs d'objets sont
hautement adaptables.
• « Un lieu où vivent les objets »
39
 Object Adapter

Organisation d'un serveur objet supportant différents politiques

d'activation.
40 .
 Server Clusters (1)

41 L'organisation générale d'un cluster de serveurs à trois niveaux

 Server Clusters (2)

42 Le principe du transfert TCP

 Serveurs distribués

Optimisation de route dans un serveur distribué

43
 Gestion des clusters de serveurs

44 L'organisation de base d'un PlanetLab node

 PlanetLab (1)
• Problèmes de gestion de PlanetLab :
• Les nœuds appartiennent à des organisations différentes.
– Chaque organisation doit être autorisée à spécifier qui est autorisé à
exécuter des applications sur ses nœuds,
– Et restreignez l'utilisation des ressources de manière appropriée.
• Les outils de surveillance disponibles supposent une
combinaison très spécifique de matériel et de logiciel.
– Tous conçus pour être utilisés au sein d'une même organisation.
• Les programmes de tranches différentes mais s'exécutant sur le
même nœud ne doivent pas interférer les uns avec les autres

45
 PlanetLab (2)

Les relations de gestion entre les différentes entités de

46 PlanetLab
 PlanetLab (3)
• Relations entre les entités PlanetLab :
• Un propriétaire de nœud place son nœud sous le
régime d'une autorité de gestion, en restreignant
éventuellement l'utilisation le cas échéant.
• Une autorité de gestion fournit le logiciel nécessaire
pour ajouter un nœud à PlanetLab.
• Un fournisseur de services s'enregistre auprès d'une
autorité de gestion, lui faisant confiance pour fournir
des nœuds qui se comportent bien.

47
 PlanetLab (4)
• Un fournisseur de services contacte une autorité de
tranche pour créer une tranche sur un ensemble de
nœuds.
• L'autorité de tranche doit authentifier le fournisseur de
services.
• Un propriétaire de nœud fournit un service de création
de tranche à une autorité de tranche pour créer des
tranches. Il délègue essentiellement la gestion des
ressources à l'autorité de la tranche.
• Une autorité de gestion délègue la création de tranches
48 à une autorité de tranche.
 Process et Migration de Code
• Dans certaines circonstances, en plus du
passage habituel de données, le passage de
code (même pendant son exécution) peut
grandement simplifier la conception d'un DS.
• Cependant, la migration de code peut être
inefficace et très coûteuse.
• Alors, pourquoi migrer du code ?

49
 Raisons de la migration du code
• Pourquoi? La principale raison : de meilleures
performances .
• La grande idée est de déplacer une tâche à forte
intensité de calcul d'une machine fortement
chargée vers une machine légèrement
chargée « à la demande » et « au besoin ».

50
 Exemple de Process Migration

51
 Exemples de migration de code
• Déplacement (d'une partie) d'un client vers un serveur -
traitement des données à proximité de l'endroit où les données
résident. Il est souvent trop coûteux de transporter une base de
données entière vers un client pour traitement, alors déplacez le
client vers les données.
• Déplacement (partie) d' un serveur à un client - la vérification
des données avant de le soumettre à un serveur. L'utilisation de
contrôle d' erreur locale ( en utilisant JavaScript) sur
les formulaires Web est un bon exemple de ce type de
traitement. Vérifiez les données à proximité de l'utilisateur, pas
sur le serveur.

52
 » Exemple de migration de code « classique

• Recherche sur le Web en « itinérance ».

• Plutôt que de rechercher et d'indexer le Web en
demandant le transfert de chaque document au
client pour traitement, le client se déplace sur
chaque site et indexe les documents qu'il trouve
« in situ ». L'index est ensuite transporté d'un
site à l'autre, en plus du processus d'exécution.

53
 Un autre grand avantage : la flexibilité

Le principe de configuration dynamique d'un client pour communiquer avec un

serveur. Le client récupère d'abord le logiciel nécessaire, puis appelle le
54 serveur. Il s'agit d'une approche très flexible.
 Inconvénient majeur
• Problèmes de sécurité .
• "Être aveuglément confiant que le code
téléchargé implémente uniquement l'interface
annoncée tout en accédant à votre disque dur
non protégé et n'envoie pas les parties les plus
juteuses à « On ne sait où » n'est pas toujours
une si bonne idée".

55
 Modèles de migration de code
• Un processus en cours se compose de trois
« segments » :
– Code - instructions.
– Ressource – références externes.
– Exécution – état actuel

56
 Migration dans les systèmes hétérogènes
Trois façons de gérer la migration (qui peuvent être combinées) :
1.Pousser les pages mémoire vers la nouvelle machine et
renvoyer celles qui sont modifiées ultérieurement au
cours du processus de migration.
2.Arrêt de la machine virtuelle actuelle ; migrez la
mémoire et démarrez la nouvelle machine virtuelle.
3.Laisser la nouvelle machine virtuelle extraire de
nouvelles pages selon les besoins, c'est-à-dire laisser les
processus démarrer immédiatement sur la nouvelle
machine virtuelle et copier les pages de mémoire à la
demande.
57
 Caractéristiques de migration de code
• Faible mobilité : seul le code est déplacé – et il repart
toujours de son état initial.
– par exemple, les applets Java.
– Remarque : mise en œuvre simple, mais applicabilité
limitée.
• Forte mobilité : le code et l' état sont déplacés – et
l'exécution redémarre à partir de l'instruction suivante.
– par exemple, D'Agents.
– Commentaire: très puissant, mais difficile à mettre en
œuvre.

58
 Plus de caractéristiques
• Sender-Initiated vs. Receiver-Initiated.
• Quel côté de la communication démarre la
migration ?
1. La machine qui exécute actuellement le code
(appelée Sender-Initiated)
2. La machine qui exécutera finalement le code
(connue sous le nom de Receiver-initiated ).

59
 ? Comment fonctionne le code migré
• Un autre problème concerne l'endroit où le
code migré s'exécute :
1. Au sein d'un processus existant (éventuellement
en tant que thread)
2. Dans son propre (nouvel) espace de processus.
• Enfin, la mobilité forte supporte également la
notion de « clonage à distance » : une copie
exacte du processus d'origine, mais
fonctionnant désormais sur une autre machine.
60
 Modèles pour la migration de code

Alternatives pour la migration de code

61
 ? Qu'en est-il des ressources
• C'est délicat .
• Ce qui rend la migration de code difficile, c'est
la nécessité de migrer les ressources.
• Les ressources sont les références
externes qu'un processus utilise actuellement et
incluent (mais sans s'y limiter) :
– Variables, fichiers ouverts, connexions réseau,
imprimantes, bases de données, etc...

62
 Types de liaison processus-ressource
• Le plus fort : Binding-by-Identifier (BI) -
précisément la ressource référencée, et rien
d'autre, doit être migrée.
• Binding-by-Value (BV) – plus faible que BI,
mais seule la valeur de la ressource doit être
migrée.
• Le plus faible : Binding-by-Type (BT) – rien
n'est migré, mais une ressource d'un type
spécifique doit être disponible après la
63 migration (par exemple, une imprimante).
 Plus sur la classification des ressources
• Les ressources sont en outre distinguées comme l'une
des suivantes :
– Non attaché : une ressource qui peut être déplacée
facilement d'une machine à l'autre.
– Fixé : la migration est possible, mais à un coût élevé.
– Corrigé : une ressource est liée à une machine ou un
environnement spécifique, et ne peut pas être migrée.
• Reportez-vous au diagramme suivant pour un bon
résumé des caractéristiques de la ressource à la liaison
(pour savoir quoi faire avec quelle ressource quand ).

64
 Migration et Resources Local

Actions à mener vis-à-vis des références aux

ressources locales lors de la migration du code
65 vers une autre machine
 Migration dans les DS hétérogènes

3-15

Utilisation d'une pile de migration : principe de maintien d'une pile de migration pour prendre en
charge la migration d'un segment d'exécution dans un environnement hétérogène. Nécessite
généralement des modifications du langage de programmation et de son environnement.
66
 Présentation de la migration de code dans D'Agents (1)

proc factorial n {
if ($n  1) { return 1; } # fac(1) = 1
expr $n * [ factorial [expr $n – 1] ] # fac(n) = n * fac(n – 1)
}
set number … # tells which factorial to compute
set machine … # identify the target machine

agent_submit $machine –procs factorial –vars number –script {factorial $number }

agent_receive … # receive the results (left unspecified for simplicity)

Un exemple simple d'un agent soumettant un script à une machine

distante (adapté de [Gray 95])
67
 Présentation de la migration de code dans D'Agents (2)
all_users $machines
proc all_users machines {
set list "" # Create an initially empty list
foreach m $machines { # Consider all hosts in the set of given machines
agent_jump $m # Jump to each host
set users [exec who] # Execute the who command
append list $users # Append the results to the list
}
return $list # Return the complete list when done
}
set machines … # Initialize the set of machines to jump to
set this_machine # Set to the host that starts the agent
# Create a migrating agent by submitting the script to this machine, from where
# it will jump to all the others in $machines.
agent_submit $this_machine –procs all_users
-vars machines
-script { all_users $machines }
agent_receive … #receive the results (left unspecified for simplicity)

Un exemple d'un agent Tel dans D'Agents migrant vers différentes

machines où il exécute la commande UNIX who.
68
 Problèmes de mise en œuvre (1)

69 L'architecture du système D'Agents

 Problèmes de mise en œuvre (2)

Description Status

Variables nécessaires à l'interpréteur d'un agent Global interpreter variables

Codes de retour, codes d'erreur, chaînes d'erreur, etc . Global system variables

Variables globales définies par l'utilisateur dans un

Global program variables
programme

Définitions des scripts à exécuter par un agent Procedure definitions

Pile de commandes en cours d'exécution Stack of commands

Pile d'enregistrements d'activation, un pour chaque commande

Stack of call frames
en cours d'exécution

70 Les pièces composant l'état d'un agent dans D'Agents.

 Agents logiciels
• Qu'est-ce qu'un agent logiciel ?
– « Une unité autonome capable d'exécuter une tâche
en collaboration avec d'autres agents (peut-être à
distance) ».
• Le domaine des agents logiciels est encore
immature et il existe de nombreux désaccords
sur la manière de définir ce que nous entendons
par eux.
• Cependant, plusieurs types peuvent être
71 identifiés.
 Types d'agents logiciels
1. Agent collaboratif – également connu sous le nom de
« systèmes multi-agents », qui peuvent travailler
ensemble pour atteindre un objectif commun (par
exemple, planifier une réunion).
2. Agent mobile – code qui peut être déplacé et
continuer à s'exécuter sur une machine distante.
3. Agent d'interface – un logiciel doté de « capacités
d'apprentissage »
4. Agent d'information – agents conçus pour collecter et
traiter des données et des informations dispersées
géographiquement.
72
 Agents logiciels dans les systèmes distribués

Common to
Description Property
all agents?

Peut agir seul Oui Autonome

Répond en temps opportun aux changements de son

Oui Réactif
environnement

Initiés actions qui affectent son environnement Oui Proactif

Peut échanger des informations avec les utilisateurs et d'autres

Oui Communicatif
agents

A une durée de vie relativement longue Non Continu

Peut migrer d'un site à un autre Non Mobile

Capable d'apprendre Non Adaptatif

Quelques propriétés importantes par lesquelles différents

73 types d'agents peuvent être distingués.
 Technologie des agents - Normes
• Le modèle général d'une plateforme d'agents a
été standardisé par la FIPA (« Foundation for
Intelligent Physical Agents ») située à l'
adresse http://www.fipa.org
• Les spécifications comprennent :
– Composant de gestion des agents.
– Service d'annuaire d'agents.
– Canal de communication des agents.
– Langage de communication des agents.
74
 Agent Technology

Le modèle général d'une plateforme d'agents (adapté de [FIPA

75 1998])
 Langues de communication des agents (1)

Message Content Description Message purpose

Proposition Inform that a given proposition is true INFORM

Proposition Query whether a given proposition is true QUERY-IF

Expression Query for a give object QUERY-REF

Proposal specifics Ask for a proposal CFP

Proposal Provide a proposal PROPOSE
Proposal ID Tell that a given proposal is accepted ACCEPT-PROPOSAL
Proposal ID Tell that a given proposal is rejected REJECT-PROPOSAL
Action specification Request that an action be performed REQUEST
Reference to source Subscribe to an information source SUBSCRIBE

Des exemples de différents types de messages dans la LCA APIE [1998 APIE], donnant
76 but d'un message, ainsi que la description du contenu réel du message
 Langues de communication des agents (2)

Value Field

INFORM Purpose

max@http://fanclub-beatrix.royalty-spotters.nl:7239 Sender

elke@iiop://royalty-watcher.uk:5623 Receiver

Prolog Language

genealogy Ontology

female(beatrix),parent(beatrix,juliana,bernhard) Content

Un exemple simple de message FIPA ACL envoyé entre deux agents utilisant
Prolog pour exprimer des informations généalogiques.
77