1.1 Communication inter

Copyright (C) 1997-2007. JM Rodriguez. Tous droits réservés. Reproduction interdite par tous moyens sauf à des
fins de citation.
1.1 Communication inter-groupes
Un groupe est un ensemble de processus formant une entité unique. Un message envoyé
à ce groupe sera reçu par tous les membres du groupe au même moment.
Un groupe est un ensemble de processus qui travaille ensemble.
Un groupe comporte des processus qui agissent ensemble pour les besoins du système
ou de l'utilisateur.
Dans le cas de serveurs de fichiers comprenant plusieurs machines (tolérance de
pannes) est préférable d'adresser un message à tous les serveurs en même temps.
RPC établit une communication entre deux processus. RPC ne peut pas transmettre
un message simultanément à plusieurs processus.
Ce dernier type de communication est appelé « un à plusieurs » (one-to-many).
La figure suivante représente les deux types d'échanges :
Les groupes sont dynamiques, ils sont créés détruits et modifiés.
Un processus peut rejoindre un groupe ou le quitter, il peut être membre de plusieurs
groupes.
Le mécanisme de groupe apporte un niveau d'abstraction permettant la transparence des
systèmes répartis.
La communication de groupe dépend des possibilités du matériel. Il existe trois
méthodes :
1. Multicasting.
2. Broadcasting.
3. Unicasting.
Jean-Michel Rodriguez
Systèmes et applications répartis
2002-2007
Copyright (C) 1997-2007. JM Rodriguez. Tous droits réservés. Reproduction interdite par tous moyens sauf à des
fins de citation.
1.1.1 Les caractéristiques de la réalisation
1.1.1.1 Groupe ouvert et groupe fermé
Le groupe ouvert peut communiquer avec des processus qui ne sont pas membres du
groupe.
Le groupe fermé ne communique pas avec des processus qui ne sont pas membres du
groupe.
La figure suivante représente les deux types de groupe. L'utilisation du système décidera
de l'utilisation des groupes.
1.1.1.2 Groupe hieréarchique ou égalitaire
L'organisation interne du groupe peut être d'égal à égal ou hiérarchique.
Dans une organisation d'égal à égal, le premier type la communication est en réseau, il
n'y a pas de point unique de panne, en cas de panne le mécanisme d'élection détermine
le successeur, ce mécanisme impacte les performances.
Dans une organisation hiérarchique, il existe une hiérarchie à un niveau. Ici une panne
du coordinateur a un impact plus important, le groupe est bloqué.
Jean-Michel Rodriguez
Systèmes et applications répartis
2/10
2002-2007
Copyright (C) 1997-2007. JM Rodriguez. Tous droits réservés. Reproduction interdite par tous moyens sauf à des
fins de citation.
1.1.2 Gestion des groupes
La méthode centralisée avec un serveur de groupes n'est pas souhaitable car elle
entraîne un Single Point of Failure (SPF).
La gestion distribuée est la solution.
Pour rejoindre le groupe l'impétrant envoie un message et les listes sont mises à jour.
Pour quitter le groupe un message et envoyé aux membres qui mettent à jour les listes
(mécanismes pour les groupes fermés).
Le problème réside dans les pannes des machines des membres du groupe, il faut faire
la différence entre la panne et quitter le groupe.
1.1.3 L'adressage du groupe par les processus
Nous avons vu le multicasting, le bradcasting et le unicasting, les noyaux déterminent
les machines adressées.
Il y a deux autres méthodes.
• Le processus qui envoie le message envoie l'adresse de tous les membres du
groupe. Il faut maintenir la liste des adresses de tous les membres.
• La sélection, à partir d'un prédicat dans le message par le processus permet aux
autres machines du groupe ou du système complet de prendre le message ou pas.
1.1.4 Atomicité
L'atomicité ou le broadcast atomique contient le principe de la transaction atomique : le
message est reçu pour tous les membres du groupe ou il n'est pas reçu.
1.1.5 Ordre des messages
II y a plusieurs principes qui guident l'acheminement des messages aux destinataires :
• L'ordre global dans le temps permet à tous les membres du groupe de recevoir
les messages dans l'ordre où ils ont été émis.
Jean-Michel Rodriguez
Systèmes et applications répartis
3/10
2002-2007
Copyright (C) 1997-2007. JM Rodriguez. Tous droits réservés. Reproduction interdite par tous moyens sauf à des
fins de citation.
•
L'ordre cohérent dans le temps permet à tous les membres du groupe de recevoir
les messages dans le même ordre.
On constatera que l'ordre des messages devient plus subtil lorsque des processus
sont membres de plusieurs groupes.
Jean-Michel Rodriguez
Systèmes et applications répartis
4/10
2002-2007
Copyright (C) 1997-2007. JM Rodriguez. Tous droits réservés. Reproduction interdite par tous moyens sauf à des
fins de citation.
2 La synchronisation dans les systèmes répartis
Nous avons vu comment les processus communiquent dans un système réparti (RPC,
communication de groupes, etc.).
La communication entre processus est importante, mais il faut voir aussi :
• Comment ils coopèrent.
• Comment ils se synchronisent les uns les autres.
Dans un système centralisé, les problèmes de synchronisation sont résolus par des
sémaphores :
• Régions critiques.
• Exclusion mutuelle.
Dans les systèmes répartis, le fait qu’il n’y ait pas de mémoire partagée, les
sémaphores (variables partagées) ne peuvent pas exister.
Dans le cadre des systèmes répartis, c’est ce que nous allons étudier au travers de :
• La synchronisation des horloges.
• L’exclusion mutuelle.
• Les algorithmes d’élection.
• Les transactions atomiques et les mémoires stables.
Jean-Michel Rodriguez
Systèmes et applications répartis
5/10
2002-2007
Copyright (C) 1997-2007. JM Rodriguez. Tous droits réservés. Reproduction interdite par tous moyens sauf à des
fins de citation.
2.1 La synchronisation des horloges
La synchronisation dans un système réparti pose plus de difficultés que celle d'un
système centralisé car des algorithmes répartis vont l'établir. Ces / algorithmes ont les
propriétés suivantes :
1. Les informations pertinentes sont réparties sur plusieurs.
2. Les processus décident à partir d'informations locales.
3. Il ne doit pas y avoir un seul point faible, point unique de panne, dans le
système.
4. Il n'y a pas d'horloge commune ou de source de temps précis.
Pour comprendre la nécessité de la synchronisation des horloges il suffit d'envisager une
opération make du compilateur sur un système réparti (figure ci-dessous). La mise à jour
des fichiers programmes se décide à partir de l'heure de la dernière modification, si les
horloges sont déphasées des mises à jours inutiles seront faites chargeant le système
inutilement.
FICHIER.O plus récent que FICHIER.C, les modifications de FICHIER.C ne sont pas
pris en compte. FICHIER.C est modifié mais non compilé.
2.1.1 Les horloges logiques
Tous les ordinateurs ont une horloge (timer) physique qui est un oscillateur au quartz.
Le compteur logique (counter) et le registre (holding register) sont associés au timer
(quartz). Chaque oscillation diminue le compteur de 1, lorsqu’il est à 0 le compteur
génère une interruption, puis il prend le contenu du registre (holding register) et ça
recommence. Ainsi on peut facilement programmer des interruptions : x fois par
seconde (clock tick).
À chaque interruption, la procédure d'interruption ajoute un à la valeur du temps dans
une mémoire, ainsi l'horloge logicielle est mise à jour.
Jean-Michel Rodriguez
Systèmes et applications répartis
6/10
2002-2007
Copyright (C) 1997-2007. JM Rodriguez. Tous droits réservés. Reproduction interdite par tous moyens sauf à des
fins de citation.
Aucune structure répartie ne pourra maintenir les horloges physiques synchronisées. Les
faibles variations des oscillateurs seront répercutées et très vite les machines seront
déphasées.
Les horloges logiques, dont l’algorithme de Lamport, se sont imposées car il est
possible de les ajuster régulièrement. L'horloge logique se base sur la suite
d’évènements où l’un arrive avant l’autre, avec une relation : « arrivé avant » = a d b
qui signifie que l’évènement a est arrivé avant l’évènement b.
2.1.1.1 L'algorithme de Lamport
L'algorithme de Lamport associé au temps logique C() permet de synchroniser les
horloges des différentes machines du système réparti.
Voici les règles de l'algorithme :
• Si a d b alors C(a) < C(b)
• Si a et b représentent l'envoi d'un message et la réception d'un message alors
C(a) < C(b).
• Si ce n'est pas le cas réellement pour les horloges alors l'algorithme ajustera par
C(b) = C(a) + 1, en modifiant aussi l'horloge, pour tous les événements a et b
alors C(a) est différent de C(b).
Voir la figure ci-dessous :
Les processus s’exécutent sur des machines différentes.
Les horloges sont différentes :
• Quand l’horloge de 1 a tické 10 fois, celle de 2 a tické 15 fois et celle de 3 a
tické 20 fois.
Jean-Michel Rodriguez
Systèmes et applications répartis
7/10
2002-2007
Copyright (C) 1997-2007. JM Rodriguez. Tous droits réservés. Reproduction interdite par tous moyens sauf à des
fins de citation.
2.1.2 Les horloges physiques et leur synchronisation
Lamport permet d’établir un ordre logique entre processus, mais dans les systèmes à
temps réel le temps précis (absolu) est nécessaire, il faut donc aller au-delà de
l'algorithme de Lamport pour synchroniser le système.
Les mécanismes de synchronisation reposent sur un modèle général.
Chaque machine a son horloge qui renvoie régulièrement les interruptions enregistrées
par l’horloge logicielle, avec une origine, régulièrement cette horloge est comparée au
temps universel (nombres d’interruptions écoulées), si la différence reste dans une
fenêtre admise, rien ne se passe, sinon, les horloges logicielles sont ajustées.
2.1.2.1 L’algorithme de Christian
Une machine reçoit le TUC, les autres devront rester synchroniser avec elle. Un temps
de transaction de référence est établi.
Les machines émettrices gardent trace des temps de référence et font des moyennes
(corrigent si problème réseau).
Régulièrement chaque machine envoie un message à la machine de référence et
compare le temps de la transaction avec le temps de référence, si le temps dépasse la
fenêtre admise (moyenne, +- sigma), la machine corrigera, progressivement de
préférence, l'horloge logicielle.
2.1.2.2 Algorithme de Berkeley
Même principe que Christian, avec les différences suivantes :
• Pas de TUC.
• Le serveur de référence appelle les autres machines (inverse de Christian), il
utilise un daemon.
Jean-Michel Rodriguez
Systèmes et applications répartis
8/10
2002-2007
Copyright (C) 1997-2007. JM Rodriguez. Tous droits réservés. Reproduction interdite par tous moyens sauf à des
fins de citation.
•
•
Le daemon reçoit les réponses.
Le daemon calcule un temps moyen, serveur compris, il ajuste le serveur si
nécessaire et demande aux autres machines de s'ajuster en donnant les directives
(+t1, t2, etc.).
2.1.2.3 L’utilisation d'horloges synchronisées
Deux exemples d’utilisation des horloges synchronisées. L'étiquette temps est utilisée,
les paramètres des fichiers contiennent une information donnant la date et l'heure
d'utilisation du fichier.
Description des deux exemples :
1) "Pas plus d'un envoi de message".
• C’est une problématique importante car si un serveur reçoit des messages et les
numérote, qu’il les stocke dans sa table de messages et qu’il crashe, la table est
perdue.
• De plus le serveur va stocker plus de messages que nécessaire.
La question est : « Quand le serveur devra-t-il détruire les messages ? ».
•
•
Les messages contiennent une étiquette « temps » et un identifiant de connexion.
La dernière étiquette reçue, la plus récente pour un id donné, est stockée. Si la
machine crashe, à la mise en service elle retrouvera l'étiquette, tous les messages
précédant le temps de l'étiquette seront ignorés, seulement les fichiers dont
l'étiquette dans le temps est la plus récente seront traités.
Pour faire cela, le serveur maintient une variable globale G stockée sur disque.
Lorsqu’il redémarre, tous les messages dont le temps est inférieur à G sont
répétés.
Jean-Michel Rodriguez
Systèmes et applications répartis
9/10
2002-2007
Copyright (C) 1997-2007. JM Rodriguez. Tous droits réservés. Reproduction interdite par tous moyens sauf à des
fins de citation.
2) Le cache basé sur la cohérence d’horloge ou méthode du leasing dans les
systèmes de fichiers répartis.
• Un fichier s'emprunte en leasing pendant un certain temps en mode lecture, il se
charge dans le cache du client (meilleure performance du système).
• Lorsque le temps de leasing est expiré,le client ne peut plus utiliser le fichier.
• Si le client veut l'utiliser plus longtemps, il le signale au serveur, on évite le
renvoi du fichier.
• Si un client veut modifier le fichier, le serveur envoie un message aux clients qui
l'utilisent, et attend leur réponse.
• Si l'un des clients ne répond pas, panne de machine ou autre, le serveur attend
simplement la fin du temps de leasing.
Note : Pb lorsque deux clients accèdent à un fichier dans leur cache local.
Jean-Michel Rodriguez
Systèmes et applications répartis
10/10
2002-2007