Table des matières. 1 Introduction 3

Transcription

1 Table des matières 1 Introduction 3 2 Etat de l art Qu est ce que la Grille? Quelques exemples de grilles de calcul Systèmes de fichiers distribués pour les Grilles Internet Backplane Protocol Modélisation Modélisation du réseau Les Threads, ou modèle de communication multiport Méthode de calcul dynamique des vitesses réelles des liens Distribution des fichiers Popularité d un fichier Fragmentation et répartition des fichiers Duplication des fichiers Les tâches Politique d attribution des taches Temps d exécution d une tache Simulation Paramètre du simulateur Influence de la fragmentation, des threads et de la taille de fichiers Test d efficacité de la fragmentation et de l usage de threads Test sur la variation des tailles des fichiers Test de l efficacité de la duplication Influence du trafic externe sur l expérimentation Test d efficacité de diverses politiques de choix de duplication

2 2 TABLE DES MATIÈRES Test de divers politiques de choix du meilleur serveur Ajout de la notion de tache Impact du placement des taches Gestion de l espace disque par LRU et répartition de charge par le placement de tache Conclusion 33 Bibliographie 35

3 Chapitre 1 Introduction Les expérimentations ou les simulations dans des domaines tel que la physique nucléaire, la génomique ou l astronomie sont de plus en plus gourmandes en puissance de calcul et génèrent de très grandes masses de données à partager par une communauté. Par exemple, à partir de 2006, le CERN génèrera plusieurs Petabytes de données par an. Plusieurs centaines de physiciens dispersés de par le monde accéderont à une partie de ces données pour exécuter de nombreux calculs. Les Grilles de calcul permettront de répondre à ces besoins en découpant les traitements en calculs dispersés sur de nombreux sites reliés entre eux par de puissants réseaux. Le domaine de la Grille est devenu extrêmement actif et porteur car il existe actuellement une énorme demande de capacité de calcul. De nombreux projets tels que GriPhyN [6], DataGrid [2] ont vu le jour, et une multitude d infrastructures ont été développées (DIET [10] [11], Globus citeglobus, Datafarm[19], IBP [16]) Il reste cependant encore de nombreux problèmes à résoudre, comme des problèmes d ordonnancement, de partage et d accès équitable des ressources, de sécurité et aussi de gestion des données. Répartir efficacement les traitements sur différents noeuds de façon à minimiser les temps de calculs totaux et les temps de téléchargement des données est un problème complexe et critique [18]. Il est nécessaire de trouver des moyens de stocker et de rendre rapidement accessible de grandes masses de données souvent accédées. Une solution simple et mauvaise consiste à conserver les données à la source, qui risque de devenir rapidement le goulot d étranglement suite à des téléchargements intempestifs de fichiers massifs et populaires. Les données doivent être distribuées pour éviter ces goulots d étranglement. Par exemple, dans DataGrid[2], les données sont réparties sur des tiers : des serveurs accessibles via GridFtp[17], une version distribuée de ftp. Trouver une distribution optimale est un problème insoluble. Pour illustrer la complexité du placement des données, considérons un cas simple où il y a seulement un serveur et deux clients. Soit un seul serveur contenant fichiers correspondants chacun à une unique tache à répartir sur deux clients identiques (même capacité de calcul, même vitesse de liens). Il suffit que le temps de calcul des taches ou que la taille des fichiers diffèrent pour être ramené au problème 2-PARTITION (e) qui montre que la répartition de n entiers en deux ensembles dont la somme est identique est un problème NP-complet. Se ramener à un autre cas simple peut permettre de démontrer la NP-complétude : Si on dispose d un unique serveur contenant "f" fichiers et de deux noeuds de calcul différents (capacité de calcul et vitesse de liens 3

4 ### %%$$$ ''&& ,,, //.. 4 CHAPITRE 1. INTRODUCTION pouvant ne pas être identique pour chaque noeud), [12] [13] démontre la NP-complétude dans le cas de figure où fichiers de tailles identiques peuvent être requis pour l exécution de plusieurs taches d une durée identique (c). Figure 1.1 Autres résultats de complexité pour le problème d ordonnancement de taches partageant des fichiers... (a) Polynomial (tourniquet) """ """!!!! (b) Polynomial [9]... (c) NP-complet [11, 12] *** *** (()) (()) (d) Polynomial [14] (e) NP-complet (2-PARTITION) (f) problème ouvert Ainsi le problème de la distribution dans un cadre statique (réseau fixé) est déjà un problème difficile. Qui plus est, la Grille est utilisée dans un environnement dynamique (débit réseau variable, accès aux données aléatoire,...). La problématique qui se pose est de trouver quels sont les politiques de placement et de distribution de données qui soient efficaces sur un système de stockage distribué, comme IBP [16]. L objectif de ce stage est d étudier différentes stratégies de distributions utilisées sur ce type d architecture, comme la réplication et la fragmentation des données, pour améliorer les traitements et les accès aux données. Il me faut donc estimer l efficacité des différentes stratégies de distribution sur le temps de téléchargement de fichiers au travers du réseau. Le problème peut se résumer ainsi : on a 0 taches indépendantes à exécuter sur 1 machines. L exécution de chaque tache nécessite le téléchargement selon leur popularité de certains des fichiers disponibles qui sont répartis sur 2 dépôts de données de tailles variables. Notre objectif consiste à estimer la meilleure stratégie pour minimiser le temps total de récupération et de traitement. Pour étudier ces différentes stratégies, plusieurs approches peuvent être imaginées : L expérimentation en grandeur réelle L analyse théorique La simulation L expérimentation en grandeur nature n est pas réellement envisageable, car il n est pas possible de déployer des expériences à grande échelle faute d accès global à la grille. D autre part, il n est pas possible non plus de récupérer des données d utilisation réelle de la grille car celles ci sont toujours dans une phase expérimentale et pas en production. L utilisation des outils de l analyse théorique (basée par exemple sur des modèles stochastiques) nécessite de nous ramener à des modèles mathématiques basés sur des hypothèses probabilistes fortes qui ne correspondent pas forcément à la réalité. La simulation à l avantage d être plus souple bien qu elle nécessite plus de calculs. J ai donc opté pour la simulation.

5 Je vais maintenant définir et présenter différentes infrastructures de grilles et de gestions de données distribuées, et en particulier IBP [16]. Puis je détaillerai un modèle de simulation suivant un schéma de réseau clients-serveurs, un schéma Peer-to-Peer (où les clients sont aussi des serveurs qui mettent à disposition des autres clients leurs fichiers), et enfin un schéma Peer-to-Peer intégrant l affectation et le calcul des taches. J énoncerai les techniques utilisées pour simuler la notion de popularité des fichiers, le fonctionnement du réseau, et le temps d exécution des taches. Dans la partie suivante, je présenterai les résultats observés grâce à l implémentation de ces schémas dans un simulateur. J illustrerai par diverses expériences que la réplication des fichiers souvent accédés, ou que la fragmentation et la répartition des données au travers du réseau peuvent s avérer des méthodes efficace pour réduire le temps de téléchargement. Enfin, après avoir montré l inutilité d une politique de placement des taches sur les noeuds d un système Peer-to-Peer, je conclurai en évoquant de futurs implémentations possibles. 5

6 6 CHAPITRE 1. INTRODUCTION

7 Chapitre 2 Etat de l art Nous allons dans un premier temps introduire le concept des grilles de calcul et en présenter quelques exemples de projets de réalisation, puis nous développerons plusieurs approches possibles pour le stockage distribué des données générées par les Grilles, et particulièrement la solution la plus aboutie : IBP. 2.1 Qu est ce que la Grille? La grille de calcul est en devenir. Elle promet d optimiser des infrastructures et de gérer globalement l accès et le partage de ressources, de données, et d applications à grande échelle. Le principe en est de permettre le partage de moyens de calculs, de stockage et d applicatifs à travers un réseau de communication. Il peut-être imaginé à l échelle mondiale d Internet ou plus modestement à l échelle d une entreprise qui, en interne, cherche à optimiser l utilisation de ses moyens informatiques. La grille banalise l accès aux ressources disponibles en incluant non seulement les ressources classiques, processeurs, mémoire et stockage, mais aussi les applications. Elle facilite le partage de ces ressources et la collaboration au sein d organisations virtuelles dans un environnement distribué, entre groupes de travail et entreprises indépendantes. Il rend transparent l hétérogénéité des composants et la complexité de l infrastructure : systèmes d exploitation et localisations variées, réseaux complexes, politiques de sécurité variables, etc. Loin d être antinomique ou concurrente, la grille valorise et fédère l ensemble des technologies existantes dans ce domaine, telles que le clustering ou le "pair à pair". Des briques de base se posent sur l infrastructure existante en apportant des modules formant le système d exploitation de la grille. Pour citer quelques exemples, des modules nécessaires à la gestion d une grille sont, schématiquement, un annuaire dynamique de ressources, un système de gestion de données distribuées, un système d exécution et de suivi d applications, et bien entendu des services de sécurité. Les besoins en calcul intensif et de manipulation de très grandes quantités d informations rendent nécessaires l utilisation de moyens de traitement de l information de plus en plus performants. Le calcul sur la grille apporte une solution dont le rapport performance/coût est extrêmement avantageux, en comparaison avec l achat massif de supercalculateurs par exemple. Les expériences menées dans le cadre du projet EuroGRID indiquent que les grands 7

8 8 CHAPITRE 2. ETAT DE L ART centres de calcul sont très actifs dans ce domaine et poussent les Grilles vers la production. 2.2 Quelques exemples de grilles de calcul Le projet DataGrid [2] est un projet européen visant à exploiter des grilles de données pour le stockage et le traitement distribué de grandes quantités de données issues d expériences sur des accélérateurs de particules. Les expérimentations du projet DataGrid s appuient sur le middleware Globus qui a été développé par des équipes de recherche aux Etats-Unis (Argonne Nationale Laboratory, Université de Californie Sud...). Le projet Globus [5] est certainement aujourd hui le leader dans les middlewares dédiés aux grilles de calculs. Globus propose une boite à outils où les programmeurs et développeurs d application peuvent choisir les services spécifiques répondant au mieux à leurs besoins. Le middleware a été au coeur de nombreux développements et de recherche sur différentes grilles de calcul et applications. Le projet GriPhyN [6] (Grid Physics Network) : Ce projet vise à développer des technologies basées sur les grilles de calcul dans le cadre de projets scientifiques utilisant de très grandes bases de données distribuées (de l ordre du Petabyte). Le projet TeraGrid [7] : Projet américain visant à construire et déployer la plus grande et plus rapide infrastructure distribuée pour la recherche scientifique. A terme, les quatre sites TeraGrid fourniront grâce à des clusters Linux une puissance de calcul de 13.6 teraflops. Le projet DataTAG [3] : projet européen visant à créer un banc d essai à large échelle des grilles de calcul. Pour ce faire, le projet se concentre sur deux points : les techniques avancées concernant les réseaux gigabits et l interopérabilité entre grilles de calcul. Le projet CrossGrid [1] : Ce projet européen devra développer, implémenter et exploiter de nouveaux composants pour les grilles de calcul permettant de réaliser des simulations d interventions chirurgicales, des systèmes d aide à la décision de groupe, des systèmes de prévision de la pollution de l air. Les Grilles sont basées sur un concept simple mais dont la mise en oeuvre reste complexe. Il reste encore à résoudre divers problèmes théoriques et techniques. De nombreux travaux publiés autour des grilles se focalisent principalement sur les calculs (scheduling des taches...) et assez peu sur les données (citons par exemple la grille E-Toile [4] qui ne gère pas du tout les données.) 2.3 Systèmes de fichiers distribués pour les Grilles Il reste à traiter de nombreuses problématiques liées aux données sur la grille, nous allons nous intéresser principalement aux développements technologiques liés aux transferts de fichiers. GridFTP [17] ou Kangaroo [20] permettent d accéder à des fichiers distribués sur des noeuds. GridFTP est un composant de Globus [5] permet d optimiser la bande passante par l usage de téléchargements parallèles adaptatifs (notons que [15] a montré les limites de l efficacité de ce système). Kangaroo utilise un système de cache pour assurer la disponibilité

9 2.4. INTERNET BACKPLANE PROTOCOL 9 des données et une tolérance aux pannes, au détriment de la cohérence des données. Data- Farm [19] reprend ces deux techniques d optimisation et conserve en plus un historique des calculs soumis afin de pouvoir régénérer les données perdues si la réplication ne suffit pas à assurer la tolérance aux pannes. Datafarm souffre cependant de n être pour l instant qu un prototype, à la différence de sa principale source d inspiration : IBP [16] [8] 2.4 Internet Backplane Protocol IBP est un composant du middleware qui permet d administrer et d utiliser des stockages distribués. Il a été conçu pour supporter l optimisation les transferts de données dans le cadre des systèmes et des applications distribuées ou de l administration des données sur la grille. IBP proposera bientôt 50 TeraBytes d espace de stockage temporaire répartis sur plusieurs centaines de sites dispersés dans le monde entier. Les dépôts de données IBP gèrent des allocations d espace temporaire sur disque ou en mémoire qui ont une sémantique située entre les fichiers conventionnels et les buffers. Structure de IBP Les applications ou les utilisateurs peuvent directement accéder aux ressources du réseau, passant par un client IBP (LORS) qui s appuie sur le L-Bone et les Ex-nodes. Figure 2.1 Structure de IBP Le L-Bone est un index centralisé et répliqué qui référence l ensemble des adresses de tous les dépôts IBP, et leurs paramètres (taille et nature des dépôts, limite de durée de stockage...). Celui-ci permet de découvrir quels sont les dépôts les plus proches physiquement du client ou (grâce à l usage de NWS) les plus rapidement accessibles. Ainsi le client peut récupérer en priorité la plus accessible des copies de ses données. Les données dans IBP Le Ex-node est une structure de données. On peut le voir comme une métaphore du I- node de linux, à la différence que ce n est pas un agrégat de block disques où est stocké

10 10 CHAPITRE 2. ETAT DE L ART physiquement un fichier, mais un agrégat d espace de stockage alloué sur divers dépôts IBP. Il se présente comme un index en XML regroupant les adresses IBP de tous les fragments de toutes les copies d un fichier. Il n existe aucun index permettant de faire une recherche sur une donnée présente sur un noeud du réseau. D un certain coté, cet anonymat des données peut permettre d en assurer la sécurité, car sur IBP, seul le propriétaire d un ex-node peut retrouver ou déplacer le fichier correspondant. Figure 2.2 Le ex-node gère la réplication et la fragmentation et assure une certaine résistance aux pannes Sur IBP, les données ont une durée de vie limitée, fixée au moment où elles sont insérées dans le réseau. La pérennité des données est uniquement assurée par la réplication et la fragmentation. Un fichier répliqué, fragmenté et réparti à travers tout le globe à plus de chance d être disponible (résistance du système aux pannes) et rapidement téléchargeable par le client. Figure 2.3 Téléchargement grâce à LORS d un fichier dupliqué, fragmenté et dispersé sur plusieurs dépôts LORS est un client IBP avec interface graphique. Il permet d interroger le L-bone, et d établir des connections cryptées et multi-threadées.

11 Chapitre 3 Modélisation Dans la grille, le réseau interconnecte entre elle de façon transparente les ressources de calcul où sont exécutés les traitements découpés en tâches, et les ressources de stockage où sont distribuées les données. Figure 3.1 Représentation générique du réseau 3.1 Modélisation du réseau Les réseaux sont hautement entropiques. Il existe de nombreux modèles de simulation, mais aucun n est capable de prendre en compte tous les paramètres pouvant avoir une influence sur le réseau. Celui-ci fluctue en permanence et dépend entre autre des politiques locales de routage. Pour ma simulation, nous avons implémenté plusieurs schéma d exploitation de la grille (clients-serveurs, Peer-to-Peer, Peer-to-Peer avec gestion des taches). Afin de simuler l influence parasitaire des fluctuations du réseau, chaque expérimentation est répétée plusieurs centaines de fois, en faisant à chaque fois varier aléatoirement un certain nombre de paramètres. Les résultats qui vont être présentés sont les moyennes de ces nombreuses expérimentations. En opérant ce "lissage" de nos courbes, nous montrerons par la suite que nous obtenons des résultats qui restent significatifs même dans un réseau fortement entropique, modulo une certaine marge d erreur raisonnable. L objectif n étant pas de 11

12 12 CHAPITRE 3. MODÉLISATION prédire les temps d accès aux données, mais plutôt d étudier le comportement global des différentes stratégies d accès aux données. Figure 3.2 Schéma 1 : approche client-serveur On considère que 1 clients cherchent à télécharger certains des fichiers de taille, répartis aléatoirement sur 2 sources disposant chacun d un espace de stockage de taille. A chaque lien virtuel reliant chaque client à chaque serveur est attribué une vitesse maximum 0 qui représente la vitesse maximum de téléchargement à travers le réseau entre le client et le serveur. Les débits des équipements réseaux des clients et des serveurs (modem, carte réseau, switch...) limitent aussi les vitesses de téléchargement. Ajouter une dose d aléatoire dans le choix de ces limites permet de simuler l influence d un possible trafic réseau parasitaire au niveau du client ou du serveur Les Threads, ou modèle de communication multiport. Chaque client peut partager sa bande passante en connections à des serveurs différents simultanément ou télécharger en parallèle plusieurs fichiers sur différents serveurs. Un téléchargement non threadé correspond à. Un autre mode permet aux clients d utiliser un nombre maximal de thread simultanément, soit 2. Les contraintes imposées par le réseau sont les suivantes : les vitesses réelles de téléchargement doivent donc rester inférieures ou égales aux vitesses maximales des liens la somme des vitesses réelles de tous les téléchargements simultanés sur un unique serveur doit rester inférieur ou égal à la limite de débit du serveur la somme des vitesses réelles de tous les téléchargements simultanés par un unique

13 3.1. MODÉLISATION DU RÉSEAU 13 client doit rester inférieur ou égal à la limite de débit du client. La principale difficulté lors de la simulation du réseau est d estimer les débits effectifs des différents téléchargements. Ces débits sont le résultat d arbitrage des différents composants du réseau qui suivent généralement une politique locale. Une vision optimiste du réseau considère que celui ci va maximiser l utilisation des ressources et ceci avec une certaine équité. Maximiser les vitesses réelles selon ces paramètres revient donc à résoudre un système linéaire d inéquations par la méthode du Simplex, avec la somme des vitesses réelles comme fonction objectif à optimiser. Cependant, l équité peut ne pas être assurée aussi la méthode que j ai implémentée est basée sur une série d optimisation qui s en inspire, à deux grandes différences près : Il existe de nombreuses politiques de routage possible implémentées dans le réseau, cependant la plus répandue (et la plus simple) est le tourniquet dans lequel le routage proportionnel à la taille du flux de données traversé par le routeur. Aussi ma méthode d estimation cherche à optimiser la somme des vitesses réelles mais aussi à conserver (favoriser) cette notion de proportionnalité : Par exemple, dans le cas ou on simule un réseau dont les vitesses des liens sont toutes limitées à 100, ma méthode donne une estimation pour l utilisation des débits avec des vitesses comprises entre 20 et 90, alors que le simplexe trouvera une solution optimale avec un lien à 100 mais en réduisant trois des liens à 0. Comme la fonction objectif ne permet pas de quantifier efficacement cette notion d équité, j ai donc du adapter la méthode du simplexe. La méthode proportionnelle est plus simple, donc plus rapide à calculer mais bien sur avec une perte possible dans la maximisation de l utilisation des ressources. Dans l exemple précédent, la méthode du simplex est dans le pire des cas plus efficace de 15 à 20% en terme de débit global par rapport à ma méthode. Cependant ces pertes peuvent être considérées comme une forme de "bruit" du réseau et être compensées par la marge d erreur que nous allons prendre en compte pour simuler l entropie du réseau Méthode de calcul dynamique des vitesses réelles des liens La simulation du réseau se déroule de la manière suivante : A chaque thread de chaque client est attribué un fichier et un serveur où le télécharger Les vitesses réelles des liens inactifs 1 sont mises à 0. Les vitesses réelles des liens actifs sont initialisées à leur vitesse maximum. Pour chaque client, les vitesses réelles des liens actifs sont proportionnellement réduites afin que leur somme ne dépasse pas la limite de débit. On recommence pour les serveurs. Bien que les vitesses des liens soient toujours bornées par les limites de débits des clients, celles-ci peuvent ne plus être optimales de par la perte de vitesse induite par les limites de débits des serveurs. On essaye d optimiser nos vitesses en tentant de compenser les pertes de vitesses de chaque lien sur les liens actifs des autres clients, tout en respectant les limites de débits des clients et des serveurs. On calcule quel sera le prochain lien qui sera inactivé, i.e. on trouve la date de la fin du prochain téléchargement. 1 chaque lien reliant un serveur avec un client n ayant aucun téléchargement en cours

14 14 CHAPITRE 3. MODÉLISATION On calcule et on stocke l état d avancement des téléchargements de chaque thread à ce moment. Pour chaque client, on cherche à activer les threads inactifs en essayant de leur associer des fichiers à télécharger. On recommence jusqu à la récupération complète de tous les fichiers par tous les clients. Cette expérience de récupération est recommencée plusieurs centaines de fois. 3.2 Distribution des fichiers. Le nombre de fichiers, leurs tailles et la taille des dépôts sont paramétrables. Nous allons en autre étudier par la suite l impact de la duplication, de la fragmentation et de l écart de tailles de fichiers sur les temps de récupération. Mes expérimentations montreront que les variations de tailles de fichiers n ont que très peu d influence sur les performances. Comme l usage de la duplication peut être limité par l espace disque, il nous faudra aussi mettre en place une politique de gestion de l espace Popularité d un fichier A chaque client est attribué la liste des fichiers qui lui reste à télécharger. Dans le cadre d applications collaboratives, certaines données sont plus populaires, donc accédés plus que d autres. Ainsi, chaque fichier possède une probabilité qu un client ait besoin de le télécharger. Pour simuler le fait que sur un réseau la majorité des accès sont réalisés sur un petit nombre de fichiers populaires, j utilise une pseudo-loi géométrique de la forme : Où, la popularité du 1er fichier peut-être soit fixée, est calculée par la formule : 0 de façon à ce que le dernier fichier ait une probabilité de 10% : Ainsi le nombre de fichiers accédés augmente avec, le nombre de fichiers (c est le mode que l on utilisera par la suite) Fragmentation et répartition des fichiers Une distribution possible des fichiers (proposée par IBP) consiste à les fragmenter et à les disperser sur l ensemble des serveurs. L intérêt de cette fragmentation est de répartir la charge. Initialement, chaque fichier est disponible sur un unique serveur, choisi aléatoirement. Chaque fichier est découpé en 2 fichiers de taille! #"$ &%(' "). Le premier fragment de chaque fichier est placé aléatoirement sur un serveur. Le 2ème fragment est placé sur le serveur suivant, le 3ème sur le suivant, etc... quand on arrive au dernier serveur, on continue avec le 1er, puis le second, jusqu à avoir placé un fragment par serveur.

15 3.2. DISTRIBUTION DES FICHIERS. 15 Figure 3.3 Schéma 2 : approche Peer-to-Peer En résumé, la fragmentation revient à posséder 2 fois plus de fichiers 2 fois plus petits, et répartis de façon (pseudo)homogène Duplication des fichiers En plus d ajouter une certaine résistance aux pannes, la duplication des fichiers peut permettre de disposer de plusieurs sources de téléchargement et ainsi d éviter l apparition de goulets d étranglements. Le client peut ainsi choisir parmi plusieurs serveurs disposant d une même donnée le plus rapide ou le moins engorgé. Politique de choix de duplication La popularité d un fichier indique le nombre de fois que celui-ci ou l une de ses copies est accédé. Lorsque cette popularité arrive à un certain seuil paramétrable, elle est remise à 0, et le fichier est dupliqué. si ce seuil vaut, un fichier est dupliqué à chaque fois que un tiers des clients le téléchargent. Avec cette politique, un fichier est donc dupliqué au maximum 3 fois. Si ce seuil est fixé à 1, à chaque téléchargement, une copie supplémentaire du fichier est disponible sur un serveur de plus. Ce dernier modèle de duplication s obtient naturellement quand les noeuds de la grille sont à la fois clients et serveurs, Politique de choix de placement du duplicat Plusieurs méthodes de placement du duplicat peuvent être imaginées.

16 16 CHAPITRE 3. MODÉLISATION On peut choisir aléatoirement un serveur ne disposant pas déjà de ce fichier mais possédant suffisamment de place pour stocker le fichier. Ou dans le cas du schéma Peer-to-Peer présenté, le fichier récupéré est considéré comme dupliqué sur le serveur possédant le même numéro que le client. Comme la liste des fichiers à récupérer pour chaque client est générée aléatoirement, le placement l est aussi, ce qui nous ramène au cas précédent. On peut aussi imaginer dans le futur tester d autres heuristiques d évaluation du meilleur serveur : possiblement selon sa charge, la somme de la popularité de ses fichiers, le nombre et la taille de ses fichiers en cours de téléchargement, son débit... Politique de choix parmi les serveurs disposant d un même fichier Mes premières expérimentations semblent indiquer que le choix du serveur disposant du fichier recherché a des conséquences critiques sur l efficacité de la réplication. Plusieurs politiques ont été évaluées : Le serveur possédant le minimum de fichiers populaires est choisi en priorité. Celle-ci est calculée ainsi : 1 # où représente chaque fichier présent sur chaque serveur j disposant du fichier que le client cherche à récupérer. On peut noter que si le seuil de réplication vaut 1 (cas du schéma P2P),, dans ce cas de figure, on choisira simplement en priorité le serveur possédant le moins de fichier. On peut aussi donner la priorité au serveur avec lequel le client a le plus de chance de posséder une connexion rapide, en fonction de la vitesse du lien entre le serveur "j" disposant du fichier que le client "i" cherche à récupérer, et la limite de débit du serveur "j", selon la formule : Dans le futur, on peut imaginer prendre aussi en compte le nombre de threads actifs du client "i" et du serveur "j", et/ou proposer une politique de choix hybride, voir dynamiquement modulable. Politique de gestion de l espace La réplication a un coût en espace disque. Pour prendre en compte ce paramètre, j ai implémenté un système de gestion de l espace LRU (least recently used) : Chaque fois qu un réplicat est placé sur un serveur, celui-ci se voit attribué un indice indiquant son ordre d arrivée : cet indice vaut 1 quand le fichier est le dernier à avoir été placé sur ce serveur, et il est ensuite incrémenté à chaque fois qu un nouveau fichier y est ajouté. Lorsqu un fichier doit être copié sur un serveur ne disposant pas de la place nécessaire, on supprime les fichiers possédant les indices les plus élevés en priorité, jusqu à avoir fait assez de place. Afin d assurer la pérennité des données, les fichiers originaux ne sont jamais effacés. On considère qu un espace de stockage permanent leur à été attribué, indépendant de l espace géré par LRU. La taille de l espace de stockage géré par LRU est fixée aléatoirement entre 0 et une taille calculée de façon à pouvoir contenir tous les fichiers. Je me suis assuré empiriquement d avoir statistiquement des expérimentations où la place disque est critique, tout en évitant

17 3.3. LES TÂCHES 17 les cas de figures où certains fichiers ne pourront jamais être téléchargés par manque de place. 3.3 Les tâches Le troisième schéma d expérimentation considéré reprend la structure du schéma Peerto-Peer et y ajoute la notion de tâches, caractéristique des grilles. Une tâche exécute sur un client des calculs portant sur un certain nombre de données qui doivent être disponibles sur le client. On génère un nombre 0 paramétrable de tâches et on leur attribue aléatoirement (selon une loi pseudo-géométrique, comme précédemment) une liste de fichiers à télécharger. Dans le cadre de ce stage, je me contenterai de considérer uniquement des taches indépendantes les unes par rapport aux autres. Figure 3.4 Schéma 3 : approche Peer-to-Peer avec notion de taches Politique d attribution des taches J ai testé plusieurs politiques d attribution d un client à une tache : Lorsqu un client est disponible, on lui attribue la prochaine tache non encore affectée dans l ordre des numéros de taches. On attribue une tache à un client en cherchant à limiter au maximum la masse de fichiers (en octets) qu il sera nécessaire de supprimer pour permettre le stockage des fichiers requis par cette tache et qui ne sont pas déjà présent sur ce client. On attribue au client disponible la tache nécessitant le moins de données à télécharger (en octets et non en nombre de fichiers). Si l on ne peut départager deux taches, on

18 18 CHAPITRE 3. MODÉLISATION essaye de minimiser le nombre de fichiers dont le client n aura pas l usage pour le traitement de la tache. Ainsi, par exemple si un client possède une copie de presque tous les fichiers disponibles, on y exécutera de préférence les taches nécessitant beaucoup des fichiers présents Temps d exécution d une tache Lorsqu un client a fini de télécharger tous les fichiers nécessaires à l exécution de la tache qui lui a été attribuée ( et dont il ne disposait pas encore), il exécute des traitements sur ces données pouvant durer un laps de temps variant énormément selon la nature des données et des calculs. Par exemple exécuter un filtrage des données, calculer un produit scalaire, résoudre un système triangulaire ou faire la combinaison linéaire de deux vecteurs prendra un temps proportionnel à la taille des fichiers, et la multiplication de matrices prendra un temps proportionnel au cube de cette même taille. Cependant si le temps de calcul est trop élevé en comparaison au temps de téléchargement des données, nous nous ramenons à un cas d étude où seule la vitesse de calcul importe (de même si le temps de téléchargement est trop élevé en comparaison au temps de calcul). Aussi ai-je opté pour un temps de calcul simplement proportionnel à la taille des données, multiplié par un facteur choisi expérimentalement de façon à obtenir des temps significatifs.

19 Chapitre 4 Simulation Nous avons décrit dans le chapitre précédent des schémas de simulation de stockage distribué, qui ont permis l implémentation d un simulateur grâce auquel plusieurs séries de mesures ont été réalisées, permettant d évaluer l impact de divers politiques de gestion des données et de placement des taches. Après une rapide description des paramètres du simulateur, nous allons détailler les expérimentations et les résultats obtenus, et conclure en présentant la solution optimale. 4.1 Paramètre du simulateur Le simulateur peut être lancé selon plusieurs modes, suivant les caractéristiques (politiques testés) et le type de modèle de réseau à simuler, et trois types de sorties sont disponibles, selon le degré de finesse et la nature des mesures à effectués. Un certain nombre de variables peuvent être paramétrées, dont : le taux de recopie d un fichier avant recopie, le nombre d expérimentations, la méthode de calcul du temps d exécution d une tache, etc... Le nombre de clients 1, le nombre de serveurs 2, le nombre de fichiers, le nombre de tache0, est au choix fixé choisi aléatoirement (selon une loi uniforme) entre deux bornes paramétrables incrémenté régulièrement d une valeur paramétrable jusqu à un seuil paramétrable choisi. le nombre de fichiers, la taille des fichiers, les débits des équipements réseaux des clients et des serveurs, les vitesses maximum des liens 0 peuvent être fixés ou choisis aléatoirement (selon une loi uniforme) entre deux bornes paramétrables Le nombre de threads0 peut être fixés incrémentés régulièrement d une valeur paramétrable jusqu à un seuil choisi. maximum (0 2 ) Dans un premier temps je me suis attaché à quantifier l influence de la fragmentation sur les vitesses de téléchargement, et son interdépendance avec l usage des threads et les 19

20 20 CHAPITRE 4. SIMULATION variations de tailles des fichiers. Puis j ai complexifié mon modèle, et après avoir vérifié que celui-ci résistait aux variations inhérentes au réseau, j ai introduit divers degrés de réplication et testé plusieurs politiques de duplication et de choix du réplicat à télécharger. Enfin dans la dernière partie, j ai intégré le temps de traitement des taches, et j ai étudié l efficacité de plusieurs politiques d allocation d une tache à un client. 4.2 Influence de la fragmentation, des threads et de la taille de fichiers Test d efficacité de la fragmentation et de l usage de threads Pour commencer, je me suis placé dans un cas simple (schéma 1 client-serveur) et j ai fixé un certain nombre de paramètres, pour tester uniquement l influence des threads et de la fragmentation sur la moyenne des temps de récupération des fichiers. Ma première expérimentation a montré un gain notable et cumulable grâce à ces deux méthodes. Paramètres nombre de clients incrémenté de 1 à 100 nombre fixe de serveurs : 10 nombre maximum de fichiers : 60 taille fixe des fichiers : Mb vitesse des débits clients : 1000 Mb/s vitesse des débits serveurs : 1000 Mb/s vitesse des liens : 100 Mb/s Expérience exécutée 1000 fois avec et sans fragmentation avec 1,2,4,8 threads pas de recopie

21 4.2. INFLUENCE DE LA FRAGMENTATION, DES THREADS ET DE LA TAILLE DE FICHIERS21 Résultats moyenne des temps totaux par rapport au nombre de clients sans replication (10 serveurs) moyenne temps totaux avec fragmentation et 1 thread moyenne temps totaux avec fragmentation et 2 threads moyenne temps totaux avec fragmentation et 4 threads moyenne temps totaux avec fragmentation et 8 threads moyenne temps totaux sans fragmentation et 1 thread moyenne temps totaux sans fragmentation et 2 threads moyenne temps totaux sans fragmentation et 4 threads moyenne temps totaux sans fragmentation et 8 threads 2000 temps Nombre de clients On constate que dans ce cas de figure idéal (pas de trafic parasitaire, vitesses des liens maximum) la politique la plus efficace est avec fragmentation et 8 threads, puis avec fragmentation et 4, puis 2, puis 1 threads, puis sans fragmentation et 8, 4, 2 threads, et que le pire résultat est sans fragmentation et sans thread. Interprétation La fragmentation permet un gain notable de performances, qui augmente avec le nombre de clients : cette politique n apporte pratiquement rien si le nombre de client est trop faible (10-20 clients) mais devrait permettre de passer plus facilement à l échelle. L augmentation du nombre de threads permet un gain notable de performance, (cumulable avec le gain de la fragmentation) mais qui tend vers 0 avec l augmentation du nombre de client. le temps de récupération est au maximum proportionnel à l inverse du nombre de threads utilisés, soit ) " % 0 avec ) " le temps total de récupération, % ' ) " le temps total de récupération avec 1 thread et, le nombre de threads. Un grand nombre de threads 1 n est pas efficace. Le gain le plus notable est donc pour 2 threads. Les limites de débits des clients et des serveurs réduisent l efficacité des threads. 1 en plus de ne pas être TCP-friendly

