Étude de faisabilité d un système de Sauvegarde Collaborative en Pair-à-Pair

École Normale Supérieure de Lyon Master Informatique Fondamentale 2 e année Étude de faisabilité d un système de Sauvegarde Collaborative en Pair-à-Pair Stage effectué sous la supervision de Fabrice Le Fessant équipe ASAP, INRIA-Futurs Saclay <Fabrice.Le_fessant@inria.fr> Samuel Bernard samuel.bernard@ens-lyon.org 22 juin 2007

Résumé Les réseaux pair-à-pair (ou peer to peer en anglais), rendus possibles par l augmentation des débits des connexions Internet personnelles, génèrent de nouveaux usages des réseaux. Ainsi, il devient envisageable de partager l espace disque libre des ordinateurs sur Internet pour sauvegarder les données de pair à pair. Nous allons étudier la faisabilité de cette sauvegarde collaborative dans ce rapport.

Table des matières 1 Introduction 2 1.1 Historique................................ 2 1.2 Intérêt.................................. 2 1.3 Difficultés................................ 3 1.4 Objectif................................. 3 2 La sauvegarde collaborative en pair-à-pair 4 2.1 Descriptif de la solution......................... 4 2.1.1 Prérequis............................ 4 2.1.2 La sauvegarde......................... 5 2.1.3 La mise-à-jour......................... 6 2.1.4 La récupération......................... 6 2.2 Analyse................................. 6 2.2.1 La réparation.......................... 6 3 Simulations 8 3.1 Hypothèses............................... 8 3.2 Protocole................................ 8 3.3 Répartition des noeuds......................... 9 4 Résultats 10 4.1 Les paramètres............................. 10 4.1.1 Les profils........................... 10 4.2 Discussion sur les paramètres...................... 11 4.3 Présentation des résultats........................ 12 4.3.1 L importance de l ancienneté.................. 12 4.3.2 Les résultats pour les nœuds d âge médian........... 13 4.3.3 Analyse des résultats...................... 14 5 Travaux existants 15 5.1 Les systèmes existants......................... 15 5.2 Autres travaux.............................. 16 6 Conclusion 18 6.1 Conclusion............................... 18 6.2 Travaux ultérieurs............................ 18 A Résultats complémentaires 21 1

Chapitre 1 Introduction 1.1 Historique L équipe ASAP (INRIA-Futurs Saclay) est engagée dans un projet de développement d une plate-forme de sauvegarde collaborative de données : en utilisant l espace disponible sur les disques durs de toutes les machines connectées en réseau, il est possible de sauvegarder les données de ces machines, tout en préservant leur confidentialité par un chiffrement adapté (cryptographie). Ceci pourrait être rendu possible par la banalisation des connexions haut débit chez les particuliers et la taille importante des espaces de stockage actuellement disponibles. 1.2 Intérêt La sauvegarde des données est devenu un problème crucial aujourd hui. D un côté, les particuliers possèdent de plus en plus de données personnelles numériques (courriels, photos, etc). De l autre, tous les acteurs économiques utilisent aujourd hui l informatique quotidiennement pour traiter et stocker leurs informations, souvent vitales pour les entreprises. Dans les deux cas, rares sont encore ceux qui ont pris conscience de l importance de la sauvegarde de ces données, et ont les moyens d acquérir les coûteux systèmes de sauvegarde existants. L objectif est donc de fournir un système gratuit, fondé sur l échange d espace de stockage libre entre les participants, et intégrant des mécanismes avancés de tolérance aux pannes et de protection des données, aussi bien pour en maintenir l intégrité que la confidentialité, s adressant aussi bien aux particuliers qu aux petites entreprises (artisans, commerçants, PME) connectées à Internet. Ce système sera intégré dans le logiciel Peerple, logiciel d accès sécurisé à ses données à distance, développé en collaboration avec l équipe GANG de l INRIA Rocquencourt. Plusieurs projets de recherche à travers le monde ont travaillé sur une telle application, mais jusqu à présent, aucun système équivalent n a vu le jour. La plupart des projets n ont pas dépassé le stade théorique ou les simulations, tandis que les quelques projets implantés sont trop restrictifs et n offrent pas les garanties nécessaires. 2

1.3 Difficultés Comme le montre le peu d applications existantes dans ce domaine, de nombreux problèmes restent encore à résoudre. Par exemple, l aspect hautement dynamique du réseau - dont les membres peuvent se déconnecter, temporairement ou définitivement, à tout moment - impose une surveillance permanente de l état de la sauvegarde. Ainsi, il peut s avérer nécessaire de réparer celle-ci en redéployant les fragments de données sur des machines plus stables, voire dans le pire des cas, de recommencer une sauvegarde des données dont la sauvegarde précédente est devenue incertaine. De même, l utilisateur peut être amené à effacer volontairement certains fichiers de son ordinateur et il n est alors plus nécessaire de sauvegarder ces fichiers, qui utilisent inutilement un espace de stockage précieux : l expansion des données par les codes correcteurs d erreurs et la distribution des fragments sur de multiples ordinateurs rendent néanmoins cette récupération d espace complexe. Elle peut aussi nécessiter de recommencer une sauvegarde des données encore utiles. 1.4 Objectif L objectif de ce stage était d évaluer le coût lié à la dégradation de l état de la sauvegarde, causée aussi bien par la dynamique du réseau que par l effacement des fichiers par l utilisateur. Ce coût peut s avérer rédhibitoire pour la sauvegarde collaborative dans l état actuel des connexions Internet. C est donc une étude de faisabilité. D autre part, si ce coût est tolérable, son estimation doit permettre de comprendre les paramètres du système dont il dépend, de comprendre leur influence sur les seuils de déclenchement des réparations, ainsi que d optimiser ces réparations par le choix de la bonne politique de réparation. Le plan de ce rapport est le suivant : 1. Description des processus mis en œuvre dans la sauvegarde collaborative 2. Spécifications des simulations réalisées 3. Résultats obtenus 3

