Observations d`exécutions d`algorithmes de consensus sur

Observations d’exécutions d’algorithmes de consensus sur réseaux
sans fil en mode ad-hoc
Corine Marchand, Jean-Marc Vincent∗
{Corine.Marchand, Jean-Marc.Vincent}@imag.fr
Laboratoire ID-IMAG, Projet APACHE, (CNRS-INRIA-INPG-UJF)
ZIRST 51, avenue Jean Kuntzmann
38330 MONTBONNOT SAINT MARTIN
Résumé
La mise au point de middleware sur des architectures distribuées dynamiques nécessite des méthodes
de mesure et d’analyse adéquates. A partir de l’exemple d’un module de consensus basé sur des détecteurs de défaillances, l’article présente la visualisation d’exécutions de l’algorithme en fonction de l’évolution de l’architecture (défaillance réseau, crash de processus, reprise, etc...). La méthode présentée se
base sur la modélisation du comportement de l’algorithme (états et événements) couplée avec un modèle
hiérarchique de visualisation. L’analyse permet d’une part la vérification du schéma de l’algorithme
réparti et d’autre part de mesurer les latences afin de déterminer l’impact des temporisations sur la
qualité de service de l’algorithme.
Mots-clés : Traces d’exécution, Algorithme de consensus réparti, Réseaux sans fil ad-hoc
1. Introduction
Dans le cadre du développement d’intergiciels distribués, l’étape de mise au point reste une tâche
complexe. En effet, cette étape, directement corrélée à la mise en œuvre de l’environnement réparti,
correspond à la fois à une phase de debogage et à une phase d’évaluation de performances. Pour ce
faire, la validation passe d’une part par la vérification du bon enchaı̂nement des événements répartis, et
d’autre part par l’analyse de la qualité de service, à savoir la prise en considération des problèmes liés
aux durées d’exécution. Aussi, l’objectif des travaux présentés dans cet article est d’illustrer l’approche
méthodologique que nous avons utilisée [13] afin de permettre la validation d’algorithmes répartis et
l’analyse de leurs performances.
La validation du fonctionnement correct d’un protocole vis à vis de ses spécifications peut être notamment réalisée grâce à une observation précise de son exécution lors d’expérimentations spécifiques. Cependant, quelque soit l’environnement considéré (centralisé ou réparti), la complexité liée au problème
de l’observation provient essentiellement de l’intrusion nécessaire à la prise d’informations impliquant
immanquablement une modification même minime de l’exécution en elle-même. Aussi, l’obtention
d’observations significatives impose une analyse préalable des informations à collecter, effectuée lors
du prototypage de l’algorithme distribué à valider expérimentalement.
Dans un contexte distribué, l’obtention de la visualisation de traces d’exécution post-mortem soulève
donc deux problématiques :
• D’une part, la résolution de difficultés liées à l’observation d’événements distribués. En effet, outre
les problèmes de modélisation (Que veut-on mesurer ?), la prise d’informations nécessite une instrumentation adaptée (Comment mesurer ?), suivie de la réalisation de mesures pertinentes.
• D’autre part, l’analyse des données collectées peut s’avérer relativement complexe dans le cadre d’un
système réparti. En effet, l’étape d’interprétation des données enregistrées nécessite préalablement
une mise en relation temporelle des informations récupérées localement sur différents sites.
∗
Ce travail est partiellement financé par France Télécom R&D (Contrat INRIA CRE MIRRA).
À ces difficultés, dans notre système distribué basé sur un réseau sans fil de machines hétérogènes,
s’ajoutent de nouvelles problématiques liées aux spécificités d’un tel environnement. Tout d’abord, la
dynamicité de l’environnement doit être considérée. En effet, aux défaillances possibles des entités composant notre système distribué viennent se greffer les déconnexions de ces même entités dues principalement à leur mobilité mais aussi à diverses perturbations extérieures (interférences pouvant générer
une isolation momentanée). La difficulté soulevée ici réside essentiellement dans le choix des informations à enregistrer lors de l’exécution de l’algorithme de façon a être capable d’identifier par la
suite de tels phénomènes et pouvoir ensuite interpréter et visualiser le comportement de l’algorithme
étudié. De plus, dans ce type d’environnements, la non fiabilité des communications soulève également
de nouvelles difficultés. En effet, comment parvenir à la mise en relation d’événements de type envois/réceptions de messages lorsque des pertes se sont produites ? Une trace d’envoi de message qui
n’ayant aucune correspondance au niveau des réceptions signifie-t-elle que l’entité émettrice n’a jamais
émis le message sur le réseau ou que l’entité devant réceptionner n’a pas pu faire remonter ce message à un niveau supérieur (niveau middleware dans notre cas) ? Aussi, il paraı̂t nécessaire de définir
précisément les données devant être enregistrées à différents niveaux hiérarchiques de façon à pouvoir
interpréter les informations récoltées sur les différents sites.
Dans cet article, l’objectif principal visé concerne donc l’observation du déroulement d’un algorithme
distribué, plus explicitement un algorithme de consensus réparti, et la prise de mesures de performances
en terme de latences. Concrètement, on mémorise, lors de l’exécution de l’algorithme de consensus, les
informations relatant des différentes étapes de son évolution, de façon à pouvoir ”post-mortem” rejouer
cette exécution et ainsi permettre une analyse fine des événements et de leurs interactions. Pour ce faire,
une méthode analytique a été mise en place afin de faciliter la construction de diagrammes temporels
représentant le déroulement des consensus.
Nous présentons tout d’abord la problématique générale dans laquelle s’inscrit cette approche d’observation de l’exécution d’un algorithme de consensus dans un système distribué soumis à une forte dynamicité ambiante, et décrivons les solutions algorithmiques proposées de façon à prendre en compte les
particularités de l’environnement considéré. Après avoir expliciter l’étape d’instrumentation, nous nous
attacherons ensuite à décrire la manière dont l’exécution de cet algorithme réparti testé expérimentalement, peut être représenté graphiquement par un diagramme temporel réalisé post mortem. Enfin, la
dernière section est consacrée à la présentation des expérimentations réalisées et des résultats obtenus
en terme de traces d’exécutions permettant l’observation post mortem du déroulement de l’algorithme
de consensus.
2. Un algorithme de consensus en environnement instable
2.1. Contexte général
S’inscrivant au sein du projet Sidrah [4] -projet visant à la mise en œuvre d’une infrastructure permettant
entre autres la collaboration spontanée entre différents appareils connectés entre eux par un ou plusieurs
réseaux sans fil-, nos travaux se sont essentiellement attachés aux aspects liés à la ”résilience” d’une telle
infrastructure. A savoir, comment assurer la cohérence d’un groupe d’entités évoluant en coopération
dans un environnement totalement distribué et présentant une forte instabilité due essentiellement à
l’utilisation d’un protocole de communication sans fil mais aussi au fait que les entités mises en jeux ne
sont pas statiques.
Aussi, afin de fournir aux différentes entités composant le système le moyen de coordonner leurs actions ou de s’accorder sur une ou plusieurs valeurs partagées, l’algorithmique répartie tolérante aux
pannes fait référence à différents problèmes d’accords (consensus, élections, exclusions mutuelles, etc...)
concourant à résoudre les problèmes de maintien de la cohérence dans le groupe. De ce fait, nous avons
focalisé notre approche algorithmique sur le problème fondamental de résolution du consensus [19, 11]
en environnement fortement variable.
En effet, l’environnement considéré présente un certain nombre de caractéristiques particulières. Par
exemple, la principale spécificité de l’environnement dans lequel nous nous plaçons concerne l’utilisation d’un réseau sous-jacent basé sur un protocole de communication sans fil. Or, ce réseau sous-jacent
peut être qualifié de ”réseau local ad-hoc” et est donc caractérisé principalement par sa topologie dynamique. Aussi, les infrastructures logicielles reposant sur de tels environnements - réseaux sans fil
2
en mode ad-hoc composés d’entités hétérogènes - doivent pouvoir s’adapter et gérer cette dynamicité (connexion / déconnexion) ainsi que la forte variabilité des communications (latence, débit, pertes)
spécifiques à ces réseaux ambiants [15]. Il est cependant important de noter que, dans un soucis de
simplification, les entités de notre système appartiennent à la même ”bulle”. On entend par là que les
communications entre les différents membres de la communauté considérée ne nécessitent aucun intermédiaire, à savoir chaque entité peut atteindre directement et être atteignable directement par toutes
les autres entités de la communauté. De plus, une des propriétés remarquables de notre environnement
concerne le respect d’un ordre FIFO au niveau des communications.
Ainsi, dans cet environnement particulier, l’objectif général était donc de concevoir et d’implanter un
algorithme de consensus permettant de disposer d’une prise de décision répartie, et ce afin de maintenir la cohérence d’une communauté formée d’entités hétérogènes et partageant des services sur ces
architectures fortement dynamiques (instables).
Or, dans un tel contexte, - système asynchrone dans lequel les entités mises en jeu sont susceptibles
de subir de simples déconnexions voire des défaillances définitives -, la réalisation d’un consensus se
trouve directement confronté au résultat d’impossibilité énoncé par Fischer, Lynch & Paterson [5]. Bien
que diverses alternatives permettent de contourner cette impossibilité (approches probabilistes [2], approches auto-stabilisantes [20], etc...), la stratégie retenue concerne l’enrichissement de l’environnement
par un mécanisme de détection de défaillances non fiable tel que proposé initialement par Chandra
& Toueg [3]. En effet, étant donné l’instabilité de l’environnement considéré, le principal avantage de
cette approche concerne la flexibilité offerte lors de son implantation, et notamment la possibilité de
concentrer toute l’analyse de la variabilité de l’environnement au niveau du module de détection de
défaillances.
Cependant, reposant sur une hypothèse de fiabilité des communications, les algorithmes de consensus
basés sur l’utilisation de mécanismes de détections de défaillances [3, 8, 18] ne sont pas directement
utilisables dans notre contexte. De plus, les algorithmes proposant une résolution du consensus lorsque
le modèle de pannes peut être de type arrêt/rétablissement [7, 16, 1], ne semblent pas très adaptés à un
environnement soumis à une forte instabilité et considérant à la fois des défaillances définitives et des
déconnexions momentannées.
Aussi, inspiré de l’algorithme présenté par Chandra & Toueg [3], un algorithme de consensus spécifiquement adapté à la forte variabilité de l’environnement considéré a été proposé et développé [14]. Cet algorithme permet de contourner les obstacles que sont la variabilité des latences de communications, la
non fiabilité du protocole de communication, ainsi que les déconnexions intempestives des entités du
système. La principale particularité de cet algorithme repose sur l’utilisation d’un module de retransmission de certains messages couplé à une utilisation plus systématique du mécanisme de détection des
défaillances afin d’éviter les attentes trop longues et d’empêcher les interblocages [13].
2.2. Description de l’algorithme de consensus
Concept théorique :
De manière générale, l’algorithme de consensus repose sur le paradigme du coordinateur tournant. A
savoir, le déroulement de cet algorithme peut être décomposé en ”rounds” asynchrones, chacun étant
géré par une entité particulière appelée coordinateur. L’entité coordinatrice a un rôle majeur car elle est
chargée de la gestion du protocole d’accord, et donc d’une certaine façon de centraliser les informations
échangée pendant le ”round” dont elle est coordinatrice. Aussi, comme l’illustre la figure ??, le protocole
consiste en la réalisation de deux phases principales :
(i) la collecte des estimations des participants suivie de la communication de la proposition concernant la valeur de décision,
(ii) la collecte des acquittements des participants et la transmission de la décision.
Dans l’algorithme de Chandra & Toueg, collecter signifie que le coordinateur doit réceptionner une
majorité des messages envoyés par les participants (d (N+1)
e). Aussi, après l’étape de collecte, le coordi2
nateur diffuse soit, lors de la première phase, une proposition réalisée via une fonction sur l’ensemble
des estimations collectées, soit, lors de la seconde phase, la valeur de décision.
3
Le principe de fonctionnement de cet algorithme est qu’à chaque ”round” plusieurs
cas sont envisageables : la défaillance d’une
entité ou de plusieurs entités, des temps
VALEUR
de communication entre les entités plus ou
PROPOSITION
ACK
DECISION
moins longs, etc..., peuvent avoir diverses
influences sur le déroulement de l’algorithme.
PHASE 1
PHASE 3
Aussi, si les circonstances ne sont pas faROUND
vorables à la prise de décision lors d’un
F IG . 1 – Principe d’exécution de l’algorithme de consensus ”round” R, la résolution du consensus est
remise à un ”round” ultérieur. Les conditions environnementales pouvant évoluer rapidement, le passage au ”round” suivant R + 1 peut permettre la résolution du consensus. Ainsi, lorsqu’une entité pi est en attente d’un message de proposition
en provenance du coordinateur du ”round” R, elle interroge son détecteur de défaillances et, s’il s’avère
que celui-ci suspecte le coordinateur, cette entité pi passe au ”round” suivant (R + 1).
Ce principe théorique de fonctionnement de l’algorithme de consensus peut être décrit et/ou illustré de
diverses façons (la figure ci-dessus en est un exemple). Cependant, l’observation de ce même principe
lors d’expérimentations, c’est à dire sur une exécution réelle de l’algorithme, n’est pas triviale. En effet,
comme nous le verrons dans la suite de ce document, la reconstruction de la manière dont une exécution
a eu lieu nécessite différentes étapes de traitement préalables (détermination de la représentation visuelle des différents événements, élaboration d’un référentiel de temps commun entre les différents
sites, etc...).
Coordinateur
PHASE 2
PHASE 4
Présentation de l’algorithme adapté à l’instabilité de l’environnement :
Reposant sur l’existence de deux primitives de communication, une primitive de communication point
à point et une primitive de diffusion de messages, l’algorithme de consensus proposé s’appuie sur l’hypothèse d’intégrité des messages : on suppose en effet qu’il n’y a d’altération possible des messages.
De plus, l’introduction d’une couche de fiabilisation (retransmission) des messages permet de garantir
que tout message émis finira par être reçu. Par ailleurs, cet algorithme n’impose pas nécessairement la
présence d’une majorité d’entités correctes, mais suppose que les isolations réseau (déconnexions momentannées) des différentes entités sont indépendantes entre elles. La figure 2 présente l’automate per-
! stable
rcv(Estimate)
C−Wait−Estimate
C−Wait−Ack
Coord and
bc(Estimate)
INIT
not(Coord) and
send(Estimate)
! stable
majority(Ack)
and bc(Decision)
rcv(Nack)
suspect(Coord)
and send(Nack)
CHANGE
ROUND
rcv(Ack)
majority(Estimate)
and bc(Proposition)
END
CHECK
COORD
not(suspect(Coord))
and send(Ack)
rcv(Proposition)
P−Wait−Proposition
rcv(Decision)
P−Wait−Decision
F IG . 2 – Automate spécifiant le comportement de l’algorithme de consensus
mettant de décrire l’algorithme de consensus proposé. Pour détailler rapidement cet automate, les états
C-states (partie haute de l’automate) correspondent aux rôles attribués au coordinateur et se décomposent
4
en deux états : un état attribué à l’étape d’attente de réception d’une majorité de valeurs d’Estimation
(état CWaitEstimate) et l’état correspondant d’attente de réception d’une majorité d’acquittement (état
CWaitAck). La transition entre ces deux états est déclenchée par l’obtention d’une majorité d’Estimation
et se traduit par le diffusion de la valeur de Proposition.
A l’opposé, les états P-states correspondent aux rôles attribués aux participants (autres que le coordinateur) et se décomposent ainsi : un état représentant l’attente de la réception d’une valeur de Proposition
(état PWaitProposition) et un état associé à l’attente de réception de la valeur de Decision (état
PWaitDecision).
En relation avec la figure 1 présentée précédemment, l’état CWaitEstimate se situe dans la ”phase
2”, laquelle se termine par la diffusion de la valeur de Proposition du coordinateur (lien entre l’état
CWaitEstimate et l’état CWaitAck). L’état PWaitProposition se positionne dans ce qu’on nomme
”phase 3” dans la figure 1. Globalement, alors que les états et actions attribués au coordinateur dans la
figure 2 sont principalement associés aux phases 2 et 4 dans la figure 1, ceux attribués aux participants
correspondent quant à eux, aux phases 1 et 3 de la figure 1.
Par ailleurs, deux opérations importantes sont illustrées dans cette figure 2 : l’action C HECK D ETECTOR
qui est systématiquement déclenchée après réception d’une Proposition et l’action C HANGE R OUND
qui sera déclenchée après détection d’un problème (non stabilité du système) suite à une attente trop
longue.
2.3. Validation de l’algorithme de consensus
Afin de compléter l’étude théorique réalisée préalablement, l’étape d’implantation de l’algorithme de
consensus a été suivie d’une étape expérimentale de validation du fonctionnement de cet algorithme.
En effet, une vérification expérimentale de la conformité du comportement de l’algorithme par rapport
à ses spécifications est indispensable. Par ailleurs, une évaluation des performances de l’algorithme est
nécessaire à la mise au point et à l’optimisation de l’algorithme, ou plus précisément au dimensionnement des différents paramètres introduits (paramètres directement liés à l’algorithme de consensus,
mais aussi les paramètres attribués aux détecteurs de défaillances et ceux définis au niveau du module
de fiabilisation des communications).
Aussi, de façon à réaliser cette validation expérimentale, nous avons mis en place une méthode permettant d’observer le comportement (enchaı̂nement des événements successifs) de cet algorithme implémenté et exécuté sur une plateforme expérimentale. Or, l’observation d’une telle exécution peut être décomposée en deux étapes principales : d’une part, la prise d’informations au cours de l’exécution, et d’autre
part, l’interprétation des données ainsi collectées.
La première étape nécessite tout d’abord une définition précise des informations devant être enregistrées, suivie d’une instrumentation adaptée (voir section 3). La principale difficulté rencontrée lors de
l’instrumentation de l’algorithme de consensus, concerne la détermination des informations nécessaires
et leur correspondance en terme d’événements à tracer. En effet, il s’est avéré que les informations
intéressantes dépendaient directement d’événements provenant de divers niveaux hiérarchiques (module de consensus, module de détection de défaillances, couche de fiabilisation).
La seconde phase quant à elle, impose une mise en relation des événements collectés et enregistrés
sur différents sites distants, ceux-ci étant estampillés par une date locale. Bien que diverses techniques
peuvent être envisagées pour l’obtention d’une datation globale en cours d’expérience, devant l’instabilité de notre environnement et par soucis de simplification, nous avons opté pour la réalisation d’un
post-traitement des datations locales. Aussi, comme nous le verrons par la suite, la transformation des
différentes dates locales associées aux événements survenus sur différents sites, en une datation commune doit être réalisée (approximation d’horloge globale). Or, dans le cadre de cette validation d’algorithme, une datation globale approchée est suffisante. En effet, seul l’ordre d’exécution des événements
sur les différents sites est nécessaire à la réalisation de traces d’exécution post-mortem. Cependant, pour
pallier à un manque d’interaction entre certains sites distants pouvant complexifier la mise en œuvre
d’une datation globale, une entité extérieure peut être ajoutée dans les expérimentations afin de capter
les messages en transit et d’enregistrer l’ordre de passage de ces messages sur le réseau.
Aussi, afin de permettre un ordonnancement des événements distants, seuls les événements de type
envois et réceptions de messages estampillés de leur date locale sont utilisés. Or, un des problèmes
majeurs à l’extrapolation d’une datation commune réside dans la complexité à estimer le délai d’ache5
minement d’un message. En effet, comme l’illustre la figure 3, chaque événement correspondant à un
envoi de message estampillé (par une date D1) et enregistré au niveau du module de consensus, ne sera
réellement émis sur le réseau sans fil qu’à une date ultérieure (D2). Il en est de même pour l’événement
de réception du message qui sera estampillé par la date locale D4, mais aura été reçu sur le site concerné
à la date D3. Aussi, face à l’instabilité de l’environnement considéré et à l’hétérogénéité des machines
utilisées, le délai d’acheminement des messages peut être fortement variable.
Date Emission
Locale (D1)
Module Consensus
Délai inter−émissions DD
Détecteur
Site
Emetteur
D2
Réseau
Délai inter−émissions réseau
Délai entre deux réceptions réseau sur le site récepteur
Réseau
D3
Site
Récepteur
Détecteur
Délai inter−réceptions DD
Module Consensus
Date Réception
Locale (D4)
F IG . 3 – Décomposition des communications
3. Prises de mesures - Instrumentation
La collecte d’informations est une étape délicate car la prise de mesure est réalisée en cours d’exécution
et a donc une influence directe sur l’exécution en elle-même.
Cette phase d’instrumentation passe impérativement par la définition préalable de ce que l’on souhaite
observer, puis par la détermination des informations permettant de mettre en valeur l’évolution de l’état
du système. Aussi, une étape importante concerne la définition du modèle relationnel existant entre un
état à observer et les événements exécutés permettant d’identifier cet état et de le retracer ultérieurement.
Autrement dit, la principale difficulté réside donc dans l’identification des événements permettant de
déduire l’état du système à un instant donné (événements représentatifs de l’état du système).
Dans notre contexte, nous souhaitons pouvoir analyser le comportement de l’algorithme de consensus et à terme être capable de visualiser son exécution post-mortem. Pour ce faire, il est impératif de
conserver les informations concernant entre autres les divers échanges de messages effectués ainsi que
les états successifs des entités participantes, c’est à dire leur état d’évolution entre l’initiation du consensus et la prise de décision. Aussi, chaque événement (réception d’un message, émission d’un message,
changement d’état, etc...) doit être enregistré localement par chacune des entités composant le système
et estampillé notamment par sa date locale.
Concrètement, pour comprendre le déroulement de l’algorithme de consensus, les principaux événements devant
Enregistrements des
Module de Consensus
changements d’état relatifs
être récoltés correspondent aux émisà l’algorithme de consensus
sions et réceptions des différents types
Enregistrements
Module de
de messages (Estimation, ProposiDétecteur
Enregistrements des
des suspicions
Fiabilisation
de Défaillances
retransmissions de
tion, Ack, Nack, Decision, Forward)
(expirations des
messages
temporisations)
par les divers sites, ainsi que l’état couRESEAU
rant (Init, CWaitEstimate, CWaitAck,
PWaitProposition, PWaitDeciF IG . 4 – Extraction d’informations à différents niveaux
sion, End) de chacune des entités mises en jeu. Cependant, une telle prise de données est restrictive et ne sera représentative que des événements marquant l’exécution de l’algorithme au niveau du module de consensus (figure 4), mais ne
APPLICATIONS
6
dénotera en aucun cas des causes environnementales influençant cette exécution. Une trace ainsi obtenue pourra par exemple relater du passage au ”round” suivant d’une entité, - ce qui indique implicitement la suspicion du coordinateur courant par cette entité -, mais ne suffira pas à déduire par exemple
la déconnexion de l’une de ces entités. Aussi, une extraction de données particulières au niveau du module de détection de défaillances et du module de fiabilisation des communication semble également
nécessaire. Par exemple, l’information retournée par un détecteur de défaillances lorsqu’il est interrogé,
peut être mémorisée de façon à faciliter l’analyse et l’interprétation des traces d’exécutions générées
ensuite. De même au niveau du module de fiabilisation, la trace des messages retransmis, ou tout du
moins le nombre de retransmissions effectuées pour un même message, paraı̂t indispensable à une analyse future des délais d’attente dans l’exécution de l’algorithme.
Aussi, vis à vis de l’algorithme de consensus étudié, la phase d’instrumentation nécessite une collecte
d’informations à différents niveaux hiérarchiques.
Par ailleurs, la prise de mesures représente une perturbation dans l’exécution normale et a donc un
coût (prise de temps, enregistrement des informations dans un fichier) dont il faudra tenir compte lors
de l’interprétation des données ainsi récoltées. De plus, ce coût lié à la prise de mesures n’a pas le
même impact suivant le type d’entités concerné. En effet, la collecte d’informations aura davantage de
conséquences sur une entité aux ressources limitées (un PDA par exemple) que une machine puissante
(PC, ordinateur portable, etc...). Aussi, afin de limiter au maximum ce coût lié à l’enregistrement d’informations, une analyse précise des événements significatifs et nécessaires à la fois à l’évaluation et à la
visualisation, est effectuée.
De ce fait, l’objectif étant la visualisation du déroulement de l’algorithme de consensus, les traces récoltées
proviendront essentiellement du niveau module de consensus, mais s’appuieront également en complément sur les enregistrements relatant d’informations issues des modules de détections de défaillances
et de fiabilisation, indispensables à la représentation (figure 4).
Enfin, un formalisme précis du traçage est défini ensuite. En effet, chaque enregistrement d’événement
doit contenir l’ensemble des informations nécessaires à une analyse future (par exemple, la date d’occurrence, un identifiant unique de l’événement dans le cas où plusieurs événements similaires peuvent
se produire, etc...). Aussi, une étude sur la ”manière” de récupérer les informations est nécessaire afin
de pouvoir enregistrer un maximum d’informations en un minimum de données.
4. Visualisation
Les différents événements enregistrés sur les diverses entités participant aux élections, une fois ordonnés de façon
cohérente et datés approximativement dans un référentiel
temporel commun, peuvent être représentés graphiquement. Pour ce faire, nous avons choisi d’utiliser l’environProcessus
Processus
Processus
Détecteur
Consensus
Retransmission
nement de visualisation Pajé [9].
Aussi, l’obtention de diagrammes ”post mortem” représentatifs des exécutions de l’algorithme de consensus expériHeartbeats Suspicions
Compteurs
menté, nécessite que l’ensemble des traces récupérées soit
États
Messages
converti dans un format compatible avec l’outil de visualisation. La figure 5 représente le modèle de visualisation
Init
Estimate
choisi. Ce modèle se décompose en trois parties, une pour
Proposition
CWaitEstimate
Ack
CWaitAck
chaque module de l’architecture considérée (module de
Nack
PWaitProp
consensus, module de détection de défaillances et couche
Decision
PWaitDecision
de fiabilisation) ; mais ne présentant dans cet article que
Forward
End
les traces issues du module de consensus, seul le modèle
F IG . 5 – Modèle de visualisation
associé à ce module est détaillé. Ainsi, comme illustré dans
cette figure, pour chaque entité (site), les états introduits dans l’algorithme de consensus différents types
de messages échangés seront représentés visuellement.
SITES
7
Durée du consensus
(pour l’initiateur : PC5)
Attente majorité d’estimations
ms
0
5
10
15
20
25
30
Acquittement tardif
force le renvoi agressif de la décision
Attente majorité d’Ack
35
40
45
50
55
60
65
70
75
80
85
90
95
100
PC−0
PC−5
PDA−1
PDA−2
PDA−3
PDA−4
DECISION Phase
ESTIMATE Phase
PROPOSITION Phase
F IG . 6 – Diagramme post-mortem d’une élection ne donnant lieu à aucune suspicion
Exemple de visualisation obtenue :
Sur le diagramme 6, chaque ligne correspond à un module de consensus participant à l’algorithme et
permet d’illustrer les changements d’états survenus au cours du consensus. De plus, les communications entre les différentes entités sont représentées par des flèches allant de l’émetteur vers le ou les
récepteur(s). Il est important de constater que la diffusion d’un message est représentée graphiquement
par plusieurs flèches ayant la même origine, mais il est bien évident qu’en réalité un seul message est
réellement émis.
Comme illustré dans cette trace d’exécution, l’initiation du consensus est effectuée par un des participants, l’entité PC-5, qui envoie sa valeur d’Estimation au coordinateur de ce round (PC-0), déclenchant
ainsi l’implication cette l’entité. Le coordinateur diffuse alors sa valeur d’Estimation, et se met en attente de la réception des estimations d’une majorité de participants. Aussi, dès que le coordinateur a
obtenu une majorité d’estimations, il génère une proposition qu’il diffuse aussitôt. On peut noter par
exemple que la valeur d’estimation de l’entité PDA-4 n’est pas utilisée pour le calcul de la proposition
car elle parvient plus tard au coordinateur. Ceci n’empêche pas pour autant à cette entité de poursuivre
sa participation à l’obtention d’une décision commune. Lorsqu’une majorité d’acquittements est parvenue au coordinateur (PC-0), celui-ci peut dès lors diffuser la décision. Enfin, lorsque le coordinateur
reçoit les messages d’acquittement des entités PDA-1 et PDA-4, il diffuse de nouveau la décision (message de type Forward).
5. Exemples détaillés
L’algorithme de consensus présenté précédemment ayant été implanté sur un réseau ad-hoc sans fil de
type 802.11b, de nombreuses prises de mesures ont été réalisées afin de permettre la génération de traces
d’exécution et ainsi de valider expérimentalement le fonctionnement de l’algorithme. Aussi, après avoir
décrit le contexte expérimental dans lequel les expériences ont été réalisées, nous présentons les résultats
obtenus en terme de diagrammes d’exécution issus de ces différents tests.
5.1. Conditions Expérimentales
Une plateforme Java a été mise en place sur un réseau sous-jacent de type réseau 802.11b en mode adhoc, et dans lequel aucun mécanisme de routage ou d’encryption n’ont été mis en place. La configuration
matérielle des différentes entités mises en jeu dans nos expériences est proposée dans le tableau 1 en
annexe 1.
L’implémentation des détecteurs de défaillances retenue pour ces expérimentations s’appuie sur la mise
en place d’un mécanisme de ”heartbeat”. Aussi, dans ce modèle d’implémentation, deux paramètres
principaux sont associés aux détecteurs de défaillances : la période de heartbeat et le délai de temporisation [15]. De ce fait, les observations résultantes seront à interpréter en fonction des valeurs de ces
paramètres.
Par ailleurs, la réalisation d’un consensus nécessite que chaque entité composant le système étudié, à
savoir les entités participant à l’algorithme de consensus, possède préalablement :
• un identifiant unique,
8
• un fichier contenant la liste des participants (identique pour chaque entité),
• un algorithme de sélection (politique de choix d’une valeur parmi plusieurs).
Enfin, la fiabilisation des communication est réalisée par réémission régulière. Un paramètre de ”polling” permet ainsi de régler à la fois par polling la fréquence d’interrogation du détecteur de défaillances
et la retransmission des messages.
Description des expériences et réglages des paramètres :
Les résultats présentés ici ont été obtenus lors d’expérimentations impliquant 7 entités. Afin de capturer
les communications réseau sans interférer dans les expérimentations, une entité particulière (un ordinateur portable) ne participant pas réellement aux tests de consensus, a fait office de ”sniffer”. Ainsi,
hormis cette entité au rôle particulier, toutes les autres entités exécutent l’algorithme de consensus distribué dont les principes ont été introduits précédemment.
Précisons que : d’une part, le capteur de trafic réseau n’est pas intrusif et, d’autre part, les entités mises
en jeu restent physiquement à la même place et toutes ont leur mode d’économie d’énergie inactivé et
de plus restent alimentées électriquement tout au long des expériences.
Par ailleurs, chacune des expériences effectuée consiste en une série de 1000 élections consécutives (identifiées de manière unique) sans aucune synchronisation additionnelle, chaque élection étant initiée par
un des participants (par forcément le même). Rappelons le principe d’une élection dans cette série : une
élection est réalisée grâce à l’exécution de l’algorithme de consensus, afin d’obtenir d’un accord sur la
proposition d’un leader parmi les différents participants. Pour ce faire, lorsqu’une élection est engagée,
chaque participant soumet sa propre estimation (générée aléatoirement dans nos expérimentations).
La politique de choix d’une valeur parmi plusieurs a été déterminé tel que l”algorithme d’élection
sélectionne le participant ayant la valeur d’estimation la plus grande (celui ayant l’adresse IP la plus
grande en cas d’égalité sur la valeur d’estimation).
D’autre part, le paramétrage retenu dans les expérimentations proposées dans cet article, est donné par :
• 500 ms pour la période d’émission des heartbeats (2 pulsations par seconde au niveau du module de
détection de défaillances),
• 1500 ms pour la valeur de temporisation (temps écoulé avant la suspicion du site distant par le
détecteur de défaillances n’ayant reçu aucune information en provenance de ce site).
• 2000 ms pour le paramètre de ”polling” (interrogation du détecteur de défaillances et retransmission
éventuelle du dernier message précédemment émis).
5.2. Traces d’exécution obtenues
Comportement ”idéal” :
La trace d’exécution 6 illustre les différentes étapes du déroulement d ’une élection particulière dans
un cas ”idéal” (aucune perturbation extérieure, aucune suspicion, ...). Cette trace d’exécution permet
de bien distinguer les 3 phases du déroulement d’une élection : la phase d’Estimation, la phase de
Proposition et la phase de Decision. On peut ainsi retrouver les différentes phases introduites dans le
modèle théorique (figure 1).
Il est à noter que l’élection représentée par le diagramme 6 a été réalisée en un round seulement,
round durant lequel le coordinateur était l’entité PC-0. Ceci est bien visible sur le diagramme puisque
les groupes de messages (diffusions) sont en partance de l’entité PC-0 et que toutes les autres entités
émettent vers cette entité PC-0.
De plus, dans cette trace, la représentation d’une diffusion de messages utilisée met bien en évidence les
réceptions différées suivant les sites (latences variables de transmission des messages). Ce délai inclut
d’une part les transmissions réseau ainsi que la traversée des différentes couches, du niveau UDP/IP à
l’application Java (remontée de la pile).
Par ailleurs, comme l’illustre ce diagramme, le temps de réalisation d’un consensus dans de telles conditions est inférieur à 1 seconde (temps pour que toutes les entités aient connaissance de la décision).
Bien sûr ce temps inclut le coût dû à l’instrumentation, et dépend directement du nombre d’entités impliquées et du réglage des paramètres utilisé. Cependant, une telle observation permet notamment de
comparer le comportement des différentes entités (il semble par exemple que PC-5 reçoive plus rapidement les informations que les PDAs) et l’identification des phases à optimiser. Une analyse statistique
9
peut être menée pour caractériser les latences [13].
Avec une suspicion :
La trace d’exécution 7 permet d’illustrer le déroulement d’une élection pendant laquelle un des participants suspecte le coordinateur.
PDA2 suspecte le coordinateur (PC0)
et envoie un NACK
NACK message
ms
0
5
10
15
20
25
30
35
Réception NACK après émission décision
45
75
50
40
55
60
65
70
80
85
90
95
100
PC0
PC5
PDA1
PDA2
PDA3
PDA4
ESTIMATION Phase
(Round 1)
DECISION Phase (Round 1)
PROPOSITION Phase (Round 1)
ESTIMATION Phase (Round 2)
F IG . 7 – Diagramme post-mortem d’une élection pendant laquelle une fausse suspicion a lieu
En effet, venant à suspecter l’absence du coordinateur actuel (PC-0), l’entité PDA-2 envoie un nonacquittement (message Nack) en réponse à la Proposition faite par le coordinateur, puis passe au round
suivant (cf figure 2). Or, comme le montre la trace d’exécution, cette suspicion peut être qualifiée de
”fausse suspicion” car le coordinateur de ce round (PC-0) n’est pas réellement absent. Aussi, dans ce
cas de figure l’ordre des événements a une grande importance. En effet, avant de réceptionner ce nonacquittement (message Nack), le coordinateur ayant préalablement reçu une majorité d’acquittements
positifs (messages de type Ack), a déjà diffuser un message de Decision. Aussi, en réponse à ce message
Nack, le coordinateur (PC-0) diffuse simplement un nouveau message contenant sa valeur de Decision.
On peut ainsi constater la désynchronisation des participants puisque ceux-ci sont dans des états différents (rounds différents, phases différentes). Cependant, lorsqu’un participant connaı̂t la valeur de Decision, à chaque réception d’un message estampillé par l’identifiant du consensus il répond par diffusion
de cette valeur de décision (message FORWARD). Ainsi, la fin de la trace 7 montre que tous les participants finissent par connaı̂tre la valeur de décision.
Au vu de cette trace d’exécution, il apparaı̂t qu’une optimisation de la diffusion agressive de la décision
(message Forward) soit envisageable afin de diminuer la quantité de messages émis tout à préservant
la garantie de terminaison de l’algorithme.
Avec déconnexion d’une entité :
Tout d’abord, la déconnexion imprévisible d’une entité participante est considérée. Bien sûr, si l’entité
se déconnectant brutalement n’est pas coordinatrice du round (ou des rounds) en cours, sa déconnexion
n’aura pas de véritable impact sur la résolution de l’élection, si ce n’est sur la durée qui peut éventuellement être augmentée. Aussi, l’étude menée a porté sur la déconnexion de l’entité coordinatrice du
premier round (dans la liste initiale des participants) et son impact sur les performances.
Lorsque le premier coordinateur est absent, et si aucune autre perturbation n’intervient au cours de
l’expérience, toutes les élections sont réalisées en deux rounds. Ceci est illustré dans la trace d’exécution
8.
Comme on peut le voir au début de la trace 8 (figure 9), tous les participants sont présents. Cependant
PC-0, le premier coordinateur, se déconnecte (ou subit une défaillance) durant le premier round. Cette
déconnexion (ou défaillance) peut être qualifiée de déconnexion définitive (ou défaillance définitive)
par rapport à l’élection en cours. Après un délai dépendant des valeurs attribuées aux paramètres
10
Temporisation de changement de round
Déconnexion coordinateur PC0
0
100
200
300
400
500
600
700
800
900
1000
1100
1200
1300
1400
1500
1600
1700
1800
1900
2000
2100
2200
PC0
PC5
PDA1
PDA2
PDA3
PDA4
ROUND 2
ROUND 1
F IG . 8 – Trace d’exécution post-mortem d’une élection où le coordinateur du premier round (PC-0) se
déconnecte (ou subit une défaillance)
Déconnexion du coordinateur PC0
après diffusion de la Proposition
Émission Proposition
50
60
70
80
90
100
110
120
130
140
150
160
170
180
190
200
210
220
230
240
250
260
PC0
PC5
PDA1
PDA2
PDA3
PDA4
ESTIMATE messages
PROPOSITION Broadcast
ACK messages
F IG . 9 – Zoom sur le début du round 1 dans la trace 8
Suspicion de PC0 par PC5 qui déclenche le round 2 (coordinateur : PDA1)
2100
2105
2110
2115
2120
2125
2130
2135
2140
2145
2150
2155
2160
2165
2170
2175 2180
2185
2190
2195
2200 2205
2210
2215
PC0
PC5
PDA1
PDA2
PDA3
PDA4
ESTIMATE messages
PROPOSITION Broadcast
DECISION Broadcast
ACK Messages
FORWARD Broadcast
F IG . 10 – Décision lorsque le premier coordinateur est absent (fin de la trace 8)
des détecteurs de défaillances, les entités participantes finissent par passer au round suivant (fin de
la trace 8). L’illustration du second round où l’entité PDA-1 est coordinatrice est donnée dans la trace
d’exécution post-mortem 10.
6. Conclusion
Basé sur l’utilisation d’un mécanisme de détections de défaillances, un algorithme de consensus spécifiquement adapté à notre environnement fortement instable - réseaux sans fil ad-hoc composé d’entités
hétérogènes - a été développé et implanté. Dans cet article, nous avons présenté l’approche expérimentale
utilisée afin de valider le bon fonctionnement de cet algorithme de consensus, à savoir vérifier que le
comportement de cet algorithme est conforme à ses spécifications. Pour ce faire, divers scénarios mis en
œuvre dans nos expérimentations (pertes de communications, défaillances ou déconnexions d’une ou
de plusieurs entités) ont permis la génération de traces d’exécutions post mortem et par suite une analyse
comportementale basée sur les observations ainsi obtenues.
Par ailleurs, les traces d’exécution ainsi reconstruites permettent également l’obtention d’évaluations
des durées d’exécution de l’algorithme. En effet, les diagrammes ainsi réalisés sont des outils de visualisation du temps passé dans chacune des phases de l’algorithme de consensus. Bien que les coûts liés
à la prise de mesures pendant l’exécution de l’algorithme soient à prendre en compte, les durées ainsi
observées sont cependant relativement significatives et peuvent être comparées.
Aussi, en vue de l’optimisation de cet algorithme de consensus, une analyse fine de ces durées d’exécution sera publiée ultérieurement [13]. Elle permet la mise en place d’un réglage adéquat des paramètres
liés au module de consensus mais également des paramètres des détecteurs de défaillances.
11
Bibliographie
1. Aguilera, M. and Chen, W. and Toueg, S. – Failure Detection and Consensus in the Crash-Recovery
Model. In : International Symposium on Distributed Computing, pp. 231–245.
2. Canetti, R. and Rabin, T. – Fast Asynchronous Byzantine Agreement with Optimal Resilience. In :
In 25th ACM Symposium on Theory of Computing. pp. 42–51. – San Diego, California, United States,
1993.
3. Chandra, T. and Toueg, S. – Unreliable Failure Detectors for Reliable Distributed Systems. Journal of
the ACM, vol. 43, n˚ 2, mars 1996, pp. 225–267.
4. Durand, Y. and Perret, S. and Vincent, J-M. and Marchand, C. and Ottogalli, F-G. and Olive, V. and
Martin, S. and Dumant, B. and Chambon, S. – SIDRAH : A software infrastructure for a resilient
community of wireless devices. In : Smart Objects Conference, pp. 134–137. – Grenoble, France, 2003.
5. Fischer, M. and Lynch, N. and Paterson, M. – Impossibility of Distributed Consensus with One
Faulty. Journal of the ACM, vol. 32, n˚ 2, 1985, pp. 374–382.
6. Haddad, Y. – Performance dans les systèmes répartis : des outils pour les mesures. – Orsay, France, Thèse
de doctorat, Université Paris-Sud, 1988.
7. Hurfin, M. and Mostefaoui, A. and Raynal, M. – Consensus in Asynchronous Systems Where Processes
Can Crash and Recover. – Rapport technique n˚ IRISA Publication Interne, PI-1144, 1997.
8. Hurfin, M. and Raynal, M. – A Simple and Fast Asynchronous Consensus Protocol Based on a Weak
Failure Detector. Distributed Computing, vol. 12, n˚ 4, 1999, pp. 209–223.
9. Laboratoire Informatique et Distribution. – Pajé Home Page.
http ://www-apache.imag.fr/software/paje/.
10. Lamport, L. – Time, Clocks, and the Ordering of Events in a Distributed System. Communications of
the ACM, vol. 21, n˚ 7, juillet 1978, pp. 558–566.
11. Lynch, N. – Distributed Algorithms. – Morgan Kaufmann Publishers Inc., 1996.
12. Maillet, E. – Le traçage logiciel d’applications parallèles : conception et ajustement de qualité. – Grenoble,
France, Thèse de doctorat, Institut National Polytechnique de Grenoble, 1996.
13. Marchand, C. – Mise au point d’algorithmes répartis dans un environnement fortement variable, et
expérimentation dans le contexte de pico-réseaux. – Thèse de doctorat, Laboratoire ID-IMAG, décembre
2004.
14. Marchand, C. and Perret, S. and Vincent, J-M. – A Consensus based Middleware for Resilient Applications in Wireless Networks. – Submitted to IPDPS 2005.
15. Marchand, C. and Vincent, J-M. – Détecteurs de défaillances et qualité de service dans un réseau
ad-hoc hétérogène. In : Conférence Française sur les Systèmes d’Exploitation (CFSE’3), éd. par INRIA,
pp. 525–536. – La Colle sur Loup, France, octobre 2003.
16. Oliveira, R. and Guerraoui, R. and Schiper, A. – Consensus in the Crash-Recover Model. – Rapport
technique n˚ TR-97/239, 1997.
17. Ottogalli, F-G. – Observations et analyses quantitatives multi-niveaux d’applications à objets réparties. –
Grenoble, France, Thèse de doctorat, Université Joseph Fourier, 2001.
18. Schiper, A. – Early Consensus in an Asynchronous System with a Weak Failure Detector. Distributed
Computing, vol. 10, n˚ 3, avril 1997, pp. 149–157.
19. Tel, G. – Introduction to Distributed Algorithms. – Cambridge University Press, 1994.
20. Tixeuil, S. – Auto-Stabilisation Efficace. – Thèse de doctorat, Université Paris Sud, 2000.
12
ANNEXE 1 : Configuration matérielle
PC
PDA
Laptop
Type
HP Workstation
HP Ipaq 3800
HP Omnibook
Architecture
X86 (P4)
Strong ARM
X86 (PIII)
Processeur
2.4 GHz
207 MHz
1.0 GHz
Mémoire
512 MB
32 MB
256 MB
OS
Linux Debian (kernel 2.4)
Linux Familiar (kernel 2.4)
Linux Debian (kernel 2.4)
JVM
Sun Java JRE 1.4.2 01-b06
Jeode EVM Version 1.10.2
Sun Java JRE 1.4.2 01-b06
Wireless Card
Compaq Orinoco 802.11b
Compaq Orinoco 802.11b
Compaq Orinoco 802.11b
Nombre
1
4
2
TAB . 1 – Configuration matérielle des machines.
ANNEXE 2 : Extrapolation d’une horloge globale
Étant donné que chaque entité composant le système distribué considéré se réfère à sa propre horloge
physique, l’objectif est de définir une horloge de référence permettant d’avoir une datation globale. En
effet, définir des relations entre une horloge de référence et chacune des horloges locales de chaque
site du système permet d’avoir une approximation d’horloge globale. Cette solution proposée dans
différents travaux [6, 12, 17] permet de calculer des facteurs correctifs pour chaque datation locale afin
de les projeter dans un référentiel de temps commun. Ce principe de datation globale qui consiste en
une synchronisation des différentes datations locales utilisées, ne cherche pas à extrapoler une horloge
globale précise mais simplement à définir une relation d’ordre partielle entre les événements s’étant
produits sur différents sites répartis.
D’après Lamport [10], dans un système distribué, une relation partielle de précédence causale peut être
définie comme suit :
Définition :
On dit qu’un événement ei précède causalement un événement ej (ei ≺ ej ) si et seulement si une des
trois conditions suivantes est vérifiée :
1. les événements ei et ej se produisent sur le même processus et ei se produit avant ej localement.
2. les événements ei et ej se produisent sur deux processus distincts et ei est l’émission d’un message tandis que ej est la réception de ce même message.
3. ∃k tel que ei ≺ ek et ek ≺ ej
Chaque événement, initialement daté localement, doit donc être daté approximativement dans un référentiel
commun. La date locale d’un événement ei s’exprime donc dans le référentiel global par la formule
mathématique suivante :
i
i
deref
= αdeloc
+β
(1)
où α représente la dérive et β le décalage initial.
Aussi, si l’on ne s’intéresse qu’aux événements de types émissions et réceptions de messages, la relation
de causalité existant entre les divers événements est basée sur le fait que la date d’émission d’un message
Ei exprimée dans le référentiel global précède forcément la date de réception de ce message Ri dans le
même référentiel :
Ri
i
dE
ref ≤ dref .
Ri
i
Si le message i a été émis par le site A à la date dE
A et réceptionné par le site B à la date dB , on a donc :
Ri
i
αA dE
A + βA ≤ αB dB + βB
13
(2)
Bien évidemment, de telles relations existent entre les différents sites ayant réalisé au moins une communication entre eux. Cependant, suivant le type de protocole réparti testé expérimentalement, il peut
s’avérer que certaines paires de sites n’échangent aucun message pendant l’exécution. En effet, dans
l’exemple de l’algorithme de consensus, le principe théorique de fonctionnement ne définit des communications seulement du coordinateur vers les autres participants ou des participants vers l’entité coordinatrice du ”round”. Aussi, dans ce cas, quelques soient les conditions expérimentales, le consensus
se déroulant nécessairement en un ”round” au minimum, le référentiel de temps du premier coordinateur (premier site dans la liste des coordinateurs) semble être le plus adapté comme référence de temps
global.
De manière générale, on en vient alors à chercher les αk et βk (k représentant l’ensemble des sites mis
en jeu), tel que :
Ri
i
αA dE
A + βA ≤ αB dB + βB , ∀i
(3)
i
αB dE
B
(4)
+ βB ≤
i
αA dR
A
+ βA , ∀i
Cependant, face au nombre important d’événements enregistrés, les calculs réalisés portent sur les enveloppes convexes de chaque type d’événements (émissions, réceptions) et sur chacun des sites afin de
réduire l’ensemble des contraintes [6].
Pour chaque paire de sites distants du système, on cherche donc une droite passant entre deux enveloppes convexes (définies par l’équation (3)) afin de satisfaire toutes les contraintes, c’est à dire respecter
les relations d’ordre existantes entre les événements survenus sur ces deux sites.
Le système à résoudre se ramène donc à :
αA
≤ v2
αB
βA − βB
≤ v4
v3 ≤
αB
v1 ≤
(5)
(6)
Bien sûr, des relations similaires existent entre chaque couple de sites distants mis en jeu dans le système
ayant des interactions au cours de l’exécution d’une expérience.
Ainsi, on définit les αk et βk , k = 0...N (où N est le nombre de sites répartis dans le système), de
façon à ce que toutes les relations de causalité soient respectées. De ce fait, rien n’assure de l’exactitude
de la datation dans le référentiel global, mais seulement de l’ordre des événements en relation directe.
Aussi, la nouvelle datation ainsi obtenue (datation globale) peut éventuellement être biaisée du fait de
l’imprécision dans la prise de dates (top d’horloge, dérive due aux températures, le fait que la prise de
date fasse suite à l’événement, ...). De plus, les événements n’ayant aucune relation de causalité entre
eux sont susceptibles de ne pas être placés dans l’ordre de leur exécution réelle.
Finalement, cette méthode permet simplement de construire une approximation linéaire d’une horloge
globale qui respecte analytiquement la causalité des événements de l’exécution observée.
14