22 22 CHAPITRE 4. SIMULATION Dans cette première expérience, les débits de clients sont assez élevés pour pouvoir supporter 10 connections threadées à 10 serveurs sans ralentissement. L augmentation du nombre de clients entraîne une saturation des débits des serveurs, d où dégradation des performances Test sur la variation des tailles des fichiers Intuitivement, on peut penser que la fragmentation et la répartition des fichiers sur tous les serveurs homogénéise les temps de récupération et peut limiter une possible dégradation les performances dans le cas où les fichiers sont de tailles fortement hétérogènes. J ai donc réitéré la même expérience en faisant varier l écart de taille des fichiers. On pourra constater que ces variations n ont finalement que peu d influence. Paramètres jusqu à 3 tailles des fichiers testés : fixés à 10000Mb, aléatoire entre 5000 Mb et 15000Mb, aléatoire entre 1000Mb et 19000Mb avec et sans fragmentation avec 1,2,4,8 threads Les autres paramètres restent identiques Résultats moyenne des temps totaux par rapport au nombre de clients pour 1 thread/client sans replication moyenne des temps totaux par rapport au nombre de clients pour 2 threads/client sans replication moyenne temps totaux avec fragmentation, taille des fichiers=10000 moyenne temps totaux avec fragmentation, taille des fichiers=[ ] moyenne temps totaux sans fragmentation, taille des fichiers=10000 moyenne temps totaux sans fragmentation, taille des fichiers=[ ] moyenne temps totaux sans fragmentation, taille des fichiers=[ ] moyenne temps totaux avec fragmentation, taille des fichiers=10000 moyenne temps totaux avec fragmentation, taille des fichiers=[ ] moyenne temps totaux sans fragmentation, taille des fichiers=10000 moyenne temps totaux sans fragmentation, taille des fichiers=[ ] moyenne temps totaux sans fragmentation, taille des fichiers=[ ] temps 2500 temps Nombre de clients Nombre de clients moyenne des temps totaux par rapport au nombre de clients pour 4 threads/client sans replication moyenne des temps totaux par rapport au nombre de clients pour 8 threads/client sans replication 3000 moyenne temps totaux avec fragmentation, taille des fichiers=10000 moyenne temps totaux avec fragmentation, taille des fichiers=[ ] moyenne temps totaux sans fragmentation, taille des fichiers=10000 moyenne temps totaux sans fragmentation, taille des fichiers=[ ] 3000 moyenne temps totaux avec fragmentation, taille des fichiers=10000 moyenne temps totaux avec fragmentation, taille des fichiers=[ ] moyenne temps totaux sans fragmentation, taille des fichiers=10000 moyenne temps totaux sans fragmentation, taille des fichiers=[ ] moyenne temps totaux sans fragmentation, taille des fichiers=[ ] temps 1500 temps Nombre de clients Nombre de clients

