Surcoût lié au taux de réplication

Nous avons vu que la création de répliques à r% permettait d’éviter la disparition des don- nées. Cependant, ces répliques induisent un coût par rapport à l’algorithme de réplication à la demande, que nous mesurons dans cette section.

Soit N le nombre de terminaux, r le taux de réplication et C le nombre de copies existantes. Deux situations sont possibles :

– C>N*r : on a plus de copies que nécessaire, et on fait donc l’hypothèse qu’elles sont toutes utiles. Cette hypothèse est permise par notre algorithme d’éviction de répliques présenté dans le chapitre suivante.

– C=N*r : on a exactement le nombre de copies nécessaire. Dans ce cas, il est possible que certaines ne soient pas utilisées par leur hôte.

Nous allons voir dans la section suivante comment, si de nombreuses copies ont été créées à un instant mais ne sont plus utilisées par la suite, et génèrent donc du trafic, elles sont éliminées, ce qui permet donc de maintenir le nombre de répliques au minimum nécessaire. Suite à l’application de cet algorithme, si le nombre de copies existantes est supérieur au nombre minimum requis, ces copies sont toutes utilisées. Il n’y a donc pas de surcoût. Quel est alors le surcoût de la réplication à n% par rapport à la réplication à la demande si on a seulement le nombre de copies maintenu par notre algorithme de réplication, c’est à dire que C=N*r ?

Soit c1 le nombre de copies utilisées par leur hôte, et c2 le nombre de copies non utilisées.

On a, bien entendu, c2 = C −c1. On suppose que si on utilisait un algorithme de réplication

Sur une période d’évaluation, chaque hôte utilisant la donnée génère en moyenne k mises à jour. Le nombre total de messages sur la période est donc :

nbT otM sg= c1∗ k ∗ (C − 1) = c1∗ k ∗ (N ∗ r − 1)

Les messages à destination des hôtes utilisant la donnée sont utiles, et génèrent donc le même nombre de messages que pour la réplication à la demande :

nbM sgU tile= c1∗ k ∗ (c1− 1)

Le nombre de messages inutiles est donc :

nbM sgSurcout= c1∗ k ∗ (c2) = c1∗ k ∗ (N ∗ r − c1)

On peut alors calculer le pourcentage de trafic généré en plus, par rapport à la réplication à la demande : portionSurcout= nbM sgSurcout nbT otM sg = c1∗ k ∗ (N ∗ r − c1) c1∗ k ∗ (N ∗ r − 1) portionSurcout= N ∗ r − c1 N ∗ r − 1

On voit donc que plus le nombre d’hôtes utilisant la donnée est élevé, plus la portion de messages inutiles diminue.

Cependant, cela ne signifie pas nécessairement qu’en nombre de messages, avoir moins d’hôtes utilisant la donnée crée plus de trafic. En effet, cette mesure est une portion du nombre total de messages : si c1=0, c’est à dire qu’aucun terminal ne crée de mise à jour,

le trafic total est nul.

Afin de déterminer le coût maximum en terme de messages, on dérive donc la fonction f permettant de calculer le nombre de messages en surcoût, en considérant r, N et k fixes.

f(c) = c ∗ k ∗ (N ∗ r − c) = c ∗ k ∗ N ∗ r − c2 f′_{(c) = k ∗ N ∗ r − 2 ∗ c}

La dérivée f’ s’annule pour c0 = k∗N ∗r₂

On peut donc en conclure que pour un nombre c0 = k∗N ∗r₂ de terminaux utilisant la donnée,

on génère le pire surcoût en terme de messages inutiles. f(c0) = c0∗ k ∗ N ∗ r − c20 f(c0) = k∗ N ∗ r 2 ∗ k ∗ N ∗ r − k∗ N ∗ r 2 2 f(c0) = (k ∗ N ∗ r)2 4

La figure 6.38 représente le pire surcoût en terme de message de manière graphique. Les axes du plan représentent le nombre de terminaux présents, et le nombre de répliques utilisées, tandis que l’axe vertical représente le nombre de messages en surcoût. On peut voir que si toutes les répliques, ou aucune, sont utilisées, aucun message supplémentaire n’est créé.

160 6. Réplication de données

Figure 6.38 – Surcoût lié au maintien de C répliques

6.7

Comparaison à l’existant

De nombreux systèmes ne proposent pas d’algorithme de réplication spécifique. Nous avons alors considéré que la réplication se fait à la demande. Un autre critère algorithme de réplication simple proposé dans l’état de l’art est une restriction de la réplication à la demande, où on crée une copie de la donnée en fonction de la distance de l’hôte la servant. Enfin, une troisième proposition est de créer des répliques des données très demandées, afin de les rapprocher de leurs utilisateurs.

Ces systèmes supposent l’existence d’un serveur, et ne prennent pas en compte la mobilité des terminaux. Dans une approche totalement distribuée, l’utilisation d’un algorithme de réplication à la demande crée le risque de perte des données les moins utilisées.

Le système adHocFS maintient par contre au moins une copie préventive de chaque donnée, en sus d’une réplique de travail, au sein d’un groupe. L’hôte de cette copie est choisi en fonction de ses capacités, notamment pour éviter qu’il disparaisse à cause d’un faible niveau de batterie. Ceci permet de tolérer la disparition d’un terminal mais n’est pas robuste en cas de partition.

Les algorithmes de réplication proposés par Hara placent pro-activement les données sur les terminaux les plus susceptibles de les utiliser, et répliquent collaborativement. Cepen- dant, ces algorithmes sont utilisés dans des réseaux de capteurs, et selon les algorithmes, supposent une connaissance totale des fréquences d’accès, une connaissance totale des fré- quences de mise à jour ou une connaissance de la corrélation pour chaque paire de données. Notre proposition ne nécessite pas une connaissance de la totalité des données, ni des in- formations citées ci-dessus.

6.8

Conclusion

Dans ce chapitre nous avons présenté un algorithme de réplication de données pro-actif et se basant sur une prédiction des accès utilisateurs pour placer les données.

Nous avons vu que créer pro-activement des données permet d’en limiter les disparitions, qui, comme nous travaillons dans un système sans serveur, risquent d’être définitives. Par ailleurs, la réplication au prorata du nombre de terminaux permet de mieux supporter les partitions du réseau.

Nous avons ensuite vu que le placement prédictif permet de faire diminuer la distance moyenne d’accès à une donnée. Ce résultat nécessite cependant d’avoir une bonne métrique pour prédire les accès. La réplication collaborative permet elle-aussi de diminuer cette distance pour les terminaux ayant un espace de stockage plus réduit que celui de leurs voisins.

Enfin, nous avons déterminé que la partie probabiliste de notre algorithme se termine en moyenne en moins de deux itérations.

Nous avons ensuite comparé cet algorithme à la réplication à la demande et borné le sur- coût qu’il engendre en terme de charge réseau. Nous avons tout d’abord calculé le surcoût engendré par la création des K répliques attendues par notre algorithme, plutôt que d’at- tendre leur création à la demande, puis le surcoût engendré par les répliques non utilisées.

Un terminal ne peut pas héberger des répliques à l’infini : il doit parfois éliminer une copie locale afin de faire place à une nouvelle donnée. Dans le chapitre suivant nous présentons l’algorithme de remplacement de cache utilisé dans ces circonstances.

Chapitre 7

Remplacement de cache et éviction

de répliques

7.1 Libérer de l’espace mémoire . . . 164

7.1.1 Principe . . . 164