D´efinition de m´etriques

Les m´etriques que nous avons d´efinies font appel aux variables suivantes :

N_{M AX} : la valeur num´erique la plus grande correspondant `a un identifiant pour les pairs et les cl´es. La fonction de hachage de Chord g´en`ere des identifiants compris dans l’intervalle [0, NM AX[ et toutes les op´erations sont effectu´ees modulo NM AX;

ni : un nœud d’identifiant i ;

N : l’ensemble des nœuds ni qui sont actuellements pr´esents et joignables dans un anneau, avec N = {ni} ;

NT : le nombre total de nœuds dans un anneau, avec NT = Card(N ) ; ki : une cl´e d’identifiant i ;

Ki : le nombre de cl´es dont le pair ni est responsable, avec Ki = Card({kj}) et id(pred(ni)) ≤ j ≤ i.

K_T : le nombre total de cl´es r´ef´erenc´ees dans un anneau, avec K_T =P

i∈NK_i. K : le nombre moyen de cl´es par pair, avec K = ^KT

NT Mesure de la dynamique de l’anneau

Avant de d´efinir des m´etriques pour la mesure de performance d’un anneau Chord, nous avons estim´e qu’il ´etait important de pouvoir en ´evaluer l’´etat. Nous avons ainsi d´efini des m´etriques qui caract´erisent un anneau Chord du point de vue de la stabilit´e des pairs et des cl´es. De la mˆeme mani`ere que nous avons d´efini deux niveaux d’abstraction pour les services P2P, nous proposons de d´efinir ces m´etriques sur deux niveaux : un niveau local inh´erent `a un ´el´ement, comme un pair ou une cl´e, et un niveau global qui concerne un anneau dans sa globalit´e.

La caract´erisation de la stabilit´e de l’anneau est un indicateur qui va permettre de relativiser et expliquer les valeurs des m´etriques d´efinies par la suite. Par exemple, l’augmentation brutale du nombre moyen de sauts n´ecessaires au routage d’une requˆete peut s’expliquer par un fort taux d’arriv´ee et de d´epart des nœuds qui perturberait la coh´erence des donn´ees maintenues dans les tables de routage. La m´etrique de dynamique de l’anneau permet ainsi de d´etecter ce fort changement et d’expliquer la baisse de performance du processus de localisation.

Dans un anneau Chord, les deux ´el´ements soumis `a des changements sont les pairs et les cl´es. Les pairs peuvent joindre et quitter la communaut´e de mani`ere impr´evisible, de mˆeme que les cl´es peuvent ˆetre ins´er´ees ou retir´ees, ou migrer pour assurer leur persistence. Ainsi, pour ces deux ´el´ements, nous avons choisi de caract´eriser leur temps moyen de pr´esence et la fr´equence `a laquelle ils subissent des changements. Pour ce faire, nous consid´erons que les temps d’arriv´ee et de d´epart sont connus et stock´es dans un journal. Ceci permet de calculer directement leur temps de pr´esence dans l’anneau et de d´eduire la fr´equence `a laquelle ils subissent des changements, consid´er´ee comme l’inverse de l’intervalle de temps s´eparant deux ´ev´enements. Ensuite, d’un point de vue global, nous proposons d’´evaluer le taux d’arriv´ee et de d´epart des cl´es et des nœuds par le biais des relations 6.1 et 6.2. Dans la suite, nous expliquons ces relations en consid´erant le cas des nœuds. Lorsqu’un nœud joint ou quitte l’anneau, la date courante est relev´ee et sert `

a calculer les indicateurs JoinF requency et LeaveF requency. La valeur de cette date courante est ensuite stock´ee dans les variables LastArrivalT ime et LastDepartureT ime, selon le cas, pour calculer la fr´equence d’apparition de l’´ev´enement suivant.

JoinF requency = ¹

CurrentT ime − LastArrivalT ime ^(6.1)

LeaveF requency = ¹

CurrentT ime − LastDepartureT ime ^(6.2) Le temps de pr´esence moyen d’un nœud est calcul´e par l’´equation 6.3. On consid`ere une fenˆetre temporelle T dont la taille d´epend du contexte et peut s’adapter au niveau de dynamisme estim´e. Pour tous les pairs qui ont particip´e `a l’anneau durant l’intervalle de temps d´efini par T , tous leurs temps de pr´esence sont moyenn´es de mani`ere `a fournir une estimation globale.

P resenceM eanT ime =

P

i∈N

P

t∈Tit

P

6.4. Instanciation du mod`ele de l’information sur Chord

T : la fenˆetre temporelle de calcul du temps de pr´esence moyen, avec T = [TBegin, TEnd] ; Ti : l’ensemble des temps de pr´esence collect´es dans la fenˆetre T pour le nœud ni, avec Ti =

{t | t = (TDeparture− TArrival); TDeparture, TArrival ∈ T }.

Maintenant, concernant les cl´es, nous avons d´efini des m´etriques identiques `a celles propos´ees pour les pairs. Ceci nous permet de repr´esenter les fr´equences globales d’insertion, de migration et de retrait des cl´es.

Par le biais des m´etriques d´efinies dans cette section nous ne sommes pas capables d’´evaluer la performance d’une communaut´e Chord mais la mani`ere dont la communaut´e ´evolue, en termes de dynamisme des cl´es et des pairs. Cette m´etrique sert `a mettre en relation les m´etriques que nous d´efinissons dans les section suivantes avec l’´etat d’un anneau.

Mesure de la performance du processus de localisation

Dans la section 6.3.2, nous avons propos´e un mod`ele qui permet de tracer les requˆetes de localisation effectu´ees au sein d’une DHT. Dans cette section, nous proposons la d´efinition d’une m´etrique statistique relative `a la performance du processus de localisation qui est calcul´ee grˆace aux donn´ees fournies par le mod`ele de m´etriques et d’unit´es de travail du processus de localisa-tion. La grandeur que nous proposons de monitorer est le nombre moyen de sauts par requˆete de localisation, pour laquelle nous proposons la d´efinition d’une m´etrique. Cette m´etrique est int´e-ressante car elle peut ˆetre directement compar´ee aux performances th´eoriques attendues, `a savoir

1

2log₂N_T et indiquer le bon ´etat d’un anneau Chord. L’algorithme que nous proposons pour le calcul de cette m´etrique est d´ecrit dans l’´equation 6.4. Pour chaque pair ni, nous d´efinissons les m´etriques suivantes :

– N InitiatedRequestsi : Le nombre total de requˆetes de localisation dont le nœud ni est la source ;

– N F orwardedRequestsi : Le nombre total de requˆetes pour lesquelles le nœud ni a ´et´e routeur ;

– N ReceivedRequestsi : Le nombre total de requˆetes `a destination du nœud ni.

Ensuite, nous additionnons chacune de ces m´etriques et d´eduisons le nombre moyen de sauts n´ecessaires au routage des requˆetes comme suit :

AverageP athLength = P i∈NN ReceivedRequestsi+P i∈NN F orwardedRequestsi P i∈NN InitiatedRequestsi (6.4)

Mesure de l’´equilibre des cl´es

Contrairement au mod`ele client-serveur qui centralise ses ressources, le mod`ele P2P les dis-tribue parmi l’ensemble des pairs participants. Les DHTs reposent sur des mod`eles qui appuient leurs propri´et´es de performance de localisation sur une r´epartition ´equilibr´ee des cl´es. La fonction de hachage qui g´en`ere les identifiants de nœuds et de cl´es garantit avec une tr`es forte probabilit´e que les cl´es seront r´eparties de mani`ere ´equitable parmi les nœuds pr´esents. N´eanmoins, dans le cas d’un d´eploiement r´eel d’une DHT, mettant en œuvre des pairs et des cl´es qui vont et viennent de mani`ere impr´evisible, il est impossible de savoir si cet ´equilibre sera toujours assur´e. Or, un d´es´equilibre de cette r´epartition peut fortement d´egrader les performances du processus de localisation. A l’extrˆeme, si seuls quelques pairs devenaient responsables de la majorit´e des cl´es, la DHT ne fonctionnerait plus selon le mod`ele P2P mais selon le mod`ele client/serveur, et elle ne pourrait plus garantir aucune propri´et´e en termes de passage `a l’´echelle, de tol´erance aux

fautes et d’´equilibre de la charge et du trafic. C’est pourquoi, dans notre travail de caract´erisa-tion de la performance de Chord, nous avons choisi de monitorer la r´eparticaract´erisa-tion de cl´es au sein d’un anneau. Pour cela, nous avons ´etabli une m´etrique qui mesure le niveau de respect de cet ´equilibre. Dans [153], les auteurs annoncent que chaque nœud Chord est responsable d’au plus (1 + ǫ)K cl´es. Nous proposons de surveiller cette valeur pour chaque nœud. D’un point de vue global, l’´equation 6.5 montre la mani`ere dont nous estimons l’´equilibre global d’un anneau. Pour chaque nœud ni, nous consid´erons la diff´erence entre le nombre de cl´es h´eberg´ees par le nœud et la valeur moyenne th´eorique estim´ee pour l’anneau. Nous effectuons ensuite la moyenne de ces ´ecarts pour chaque nœud participant et obtenons un indicateur, compris entre 0 et 1 qui repr´esente le niveau d’´equilibre de l’anneau.

N odesEquity%= 1 − ¹ KT

X

i∈N

⌊ | Ki− K | ⌋ (6.5)

En proposant cette d´efinition de m´etrique, nous ne faisons aucune supposition sur la mani`ere dont elle est calcul´ee. On voit que son calcul requiert la connaissance du nombre total de cl´es KT et du nombre moyen de cl´es par nœud K qui sont des valeurs globales qu’un nœud doit pouvoir d´eterminer. Plusieurs mani`eres sont envisageables pour les calculer. La premi`ere consiste `

a interroger un gestionnaire qui poss´ederait cette connaissance par le biais de la gestion. Cette m´ethode est syst´ematique et adh`ere au mieux `a la r´ealit´e. La seconde consiste `a proc´eder par estimation. Cette m´ethode est utilis´ee dans [103] pour estimer le nombre total de pairs pr´esents dans une communaut´e Viceroy. Chaque nœud interroge ses voisins et collecte des informations qui lui permettent de calculer une estimation de K et KT. De cette mani`ere le calcul de la m´etrique d’´equilibre de cl´es peut ˆetre accompli de mani`ere totalement distribu´ee.

Mesure de la coh´erence de l’anneau

Lorsque l’on consid`ere les performances d’une DHT, on se place dans un contexte statique, o`u les pairs et les cl´es ne changent pas d’´etat. Cependant, dans un contexte dynamique, on peut se demander ce que deviennent le bon fonctionnement et les performances du processus de routage. Comment un pair Chord peut il faire suivre des messages lorsque les entr´ees de sa table de routage sont erron´ees ? Et, Comment ´evolue le nombre moyen de sauts des requˆetes dans ce contexte ?

Nous pensons donc qu’ˆetre capable, d’un point de vue de la gestion, d’estimer la coh´erence d’un anneau est une information int´eressante, qui pourrait conduire `a diff´erentes actions de gestion. Par exemple, dans le cas o`u le niveau de coh´erence g´en´eral de l’anneau est trop bas, conduisant `a l’effondrement des performances du processus de localisation⁶, un gestionnaire pourrait ordonner l’ex´ecution du processus de maintenance sur certains nœuds afin de restaurer un niveau de coh´erence correct.

C’est pourquoi, en accord avec les d´efinitions propos´ees dans [153], nous avons d´efini trois contraintes qui d´efinissent la coh´erence des informations stock´ees dans les tables de routage de nœuds Chord. Elles sont :

– Contrainte 1 Coh´erence de l’anneau. Cette contrainte est respect´ee si, ´etant donn´e l’en-semble des nœuds pr´esents dans l’anneau, chaque nœud est effectivement le pr´ec´edent de son suivant.

– Contrainte 2 Coh´erence de la liste de suivants. Chaque nœud maintient une liste de k suivants dans l’anneau. Cette contrainte est respect´ee si, ´etant donn´e l’ensemble des 6

6.4. Instanciation du mod`ele de l’information sur Chord

nœuds pr´esents dans l’anneau, la liste maintenue par chaque nœud contient effectivement les suivants imm´ediats et si ces suivants sont joignables.

– Contrainte 3 Coh´erence de la table de routage. Cette contrainte est respect´ee si, ´etant donn´e l’ensemble des nœuds pr´esents dans l’anneau, chaque finger de chaque nœud respecte la relation f ingerk = suivant(ni+ 2k−1), o`u 1 ≤ k ≤ m et est joignable.

Etant donn´e les trois contraintes ci-dessus, nous consid´erons qu’un anneau Chord est coh´erent si, pour chaque nœud pr´esent, chacune d’elles est respect´ee. Ceci nous a conduit `a d´efinir, pour chaque nœud ni, quatre variables bool´eennes qui renseignent sur le respects de ces contraintes. La premi`ere, IsConsistenti indique si le nœud respecte ou non les trois contraintes. Les trois suivantes, SuccessorIsConsistenti, SuccessorListIsConsistentiet F ingerT ableIsConsistenti

renseignent sur le respect de chacune des contraintes respectives 1, 2 et 3.

Les valeurs prises par ces variables sont donn´ees par un gestionnaire qui peut les estimer par comparaison entre la vue qu’il poss`ede d’un anneau et les donn´ees de gestion issues de l’instrumentation des nœuds, telles que le pr´ec´edent, les tables de routage et la liste des suivants. Pour estimer le niveau de coh´erence globale d’un anneau Chord, le gestionnaire dispose de deux indicateurs. Le premier, IsGloballyConsistent, indique de mani`ere bool´eenne si l’anneau est dans un ´etat coh´erent ou non. Il est calcul´e d’apr`es la formule 6.6.

IsGloballyConsistent = ^

i∈N

IsConsistenti (6.6)

Le second affine l’information fournie par le premier en indiquant le niveau de coh´erence global de l’anneau. Il est calcul´e selon l’´equation 6.7 et d´efinit, sous forme de pourcentage, le niveau de coh´erence global. La fonction valueOf retourne 1 lorsque IsConsistent_i est vrai et 0 sinon. GloballyConsistencyLevel%= ¹ NT X i∈N valueOf (IsConsistent_i) (6.7)

Enfin, nous avons d´efini un dernier indicateur qui compte pour chaque nœud le nombre de fois o`u il est mal r´ef´erenc´e par d’autres nœuds. Cette indication aide `a localiser les zones de l’anneau qui sont dans un ´etat incoh´erent et permet par exemple `a un gestionnaire de provoquer l’ex´ecution du processus de maintenance seulement sur des nœuds qui sont mal r´ef´erenc´es.