23 4.3. TEST DE L EFFICACITÉ DE LA DUPLICATION 23 L augmentation de l écart de taille des fichiers n a aucune influence si les fichiers sont fragmentés, et fait varier de façon négligeable le temps de récupération si les fichiers ne sont pas fragmentés. Cet accroissement diminue encore lorsque le nombre de threads augmente. Interprétations Les variations de la taille des fichiers n ont donc que peu d influence sur les résultats : pour les expériences suivantes, nous avons utilisé systématiquement des fichiers de tailles variant entre 1000Mb et 19000Mb. 4.3 Test de l efficacité de la duplication Nous avons ensuite fait varier un plus grand nombre de paramètres afin d obtenir une simulation plus réaliste. Nous avons commencé par montrer que les variations de vitesses inhérentes aux réseaux n ont que peu d influence sur ce modèle, puis la notion de réplication a été ajoutée, ce qui permet d introduire mon second schéma basé sur une l approche Peerto-Peer Influence du trafic externe sur l expérimentation Pour vérifier l influence du trafic externe sur ma simulation, un "bruit" réseau a été ajouté, représenté par diverses variations aléatoires de vitesse des liens. On constatera que celui-ci n a que peu d influence sur les résultats. Paramètres nombre de clients et de serveurs incrémenté simultanément : nombre maximum de fichiers : 30 vitesse des débits clients : aléatoire (uniformément) entre 50 et 500Mb/s vitesse des débits serveurs : aléatoire (uniformément) entre 100 et 1000Mb/s Sans fragmentation et 2 threads Expérience réalisée 300 fois 4 vitesses de liens testées : fixé à 500 fixé aléatoirement (uniformément) en début de simulation entre 100 et 1000 Mb/s fixé aléatoirement (uniformément) en début de simulation entre 100 et 1000 Mb/s +/- 10% de variation après chaque récupération de fichier fixé aléatoirement (uniformément) en début de simulation entre 100 et 1000 Mb/s +/- 20% de variation après chaque récupération de fichier