Chapitre 2 La sauvegarde collaborative en pair-à-pair 2.1 Descriptif de la solution Voici une présentation détaillée des différents processus envisagés pour réaliser la sauvegarde collaborative de données dans Peerple. 2.1.1 Prérequis Pour notre système, nous avons besoin des prérequis suivant : Espace libre Un réseau avec de l espace disque, les participants doivent fournir de l espace en échange du stockage de leurs données. Nous ne nous attarderons par sur ce point, car nous supposons que cela ne pose pas problème, la plupart des personnes n utilisent pas complétement l espace fourni par les disques durs actuellement livrés en standard dans les ordinateurs personnels. Ils n auront donc aucune difficulté à en réserver une partie pour le système de sauvegarde en échange de l assurance que leurs données soient en sécurité. Connectivité totale Nous supposons que les machines sont toutes connectées entre elles, c est-à-dire qu elles ont la capacité de communiquer avec n importe quelle autre. Le processus nous amenant cette propriété n est pas l objet de cette étude. Cependant, on peut imaginer un réseau non structuré de type mesh animé par un protocole de routage (et utilisant des diffusions limitées pour la découverte de nouveaux nœuds). Surveillance de l ancienneté Pour la sélection de partenaires, nous avons besoin d avoir une estimation de la fiabilité d un nœud. Il est montré expérimentalement ([4], [21] et [28]) que cette fiabilité est en forte corrélation avec l ancienneté dans le réseau. Donc pour notre estimation de la fiabilité d un nœud distant, nous utiliserons son âge. 4

Mais pour cela, nous avons besoin de connaître de façon fiable l ancienneté d un nœud, au moins jusqu à une certaine limite (actuellement 90 jours). Nous supposons que cela nous ait donné par un système de surveillance, sur lequel travaille aussi l équipe ASAP mais dont les détails ne sont pas utiles ici. Cryptographie Nous supposons l utilisation de cryptographie pour garantir la confidentialité des données. Les techniques utilisées sont orthogonales aux mécanismes de réparation que nous étudions, et ne sont donc pas décrites dans ce rapport. Codes correcteurs d erreurs Les codes correcteurs d erreurs servent à corriger les pertes d information dans un système distribué. Dans notre cas, des blocs de données peuvent être perdus, parce que l hôte les possédant s est déconnecté définitivement du système. Pour y remédier, des blocs correcteurs d erreur, redondants avec les blocs initiaux, sont créés préventivement. Ainsi, il est possible de recomposer les données même si des blocs sont perdus, en utilisant les blocs correcteurs d erreur. Dans Peerple, le codage utilisé est Reed-Solomon. Le grand avantage des blocs créés par ce codage est qu il est possible de remplacer n importe quel bloc de données initiales par n importe quel bloc correcteur d erreurs. Par exemple, si l on considère 128 blocs de données, en créant 128 blocs correcteurs d erreurs associés, l espace de stockage utilisé est deux fois plus important, mais les données peuvent être reconstruites avec n importe quel sous-ensemble de 128 blocs parmi les 256 blocs. Par conséquent, avec un bloc par hôte, le système tolère 128 pannes pour 256 machines, ce qui est bien plus efficace que la réplication habituelle qui peut perdre des données à partir de deux pannes. 2.1.2 La sauvegarde Les différentes étapes de la sauvegarde : 1. On crée la liste des fichiers, et si ce n est pas la première sauvegarde, la listedifférence entre l ancienne liste et la nouvelle. 2. On copie les fichiers à sauvegarder dans un tampon, ils sont chiffrés puis agrégés en composantes de 128Mo, à découper en 128 blocs chacune. 3. Pour chaque composante, en plus des blocs initiaux, on calcule 128 blocs correcteurs d erreurs, nous donnant en tout 256 blocs dont 128 sont nécessaires pour reconstruire les données. 4. On répartit chacun de ces blocs sur un partenaire, chaque fragment contient l identifiant (ID) du propriétaire et son numéro de composante et de bloc. 5. Parallèlement, on crée des blocs de méta-données de même taille, agrégés de la même façon, contenant la liste des fichiers sauvegardés (méta-données, clef de chiffrement, composante contenant le fichier et position dans celle-ci), et la date et le numéro de vue de la sauvegarde. On ajoute aussi pour chaque bloc cité, les partenaires qui en stockent un fragment. 6. Comme pour les données, pour chaque composante de méta-données, on calcule 128 blocs supplémentaires correcteurs d erreurs et on les répartit sur les partenaires de la même façon. 5

