Système de backup distribué

Transcription

1 Système de backup distribué Alexandre Decan Directeur: Luc Onana Alima Rapporteurs:AlainBuys&TomMens Service des Systèmes Distribués, Faculté des Sciences Université de Mons-Hainaut,

2 Résumé L hommeapprenddeseserreurs.c estsûrementsuiteàundésastreouà une catastrophe qu il a appris à sauvegarder régulièrement ses données. Puisque les méthodes traditionnelles montrent rapidement leurs faiblesses et leurs exigences, nous abordons une voie alternative dans la réalisation de backups. S il est un domaine qui a reçu beaucoup d attention ces dernières années, c est bien celui des applications distribuées. Bénéficiant des capacités mises en commun par les participants d un réseau peer-to-peer, ces applications- ce n est pas un hasard- s avèrent souvent d excellentes solutions pour profiter des ressources inexploitées des nombreux participants. Nous allons décrire et développer pas à pas les éléments d une application classique de backup distribué, tout en nous intéressant tout particulièrement, au travers de l utilisation de codes correcteurs, à l amélioration de la disponibilité des données face aux solutions de backup existantes.

3 Table des matières 1 Introduction Méthodetraditionnelledebackup Réseauxpeer-to-peer Tabledehachagedistribuée LaDHTsurunOverlayNetwork DistributedK-ArySystem Systèmedebackupdistribué Système de backup distribué Présentationdel application Pré-requis Conceptdeméta-donnée Chiffrementsymétrique&asymétrique Signaturenumérique Codescorrecteurs Identificationdesdonnées Confidentialité&Intégrité Haute-disponibilité Mécanismederéplication Codescorrecteurs SauvegardeauniveaudelaDHT Déterminationdescandidats Choixaveugle Interrogationparbroadcast Maintiendynamiqued uneliste LimitedScopeFlooding Expérimentations Implémentations ImplémentationdeRSEC ImplémentationdeDBS Vued ensemblededbs Présentationdesapplications ApplicationRSEC ApplicationDBS

4 TABLE DES MATIÈRES 2 4 Discussions Conclusion Perspectives Contrôledeversions Quota,confianceetmonitoring Remerciements Bibliographie 60 A CD-Rom 62 A.1 Introduction A.2 Contenu A.3 Utilisation... 63

5 Table des figures 1.1 Anneauvirtuel DHT&Key-BasedRouting Typesdeméta-données Chiffrementasymétrique Signaturenumérique Transmissionutilisantuncodecorrecteur Graphesbipartitespourl encodagedetornado Lestroisméta-données Disponibilitéd unedonnéeenfonctiondesnoeuds Nombrederéplicationsenfonctiondelafragmentation Comparaison entre la réplication et les codes correcteurs Gainducodecorrecteurparrapportàlaréplication Influencedelafragmentationsurladisponibilité Débitmoyen Déterminationdescandidats Vued ensemblededbs RSEC-Encodage RSEC-Décodage DBS-Options Diagramme:créationd unbackup Diagramme:récupérationd unbackup Diagramme:connexiond unnoeud Diagramme:déconnexiond unnoeud

6 CHAPITRE 1 INTRODUCTION 1.1 Méthode traditionnelle de backup Effectuer un backup est une approche bien connue pour tenter de conserver et de protéger physiquement des données. La plupart des compagnies et des organisations ainsi que les particuliers effectuent régulièrement des backupsdansl optiquedenepasêtrepénalisésencasdepertesoudedégâts occasionnées aux données originales. Les méthodes de backup traditionnelles impliquent de copier les données sur des média amovibles tels quedescdetdvd,etensuitedelestransférerdansunendroitsûroù ils pourront être récupérés en cas de désastre. Ces opérations nécessitent d être réalisées suffisamment fréquemment. Cependant, certains inconvénients et certaines insuffisances persistent: Lesmédiaamoviblestelsquelescassettes,lesCD,lesDVD,...nesont pasconçuspourêtreéternels:ilssedétériorentavecletempsetsont susceptibles d entraîner des pertes de données. Leprocessusdebackupnécessitedutempspourêtrecomplet.Les cassettes, qui constituent le médium le plus courant pour effectuer des sauvegardes massives, sont très lentes en lecture et en écriture. Des coûts supplémentaires sont à envisager: engagement de personnel pour effectuer et déplacer les backups sur les sites appropriés ainsi que pour garantir la sécurité du site. Une bonne organisation des données et des média est impérative pour prévenir des pertes accidentelles et faciliter la récupération de ces données. Idéalement, la réalisation d un backup devrait être aussi transparente que possible pour l utilisateur, sans l impliquer dans de nombreux détails parfois complexes et/ou laborieux. En réalité, l intervention de l utilisateur ne devrait être requise que pour un minimum de tâches. Les applications peerto-peer(p2p) sont apparues comme une approche intéressante dans le domaine des backups. Ces applications utilisent l espace disque libre des différentes machines du réseau pour sauvegarder les données. C est un processus transparent aux yeux de l utilisateur, puisque ce dernier ne doit avoir aucune connaissance sur la façon dont le processus est effectué. Seuls les besoins en terme de disponibilité et de sécurité sont importants aux yeux

7 1.2 Réseaux peer-to-peer 5 de l utilisateur. Les applications P2P garantissent ces exigences, tout en gardant les performances à un niveau hautement appréciable. Un autre avantage de cette gamme d applications est qu elle ne nécessite aucun matériel particulier: peu de ressources, peu de puissance matérielle. Nous décrirons comment allier les caractéristiques d un réseau peerto-peer décentralisé avec les exigences de haute-disponibilité d un backup, particulièrement au travers de l utilisation de codes correcteurs[24], afin de proposer une application de backup distribuée efficace, transparente, bon-marché et sûre. 1.2 Réseauxpeer-to-peer Un réseau peer-to-peer est un réseau dans lequel tous les participants, appelés noeuds, fonctionnent sur un même pied d égalité. Un réseau P2P est dit décentralisé s il fonctionne sans avoir un(ou plusieurs) serveur(s) dédié(s) responsable(s) de la prise en charge des requêtes. Chaque noeud a unrôledual:tantôtclient,tantôtserveur,dépendantducontexteetdela requête. Le principal avantage d une telle architecture par rapport au traditionnel client-serveur est qu aucun serveur dédié ne s avère être un goulot d étranglement, ou un single point of failure, c est-à-dire que le réseau ne peutêtredégradéoudétruitenunseulendroit. Une caractéristique importante des réseaux peer-to-peer est qu ils peuvent être hétérogènes: il n y a aucune restriction au niveau des noeuds, et un ensemble de participants peut être composé de nombreuses architectures différentes, que ce soit au niveau logiciel ou matériel. Cependant, si ces réseaux sont potentiellement hétérogènes, la bande passante disponible, la vitesse du CPU, la capacité de stockage ou encore le degré de confiance en chaque noeud sont des caractéristiques fort différentes des systèmes traditionnels client-serveur: aucune information à ce sujetnepeut,apriori,êtreconnue,etilestnécessairedefonctionnersans cette information dans un premier temps, rendant ainsi la conception d applications peer-to-peer délicate et difficile. Les réseaux peer-to-peer peuvent être catalogués en deux classes[30]: les réseaux structurés et les réseaux non-structurés. La topologie logique d un réseau non-structuré est aléatoire. Quand un noeud effectue une requête pour une certaine donnée, cette requête est propagée saut après saut surbased unprincipedeflooding,jusqu àcequelenoeudcapablederépondre à cette requête soit atteint ou que la requête expire. Ceci implique qu au sein d un réseau non-structuré, il est possible qu une requête n aboutisse pas même si la donnée concernée est présente. Gnutella est un exemple typique de réseau non-structuré. Paradoxalement, la qualité du réseau décroît avec le nombre de noeuds. Dans un réseau structuré, la topologie logique présente certains aspects structurés:lesnoeudsd untelréseaupeuventformeruncercleouune chaîne et sont identifiables d une manière unique, souvent liée à leur positionauseinducercleoudelachaîne.dansunréseaustructuré,ilest

8 1.2 Réseaux peer-to-peer 6 FIG. 1.1 Anneau virtuel (a)lesnoeuds1,4,8,10,11et14sontprésents. systématiquement possible d atteindre tout noeud du réseau en un nombre desautsdéterminé.larecherched unedonnéeauseind unteltypede réseau est garantie après un nombre déterminé d étapes si la donnée est présente. Dès lors, la localisation de données dans le réseau structuré est clairement plus efficiente que dans un réseau non-structuré Table de hachage distribuée Etant donnée l efficacité du mécanisme de lookup au sein d un réseau structuré, il est envisageable de concevoir une structure de données adéquate pour le développement d applications peer-to-peer. Un des mécanismes de base pouvant être développé au-dessus d un réseau structuré consiste en une table de hachage distribuée, ou Distributed Hash Table(DHT)[12]. UneDHTestunservicequipermetdemainteniretd utiliserunetable de données dispersée sur chacun des noeuds du réseau. Les sections suivantes décrivent une DHT au sein d un réseau structuré basé sur une topologie en anneau. Une topologie en anneau[22] au sein d un réseau structuré est réalisée en assignant un identifiant à chaque noeud du réseau. Chaque noeudsevoitattribuéunidentifiantuniquequiestchoisiparmiunespace d identification préalablement défini. Avec ces identifiants, les noeuds forment un anneau virtuel respectant l ordre des identifiants. La figure 1.1 présente l attribution de différentes valeurs au sein du réseau. L utilisation d une topologie en anneau facilite les mécanismes de base du routage et de la recherche d informations entre les noeuds. Cette façon de mettre les noeuds en relations, ou encore réseau virtuel est souvent appelée Overlay Network La DHT sur un Overlay Network La DHT fournit une abstraction dans l utilisation d une table de hachage permettant simplement d ajouter et de récupérer des informations au sein

9 1.2 Réseaux peer-to-peer 7 FIG.1.2 DHT&Key-BasedRouting decettetable.ladhtpeutêtreconsidéréecommeunetabledehachage classique, pour laquelle les données sont distribuées parmi les noeuds du réseau.unetabledehachageestunestructurededonnéesquipermetune association clé-valeur. Chaque couple de la table de hachage est identifié demanièreuniqueparsaclé.cecipermetunaccèsdirectàunedonnée, puisqu il suffit d en connaître la clé et, par extension, sa valeur de hachage, pourendéduiresonemplacementauseindelatable. Il est simple d envisager l intégration d une table de hachage au sein d un réseau peer-to-peer structuré. Puisque chaque noeud est identifié de manière unique au sein du réseau, il suffit d employer une fonction de hachage partageant le même espace d arrivée que l espace d identification des noeuds. Ainsi, toute valeur obtenue par cette fonction désigne un noeud responsable de la donnée associée au sein du couple clé-valeur. En utilisant une DHT, les données peuvent être insérées dans l Overlay Network en spécifiant la clé associée à chaque donnée, comme si celles-ci étaient insérées dans une table de hachage classique. Les clés sont choisies depuis un même espace d identification, celui des identifiants des noeuds. Récupérer une donnée ne nécessite alors que la connaissance de la clé associée à cette donnée. Quand une donnée doit être ajoutée dans la DHT, le noeud responsable de son stockage est déterminé par la clé associée. Cette technique de routage est appelée key-based routing(figure 1.2). Lors de la récupération de la donnée, le mécanisme de key-based routing est utilisé pour déterminer le noeud responsable de la donnée. Dans le cas d une topologie en anneau, silenuméroainsiobtenun estpasoccupéparunnoeud,c estlepremier noeudsuccesseurdecenuméroquiestresponsabledeladonnée.unefois l adressedunoeudobtenue,ladhtcontactecedernieretluidemandela donnée.

10 1.3 Système de backup distribué 8 Garantir la disponibilité physique d une donnée au sein de la DHT impliquedetenircompteducaractèredynamiqueduréseau.c estàladht d effectuer ce travail en tenant compte du départ et de l arrivée des différentsnoeudsetendéplaçantladonnéedemanièreadéquateauseindu réseau. Une solution simple et élégante pour garantir cela est d utiliser un mécanisme de réplication sur plusieurs noeuds. Quand un noeud disparaît du réseau(déconnexion involontaire), les données dont il était responsable peuvent être obtenues via d autres noeuds qui maintenaient une copie de ces données. De même, de nouvelles copies sont effectuées et stockées sur d autres noeuds afin de disposer en permanence d un nombre de copies suffisant. Généralement, les caractéristiques souhaitées d une DHT sont: Décentralisation: les données sont dispersées au sein du réseau en l absence de toute centralisation. Scalability: la DHT doit pouvoir fonctionner quelque soit la taille du réseauetlenombredenoeuds. Toléranceauxerreurs:laDHTdoitêtreàmêmedegérerleserreurs dues aux noeuds Distributed K-Ary System Le Distributed K-Ary System(DKS)[11, 21, 22] est un middleware qui fournit différents services facilitant la création d un réseau peer-to-peer décentralisé et structuré. DKS propose en outre un service de table de hachage distribuée, un service de communication directe ainsi qu un service de communication de groupe. Les noeuds participants au sein de DKS sont assemblés suivant une topologie en anneau, et les propriétés et avantages cités ci-avant sont respectés. La DHT de DKS joue un rôle fondamental dans la conception de notre application. L ajout ou la suppression d un noeud repose sur un mécanisme appelé Local Atomic Actions, qui garantit l unicité dans l attribution des responsabilités au sein du réseau. LesprincipauxservicesoffertsparlaDHTdeDKSsontl ajoutetla recherche de valeurs dans la table distribuée. put(key,value) va mémoriser lecouple(key,value)surlenoeuddésignéparlavaleurdehachagedekey. get(key[,value]) va demander les couples associés à key(ou à(key,value) si valueestprécisé)aunoeuddésignéparlavaleurdehachagedekey. Par ailleurs, DKS propose un service de Bulk Lookup, permettant la recherche de plusieurs milliers d identifiants sans pour autant créer plusieurs milliers de requêtes. Ceci s avèrera extrêmement important, dans le sens où notre application nécessitera parfois la recherche de plusieurs centaines voire milliers de fichiers. 1.3 Système de backup distribué Nous allons nous intéresser à une application qui permet d effectuer un backup sur un réseau P2P décentralisé tel que nous l avons décrit ci-avant, en profitant des avantages d une DHT[26]. Idéalement, cette application présenterait les caractéristiques[3, 10] suivantes:

11 1.3 Système de backup distribué 9 Transparente pour l utilisateur: Seules les informations essentielles (choix des fichiers, cryptage, compression,...) doivent être fournies par l utilisateur. Il emploie ainsi l application sans avoir à se préoccuper de la façon dont le système réalise l opération. Bon-marché: Il n est pas nécessaire d engager du personnel supplémentaire pour s occuper du backup, transférer les média et garantir sa sécurité physique. Par ailleurs, la nature distribuée de l application n engendre aucun coût lié au matériel nécessaire(pas de CD, cassettes, machines spécifiques,...). Facilement accessible: Le backup est accessible quelque soit le moment et le lieu souhaité. Bienorganisée:Lesbackupssontindépendantslesunsdesautres,ce qui permet une récupération précise des données. Sécurisée: Divers mécanismes garantissant l intégrité et la confidentialité des données fournissent un certain degré de sécurité. Haute-disponibilité:DeparlanatureduréseauP2Petgrâceauxmécanismes utilisés, l application garantit une haute disponibilité, permettantlaperteoul absenced ungrandnombredemorceauxdela donnée sans pour autant rendre celle-ci irrécupérable.