24 24 CHAPITRE 4. SIMULATION Résultats moyenne des temps totaux de 300 experiences de recuperation de 30 fichiers moyenne des temps maximun de 300 experiences de recuperation de 30 fichiers threads sans fragmentation 2 threads, sans fragmentation et ajout de +-10 % de traffic aleatoire 2 threads sans fragmentation, vitesse des liens fixe 2 threads, sans fragmentation et ajout de +-20% de traffic aleatoire threads sans fragmentation 2 threads, sans fragmentation et ajout de +-10 % de traffic aleatoire 2 threads sans fragmentation, vitesse des liens fixe 2 threads, sans fragmentation et ajout de +-20% de traffic aleatoire temps temps Nombre de serveurs/clients Nombre de serveurs/clients Le premier graphique indique la moyenne sur 300 expériences des temps totaux de récupération des fichiers. Le second graphique indique la moyenne des temps maximaux de récupération des fichiers. On constate dans les deux cas que toutes les courbes ont un comportement identique. Interprétation Calculer des moyennes sur 300 expériences permet d obtenir un "lissage" des résultats. On a donc considéré les prochains résultats comme non assujetti au trafic externe, à condition d ajouter +/-500 de marge d erreur Test d efficacité de diverses politiques de choix de duplication Après cette "validation" de mes nouveaux paramètres de simulation, j ai recommencé mes tests de temps de récupération non seulement suivant l usage (ou non) de la fragmentation et du multi-thread, mais aussi selon deux taux de recopie différents, ce qui démontrera l efficacité d un taux de recopie élevé et l inutilité du multi-thread massif sans fragmentation. paramètres nombre de clients et de serveurs incrémenté simultanément : 3-50 nombre maximum de fichiers : 30 vitesse des débits clients : aléatoire (uniformément) entre 50 et 500Mb/s vitesse des débits serveurs : aléatoire (uniformément) entre 100 et 1000Mb/s vitesse des liens : aléatoire (uniformément) entre 10 et 100 Mb/s Expérience réalisée 300 fois. sans fragmentation pour commencer avec 1,2,8 threads avec et sans recopie 2 politiques de recopie testées : si le taux de popularité d un fichier = 1 ou recopie d un fichier à chaque accès (taux de popularité = 1, cas du second schéma de réseau : approche Peer-to-Peer) 1,