7. On met à jour le bloc "maître" contenant la liste des partenaires, la liste des composantes de méta-données et les clés de chiffrement utilisées pour les métadonnées. 8. Chaque partenaire stocke ce bloc "maître". Les composantes sont marquées données ou méta-données. 2.1.3 La mise-à-jour Après avoir fait la premère sauvegarde, on va vouloir la réactualiser de temps en temps : 1. On sauvegarde vue par vue (si le tampon n est pas assez grand pour contenir toutes les données à sauvegarder, on le fait en plusieurs fois, en prenant les fichiers dans leur état actuel, même s ils ont été modifiés depuis le moment où l on a calculé la liste-différence et sans prendre en compte les nouveaux fichiers et les dépendances entre versions de fichier). 2. On modifie la liste-différence pour prendre en compte les fichiers que l on vient de sauvegarder, pour ne pas les sauvegarder de nouveau dans le même état à la prochaine sauvegarde. 3. Les sauvegardes sont cumulatives, on ne modifie pas les données précédentes, on rajoute des composantes. 4. Les fichiers sont à chaque fois stockés entièrement. 5. On pourra compléter les blocs par des fichiers tampons, permettant de sauvegarder immédiatement les derniers fichiers (on ne sauvegarde que des blocs complets). 2.1.4 La récupération En cas de perte totale, 1. On doit posséder le bloc "maître" (ou le demander par diffusion, mais il faut pouvoir le déchiffrer). 2. On contacte chacun de ses partenaires et on demande toutes nos méta-données (en donnant les numéros des composantes et leur ID). 3. Avec les méta-données, on recrée la base de données, associant les fichiers (avec leur version) avec leurs blocs, composantes et partenaires. 4. À partir de là, on demande à chaque partenaire les blocs que l on a besoin pour restaurer nos données. Au cas où l on veut juste récupérer quelques fichiers, vu que l on possède en permanence la base de données en local, il suffit de demander les blocs correspondants à nos partenaires. 2.2 Analyse 2.2.1 La réparation Les sauvegardes effectuées doivent être maintenues, c est à dire que l on doit s assurer qu elles sont toujours cohérentes, mais aussi, on veut récupérer l espace utilisé par des fichiers maintenant obsolètes. 6

Protocole On récupére suffisament de blocs pour recomposer la composante, on les agrége de nouveau pour recréer une nouvelle composante pleine et de nouveaux blocs de codes d erreurs puis on les réémet. On n oublie pas de mettre à jour les méta-données en marquant les anciens blocs comme "À effacer". Causes Les causes pouvant amener à une réparation sont : Élimination des fichiers obsolètes Augmentation de la redondance Notons que l on peut réaliser les deux objectifs en même temps, c est pour cela que pour simplifier, nous allons pour l instant négliger le problème d obsolescence. Coût Le coût est : C récupération + C travail local + C réemission + C méta données La puissance de calcul des ordinateurs actuels est telle que le coût en puissance machine est négligeable par rapport au coût en bande passante, facteur limitant de notre système. On suppose que les connexions au réseau sont asymétriques, avec un débit en réception entre 4 et 20 fois plus rapide. De ce fait, on considère que la reception de données n est limitée que par la vitesse d envoi des partenaires. On considère une connexion disposant d un débit de 1 Mb/s en émission. Cette valeur peut être atteinte par des offres grand public chez la plupart des opérateurs. Comme une composante fait 2*128Mo, on mettra moins de 40 minutes pour l envoyer, et en prenant 10 minutes de marge pour la réception, les calculs et la mise à jour des méta-données (qui consomme aussi du réseau), on arrive à moins d une heure. Le système peut donc être viable avec une réparation par heure. Mais, dans ces conditions, le système n est plus du tout transparent pour l utilisateur et devient inutilisable sur des connexions moins rapides. De plus, un utilisateur peut avoir plus d une composante, et s il doit réparer celles-ci une fois par heure, sa connexion sera saturée. L objectif minimum est donc d arriver en moyenne à une réparation par centaine d heure, laissant ainsi de la marge pour plusieurs composantes et/ou une connexion moins rapide. Paramètres On cherche à déterminer quand il faut effectuer la maintenance de redondance : Cela dépend du taux de redondance et de la vitesse à laquelle on perd des blocs, vitesse surveillée par le client. On place une valeur fixe, par exemple 20% de fragments redondants, si l on passe en dessous de ce seuil pendant un certain temps, la réparation est déclenchée. Dans le chapitre suivant, nous vérifions expérimentalement, par la simulation si ces différentes stratégies sont pertinentes et si elles permettent bien d atteindre les objectifs initiaux. 7

