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 :
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 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