25 4.3. TEST DE L EFFICACITÉ DE LA DUPLICATION 25 politique de choix parmi les serveurs disposant d un même fichier : test sur la vitesse des liens Résultats sans fragmentation moyenne des temps totaux de 300 experiences de recuperation de 30 fichiers sans thread et sans fragmentation avec 2 threads et sans fragmentation avec 8 threads et sans fragmentation avec taux de recopie 1/1, sans thread et sans fragmentation avec taux de recopie 1/1, avec 2 threads et sans fragmentation avec taux de recopie 1/1 avec 8 threads et sans fragmentation avec taux de recopie n/3, sans thread et sans fragmentation avec taux de recopie n/3, avec 2 threads et sans fragmentation avec taux de recopie n/3 avec 8 threads et sans fragmentation 6000 temps Nombre de serveurs/clients moyenne des temps maximaux de 300 experiences de recuperation de 30 fichiers sans thread et sans fragmentation avec 2 threads et sans fragmentation avec 8 threads et sans fragmentation avec taux de recopie 1/1, sans thread et sans fragmentation avec taux de recopie 1/1, avec 2 threads et sans fragmentation avec taux de recopie 1/1 avec 8 threads et sans fragmentation avec taux de recopie n/3, sans thread et sans fragmentation avec taux de recopie n/3, avec 2 threads et sans fragmentation avec taux de recopie n/3 avec 8 threads et sans fragmentation temps Nombre de serveurs/clients On observe que les trois meilleures moyennes de temps totaux de récupération sont obtenus avec respectivement 8,2,1 threads et un taux de recopie de 1 pour 1 ; puis avec 8,2,1 threads et un taux moins élevé, et enfin avec 8,2,1 threads sans recopie. De plus, les trois meilleures moyennes de temps maximaux de récupération sont obtenues avec respectivement 1,2,8 threads et un taux de recopie de 1 pour 1 ; puis avec 1,2,8 threads et un taux moins élevé, et enfin avec 1,2,8 threads sans recopie.