12 CHAPITRE 2 SYSTÈME DE BACKUP DISTRIBUÉ 2.1 Présentation de l application Nous allons développer une application permettant d effectuer un backup sur un réseau P2P décentralisé. Cette application sera bâtie au-dessus du middleware DKS utilisé pour la création et le maintien d un réseau peerto-peer décentralisé. Nous tâcherons de répondre de notre mieux aux objectifs énoncés en section 1.3. La nature décentralisée et distribuée de l application permet de répondre intrinsèquement aux objectifs d accessibilité, d organisation, de ressources matérielles nécessaires et par extension, des ressources financières nécessaires. Nous allons orienter le développement de l application selon les objectifs de transparence, de confidentialité& d intégrité des données et tout particulièrement de haute-disponibilité. Nous découvrirons et emploierons divers mécanismes et outils parfois complexes afin d y parvenir. Ainsi, l usage de méta-données nous permettra d offrir une abstraction suffisante et confortable au niveau des structures de données et rendra possible l adoption de conventions de nommage simples pour l utilisateur tout en restant performantes d un point de vue d identification des données au sein du réseau et plus particulièrement de la table de hachage distribuée. La confidentialité et l intégrité des données seront assurées par divers mécanismes de chiffrement reposant sur les architectures à clé secrète et à clé publique [18, 25]. Finalement, l utilisation de codes correcteurs[9, 24] nous permettra de subdiviser les différents fichiers en blocs plus concis, plus simples à traiter tout en garantissant une haute-disponibilité pour un surcoût acceptable en terme de stockage. Nous débuterons ce chapitre en introduisant quelques concepts fondamentaux. Nous aborderons ensuite en détail les différents mécanismes nous permettant de remplir les objectifs énoncés ci-dessus, les choix que nous avons effectués ainsi que les solutions développées. Le chapitre suivant sera l occasion de présenter un prototype d une telle application, son implémentation et son fonctionnement. Finalement, nous discuterons des perfor-

13 2.2 Pré-requis 11 FIG. 2.1 Types de méta-données mances et des résultats de cette application à partir desquels nous conclurons et proposerons quelques perspectives supplémentaires. 2.2 Pré-requis Concept de méta-donnée De nombreuses définitions d une méta-donnée existent. La plus simple et la plus courante est qu une méta-donnée est une donnée à propos d une donnée [29]. Généralement, une méta-donnée peut être vue comme une certaine quantité d informations venant décrire ou compléter une autre information, centrale. Par exemple, une méta-donnée associée à une image peut décrire le contenu de cette image ou encore les valeurs de correction d exposition, de date, etc. s y rapportant. Plus formellement, on considère une méta-donnée comme une information facultative pour l existence même de la donnée centrale, mais néanmoins essentielle pour la bonne utilisation de cette dernière. Ainsi, par exemple, estunedonnéedetypenumériquequi,endehorsdetout contexte, n a pas réellement de sens. Dès que cette donnée est associée à uneméta-donnéequiladécritcommeétantuncodepostal,uneadresseou une quantité, son sens devient explicite et il est possible de l utiliser à bon escient. La notion de méta-donnée est largement utilisée dans le domaine de l informatique moderne[29]. En général, les méta-données sont utilisées en complément des données centrales pour rendre l utilisation de processus de recherche ou de filtrage praticables, ou tout simplement dans les (nombreuses) situations dans lesquelles il est nécessaire de faire la distinction entre le contenu et le contenant(tcp, en-têtes http, images,...). Plus proches de nos préoccupations, les méta-données sont également utiliséesdanslessystèmesdefichiersetdebackupafindefournirunedescription précise et concise du fichier concerné. Nous allons considérer des méta-données de deux types(figure 2.1): Séparées de l information à laquelle elles se rapportent. C est le cas, par exemple, d une feuille de style CSS[16] décrivant l affichage d un fichier de données XML[14] ou des images disques au format cue/iso. Associées à l information à laquelle elles se rapportent. Typiquement plus répandue, cette disposition est utilisée notamment pour les tags

14 2.2 Pré-requis 12 ID3 d un fichier MP3, le conteneur vidéo avi. Le principal avantage d une méta-donnée est qu elle permet de séparer distinctement le contenu de sa description. Ceci permet de lire ou de modifier la description(ou toute information) d une donnée sans l altérer, voire sans même y avoir accès directement. La méta-donnée permet en outre d identifierunedonnéedefaçonsimple,mêmesilenomdecettedernières avère très compliqué, elle agit alors comme une sorte de pointeur vers la donnée concernée Chiffrement symétrique& asymétrique La cryptographie symétrique est régulièrement appelée cryptographie à clé secrète. La cryptographie symétrique repose fondamentalement sur la notion de clé. Il s agit d une information permettant de chiffrer et de déchiffrerunmessage,àlabasedetoutelasécuritédelacommunication. Un algorithme de chiffrement(resp. de déchiffrement) est une fonction f prenant en paramètre le message m à chiffrer(resp. à déchiffrer) et la clé secrète k:f(m, k).lasécuritédelacryptographiesymétriquedépendessentiellement du choix de l algorithme: ce type de cryptographie ne satisfait pas les utilisateurs de chiffrement parce que la conception d un bon algorithme est très difficile et qu une fois découvert, il n offre plus de sécurité. Tous les messages ayant été chiffrés avec cet algorithme deviennent alors accessibles. Actuellement, nous savons qu au moins le chiffrement de GILBERTVERNAM[25],quiconsisteàajouteraumessageenclairuneclé de même longueur que le message, est parfaitement sûr. C est le seul pour lequel il a été possible de prouver une telle chose. L inconvénient est que chiffrerunmessagede nbitsnécessited échangerunecléde nbitsavecle destinataire du message et ce, de manière parfaitement sûre. La cryptographie asymétrique ou cryptographie à clé publique[8, 18], par opposition, repose sur des fonctions à sens unique, c est-à-dire des fonctionsappliquéesàunmessagedesorteàcequ ilsoittrèsdifficilederetrouver ce message dès lors qu il a été transformé. En réalité, ces fonctions sontàsensuniqueetàbrèchesecrète:ellessonttrèsdifficilesàinverser,à moins d en connaître la brèche, autrement appelée clé privée. Nous pouvons voir le chiffrement asymétrique comme un chiffrement quiutilisedeuxdecesfonctions:unefonction PrKetunefonction PuKpermettant chacune le chiffrement et le déchiffrement d un message m. Ainsi, si Alice souhaite pouvoir recevoir des messages chiffrés, elle publie sa fonction PuK. Quand quelqu un souhaite lui envoyer un message m, il calcule m = PuK(m)etenvoie m àalice.celle-ciutilisealorssacléprivéepour retrouverlemessaged origine mtelque m = PrK(m ). La cryptographie asymétrique vient combler une lacune majeure de la cryptographie symétrique: le partage sécurisé d une clé entre les correspondants. Les mécanismes de chiffrement symétrique étant moins coûteux en temps de calcul, ceux-ci sont privilégiés aux mécanismes de chiffrement asymétrique pour le reste de la communication. Cependant, toute utilisation de la clé de chiffrement symétrique nécessite que les correspondants se

15 2.2 Pré-requis 13 FIG. 2.2 Chiffrement asymétrique partagent cette clé. Le mécanisme de chiffrement asymétrique entre dans laréalisationdecepartage:ilestutilisépourlaphased échangedelaclé symétrique et cette dernière est employée pour le reste de la communication.lafigure2.2illustrecemécanisme:laclésecrèteestutiliséepour chiffrer le message à transmettre, et cette clé secrète est chiffrée à l aide de lacléprivée.cetteclésecrètechiffréeetlemessagechiffrésonttousdeux envoyés. Le message original est alors obtenu par déchiffrement à l aide de la clé secrète, elle-même déchiffrée à l aide de la clé publique de l expéditeur Signaturenumérique Il est possible de signer numériquement un document sur base des principes du chiffrement asymétrique. Signer numériquement un document permet de certifier au destinataire que le message n a pas été altéré. Par ailleurs, il est possible de s assurer de l identité de l expéditeur via un mécanisme de certificats reposant sur des organismes dits de confiance. Ce concept de signature numérique est actuellement relativement simple à mettre en place et de plus en plus répandu. Idéalement, la signature numérique doit être: Authentique L identité du signataire doit pouvoir être retrouvée de manière certaine. Infalsifiable La signature ne peut être falsifiée. Il n est pas possible d usurper l identité de l expéditeur. Non réutilisable La signature n est pas réutilisable. Elle fait partie du document signé et ne peut être déplacée sur un autre document. Inaltérable Un document signé est inaltérable. Une fois signé, il n est plus modifiable. IrrévocableLapersonnequiasignénepeutlenier. Notons PuK la fonction de chiffrement(connue de tous) et PrK la fonction de déchiffrement. Quand Alice désire signer numérique un message m, elle calcule s = PrK(m).Ilestalorssimplepourunepersonnedisposantdu message metdelasignature sdes assurerqu Aliceestàl originedela signatureetdumessageencalculant PuK(s).Pourquelemessageaitpu être altéré, il faudrait que la signature soit altérée de manière cohérente, ce qui est pratiquement impossible en pratique, à moins de disposer de PrK. Plus précisément, la signature concerne une partie de ce message, son empreinte, et non le message en entier. Cette empreinte est calculée grâce

16 2.2 Pré-requis 14 FIG. 2.3 Signature numérique àunefonctiondehachage.lechoixdelafonctiondehachageinfluencela sécuritédelasignaturenumérique:étantdonnéunmessageetsonempreinte, il faut qu il soit très difficile de fabriquer un message différent ayant une empreinte identique. L intérêt dans l utilisation de l empreinte plutôtquedelatotalitédumessageestqu ilnefautsignerqu unepetite quantité de données comparativement au message. La figure 2.3 illustre un scénario classique: une empreinte du message est calculée par l expéditeur et cette empreinte est chiffrée. Le message ainsi que l empreinte chiffrée sontenvoyés.vérifierquelemessagen apasétéaltérésefaitencomparant une empreinte nouvellement calculée avec l empreinte reçue, préalablement déchiffrée à l aide de la clé publique de l expéditeur Codescorrecteurs [9] définit un code correcteur comme étant une technique de codage de l information basée sur la redondance d une partie ou de la totalité de l informationdanslebutdefournirunmoyendecorrigerouderécupérercette information suite à une erreur lors de sa transmission. La théorie des codes correcteurs ne sert pas seulement pas aux communications classiques, mais également aux supports pour le stockage comme les CD, la mémoire et d autres applications où l intégrité des données est importante. Nous sommes partis du constat suivant: si un code correcteurpeutêtreutilisépourrécupérerdesdonnéessuiteàuneerreurde transmission, de tels codes peuvent être également utilisés pour combler un problème de récupération de données. Une situation classique: l information concernée est stockée sur plusieurs supports différents et l un de ces supports est manquant. Dans une situation normale, en l absence de code correcteur, il n est pas trivial de récupérer ou de reconstituer la partie manquante de ces données. Nettement moins courante, l utilisation de codes correcteurs dans le cadre de la sauvegarde distribuée de données n en est pourtant pas moins

17 2.2 Pré-requis 15 FIG. 2.4 Transmission utilisant un code correcteur intéressante: l objectif d un tel environnement est de fournir un moyen simple de sauvegarder une donnée en la subdivisant en blocs répartis sur plusieurs machines. Bien que ces machines soient probablement destinées àoeuvrerdansunbutbienprécis-resterdisponible-iln estpasexcluque l uned entreellenesoitplusdisponibleounedisposeplusdeladonnéetelle qu elle avait été confiée initialement. L usage d un code correcteur nous permet de pallier à ces éventualités. L ajout de redondance offre une certaine tolérance à l absence d un ou de plusieurs blocs lors de la reconstruction de la donnée. Formellement, un code correcteur transforme un message(ou une donnée) m composé(e) de n blocs(paquets, fragments, bits,...) en un message (oudonnée) m ayantunnombre n > ndeblocstelque mpuisseêtreretrouvédepuisunefraction rdecesblocs,c est-à-diredepuis n.r nblocs (figure 2.4, inspirée du document accompagnant[24]). Uncodecorrecteuroptimalproduit n = n r blocsoùseuls nsontnécessaires pour retrouver le message original. Le code procède en ajoutant de la redondance au niveau des blocs. Malheureusement, ce genre de codes est souventcoûteuxentermedemémoireetdetempscpuquand ndevient important. En pratique, un code correcteur presque optimal, code pour lequel (1 + ε)nblocssontrequispourrecomposerlemessage,estutilisédans la majorité des applications temps-réel nécessitant un temps d encodage et de décodage le plus court possible. Réduire ε, l overhead, peut être fait au prix d une augmentation du temps CPU. Les paragraphes suivants décrivent plus précisément les bases du fonctionnement des codes Reed-Solomon[5, 24] et Tornado[1, 6, 20], les principaux codes de leur catégorie, respectivement code optimal et code presque optimal.entantquecodepresqueoptimal,letornadocodeinduitunléger overhead ǫ mais est significativement plus rapide lors de l encodage et du décodage que le code Reed-Solomon. Le tableau 2.1[2] reprend les principales caractéristiques des deux codes mentionnés(p étant la taille d un fragment).

18 2.2 Pré-requis 16 TAB. 2.1 Propriétés de Tornado et Reed-Solomon Tornado Codes Reed-Solomon Codes Overhead ǫ > 0( 0.05) 0 Tempsd encodage nk. ln( 1 ǫ )P k2 ( 1 k + n 1)P Tempsdedécodage nk. ln( 1 ǫ )P k2 ( 1 k + n 1)P Opération de base XOR Résolution d équations Code optimal Reed-Solomon Inventé en 1960 par IRVING S. REED et GUSTAVE SOLOMON, le code Reed-Solomon est un code correcteur optimal. L idéederrièrececodeestquelesdonnéespeuventêtrevuescommeun polynôme. Le code se base sur un théorème d algèbre linéaire qui stipule que k points distincts déterminent de façon unique un polynôme de degré aumoins k 1. Le polynôme est ensuite encodé par l évaluation successive de plusieurs points, et ces valeurs sont ensuite envoyées comme message. A la réception, il est possible de déduire le polynôme initial sur base d une fraction despointsinitiaux.formellement,pourunchampfini Fetunanneaupolynomial F[x][7],nouschoisissons net ktelque 1 k n F. néléments distinctssontchoisisdans Fetnotés {x 1, x 2,..., x n }.Ensuite,lecode Cest crééàpartirdesvecteursobtenusenévaluantchaquepolynôme(sur F)de degré< kpourchaque x i,c est-à-dire: C = {(f(x 1 ), f(x 2 ),..., f(x n )), f F[x], deg(f) < k} Cestun [n, k, n k + 1]code,end autresmots,c estuncodelinéairede taille n,dedimension ketdedistanceminimale n k + 1. Code presque optimal Tornado Le code Tornado a été introduit dans les travaux[19, 20] comme un code correcteur presque optimal permettant l encodage et le décodage d un message en un temps suffisamment court que pour être utilisé dans des applications temps-réel, comme la diffusion audio/vidéo en streaming. Le code permet la diffusion d informations avec un débit proche de la capacité du canal utilisé. Le code Tornado est construit par une succession d opérations élémentaires sur des graphes bipartites aléatoires.uncode C(b)avec kbits 1 et bkbitsredondants(0 < b < 1)est définienluiassociantungraphebipartite B.Cegraphe B(figure2.5[20])a k noeuds à gauche et bk noeuds à droite, correspondant respectivement aux bits du message et aux bits de redondance, ou encore check-bits. L encodage C est déterminé en définissant chaque check-bits comme étant le résultat del opération XORdesvoisinsdegauche(ex.:x 1 et x 2 pour c 1 )dansle graphe B. Cette opération est alors répétée en cascade sur les check-bits jusqu à un degré fixé, produisant alors l encodage désiré. La qualité du code dépendévidemmentdelaconstructiondugraphe Bainsiquedelamanière dont les check-bits sont associés aux bits du message. 1 Plusgénéralement,avec ksymboles

19 2.3 Identification des données 17 FIG. 2.5 Graphes bipartites pour l encodage de Tornado Puisque nous connaissons maintenant les concepts fondamentaux sur lesquels reposera notre application, nous allons envisager une façon de les réuniretdelesexploiteraumieuxafinderemplirlesobjectifsd unesolution de backup distribuée répondant aux exigences énoncées dans la section 1.3. Tout d abord, nous présenterons en section 2.3 un mécanisme simple reposant sur l usage des méta-données comme structures élémentaires pour l identification et la manipulation de données quelconques, les raisons pour lesquelles il est nécessaire de les identifier de façon unique au sein d un réseau décentralisé et les moyens mis en oeuvre pour garantir une facilité d utilisation malgré ces subtilités. En second lieu, nous reparlerons d architectures à clé publique et à clé secrète dans le contexte de la confidentialité. La vérification de l intégrité des données sera l occasion, en section 2.4, d utiliser la notion de signature numérique et de présenter une façon élégante de l employer en l absence d organisme de certification. Ensuite, nous discuterons plus en détail des solutions classiques permettant d offrir une haute-disponibilité par le biais de la réplication et nous envisagerons l utilisation de codes correcteurs d erreurs pour assurer une très haute-disponibilité à moindre coût(section 2.5). Finalement, nous analyserons en section 2.6 les différentes façons d obtenir du réseau une liste de noeuds potentiellement candidats pour la sauvegarde d une partie de nos données en nous concentrant sur l exhaustivité, la cohérence et la souplesse de cette liste tout en minimisant les ressources nécessaires à son obtention. 2.3 Identification des données Dans l optique de fournir une application simple d utilisation, il n est pas désirable que l utilisateur ait besoin de connaissances particulières dans le domaine ni qu il doive mémoriser d importantes informations d une utilisationàl autreafindeprofiterdenotreapplication.pourcefaire,ilestnéces-