Chapitre 3 Simulations Une partie essentielle de mon travail a porté sur la création d un simulateur. Pour cela, j ai utilisé peersim [16] qui me fournit le squelette du simulateur. Les simulations ont un déroulement organisé en cycles, dans lesquels un certain nombre de tâches sont effectuées séquentiellement, mais dans un ordre aléatoire. C est à opposer au déroulement par évènements où toutes les tâches sont effectués en concurrence. C est à priori moins réaliste, mais mes simulations sont gros grains, c est à dire que je considère de longues échelles de temps peu précises (la précision est d une heure). Cela parce que je ne m interesse qu à des tâches de haut niveau, prenant un temps important (comme la réparation). Ainsi en prenant des cycles d une heure, je suis suffisament réaliste tout en gardant la simulation simple et rapide (me permettant de simuler plusieurs années). 3.1 Hypothèses Avant de réaliser les simulations, posons quelques hypothèses : Indépendance On suppose que les départs/arrivées/déconnexions/reconnexions des hôtes sont sans relations. Il s avère que cette hypothèse est globalement réaliste, puisque vérifiée expérimentalement sur les réseaux pair-à-pair actuels [2]. Fidélité Les nœuds qui sont depuis longtemps dans le système ont une plus forte probabilité d y rester à l avenir. En d autres termes, si une personne utilise depuis longtemps un service, il n y a pas de raison pour qu elle s en aille dans les jours qui viennent ([4], [21] et [28]). Cette propriété est très importante, puisqu elle fait de l ancienneté le principal critère de sélection des partenaires. 3.2 Protocole Voici le protocole utilisé pour réaliser les simulations : 8

Arrivée Un nœud arrive dans le réseau : Il cherche 256 autres nœuds (partenaires) pour y stocker ses données. Pour ça, il essaye de se consistuer un ensemble de partenaires possibles, c est à dire des nœuds l ayant accepté pour stocker des données chez eux. Il choisit parmis cet ensemble les meilleurs nœuds d après le critère de l ancienneté et y stocke ses blocs. Acceptation La fonction d acceptation, actuellement implantée ne prend en compte que l ancienneté des deux nœuds qui intéragissent. Elle est de la forme : ( palier (min(ancienneté1, palier) min(ancienneté 2, palier)) + 1 f p1 (p 2 ) = palier et donne la probabilité d accepter que le nœud distant p 2 stocke des données sur le nœud local p 1. Les paramètres : palier qui est l ancienneté à partir de laquelle on déclare qu un nœud est stable. Elle est de 90 jours dans la simulation présentée plus loin. k sert à définir la souplesse de l acceptation : si k > 1, il sera plus dur aux nouveaux nœuds d être accepté par des partenaires âgés, à l inverse du cas où 0 < k < 1. Dans la simulation présentée, k = 1. Ensuite Ensuite, chaque cycle (qui représente pour nous une heure) : Le nœud interroge ses partenaires pour savoir s ils possèdent toujours ses données. Si un partenaire n est pas en ligne, on considère que nos données stockées chez lui sont perdues. Si plus qu un certain nombre (le palier de réparation) de partenaires ont répondu favorablement, il ne fait rien (dans la simulation présentée, ce palier est de 152 blocs disponibles sur 256). Sinon, il doit réajuster la redondance de ses données. Pour ça : Il remplace tous les partenaires absents par des nouveaux, ce qui nécessite de les trouver en utilisant le même mécanisme qu à l arrivée. Le mécanisme de la réparation a été détaillé dans le chapitre précédent. 3.3 Répartition des noeuds Tous les nœuds ne vont pas avoir le même comportement dans le système. Certains vont être très sérieux et avoir un faible taux de déconnexions, d autres, au contraire, vont être souvent déconnectés et partiront sans préavis du système, emportant avec eux les sauvegardes des premiers. Nous nous devons de simuler cet état. Pour cela, les nœuds du réseau sont classés dans des profils. Un profil indiquera à chacun sa fiabilité et donnera une estimation de son espérance de vie dans le système. En jouant sur les profils, on peut simuler des systèmes plus ou moins instables et voir si les protocoles de restaurations restent valables et efficaces. ) k 9

Chapitre 4 Résultats Je vais présenter dans ce chapitre le résultat d une des simulations. 4.1 Les paramètres Les paramètres de cette simulation sont : La taille du système, après une phase de croissance, est d environ 32000 nœuds. Les nœuds doivent faire stocker 256 blocs, dont 128 sont nécessaires. Le palier de réparation est fixé à 152 blocs disponibles sur 256. Les nœuds peuvent stocker chez eux au maximum 512 blocs. Ils choissent leurs partenaires parmi 2048. La simulation dure 60000 cycles, ce qui en temps réel donne un peu plus de 6 ans. Ce temps très long s explique par la phase de démarrage pendant laquelle on doit laisser le système se stabiliser. 4.1.1 Les profils On utilise pour cette simulation 4 profils différents. Du plus stable au moins stable : Les très stables Ils représentent 10% des nœuds du système. Ils sont permanents, c est à dire qu ils ne quittent jamais le système. Leur taux de déconnexion/reconnexion est de 1%/20%, c est à dire que toutes les heures (cycles), 1% des nœuds se déconnectent temporairement et 20% des nœuds déconnectés reviennent sur le réseau. De ce fait, en moyenne, 1/21 des nœuds sont déconnectés à un moment donné. Ils représentent des machines très fiables, que l on n éteint jamais. Les stables Ils représentent 25% des nœuds du système et ont une durée de vie comprise entre un peu plus d un an et 3 ans, donc très importante. On pourrait presque les assimiler aux nœuds du profil précédent mais ils ont un taux de déconnexion/reconnexion un peu plus important, de 3%/20% donnant la proportion de 3/23 déconnectés à un moment donné. 10