26 26 CHAPITRE 4. SIMULATION interprétations des résultats sans fragmentation Plus le taux de recopie est bas, plus le nombre de fichiers dupliqués est élevé, meilleures sont les performances générales (moyenne des temps maximaux et totaux bas). Avec 1, 2 ou 8 threads et sans fragmentation, le taux de recopie de 1 pour 1 donne les meilleurs résultats : On observe des temps totaux et maximaux pratiquement constant, ce qui tend à montrer que cette solution passe à l échelle. L augmentation du nombre de threads entraîne une diminution des temps totaux (non significative au-delà de 2 threads) mais aussi une augmentation inversement proportionnelle des temps maximaux, la saturation des liens entraînant un ralentissement de tous les téléchargements effectués en parallèle. De plus, les moyennes des temps totaux finissent par converger à une vitesse proportionnelle au nombre de threads. L usage de threads n est donc pas réellement efficace avec un grand nombre de clients et de serveurs et sans fragmentation. Nous avons par la suite tenté la même expérience avec un nombre plus significatif de clients et de serveurs, et en y ajoutant la fragmentation. On constatera que les gains de performances obtenus ne sont pas réellement cumulables avec ceux de la réplication. Résultats avec fragmentation moyenne des temps totaux de 300 experiences de recuperation de 30 fichiers avec taux de recopie 1/1 avec 8 threads et avec fragmentation avec taux de recopie n/3 avec 8 threads et avec fragmentation sans thread et avec fragmentation avec 2 threads et avec fragmentation avec taux de recopie 1/1, sans thread et avec fragmentation avec taux de recopie 1/1, avec 2 threads et avec fragmentation avec taux de recopie n/3, sans thread et avec fragmentation avec taux de recopie n/3, avec 2 threads et avec fragmentation temps Nombre de serveurs/clients On observe que toutes les courbes tendent vers un minima commun, hormis celles obtenues à la fois sans threads avec un taux de recopie inférieur à 1 pour 1. Le même phénomène à été constaté aussi bien pour la moyenne des temps totaux que la moyenne des temps maximaux de récupération.