20 2.3 Identification des données 18 FIG. 2.6 Les trois méta-données saire de concevoir et de fournir des outils abstrayant ces connaissances et ces informations. Les méta-données nous permettent d associer des informations descriptives à une autre information. Plus spécifiquement, il nous estpossibled identifierunedonnéeparunmoyensimple-sonnompar exemple- sans pour autant devoir utiliser directement ce nom au sein des mécanismes sous-jacents. En d autres termes, nous pouvons profiter d un nom canonique facilement mémorisable et manipulable du point de vue de l utilisateur, tout en employant des conventions complexes en arrière-plan, rendant envisageables certains mécanismes exigeants, comme l unicité nominale des données. Ainsi, l usage de méta-données nous permet-il de récolter des informations précises et ciblées concernant les données présentes dans notre application, tout en évitant de devoir récupérer l ensemble de celles-ci. La figure 2.6 reprend les trois types de méta-données définis dans le cadre de notre application: BackupID Il s agit d une sorte de carte d identité du backup décrivant le contenu de ce dernier. Nous retrouvons dans cette méta-donnée des informations telles que le nom du backup, son auteur(identifié nominativement ou via sa clé publique), la clé publique permettant de vérifier l intégrité de la donnée ainsi que sa signature numérique, diverses informations plus techniques, comme le préfixe unique des fragments ainsi que leur nombre. La BackupID est une méta-donnée créée par l auteur d un backup et soigneusement insérée dans la DHT lors de la création du backup. C est cette carte d identité qui garantit l existence(d un point de vue fonctionnel) même du backup au sein du réseau. Remarquons que le nom de cette méta-donnée est identique aunomdubackupetnedoitpasspécifiquementêtreunique.comme nous le verrons juste après, seul le couple(nom, auteur) doit l être. FragmentID Il s agit d une méta-donnée insérée et maintenue à jour par tout noeud possédant un fragment d un backup donné. Par conséquent, chaque méta-donnée de ce type ne concerne que chaque fragment actuellement disponible dans le réseau. Le FragmentID contient l information de localisation physique du fragment auquel il se rap-

21 2.3 Identification des données 19 porte. Comme cette méta-donnée est utilisée lors de la récupération d un backup- elle possède l information de localisation permettant de retrouverlepropriétairephysique 2 dufragmentconcerné-sonnom doitêtreuniqueafindenepass orienterparerreurversunfragment d un backup concurrent. Nous verrons ci-après comment garantirl unicitédecenometlereformerafind obtenirlalocalisationdes différents fragments. FragmentStorage Par analogie à la BackupID, la méta-donnée Fragment- Storage est une sorte de carte d identité d un fragment. En réalité, le FragmentStorage est la structure de données de base de tout fragment au sein de l application. Le FragmentStorage précise le backup auquel appartient ce fragment, son auteur, une signature numérique du fragment ainsi qu un champ Content représentant le morceau de ladonnéeentantquetel.lorsdelaréalisationd unbackup,chaque fragmentestinsérédansuneméta-donnéedecetypeetestenvoyé à chaque candidat sur le réseau. Ces divers candidats stockent alors localement le FragmentStorage en attente d une éventuelle récupération ultérieure par le créateur du backup. Le processus inverse est employé lors de la récupération d un backup. Puisque chaque noeud du réseau a pour responsabilité un certain nombre de fragments, il est nécessaire d attribuer un nom unique à chacun de ces fragments afin d éviter des conflits de responsabilité et de récupérationplusieurs noeuds se portant garants d informations identifiées comme étant identiques mais pourtant différentes. Par exemple, supposons qu un noeud adisposed unfragment f 1 concernantladonnée d 1.Delamêmemanière, unnoeud bdisposed unfragment f 2 concernantladonnée d 2.L auteur dubackup d 1 souhaiterécupérersadonnée.sinousautorisons nom(f 1 ) = nom(f 2 )etquelenoeud aestindisponibleaumomentdelarécupération, l auteurdubackuprisquederecevoir f 2 aulieude f 1.Sinouspouvons garantir nom(f 1 ) nom(f 2 ),bienquelefragment f 1 soitirrécupérable(a étant indisponible), l application ne récupérera pas l information fausse correspondantàd 2. La principale contrainte dans l identification unique est que l espace de nommage doit être suffisamment grand que pour couvrir l ensemble des éléments présents dans le réseau, sans quoi une collision est inévitable. Il n estpasdifficiled attribuerunnomuniqueàunélément:unsimplenom généré aléatoirement jusqu à ce qu aucune collision ne soit détectée suffit amplement. Cependant, cette solution ne serait ni efficace ni élégante à grande échelle. Surbasedunomdubackup netdunuméro fdufragmentconcerné,il estpossibledecréerunnomuniqueenyajoutantl estampille ttelquele nomsoitlaconcaténationde n + t + f.puisquelenumérodechaquefragment est unique pour un backup donné, les seules collisions possibles surgissent quand deux utilisateurs effectuent un backup portant exactement le même nom, et ce exactement au même moment. Nous utilisons ensuite une fonction de hachage sur le résultat ainsi obtenu. 2 Paroppositionaupropriétairelogique,l auteurdubackup

22 2.3 Identification des données 20 Bien que le nom soit, disons-le, unique, la fonction de hachage nous permetdeleramenerdansunespacedenommageplusconventionnel-une suite de chiffres par exemple- et donc d en faciliter l utilisation par les différents mécanismes employés. Le choix de la fonction de hachage est important: il est indispensable que celle-ci dispose d un vaste espace d arrivée, d une dispersion maximale et d une distribution aussi uniforme que possible pour éviter les collisions. SHA-1 est réputé pour ces qualités et s avère un excellent choix. A ce stade, nous distinguerons le nom canonique d unfragment n + f desonnomunique n + t + f dontlavaleurhachée sha1(n + t + f)identifielalocalisationdufragmentidauseindeladht. Le nombre de fragments pouvant vite devenir conséquent(potentiellement plusieurs centaines de fragments par fichier), il serait fastidieux d employer un nom canonique unique(dans notre cas, le nom canonique seraitcomposédunomdubackupsuividunumérodefragment)pourchaque fragment. Les performances en seraient d ailleurs fortement dégradées de par la nécessité d augmenter la longueur de la chaîne de caractères nécessaire pour identifier de façon unique chacun d entre eux. Il est évident que l utilisation d un nom unique tel que nous l avons présenté, haché dans un espace de nommage bien défini, est impératif. Remarquons cependant qu il n est pas forcément utile de procéder de la sorte pour l identification des backups. En effet, le nombre de backups étant forcément inférieur au nombre de fragments, ceux-ci peuvent être identifiés relativement facilement grâce au couple(nom du backup, identité de l auteur). Ce couple facilite l utilisation courante de l application, offrant un nom canonique simple(nous l espérons!)àmémoriser,toutenévitant,danslamajoritédecas,lescollisions. Celles-ci peuvent néanmoins se produire si un même utilisateur souhaite effectuer un backup portant le nom d un précédent backup. Dans ce cas, l application pourrait, au choix, le signaler afin de ne pas avoir à rencontrercecasdefigure(cequenousenvisagerons),oul accepteret,lorsde la récupération, demander à l utilisateur quel est le backup qu il souhaite récupérer, parmi les collisions. A nouveau, l utilisation de la fonction de hachagenouspermetdetravaillerdansunespacedenommagebiendéfini,de taille adaptée au problème considéré. La récupération d un backup implique en partie celle des fragments. Pourcefaire,ilestnécessairedeconnaîtrelalocalisationdechacundeces fragments, c est-à-dire de disposer de l information contenue dans la métadonnée FragmentID. Autrement dit, pour chaque numéro de fragment f allantde 1àN-lenombretotaldefragments-ilfautcalculer sha1(n + t + f) pour atteindre le FragmentID du fragment f. Or, puisque nous disposons parlebiaisdelabackupidde n + tainsiquede N,ilesttrèssimpled interroger la DHT afin de récupérer chaque FragmentID présent. Sur base d un FragmentStorage, un noeud du réseau peut aisément obtenir les informations concernant le backup auquel se rapporte le fragment qu il stocke localement. Avec ces informations, il peut créer une métadonnéedetypefragmentidqu ilinsèredansladhtpouravertirlesystème qu il dispose d un fragment. Ce FragmentID contient son adresse IP

23 2.4 Confidentialité& Intégrité 21 et porte le nom unique dont nous avons déjà largement discuté précédemment. Puisque le FragmentStorage contient le nom du backup ainsi que son auteur, nous disposons de toutes les informations nécessaires pour identifier et récupérer la BackupID associée. Via cette méta-donnée, le préfixe communauxfragmentestdisponible.grâceàcepréfixeetàl aidedenotre numéro de fragment contenu également dans le FragmentStorage, nous pouvons donc reconstruire le nom unique de la méta-donnée FragmentID dans laquelle nous insérons notre adresse IP, et que nous plaçons dans la DHT. Bien entendu, le préfixe commun aux fragments pourrait être mémorisé dans le FragmentStorage stocké localement. De plus, ceci permettrait à priori d éviter la consultation de la méta-donnée BackupID dans la DHT. Cependant, nous avons défini la BackupID comme étant la preuve même de l existence d un backup au sein du réseau. L absence de cette informationdansladht(oul expirationdesavalidité)signifiequesonauteuren a demandé la suppression. Le seul moyen de prendre conscience de ce fait, en tant que noeud mémorisant un fragment, est de consulter la BackupID. Nous profiterons donc des opérations inhérentes aux connexions et déconnexions pour consulter l état du backup pour lequel nous stockons localementunfragment,afindeleconserveretd informerlesystèmedesa disponibilité au travers de notre présence, ou de le supprimer dans l optique de ne pas consommer inutilement de l espace disque. 2.4 Confidentialité& Intégrité Réaliser un backup au sein d un environnement distribué implique de faire participer à la sauvegarde un certain nombre d autres noeuds. La donnéeestdisperséeauseinduréseauetchaquefragmenteststockéchez un noeud. Bien que la fragmentation puisse, dans une certaine mesure, rendre la lecture du fichier difficile, il n est pas exclu qu une partie soit lisible. Afin de rendre impossible la découverte d informations sur base d un fragment, et donc de garantir la confidentialité de la donnée sauvegardée, nous employons un mécanisme de chiffrement symétrique. La section a introduit la notion de chiffrement symétrique, reposant sur l utilisation d une architecture à clé publique pour la transmission d informations. Un algorithme de chiffrement symétrique est utilisé pour chiffrer la donnée m = ceipher(m, k)avecuneclésecrète k.afindenepasobligerl utilisateur de l application à mémoriser l ensemble des clés secrètes utilisées lors des différentes sauvegardes, nous allons sauvegarder cette informationavecladonnéechiffrée m viasaméta-donnée.cependant,mémoriser enclairlaclésecrète kavecladonnéereprésenteunrisqueindéniable:si un utilisateur accède à cette information, il peut alors retrouver le message m = ceipher(m, k)sansaucunproblème.l idée,afindegarantirquecela ne se produise pas, est d utiliser notre clé publique PuK de sorte à chiffrer laclésecrètedetellemanièreque,mêmesiellerestedisponible(danssa version chiffrée) à tous les utilisateurs, nous sommes les seuls à pouvoir l utilisergrâceànotrecléprivée.ainsi,laclésecrètechiffrée k = PuK(k) estassociéeàladonnée m = ceipher(m, k).pourdéchiffrerladonnée,ilsuffitdecalculer k = PrK(k )etensuite m = ceipher(m, k).

24 2.5 Haute-disponibilité 22 Garantir l intégrité des données sauvegardées signifie qu à aucun momentunutilisateurnepeutmodifierlecontenudecettedonnée,oud une partiedeladonnée.idéalement,unesortedeverrou(paranalogieàun coffre-fort) empêchera toute personne non autorisée de modifier la donnée. En pratique cependant, il n est pas possible d appliquer une telle sécurité. Nous nous contenterons de pouvoir détecter qu une modification a eu lieu, afindenousassurerqueladonnéequenousrécupéronsestbienladonnée à laquelle nous nous attendions. Pour ce faire, nous allons utiliser le mécanisme de signature numérique décrit dans la section A toute donnée m insérée au sein de notre réseau, nous allons ajouter sa signature numérique s.pourcefaire,nouscalculonsuncondensé digest = hash(m)quenous signons numériquement à l aide de notre clé s = PrK(digest). Puisque nous sommes les seuls à pouvoir calculer la valeur s cohérente avec le message m, toute modification du message rendra incohérente le condensé. Vérifier l intégritédeladonnéeserésumealorsàvérifierque PuK(s) = hash(m)à l aide de notre clé publique. 2.5 Haute-disponibilité Garantir la haute-disponibilité des données précédemment sauvegardées est le principal objectif de notre application. Une haute-disponibilité, idéalement, signifie que les données devraient être disponibles à tout instant. En général, il est impossible de garantir cette définition: erreurs logicielles, pannes matérielles, réseau indisponible ou encore simple déconnexion des noeuds possédant la donnée sont les principales causes d une perte de disponibilité. En informatique, il est naturel d envisager et de considérer ces différentes pannes. La disponibilité d un système ou d une donnée est couramment chiffrée à l aide de la notation dite en nombre de neufs. Formellement, nous mesurons la proportion de temps de disponibilitéparrapportàunepériodedonnéeetnousl exprimonsenunpourcentage ne comportant que des 9. Par exemple, % réfère un système en 4 neufs. Nous allons voir comment il est possible d atteindre une certaine disponibilité grâce à un mécanisme simple de réplication, solution généralement utilisée les applications de backup. Nous verrons également certaines limites de ce mécanisme, et proposerons une alternative plus efficace et moins coûteuse en terme de capacité de stockage au travers des codes correcteurs sous certaines hypothèses de stabilité du réseau(section 2.5.2) Mécanisme de réplication Supposons que nous sauvegardons une donnée quelconque sur un noeud dontladisponibilitémoyenneestnotée p [0, 1].Laprobabilitéderécupérerladonnée(ousadisponibilitéthéorique)estdoncde p.legraphique2.7 illustre différents résultats mettant en relation la disponibilité d une donnée en fonction de la disponibilité moyenne des noeuds. Sur ce graphique, la courbe(1) représente la disponibilité pour un seul fichier, non répliqué, c est-à-dire f(p) = p. Afin de profiter de la structure décentralisée de notre

25 2.5 Haute-disponibilité 23 FIG. 2.7 Disponibilité d une donnée en fonction des noeuds application, il est nécessaire d effectuer une fragmentation de la donnée àsauvegarder.cecipermetdenepasdépendred unseulnoeudpourla récupérationdeladonnéeetdenepaspénaliserunnoeuduniqueenlui envoyant une quantité importante de données. Cependant, la fragmentation induit une diminution de la disponibilité. Par exemple, si une donnée est fragmentée en deux, récupérer la donnée nécessite de récupérer chacundesfragments,c est-à-dire p 2.Plusgénéralement,sinousfragmentons en kfragments,laprobabilitéderécupérerladonnéeestde p k.lacourbe (2) du graphique 2.7 illustre le résultat, au travers duquel nous identifions clairement une perte de disponibilité avec 100 fragments. Or, si nous souhaitonslimiterlatailledechaquefragmentàunseuilacceptablede50ko par exemple, un simple fichier de 5 mo nécessite déjà 100 fragments. Une façon simple de compenser cette perte de disponibilité résultant de la fragmentation consiste à dupliquer un certain nombre de fois la donnée et, par extension, chaque fragment. Récupérer une donnée non-fragmentée dupliquée n fois nécessite de ne récupérer qu une seule copie de ces duplications. Puisque (1 p) représente la probabilité de ne pas pouvoir récupérer unecopie,laprobabilitédenepaspouvoirrécupéreraumoinsunecopieest (1 p) n.delà,noustirons 1 (1 p) n,laprobabilitédepouvoirrécupérer au moins une copie parmi les n. Cependant, bien que la réplication puisse rehausser la disponibilité théorique d une donnée, elle a un coût: chaque réplication nécessite en effet davantage d espace disque. De façon générale, si testlatailledeladonnéeàsauvegarder, t.nestlatailleutiliséesurle réseau après duplication: l espace disque requis est naturellement proportionnel au degré de duplication.