Ce profil représente les personnes utilisant sérieusement le système, avec peu de déconnexions, et une présence sur le long terme. Les moyennement stables Leur proportion est de 30% du réseau. Leur durée de vie est comprise entre 3 mois et un peu plus d un an. Ils représentent des personnes essayant et utilisant le système sur une longue période mais en n y trouvant pas satisfaction (notamment parce que le système a un coût continu alors que son utilité se fait uniquement ressentir rarement et sur de brèves périodes). Leur assiduité est inférieure aux profils précédents, puisqu ayant des taux de 5% et 15%. On remarque qu on commence à atteindre des taux de déconnexions non négligeables, car la plupart des nœuds se déconnecteront au moins une fois par jour et mettront plusieurs heures à se reconnecter. D ailleurs en moyenne, à un instant donné, un quart des nœuds sont déconnectés. Les instables Notre but est de prouver que la réalisation d un système de sauvegarde collaborative fonctionnant à l aide d un réseau pair-à-pair est possible. Pour cela, il faut introduire une large part de nœuds instables. Nous l avons fixée ici à 35%. On ne peut pas compter sur les nœuds appartenant à ce profil pour y stocker des données sur le long terme. Leur durée de vie est comprise entre une heure et 3 mois. Leur taux de déconnexion est de 20% et leur taux de reconnexion de 10%. Cela nous donne 2/3 des nœuds déconnectés à tout moment, ce qui est très faible. Pour conclure sur les profils, environ un tiers des nœuds sont très stables et conviennent pour la sauvegarde, un autre tiers est moins stable et pourrait poser quelques problèmes, et enfin, le dernier tiers est trop instable pour être utilisable. Il reste à savoir, si le tiers instable empêche les nœuds stables d obtenir de bonnes performances (en terme de réparation). 4.2 Discussion sur les paramètres Les paramètres n ont pas été choisis au hasard. Pour la composition des profils, cela n a pas été aisé. En effet, étant donné qu il n existe actuellement aucun système du genre (sauvegarde collaborative sur un réseau pair-à-pair) déployé à large échelle, il n existe pas de résultats expérimentaux sur le comportement des utilisateurs. Cependant, les systèmes pair-à-pair d échange de fichiers existent depuis quelques années et des études ont été menées sur la dynamicité de ces réseaux [2]. Nous sommes donc parti de ces études pour créer nos profils. Le profil très instable dérive directement du comportement des utilisateurs des systèmes d échanges. Puis nous avons anticipé le comportement possible des utilisateurs d un système de sauvegarde, et nous avons créé les autres profils en prenant soin d avoir toujours une approche pessimiste pour veiller à que dans tous les cas, le système soit viable. Ainsi le taux de déconnexion n est jamais négligeable, puisque même dans le profil stable, un nœud a 50% de chance de se déconnecter par jour et ce, pour plusieurs heures. Concernant la taille de la simulation, des réseaux plus importants ont été simulés, sans que cela n affectent les résultats. En réalité, du fait que les nœuds recherchent des 11

30 Anciennete de 3 mois Anciennete de 1 mois et demi Anciennete de 3 semaines Anciennete de 1 heure 25 20 Reparations cumulees 15 10 5 0 0 10000 20000 30000 40000 50000 60000 Heures FIG. 4.1 Comparatif du nombre de réparations réalisées par des hôtes d âges différents : Les nœuds anciens réparent moins souvent. partenaires, ils ont tendance à s aggréger en cluster. De ce fait, la simulation d un tel cluster revient à simuler le système entier. 4.3 Présentation des résultats 4.3.1 L importance de l ancienneté Tout d abord, la figure 4.1 montre le nombre total de réparations effectuées par des nœuds totalement stables et ayant des anciennetés fixées. Quatre nœuds sont présentés : Le premier a une ancienneté de l ordre de la valeur palier de la fonction d acceptation (3.2), c est à dire 3 mois (ou 2200 cycles). Le deuxième a une ancienneté égale à la moitié de palier. Le troisième a une ancienneté qui vaut 1/4 de palier. Et enfin le dernier représente un nouvel arrivant, et a une ancienneté égale à 1. Les résultats sont que le nombre de réparations effectuées par le nouvel arrivant est bien supérieur à celui des autres, puisqu étant de 7-8 réparations tous les 10000 cycles (équivalent à une année), à comparer au taux des autres qui vaut entre 1 et 3 réparations par an. On note aussi que plus un nœud est ancien, moins il répare, même si la différence est moins flagrante pour les 3 premiers nœuds. À noter aussi les bons résultats dans tous les cas, au pire de l ordre du pour mille. 12

