Réplication selon la disponibilité des nœuds

Notre deuxième stratégie est fondée sur une réplication selon la disponibilité des nœuds. En effet, la disponibilité de données est liée essentiellement à la disponibilité des nœuds. En

effet, un nœud est dit disponible s’il peut remplir la mission ou la fonction pour laquelle il a été conçu à un instant donné ou pendant un intervalle de temps donné.

Le principe de cette approche consiste alors à vérifier le taux de disponibilité du chemin créé pendant la phase de souscription pour réduire le nombre de chemins répliqués et avoir en même temps le chemin le plus fiable. En effet, ce chemin présente le chemin d’acheminement des notifications pendant la phase de publication. Pour ce faire, nous supposons que l’iden-tifiant d’un nœud sur DHT reflète le taux de leur disponibilité. Chaque nœud DHT possède une valeur de disponibilité notée a.

Cette valeur de disponibilité a représente la durée de la disponibilité du nœud pour la ré-ception d’un flux de messages. Cette durée dépend du taux de churn du parent dans l’arbre de multicast. Cependant, dans le cas où un parent se déconnecte, une telle DHT possède ces propres mécanismes de réparation pour rétablir la situation du fils, c’est-à-dire le fils qui perd un parent, s’attache automatiquement à un nouveau parent. Mais, à chaque dé-connexion d’un nœud parent, il faut un temps, noté ∆, pour s’attacher à un autre parent et continuer à recevoir le flux de messages. Alors pour une telle déconnexion, la durée de la non-disponibilité du nœud pour la réception du flux correspond exactement au temps ∆ (Indisponibilité = 1 - Disponibilité). Ainsi, la disponibilité de réception de flux a peut être décrite par la formule 5.1.

a= ^{unité de temps de churn}−nombre de churn du parent du noeud∗∆

unité de temps de churn ^(5.1)

Par exemple, si le churn du parent d’un nœud est de 1 déconnexion par 1 heure, et pour s’attacher à un autre parent demande 30 secondes, alors la disponibilitéa de ce nœud vaut :

a= ³⁶⁰⁰−1∗30

3600 ^{= 0.991 (5.2)}

Ainsi, pour chaque nœud qui s’ajoute au chemin de la souscription, la valeur de disponibi-lité a du nœud est calculée. Par conséquent, chaque branche de l’arbre de multicast (chemin du souscrit au root définit par l’ensemble des nœuds parcourus), a aussi une valeur de dispo-nibilité bien déterminée. Pour calculer cette valeur, nous appliquons la règle de dispodispo-nibilité pour un système en série. Il suffit alors de multiplier les valeurs de disponibilité de tous les nœuds formant la branche en question pour trouver la disponibilité totale donnée par la formule5.3. Ceci nous permet d’associer une valeur de disponibilité à chaque chemin utilisé

Chapitre 5

pour acheminer une souscription de l’utilisateur vers le nœud root responsable de mémoriser cette souscription. A = n Y i=1 (a_i) (5.3) Avec :

– A : disponibilité totale du chemin ;

– ai : disponibilité d’un nœud calculé par la formule 5.1;

– n : le nombre de nœuds parcourus par la souscription.

Donc, si par exemple un fils possède 5 parents pour s’attacher à la racine avec une même valeur de disponibilité pour tous les parents qui vaut 0.991 donnée par la formule5.2. Alors,

la disponibilité totale A est le produit de disponibilité de tous ces nœuds parents comme

exprimé par la formule suivante :

A=

5

Y

i=1

(0.991) = 0.955 (5.4)

Afin de garantir la disponibilité des données, nous fixons un taux de disponibilité accepté, dit aussi taux de disponibilité souhaité, à atteindre pour assurer la fiabilité totale de notre plateforme. Ce taux est noté A_souh. Par conséquent, nous cherchons à faire des réplications de souscriptions si le taux souhaité n’est pas encore atteint. Pour ceci, nous comparons la valeur de disponibilité atteinteApar rapport àA_souh. Si la valeur de disponibilité du chemin est supérieure ou égale à la valeur de disponibilité souhaitée, alors ce chemin est maintenue et considéré comme un chemin fiable assurant la disponibilité souhaitée des données. Dans le cas où la valeur de disponibilité de chemin est strictement inférieure à la valeur de disponibilité souhaitée, le chemin est considéré comme insuffisant et un deuxième chemin doit être établit

pour atteindre ou dépasser A_souh. Par la suite, nous cherchons un chemin complémentaire

ayant une disponibilité que nous appelons disponibilité complémentaire pour atteindre la valeur de disponibilité totale souhaitée. En utilisant la formule de calcul de disponibilité pour un système en parallèle, nous devons vérifier l’égalité donnée par l’équation 5.5. En effet, les chemins de réplication sont considérés comme des composants liés en parallèle puisque l’un de ces chemins permet d’acheminer une publication du root au souscrit.

Avec :

– A : taux de disponibilité du chemin parcouru calculé par la formule 5.3;

– A_comp : taux de disponibilité du chemin complémentaire ;

– A_souh : taux souhaité de la disponibilité total.

Ensuite, le chemin complémentaire est choisi par son premier nœud (nœud fils) ayant la disponibilité supérieure ou égale ou la plus proche de A_comp. D’après 5.5, A_comp vaut :

Acomp = ^A−A_souh

A−1 ^(5.6)

Enfin, nous cherchons l’identifiant du nœud complémentaire, correspondant à la valeur de la disponibilité complémentaire trouvée par5.6. Pour ce faire, nous convertissonsA_comp à un identifiant exprimé dans la base hexadécimale en utilisant la formule5.7. Une fois retrouvé, nous répliquons la souscription à partir du nœud d’identifiantID_{DHT_comp} et nous calculons le taux de disponibilité totale de tous les chemins créés. Si le taux total, notéA_tot, calculé par la formule5.8 (disponibilité d’un système en parallèle) est encore inférieur à la disponibilité souhaitée, nous répétons la même démarche jusqu’à atteindre le taux souhaité.

IDDHT_comp = [Acomp∗2¹²⁸]_Hexa (5.7)

A_tot = 1− n Y i=1 (1−A_i) (5.8) Avec :

– A_i : la disponibilité du chemin parcouru calculée par5.3; – n : le nombre de chemins créés ;

– A_tot : la disponibilité totale de tous les chemins créés.

5.5 Évaluation des performances

Ces approches sont implémentées sur le système publier/souscrire Scribe intégrant le si-mulateur Freepastry et fondé sur la DHT Pastry. Nous faisons des expérimentations pour la validation de la première stratégie de réplication dans une première partie puis une compa-raison entre les deux stratégies proposées dans une deuxième partie.

Chapitre 5