26 2.5 Haute-disponibilité 24 FIG. 2.8 Nombre de réplications en fonction de la fragmentation En associant le mécanisme de réplication au mécanisme de fragmentation,nousobtenonsunedisponibilitéthéoriquede (1 (1 p) n ) k.les3 dernières courbes du graphique 2.7 illustrent cette association avec n = {2, 3, 4}. Malheureusement, augmenter la duplication ne compense pas linéairement la fragmentation. Or, la fragmentation est indispensable si nous souhaitons profiter des propriétés d un réseau peer-to-peer et, de ce fait, la réplication l est également si nous souhaitons maintenir une disponibilité correcte. L espace disque total utilisé devient vite conséquent, même pour de petites données initiales. Le graphique 2.8 représente, pour une probabilité de disponibilité fixée à 0.9, le nombre de réplications nécessaires en fonction de la disponibilité moyenne de chaque noeud et du nombre de fragments. Toute augmentation de la fragmentation entraîne une augmentation relativement importante de la réplication, accentuée par toute diminution de la disponibilité moyenne des noeuds. Garantir une haute-disponibilité par le biais du mécanisme de réplication s avère rapidement extrêmement coûteux en espace disque et constitue donc une solution difficilement envisageable bien que couramment envisagée. Une alternative efficace et moins coûteuse au mécanisme de réplication repose sur l usage de codes correcteurs.

27 2.5 Haute-disponibilité 25 FIG. 2.9 Comparaison entre la réplication et les codes correcteurs Codescorrecteurs Nous avons vu que, de façon générale, les codes correcteurs de paramètres net kfragmententunfichierdetaille ten nfragmentsdetaille t k,soitunespacedisquerequisde t. n k [20,23,24].Seuls kfragmentssont nécessaires pour reconstituer la donnée initiale. Dans le cadre de notre application, nous considérons l utilisation du code Reed-Solomon, un code correcteur optimal, code dont l overhead est nul et donc pour lequel seuls exactement k fragments suffisent pour la reconstruction de la donnée. Ceci nous permet d avoir un système dont les résultats pratiques correspondent aux résultats théoriques- l overhead étant variable dans le cas contraire-, au prix de temps d encodage et de décodage plus importants mais néanmoins acceptables vu la nature lente d un backup par rapport aux applications de diffusion en temps-réel. En effet, le débit lors de l encodage/décodage atteint plusieurs Mo par secondes. La figure 2.9 compare les résultats obtenus en terme de disponibilité entre le mécanisme de réplication et le code correcteur pour une fragmentation et une consommation d espace disque identiques. Nous remarquons que la courbe du code correcteur suit une loi binomiale cumulative. Une loi binomiale de paramètres a et p correspond au modèle suivant: une épreuve de Bernouilli de paramètre p est renouvelée n fois de manière indépendante. pestlaprobabilitéd uneréussitedecetteépreuve, (1 p)l échec (ici:nepasrécupérerunfragment).nouscomptonsalorslenombrede succèsobtenusàl issuedes aépreuvesetnousappelonsxlavariablealéatoire mesurant ce nombre de succès. Cette variable aléatoire suit une loi de

28 2.5 Haute-disponibilité 26 FIG.2.10 Gainducodecorrecteurparrapportàlaréplication probabilité définie par: ( a p(x) = P(X = x) = x ) p x.(1 p) a-x Notrecourbesuitcetteloideparamètres a = net pdefaçoncumulative. Nous mesurons la probabilité de récupérer au moins k fragments parmi n (pour xallantde kà n): x=n x=k ( n x ) p n.(1 p) n-x Le graphique 2.10 illustre l apport indéniable de l utilisation d un code correcteur pour la disponibilité par rapport au mécanisme de réplication pour une même fragmentation(200 fragments) et un même espace disque utilisé(2 fois la taille initiale). Plus encore, l utilisation du code correcteur améliore la disponibilité lors de l augmentation de la fragmentation, contrairement au mécanisme de réplication. Nos observations concordent avec les travaux réalisés par LILLIBRIDGE[17] et WEATHERSPOON[13]. Le graphique 2.11 identifie l influence de la fragmentation sur les résultats du code correcteur. Toute augmentation de la fragmentation rapproche la courbededisponibilitédel asymptotesituéeen k n,c est-à-direaugmente legaindedisponibilitédeladonnéedèsque p > k n.cecinousamèneà la conclusion suivante: il est possible de paramétrer le code correcteur de sorte à s assurer une haute-disponibilité en toutes circonstances. En d autres termes, pour tout degré de fragmentation n et pour toute disponibilité moyenne p des noeuds, il existe une valeur du paramètre k garantissantunehaute-disponibilitépourunsurcoûtraisonnablede n k foisla taille initiale de la donnée.

29 2.5 Haute-disponibilité 27 FIG Influence de la fragmentation sur la disponibilité TAB.2.2 EchantillonderésultatsducodeRS, n = 2.k n = 100 n = 500 n = 1000 n = 5000 p = neufs >13neufs >13neufs p = 0.7 7neufs >13neufs >13neufs >13neufs p = neufs >13neufs >13neufs >13neufs Bien que cela dépende de l environnement et du contexte de l application, les constituants d un réseau créé dans le cadre d un backup distribué sont attendus comme étant relativement disponibles, par opposition aux réseaux d échange de fichiers tels que KaZaa, gnutella,... dans lesquels les connexions et déconnexions sont régulières et la durée moyenne d une connexion relativement courte. Nous considérons donc un réseau relativement stable au sein duquel les différents noeuds sont présents en moyenne unminimumde50%dutemps.decefait,nousfixons k = n 2avec p > 0.5. Bien entendu, un éventuel système de monitoring pourrait nous informer quecetteconditionn estpasremplie,auquelcasnouschoisirions n > k p. En toute généralité, l utilisation de codes correcteurs nous permet d obtenir facilement une disponibilité théorique minimale de plusieurs neufs (tableau 2.2), sans pour autant nécessiter davantage d espace disque. Les différentes simulations que nous avons effectuées corroborent ces résultats avecunemarged erreurinférieureà10-6.atitredecomparaison,unsystème en 2 neufs signifie une disponibilité de 99.99%, soit une indisponibilité demoinsde52minutesparan.

30 2.5 Haute-disponibilité Sauvegarde au niveau de la DHT Jusqu à présent, nous avons considéré que le stockage des données s effectuait au niveau des noeuds du réseau, fragment par fragment. Pourquoi nepasprofiterdeladhtpoureffectuerlasauvegardedesdonnéesdirectementauniveauduréseau?eneffet,nousavonsvu(en1.2.2)quela DHT offrait un service échelonnable, tolérant aux pannes et décentraliséexactementcedontnousavonsbesoindanslecadred unbackup.enréalité,ladhtn estpasadaptéeàlasauvegardededonnéesdetailleconséquente. Le mécanisme employé dans la DHT pour garantir une tolérance aux pannes et par extension, la disponibilité des données, est fort similaire au mécanisme de réplication. A tout moment, le service de DHT maintient unnombreconstantde frépliquesauseinduréseau.pourchaqueentrée deladht,unnoeudestdésignéresponsable(ensebasantsurlerésultat de hash(key))et f 1noeudssontchoisispourmaintenirunecopiedecette entrée. Lorsqu un noeud, qu il soit responsable de l entrée ou d une copie, se déconnecte du réseau, le service de DHT effectue une nouvelle copie dont il attribue la responsabilité à un autre noeud. De même, lorsqu un noeud se connecte sur le réseau et que ce noeud s insère à l emplacement désigné par hash(key), que ce soit pour une entrée spécifique ou l une de ses répliques, la DHT lui en transfère la responsabilité. Dès lors, chaque connexion ou déconnexion implique potentiellement le transfert d une certaine quantité dedonnées.sicettequantitéestimportante,parexempledanslecasdela sauvegarde d un fichier de plusieurs Mo, le temps nécessaire au transfert de la donnée concernée peut prendre plusieurs minutes et consommer une bande passante non-négligeable. Bien entendu, cela se ressent d autant plus rapidement si le dynamisme du réseau, c est-à-dire la propension qu ont les noeuds à se connecter et à se déconnecter, est important. Dans le cas contraire, la quantité de données à transférer sera moindre et, sous certaines hypothèses, négligeable. Cependant, puisqu un faible dynamisme signifie de faibles changements au niveau des noeuds, quel est l intérêt de maintenir un nombre conséquent de copies engendrant un surcoût en terme d espace disque? La réplication des données devient alors partiellement inutile: en l absence de tout dynamisme, f 1 répliques sont superflus. Nous allons nous intéresser plus précisément à la quantité de données transférées en présence d un certain dynamisme. Notons p la probabilité qu un noeud soit présent dans le réseau. Supposons que nous disposons d un réseau composé de n noeuds avec une quantité t de données sauvegardées dansladht.puisquelaprésencemoyennedesnoeudsestde p,nousaurons p.n noeuds dans le réseau, partageant ensemble une quantité t de données. Nous avons vu que la DHT garantit la disponibilité des informations grâce à un mécanisme de réplication en maintenant en permanence f copies de ladonnée.ilyadonc,autotal,unequantitédedonnéesde f.tdansladht. En théorie, la fonction de hachage utilisée pour distribuer les responsabilités au sein du réseau est uniformément répartie. Cela signifie que cette quantité f.tdedonnéesseradistribuéeenmoyenneàlahauteurde ft pn par

31 2.5 Haute-disponibilité 29 TAB. 2.3 Bande passante utilisée p 1000ko 2go ko/sec 3.56 mo/sec ko/sec 2.67 mo/sec ko/sec 1.77 mo/sec ko/sec 888 ko/sec noeud.autrementdit,chaquenoeudstockelocalement ft pn quantitédedonnéesissuesdeladht. Nous avons vu également que lors d une connexion, la responsabilité d une donnée peut être transférée. De la même façon, lors de la déconnexion d un noeud, il est nécessaire de maintenir le niveau de réplication en effectuant une nouvelle copie. Chacune de ces opérations implique le transfert de la donnée correspondante, c est-à-dire en moyenne, pour chaque noeud, ft pn. En partant du postulat que les connexions/déconnexions d un noeud sont uniformément réparties dans le temps, nous pouvons définir la probabilité qu unnoeudseconnecteousedéconnecteàuninstantdonné.eneffet, puisqu en moyenne, p.n noeuds sont présents dans le réseau, chaque noeud présenta(1 p)chancesdesedéconnecter,etchaquenoeudabsentap chances de se connecter au réseau. Plus généralement, puisque p.n noeuds sontprésentset (1 p)nnoeudsabsents,noussavonsqu ilyaura pn(1 p) déconnexions et (1 p)np connexions. Nous remarquons que, comme nous travaillons en moyenne, le nombre de connexions équivaut au nombre de déconnexions. A chaque instant donné, nous avons donc 2pn(1 p) transferts = 2ft(1 p). Enfixantunepériodedetemps s,noussavonsqu avecnnoeudsdans le réseau partageant t quantités de données, un degré f de réplication et une présence d une durée ps, la quantité moyenne de données transférées sera de 2f t(1 p). Plus précisément, la consommation en bande passante dedonnées,d unequantitétotalede 2pn(1 p). ft pn s élèveraà 2ft(1 p) s, deux fois inversement proportionnelle à la disponibilité moyenne des noeuds du réseau. Nous avons comparé, sur une période d une heure, le débit moyen requis pour les transferts de données dans le cas d une utilisation classique de la DHT(de petites informations telles que des méta-données) comparativementàuneutilisationdeladhtdanslecadred unsystèmedefichiers oudebackups.nousavonschoisidefixerleseuilderéplicationà4-une valeur courante utilisée par défaut dans DKS- et nous avons considéré que l ensemble des méta-données représentait environ 1000 ko et l ensemble des backups 2 go. Le tableau 2.3 reprend ces résultats. Le graphique 2.12 met en relation la présence moyenne des noeuds sur une période d une heure avec la taille, en Mo, des données considérées et présente le débit moyen exprimé en Mo/sec pour l ensemble du réseau. Il est aisément concevable qu une telle consommation de bande passante n est

32 2.5 Haute-disponibilité 30 FIG.2.12 Débitmoyen pas acceptable en pratique. C est pourquoi nous nous contenterons d utiliserladhtpourystockerdepetitesinformationstellesquelesmétadonnées et l exclurons lors de la sauvegarde des backups à proprement parler. Finalement, le mécanisme de réplication employé par la DHT s avère adaptéàdepetitesquantitésdedonnées[26].dèsquelatailled unedonnée dépasse un certain seuil, le service présente une contradiction: soit le dynamisme est suffisamment important pour justifier une réplication, dans cecas,laquantitédedonnéesàtransférerpénaliseleréseau,soitledynamisme est relativement faible et permet de négliger les transferts, auquel cas la réplication est majoritairement inutile. Puisqu à l heure actuelle, il n est pas possible de modifier dynamiquementleparamètre f,lenombrederéplicationsauseindeladht,pour s adapter en temps-réel au dynamisme du réseau, nous avons choisi de laisserdecotéladhtpourlaréalisationdesbackupsetnouseffectuerons cette dernière directement au niveau des noeuds. La DHT nous servira essentiellement pour la mémorisation des méta-données, qui sont de taille suffisamment petite que pour ne pas consommer trop de bande passante en cas de connexion/déconnexion d un noeud.

33 2.6 Détermination des candidats Détermination des candidats Nous avons vu que chaque donnée destinée à être sauvegardée au sein de notre application doit être découpée en un certain nombre de fragments. Idéalement, chaque fragment devrait être stocké indépendamment des autres auseind uncertainnombredenoeudsduréseau.cependant,cen estpas parcequ unnoeudestprésentdansleréseauqu ilestapteàeffectuerla sauvegarde d un fragment. En effet, un noeud peut voir sa capacité de stockage atteinte ou simplement être présent temporairement en vue de la récupération d un backup précédemment effectué, et non pas en tant que candidat à la sauvegarde. De plus, la topologie de DKS implique qu un numéro de noeud n est pas spécifiquement occupé par un noeud, autrement dit, un emplacement destiné à accueillir un noeud du réseau peut être libre. Dès lors, il est nécessaire de pouvoir identifier les noeuds présents dans le réseau qui sont aptes à répondre à notre requête de sauvegarde d un fragment de donnée. Dans un premier temps, nous supposerons que nous disposons d un moyen pour obtenir une liste de candidats. Nous verrons ensuite comment réaliser une telle liste. Cette liste devrait idéalement répondre aux objectifs suivants: 1. Exhaustivité: la liste se doit d être exhaustive, c est-à-dire qu il faut qu elle contienne l ensemble de tous les candidats disponibles dans le réseau. Seuls les noeuds absents, indisponibles ou saturés ne figurent pas dans cette liste. 2. Cohérence:lalistenepeutcontenirquelesnoeudsétantréellement candidats. A aucun moment il ne faudrait que cette liste contienne un noeud absent, indisponible ou saturé. 3. Légèreté:lemaintiend unetellelistenedoitpasconsommertropde ressources. Autrement dit, la bande passante et le nombre de messages envoyés doivent être aussi faibles que possible. 4. Souplesse: il doit être possible d obtenir une liste contenant un nombre spécifique d enregistrements, en fonction de la requête effectuée. En effet, il nous est inutile d obtenir une liste de plusieurs centaines de noeuds si nous ne requérons en réalité qu une petite dizaine d entre eux. Plusieurs approches existent afin de répondre dans une certaine mesure à ces objectifs. Les paragraphes suivants décrivent les principales solutions envisagées pour construire un mécanisme d obtention de liste de candidats Choixaveugle Puisque nous disposons d un mécanisme simple- DKS- pour mettre en relation les différents constituants du réseau P2P, il nous serait possible d envoyer chaque fragment au hasard à des éventuels noeuds. Ainsi, par exemple, si nous avions à sauvegarder une donnée fragmentée en 100 éléments, nous pourrions envoyer chacun de ces fragments aux noeuds numérotés de 0 à 99. Cependant, cette solution n est ni élégante ni performante