18000 16000 noeuds noeuds actifs reparation(pour mille) 2.5 14000 2 12000 Noeuds 10000 8000 1.5 1 Reparations pour mille noeuds 6000 4000 0.5 2000 0 0 10000 20000 30000 40000 50000 60000 Heures FIG. 4.2 Taux de réparation pour les nœuds ayant entre 6 mois et 2 ans. Les courbes sont dans l ordre, de haut en bas, le nombre de nœuds total pris en compte, puis le nombre de nœuds actifs et enfin le nombre de réparations. 4.3.2 Les résultats pour les nœuds d âge médian La seconde courbe, figure 4.2 présentée dans ce chapitre montre l évolution du taux de réparation pour les nœuds âgés entre 6 mois et 2 ans. Pour indication est aussi présent le nombre de nœuds actuellement dans le réseau et satisfaisants la condition d ancienneté, ainsi que la part active, c est à dire non déconnectés. Les résultats sont, qu après une phase d initialisation de 30000 cycles (due au démarrage de la simulation, qui est non-réaliste car un grand nombre de nœuds se connectent au même moment), le taux de réparation et le nombre de nœuds se stabilisent. La réparation est aux alentours de 0.025% correspondant, pour un nœud, à une moyenne d une réparation tous les 4000 cycles, soit une fois tous les 5 mois. On est donc dans une bonne moyenne, largement au dessus de la limite de faisabilité. Pour ne pas surcharger ce chapitre de courbes, celles présentant les résultats pour les nœuds d âge différents sont en annexes A. Pour résumer, elles confirment que le taux de réparation décroît en fonction de l ancienneté d un nœud. Un autre résultat important est qu il n y a pas de données perdues dans le système, c est à dire de données qu on ne peut plus réparer (dont le nombre de blocs disponibles est inférieur à 128 blocs), ou alors très localement et dans les classes de nœuds très instables. 13

4.3.3 Analyse des résultats Les raisons de la corrélation très forte entre l ancienneté et les résultats s explique, d une part, parce que le nœud âgé arrive plus facilement à stocker sur d autres nœuds agés, donc à priori plus stables. Et d autre part, parce qu après de multiples réparations, il arrive à rassembler un sous ensemble de partenaires très stables, avec lequels il formera un cluster très fiable. Mais il faut aussi noter la relativement bonne performance des jeunes nœuds, ce qui reste important pour ne pas décourager les nouveaux utilisateurs. En conclusion, dans tous les cas, le système est viable, avec même une marge importante, aucune donnée perdue, ce qui nous permet d appréhender avec optimisme les problèmes à venir. 14

Chapitre 5 Travaux existants 5.1 Les systèmes existants Dès les années 2000, de nombreux systèmes ont été élaborés, plus ou moins différents sur certains aspects de leur architecture. Cependant, peu ont atteint le stage du prototype et aucun ne l a dépassé pour être exploité en conditions réelles. Dans l ordre chronologique : Le plus ancien, OceanStore ([19] et [23]) est un système orienté sauvegarde et stockage, sauvegarde parce que l on veut que nos données soient conservées avec fiabilité et stockage parce qu on doit pouvoir y accèder rapidement. Il repose sur une table de hashage distribuée (DHT) et utilise à la fois les réplications simples et les codes correcteurs d erreurs. Les premières pour assurer de bonnes performances en lecture et les seconds pour obtenir une bonne réplication des sauvegardes. Le système de mises à jour des données dans le système est particulier, il repose sur un inner ring, ensemble de machines, différent pour chaque client, responsable de la propagation de la dernière version, et pouvant la certifier à tous. Ce inner ring décide par consensus à l aide de protocoles byzantins. L évaluation du système se concentre sur le inner ring et les performances en tant que système de fichiers (par l utilisation du Andrew Benchmark ). Ce n est donc pas du tout l optique que nous avons adoptée. Ensuite vient Past ([11] et [24]), qui est un système simple, utilisant une DHT et des répliques parfaites pour assurer la redondance et la fiabilité de la sauvegarde. L évaluation est simpliste et les performances (notamment en coût de replication) ne sont pas très intéressantes. pstore [1] rajoute à Past la possibilité de partager les blocs de données entre les versions de sauvegarde et les utilisateurs. Pour cela, il passe par une DHT. L évaluation se fait sur un réseau de 30 nœuds et se focalise sur la place occupée par les sauvegardes suivant différentes méthodes. Le système suivant, Pastiche [7] est intéressant parce que c est le premier système qui ne repose pas directement sur une DHT. En effet, les données sont stockées sur des partenaires, trouvés grâce à des DHTs. Le principe est de trouver des partenaires qui nous ressemble, c est à dire qui un grand nombre de données en commun avec nous. 15

Ainsi, on pourra partager une partie de nos sauvegardes et économiser de l espace disque. L évaluation porte sur la recherche de partenaires adéquats et sur le Andrew Benchmark sur de petites données (13.4Mo). L intérêt principal du papier de Lillibridge [20] sur son système est qu il étudie en profondeur la problèmatique de la sécurité. En dehors de ça, il s agit d un système reposant sur des partenaires, sans partages et avec des codes correcteurs d erreurs. En terme d architecture, il s agit du système qui nous a le plus inspiré. Malheureusement, la partie validation expérimentale est beaucoup trop concise. Ensuite vient Venti-DHash ([22] et [26]) basé sur CFS, DHash ([9] [5]) qui est très classique par sa conception, avec l utilisation de codes correcteurs d erreurs et d une DHT. Leur seule amélioration est de prendre en compte la distance sur le réseau pour améliorer la latence de récupération des données. Un point positif est la réalisation d un prototype, testé sur une centaine de nœuds. Le suivant, Total Recall [3], repose aussi sur DHash [9]. Sa principale motivation est de pouvoir auto-adapter les différents paramètres aux conditions du réseau. De plus, sa partie évaluation est la plus importante des papiers du domaine. Malheureusement, ça n a pas aboutit sur la création d un logiciel fonctionnel. PeerStore [12] est une amélioration de pstore. La différence porte sur le stockage des données. pstore utilise une DHT alors que PeerStore utilise des partenaires, avec une DHT pour stocker les méta-données. Et enfin, Glacier [14] est le système le plus moderne. Il est conçu comme système de stockage distribué et système de sauvegarde. La partie sauvegarde utilise les codes correcteurs d erreurs et une DHT. En Conclusion, on peut le voir, le domaine est plutôt productif. Cependant, il s avère que même les systèmes les plus anciens ne sont pas mis en production et restent au mieux au stade du prototype non totalement fonctionnel. De plus, notre optique différe toujours plus ou moins de celle de ces systèmes. La plupart cible à la fois le stockage et la sauvegarde, et sont comparés à NFS, alors que nous nous concentrons uniquement sur la sauvegarde. Les différences entre les deux approches sont que l on ne se soucie que de la disponibilité des données et de leur taille dans le système et pas de la rapidité en écriture et en lecture. De plus, même sur la sauvegarde, notre approche est différente, puisque notre objectif est la réalisation d un logiciel grand public, simple d utilisation et entièrement automatisé. 5.2 Autres travaux En dehors des présentations de systèmes, des travaux sur certains aspects de la sauvegarde en pair-à-pair sont intéressants : Bayou [10], reflexions sur la synchronisation de données dans un réseau mobile. Pourquoi se restreindre à un réseau F2F (entre amis) : [13]. L avantage en terme de sécurité peut elle compensé la difficultée de trouvé des partenaires (ses amis)? 16

