Table des matières
1 Introduction 3
2 Etat de l’art 7
2.1 Qu’est ce que la Grille ? . . . 7
2.2 Quelques exemples de grilles de calcul . . . 8
2.3 Systèmes de fichiers distribués pour les Grilles . . . 8
2.4 Internet Backplane Protocol . . . 9
3 Modélisation 11 3.1 Modélisation du réseau. . . 11
3.1.1 LesThreads, ou modèle de communication multiport. . . . 12
3.1.2 Méthode de calcul dynamique des vitesses réelles des liens . . . 13
3.2 Distribution des fichiers. . . 14
3.2.1 Popularité d’un fichier . . . 14
3.2.2 Fragmentation et répartition des fichiers . . . 14
3.2.3 Duplication des fichiers . . . 15
3.3 Les tâches . . . 17
3.3.1 Politique d’attribution des taches . . . 17
3.3.2 Temps d’exécution d’une tache . . . 18
4 Simulation 19 4.1 Paramètre du simulateur . . . 19
4.2 Influence de la fragmentation, des threads et de la taille de fichiers . . . 20
4.2.1 Test d’efficacité de la fragmentation et de l’usage de threads . . . 20
4.2.2 Test sur la variation des tailles des fichiers . . . 22
4.3 Test de l’efficacité de la duplication . . . 23
4.3.1 Influence du trafic externe sur l’expérimentation . . . 23
4.3.2 Test d’efficacité de diverses politiques de choix de duplication . . . 24 1
2 TABLE DES MATIÈRES 4.3.3 Test de divers politiques de choix du meilleur serveur . . . 27 4.4 Ajout de la notion de tache. . . 28 4.4.1 Impact du placement des taches . . . 28 4.4.2 Gestion de l’espace disque par LRU et répartition de charge par le pla-
cement de tache . . . 31
5 Conclusion 33
Bibliographie 35
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 mau- vaise 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 po- pulaires. 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 den 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 conte- nant "f" fichiers et de deux noeuds de calcul différents (capacité de calcul et vitesse de liens
3
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.1Autres 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 pro- blè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 sur1 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 pos- sible 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 sto- chastiques) nécessite de nous ramener à des modèles mathématiques basés sur des hypo- thè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 simula- tion 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 obser- vé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.
6 CHAPITRE 1. INTRODUCTION
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 ap- proches possibles pour le stockage distribué des données générées par les Grilles, et particu- liè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 mon- diale 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 res- sources classiques, processeurs, mémoire et stockage, mais aussi les applications. Elle faci- lite 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 tech- nologies 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 sys- tè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 sys- tè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 trai- tement 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 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’ap- puient 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éve- loppeurs 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 techno- logies 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 (schedulingdes 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’ef- ficacité de ce système). Kangaroo utilise un système de cache pour assurer la disponibilité
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 sto- ckages 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.1Structure 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 sto- ckage...). 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 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.2Le 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.3Té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’éta- blir des connections cryptées et multi-threadées.
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.1Repré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 in- fluence 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’exploi- tation 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 nom- breuses 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 forte- ment entropique, modulo une certaine marge d’erreur raisonnable. L’objectif n’étant pas de
11
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.2Schéma 1 : approche client-serveur
On considère que 1 clients cherchent à télécharger certains des fichiers de taille , répartis aléatoirement sur2 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.
3.1.1 LesThreads, 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 nonthreadé 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
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 sys- tè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.
3.1.2 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 inactifs1sont 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.
1chaque lien reliant un serveur avec un client n’ayant aucun téléchargement en cours
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.
3.2.1 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).
3.2.2 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.
3.2. DISTRIBUTION DES FICHIERS. 15 Figure 3.3Schéma 2 : approche Peer-to-Peer
En résumé, la fragmentation revient à posséder2 fois plus de fichiers 2 fois plus petits, et répartis de façon (pseudo)homogène.
3.2.3 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 na- turellement 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 CHAPITRE 3. MODÉLISATION – On peut choisir aléatoirement un serveur ne disposant pas déjà de ce fichier mais pos-
sé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 :
0
1 1
– 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 im- plé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’ar- rivé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’as- surer 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
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 Peer- to-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 nombre0 paramétrable de tâches et on leur attribue aléatoirement (se- lon 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épen- dantes les unes par rapport aux autres.
Figure 3.4Schéma 3 : approche Peer-to-Peer avec notion de taches
3.3.1 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 CHAPITRE 3. MODÉLISATION essaye de minimiser le nombre de fichiers dont le client n’aura pas l’usage pour le trai- tement 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.
3.3.2 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érimen- talement de façon à obtenir des temps significatifs.
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 (poli- tiques testés) et le type de modèle de réseau à simuler, et trois types de sorties sont dispo- nibles, 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 clients1 , le nombre de serveurs2 , 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 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 varia- tions inhérentes au réseau, j’ai introduit divers degrés de réplication et testé plusieurs poli- tiques 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 fi- chiers
4.2.1 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 : 10000 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
4.2. INFLUENCE DE LA FRAGMENTATION, DES THREADS ET DE LA TAILLE DE FICHIERS21 Résultats
0 500 1000 1500 2000 2500 3000 3500
0 10 20 30 40 50 60 70 80 90 100
temps
Nombre de clients
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
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 frag- mentation 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, (cumu- lable 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 1n’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.
1en plus de ne pas être TCP-friendly
22 CHAPITRE 4. SIMULATION Dans cette première expérience, les débits de clients sont assez élevés pour pouvoir suppor- ter 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 perfor- mances.
4.2.2 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
1000 1500 2000 2500 3000 3500 4000
0 10 20 30 40 50 60 70 80 90 100
temps
Nombre de clients
moyenne des temps totaux par rapport au nombre de clients pour 1 thread/client sans replication moyenne temps totaux avec fragmentation, taille des fichiers=10000
moyenne temps totaux avec fragmentation, taille des fichiers=[1000-19000]
moyenne temps totaux sans fragmentation, taille des fichiers=10000 moyenne temps totaux sans fragmentation, taille des fichiers=[5000-15000]
moyenne temps totaux sans fragmentation, taille des fichiers=[1000-19000]
500 1000 1500 2000 2500 3000
0 10 20 30 40 50 60 70 80 90 100
temps
Nombre de clients
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=[1000-19000]
moyenne temps totaux sans fragmentation, taille des fichiers=10000 moyenne temps totaux sans fragmentation, taille des fichiers=[5000-15000]
moyenne temps totaux sans fragmentation, taille des fichiers=[1000-19000]
0 500 1000 1500 2000 2500 3000
0 10 20 30 40 50 60 70 80 90 100
temps
Nombre de clients
moyenne des temps totaux par rapport au nombre de clients pour 4 threads/client sans replication moyenne temps totaux avec fragmentation, taille des fichiers=10000
moyenne temps totaux avec fragmentation, taille des fichiers=[1000-19000]
moyenne temps totaux sans fragmentation, taille des fichiers=10000 moyenne temps totaux sans fragmentation, taille des fichiers=[1000-19000]
0 500 1000 1500 2000 2500 3000
0 10 20 30 40 50 60 70 80 90 100
temps
Nombre de clients
moyenne des temps totaux par rapport au nombre de clients pour 8 threads/client sans replication moyenne temps totaux avec fragmentation, taille des fichiers=10000
moyenne temps totaux avec fragmentation, taille des fichiers=[1000-19000]
moyenne temps totaux sans fragmentation, taille des fichiers=10000 moyenne temps totaux sans fragmentation, taille des fichiers=[5000-15000]
moyenne temps totaux sans fragmentation, taille des fichiers=[1000-19000]
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 Peer- to-Peer.
4.3.1 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 : 10-300 – 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 CHAPITRE 4. SIMULATION Résultats
0 2000 4000 6000 8000 10000 12000 14000 16000 18000
0 50 100 150 200 250 300
temps
Nombre de serveurs/clients
moyenne des temps totaux de 300 experiences de recuperation de 30 fichiers 2 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
0 2000 4000 6000 8000 10000 12000 14000 16000 18000
0 50 100 150 200 250 300
temps
Nombre de serveurs/clients
moyenne des temps maximun de 300 experiences de recuperation de 30 fichiers 2 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
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 com- portement 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.
4.3.2 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 fragmenta- tion 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 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)
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
1000 2000 3000 4000 5000 6000 7000 8000 9000
0 5 10 15 20 25 30 35 40 45 50
temps
Nombre de serveurs/clients
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
500 1000 1500 2000 2500 3000 3500 4000 4500 5000
0 5 10 15 20 25 30 35 40 45 50
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
On observe que les trois meilleures moyennes de temps totaux de récupération sont ob- tenus 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 respective- ment 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 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 proportion- nelle 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 propor- tionnelle 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 per- formances obtenus ne sont pas réellement cumulables avec ceux de la réplication.
Résultats avec fragmentation
1000 2000 3000 4000 5000 6000
0 20 40 60 80 100 120 140
temps
Nombre de serveurs/clients
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
On observe que toutes les courbes tendent vers un minima commun, hormis celles obte- nues à 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 maxi- maux de récupération.
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 minima2atteint 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 par- tie 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.
4.3.3 Test de divers politiques de choix du meilleur serveur Paramètres
– nombre de clients et de serveurs incrémenté simultanément : 10-200 – 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 popu- larité 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
0 2000 4000 6000 8000 10000 12000 14000 16000 18000
0 20 40 60 80 100 120 140 160 180 200
temps
Nombre de serveurs/clients
moyenne des temps totaux de 300 experiences de recuperation de 30 fichiers (sans fragmentation) 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
0 2000 4000 6000 8000 10000 12000 14000
0 20 40 60 80 100 120 140 160 180 200
temps
Nombre de serveurs/clients
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
2Ce minima vaut environ 2500s et reste pratiquement constant malgré l’augmentation du nombre de clients et de serveurs
28 CHAPITRE 4. SIMULATION
0 2000 4000 6000 8000 10000 12000
0 20 40 60 80 100 120 140
temps
Nombre de serveurs/clients
moyenne des temps totaux de 300 experiences de recuperation de 30 fichiers (avec fragmentation) 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
0 10000 20000 30000 40000 50000 60000 70000
0 20 40 60 80 100 120 140
temps
Nombre de serveurs/clients
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
On constate que la politique de test des vitesses donnent les meilleurs résultats avec et sans fragmentation.
Interprétation
Dans le cas d’une recopie systématique des fichiers accédés, leur popularité reste à 0 : tes- ter la somme du nombre de fichiers et de leur popularité revient donc simplement à choisir en priorité le serveur possédant le moins de fichiers. Avec cette définition de la popularité, cette heuristique est inefficace.
Dans le cas d’une recopie des fichiers accédés par un tiers des clients, les deux politiques de choix du meilleur serveur proposées donnent tous deux des résultats identiques : efficace avec fragmentation, inefficace sinon.
En conclusion, le cas d’une recopie systématique des fichiers accédés avec test de la vi- tesse des liens est efficace avec et sans fragmentation. De plus l’augmentation du nombre de clients/serveurs semble ne pratiquement pas avoir d’influence sur les performances.
4.4 Ajout de la notion de tache
Comme nous avions alors une vision plus précise des mécanismes de réplication et de fragmentation, nous avons ajouté les taches à notre simulation pour implémenter le 3eme schéma de réseau décrit, et tester l’impact de diverses techniques de placement de taches.
Comme on constate par la suite que la diffusion naturelle des fichiers par recopie rend inutile voire inefficace les heuristiques de placement de taches, je conclurai en tentant de réduire le coût en espace disque de cette réplication par une gestion LRU des données et une politique de répartition des charges, pour éviter de nuire aux performances générales.
4.4.1 Impact du placement des taches
L’expérience suivante a montré l’inefficacité de différentes politiques de placement sur les temps de téléchargement et de traitement dans un environnement de grille avec frag- mentation et/ou duplication et/ou multi-thread, et cela en fonction du nombre de taches.
On estime que dans la grille, de nombreuses taches peuvent être soumises, mais que géné- ralement chacune d’elle ne nécessite à chaque fois que peu de fichiers.
4.4. AJOUT DE LA NOTION DE TACHE 29 Paramètres
– Nombre de clients et de serveurs testé : 4, puis 40 – Nombre maximum de fichier par tache : 8
– Nombre de taches incrémenté régulièrement jusqu’à 450 – avec et sans fragmentation
– 1 et 2 threads
– Politique de réplication : chaque client met à disposition sa copie des fichiers récupérés.
– Politique de choix parmi les serveurs disposant d’un même fichier : test des vitesses des liens item Répartition des taches : chaque client disponible exécute la prochaine tache ou les taches sont placées sur les clients afin de limiter la taille des fichiers à télécharger
– Temps de calcul d’une tache :
0
avec Z=0.001
Résultat
0 1000 2000 3000 4000 5000 6000
0 50 100 150 200 250 300 350 400
temps
Nombre de taches
moyenne temps totaux de 300 experiences de recuperation et execution de taches sans thread, 4 clients/serveurs sans fragmentation
2 threads, 4 clients/serveurs sans fragmentation, affectation des taches dans l’ordre sans thread, 4 clients/serveurs avec fragmentation, affectation des taches dans l’ordre 2 threads, 4 clients/serveurs avec fragmentation, affectation des taches dans l’ordre sans thread, 4 clients/serveurs sans fragmentation, minimisation des tailles des fichiers a charger 2 threads, 4 clients/serveurs sans fragmentation, minimisation des tailles des fichiers a charger sans thread, 4 clients/serveurs avec fragmentation, minimisation des tailles des fichiers a charger 2 threads, 4 clients/serveurs avec fragmentation, minimisation des tailles des fichiers a charger