34 2.6 Détermination des candidats 32 et de nombreux problèmes apparaissent: Iln estpasimpossiblequemoinsde100noeudssoientprésentsdans le réseau, auquel cas plusieurs fragments seront envoyés à un même noeuddefaçoncyclique.sicenoeudest,parlasuite,peuprésent, cela vient fausser l hypothèse d indépendance des disponibilités sur laquelle se repose les résultats théoriques des codes correcteurs(section 2.5.2). Autrement dit, si ce noeud venait à disparaître du réseau, il pourrait emporter avec lui plus d informations que ce que le système peut théoriquement supporter. Delamêmefaçon,ilseraitdommagedenepasprofiterdelaprésence deplusde100noeudspourladonnée.siplusde100noeudssont disponibles, il pourrait être intéressant de fragmenter la donnée en davantage que 100 fragments, si la taille de chaque fragment s avère suffisante. Aucune distinction claire entre noeuds et candidats n est effectuée vialechoixenaveugle.iln estpasexcluqu unnoeudnousinforme qu il ne dispose pas d assez d espace disque ou tout simplement qu il ne fait pas tourner la partie serveur de notre application lorsque nous tenterons de lui envoyer le fragment concerné. Il est alors nécessaire d interroger un noeud supplémentaire à chaque fois qu un noeud précédemment interrogé nous informe qu il ne peut contribuer à notre backup. Ceci peut vite devenir fastidieux Interrogation par broadcast Une alternative au choix en aveugle consiste à interroger les différents noeudsduréseaugrâceàunmécanismedebroadcast.dksoffreuntel service de broadcasting. Cette solution consiste à émettre un message de broadcast qui sera alors envoyé à l ensemble des noeuds présents dans le réseau.enfonctiondesréponses,ilestaisédeconstruireunelistedenoeuds qui se disent candidats. Le principal avantage de cette méthode est qu elle permet d avoir une liste de noeuds ne comportant que des noeuds capables d accepter notre demande. Puisque nous recevons directement les réponses de ces noeuds, nous pouvonsaisémentdéfinirlenombredecandidats:ils agitdunombrederéponses positives. De là, nous pourrions définir la fragmentation idéale afin d attribuerunseulfragmentparnoeud.parcontre,riennenousditque certains candidats potentiels vont se déclarer: il n est pas impossible, pour des raisons de congestions, de machines temporairement indisponibles ou autre, qu un noeud ne puisse répondre volontairement ou involontairement à une demande. Il serait dès lors dommage d omettre certains candidats potentiels suite à un problème très ponctuel. L avantage du broadcast est qu il permet facilement de prendre contact avec la majorité des candidats potentiels au backup. Cependant, cet avantage nécessite d envoyer un message à l ensemble des noeuds présents dans le réseau. Autrement dit, pour chaque noeud présent dans le réseau, un message doit être envoyé. Bien que certains mécanismes au sein de DKS permettent de limiter la quantité de messages nécessaire pour effectuer un véritable broadcast, le nombre de messages envoyés peut vite devenir im-

35 2.6 Détermination des candidats 33 portant.ceciestdommageabledanslesensoùilestfortpossiblequela majorité de ces messages soient inutiles: Un noeud ayant répondu récemment, suite à une autre demande, qu il n était pas disponible a peu de chances de l être l instant d après. De la même façon, les noeuds déjà saturés en terme de capacité de stockage ont peu de chances de disposer de davantage d espace disque. De façon générale,l étatd unnoeud-candidatounon-estunétatquivariepeu sur une courte période de temps. Interroger régulièrement le réseau, c est-à-dire à chaque création de backup, s avère inutilement coûteux. Un backup peut nécessiter nettement moins de candidats qu il n y en a réellement dans le réseau. Par exemple, une donnée fragmentée en 100 éléments au sein d un réseau contenant 1000 noeuds, tous candidats, va consommer 10 fois plus de messages que nécessaire. Contrairement au choix en aveugle, la technique d interrogation par broadcast nous garantit une réponse fonctionnelle et utilisable. Cependant, elle nécessite de consommer une quantité non négligeable de ressources pour pouvoir fournir cette réponse Maintien dynamique d une liste Une façon simple de pouvoir construire et obtenir une liste idéale de candidatsauseinduréseauestdesupposerquecettelisteexistedéjàquelque part, et qu il suffit de la récupérer. Idéalement, il devrait être possible d obtenirlalistedescandidatsenunseulmessagedequestionetunseulmessage de réponse. Intuitivement, une telle requête serait: Donnez-moi 100 candidatspourlasauvegardede40ko. Lalistedescandidatsreçueen réponse ne devrait contenir que les candidats garantis, c est-à-dire qu en aucun cas ne devrait figurer dans cette liste un candidat déconnecté ou ne disposant plus de suffisamment d espace disque. Malheureusement, le seul moyen efficace pour maintenir une telle liste consisteraitàlefairedefaçoncentralisée-notreréseaunel estpas-,par une surveillance intensive des différents noeuds- nous n avons pas de monitoring- et en minimisant le nombre de messages nécessaire pour maintenir cette liste. Une méthode simple et élégante pour maintenir une telle liste consisterait à utiliser la DHT pour centraliser les données en se basant sur la notion de soft states[15]. Concrètement, chaque candidat se déclare au sein de la DHT en précisant la quantité de données qu il peut accueillir. La notion de soft states intervient dans la précision d une durée de validité de cette information. Le candidat doit alors renouveler cette information régulièrement pour informer le réseau qu il est toujours disponible pour la sauvegarde de données, sans quoi l information sera retirée de la DHT en mêmetempsquesacandidature.dupointdevueduclientsouhaitanteffectuerunbackup,ilsuffitderécupérerlesentréesdeladhtetdecontacter les candidats adéquats. Cette solution, bien que fonctionnelle, présente quelques inconvénients: Le maintien de l information afin de renouveler la date d expiration de l information nécessite l envoi régulier d informations supplémen-

36 2.6 Détermination des candidats 34 tairesparlebiaisdemessage.sipourquelquesnoeuds,celanereprésente pas une charge conséquente, ce n est pas le cas lorsque de nombreux candidats sont disponibles. Il est difficilement imaginable d appliquer une telle solution dans le cadre d un réseau contenant quelques centaines de candidats devant renouveler leur candidature toutes les heures. Il est difficile d évaluer la durée optimale de validité de l information. UneduréesuffisammentgranderisquedelaisserauseindelaDHT une information erronée car périmée. Par exemple, un noeud se proclamant candidat pour une période de 10 minutes pourrait se voir déconnecté du réseau dans la minute suivante. L information de candidature serait donc incohérente pour les 9 minutes à venir. Une durée suffisamment petite permet d éviter ce problème, mais implique une augmentation conséquente des informations circulant au sein du réseau pour pouvoir maintenir cette liste. Enfin, pour que la liste soit utilisable, il est nécessaire qu elle contienne la quantité d espace disque disponible pour chacune des candidatures présentes dans la liste. Cependant, cette information devrait être modifiée régulièrement car chaque backup entraîne une modification de cette quantité pour un certain nombre de candidats. Un nombre conséquent de messages supplémentaires seraient alors requis pour mettre à jour cette information. Déterminer les candidats nécessite d obtenir d une façon ou d une autre la liste des candidats disponibles ainsi que la quantité de données dont ils disposent afin de pouvoir choisir efficacement les candidats. Nous avons vu deux mécanismes faisant intervenir directement les noeuds, et un mécanisme faisant intervenir la DHT afin de maintenir en permanence une telle liste. Le choix de la solution dépend du contexte de l application: Silenombredeconsultationsdelalisteestimportant,ilseraitfortement intéressant de ne pas avoir à recalculer une liste de candidats à chaque consultation. Dans ce cas, la dernière solution proposée- le maintien dynamique d une liste- s avère intéressant. Silenombredeconsultationsdelalisteestfaible,ilestpossibled éviter la surenchère d informations envoyées sur le réseau pour le maintien d une liste en ré-évaluant la liste à chaque consultation. Les solutions de choix en aveugle et de broadcast travaillent de la sorte Limited Scope Flooding Nous avons choisi une solution adaptée à la deuxième situation: le nombre de consultations de la liste est faible en comparaison de la quantité de messages nécessaires pour maintenir dynamiquement une liste. Cette solution se base sur le principe de Limited Scope Flooding[8] utilisé notamment au sein des réseaux Gnutella. Elle ressemble fortement au broadcast,toutenlimitantlenombredemessagesàunevaleurdéfinie,proche du nombre de candidats nécessaires pour effectuer notre backup.

37 2.6 Détermination des candidats 35 FIG Détermination des candidats Concrètement, si nous requérons k candidats parmi n noeuds disponibles, nous envoyons un message à notre successeur contenant la quantité de données que nous souhaiterions sauvegarder, le nombre k de candidats souhaités ainsi que notre adresse. Nous pouvons profiter de la topologie en anneau de DKS pour envoyer ce message efficacement. En effet, comme chaquenoeuddksmaintientunpointeurdirectsursesvoisinsauseinde l anneau, il ne faudra qu un seul et unique saut pour contacter son successeur. Lorsque le successeur reçoit le message, il regarde s il dispose d assez d espace disque pour pouvoir satisfaire notre demande. Si c est le cas, il nous envoie une réponse en se proclamant candidat et décrémente k. Ensuite,si k > 0,iltransfèrelemessageàsonsuccesseur.Deprocheenproche, seuls les noeuds disposant d assez d espace disque et étant présents dans le réseau vont se proclamer candidats en nous répondant directement. Si k n où n estlenombredecandidatseffectifsauseinduréseau,nous obtiendronsunelistecontenantexactement kcandidats.si k > n,c est-àdire si nous demandons davantage de candidats qu il n y en a réellement, le message nous sera tôt ou tard transféré. En effet, quoiqu il arrive, dans une topologie en anneau comme celle de DKS, nous sommes toujours le successeur d un de nos successeurs. Dans ce cas, nous connaîtrons précisément le nombre maximum de candidats disponibles pour notre backup: il s agit de la valeur initiale de k à laquelle nous soustrayons la valeur de k contenue dans le message que nous venons de recevoir. Cette solution répond aux objectifs que nous nous étions fixés pour déterminer des candidats: 1. Exhaustivité: puisque le message est transféré de successeur en successeur, nous sommes assurés de ne rater aucun candidat potentiel au

38 2.6 Détermination des candidats 36 sein du réseau. 2. Cohérence: seuls les noeuds répondant positivement à notre requête sontcandidats.iln yaàaucunmomentdefauxcandidats. 3. Légèreté: seule la consultation de la liste implique l envoi d informations. De façon générale, le nombre de messages envoyés sera toujours inférieurà n(enmoyenne,égalà n n.k)etdoncinférieuraubroadcast. Demême,lenombredemessagesreçusserainférieurà min{n, k}. 4. Souplesse:parladéfinitiondelavaleur k,nouspouvonsadapter notre requête à nos besoins. Le graphique 2.13 illustre typiquement une requête en vue d obtenir k = 4 candidatsparmi n = 12noeudsprésents.Noussommeslenoeud0etles noeuds1,4,5et9répondentpositivementànotrerequête.lesnoeuds pleins sont présents, les noeuds vides sont absents.

39 CHAPITRE 3 EXPÉRIMENTATIONS Maintenant que nous connaissons les différentes notions théoriques permettant de remplir les objectifs de transparence, de haute-disponibilité, de confidentialité et d intégrité ainsi que certains des mécanismes sous-jacents comme la sélection de candidats au sein du réseau, nous allons décrire l implémentation d un prototype. Nous distinguerons deux applications: Une première application, Reed-Solomon Erasure Code(RSEC), qui permet l encodage et le décodage d informations par le biais d un code correcteur, celui de Reed-Solomon. Cette application permet la fragmentationdesdonnéesetaétéconçueentantquemoduleàpartentière d une application de backup distribuée, afin de pouvoir éventuellement la remplacer ultérieurement par d autres outils de fragmentation tels que les Tornado Codes. Une seconde application, Distributed Backup System(DBS), qui effectue concrètement un backup au sein d un réseau décentralisé construit grâce à DKS(section 1.2.3). Cette application nécessite l utilisation d un module externe pour la fragmentation des données. Les sections suivantes décrivent les implémentations respectives de RSEC et de DBS. Ensuite, nous présenterons concrètement ces applications et leur fonctionnement du point de vue de l utilisateur. Finalement, nous étudierons plus en détail certains aspects pratiques rencontrés avant de conclure sur les résultats et performances de ces applications. 3.1 Implémentations Implémentation de RSEC RSEC- Reed-Solomon Erasure Code- est une application graphique permettant l encodage et le décodage de données grâce au code correcteur Reed-Solomon. RSEC est essentiellement un front-end pour la librairie, légèrement modifiée, py_ecc d encodage et décodage RS. Nous avons écrit RSEC en Python 2.4, utilisant GTK2 pour la partie graphique. La réalisation d une application externe à l application de backup distribuée pour l encodage et le décodage des données nous permet d envisager l utilisation

40 3.1 Implémentations 38 denombreuxautrescodessansavoiràmodifierlastructureoulecomportement interne de l application de backup. Les sections suivantes décrivent brièvement les différentes technologies employées. Une description plus complète du fonctionnement de l application est réalisée en section Python Nous avons choisi d écrire RSEC en Python 2.4. Python est un langage de programmation interprété et multi-paradigmes[28]. Il permet le développement suivant la programmation impérative structurée, orientée-objet et fonctionnelle. Python est, en outre, doté d un typage dynamique fort, d une gestion automatique de la mémoire par un garbage-collector indéniablement plus efficace que celui de Java, d un système de gestion d exceptions et, dans l ensemble, d un nombre impressionnant de modules hautniveau facilitant son utilisation quel que soit le contexte. Bien qu interprêté, Python est très rapide et nous permet d obtenir des débits satisfaisants pour l encodage et le décodage Reed-Solomon. GTK2, pygtk& Glade GTK-GimpToolKit-estunensembledebibliothèqueslogiciellesdéveloppées originellement pour les besoins du logiciels de traitement d images GIMP[27]. GTK propose une série de fonctions permettant la création et l utilisation d interfaces graphiques logicielles. Dans le cadre de RSEC, nous avons choisi GTK+ 2.0 pour la partie graphique, la seconde évolution majeuredegtk.gtk+2.0reposesurunnouveaumoteurderendu.afin de profiter aisément des possibilités offertes par GTK+ 2.0, nous utilisons Glade. Glade est un outil interactif de construction d interfaces graphiques GTK+ 2.0[4]. Glade enregistre au format.xml[14] les différents composantsgraphiquesduprojet.lalecturedecefichier.xmlparpythonau travers de libglade, la librairie de transition, permet d utiliser l interface graphique GTK2 ainsi construite, en associant les différents signaux définissant les actions possibles au sein de l application. La bibliothèque permettant la gestion des interfaces graphiques GTK en Python est pygtk, orientée objet et d une facilité d utilisation déconcertante en comparaison de Swing(Java). UnautreavantagedeGladeestqu ilestsupportépardenombreuxlangages de programmation, offrant une portabilité conséquente de la partie graphiquedel applicationenc++,java,perl,c#...commegtk+2.0est également multi-plates-formes, ceci permet la réalisation de front-end puissants, agréables et portables. py_ecc RSEC repose sur la librairie py_ecc pour l encodage et le décodage Reed- Solomon. py_ecc est une librairie écrite par EMIN MARTINIAN et disponible librementsursonsite 1.Lalibrairiecontientunensembled outilsfacilitant 1

