Émulation des systèmes pair-à-pair

Laboratoire
Informatique et
Distribution
Émulation des systèmes pair-à-pair
Lucas Nussbaum
sous la direction de
Olivier Richard
Membres du jury :
Joëlle Coutaz
Yves Denneulin
Jérôme Euzenat
Noël De Palma
Juin 2005
2
Émulation des Systèmes pair-à-pair
Lucas Nussbaum
sous la direction de
Olivier Richard
{lucas.nussbaum,olivier.richard}@imag.fr
Laboratoire ID-IMAG
Montbonnot St Martin, Isère
Résumé
Maintenant utilisés pour des applications très diverses, les systèmes pair-à-pair sont difficiles à étudier du fait de leur complexité.
Entre la simulation à partir d’un modèle, et l’exécution sur un système réel, l’émulation (exécution de l’application réelle dans un environnement synthétique) permet souvent d’obtenir des résultats à
un moindre coût.
Nous proposons un système d’émulation léger (permettant d’émuler un grand nombre de noeuds virtuels sur un faible nombre de
noeuds physique), passant bien à l’échelle, et particulièrement adapté
à l’émulation des aspects réseaux des systèmes pair-à-pair. Après
avoir vérifié la validité des résultats obtenus par cette approche, nous
avons avons utilisé cette technique pour étudier quelques aspects du
système d’échange de fichiers BitTorrent.
Mots clés : Émulation, réseau, systèmes pair-à-pair
4
Table des matières
Remerciements
7
1
Introduction et problématique
9
2
Outils d’étude des systèmes pair à pair
11
2.1
Caractéristiques attendues d’un émulateur . . . . . . . . . . . . . . . . . . . .
11
2.2
Outils de simulation existants . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12
2.3
Outils d’émulation existants . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12
2.3.1
Outils d’émulation réseau . . . . . . . . . . . . . . . . . . . . . . . . . .
12
2.3.2
Outils d’émulation de système . . . . . . . . . . . . . . . . . . . . . . .
17
2.3.3
Outils d’émulation de systèmes distribués . . . . . . . . . . . . . . . .
18
Systèmes réels dédiés à l’expérimentation . . . . . . . . . . . . . . . . . . . . .
20
2.4
3
4
P2PLab : un système d’émulation léger
21
3.1
Particularités de l’émulation des systèmes pair-à-pair . . . . . . . . . . . . . .
22
3.1.1
Impact sur le système . . . . . . . . . . . . . . . . . . . . . . . . . . . .
22
3.1.2
Aspects réseaux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
22
3.1.3
Applications limitées par le processeur ou par le réseau . . . . . . . . .
23
3.2
P2PLab : présentation générale . . . . . . . . . . . . . . . . . . . . . . . . . . .
23
3.3
Émulation du réseau avec P2PLab . . . . . . . . . . . . . . . . . . . . . . . . .
23
3.4
Affectation d’adresses IP aux processus . . . . . . . . . . . . . . . . . . . . . .
25
Évaluation de l’émulation avec P2PLab
29
4.1
Étude de la faisabilité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
29
4.1.1
Passage à l’échelle du nombre de processus . . . . . . . . . . . . . . . .
29
4.1.2
Équité entre processus . . . . . . . . . . . . . . . . . . . . . . . . . . . .
31
Émulation du réseau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
33
4.2
5
4.3
5
6
Affectation d’adresses IP aux processus . . . . . . . . . . . . . . . . . . . . . .
33
Émulation avec P2PLab : expériences
35
5.1
Émulation d’une topologie réseau complexe . . . . . . . . . . . . . . . . . . .
35
5.2
Étude de BitTorrent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
35
5.2.1
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
35
5.2.2
Validité des résultats . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
37
5.2.3
Passage à l’échelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
37
5.2.4
Super-seeding et autres techniques pour accélérer la diffusion . . . . .
38
Conclusion et perspectives
41
Remerciements
Je tiens tout d’abord à remercier Olivier Richard, qui m’a donné
la possibilité de mener cette étude au sein du laboratoire Informatique et Distribution, de son encadrement précieux et du temps qu’il
a eu l’amabilité de me consacrer.
Je remercie également l’ensemble des membres du laboratoire
pour leur accueil chaleureux, et pour les conseils et les explications
qu’ils ont su me fournir.
Enfin, je remercie les rapporteurs et membres du jury qui me font
l’honneur de juger ce travail.
7
8
Chapitre 1
Introduction et problématique
La puissance de calcul et les connexions à Internet disponibles sur les ordinateurs personnels ont atteint des niveaux qui étaient réservés il y a quelques années encore aux centres
de calcul. Afin d’exploiter ces ressources inutilisées la plupart du temps, un nouveau type
d’applications a émergé : les applications distribuées, ou systèmes pair à pair.
Les systèmes pair à pair ont d’abord été utilisés pour du calcul (Distributed.net, SETI@home,
puis BOINC et XtremWeb [1]) et du partage de fichiers (Freenet [2], Napster, Kazaa, ...), mais
ils sont maintenant utilisées dans des domaines bien plus divers, comme la voix sur IP [3]
ou la messagerie instantanée.
Le développement, la mise au point et l’étude des systèmes pair à pair est difficile. Il faut
pouvoir évaluer le comportement d’applications ou d’algorithmes sur des milliers de machines fortement hétérogènes, alors qu’on dispose en général d’un nombre bien plus réduit
de machines, le plus souvent homogènes.
Quatre méthodes sont actuellement utilisées pour étudier les systèmes pair à pair :
–
–
–
–
la modélisation mathématique ;
la simulation ;
l’émulation ;
l’exécution sur système réel.
La modélisation mathématique consiste à mettre en équation le système à étudier. Cette
approche permet d’étudier certaines propriétés du système, comme l’aptitude au passage à
l’échelle par exemple, mais elle reste assez limitée dans le cas général.
La méthode de simulation est celle qui a fait l’objet du plus de recherche. Elle est assez
fiable quant aux résultats fournis. Elle consiste à utiliser un modèle mathématique ou une
représentation du code dans un environnement synthétique. Toutes les composantes de l’environnement sont complètement contrôlées et reproduites au sein du simulateur. Le principal avantage de cette approche est d’être indépendante du matériel disponible, puisque tout
est entièrement modélisé dans le simulateur. Par contre, il faut proposer le système à étudier
sous un modèle compréhensible par le simulateur. Et plus la modélisation est précise, plus
la simulation sera coûteuse : il est donc important de vérifier que les simplifications nécessaires ne nuisent pas à la représentativité des résultats obtenus. En outre, les simulateurs
gérant leur propre évolution du temps, en général conduite par des événements, il n’est pas
9
possible de faire des simulations en temps réel.
A l’opposé de la simulation, on peut exécuter le système à étudier sur un système réel.
Dans ce cas, on dispose directement de l’environnement à modéliser, mais les conditions
d’expérience sont évidemment limitées par le matériel disponible.
L’émulation est une solution intermédiaire entre la simulation et l’exécution sur système
réel. Elle consiste à exécuter réellement l’application à étudier en lui présentant un environnement synthétique. Le réalisme de l’émulation dépend donc directement de la qualité de la
modélisation de l’environnement. Les conditions d’émulations dépendent partiellement de
la plate-forme utilisée, mais un environnement de laboratoire permet en général de reproduire une très large gamme de conditions d’expérience.
Au cours de ce stage, mon objectif sera d’étudier la faisabilité d’un système d’émulation léger de systèmes pair à pair, permettant d’émuler un grand nombre de noeuds. Nous
commencerons par présenter l’état de l’art de la simulation et surtout de l’émulation (chapitre 2), puis nous proposerons un système d’émulation, P2PLab, (chapitre 3) et vérifierai
ses propriétés (chapitre 4), avant de l’utiliser pour examiner quelques aspects du système
pair-à-pair d’échange de fichiers BitTorrent (chapitre 5).
10
Chapitre 2
Outils d’étude des systèmes pair à pair
2.1 Caractéristiques attendues d’un émulateur
On attend les caractéristiques suivantes d’un émulateur :
Bon rapport machines émulées/machines physiques : L’émulation doit être efficace : l’émulateur doit permettre d’émuler un grand nombre de machines virtuelles sur un faible
nombre de machines physiques.
Faible surcoût dû à l’émulation : L’émulation ne doit pas provoquer de distorsion des résultats par rapport à une exécution sur machine physique. Son surcoût doit être suffisamment faible pour mettre une émulation efficace.
Bonne aptitude au passage à l’échelle : L’émulateur doit permettre d’augmenter facilement
le nombre de systèmes virtuels émulés, en augmentant simplement le nombre de systèmes physiques.
Accès équitable et paramétrable aux ressources : L’émulateur doit permettre de reproduire
une grande variété de conditions d’expérience différentes. Il doit, si l’expérimentateur
le désire, garantir l’équité entre les systèmes virtuels.
Utilisation d’applications sans modification, dans un environnement virtuel : L’émulateur
doit permettre d’utiliser des applications sans les modifier, ou en se contentant de modifications triviales.
Reproductibilité des expériences : L’émulateur doit permettre de faire des expériences reproductibles, notamment afin d’affiner les mesures.
Utilisabilité : L’utilisabilité de l’émulateur doit être bonne. La mise en place de l’environnement d’émulation et son paramétrage ne doivent pas être trop fastidieux. De plus, cette
procédure de configuration doit rester simple lorsque le nombre de noeuds à configurer est important (bon passage à l’échelle).
Bien sûr, il est impossible de satisfaire toutes ces caractéristiques simultanément. Les
solutions d’émulation existantes sont donc toutes des compromis entre ces différentes caractéristiques.
11
2.2 Outils de simulation existants
Network Simulator (NS)
NS2 [4] est un simulateur Open Source à événements discrets destiné à la simulation de
protocoles réseaux. Il permet la simulation du routage et de protocoles IP comme UDP ou
TCP sur des réseaux câblés, sans-fil ou satellites. NS2 permet de choisir le niveau d’abstraction désiré en définissant la granularité de la simulation. Il inclut également une interface
d’émulation permettant d’échanger du trafic réel entre un réseau réel et le simulateur.
Le principal inconvénient de NS2 est qu’il ne permet pas de passer correctement à l’échelle.
En effet, la seule manière de réaliser une simulation à grande échelle est de diminuer la granularité.
SimGrid
SimGrid [5] est à la fois un simulateur et un outil de développement de simulateurs à
agents ou à événements discrets. Il a principalement été conçu avec l’objectif de simuler des
applications de type grille, en mettant l’accent sur les problèmes d’ordonnancement.
MaSSF
MaSSF [6] est un simulateur de réseaux à événements discrets. Pour permettre un excellent passage à l’échelle, il utilise un moteur de simulation distribué tournant sur une
grappe. A partir d’une topologie de réseau à simuler et d’un ensemble de noeuds, MaSSF
partitionne le réseau virtuel en plusieurs blocs, assigne les blocs à des noeuds de la grappe, et
simule en parallèle. Chaque noeud de la grappe utilise un simulateur à événements discrets
et échange des événements avec les autres noeuds. Pour conserver une simulation réaliste,
les noeuds se synchronisent périodiquement.
MaSSF utilise une interface de configuration similaire à celle d’un simulateur de réseaux
écrit en Java, SSFNet. MaSSF est utilisé dans Microgrid (voir 2.3.3 page 19).
p2psim
p2psim [7] est un simulateur à événements discrets multi-threadé permettant d’étudier
des protocoles pair-à-pair. Il fait partie du projet IRIS. p2psim permet d’écrire des implémentations des algorithmes d’une manière très compréhensible et sensiblement plus condensée
que les implémentations réelles. Plusieurs protocoles sont déjà supportés par p2psim.
2.3 Outils d’émulation existants
2.3.1 Outils d’émulation réseau
On attend d’un outil d’émulation réseau les fonctionnalités suivantes :
12
– ajout de délai et de gigue suivant une distribution paramétrable (fixe, loi normale, loi
gamma) ;
– limitation de la bande passante ;
– simulation de congestion (tailles de queue limitées sur les routeurs) ;
– simulation de perte de paquets, de duplication de paquets, et de déséquencement.
Bien entendu, les autres caractéristiques attendues d’un émulateur (section 2.1 page 11)
s’appliquent également aux outils d’émulation réseau.
NIST Net
NIST Net [8] est un émulateur de réseau développé par le National Institute of Standards
and Technology. Il fonctionne sous Linux 2.4 et se place dans le noyau entre le pilote réseau
et la couche IP (figure 2.1 page suivante). Il permet d’agir sur les paquets en rajoutant du
délai et de la gigue, en limitant la bande passante, en simulant de la congestion, des pertes
de paquets et de la duplication de paquets.
Il dispose donc de toutes les fonctionnalités que nous souhaitions trouver.
Toutefois, NIST Net présente plusieurs problèmes :
– Il n’est plus activement maintenu (la dernière mise-à-jour date de 2002) ;
– Il ne fonctionne qu’avec les versions 2.0, 2.2 et 2.4 de Linux ;
– Le support SMP ne fonctionne pas avec le noyau que nous avons utilisé (2.4.27). Certaines indications font penser qu’il ne fonctionne que jusqu’à Linux 2.4.23 ;
– Il ne permet d’agir que sur les paquets entrants dans le système, et non sur les paquets
sortants.
Cette dernière limitation est très gênante : dans le cadre de l’émulation de systèmes pair à
pair, nous allons souvent souhaiter émuler de nombreuses configurations différentes. Même
si des optimisations sont possibles, le fait de ne pouvoir agir que sur les paquets entrants
oblige à avoir une règle de traitement par couple de noeud virtuel (complexité en O(n 2 )).
Cela n’est bien entendu pas souhaitable dans le cas d’un émulateur dont un des objectifs
principaux est le passage à l’échelle.
Nous avons tout de même cherché à vérifier la manière dont NIST Net passait à l’échelle.
Ces expériences ont été menées sur un bi-Xeon 2.4 GHz avec 1 Go de mémoire vive. Toutefois, un seul processeur était utilisé (noyau non-SMP) comme NIST Net ne supporte plus le
SMP. Le logiciel utilisé pour le test était un petit programme C réalisant un anneau à jeton.
Nous avons cherché à caractériser le surcoût attribuable à NIST Net (figure 2.2 page 15).
Les résultats ne sont pas encourageants, d’autant plus que, lors de nos tests, nous avons
constaté qu’il n’était apparemment pas possible de configurer plus de 260000 règles (soit le
nombre de règles nécessaires à l’émulation d’un peu plus de 500 machines, si l’on décrit la
liaison entre chaque couple de noeuds).
Netem
Écrit par Stephen Hemminger (Open Source Development Labs), Netem [9] est le successeur de NIST Net dans Linux. Intégré à Netfilter, il était initialement destiné uniquement
13
Code de l’application
User level
Kernel level
NIST Net :
Couche Socket
− interception des paquets
− sélection des paquets à
partir de règles
Couche IP
− gestion d’une horloge à
fréquence élevée basée
sur la RTC
− traitement des paquets
RTC
(perte, duplication)
− réordonnancement des
paquets
Driver réseau
Réseau
F IG . 2.1 – Architecture de NIST Net : les paquets entrants sont redirigés
au niveau du driver réseau vers NIST Net avant d’être réinjectés dans
la couche IP.
à rajouter du délai, mais il a évolué vers une solution plus complète. Il permet actuellement
d’émuler un délai variable, des pertes de paquets, de la duplication de paquets, et du réordonnancement de paquets. Il ne permet pas de faire directement de la limitation de bande
passante : pour cela, il faut utiliser les autres outils disponibles dans Netfilter.
Toutefois, il ne permet d’agir que sur les paquets sortants du système, ce qui pose les
mêmes problèmes de passage à l’échelle que NIST Net. De plus, il n’a pas encore été validé
scientifiquement.
14
8
120
Linux 2.4 avec NISTNet et 250000 regles
Linux 2.4 avec NISTNet sans regles
Linux 2.4 sans NISTNet
7
Linux 2.4 avec NISTNet et 250000 regles
Linux 2.4 avec NISTNet sans regles
Linux 2.4 sans NISTNet
100
6
80
temps (s)
temps (s)
5
4
3
60
40
2
20
1
0
100
0
200
300
400
nb de noeuds
500
600
0
200
400
600
800
1000
nb de noeuds
1200
1400
F IG . 2.2 – Passage à l’échelle de NIST Net (respectivement jusqu’à 600
et 1600 machines) : nous mesurons le temps nécessaire pour qu’un jeton
parcoure un anneau.
Dummynet
Dummynet [10] est un « shaper de trafic IP » disponible sur FreeBSD. Développé à l’origine par Luigi Rizzo pour tester des connexions TCP, il fut ensuite étendu pour supporter
tous les protocoles IP. Dummynet est intégré dans le firewall de FreeBSD IPFirewall (ipfw).
Dummynet est généralement utilisé comme limiteur/régulateur de bande passante en
sortie d’un réseau local. Ainsi, certains trafics peuvent être rendus prioritaires par rapport
à d’autres. Mais il peut aussi être utilisé comme un puissant émulateur de réseau. Il permet
d’agir sur les paquets entrants ou sortants du système :
–
–
–
–
en limitant la bande passante,
en rajoutant du délai,
en simulant des pertes de paquets,
en simulant de la congestion (les queues sont de taille limitée).
Par rapport à NIST Net, il lui manque quelques fonctionnalités :
– le délai rajouté est fixe et non variable,
– il ne permet pas de simuler de la duplication de paquets, ou du réordonnancement.
Par contre, Dummynet a été bien plus utilisé, et est donc bien mieux validé scientifiquement (voir par exemple [11]).
Delayline
Delayline [12] est un outil d’émulation au niveau applicatif. Il s’agit d’une bibliothèque
permettant d’intercepter les appels systèmes comme send() ou recv() (figure 2.3 page suivante). Delayline permet ainsi d’émuler des pertes de paquets et de rajouter du délai suivant
une certaine distribution (fixe, de loi normale, ou de loi gamma).
Delayline utilise une technique intéressante pour ajouter du délai dans les transmissions
15
1600
Code de l’application
Delayline
Bibliothèques utilisées
Routines d’appels systèmes dans la libc
Noyau
F IG . 2.3 – Delayline : les appels systèmes (send(), recv()) sont interceptés par une bibliothèque
de paquets. En effet, il n’est pas possible de manière simple de rajouter du délai lors de
l’émission des messages. Delayline déporte donc le traitement du délai au récepteur : lors
de l’émission du message, l’émetteur ajoute au message une signature indiquant quand le
message devra être délivré. Le message est ensuite transmis immédiatement au récepteur,
mais celui-ci ne le délivrera à l’application que lorsque le délai souhaité aura été écoulé.
Cette approche fonctionne très bien, avec un surcoût assez faible, et permet de réaliser
une émulation très précise. Par contre, comme nous le verrons plus loin, elle ne fonctionne
pas avec toutes les applications, et elle est compliquée à mettre en oeuvre puisqu’il faut
intercepter de nombreux appels de bibliothèque.
Interceptor
Interceptor [13] est une plate-forme d’émulation développée par Stefano Cacciaguerra
pendant sa thèse à l’université de Bologne. Interceptor simule un environnement, permettant
d’intégrer des systèmes réels (et leurs applications) dans un environnement complètement
synthétique. Interceptor est composé de 4 éléments :
– une interface d’émulation, chargée de l’échange de paquets IP entre Interceptor et des
vrais systèmes ;
– un gestionnaire d’événements basé sur un modèle de simulation déterminé ;
– un gestionnaire de topologie réseau ;
– un générateur de trafic.
L’interface d’émulation utilise directement des appels à Iptables pour détourner les paquets et les réinjecter.
16
NetBed
NetBed [14] est la suite d’Emulab, un projet qui visait à faciliter la configuration et le
contrôle d’expériences sur des topologies réseau émulées. NetBed y intègre de la simulation
et de la distribution. NetBed permet ainsi de réaliser des expériences sur des topologies
réseaux complexes en intégrant :
– des noeuds simulés à l’aide de l’interface d’émulation de Network Simulator ;
– des noeuds dont le réseau est émulé à l’aide de Dummynet ;
– des noeuds réels utilisant différents types de connexions à Internet (ADSL, cable, RTC).
WAN In Lab
WAN In Lab [15] est un projet commun au Caltech et à la société Cisco. À mi-chemin
entre système réel et émulation, ce projet a pour but de créer un environnement d’expérimentation en réseau à l’échelle planétaire, contenant des équipements très divers allant de
périphériques Bluetooth aux plus gros routeurs Cisco. WAN In Lab permet de faire des expériences reproductibles dans un environnement paramétrable et évolutif. La surveillance
totale du réseau permet de détecter et résoudre des problèmes facilement.
2.3.2 Outils d’émulation de système
User Mode Linux
User Mode Linux (UML) [16] est un portage du noyau Linux vers une autre architecture : un processus Linux. Avec User Mode Linux, le noyau du système émulé est en fait
représenté sur le système hôte par un ou plusieurs processus. Une machine virtuelle UML
fonctionne d’une manière totalement transparente pour l’utilisateur, et est capable de faire
tourner exactement les mêmes processus que le système hôte. Un utilisateur n’a pas besoin
de privilèges particuliers pour faire tourner une machine virtuelle UML. D’une manière interne, UML fonctionne en interceptant tous les appels systèmes à l’aide de ptrace(). Au lieu
de laisser le système hôte exécuter l’appel système lui-même, UML l’exécute directement.
UML utilise son propre système de mémoire virtuelle, et a son propre ordonnanceur.
Malheureusement, la surcharge induite par User Mode Linux rend cette solution difficilement utilisable dans le cadre d’un émulateur léger : le nombre de machines émulées
serait trop faible. De plus, User Mode Linux est encore en plein développement, et a montré
quelques problèmes d’instabilité.
VServer
VServer [17] est un patch du noyau Linux lui ajoutant la gestion de Security Contexts,
qui permettent de diviser l’ensemble des processus en classes. On assigne à chaque système
virtuel VServer un context différent.
Les contextes permettent de cacher les processus qui ne sont pas dans le même contexte
et d’interdire les interactions entre processus de contextes différents. Concernant le réseau,
17
VServer permet de lier un contexte à une adresse IP particulière.
Benjamin Quétier a montré dans Emugrid [18] que VServer était bien adapté à la réalisation d’un émulateur de grappes ou grilles. Mais son support de l’équité entre systèmes
virtuels reste limité, et insuffisant dans le cadre de l’émulation de systèmes pair-à-pair, où
on souhaite pouvoir émuler des environnements très différents avec précision.
Xen
Xen [19] est un système de virtualisation libre développé par l’université de Cambridge,
ayant pour objectif de faire tourner jusqu’à 100 systèmes d’exploitation complets sur un seul
ordinateur. Les systèmes d’exploitation doivent être modifiés (portés) pour fonctionner audessus de Xen (figure 2.4). Cette technique, appelée para-virtualisation, permet d’obtenir
d’excellentes performances (surcoût de l’ordre de 8% dans le pire cas).
Logicels de controle Xen
Xeno−Linux
Drivers Xen
User−space
Linux
Drivers Xen
User−space
FreeBSD
Drivers Xen
Xen
Matériel
F IG . 2.4 – Architecture de Xen : les systèmes d’exploitation émulés
doivent être modifiés pour fonctionner au-dessus d’une architecture
spécifique.
Un support de la virtualisation au niveau du processeur (comme dans les systèmes LPAR
d’IBM, ou les projets Vanderpool d’Intel et Pacifica d’AMD) permet de faire tourner des
systèmes sans modification, et avec un surcoût moindre.
2.3.3 Outils d’émulation de systèmes distribués
ModelNet
ModelNet [20] est un système d’émulation permettant de déployer des applications non
modifiées dans un environnement d’émulation paramétrable reprenant les caractéristiques
d’Internet. Modelnet partitionne les machines disponibles en deux groupes (figure 2.5 page
ci-contre) :
– Les edge nodes exécutent un certain nombre d’instances de l’application cible sur un
système d’exploitation laissé au choix de l’utilisateur. Chaque instance est appelée un
virtual edge node.
– Les ModelNet core nodes coopèrent pour soumettre le trafic à des contraintes de bande
passante, de latence et de perte de paquets.
Les auteurs de ModelNet se sont intéressés à différentes techniques permettant de réaliser un compromis entre exactitude et coût. En effet, ModelNet permet d’effectuer une ému18
Edge nodes
SWITCH
Modelnet Core
SWITCH
F IG . 2.5 – Architecture de Modelnet : les noeuds disponibles sont utilisés pour exécuter l’application cible (edge nodes ) ou pour émuler une
topologie réseau complexe (Modelnet core ).
lation extrêmement précise d’Internet avec un nombre de noeuds importants dans le ModelNet core.
Mais si on dispose d’un nombre plus faible de noeuds, on peut simplifier la topologie du
réseau lors de la phase de Distillation. On crée alors un maillage entre certains noeuds du
Modelnet core pour réduire le nombre de sauts nécessaires.
MicroGrid
MicroGrid [21] est un émulateur de grilles statiques permettant d’émuler des applications Globus sans modification.
Un premier problème est de virtualiser l’identité de la machine. Les appels de bibliothèque comme gethostbyname, bind, send, receive sont donc interceptés. La simulation des
ressources processeur se fait à l’aide d’un ordonnanceur round-robin, les tranches de temps
étant calculées en fonction de la vitesse de simulation désirée.
Concernant l’émulation réseau, deux approches ont été explorées. Tout d’abord, NS2
19
(voir 2.2 page 12) a été essayé, mais il ne permettait pas de passer à l’échelle correctement.
MaSSF [6] a alors été développé (voir 2.2 page 12).
D’une manière générale, MicroGrid se distingue des autres solutions d’émulation par
son soucis de conserver un réalisme très important au détriment du coût de l’émulation. Il
s’agit d’une approche à mi-chemin entre simulation et émulation.
2.4 Systèmes réels dédiés à l’expérimentation
PlanetLab
PlanetLab [22] est une plate-forme globalement distribuée d’environ 500 noeuds permettant de développer et déployer des services à l’échelle planétaire. Les noeuds de PlanetLab sont virtualisés à l’aide de VServer et Xen. Toutefois, sa taille limitée et la nonreproductibilité des expériences liée à son architecture dynamique peut poser problème pour
certaines expériences.
Grid5000
Grid5000 [23] est un projet visant à créer une plate-forme de grille expérimentale rassemblant 10 laboratoires français, permettant de réaliser des expériences à tous les niveaux, des
protocoles réseaux aux applications en passant par les middlewares pour grilles.
L’objectif à court terme est d’assembler une plate-forme physique rassemblant 9 grappes,
chacune comprenant de 100 à un millier de PCs, connectés par le réseau Renater. Cette plateforme inclut Grid Explorer, un instrument dédié à l’expérimentation de 500 processeurs.
Toutes les grappes sont connectées entre elles par un réseau gigabit.
20
Chapitre 3
P2PLab : un système d’émulation léger
La plupart des systèmes d’émulation existants tentent de parvenir à une émulation très
précise, au détriment du nombre de machines émulées (figure 3.1). Nous allons explorer
quelques voies permettant d’obtenir une émulation un peu moins précise, mais à un coût
beaucoup plus faible, afin d’obtenir une émulation plus efficace (meilleur rapport nombre
de machines émulées / nombre de machines physiques).
log(coût)
Vrais systèmes
Vraies applications
Plateformes de laboratoire
Conditions synthétiques
Modélisation des :
Systèmes
Applications
Plateformes
Conditions
Vrais systèmes
Vraies applications
Vraies plateformes
Vraies conditions
Mécanismes clés des systèmes (Algorithmes...)
Plateformes virtuelles
Conditions synthétiques
log(réalisme)
Modélisation
mathématique
Simulation
Émulation
Systèmes réels
F IG . 3.1 – Modélisation, simulation ou émulation : un compromis entre
réalisme et coût
21
3.1 Particularités de l’émulation des systèmes pair-à-pair
Au chapitre précédent, nous avons présenté les solutions d’émulation de systèmes distribués en général, et en particulier les solutions ciblant l’émulation d’applications sur grilles
de calcul. La problématique est un peu différente lorsqu’on s’intéresse à l’émulation des systèmes pair-à-pair.
3.1.1 Impact sur le système
Les applications de type grille ont en général un déploiement compliqué et sont très
dépendantes de leur environnement (bibliothèques utilisées, version du noyau, ...). Pour
émuler ce genre d’applications, la solution la plus simple est donc souvent d’émuler l’environnement d’un système entier, noyau compris.
Les applications pair-à-pair, au contraire, sont moins intrusives, car conçues pour être
déployées à travers le monde dans des environnements très hétérogènes. Ces applications
sont en général contenues dans un seul processus, et émuler l’environnement de ce processus
est suffisant.
3.1.2 Aspects réseaux
Les grilles de calcul disposent en général d’une très bonne connectivité entre elles (latence faible et débit important). Il est donc nécessaire d’émuler précisément les connexions
entre les grappes.
Dans le cas des réseaux pair-à-pair, les noeuds sont situés sur des ordinateurs personnels,
sur les bords d’Internet [24], avec une connectivité relativement faible (latence assez importante et débit peu important, par rapport aux débits disponibles dans le coeur d’Internet)
(figure 3.2).
Internet Core
Edges
F IG . 3.2 – Les noeuds de systèmes pair-à-pair sont en général situés en
bordure d’Internet
22
On peut aussi traiter séparément deux caractéristiques des réseaux à émuler :
– le débit disponible, qui est spécifique à un noeud ;
– la latence, qui est souvent commune à un ensemble de noeuds (par exemple, tous les
noeuds du fournisseur d’accès A par rapport aux noeuds du fournisseur d’accès B, ou
tous les noeuds européens par rapport aux noeuds d’Amérique du Nord)
3.1.3 Applications limitées par le processeur ou par le réseau
Les applications pair-à-pair peuvent être séparées en deux catégories :
– les applications qui sont limitées par le temps processeur disponible (les applications
de Global Computing, par exemple) ;
– les applications qui sont limitées par les caractéristiques du réseau (débit ou latence).
Les applications limitées en même temps par ces deux critères sont très rares : dans le
cadre de l’émulation, il est envisageable de distinguer ces deux cas afin de leur appliquer un
traitement différent.
3.2 P2PLab : présentation générale
P2PLab a pour objectif de fournir une émulation légère (très bon rapport nombre de
noeuds virtuels / nombre de noeuds physiques) sans trop sacrifier le réalisme de l’émulation. P2PLab fonctionne sur FreeBSD, qui a l’avantage de disposer d’outils d’émulation
reconnus (Dummynet), et d’être assez simple à prendre en main et à modifier.
Contrairement à beaucoup d’autres systèmes d’émulation, P2PLab se place au niveau
processus :
– Comme nous l’avons montré précédemment, c’est suffisant dans le cadre des systèmes
pair-à-pair.
– Cela permet un gain d’efficacité important, puisque nous n’avons pas besoin d’exécuter un noyau par noeud virtuel : il n’y a qu’un seul noyau par noeud physique.
L’affectation d’une adresse réseau à chaque noeud virtuel se fait par l’utilisation d’interfaces réseau aliasées. Chaque noeud virtuel dispose d’une interface d’alias, et donc d’une
adresse IP sur le réseau d’expérimentation (figure 3.3 page suivante).
3.3 Émulation du réseau avec P2PLab
Comme ModelNet [20], P2PLab utilise Dummynet [10] pour réaliser l’émulation du réseau. Mais Dummynet est utilisé d’une manière différente. Nous avons vu (voir 3.1.2 page
ci-contre) que le facteur limitant, dans le cadre des systèmes pair-à-pair, était presque toujours la connexion entre le noeud et le coeur de l’Internet (représenté par son fournisseur
d’accès) (figure 3.2 page précédente). Avec P2PLab, nous déportons donc l’émulation du
réseau sur les noeuds physiques.
23
Noeud 1
eth0
192.168.38.2
10.0.0.51 (alias)
10.0.0.52 (alias)
10.0.0.53 (alias)
...
10.0.0.100 (alias)
eth0
192.168.38.1
10.0.0.1 (alias)
10.0.0.2 (alias)
10.0.0.3 (alias)
...
10.0.0.50 (alias)
Noeud 2
192.168.38.3
10.0.0.101 (alias)
10.0.0.102 (alias)
10.0.0.103 (alias)
...
10.0.0.150 (alias)
eth0
Noeud 3
SWITCH
(...)
F IG . 3.3 – Utilisation d’interfaces aliasées
D’une part, nous agissons alors sur le débit et les caractéristiques de fiabilité de la ligne
(perte de paquets). Notre approche ne permet pas de considérer les problèmes de débit et de
congestion dans le coeur d’Internet. Cette simplification permet d’obtenir un meilleur passage à l’échelle, et on peut considérer que, dans le cas des systèmes pair-à-pair, les problèmes
de congestion se manifestent la plupart du temps sur le lien liant le noeud à son fournisseur
d’accès.
D’autre part, nous agissons sur la latence. Une partie de la latence est spécifique au lien
entre le noeud et son fournisseur d’accès, et nous la traitons en même temps que le débit.
Mais une autre partie de la latence est liée à la localisation du noeud sur Internet.
Cette latence n’est pas négligeable dans le cadre des réseaux pair à pair : ainsi, certains
réseaux tentent d’en déduire une notion de localité [25]. Ils utilisent la distance par rapport à certains serveurs de référence pour déterminer la position du système sur Internet, et
évaluer la distance de ce système à d’autres systèmes. Pour émuler cette latence, nous considérons des sous-ensembles de l’ensemble des noeuds (par exemple, tous les noeuds d’un
fournisseur d’accès, ou tous les noeuds européens par rapport aux noeuds américains).
Notre approche ne permet pas de représenter les problèmes de congestion au sein du
coeur d’Internet, mais le fait que l’émulation réseau soit déportée sur chaque noeud a d’autres
avantages. Chaque noeud physique est alors chargé de l’émulation réseau de ses noeuds
virtuels, ce qui permet un passage à l’échelle très facile (nous n’avons pas besoin de dimensionner conjointement la partie de l’émulateur chargée du réseau, et celle chargée de la
virtualisation.
24
D’un point de vue pratique, nous ajoutons sur chaque noeud physique les règles Dummynet prenant en charge l’émulation réseau (paquets émis et reçus) pour les noeuds virtuels
de ce noeud physique ( 3.4).
Noeud
Virtuel 3.2
Noeud
Virtuel 3.1
Noeud Physique 3
Noeud Physique 1
Noeud Physique 2
Noeud Virtuel 1.1
Noeud Virtuel 2.1
Noeud Virtuel 1.2
Noeud Virtuel 2.2
Filtrage Dummynet en entrée
Filtrage Dummynet en sortie
F IG . 3.4 – Traitement des paquets par Dummynet dans P2PLab
3.4 Affectation d’adresses IP aux processus
Avec P2PLab, les noeuds virtuels sont des processus. Il est donc nécessaire d’avoir la
possibilité de forcer un processus à utiliser une adresse IP, et non celle par défaut du système,
pour toutes les communications. La figure 3.5 page suivante présente les différents appels
systèmes réseaux et l’ordre dans lesquels ils peuvent être appelés. Si un bind() est fait avant
un connect(), c’est l’adresse du bind() qui est utilisée comme adresse source de la connexion.
Plusieurs approches sont possibles pour forcer une application à utiliser une IP définie.
Modifier l’application
Une première approche consister à modifier l’application pour la forcer à toujours faire
un bind() avec l’adresse souhaitée. Ce n’est pas une approche intéressante, car elle nécessite
d’avoir le code de l’application, de la modifier et de la recompiler.
Lier l’application avec une bibliothèque
Une autre possibilité est de lier l’application avec une bibliothèque qui redéfinit les appels systèmes à modifier. C’est l’approche utilisée par Delayline [12] et des outils de débo25
socket()
bind()
sendto(), recvfrom(),
sendmsg(), recvmsg()
connect()
listen()
accept()
F IG . 3.5 – Enchaînement des appels systèmes réseaux
guage comme ElectricFence. La bibliothèque peut être liée à la compilation (cas de Delayline)
ou à l’exécution (cas d’ElectricFence) en utilisant la variable d’environnement LD_PRELOAD.
Cette approche est intéressante, car elle ne nécessite pas de modifier l’application, ni
d’avoir son code source. Mais elle a des limites : le chargeur (ld) charge la bibliothèque d’interception directement au-dessous de l’application, mais au-dessus des autres bibliothèques
éventuellement utilisées. Ainsi, si l’application fait appel à une librairie qui fait elle-même
les appels systèmes (figure 3.6), les appels systèmes réseaux ne peuvent pas être interceptés.
Pour que cette approche fonctionne dans un cadre plus général, il faudrait donc modifier le
chargeur ld.
Application
Bibliothèque d’interception
Application
libnet_connect()
libnet_connect()
libnet
libnet
connect()
connect()
noyau
noyau
F IG . 3.6 – Interception par une bibliothèque : l’appel à connect() n’est
pas intercepté, seul l’appel à libnet_connect() est vu par la bibliothèque
26
Modifier le noyau
Modifier le traitement des appels systèmes dans le noyau. Cette approche est la plus
difficile à mettre en oeuvre, mais elle fonctionne parfaitement avec toutes les applications.
Utiliser ptrace()
L’appel système ptrace() permet à une application d’en surveiller une autre, et notamment d’intercepter les appels systèmes. C’est l’approche utilisée par User Mode Linux. Cette
approche fonctionne avec toutes les applications sans avoir à les modifier, mais a un surcoût
relativement important à cause des changements de contexte nécessaires.
Modifier la bibliothèque C
Modifier la bibliothèque C (libc). Cette approche permet de se placer « au-dessous » des
bibliothèques éventuelles. Son seul inconvénient est qu’elle ne fonctionne pas avec les exécutables compilés statiquement.
C’est la modification de la bibliothèque C que nous avons retenu pour P2PLab. En effet, il
nous a semblé que cette approche était le meilleur compromis entre complexité et efficacité.
27
28
Chapitre 4
Évaluation de l’émulation avec P2PLab
4.1 Étude de la faisabilité
Dans un premier temps, nous avons cherché à vérifier que FreeBSD disposait de caractéristiques suffisantes pour notre émulateur en utilisant les métriques de performance proposées dans [26] : linéarité lors du passage à l’échelle, équité et surcoût de l’émulation.
4.1.1 Passage à l’échelle du nombre de processus
FreeBSD 5 dispose de deux ordonnanceurs différents :
– un ordonnanceur historique (appelé 4BSD) [27] dérivé de celui de BSD 4.3 ;
– Un ordonnanceur plus moderne, ULE [28] (il s’agit d’un jeu de mots, la directive de
compilation pour l’activer dans le noyau étant SCHED_ULE).
ULE est inspiré des avancées faites dans l’ordonnanceur de Linux 2.6, notamment en
matière d’interactivé, de passage à l’échelle (ordonnancement en O(1)) et du support de plusieurs processeurs ou de processeurs avec Symetric Multi-Threading (migrations inutiles de
processus d’un processeur à un autre évitées, par exemple). Mais il n’est pas encore considéré par l’équipe de développement de FreeBSD comme utilisable en production.
Pour vérifier l’aptitude au passage à l’échelle, nous avons exécuté simultanément un
nombre variable d’instances d’un même programme calculant la fonction de Ackermann
(calcul intensif en processeur, mais peu coûteux en mémoire) et mesuré le temps nécessaire
à la terminaison de toutes les instances. Les résultats obtenus (figure 4.1 page suivante) sur
un bi-P4 Xeon 2.4 Ghz doté de 2 Go de mémoire vive montrent que le passage à l’échelle
du nombre de processus est correct à la fois avec l’ordonnanceur 4BSD et l’ordonnanceur
ULE : le temps nécessaire à la terminaison des tâches croît linéairement, sans qu’on puisse
constater un surcoût lié au nombre de processus actifs.
Sur cette première expérience, il est important de noter que la mémoire utilisée par
chaque instance était très faible. Nous avons donc ensuite réalisé une expérience similaire,
mais avec un programme effectuant des opérations sur des matrices dont chaque instance
occupe 50 Mo en mémoire. Dans ce cas, on constate que dès que la mémoire virtuelle com29
1600
Mesure (4BSD)
Mesure (ULE)
1400
1200
temps (s)
1000
800
600
400
200
0
0
500
1000
1500
nb d’instances
2000
2500
3000
F IG . 4.1 – Passage à l’échelle du nombre de processus. Les processus
effectuent un calcul long mais peu coûteux en mémoire.
mence à être utilisée, les performances chutent énormément (figure 4.2) et les résultats deviennent très instables (intervalles de confiance plus larges pour un même nombre d’expériences). Il sera donc important par la suite de définir le nombre de noeuds virtuels sur
chaque noeud physique en fonction de l’occupation mémoire de chaque noeud virtuel, afin
d’éviter l’utilisation de mémoire virtuelle qui pourrait fausser les résultats.
60
2000
Mesure
Mesure
1800
50
1600
1400
temps (s)
temps (s)
40
30
20
1200
1000
800
600
400
10
200
0
0
0
5
10
nb d’instances
15
20
0
10
20
30
40
50
nb d’instances
F IG . 4.2 – Passage à l’échelle du nombre de processus avec forte utilisation de la mémoire
30
60
70
80
4.1.2 Équité entre processus
Dans le cadre d’un émulateur au niveau processus, il est bien sûr nécessaire d’avoir un
ordonnanceur ayant de bonnes propriétés d’équité. Par exemple, plusieurs processus démarrés en même temps et effectuant la même tâche doivent avancer presque en même temps et
terminer presque en même temps.
Il est aussi important de pouvoir spécifier des conditions d’expérience particulières, comme
par exemple une expérience avec un processeur rapide (processus à haute priorité, donc
pouvant effectuer beaucoup de traitements) et un processeur lent (processus à faible priorité,
donc ne pouvant effectuer que peu d’opérations). Ce genre de comportement doit pouvoir
être décrit précisément, par exemple en utilisant les priorités des processus Unix.
Pour vérifier que les ordonnanceurs de FreeBSD étaient équitables, nous avons réalisé
une première expérience. À intervalles fixes (1 seconde), nous démarrons un processus qui
effectue un calcul prenant une dizaine de secondes lorsque le processus est le seul à être
exécuté. Nous mesurons le temps réel mis pour effectuer le traitement par chaque processus.
Idéalement, après une période de démarrage, le calcul devrait prendre le même temps pour
tous les processus. Pour éviter que le grand nombre de processus influence le comportement
du processus chargé de créer les autres processus, nous le rendons très prioritaire par rapport
aux processus créés.
1200
Scheduler ULE
Scheduler 4BSD
Linux 2.6
1000
temps d’execution (s)
800
600
400
200
0
0
10
20
30
40
50
60
numero d’instance
70
80
90
100
F IG . 4.3 – Équité inter-processus dans l’accès au processeur. Les processus effectuent un calcul prenant une dizaine de secondes, et sont
démarrés avec une seconde d’intervalle.
Les résultats sont présentés dans la figure 4.3. Nous avons fait cette expérience sur un
bi-P4 Xeon à 2.4 GHz sous Linux 2.6 et avec les deux ordonnanceurs de FreeBSD, 4BSD et
ULE. Nous avons pu expliquer la différence de performance entre Linux et FreeBSD par
31
une régression dans le compilateur GCC (des versions différentes de GCC étaient utilisées
sur les deux systèmes). Nous constatons que 4BSD et Linux 2.6 ont des propriétés d’équité
similaires. Par contre, ULE pose de gros problèmes. Les temps d’exécution des processus
sont très différents, et certains processus (ceux dont les numéros sont multiples de 12) sont
très fortement favorisés (comme s’ils s’exécutaient seuls sur le système).
Si l’utilisation d’ULE est donc à exclure, tout n’est pas parfait avec 4BSD : le temps d’exécution varie assez fortement entre les instances. Cela pourrait s’expliquer par le paramétrage du quantum : le temps processeur alloué à un processus avant de passer au processus
suivant. Un quantum plus faible devrait donc améliorer l’équité entre processus. Mais la figure 4.4 montre que diminuer cette durée n’améliore pas sensiblement l’équité, en dégradant
assez fortement les performances.
1600
temps d’execution (s)
1400
1200
1000
800
Quantum 1ms
Quantum 10ms
Quantum 100ms
Quantum 1s
600
400
0
20
40
60
numero d’instance
80
100
Quantum
1ms
10ms
100ms
1s
Moyenne
1437s
843s
801s
781s
Variance
15.7
17.1
16.9
15.6
F IG . 4.4 – Influence du Quantum sur l’équité inter-processus avec l’ordonnanceur 4BSD
Ces résultats décevants étaient prévisibles, car les ordonnanceurs génériques comme
ceux de FreeBSD ou Linux ont d’autres objectifs que l’équité :
– un algorithme efficace pour choisir le prochain processus à exécuter (O(1) dans le cas
de Linux et FreeBSD) ;
– une réponse très rapide aux processus interactifs, même si le système est très chargé ;
– une bonne prévention des problèmes de famine ;
– un fonctionnement efficace dans le cas d’architectures SMP.
Dans le cas de FreeBSD, l’ordonnanceur gère également une partie du modèle de threads,
où les threads sont regroupés en Kernel-scheduled entities [29] pour implémenter des Scheduler Activations. Cela le rend très complexe à comprendre et à modifier.
Une solution permettant d’obtenir une meilleure équité inter-processus et un contrôle
plus fin du temps alloué à chaque processus serait de réaliser un ordonnanceur FIFO avec
priorités. Cela devrait être facilement réalisable sous Linux, l’ordonnanceur étant très bien
documenté [30], et des travaux similaires ayant déjà été menés [31]. Il faudrait également
gérer le cas de processus multi-threadés : l’équité doit être assurée entre les processus, pas
au niveau des threads.
32
4.2 Émulation du réseau
Pour émuler le réseau, nous utilisons Dummynet (voir 3.3 page 23). Cela nécessite de
recompiler le noyau de FreeBSD pour en activer le support, et de réduire la durée des timeslices de 10ms à 1ms (paramétrage du HZ) pour permettre une émulation précise. Le surcoût
se décompose donc en 3 éléments :
– le surcoût provoqué par le passage dans Dummynet. Nous avions vu avec NIST Net
qu’il n’est pas forcément nul ;
– le surcoût causé par le passage de HZ=100 Hz à HZ=1000 Hz ;
– le surcoût causé par l’examen des règles du firewall ipfw.
7
60
Sans Dummynet, HZ=100
Avec Dummynet, HZ=100
Avec Dummynet, HZ=1000
6
Sans Dummynet, HZ=100
Avec Dummynet, HZ=100
Avec Dummynet, HZ=1000
Avec Dummynet et regles, HZ=1000
50
5
temps (s)
temps (s)
40
4
3
30
20
2
10
1
0
0
0
500
1000
1500
nb de noeuds
2000
2500
0
500
1000
1500
nb de noeuds
2000
F IG . 4.5 – Surcoût provoqué par Dummynet, HZ=1000, et le parcours
des règles
Pour déterminer ces surcoûts, nous avons réutilisé le programme de test réalisant un anneau à jetons en C que nous avions déjà utilisé pour NIST Net. La figure 4.5 montre que les
surcoûts provoqués par HZ=1000 et Dummynet sont négligeables. Par contre, celui provoqué par l’examen des règles est très important. En effet, nous ajoutons une règle par noeud,
et l’ensemble des règles est toujours parcouru linéairement. IPFW n’a probablement pas été
développé dans le but d’utiliser des milliers de règles.
Il serait intéressant de modifier IPFW pour optimiser le parcours des règles, en rajoutant
la possibilité de faire des parcours arborescents ou de choisir une règle à l’aide d’une table
de hachage.
4.3 Affectation d’adresses IP aux processus
Afin de pouvoir affecter une adresse IP à un processus, nous avons choisi de modifier
la bibliothèque C (voir 3.4 page 25). Pour évaluer ce choix, nous avons modifié la libc de
FreeBSD pour modifier le comportement des appels systèmes bind(), listen() et connect().
Nous avons d’abord utilisé une approche naïve :
33
2500
– Lorsqu’une application fait un bind(), on modifie le paramètre my_addr pour limiter le
bind() à l’adresse IP spécifiée dans la variable d’environnement BINDIP.
– Lorsqu’une application fait un connect(), on fait un bind() avant pour limiter le connect()
à l’adresse IP de BINDIP. Le bind() échouera si un bind() a déjà été fait avant de manière
explicite, mais on ignore l’erreur dans ce cas.
– Lorsqu’une application fait un listen(), comme pour le connect(), on fait un bind() avant
pour s’assurer que le listen() est bien limité à l’adresse désirée. Si bind() échoue, on
ignore son erreur.
Cette première implémentation est a priori très inefficace (nombre d’appels systèmes
doublé pour les connect() et les listen().) De plus, elle ne permet de traiter que les connexions
TCP. Une modification similaire est possible pour l’UDP.
Nous avons d’abord vérifié que cette technique par modification de la libc fonctionnait
avec des programmes de test en Perl, Python, Ruby, TCL, C (compilé avec gcc sans l’option -static) et Java (avec le JDK 1.4 de Sun). Par contre, cette approche ne fonctionne pas
avec les programmes en C compilés statiquement (avec -static). C’est logique, puisque les
programmes compilés statiquement n’utilisent pas la libc du système.
Puis nous avons cherché à mesurer le surcoût de cette technique. Pour cela, nous avons
réalisé un programme de test très simple : un client TCP qui se connecte sur un serveur
tournant sur la même machine. Dès que la connexion a été acceptée par le serveur, le serveur coupe la connexion. Puis le cycle recommence : le client se reconnecte. En exécutant ce
test un nombre important de fois, nous avons pu mesurer avec un intervalle de confiance
satisfaisant que la durée d’un cycle était de 10.22µs sans la modification de la libc, et de
10.79µs avec la modification de la libc. Il faut noter que ce surcoût n’est présent que lors de
l’établissement de la connexion. Notre test montre que, même dans un cas limite (application passant tout son temps à établir des connexions), ce surcoût reste très limité comparé
comparé au temps nécessaire pour établir une connexion.
34
Chapitre 5
Émulation avec P2PLab : expériences
5.1 Émulation d’une topologie réseau complexe
Dans une première expérience, nous avons cherché à montrer que P2PLab permettait
d’émuler des topologies suffisamment complexes pour la plupart des expériences, notamment pour pouvoir étudier le fonctionnement de réseaux pair-à-pair utilisant une notion de
localité [25] sur Internet. Nous avons donc écrit une petite application permettant, à partir
d’une topologie réseau et d’un ensemble de machines physiques, de générer les règles IPFirewall et Dummynet nécessaires pour émuler ce réseau. Nous avons testé ce programme
avec la topologie présentée en figure 5.1 page suivante, en répartissant les 2750 noeuds sur
16 machines de GridExplorer. Puis nous avons réalisé l’équivalent de pings en TCP entre
différents noeuds du réseau émulé.
Les résultats de ces pings sont présentés dans la figure 5.2 page suivante, et les valeurs
constatées sont bien celles attendues. Par exemple, entre 10.1.2.100 et 10.3.1.69, nous mesurons un ping de 1.31s. Ce délai se décompose ainsi :
– 40ms entre 10.1.2.100 et son fournisseur d’accès à Internet (représenté par la classe
10.1.2.0/24) ;
– 600ms entre l’ensemble des noeuds de la classe 10.1.0.0/16 et les noeuds de la classe
10.3.0.0/16 (équivalent à une liaison entre un fournisseur d’accès européen et un fournisseur d’accès d’un autre continent, par exemple) ;
– 10ms entre le fournisseur d’accès de 10.3.1.69 et lui-même ;
– 10ms + 600ms + 40ms = 650ms pour l’envoi du paquet retour.
Soit un total de 1300ms, proche de la mesure relevée.
5.2 Étude de BitTorrent
5.2.1 Introduction
BitTorrent [32] est un système pair-à-pair de distribution de fichiers, comme Kazaa, Gnutella ou Freenet. Il est actuellement responsable d’une part non négligeable du trafic sur
Internet [33]. Mais contrairement à la plupart des autres systèmes, qui incluent un système
35
10.2.0.0/16
latence : 5ms
bande passante : 10 Mbps
400ms
1000 noeuds
10.1.0.0/16
100ms
10.1.1.0/24
latence : 100ms
bande passante :
56kbps/33.6kbps
250 noeuds
10.1.2.0/24
latence : 40ms
bande passante :
512 kbps/128kbps
250 noeuds
1s
100ms
10.1.3.0/24
latence : 20ms
bande passante :
8 Mbps/1Mbps
250 noeuds
100ms
600ms
10.3.0.0/16
latence : 10ms
bande passante : 1 Mbps
1000 noeuds
F IG . 5.1 – Topologie réseau émulée
Source
10.1.1.137
10.1.1.105
10.1.1.205
10.1.1.199
10.1.1.84
10.1.2.220
10.1.2.219
10.1.2.70
10.1.2.100
10.1.3.108
10.1.3.207
10.1.3.116
10.2.0.51
10.2.1.139
10.3.3.181
Destination
10.1.1.228
10.1.2.148
10.1.3.204
10.2.2.224
10.3.0.66
10.1.2.4
10.1.3.38
10.2.3.87
10.3.1.69
10.1.3.9
10.2.2.113
10.3.0.169
10.2.3.48
10.3.1.183
10.3.0.133
Temps (A/R)
462ms
522ms
476ms
1.05s
1.46s
173ms
329ms
899ms
1.31s
84ms
853ms
1.26s
23ms
2.03s
43ms
F IG . 5.2 – Résultat de pings entre des noeuds du réseau émulé
36
de recherche de fichiers, BitTorrent est uniquement un système de distribution de fichiers et
ne prend pas en charge la recherche parmi l’ensemble des fichiers disponibles.
Trois entités sont nécessaires lors de la distribution d’un fichier par BitTorrent [34] :
– un site web où l’utilisateur pourra récupérer un fichier .torrent. Ce fichier de petite
taille (quelques Ko) contient l’adresse du tracker et les sommes de contrôle des différentes parties du fichier (ou chunks ) ;
– un tracker, qui distribue aux clients des listes d’autres clients ;
– un ensemble de clients (peers ) voulant récupérer le fichier. Si ces clients ont déjà obtenu
une copie complète du fichier, ils sont appelés seeders.
Après avoir récupéré une liste de peers sur le tracker, un client se connecte à tous les
peers reçus et échange des informations sur les chunks déjà reçus.
Ensuite, un mécanisme de réciprocité efficace [35] se met en place entre les clients afin
d’éviter le free riding [36] (l’utilisation égoïste du système pair-à-pair, sans y contribuer).
Bittorrent a déjà fait l’objet de nombreuses études. Des traces de téléchargements ont été
analysées ([37], [38], [39]). Certains ont cherché à le modéliser mathématiquement [40] tandis
que d’autres l’ont simulé [41], et de nombreuses propositions ont été faites pour améliorer le
protocole et le rendre plus robuste ([41] par exemple).
5.2.2 Validité des résultats
Nous avons d’abord cherché à comprendre quelles étaient les limites de notre approche.
Pour cela, nous avons réalisé un téléchargement entre un seeder et 158 noeuds. Les débits
alloués sont de 2 Mbps (descendant) et 1 Mbps (montant). Le tracker et le seeder sont démarrés au début de l’expérience, puis un client est démarré toutes les 5 secondes.
Nous avons répartis ces 160 noeuds (un tracker, un seeder, 158 clients) sur des machines
de GridExplorer (bi-Opteron 2 Ghz, 2 Mo de RAM). Nous avons d’abord mis 10 noeuds
par machine, puis 20 noeuds par machine, puis 32 noeuds par machine, puis 40 noeuds par
machine. Pour chaque expérience, nous mesurons la quantité totale de données reçues par
l’ensemble des clients. Les résultats sont présentés en figure 5.3 page suivante. Par manque
de temps, nous n’avons pas calculé d’intervalles de confiance. Les résultats obtenus avec 10
et 20 noeuds par machine sont très proches. Avec 32 noeuds par machine, une légère dérive
apparaît. Avec 40 noeuds, elle est bien plus importante.
5.2.3 Passage à l’échelle
Nous avons ensuite vérifié que notre approche passait correctement à l’échelle. Nous
avons réalisé un téléchargement de fichiers dans les mêmes conditions que ci-dessus, mais
avec 512 noeuds répartis sur 16 machines à raison de 32 noeuds par machine, les clients étant
lancés avec 2 secondes d’intervalle. Le taux de complétion du transfert sur chaque client est
indiqué en figure 5.4 page 39.
37
quantite totale de donnees recues sur les clients (Mo)
8000
7000
6000
5000
4000
3000
2000
1000
10 clients par noeud
20 clients par noeud
32 clients par noeud
40 clients par noeud
0
0
200
400
600
temps (s)
800
1000
1200
F IG . 5.3 – Transfert de fichiers avec BitTorrent : différents niveaux de
virtualisation
5.2.4 Super-seeding et autres techniques pour accélérer la diffusion
Un facteur limitant très important est la bande passante du seeder, surtout lorsqu’il n’y
en a qu’un seul, et qu’il a une bande passante assez limitée. En effet, les noeuds ne peuvent
uploader que les chunks qu’ils ont entièrement reçu. Il est donc important de distribuer
rapidement des chunks entiers aux autres clients.
Initialement, les clients souhaitant télécharger demandent un bloc au hasard parmi tous
les blocs disponibles sur le seeder. Du coup, le seeder peut être contraint de diffuser le même
bloc à deux clients différents, ce qui est contre-productif.
BitTornado, un client BitTorrent, propose une solution à ce problème : le Super-seeding.
Plutôt que de s’afficher comme un seeder (possédant tous les blocs), le seeder s’affiche
comme un client classique, et ne présente aux autres clients que les blocs qu’il souhaite leur
envoyer. Ainsi, il peut s’assurer que chaque bloc va être distribué avec la même fréquence,
et en particulier, au début, distribuer une fois chaque bloc à d’autres clients avant de commencer à les renvoyer vers d’autres clients.
Nous avons comparé cette approche avec d’autres approches en réalisant le transfert
d’un fichier de 50 Mo à partir d’un seul seeder, avec 320 noeuds répartis sur 16 machines
à raison de 20 noeuds par machine. Chaque noeud dispose d’une connexion à 2 Mbps en
download, et de 1 Mbps en upload. Les résultats obtenus sont présentés en figures 5.5 page 40
et 5.6 page 40.
Notre expérience n’a pas permis de mettre en évidence un avantage apporté par le Superseeding par rapport au fonctionnement classique. Ce n’est pas étonnant : le choix des blocs
38
100
donnees recues par les clients (%)
80
60
40
20
0
0
200
400
600
800
1000
1200
temps (s)
F IG . 5.4 – Transfert de fichier avec BitTorrent et 512 noeuds
demandés par les clients est aléatoire, et les cas fortement défavorables (où de nombreux
clients demandent le même bloc au seeder ) sont donc rares. Par contre, nous avons pu proposer deux autres solutions :
– Limiter le nombre de distributions simultanées (7 par défaut) à une seule. Ainsi, les
clients réalisent une chaîne, ce qui permet un transfert bien plus rapide de chaque
bloc, puisque la bande passante n’est plus partagée entre les différents blocs. plus rapidement.
– Diminuer la taille des blocs, qui est par défaut de 2 18 octets (256 ko). Ainsi, le transfert
de chaque bloc est plus rapide, et les blocs peuvent être transférés à d’autres noeuds
bien plus tôt. Nous avons évalué cette approche avec une taille de bloc de 2 14 octets
(16 ko).
Ces deux propositions sont plus performantes que les solutions implémentées dans les
clients au début du transfert, mais elles montrent leurs limites par la suite :
– limiter le nombre de distributions simultanées est très pénalisant à la fin du transfert ;
– diminuer la taille des blocs est pénalisant tout au long du transfert, car le nombre de
messages échangés par les clients est plus important.
39
1400
16000
quantite totale de donnees recues sur les clients (Mo)
14000
12000
10000
8000
6000
4000
BitTornado sans Super-seeding
BitTornado avec Super-seeding
BitTorrent 4.0
BitTornado sans SS, avec max_uploads = 1
BitTornado avec chunks de 214 octets
BitTorrent 3.4
2000
0
0
100
200
300
400
500
600
700
800
900
temps (s)
F IG . 5.5 – Super-seeding et autres techniques pour accélérer la diffusion
16000
BitTornado sans Super-seeding
BitTornado avec Super-seeding
BitTorrent 4.0
BitTornado avec max_uploads = 1
BitTornado avec chunks de 214 octets
BitTorrent 3.4
6000
quantite totale de donnees recues sur les clients (Mo)
quantite totale de donnees recues sur les clients (Mo)
7000
5000
4000
3000
2000
1000
0
0
50
100
150
temps (s)
200
250
300
15500
15000
14500
14000
13500
13000
12500
600
BitTornado sans Super-seeding
BitTornado avec Super-seeding
BitTorrent 4.0
BitTornado avec max_uploads = 1
BitTornado avec chunks de 214 octets
BitTorrent 3.4
650
700
temps (s)
F IG . 5.6 – Super-seeding et autres techniques pour accélérer la diffusion : début et fin du transfert
40
750
800
Chapitre 6
Conclusion et perspectives
Les connexions à haut débit à Internet et les ordinateurs personnels surpuissants se multiplient, permettant à des particuliers de disposer de ressources équivalentes à celles des
centres de calcul ou des fournisseurs d’accès à Internet il y a encore quelques années. Cela
provoque une remise en question du modèle client/serveur largement utilisé sur Internet.
De plus en plus d’applications, et dans des domaines très divers, ont des principes de fonctionnement empruntant au moins quelques idées aux systèmes pair-à-pair.
Cela rend malheureusement le développement et la compréhension de ces applications
bien plus difficile, car tous les problèmes classiques des applications parallèles sont alors
rencontrés à très grande échelle. Les techniques classiques d’étude de ces systèmes montrent
alors leur limite : la simulation et l’exécution sur une plate-forme réelle permettent rarement
de dépasser le milliers de noeuds sans faire d’énormes compromis sur le réalisme de l’expérience.
L’émulation est une approche prometteuse pour aider à étudier ces systèmes. Si la plupart des approches actuelles privilégient le réalisme au détriment du nombre de machines
émulées, nous avons montré qu’il était possible, à moindre coût, d’obtenir des résultats intéressants avec une approche légère, privilégiant le nombre de machines émulées et le passage
à l’échelle sans sacrifier la précision de l’émulation. Mais de nombreuses voies restent ouvertes.
Tout d’abord, il serait intéressant de comparer d’une manière plus fine les résultats obtenus par P2PLab avec ceux de Netbed ou de Modelnet. Même si la plupart des expériences
réalisées avec Netbed mettent une oeuvre des topologies simples, on peut se demander si
P2PLab permettrait de réaliser des expériences avec des topologies vraiment complexes.
P2PLab ne permet pas non plus pour l’instant de modéliser la congestion dans le coeur du
réseau. Si cela n’est pas un facteur limitant dans la plupart des expériences sur les systèmes
pair-à-pair, c’est un prérequis nécessaire à une utilisation dans d’autres domaines (émulation
de grilles, par exemple).
D’autre part, FreeBSD n’est actuellement pas le système d’exploitation le plus utilisé sur
les plate-formes que nous ciblons. Il serait intéressant de concevoir un outil ayant les mêmes
possibilités que Dummynet, mais sous Linux, en se basant par exemple sur le travail fait sur
NIST Net puis Netem.
41
Les problèmes d’équité processeur entre processus émulés n’ont pas été approfondis
dans notre étude. Il serait utile de définir précisément quels sont les besoins pour un ordonnanceur adapté à l’émulation, permettant plus de souplesse dans les paramètres des
expériences et plus de réalisme dans les résultats.
Mais, plus généralement, l’objectif pourra être d’augmenter le rapport de virtualisation
(augmenter le nombre de machines virtualisées sur chaque noeud physique) sans sacrifier
le réalisme. Nous avons montré qu’il était possible d’émuler 20 instances d’une applications
assez lourde sur une seule machine, sans perdre en réalisme. Mais il faut chercher des solutions techniques permettant d’aller au delà.
42
Bibliographie
[1] G Fedak, C. Germain, V. Néri et F. Cappello. XtremWeb : A generic global computing
system. 2001.
[2] Ian Clarke, Theodore W. Hong, Scott G. Miller, Oskar Sandberg et Brandon Wiley. Protecting freedom of information online with Freenet.
[3] S Baset et H. Schulzrinne. An analysis of the Skype peer-to-peer internet telephony
protocol. 2004.
[4] Sandeep Bajaj, Lee Breslau, Deborah Estrin, Kevin Fall, Sally Floyd, Padma Haldar,
Mark Handley, Ahmed Helmy, John Heidemann, Polly Huang, Satish Kumar, Steven
McCanne, Reza Rejaie, Puneet Sharma, Kannan Varadhan, Ya Xu, Haobo Yu et Daniel
Zappala. Improving simulation for network research. Technical Report 99-702b, University of Southern California, March 1999.
[5] Arnaud Legrand, Loris Marchal et Henri Casanova. Scheduling distributed applications : the SimGrid simulation framework. In CCGRID ’03 : Proceedings of the 3st International Symposium on Cluster Computing and the Grid, page 138, Washington, DC, USA,
2003. IEEE Computer Society.
[6] Xin Liu et Andrew Chien. Realistic large scale online network simulation. In ACM
Conference on High Performance Computing and Networking (SC2004). ACM Press, 2004.
[7] p2psim. http ://pdos.csail.mit.edu/p2psim/.
[8] Mark Carson et Darrin Santay. NIST Net : a Linux-based network emulation tool. SIGCOMM Comput. Commun. Rev., 33(3) :111–126, 2003.
[9] Stephen Hemminger. Netem. http ://developer.osdl.org/shemminger/netem/.
[10] Luigi Rizzo. Dummynet : a simple approach to the evaluation of network protocols.
ACM Computer Communication Review, 27(1) :31–41, 1997.
[11] Emmanuel Conchon. Système d’émulation de réseau IP. Mémoire de D.E.A., ENSICA,
2003.
[12] David B. Ingham et Graham D. Parrington. Delayline : A wide-area network emulation
tool. Computing Systems, 7(3) :313–332, 1994.
[13] Stefano Cacciaguerra. Experiences with synthetic network emulation for complex IP
based networks. Technical Report UBLCS-2005-04, Department of Computer Science,
University of Bologna, 2005.
[14] Brian White, Jay Lepreau, Leigh Stoller, Robert Ricci, Shashi Guruprasad, Mac Newbold, Mike Hibler, Chad Barb et Abhijeet Joglekar. An integrated experimental environment for distributed systems and networks. SIGOPS Oper. Syst. Rev., 36(SI) :255–270,
2002.
43
[15] Networking Lab (California Institute of Technology).
lab.caltech.edu/.
Wan in Lab.
http ://net-
[16] Jeff Dike. A user-mode port of the Linux kernel. In Proceedings of the 4th Annual Linux
Showcase and Conference, Atlanta, page 63. Usenix, 2000.
[17] The Linux VServer Project. http ://www.linux-vserver.org/Linux-VServer-Paper.
[18] Benjamin Quétier. Emugrid : étude préparatoire pour un émulateur de système à
grande échelle. Mémoire de D.E.A., LRI, Université Paris Sud, 2004.
[19] Paul Barham, Boris Dragovic, Keir Fraser, Steven Hand, Tim Harris, Alex Ho, Rolf Neugebauer, Ian Pratt et Andrew Warfield. Xen and the art of virtualization. In SOSP ’03 :
Proceedings of the nineteenth ACM symposium on Operating systems principles, pages 164–
177, New York, NY, USA, 2003. ACM Press.
[20] A. Vahdat, K. Yocum, K. Walsh, P. Mahadevan, D. Kostic, J. Chase et D. Becker. Scalability and accuracy in a large-scale network emulator, 2002.
[21] H. J. Song, X. Liu, D. Jakobsen, R. Bhagwan, X. Zhang, K. Taura et A. Chien. The MicroGrid : a scientific tool for modeling computational grids. In Supercomputing ’00 :
Proceedings of the 2000 ACM/IEEE conference on Supercomputing (CDROM), page 53. IEEE
Computer Society, 2000.
[22] Brent Chun, David Culler, Timothy Roscoe, Andy Bavier, Larry Peterson, Mike Wawrzoniak et Mic Bowman. PlanetLab : An Overlay Testbed for Broad-Coverage Services.
ACM SIGCOMM Computer Communication Review, 33(3) :00–00, July 2003.
[23] Grid 5000. http ://www.grid5000.fr/.
[24] Clay
Shirky.
What
is
P2P
...
and
what
isn’t ?
http ://www.openp2p.com/pub/a/p2p/2000/11/24/shirky1-whatisp2p.html.
[25] E. Ng et H. Zhang. Predicting internet network distance with coordinates-based approaches. In IEEE Conference on Computer Communications (INFOCOM ’02), 2002.
[26] Benjamin Quétier et Vincent Néri. V-Meter : Microbenchmark pour évaluer les utilitaires de virtualisation dans la perspective de systèmes d’émulation à grande échelle.
In Rencontres Francophones en Parallélisme, Architecture, Système et Composant, 2005.
[27] Jon P. Giza. The FreeBSD process scheduler.
[28] Jeff Roberson. ULE : A modern scheduler for FreeBSD.
[29] Jason Evans. Kernel-scheduled entities for FreeBSD.
[30] Josh Aas. Understanding the linux 2.6.8.1 CPU scheduler.
[31] Lisa A. Torrey, Joyce Coleman et Barton P. Miller. Comparing interactive scheduling in
Linux.
[32] Bram Cohen. Incentives build robustness in BitTorrent. http://www.bittorrent.com, 2003.
[33] T. Karagiannis, A. Broido, N. Brownlee, kc claffy et M. Faloutsos. Is p2p dying or just
hiding ? In Globecom, Dallas, TX, USA, November 2004.
[34] BitTorrent Wiki. http://wiki.theory.org/CategoryBitTorrent.
[35] Philippe Golle, Kevin Leyton-Brown et Ilya Mironov. Incentives for sharing in peer-topeer networks. In EC ’01 : Proceedings of the 3rd ACM conference on Electronic Commerce,
pages 264–267, New York, NY, USA, 2001. ACM Press.
44
[36] Eytan Adar et Bernardo A. Huberman. Free riding on gnutella. First Monday, October
2000.
[37] Mikel Izal, Guillaume Urvoy-Keller, Ernst W Biersack, Pascal A Felber, Anwar
Al Hamra et Luis Garces-Erice. Dissecting BitTorrent : five months in a torrent’s lifetime. In PAM’2004, 5th annual Passive & Active Measurement Workshop, April 19-20, 2004,
Antibes Juan-les-Pins, France / Also Published in Lecture Notes in Computer Science (LNCS),
Volume 3015, Barakat, Chadi ; Pratt, Ian (Eds.) 2004, XI, 300p - ISBN : 3-540-21492-5, Apr
2004.
[38] J.A. Pouwelse, P. Garbacki, D.H.J. Epema et H.J. Sips. The Bittorrent P2P file-sharing
system : Measurements and analysis. In 4th International Workshop on Peer-to-Peer Systems (IPTPS), feb 2005.
[39] P.Garbacki, J.A.Pouwelse et D.H.J.Epema. Analyzing BitTorrent : Three lessons from
one peer-level view. In ASCI’2005.
[40] Dongyu Qiu et R. Srikant. Modeling and performance analysis of BitTorrent-like peerto-peer networks. In SIGCOMM ’04 : Proceedings of the 2004 conference on Applications,
technologies, architectures, and protocols for computer communications, pages 367–378, New
York, NY, USA, 2004. ACM Press.
[41] Ashwin R. Bharambe et Cormac Herley. Analyzing and improving BitTorrent performance. Technical Report MSR-TR-2005-03, Microsoft Research, 2005.
45