Comment répartir ses données sur des hôtes les plus hétérogènes possibles pour pouvoir résister aux catastrophes localisées, phoenix : [17] Les tables de hashages distribuées (DHT) couramment utilisés : Chord [27], Pastry [25], Tapestry [15] et Kademlia [21]. À propos du backup en général, une survey des dernières recherches avant que l on s intéresse aux réseaux pair-à-pair : [6]. Sur le consistent hashing, très utilisé, notamment dans pastiche : [18]. Un important papier sur la sécurité dans un réseau Pair-à-Pair, comment avoir confiance en ses partenaires, et comment les forcer à être honnête : Samsara [8] Sur la disponibilité des nœuds dans un réseau pair-à-pair [2] et [28]. Étude sur Gnutella montrant que la stabilité dépend de l ancienneté [4]. 17

Chapitre 6 Conclusion 6.1 Conclusion L objet de ce travail a été de vérifier par la simulation la faisabilité d un système de sauvegarde collaborative en pair-à-pair. Pour cela, nous avons dû spécifier les processus mis en œuvre dans un tel système. Puis, modéliser les différents paramètres intervenant dans ces processus et enfin réaliser un simulateur prenant en compte ces derniers. Les résultats sont plutôt positifs puisqu en ayant une approche pessimiste sur les conditions du réseau, nous obtenons pour des nœuds correctement intégré dans le système, un taux de réparation de l ordre de 1 pour 4000 cycles, soit une réparation tous les 5 mois par composante. Nous avions calculé que le seuil de faisabilité était atteint lorsque l on avait un taux de 1%. Nous sommes donc largement en dessous, le tout sans pertes, et la marge obtenue ne peut que nous inspirer confiance. 6.2 Travaux ultérieurs Cependant, maintenant il reste à réaliser le système a proprement dit. La prochaine étape sera, tout d abord, de prendre un peu plus en compte le problème d obscolescence des données, qui a été trop rapidement vu ici. Puis il nous faudra intégrer dans la solution les contraintes du monde réel que sont la sécurité et la gestion des parasites. Des pistes ont été données par [8] et [20] mais la recherche dans ce domaine est loin d être terminé. Ensuite viendra la création d un prototype utilisant directement les travaux effectués pendant ce stage. À partir de celui-ci, nous pourrons alors modéliser encore plus finement les processus mis en jeu, nous permettant d ajuster les stratégies et les paramètres utilisés. Tout cela fera peut être pour moi l objet d une thèse dans le même laboratoire. 18

Bibliographie [1] C. Batten, K. Barr, A. Saraf, and S. Treptin. pstore : A secure peer-to-peer backup system, 2001. [2] R. Bhagwan, S. Savage, and G. Voelker. Understanding availability, In Proc. IPTPS, Feb. 2003. [3] R. Bhagwan, K. Tati, Y. Cheng, S. Savage, and G. Voelker. Total recall : System support for automated availability management, 2004. [4] F.E. Bustamante and Y. Qiao. Friendships that last : Peer lifespan and its role in P2P protocols. In 8th International Workshop on Web Content Caching and Distribution, H awthorne, NY, USA, September-October 2003. [5] J. Cates. Robust and efficient data management for a distributed hash table, 2003. [6] A. Chervenak, V. Vellanki, and Z. Kurmas. Protecting file systems : A survey of backup techniques, 1998. [7] L. Cox and B. Noble. Pastiche : Making backup cheap and easy, 2002. [8] L. Cox and B. Noble. Samsara : Honor among thieves in peer-to-peer storage, 2003. [9] Frank Dabek, M. Frans Kaashoek, David Karger, Robert Morris, and Ion Stoica. Wide-area cooperative storage with CFS. In Proceedings of the 18th ACM Symposium on Operating Systems Principles (SOSP 01), Chateau Lake Louise, Banff, Canada, October 2001. [10] A. J. Demers, K. Petersen, M. J. Spreitzer, D. B. Terry, M. M. Theimer, and B. B. Welch. The bayou architecture : Support for data sharing among mobile users. In Proceedings IEEE Workshop on Mobile Computing Systems & Applications, pages 2 7, Santa Cruz, California, 8-9 1994. [11] Peter Druschel and Antony Rowstron. Past : A large-scale, persistent peer-to-peer storage utility. hotos, 00 :0075, 2001. [12] Martin Landers Fakult. Peerstore : Better performance by relaxing in peer-to-peer backup. [13] Jinyang Li Frank. F2f : reliable storage in open networks, 2006. [14] Andreas Haeberlen, Alan Mislove, and Peter Druschel. Glacier : Highly durable, decentralized storage despite massive correlated failures. [15] Kirsten Hildrum, John D. Kubiatowicz, Satish Rao, and Ben Y. Zhao. Distributed object location in a dynamic network. Theory of Computing Systems, 2004. [16] MÃąrk Jelasity, Alberto Montresor, Gian Paolo Jesi, and Spyros Voulgaris. Peersim simulator, a peer-to-peer simulator. 19