41 3.1 Implémentations 39 le calcul d opérations sur champs finis[7], diverses opérations sur des matrices sur ces mêmes champs ainsi que des opérations élémentaires pour l encodage et décodage utilisant le code Reed-Solomon. py2exe& FreezePython Puisqu il n est pas compilé mais interprété, Python n offre pour ainsi dire aucun mécanisme intégré permettant la création de binaires. Si, dans les systèmes Linux, ce n est pas problématique- de nombreuses distributions possèdent nativement un interpréteur Python-, ce n est pas le cas pour les systèmes Win32. Afin de fournir une version binaire aisément utilisable de notre application RSEC, nous avons utilisé les outils py2exe et FreezePython. Ces deux outils permettent de convertir un script Python.py en un exécutable.exe en dehors de toute installation de l interpréteur Python. Sans rentrer dans les détails, les différentes librairies utilisées sont gelées par l outil et ensuite empaquetées. Un interpréteur minimal est copié et associé aux librairies pour former un fichier exécutable. Dans le cas de RSEC, nous avons du conjointement utiliser ces deux outils afin d exporter correctement les fonctions graphiques requises. L utilisation du binaire au sein d un environnement win32 ne nécessite finalement que les GTK 2.0 Run-TimeEnvironment 2 ensusdel applicationrsec Implémentation de DBS Nous avons développé un prototype de notre application dans le cadre delaconférenceinternationalegrid@mons Ceprototype,DBS-Distributed Backup System-, écrit en Java et multi-threads, permet d effectuer un backup au sein d un réseau DKS. S agissant d un prototype, le lecteur ne s étonnera pas de ne pas retrouver l ensemble des fonctionnalités discutées précédemment. Par convention, nous avons préfixé certaines classes du mot-clé Easy afin de souligner le fait qu il s agit de classes offrant une abstraction de plus haut niveau pour l utilisation des différents outils de communication (DKS, DHT, TCP,...) sans avoir à se préoccuper des(nombreux) mécanismes complexes sous-jacents. Nous avons également regroupé un certain nombre d outils destinés à faciliter la création et la récupération d un backup distribué, avec pour objectif de proposer un système modulaire indépendant des couches inférieures. Ces outils sont classés en fonction de leur contexte d utilisation:soitdanslecadredelapartiecliente,soitdanslecadredela partie serveur. MetaData Nous avons écrit une classe permettant d abstraire le concept de métadonnées. Cette classe MetaData est, en réalité, une classe gérant finement la sérialisation d un ArrayList(tableau dynamique de données) dans le contexte approprié. Cette classe permet de passer simplement d une chaîne LeGrid@Mons2007estlapremièreconférencedelasérieGrid@Monsorganiséeàl UMH, le4mai2007

42 3.1 Implémentations 40 de caractère représentant une méta-donnée(telle que sérialisée) à une table contenant un ensemble de couples sous la forme(clé,valeur). MetaData propose les méthodes classiques get(key), has(key), has(key, value), set(key, value), add(key, value), remove(key) ainsi que deux méthodes concernant la sérialisation set(serialized) et get() retournant la version sérialisée de notre méta-donnée. La version sérialisée est hautement paramétrable: il est possible de spécifierunmarqueurdedébut,unmarqueurdefin,unséparateurdecouples et un séparateur de valeur. Par défaut, nous avons choisi le formalisme suivant: MD[Key1:Value1;Key2:Value2;...;KeyN:ValueN] Récupérer la valeur associée à une clé Key2 se fait alors simplement en vérifiant sa présence via has( Key2 ) suivi de get( Key2 ). Un appel direct à get( Key2 ) peut être effectué, retournant une valeur null si cette clé n existe pas. MDCheck De par l implémentation du concept de méta-donnée, le contenu(en terme declés)decesdernièrespeutdifférerdel uneàl autre.puisquenoustravaillons avec un nombre réduit de types différents de méta-données, trois en l occurrence, il pourrait être intéressant de disposer de méthodes vérifiant qu une méta-donnée est de l un des types autorisé. La classe MDCheck fournit ces méthodes. Ainsi, il est possible d obtenir facilement le type d une méta-donnée par l utilisation de la méthode gettype(), voire de vérifier si une méta-donnée est d un type particulier, par exemple via isbackupid(), isfragmentid(), isfragmentstorage()... Lavérificationd untypesefaitsurbasedeladéfinitiondecertains attributs(ou clés) de la méta-donnée. Par exemple, la détection d une métadonnée de type BackupID se fait en s assurant qu elle contient des valeurs associées aux champs name, author, fragment_name, fragment_number et quelechamptypecontientbienlavaleurbackup.ilenvademêmepourles deux autres types de méta-données. EasyDKS Cette classe présente une abstraction de haut niveau dans l utilisation de certains composants de DKS. Elle n a pas pour but de retranscrire toutes les fonctionnalités de DKS, mais uniquement les plus courantes et, notamment, celles qui sont indispensables à la réalisation de notre application. A ce titre, EasyDKS permet aisément de créer ou rejoindre un réseau logique DKS sans avoir à se préoccuper du gestionnaire de connexion, des adresses de l Overlay Network ni même des différents wrappers employés par DKS. Rejoindre un réseau DKS se fait simplement en spécifiant l adresse externe d un noeud DKS(une dks overlay address ) qui peut être aisément récupéréeparlebiaisdesoutilsquenousavonsimplémentés,surbasedel adresse IP du noeud uniquement. L obtention d un numéro de noeud au sein de DKS est automatique lors de la connexion à un réseau existant, puisque, en tant que middleware, DKS

43 3.1 Implémentations 41 ne propose pas nativement de mécanisme permettant de façon naturelle de rejoindre un réseau. A contrario, DKS impose une attribution manuelle d un numéro de noeud avant chaque tentative de connexion. Si le numéro choisi est déjà réservé, la connexion échoue. Nous proposons une méthode qui utilise notre adresse IP hachée par sha 1, limitant ainsi les collisions. En cas de collision, nous choisissons aléatoirement un numéro dans l intervalle autorisé, en espérant que les éventuels échecs successifs de connexion nesoientpasdusàunréseausaturéenparticipants,situationquenousne pouvons malheureusement détecter. La classe présente également une série de services permettant d obtenir facilement des informations concernant les différents noeuds du réseau: référenceinterneauseindedks,numérodenoeuds,adresseippourles connexions directes,... EasyDHT EasyDHT est une classe visant à simplifier la manipulation de la DHT de DKS. Elle utilise implicitement l algorithme SHA-1 pour le calcul des valeurs de hachage des clés. Elle offre un degré d abstraction appréciable quantàl utilisationdesmécanismesdeladht:l ajoutdedonnéesausein de la DHT est réalisé simplement en appelant la méthode add(string key, String value). De la même manière, la récupération d une donnée s effectue grâce à get(string key) sans avoir à se préoccuper des différents mécanismes employéspardkspourassurerleservicededht. De plus, cette sur-couche de la DHT présente la possibilité de ne récupérer qu une seule(la première) des valeurs associées à une clé, la suppression d un couple(clé, valeur) ou, simplement, de toutes les valeurs associées à une clé donnée. Conjointement utilisée avec MetaData, la classe EasyDHT nous offre un service simple pour l utilisation de méta-données au sein de DKS. EasyTCP JavagèrenativementlesconnexionsréseauxTCPetUDPparlebiaisde plusieurs wrappers: socket, stream, buffer, buffers de lecture et d écriture. Idéalement, nous souhaiterions réduire le nombre de méthodes et de wrappersàmanipulerlorsdesconnexionstcp,quecesoitentantqueclientou serveur. La classe EasyTCP réalise ce travail. Elle peut être instanciée en tantqueclientenfournissantuneadresseipdistanteainsiqueleportà joindre, ou en tant que serveur en précisant uniquement le port d écoute. Deux méthodes simples fournissent la base de la communication TCP de DBS: send(message) et receive(). Toutes deux travaillent implicitement sur des flux d entrée et de sortie, sans que cela ne soit visible pour l utilisateur quin aconnaissancequedurésultatdecesfluxsouslaformedechaînesde caractères. Bien entendu, EasyTCP a été conçue dans l optique d un environnement multi-threads et est donc capable de poursuivre plusieurs connexions TCP en parallèle aussi bien coté client que coté serveur. C est typiquement dans cette configuration que nous l utilisons au sein de DBS: la partie serveur

44 3.1 Implémentations 42 de DBS écoute sur un port unique les différentes connexions entrantes et lesgèreuneàunedansunthreaddistinct. Dialog Notre application se présente sous la forme d une application interactive par opposition aux outils en ligne de commande(batch). Il est donc impératif de disposer de moyens de communication avec l utilisateur. L interface Dialog définit l ensemble des services devant être offerts par toute implémentation de cette interface Java. Ces services sont décrits comme étant les services requis pour toute interaction entre l utilisateur et l application DBS. Nous avons développé deux classes implémentant l interface Dialog: DialogConsole et DialogGUI. Chacune d elle remplit librement les mécanismes permettant d interagir avec l utilisateur en lui affichant certaines informations, en lui demandant de répondre à une question dans un format indiqué(chaîne de caractères, entier ou fichier),... La première implémentation, DialogConsole effectue ceci par le biais d un terminal et repose sur l utilisation des flux d entrée/sortie par défaut, typiquement une console locale ou distance(ssh). A contrario, DialogGUI répond à ces besoins via une interface graphique, Swing en l occurrence. Ceci rend l utilisation de l application beaucoup plus claire et conviviale qu en mode console. Deparlanaturemodulairedenotreapplication,ilesttoutàfaitenvisageable d étoffer la liste de ces outils d interaction avec l utilisateur, sans avoiràmodifierlecodeenprofondeur.eneffet,ilsuffitdefourniruneclasse implémentant l interface Dialog pour pouvoir l utiliser dans l application. ClientTools ClientTools se veut un ensemble d outils résumant les principales fonctions nécessaires à un système de backup décentralisé coté client. Les paragraphes suivants décrivent les différents outils disponibles: getdksreffromip(ip) Tente d obtenir la référence DKS d un noeud sur basedesonip.cetteméthodenouspermetd éviterderentrermanuellement la longue URL DKSRef nécessaire pour rejoindre un réseau DKS. La méthode contacte l adresse IP indiquée et lui demande de retourner cette référence DKS. getmybackup(dht,name,author) Cette méthode tente de récupérer la méta-donnée associée au backup dont le nom et l auteur sont fournis en paramètres. Cette méta-donnée correspond à la BackupID. getfragmentslocalization(dht,backup) Sur base de la BackupID, retourne une liste des méta-données disponibles au niveau de la DHT et contenant les informations de localisation des fragments, c est-à-dire les FragmentID. Cette méthode ne vérifie pas si le noeud concerné par chaque FragmentID est réellement disponible ou non. checkfragment(fragmentid) Vérifie si le fragment désigné par le FragmentID donné est disponible ou non. Cette méthode est particulièrement utile pour la méthode getverifiedipaddress() ci-dessous.

45 3.1 Implémentations 43 getverifiedipaddress(fragmentidlist) Sur base de la liste des métadonnées FragmentID retournée par la méthode getfragmentslocalization(), vérifie un à un la disponibilité réelle de chaque fragment grâce à checkfragment() et retourne une liste ne contenant que les FragmentID réellement disponibles. getfragment(fragmentid) Contacte le propriétaire physique d un fragmentetrécupèresoncontenusouslaformedelaméta-donnéefragmentstorage. Le fragment concerné est celui dont la localisation est fournie au travers du FragmentID donné en paramètre. sendfragmentstorage(ip,fragmentstorage) Envoie le FragmentStorage à l adresse IP indiquée. Cette méthode retourne faux si elle n a pas pu envoyer l information. Elle est utilisée par son équivalent surchargé ci-dessous. sendfragmentstorage(iplist,fragmentstoragelist) Envoie les FragmentStorage fournis aux adresses IP indiquées. L algorithme boucle surlalistedesadressesipsiunedesipnerépondpasousilaliste contient moins d IP qu il n y a de FragmentStorage. Cette méthode permet de distribuer les différents fragments au sein du réseau. Elle retourne faux si la liste d IP n était pas suffisante pour couvrir les différentsfragmentsetqu unbouclageaeulieusurlesip. getcandidates(ip,myip,k,t) Récupère k adresses IP de candidats pouvantmémoriserunequantitétdedonnées.ipestl adresseipdenotre successeur dans DKS(ou du premier noeud que nous souhaitons contacter). A l exception de quelques structures de contrôle supplémentaires, ceci résume l ensemble des outils nécessaires pour gérer la partie cliente de DBS. ServerTools ServerTools propose un ensemble d outils regroupant les principales fonctions nécessaires à la partie serveur de l application: getfragmentid(dht,fragmentlist) Récupère l ensemble des FragmentID de la DHT associés aux FragmentStorage fournis en paramètre. La liste des FragmentID récupérée permet par la suite d effectuer la correction à la connexion/déconnexion des candidats en supprimant de la DHT cette liste. setfragmentid(dht,ip,fragmentlist) Référence auprès de la DHT les différents FragmentID associés aux FragmentStorage donnés en paramètre, à condition que le BackupID correspondant soit accessible et valide. Cette méthode retourne une liste des FragmentStorage dont le BackupID associé n est pas valide. hasavailablespace(size) Assez curieusement, il a fallu atteindre Java1.6 pour disposer dans l API d outils calculant l espace disque disponible pour un système donné. Comme nous souhaitions une application fonctionnelle également en Java1.5, cette méthode compense une lacune de Java1.5 et réalise ce travail, en nous indiquant s il reste suffisamment d espace disque pour mémoriser size ko.

46 3.1 Implémentations 44 managerequestmessage(ip,myip,message) Cette méthode répond aux messages de type request utilisés pour récupérer une liste de candidats. Sur base de l adresse IP du successeur(pour transférer la requête si nécessaire), de notre adresse IP(que nous envoyons à l auteur initial de la requête) et du message(contenant la quantité désirée d espace disque ainsi que le nombre de candidats restant à contacter), cette méthode nous déclare candidat si nous disposons de l espace nécessaire et transfère le message à notre successeur si nécessaire. managecheckmessage(tcp,message) Cette méthode traite les messages detypecheckdemandantdevérifiersiunfragmentdonnéeststocké localement. Elle retourne vrai si et seulement si le fragment est accessible localement. La réponse est automatiquement envoyée à l expéditeur du message. managesendmessage(tcp,message) De la même façon, managesendmessage() gère les messages de type send, c est-à-dire les demandes d envoi d un fragment stocké localement. Si le fragment est disponible, la méthode répond à l auteur de la demande et lui fournit le fragment. Si non, elle lui indique simplement qu elle ne dispose pas du fragment demandé. Le résultat de la requête est retourné par la méthode. managestoremessage(tcp,message) Sur base d un message de type store associé à une demande de sauvegarde d un fragment, cette méthode contrôle l espace disque disponible et répond en conséquence. Le fragment est alors téléchargé et sauvegardé localement. Le statut du transfertestenvoyéenréponseàl auteurdelarequête,ainsiqueretourné par la méthode. getfragmentstorage() Retourne l ensemble des FragmentStorage stockés localement. Afin de ne pas charger la mémoire d informations superflues, le champ content de la méta-donnée est vide. Cette méthode permetderécupérerlalistedecequieststockélocalement,envuepar exemple, de mettre à jour les informations de localisation en ligne Vue d ensemble de DBS La figure 3.1 reprend une vue d ensemble des différents modules de l application. Bien que Java soit un langage orienté-objet, nous avons préféré écrire la majorité des outils dans un style impératif voire fonctionnel afin de faciliter la portabilité du code vers d autres langages de programmation. Aucentredecettevuesesituel applicationdbs.dbsemploielemiddlewaredkspoursemettreenrelationaveclesautresnoeuds.dedbs, nous distinguons deux grandes parties: le coté client et le coté serveur. Chacun d eux dispose d un ensemble d outils permettant de répondre aux besoins de l application. Les outils travaillent tantôt avec les méta-données, tantôt avec la DHT(nécessitant DKS), tantôt avec des connexions TCP. La structure de données principalement utilisée est la méta-donnée. Celle-ci est alternativement utilisée dans le cadre des connexions TCP(lors des échanges de messages plus complexes), pour la sauvegarde de données (méta-donnéestockéeendursurledisque)ouencoreauseindeladht.