27 4.3. TEST DE L EFFICACITÉ DE LA DUPLICATION 27 Interprétations des résultats avec fragmentation On constate que l on ne fait pas mieux que le minima 2 atteint par la meilleur des courbes sans fragmentation et avec un taux de recopie 1 pour 1 (et un nombre quelconque de threads), cependant ce minima peut être atteint sans recopie, uniquement avec l usage cumulé de la fragmentation et d un nombre limité de threads et de la fragmentation. L efficacité de la réplication que ces expérimentations démontrent dépend en bonne partie de quelle copie du fichier à télécharger a été choisie. Un choix basé sur la vitesse des liens et le débit du serveur semble efficace. Les tests de diverses autres heuristiques de choix que je vais ensuite présenter vont confirmer ce résultat Test de divers politiques de choix du meilleur serveur Paramètres nombre de clients et de serveurs incrémenté simultanément : nombre maximum de fichiers : 30 taille des fichiers aléatoire (uniformément) entre 1000Mb et 19000Mb vitesse des débits clients : aléatoire (uniformément) entre 50 et 500Mb/s vitesse des débits serveurs : aléatoire (uniformément) entre 100 et 1000Mb/s vitesse des liens : aléatoire (uniformément) entre 10 et 100 Mb/s expérience réalisée 300 fois 2 threads, sans et avec fragmentation. Les deux même politiques de recopie précédentes vont être testées : si le taux de popularité d un fichier = nombre de clients / 3, ou recopie d un fichier à chaque accès. item 2 politiques de choix parmi les serveurs disposant d un même fichier vont être testées : test sur la vitesse des liens et du débit du serveur ou test de la somme du nombre des fichiers et de leur popularité. Résultats sans fragmentation moyenne des temps totaux de 300 experiences de recuperation de 30 fichiers (sans fragmentation) moyenne des temps maximaux de 300 experiences de recuperation de 30 fichiers taux de recopie n/3, 2 threads, choix du meilleur serveur test des vitesses des liens taux de recopie 1/1, 2 threads, choix du meilleur serveur : test des vitesses des liens taux de recopie n/3, 2 threads, choix du meilleur serveur : somme des popularites taux de recopie 1/1, 2 threads, choix du meilleur serveur : somme des popularites taux de recopie n/3, 2 threads, choix du meilleur serveur test des vitesses des liens taux de recopie 1/1, 2 threads, choix du meilleur serveur : test des vitesses des liens taux de recopie n/3, 2 threads, choix du meilleur serveur : somme des popularites taux de recopie 1/1, 2 threads, choix du meilleur serveur : somme des popularites temps temps Nombre de serveurs/clients Nombre de serveurs/clients 2 Ce minima vaut environ 2500s et reste pratiquement constant malgré l augmentation du nombre de clients et de serveurs