[17] F. Junqueira, R. Bhagwan, K. Marzullo, S. Savage, and G. Voelker. The phoenix recovery system : Rebuilding from the ashes of an internet catastrophe, 2003. [18] David Karger, Eric Lehman, Tom Leighton, Rina Panigrahy, Matthew Levine, and Daniel Lewin. Consistent hashing and random trees : distributed caching protocols for relieving hot spots on the world wide web. In STOC 97 : Proceedings of the twenty-ninth annual ACM symposium on Theory of computing, pages 654 663, New York, NY, USA, 1997. ACM Press. [19] John Kubiatowicz, David Bindel, Yan Chen, Patrick Eaton, Dennis Geels, Ramakrishna Gummadi, Sean Rhea, Hakim Weatherspoon, Westly Weimer, Christopher Wells, and Ben Zhao. Oceanstore : An architecture for global-scale persistent storage. In Proceedings of ACM ASPLOS. ACM, November 2000. [20] M. Lillibridge, S. Elnikety, A. Birrell, M. Burrows, and M. Isard. A cooperative internet backup scheme, 2003. [21] Petar Maymounkov and David Mazieres. Kademlia : A peer-to-peer information system based on the XOR metric. 2002. http://www.cs.rice.edu/ Conferences/IPTPS02/109.pdf. [22] S. Quinlan and S. Dorward. Venti : a new approach to archival storage. In First USENIX conference on File and Storage Technologies, Monterey,CA, 2002. [23] S. Rhea, P. Eaton, D. Geels, H. Weatherspoon, B. Zhao, and J. Kubiatowicz. Pond : The oceanstore prototype. In Proceedings of the Conference on File and Storage Technologies. USENIX, 2003. [24] A. Rowstron and P. Druschel. Storage management and caching in past, a largescale, persistent peer-to-peer storage utility, 2001. [25] Antony Rowstron and Peter Druschel. Pastry : Scalable, decentralized object location, i and routing for large-scale peer-to-peer systems. Lecture Notes in Computer Science, 2218 :329??, 2001. [26] Emil Sit, Josh Cates, and Russ Cox. A dht-based backup system, 2003. [27] Ion Stoica, Robert Morris, David Karger, M. Frans Kaashoek, and Hari Balakrishnan. Chord : A scalable peer-to-peer lookup service for internet applications. In Proceedings of the 2001 conference on applications, technologies, architectures, and protocols for computer communications, pages 149 160. ACM Press, 2001. [28] Jing Tian and Yafei Dai. Understanding the dynamic of peer-to-peer systems. In Proc. IPTPS 2007. 20

Annexe A Résultats complémentaires En complément, voici des résultats supplémentaires présentant les taux de réparations pour des nœuds de différents âges. Dans la figure A.1, les nœuds ont plus de 2 ans. Les résultats sont que le taux de réparation se stabilise autour 0.010%-0.015%, ce qui nous donne une réparation tous les 7000-10000 cycles, ou tous les 8 mois - 1 an. C est un taux très faible et très encourageant. Dans la figure A.2, les nœuds ont moins de 3 mois. Le taux monte pour ces nœuds a 0.1%, ce qui reste raisonnable sachant que ces nœuds viennent d entrer dans le système, donc qu ils n ont pas pu choisir les hôtes fiables et qu ils n ont pas eut encore le temps de sauvegarder de grandes quantités de données. Au final, des résultats totalement en accord avec les prévisions, et avec ceux donnés dans le chapitre "Résultats". 21

12000 noeuds noeuds actifs reparation(pour mille) 0.7 10000 0.6 8000 0.5 Noeuds 6000 0.4 0.3 Reparations pour mille noeuds 4000 0.2 2000 0.1 0 0 10000 20000 30000 40000 50000 60000 Heures FIG. A.1 Taux de réparation pour les nœuds ayant plus de 2 ans 30000 noeuds noeuds actifs reparation(pour mille) 2.5 25000 2 20000 Noeuds 15000 1.5 1 Reparations pour mille noeuds 10000 0.5 5000 0 0 10000 20000 30000 40000 50000 60000 Heures FIG. A.2 Taux de réparation pour les nœuds ayant moins de 3 mois 22