47 3.2 Présentation des applications 45 FIG.3.1 Vued ensemblededbs Plus généralement, elles sont utilisées communément par les différents outils, qu ils soient dans ClientTools ou ServerTools. Finalement, les différentes connexions TCP entrantes sont gérées par le module ServerThreadHandler qui distribue directement ces différentes connexions au travers des threads ServerThread qui les récupèrent et les gèrent.cesontcesdifférentsthreadsquifontappelauxméthodesdela classe ServerTools pour répondre aux demandes clientes. 3.2 Présentation des applications ApplicationRSEC Présentation RSEC- Reed-Solomon Erasure Code- est une application d encodage et de décodage de données par le biais du code correcteur Reed-Solomon. L application, écrite en Python, se présente sous la forme d une interface graphique simple et intuitive. Les différentes fonctionnalités sont réparties en onglet: encodage(figure 3.2), décodage(figure 3.3) et onglet d informations. Pour encoder une donnée avec RSEC, il suffit de sélectionner le fichier concerné(ou l ensemble des fichiers concernés par le biais d une archive), de spécifier le répertoire de sortie de l encodeur ainsi que le préfixe qui sera utilisé pour les différents fragments. Il est possible de modifier les paramètres d encodage: le nombre de fragments générés ainsi que le nombre minimal de fragments nécessaires pour reconstituer la donnée initiale. Une option supplémentaire permet de générer un fichier d extension.dbs, utilisé uniquement dans le cadre de DBS pour identifier localement le fichier qui

48 3.2 Présentation des applications 46 FIG.3.2 RSEC-Encodage FIG.3.3 RSEC-Décodage sera sauvegardé au sein de l application de backup. Ce fichier utilise un formalisme proche de nos méta-données et contient les informations indispensables pour utiliser à bon escient le résultat de la fragmentation faite parrsecdansdbs. L encodage d une donnée peut nécessiter plusieurs secondes lors des premières utilisations. La librairie sous-jacente met en cache certains résultats afin de réduire le temps de calcul lors des opérations ultérieures. Une fois l encodage terminé, différents fragments xxx.p_1, xxx.p_2,... sont présents dans le répertoire de sortie. Décoder les données se fait de façon analogue dans l onglet adéquat. Une liste permet d ajouter des fragments et le chemin vers le fichier résultant peut être spécifié. L application va alors vérifier qu elle dispose de suffisamment de fragments pour pouvoir reconstituer la donnée et, le cas échéant, produire le fichier initial en sortie. La liste des fragments peut être modifiée à la volée afin de tester différents comportements.

49 3.2 Présentation des applications 47 Résultats Lesrésultatspratiques 4 del applicationviennentrejoindrelesrésultats auxquels nous nous attendions en théorie. Suivant les paramètres (n, k), toutfichierfragmentéen nfragmentspeutêtrerecomposéàpartirde k fragments.latailledechaquefragmentestde t k auquels ajouteunléger overhead de quelques octets, pour les informations d en-tête nécessaires à la reconstruction de la donnée. L application souffre cependant de quelques limitations: le temps nécessaire à l encodage peut, dépendant des informations précachées, grandement varier et atteindre parfois plusieurs minutes pour un fichier de petite taille là où un fichier de plusieurs mega-octets est encodé en quelques secondes.sicen estpaspénalisantdanslecontextedubackup,cecirend l utilisation de RSEC délicate dans des contextes plus exigeants tels que les applications temps-réel. Par ailleurs, la librairie py_ecc sous-jacente nous impose un seuil maximum de 256 fragments(le paramètre n), ce qui peut s avérer limitatif dans un environnement de grande envergure(typiquement, un réseau DKS de plusde256noeuds).bienentendu,entantqu outilexterneàdbs,ilestenvisageable d utiliser d autres applications semblables à RSEC pour réaliser un traitement similaire sans ces limitations ApplicationDBS Présentation Distributed Backup System est le coeur de notre application de backup distribuée qui effectue l ensemble des opérations permettant de réaliser et de récupérer un backup au sein d un environnement décentralisé. DBS a été écritenjavaetutiliselemiddlewaredkspoursemettreenrelationavec les autres noeuds du réseau. L application se présente premièrement sous la forme d un outil en ligne de commande. En réalité, l utilisateur dispose dèsledébutdeladuchoixentreuneinterfaceenlignedecommandeou une interface graphique plus élégante. Nous avions défini la transparence comme l un des principaux objectifs de DBS. A ce niveau, l application ne pose que quelques questions un tant soit peu techniques. Il s agit, et ce n est pas insurmontable, de préciser si DBS créer un nouveau réseau ou rejoindre un réseau DKS existant. Outre le port sur lequel travaillera l application, l utilisateur précisera l adresse IPd unnoeuddéjàprésentdansleréseau. Ces informations entrées, l utilisateur n a plus à se soucier d informations techniques techniques. Une fois le réseau rejoint ou créé, diverses optionss offrentàlui(figure3.4).ilpeutchoisirdecréerunnouveaubackup, d en supprimer un ou récupérer un backup préalablement effectué. Dans le cas de la création d un nouveau backup, l utilisateur est invité à fournirunnomàcebackupainsiqu àdéclinersonidentité.ilsevoitalors proposer de sélectionner le fichier(qui peut être un ensemble de fichiers par 4 Al exceptiond unoverheaddequelquesoctets

50 3.2 Présentation des applications 48 FIG.3.4 DBS-Options le biais d une archive) qui sera alors sauvegardé par l application. L applicationprocèdeàlasélectiondescandidatsets occuped envoyerunàunles différents fragments du backup en calculant les méta-données nécessaires etenmémorisantauseindeladhtlacarted identitédubackup. La suppression ou la récupération d un backup se fait de façon tout aussi naturelle:ilsuffitàl utilisateurdepréciserlenomdubackupconcernéet de s identifier. Sur base de ces informations, l application effectue le travail: soit la suppression de la carte d identité(et par extension, la suppression implicite des fragments auprès des candidats concernés, soit la récupération des données de localisation des différents fragments via la DHT et la récupération des fragments disponibles et nécessaires sur base de ces localisations. A des fins de test, l utilisateur peut également obtenir des informations plus techniques concernant l application, démarrer ou arrêter la partie serveurouencoreeffectuerquelquesrequêtesauniveaudeladhtetdes connexions TCP avec les différents intervenants du réseau. Ceci ne devrait être présent dans une application finale grand public, mais permet d étudier et comprendre la réaction des différents composants de l application. Scénarios Cette section décrit plus en détail les quatre principaux scénarios rencontrés lors de l utilisation de l application. Nous proposons une alternative visuelle aux descriptions de ces scénarios par le biais de diagrammes proches des diagrammes UML d état-transition pour lesquels le formalisme a été simplifié afin d en faciliter la compréhension. Voici une brève descrip-

51 3.2 Présentation des applications 49 FIG. 3.5 Diagramme: création d un backup tiondeceformalisme: Lepointd entréedanslediagrammeestsymboliséparuncerclenoir. Un cercle plein circonscrit dans un autre cercle représente un point de sortie. Nous distinguerons les sorties avec succès des sorties avec échec. Les rectangles arrondis symbolisent des états. Les rectangles blancs sont associés à une action, alors que les rectangles grisés sont des états simples. La transition d un état à un autre peut être conditionnée: Les transitions entre différents états sont représentées par des flèches. Certaines flèches sont annotées soit à titre informatif soit pour conditionnerlepassaged unétatàunautre.danscecas,lestransitions seront issues d un losange symbolisant le résultat de la condition. Ce losangeestlui-mêmereliéàunétat,celuiauquelserapportelacondition.enfonctiondelavaleurdecetétat,unedestransitionsestempruntée à partir du losange. Création d un backup(figure 3.5) Lorsque l utilisateur souhaite effectuerlebackupd unedonnéeauseinduréseau,ildoitprocéderendeux étapes. Tout d abord, il choisit le ou les fichier(s) qu il souhaite sauvegarder. Dans le cas de plusieurs fichiers, l utilisateur est invité à les regrouper au sein d une archive. Puisque notre prototype ne dispose pas d un mécanisme intégré garantissant la confidentialité, c est à cette étape que l utilisateur peut chiffrer manuellement, via l outil de son choix, le fichier concerné. Il utilise ensuite RSEC pour fragmenter la donnée grâce à l utilisation des codes correcteurs. Le degré de fragmentation est laissé libre, permettant de choisir le meilleur rapport entre la disponibilité et le surcoût du point de vue stockage. Par défaut, nous proposons une décomposition en 16 fragments dont seule la moitié est nécessaire pour recomposer la donnée. RSEC dispose d une option permettant de générer un fichier à l extension.dbs qui sera utilisé par la suite par l application DBS.

52 3.2 Présentation des applications 50 Une fois la fragmentation effectuée, l utilisateur amorce notre application,rejoint(oucrée)unréseaudksenprécisant(danslecasoùilexiste déjà)l adresseipd unnoeuddeceréseau.danslemenuprincipaldedbs, il sélectionne l option de création d un nouveau backup. Il est alors invité àpréciserlenomdecebackup(typiquement,lenomdufichierconcerné) ainsi qu à s identifier. Il sélectionne ensuite le fichier d extension.dbs généré par RSEC. Ce fichier regroupe les informations indispensables pour que DBS effectue correctement le backup. Surbasedunombredefragments,DBSenvoieunerequêtederécupérationd unelistedecandidatsàtraversleréseau.auboutdequelques secondes, DBS dispose d une telle liste. A ce stade, plusieurs cas sont envisagés: La liste est vide, aucun noeud n est actuellement disponible. Dans ce cas, l application ne peut poursuivre et le backup n a pas lieu. Cela signifie soit qu aucune autre machine n est présente dans le réseau, ouqu aucunnoeudnedisposed assezdeplace(oudevolonté!)pour mémoriser un(ou plusieurs) fragment(s). Lalisten estpasvide,maisn estpassuffisantepourassurerlasauvegarde de chaque fragment sur un candidat distinct. Dans ce cas, l application va tenter de regrouper certains fragments afin de réalisertoutdemêmelebackup. La liste est suffisante pour assurer la sauvegarde de chaque fragment sur un candidat distinct. C est la situation idéale. Nous supposerons que nous sommes en présence d un des deux derniers cas. Sur base de la liste de candidats, chaque fragment est empaqueté dans une méta-donnée de type FragmentStorage et est envoyé à l une des adresses de cette liste. A chaque étape, l application s assure que le fragment a bien étéreçuetstocképarlenoeudconcerné.unefoislesfragmentsenvoyéset stockés, DBS génère la méta-donnée BackupID contenant les informations dubackupetl insèredansladht. Si toutes ces opérations se sont déroulées avec succès, ou qu une solution est trouvée automatiquement par l application, l utilisateur est informé que le backup est réussi et dorénavant disponible. Récupération d un backup(figure 3.6) Récupérer un backup via DBS s avère encore plus simple que d en réaliser un: l utilisateur introduit le nom du backup qu il souhaite récupérer, ainsi que son identité. DBS tente alors de récupérer la BackupID correspondante dans la DHT. A ce stade, nous supposerons que cette information est retrouvée. Le contraire signifieraitsoitquelebackupn ajamaisétéréalisé,soitqu ilaétésupprimé préalablement,ouencorequeladhtn apasremplisonrôleenmaintenant cette information en permanence au sein du réseau. SurbasedelaBackupID,DBSestcapabledereconstruirelenomcanonique de chacune des méta-données de localisation situées dans la DHT. En effet, la BackupID contient le préfixe commun à l ensemble des fragments ainsi que le nombre de morceaux issus de la fragmentation. Pour chacun

53 3.2 Présentation des applications 51 FIG. 3.6 Diagramme: récupération d un backup de ces fragments présumés disponibles, DBS interroge la DHT afin de récupérer le FragmentID correspondant. Si ce dernier est disponible, nous possédons l information permettant de localiser le noeud propriétaire du fragment. L application évalue ensuite le nombre de fragments récupérables et informe l utilisateur de la capacité qu elle a de pouvoir récupérer la donnée. Enfin, l application contacte les noeuds concernés et demande le téléchargement des fragments. Si l information contenue dans la FragmentID est correcte et que le fragment est disponible, le FragmentStorage est alors téléchargé 5. Cette opération est répétée jusqu à ce que suffisamment de fragments aient été récupérés. Grâce à RSEC, l utilisateur peut reconstruire, la donnée initiale. Si un des fragments s avérait corrompu, il peut demander à DBS d en télécharger un supplémentaire. A ce stade, l utilisateur dispose du fichier initialement sauvegardé. Il peut décrypter/décompresser l éventuelle archive et accéder au contenu du (des) fichier(s). Dynamisme des noeuds Nous avons vu, dans la section 2.3 consacrée à l identification des données, que la présence des FragmentID contenant les informations de localisation d un fragment devait refléter la présence effective des candidats au sein du réseau. Afin de maintenir cette cohérence, nous avions indiqué que chaque noeud stockant un FragmentStorage devait, lors de sa connexion ou déconnexion, maintenir cette cohésion au niveau des FragmentID. DBS gère cette tolérance au dynamisme: Lors de la connexion d un noeud(figure 3.7), l application vérifie localement l ensemble des FragmentStorage précédemment mémorisés. Pour cha- cund entreeux,dbsconsulteladhtafinderechercherlabackupidcor- 5 C estlorsdecetteétapequ estnormalementvérifiéel intégritédechaquefragmentrécupéré. C est également lors de cette étape qu un challenge est établi entre DBS et chacun des candidats afin de s assurer que chaque fragment n est envoyé qu au propriétaire légitime du backup.

54 3.2 Présentation des applications 52 FIG. 3.7 Diagramme: connexion d un noeud FIG. 3.8 Diagramme: déconnexion d un noeud respondante. Si celle-ci n est pas disponible, soit le créateur du backup l a suppriméevolontairement,soitilyaeuuneerreurauniveaudeladht,ce quiàpriorinedevraitpasseproduire,auquelcaslebackupdevientinaccessible pour son auteur. Dans ce cas, DBS estime qu il n est plus nécessaire de stocker le FragmentStorage associé et le supprime du disque dur. Pour chacun des FragmentStorage restants, l application va vérifier la présence d un éventuel FragmentID correspondant. Une telle situation ne peut théoriquement pas se produire: en effet, les FragmentID sont censés être supprimés lors de la déconnexion du noeud(nous en reparlerons plus loin), à moins que cette déconnexion soit involontaire et/ou brutale. Chaque FragmentID trouvé est alors supprimé afin de retirer cette information erronée de la DHT. En fonction des FragmentStorage restants, de nouveaux FragmentID sont créés et envoyés dans la DHT avec l information de localisation à jour. Lors de la déconnexion d un noeud(figure 3.8), le travail effectué par DBS est presque similaire: pour chaque FragmentStorage stocké localement, l application vérifie la présence de la BackupID associée et conserve

55 3.2 Présentation des applications 53 ou supprime le FragmentStorage en fonction du résultat. Ensuite, puisque l utilisateur souhaite quitter le réseau, l application retire de la DHT toute référence aux différents fragments. Les FragmentID sont donc retirés un à un de la DHT, évitant ainsi de fournir une information erronée si l auteur du backup concerné souhaite récupérer ce dernier. Finalement, DBS fournit la possibilité de forcer la gestion de ce dynamisme afin de pouvoir nettoyer les éventuels fragments superflus et donc de libérer de l espace disque. Ceci pourrait être l objet d une tâche automatique effectuée à intervalle régulier.

56 CHAPITRE 4 DISCUSSIONS 4.1 Conclusion Partant du constat que les solutions traditionnelles pour effectuer un backup étaient relativement onéreuses et peu pratiques, nous avons exploré la faisabilité d un système de backup au sein d un environnement peer-topeer décentralisé. Nous avons choisi le middleware DKS pour mettre en place ce système. Sur base des objectifs d une application de backups, nous avons ensuite introduit divers mécanismes permettant de remplir ces objectifs: L objectif de transparence est assuré par le biais de conventions de nommage robustes. L utilisation de méta-données nous permet de séparer le contenu d une donnée de sa description, offrant à l application un outil idéal pour identifier de façon complexe mais performante les données au sein du réseau, tout en assurant à l utilisateur un moyen simple d identifier et d utiliser ses backups. La confidentialité et l intégrité des données sont garanties grâce à l utilisation d une architecture à clé secrète et à clé publique. Les données sont chiffrées et l utilisation de la signature numérique fournit un moyen simple de s assurer de l intégrité d une donnée. Enfin, l utilisation des méta-données facilite l utilisation d une telle architecture, en abstrayant les clés secrètes aux yeux des utilisateurs. Quant à la haute-disponibilité, celle-ci est garantie via l utilisation de codes correcteurs et vient compenser les lacunes des mécanismes traditionnels de réplication. L emploi des codes correcteurs nous permet de paramétrer finement le surcoût en terme d espace de stockage en fonction du degré de haute-disponibilité souhaité. Enfin, l étude des solutions existantes nous a conforté dans le choix de ces mécanismes. La réalisation d un prototype de système de backup nous a permis de mettre en pratique ces différents outils et vient confirmer la qualité de ces derniers, notre système proposant une haute-disponibilité de plusieurs neufs en moyenne rejoignant ainsi les résultats théoriques sur lesquels nous nous sommes basés.

57 4.2 Perspectives Perspectives Ilestévidentquenousn avonspaseuletempsnécessairepourexplorer toutes les pistes d une application de backup distribuée. Cependant, nous pensons avoir fourni une base à la fois performante, souple et suffisante pour aller plus loin. Cette section décrit quelques-unes des perspectives envisagées Contrôle de versions Une fonctionnalité souvent appréciée des systèmes de backup traditionnels consiste à permettre à l utilisateur des backups de type incrémental, c est-à-dire des backups dans lesquels seules les modifications par rapport à une ancienne version du même backup sont enregistrées. Cette façon de procéder permet bien souvent de gagner en espace disque, puisqu il n est pas nécessaire de sauvegarder à nouveau l ensemble des données, seuls les changements sont sauvés. Notre application permet, dans une certaine mesure, ce genre de backups. En effet, puisque nous disposons d un moyen simple de sauvegarder des données, rien ne nous empêche de sauvegarder successivement les patchs recensant les modifications effectuées depuis le précédent backup. Récupérer la version finale d un backup consiste alors à récupérer la version de base, suivie de l ensemble des patchs s y rapportant. De façon plus générale, nous pourrions envisager un système de versionning au sein de notre application. Lors de la sauvegarde de données, l application vérifierait automatiquement les modifications effectuées par rapport aux données déjà enregistrées. Ceci pourrait se faire facilement en associant à chaque fragment de données une valeur la représentant, par exemple, un checksum. Lors de l ajout de données, il suffit de consulterlecheckumdechaquefragmentetdelescompareravecleschecksums des nouveaux fragments. Il est alors possible de distinguer les nouveaux fragmentsdesanciens,etdeneprocéderàlasauvegardequepourlesnouveaux fragments. Cependant, notre mécanisme de fragmentation utilisant les codes correcteurs ne permet pas directement d effectuer ce travail. En effet, puisque le code correcteur calcule de la redondance pour chacun des fragments, la moindre modification dans un fragment(au niveau de la donnée initiale) entraîne des modifications dans l ensemble des fragments générés avec le code correcteur. Idéalement, il faudrait décomposer la donnée à sauvegarder en fragments, et appliquer le code correcteur localement à chaque fragment. Dès lors, il est possible de calculer un checksum cohérent avec chaque fragmentinitial,etdoncdevérifiersiunemiseàjourestnécessaireounon. En maintenant une liste(sous la forme d une arborescence, par exemple) des checkums et des différents fragments, il devrait être possible d obtenir une version antérieure d un backup, et donc de pouvoir utiliser notre application comme un système de versionning proche de ce qu offre CVS.

58 4.2 Perspectives Quota, confiance et monitoring Parmi les applications commerciales permettant la réalisation d un backup distribué, nombreuses sont celles qui proposent des mécanismes de quota, de confiance et de monitoring. Les paragraphes suivants détaillent les principes de base de ces mécanismes et proposent quelques perspectives pour inclure de tels mécanismes au sein de notre application. Mécanisme de quota Le principe de base d un système peer-to-peer est quechaquenoeudduréseaurépondàunservicedelamêmefaçonqu ilprofite de ce service auprès d autres noeuds. Dans le cadre d une application de backup, ceci consiste souvent à s assurer qu un utilisateur propose de l espace disque aux autres utilisateurs, de façon proportionnelle à l espace disque qu il utilise. Généralement, ceci permet d éviter qu un utilisateur ne cannibalise le réseau en profitant de l espace disque mis à sa disposition sans offrir de contrepartie. Si, dans un environnement classique(en entreprise, par exemple), ce genre de comportements est parfois souhaité- des machines spécifiques étant mises en place dans le but précis de fournir de l espace disque, sans contrepartie- ce n est pas le cas dans les applications grands publics, telles que celles qui sont proposées sur Internet. Dans de tels environnements, il est souhaitable que chaque utilisateur contribue à lahauteurdecequ ilconsomme.lemécanismedequotapermetdegarantir cette contribution, en s assurant qu un utilisateur ne puisse consommer davantage d espace disque s il ne contribue pas suffisamment. Dans le cadre de notre application, un tel mécanisme impliquerait que chaque noeud candidat, lors de la réception d une requête pour la sauvegarde d un fragment, consulte l information de quota afin d en déduire si l utilisateur est apte à pouvoir effectuer son backup sur ce noeud candidat. Concrètement, cette information de quota pourrait être centralisée(via la DHT) ou décentralisée.danscecas,laparitéseraitvérifiéeetcontrôléeauniveaudechaque couple de noeuds. Mécanisme de confiance De la même façon qu un mécanisme de quota permet de vérifier qu un utilisateur ne cannibalise pas le réseau, le mécanisme de confiance permet de vérifier qu un utilisateur fournit correctement les services qu il est censé fournir. Chaque utilisateur se voit attribuer un indice de confiance qui reflète sa capacité à répondre positivement aux requêtes qui lui sont attribuées: sauvegarde de données, récupération de données, etc. Imaginons qu un utilisateur souhaite récupérer un backup. Il contacte un certain nombre de noeuds afin de récupérer les différents fragments constituant son backup. Si l un des noeuds est absent ou répond négativement à la demande de récupération, l application peut en informer le système, lui indiquant alors que le noeud concerné n a pas répondu positivement à la requête. Ceci fera baisser son indice de confiance et avertira les autres utilisateurs que le noeud est potentiellement dangereux: si un fragment est sauvegardé sur ce noeud, il est possible(voire probable) que cenoeudnesoitpasprésentourefusederenvoyerlefragment.surbasede cette information, l utilisateur peut alors choisir d effectuer la sauvegarde d un fragment sur un autre noeud du réseau.

59 4.2 Perspectives 57 Contrairement au mécanisme de quota, nous ne pouvons pas envisager la mémorisation de l information de confiance de manière décentralisée: il n yapasoupeud intérêtàs informersoitmêmequ unautrenoeudn est pas digne de confiance pour des requêtes, puisqu au moment où nous prenonsconsciencedecefait,ilestdéjàtroptardpourladonnéeprécédemment sauvegardée. Par contre, il est intéressant de pouvoir communiquer cette information aux autres noeuds du réseau, et ceci peut se faire d une manière centralisée via la DHT. De façon générale, les mécanismes de quota et de confiance nécessitent de mémoriser des informations concernant les noeuds et de rendre ces informations accessibles à l ensemble des noeuds du réseau. Un système de monitoring répond à ces besoins. Monitoring Les deux mécanismes présentés ci-dessus consistent à surveiller le comportement des différents noeuds et à maintenir des informations reflétant ce comportement. Cette surveillance et cette collecte d informations peuvent être encapsulées dans un système de monitoring dont le rôleestderégulièrementsetenirinformédecequisepassedansleréseau et d ajuster les différents indicateurs(confiance et quota, par exemple) en conséquence. Un tel système centraliserait(virtuellement ou non) les informations ainsi récoltées et les mettrait à disposition des noeuds du réseau. Ceux-ci pourraient consulter les informations afin de réagir en conséquence:refuserunerequêtesiunnoeudnerespectepassonquota,mettre decotéunnoeudsicedernierestconsidérécommeétantdefaibleconfiance, surveiller la disponibilité moyenne des différents noeuds,... Le système de monitoring peut collecter les informations de façon active oupassive.dansunsystèmeactif,c estlesystèmedemonitoringquiva questionner régulièrement les différents noeuds du réseau afin de récupérer leurs récentes observations à propos des autres noeuds. Dans un système passif, ce sont les noeuds qui vont directement avertir le système de monitoring des modifications à effectuer dans les indicateurs de confiance etdequota. Quoiqu il en soit, dans chacune des deux approches, il est nécessaire de pouvoir s assurer de la véracité de l information. Ceci peut se faire grâce à des algorithmes fonctionnant sur le principe des réseaux neuronaux, en calculant le résultat d un indicateur sur base des propositions des autres noeuds pondérées en fonction de leur propre indice de confiance. Ainsi, si un noeud fournit une information au système de monitoring à propos d un autre noeud, ce système de monitoring va mettre en relation cette nouvelle information avec les informations reçues auparavant. Cette mise en relation des informations permet au monitoring d attribuer un poids à la nouvelle information: si celle-ci est contradictoire avec la situation connue, son poids sera faible et il faudra d autres informations similaires pour qu une décision soit prise. Si la nouvelle information vient confirmer les précédentes, le monitoring peut agir en conséquence en supposant que ces informations sont vraies, car relayées par plusieurs noeuds.

60 4.2 Perspectives 58 La réalisation d une telle application de monitoring constitue en ellemême un travail conséquent et intéressant: il est impératif que le monitoring ne soit pas synonyme de consommation au sein du réseau, qu il soit apteàdétecteretrejeterlesfauxpositifsainsiquelesfauxnégatifsetqu il soit suffisamment fiable et pratique que pour justifier son utilisation dans des applications de plus haut niveau telles que les applications de backups.

61 4.3 Remerciements Remerciements Je tiens à remercier toutes les personnes sans qui ce mémoire n aurait pu aboutir. Tout particulièrement, LUC ONANA ALIMA pour les nombreuses heures qu il a consacrées à m encadrer tout au long de l année. Ses conseils et ses connaissances ont été une source d inspiration inestimable. Je remercie également STEFAN BEAUPORT pour l infrastructure m ayant permis de tester mes logiciels ainsi que ses connaissances du DKS, SYLVAIN DEGRANDSART pour ses conseils avisés dans l étude des différents mécanismesetperrinefournierpourletempspasséàlireetàcorrigerce mémoire.

62 Bibliographie [1] John Byers, Michael Luby, Michael Mitzenmacher, and Ashutosh Rege. A Digital Fountain Approach to Reliable Distribution of Bulk Data [2] John W. Byers, Michael Luby, and Michael Mitzenmacher. Accessing Multiple Mirror Sites in Parallel: Using Tornado Codes to Speed Up Downloads. [3]L.P.CoxandB.D.Noble. Pastice:Makingbackupcheapandeasy [4]GladedotGnome. Glade-aUserInterfaceDesignerforGTK+and GNOME [5] Wikipedia En. Reed-Solomon Error Correction [6] Wikipedia En. Tornado Code [7] Jean-Pierre Escofier. Toute l algèbre du premier cycle [8]KuroseJamesF.andRossKeithW. ComputerNetworking:ATop- Down Approach Featuring the Internet. Pearson Benjamin Cummings, [9] Wikipedia Fr. Code correcteur [10] Wikipedia Fr. Sauvegarde [11] Ali Ghodsi. Distributed k-ary System: Algorithms for Distributed Hash Tables. PhD dissertation, KTH Royal Institute of Technology, Stockholm, Sweden, December [12] Steven D. Gribble, Eric A. Brewer, Joseph M. Hellerstein, and David Culler. Scalable, Distributed Data Structures for Internet Service Construction [13] Weatherspoon H. and Kubiatowicz J. D. Erasure Coding vs. Replication: A quantitative comparison [14] Elliotte Rusty Harold. XML Bible [15]PingJi,ZihuiGe,JimKurose,andDonTowsley. AComparisonof Hard-state and Soft-state Signaling Protocols. University of Massachusetts at Amherst, [16]HakonWiumLieandBertBos.CascadingStyleSheets:Designingfor the Web, 3rd Edition [17] Mark Lillibridge, Sameh Elnikety, Andrew Birrell, and Mike Burrows. A Cooperative Internet Backup Scheme

63 BIBLIOGRAPHIE 61 [18] Adams Lloyd and Steve Lloyd. Understanding Public-Key Infrastructure: Concepts, Standards, and Deployment Considerations [19] Miachel Luby, Michael Mitzenmacher, Amin Shokrollahi, and Daniel Spielman. Efficient Erasure Correcting Codes [20] Michael Luby, Michael Mitzenmacher, Amin Shokrollahi, Daniel Spielman, and Volker Stemann. Pratical Loss-Resilient Codes. July [21] KTH/Royal Institue of Technology and Swedish Institue of Computer Science(SICS). Distributed K-ary System(DKS) [22] L. Onana, S. El-Ansary, P. Brand, and S. Haridi. Dks(n,k,f) a family of low-communication, scalable and fault-tolerant infrastructures for p2p applications. In The 3rd International workshop on Global and P2P Computing on Large Scale Distributed Systems(CCGRID 2003), [23] J. S. Plank. A tutorial on Reed-Solomon coding for fault-tolerance in RAID-like systems [24] Irving Reed and Gustave Solomon. Polynomial codes over certain finite fields [25] Claude Shannon. Communication Theory of Secrecy System [26] Emil Sit, Josh Cates, and Russ Cox. A DHT-based Backup System [27] GTK+ Web Site. The GIMP Toolkit [28] Python Web Site. Python Programming Language [29] W3C Web Site. Metadata [30] Birgir Stefansson and Antonios Thodis. MyriadStore: A Peer-to-Peer Backup System

64 ANNEXE A CD-ROM A.1 Introduction Le lecteur trouvera en annexe de ce document un CD-Rom contenant l ensemble des outils nécessaires afin de tester notre prototype. La section suivante décrit le contenu du CD-Rom et explique, dans les grandes lignes, comment utiliser les différents outils. Davantage d informations sont disponibles dans les fichiers README situés sur le CD-Rom. A.2 Contenu Le CD-Rom contient quatre répertoires à sa racine: DBS Ce répertoire regroupe les différents éléments de l application DistributedBackupSystem.EcritenJava,sacompilationsefaitparlebiais du script compile.sh, et son exécution via execute.sh. La compilation nécessite le kit de développement Java, alors que l exécution nécessite la machine virtuelle Java. Ces deux outils sont disponibles sur le CD-Rom. RSEC Le répertoire RSEC contient l application Reed-Solomon Erasure- Code. Cette application nécessite Python ainsi que la librairie graphique GTK liée grâce à PyGTK. Un installeur all-in-one est disponible pour les utilisateurs sous Windows. Les utilisateurs sous Linux trouveront l interpréteur Python et la librairie PyGTK sur le CD-Rom. Java Différents outils pour exécuter et compiler des applications Java sont repris dans ce répertoire. Les machines virtuelles et kit de développementdejava6sontinclussurcecd-rom,àlafoispourwindowset pour Linux. Python Les interpréteurs Windows et Linux sont repris dans ce répertoire. De même, un installeur all-in-one pour Windows permet d installer l ensemble des outils nécessaires(python, libglade et GTK). Les utilisateurs sous Linux trouveront pygtk également. La bibliothèque graphique GTK2 n est pas fournie, celle-ci dépend en partie de votre distribution, il est fort probable qu elle soit déjà installée sur votre machine.

65 A.3 Utilisation 63 A.3 Utilisation Distributed Backup System Une fois le kit de développement Java installé, DBS peut être compilé en appelant le script compile.sh. L exécution se fait par un simple appel à execute.sh. Pour effectuer une compilation suivie d une exécution et du nettoyage automatique des fichiers compilés après l exécution, le lecteur utilisera le script Start.sh. Reed-Solomon Erasure Code L utilisation de l outil de fragmentation RSEC se fait par un simple appel au script RSEC.py via l interpréteur Python. Pour ce faire, le lecteur est invité à entrer la ligne de commande suivante dans le répertoire de l application: python RSEC.py Un double-clic sur le script RSEC.py suffit généralement au lancement de l application.