Étude et mise en œuvre d’un support pour la gestion des grandes données au sein de l’intergiciel diet sur environnements applicatifs dédiés

  • 42 trang
  • file .pdf
Rapport de stage
Stage effectué à l’ENS de Lyon
Laboratoire de l’Informatique du parallélisme (LIP)
pour l’obtention du diplôme de Master
Étude et mise en œuvre d’un support
pour la gestion des grandes données
au sein de l’intergiciel DIET sur
environnements applicatifs dédiés
Auteur : Responsable :
Patrick Telemaque M. Eddy Caron
29 Août 2014
Table des matières
Remerciements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Résumé . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1 Introduction 10
1.1 Contexte scientifique et industriel . . . . . . . . . . . . . . . . 10
1.2 Description de la plate-forme expérimentale . . . . . . . . . . 11
1.3 Problématiques et objectifs . . . . . . . . . . . . . . . . . . . 12
1.4 Contribution . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2 État de l’art 14
2.1 Les protocoles de transfert de données . . . . . . . . . . . . . 14
2.1.1 Expedat . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.1.2 Bitspeed . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.1.3 Aspera . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.1.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . 17
2.2 Les modélisations de transfert de donneés . . . . . . . . . . . 18
2.2.1 Modèle de Hockney . . . . . . . . . . . . . . . . . . . . 18
2.2.2 Famille de modèle LogP . . . . . . . . . . . . . . . . . 18
2.2.2.1 Modèle LogP . . . . . . . . . . . . . . . . . . 19
2.2.2.2 Modèle pLogP . . . . . . . . . . . . . . . . . 19
2.2.2.3 Modèle LogGP . . . . . . . . . . . . . . . . . 20
2.2.3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . 21
3 Expérimentations 23
3.1 Performances des protocoles de transfert . . . . . . . . . . . . 23
3.1.1 Transfert entre des nœuds de site différent . . . . . . . 23
1
3.1.2 Transfert entre des serveurs NFS de site différent . . . 23
3.1.3 Transfert entre un nœud et un serveur NFS de site
différent . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.1.4 Transfert entre le serveur graal et un serveur NFS . . 25
3.2 Performances des modèles et techniques de mesure de trans-
fert de donneés . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.2.1 Description des expériences . . . . . . . . . . . . . . . 26
3.2.1.1 LogP/MPI 1.3 . . . . . . . . . . . . . . . . . 27
3.2.1.2 Logp_multitest . . . . . . . . . . . . . . . . 27
3.2.1.3 Les commandes utilisées . . . . . . . . . . . . 28
3.2.2 Les expériences sur taurus-11.lyon.grid5000.fr . . . . . 29
3.2.3 Les expériences sur pastel-73.toulouse.grid5000.fr . . . 29
4 Modélisation 31
4.1 Modélisation du temps de transfert de données . . . . . . . . 31
4.1.1 Définition des variables . . . . . . . . . . . . . . . . . 31
4.1.2 Modèle . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.1.3 Présentation des résultats . . . . . . . . . . . . . . . . 33
4.1.3.1 Résultat obtenu pour le protocole Aspera . . 34
4.1.3.2 Résultat obtenu pour le protocole Expedat . 36
4.1.3.3 Résultat obtenu pour le protocole Bitspeed . 37
Conclusion générale . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Références . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
2
Table des figures
1.1 Plate-forme expérimentale . . . . . . . . . . . . . . . . . . . . 11
2.1 Comparaison des protocoles de transfert . . . . . . . . . . . . 16
3.1 Temps de transfert entre 2 nœuds de site différent . . . . . . . 24
3.2 Temps de transfert entre 2 serveurs NFS de site différent . . . 24
3.3 Temps de transfert entre un nœud et un serveur NFS de site
différent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.4 Temps de transfert entre le serveur graal et un serveur NFS . 25
3.5 Le modèle LogP . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.6 Performance réseau du modèle logP . . . . . . . . . . . . . . . 29
4.1 Temps de transfert avec Aspera sur taurus-11.lyon.grid5000.fr 35
4.2 Temps de transfert avec Aspera sur pastel-73.toulouse.grid5000.fr 35
4.3 Temps de transfert avec Expedat sur taurus-11.lyon.grid5000.fr 36
4.4 Temps de transfert avec Expedat sur pastel-73.toulouse.grid5000.fr 36
4.5 Temps de transfert avec Bitspeed sur taurus-11.lyon.grid5000.fr 37
4.6 Temps de transfert avec Bitspeed sur pastel-73.toulouse.grid5000.fr 37
3
Liste des tableaux
2.1 Caractéristiques des protocoles . . . . . . . . . . . . . . . . . 16
2.2 Le modèle LogGP exprimé en fonction de pLogP . . . . . . . 21
3.1 Table des mesures sur le nœud de Lyon . . . . . . . . . . . . 30
3.2 Table des mesures sur le nœud de Toulouse . . . . . . . . . . 30
4.1 Tableau des variables du modèle . . . . . . . . . . . . . . . . 31
4.2 Table des paramètres pour taurus-11.lyon.grid5000.fr . . . . 34
4.3 Table des paramètres pour pastel-73.toulouse.grid5000.fr . . 34
4.4 Table des paramètres pour les protocoles . . . . . . . . . . . 34
4
Remerciements
Mes remerciements s’adressent en premier lieu au grand architecte de
l’univers, Dieu, sans qui rien de ceci ne serait possible.
Je veux remercier de façon très particulièrement chaleureuse mon maître
de stage, Monsieur Eddy Caron, pour sa confiance, ses conseils et sa
disponibilité qui m’ont permis de progresser sans cesse durant ces 6 mois de
stage.
Je tiens également à remercier tous les membres de l’équipe Avalon
du LIP, pour leur amitié, leur soutien et leur accueil dans le groupe.
Mes pensés vont également à tout le personnel et enseignants de l’Institut
de la Francophonie pour l’Informatique (IFI), très spécialement Messieurs
Victor Moraru, Nguyen Hong Quang et Ho Tuong Vinh pour leur conseil et
le suivi qu’ils m’ont accordés pendant mes études de master et mon séjour
au Vietnam.
Mille mercis à tous mes amis étudiants de l’IFI avec qui j’ai passé de
bons moments pendant les périodes de stress, et qui, à leur façon m’ont
donné la force d’avancer : Paterne, Selain, Landy, Farida, Youssouf, Ma-
penda, Hoa et j’en passe forcément.
J’exprime ma profonde gratitude à l’égard de ma grande famille pour
leurs encouragements, leurs prières et leurs soutiens, qui malgré la distance
n’a jamais cessé de me prêter main forte.
Finalement, merci à tous ceux qui ont croisé mon chemin à Hanoï et
à Lyon, d’une façon ou d’une autre vous avez forcément influencé ce travail.
5
Résumé
Animérique est un projet dont l’objectif est de concevoir et déployer une
plate-forme de calcul distribuée sur ressources hétérogènes. Cette plate-forme
sera dédiée à l’industrie de l’animation. Ce projet est né de la rencontre entre
deux mondes : la recherche sur la communauté du calcul haute performance
par les chercheurs de l’Inria et de l’ENS de Lyon et la communauté d’ani-
mation à travers la société CapRézo.
Les besoins de calcul numérique se développent chaque année. Cependant
les artistes peuvent bénéficier de certains outils efficaces pour la création et
la modélisation, mais il y a un manque d’outils pour distribuer les tâches
de calcul sur des plate-forme distribuées et hétérogènes. Encore aujourd’hui,
certains studios distribuent presque manuellement les tâches. Certaines so-
lutions existent en utilisant le paradigme Cloud, mais le modèle économique
conduit à être dépendant d’un fournisseur et/ou implique d’envoyer des don-
nées critiques en dehors du territoire.
Un des problèmes majeures pour le partage des ressources et le calcul
distribué est la gestion de données en environnement distribué. Chaque ap-
plication a des besoins propres en terme d’accès ou production de données :
grandes quantités de petites données de quelques kilooctets, ou données de
plusieurs teraoctets. Dès lors que l’on utilise des plates-formes de calcul hé-
térogènes et distribuées, aussi bien les ressources de stockage (RAM, disque
local ou distant, etc.) que les liens réseaux sont très discordants en terme de
performance et de taille. Il convient donc d’adapter les politiques de dépla-
cements, réplication et positionnement des données en fonction des besoins
des applications, et des possibilités de la plate-forme sous-jacente.
Ce travail compare les approches commerciales de transport de données
rapides à travers des Wide Area Network (WAN) à haut débit . Des solutions
courantes, tels que le protocole de transport de fichiers (FTP) basé sur la
pile TCP/IP, sont de plus en plus remplacées par des protocoles modernes
basés sur des piles plus efficaces. Pour évaluer les capacités des applications
actuelles pour le transport rapide des données, les solutions commerciales
suivantes ont été étudiées : Aspera, Bitspeed et Expedat. Le but de ce tra-
vail est de tester les solutions dans les mêmes conditions réseaux et ainsi
comparer les performances de transmission des dernières solutions proprié-
taires alternatives pour FTP/TCP dans les réseaux WAN à haut débit où
il y a des latences élevées. Cette recherche porte sur une comparaison des
approches utilisant des paramètres intuitifs tels que le taux de données et la
durée de transmission.
La validation et la mise en œuvre des solutions conçues par le projet
Animérique seront effectués en utilisant l’intergiciel DIET. Cet intergiciel
est un logiciel développé par l’équipe Avalon (Inria / ENS de Lyon).
6
Mots clés : transferts de données à haut débit , cloud computing, big
data, protocole de transport.
7
Abstract
Animerique is a project whose goal is to design and deploy a platform for
distributed computing on heterogeneous resources. This platform will be de-
dicated to the animation industry. This project is born from the encounter
between two worlds : the research community for high performance com-
puting by researchers at INRIA and ENS Lyon, and community animation
through the company CapRézo.
Needs numerical calculation grow each year. However, artists can be-
nefit from some effective tools for creating and modeling, but there is a
lack of tools to distribute computing tasks on distributed and heterogeneous
platform. Even today, some studios almost manually distribute tasks. Some
solutions exist using the cloud paradigm, but the economic model leads to
be dependent on a supplier and / or involves sending critical data outside
the territory.
One of the major problem for resource sharing and distributed computing
is the data management in a distributed environment. Each application has
its own needs in terms of access or data production : large quantities of small
data of few kilobytes or terabytes of data. As long as that we use platforms
heterogeneous and distributed computing, both storage resources (RAM,
local or remote disk, etc..) and the network links are very discordant in terms
of performance and size. It is therefore necessary to adjust movement policies,
replication and data placement based on application needs and opportunities
of the underlying platform.
This work compares commercial fast data transport approaches through
high-speed Wide Area Network (WAN). Common solutions, such as File
Transport Protocol (FTP) based on TCP/IP stack, are being increasingly
replaced by modern protocols based on more efficient stacks. To assess the
capabilities of current applications for fast data transport, the following com-
mercial solutions were investigated : Aspera, Bitspeed and Expedat. The
goal of this work is to test solutions under equal network conditions and
thus compare transmission performance of recent proprietary alternatives
for FTP/TCP within high-speed networks where there are high latencies in
WANs. This research focuses on a comparison of approaches using intuitive
parameters such as data rate and duration of transmission.
Validation and implementation of designed solutions by the project
Animerique will be done using the DIET middleware. This middleware is a
software developed by the Avalon team (Inria / ENS de Lyon).
Key words : high-speed data transport, cloud computing, big data, trans-
port protocol.
8
Première partie
9
Chapitre 1
Introduction
1.1 Contexte scientifique et industriel
Ce stage s’inscrit dans le cadre du projet collaboratif Animérique entre
l’Inria, l’ENS de Lyon et la société CapRézo.
L’Institut National de Recherche en Informatique et en Automatique
(INRIA) est un organisme public de recherche français. Son objectif est de
mettre en réseau les compétences de la recherche française dans le domaine
des sciences et technologies de l’information.
L’École Normale Supérieure de Lyon (ou ENS de Lyon) est une grande
école scientifique et littéraire française, l’une des quatre écoles normales su-
périeures. Elle forme à l’enseignement et à la recherche dans le domaine des
sciences fondamentales et expérimentales ainsi que dans celui des lettres et
sciences humaines.
À travers le projet Animérique, l’Inria, l’ENS et CapRézo joignent leurs
efforts afin de concevoir et déployer une plate-forme de calculs distribués
qui sera dédiée à l’industrie de l’animation. Les principaux thèmes abordés
par le projet Animérique concernent la distribution des tâches de calcul sur
des plates-formes distribuées et hétérogènes, l’accès et la gestion locale des
ressources (ex : cluster ou Cloud), la planification des tâches et l’optimisation
du temps de transfert des grands volumes de données. Ces solutions seront
mises en œuvre en utilisant l’intergiciel DIET qui est un logiciel développé
par l’équipe Avalon (Inria / ENS de Lyon).
Ces recherches sur les grappes et grilles sont au cœur des thématiques
du laboratoire LIP de L’ENS de Lyon, en particulier sur des aspects comme
l’évaluation de performance et sur la gestion de ressources dynamiques.
10
1.2 Description de la plate-forme expérimentale
Dans ce travail, les expériences ont été réalisées sur la grille de calcul
française Grid’5000 1 . L’environnement expérimental est constitué de deux
sites séparés par un réseau étendu (WAN), un serveur de stockage et un
poste client. La figure 1.1 représente l’architecture de cet environnement
paramétré par n, qui constitue le nombre de nœuds. Nous utilisons le même
nombre de nœuds sur les deux sites S1 et S2 . Ni,j est le nœud j du site i.
La puissance des nœuds est différente d’un site à l’autre et peut grandement
faire varier les performances selon que l’on se trouve sur des machines avec
2 ou 8 cœurs par exemple mais les comparaisons sont effectuées de manière
unitaire, c’est-à-dire avec les mêmes machines. bdp représente la capacité du
lien longue distance à 1 ou 10 Gbit/s. Le RT T varie selon les sites choisis
(9,9 s entre Lyon et Toulouse). Les nœuds sont reliés par des cartes Ethernet
à 1 Gbit/s. Chaque site possède un serveur NFS commun à tous les nœuds.
Le serveur graal est un serveur qui se trouve à l’extérieur de la grille de calcul
grid’5000, il est utilisé pour le stockage des données. Nous utiliserons cette
même architecture pour toutes nos expériences.
Figure 1.1 – Plate-forme expérimentale
À partir du poste client, nous allons transférer les fichiers sur le serveur
graal. Une fois que les fichiers sont sur le serveur graal, nous allons les trans-
férer par la suite au serveur NFS des différents sites avant de les migrer vers
1. https://www.grid5000.fr/mediawiki/index.php/Grid5000:Home
11
les différents nœuds. Donc, nous allons faire des transferts de données point à
point, c’est-à-dire à partir du serveur graal vers un serveur NFS, à partir du
serveur graal vers un nœud, à partir du serveur NFS vers un nœud, etc. Ces
transferts seront réalisés en utilisant les protocoles de transfert de données
suivantes : Aspera [3], Bitspeed [6] et Expedat [7,8].
1.3 Problématiques et objectifs
La demande croissante pour l’échange rapide d’énormes quantités de don-
nées entre sites distants a conduit à l’émergence de nombreuses nouvelles
solutions de transport de données qui promettent de transporter d’énormes
quantités de données beaucoup plus rapide que les solutions FTP/TCP clas-
siques. Actuellement, les solutions les plus courantes pour le transport de
données fiable dans les réseaux IP sont basés sur le protocole TCP, qui a été
développé dans les années 1970. Un certain nombre de documents décrivent
comment TCP, avec quelques ajustements, peut fonctionner raisonnablement
sur les réseaux locaux (LAN) avec une bande passante hautement disponible
[20]. Toutefois, il est bien connu que TCP a un rendement très limité lorsqu’il
est utilisé dans les réseaux longue distance avec une bande passante élevée
- appelés "Long Fat Pipe Network (LFN)" [19]. Par exemple, un test avec
iperf en utilisant l’architecture décrite dans la figure 1.1 sur une liaison de
bout-en-bout de 1 Gbit/s avec un RTT de 50 ms (round-trip time) et en
présence d’un taux de perte d’au moins 0,1% montre un débit de données
d’environ 40 Mbit/s.
Il faut mentionner aussi que la plupart des WAN (Wide Area Network)
actuels ne sont pas appropriés d’acheminer des téraoctets et pétaoctets de
données vers la grille [19]. Tout d’abord, la grande latence du réseau longue
distance implique des communications et des retransmissions de paquets per-
dus qui sont coûteuses. Ensuite, le débit disponible sur le lien d’accès à ce
réseau est généralement inférieur à la somme des débits nécessaires si tous les
processus communiquent en même temps sur ce lien. D’une manière générale
les trois principaux challenges lorsque les Big Data 2 migrent vers la grille
sont la localisation, la bande passante, et la qualité du réseau.
Plus la distance réseau entre le data center et le site de stockage d’ori-
gine est considérable, plus la latence est importante sur le WAN, et plus
le transfert des données est long. Lorsque l’utilisation de la bande passante
disponible n’est pas suffisante, les transferts de données prennent plus de
temps à être effectuer. Compte tenu des contraintes inhérentes à TCP, l’aug-
mentation de la bande passante à elle seule ne suffit pas à tenir l’objectif
de transférer les big data avec le débit nécessaire. D’où l’émergence de nom-
2. Énormes volumes de données difficilement gérables avec des solutions classiques de
stockage et de traitement.
12
breuses nouvelles solutions de transport de données qui peuvent transporter
d’énormes quantités de données beaucoup plus rapide que les solutions FTP
/ TCP classiques.
Il est donc important de spécifier pour chaque modèle les caractéristiques
du réseau modélisé. Le comportement des réseaux de grappe, par leur as-
pect dédié, bénéficie de modélisations [1,15,17,18] que nous détaillerons en
chapitre 2.
L’objectif principal de ce stage est d’étudier en détail la gestion des grands
volumes de données sur la grille de calcul et d’évaluer les capacités des solu-
tions de transport dans les réseaux longue distance à haut débit.
1.4 Contribution
La contribution de ce stage s’articule en fonction des objectifs énoncés
dans la section précédente.
+ Expériences et analyse des transferts de données
Ce stage a permis de mener une étude sur les performances des proto-
coles de transfert de données. Cette étude propose de comparer 3 solutions :
Aspera [3], Bitspeed [6] et Expedat [7][8] sur la grille. Ces expériences ont
été menées sur les grappes du projet Grid’5000. Les travaux proposés éta-
blissent une relation entre le temps de transfert, la latence et le débit mesuré
dû à l’utilisation optimale de la bande passante par chaque protocole. Pour
atteindre cet objectif, nous avons effectué des transferts de données de taille
variée afin de juger le comportement de ces protocoles dans le transfert de
petit ou de gros fichier. Le chapitre 3 décrira le protocole expérimental mis
en œuvre.
13
Chapitre 2
État de l’art
2.1 Les protocoles de transfert de données
L’objectif principal de notre travail est d’évaluer les capacités des solu-
tions de transport dans un réseau WAN à grande vitesse. L’intérêt pour nous
est le temps de transfert de données minimale possible de bout en bout sur
de tels réseaux. Actuellement, il y a quelques différentes mesures de perfor-
mance qui ont été utilisées pour évaluer ces déficiences en terme de temps
de transfert dans les solutions open source et freeware. Par exemple, dans
[22] Grossman et al. présentent l’évaluation de la performance de UDT [21] à
travers un réseau de 10 Gbit/s. L’article montre comment en utilisant UDT
et en présence de 116 ms de RTT, ce réseau a un débit maximal de 4,5
Gbit/s dans un seul flux de données. Deux flux parallèles réalise ainsi envi-
ron 5 Gbit/s et dans les 8 flux parallèles environ 6,6 Gbit/s sont atteints. En
outre, un résultat de performance pour la transmission de données à l’aide
de RBUDP a été présenté au 3ieme atelier international annuel de CineGrid
[23]. Bien que la vitesse d’accès au disque limite la vitesse de transport de
données à 3,5 Gbit/s, sur le lien entre Amsterdam et San Diego seulement
1,2 Gbit/s a été atteint. La distance de ce chemin est d’environ 10 000 km à
travers la fibre optique, ce qui correspond à environ 100 ms de RTT.
Pour les solutions closed source commerciales, la situation diffère sen-
siblement. Il y a plusieurs publications des résultats de performance des
solutions disponibles sur le marché, fournies par les fabricants eux-mêmes :
Aspera [3], Expedat [7,8] et Bitspeed [6] - qui ont tous fait état des résultats
parfaits. Toutefois, ces résultats fournissent principalement des informations
commerciales pour attirer les clients potentiels et les conditions d’évaluation
varient. Pour remédier à ce déficit, l’idée principale de notre travail est de
placer toutes les solutions étudiées dans des conditions égales dans le même
environnement.
14
2.1.1 Expedat
Expedat est une solution de transport de données basée sur UDP dévelop-
pée par Data Expedition Inc., USA. Le cœur de cette application comprend
le Protocole Multi Transaction (MTP) [7,8], développé par le fondateur de
Data Expedition, dans le but d’envoyer et de recevoir des fichiers plus rapide-
ment et de manière fiable que les applications FTP traditionnelles. Expedat
prend en charge beaucoup de plates-formes telle que Windows, Mac OSX,
Linux/Solaris, NetBSD/FreeBSD, AIX et les plates-formes HP-UX. Selon
le site Web de la société, Expedat permet la transmission de données avec
100% d’utilisation de la bande passante allouée et en présence de cryptage
AES [8]. Il met en œuvre la logique de protocole de transport UDP sur un
canal, et utilise un seul socket UDP sur chaque côté de la connexion pour la
transmission des données et des informations de contrôle.
2.1.2 Bitspeed
Cette solution a été développée aux États-Unis. Il s’agit d’une application
de transfert de fichiers basée sur le protocole TCP, et, selon le site Web du
fournisseur [6], il permet d’utiliser pleinement la bande passante disponible.
Bitspeed est également disponible avec un cryptage de données allant jusqu’à
24 Gbit/s et un cryptage AES allant jusqu’à 1600 Mbit/s. Les plates-formes
supportées par Bitspeed sont Windows, Mac OSX, Linux et Solaris. Selon le
mode d’emploi, cette solution adapte automatiquement ses paramètres avec
les conditions du réseau et choisit les paramètres optimaux (débit, latence,
etc.) pour la transmission de données.
2.1.3 Aspera
La technologie de transfert FASP de Aspera [3] est un logiciel innovant
de la compagnie IBM qui élimine les goulots d’étranglement fondamentaux
des technologies de transfert de fichiers classiques, tels que HTTP, FTP, et
accélère les transferts sur des réseaux IP publics et privés. Cette approche
permet d’améliorer le débit, indépendant de la latence du lien. En outre, les
utilisateurs ont le contrôle sur les taux individuels de transfert et le partage
de la bande passante, et une visibilité complète sur l’utilisation de la bande
passante. Le temps de transfert de fichiers peut être garantie, indépendam-
ment de la distance des points d’extrémités ou les conditions dynamiques du
réseau, y compris les transferts sur les réseaux sans fil et les liaisons interna-
tionales fiables. Aspera intègre le cryptage des données, y compris l’authen-
tification sécurisée du point d’extrémité, et la vérification de l’intégrité des
données.
15
Comparaison et mesure :
Le tableau 2.1 compare les différents protocoles en terme des plates-
formes supportées et le débit et la latence minimales et maximales mesurés
lors de nos expériences.
Plates-formes Débit Min Débit Max Latence Min Latence Max
Aspera Windows, Linux, 44.75 Mb/s 630 Mb/s 10 ms 23 ms
Mac OSX, Sola-
ris, FreeBSD, Isi-
lon OneFS
Expedat Windows, Linux, 40 Mb/s 577 Mb/s 8 ms 19 ms
Mac OSX, Solaris,
NetBSD/FreeBSD,
AIX, HP-UX
Bitspeed Windows, Linux, 19.4 Mb/s 304,5 Mb/s 5 ms 16 ms
Mac OSX, Solaris
Table 2.1 – Caractéristiques des protocoles
Pour évaluer la performance de ces protocoles, nous avons réalisé des
transferts de données entre des paires de nœuds appartenant à deux grappes
grid5000 différentes. Les expériences ont été réalisés sur les sites de Nancy
et de Rennes.
Pour ce faire, on crée sur un nœud de Nancy 1440 fichiers de 6 Mo chacun
rempli uniquement de zéros et un fichier vidéo d’une taille de 8 Go. Après
on les transfert vers un nœud de Rennes.
Les expériences consistent à déterminer le temps mis pour transférer
les 1440 fichiers et le fichier vidéo entre les deux nœuds. Les résultats sont
présentés dans la figure 2.1.
Figure 2.1 – Comparaison des protocoles de transfert
16
Il convient de relever trois points quant à l’analyse de cette figure :
• Certains protocoles se comportent mieux dans le transfert de grand
fichier, mais très mauvais dans les petits fichiers. Comme c’est le cas
pour le protocole Expedat.
• Certains protocoles se comportent très bien à la fois dans le transfert de
petits fichiers et de grand fichier. Comme c’est le cas pour le protocole
Aspera.
• On constate que certains protocoles comme celui d’Expedat offre un
bon débit (efficace pour les gros fichiers), mais est plus faible côté
latence (moins performant pour les petits fichiers).
2.1.4 Conclusion
Il existe bien des différences de performance entre les protocoles. De plus
on constate une différence de performance en fonction de la façon d’utiliser le
protocole. Il peut donc être intéressant de proposer des solutions dynamiques
qui offrent des mécanismes permettant de choisir le bon protocole pour le
bon usage.
17
2.2 Les modélisations de transfert de donneés
Il existe différents modèles et techniques qui ont été proposés pour mesu-
rer et analyser la performance de transfert de données. En réalité, le transfert
de données n’est pas seulement un problème des grilles de calcul, mais c’est
aussi un problème qui concerne les réseaux de communication comme par
exemple Internet. Dans cette partie nous allons présenter seulement les mo-
dèles que nous avons jugés proches de notre problématique.
2.2.1 Modèle de Hockney
Le modèle de Hockney [15] est historiquement un des premiers modèles
de mesure de transfert de données, ce qui en fait l’un des modèles les plus
utilisés. Pour calculer le temps d’un transfert de données, ce modèle introduit
deux paramètres : la latence et la bande passante. La latence correspond
au temps minimal de traversée du réseau, tandis que l’inverse de la bande
passante correspond au taux de service maximum qu’offre le réseau. Ces deux
paramètres ont été largement utilisés dans d’autres modèles. Le modèle de
Hockney combine ces deux paramètres à travers une équation affine :
t(m) = L + m/B
Ainsi, le temps d’un transfert t(m) qui envoie une quantité m de données est
fonction de la latence L et de la bande passante B.
D’une manière plus formelle, le calcul de la latence L correspond à la
durée d’envoi d’une quantité de données nulle. Elle se mesure en seconde.
À l’inverse, la bande passante est le rapport entre une taille de données et
sa durée de transfert. Elle correspond au débit et se mesure en octet par
seconde. Pour obtenir les valeurs de ces deux paramètres il existe différents
outils de mesure dont entre autre NetPIPE [16].
Un modèle similaire au modèle Hockney qui combine ces paramètres à
travers une équation hyperbolique a été proposé. Ce modèle a ouvert la voie
au concept de temps de latence proportionnelle à la taille de données. Ce
concept sera repris dans les modèles de la famille LogP, en introduisant les
concepts de surcoût logiciel (overhead).
2.2.2 Famille de modèle LogP
Le modèle de Hockney calcule les temps de transfert en fonction d’une
simple équation affine et de deux paramètres. La famille des modèles LogP
est apparue afin d’exprimer de manière détaillée les mécanismes intervenant
dans un transfert. De ce fait, ces modèles sont plus complexes et augmentent
le nombre de paramètres utilisés.
18
Dans le cas de communications point à point, la famille LogP comporte
trois modèles : le modèle LogP [17], le modèle LogGP [1] et le modèle pLogP
[18].
2.2.2.1 Modèle LogP
Le modèle LogP [17] est le modèle d’origine dont découlent les autres
modèles de la famille LogP. Ce modèle définit quatre paramètres comme
suit :
• L (Latency) : qui correspond à la latence réseau ;
• o (overhead) : le coût logiciel induit par le mécanisme de transfert ;
• g (gap) : le temps intrinsèque entre deux envois ou réceptions de pa-
quets ;
• P (Processors) : le nombre de processeurs mis en jeu.
Trois de ces paramètres sont combinés par l’équation suivante :
k
2 × o + L + d e × max(g, o)
w
Cette équation calcule le temps nécessaire à l’envoi de k octets divisés en
w paquets. À la différence du modèle de Hockney, pour caractériser le taux
fixe de transfert, le modèle LogP ajoute à la latence les coûts logiciels induits
par l’émission et par la réception. Ces coûts correspondent à la création de
paquets, l’encapsulation, etc. Un taux variable est associé aux différents pa-
quets. Lorsque le modèle de Hockney précise une bande passante commune
pour chaque taille de message, sans introduire la notion de paquets, le mo-
dèle LogP ajoute une contrainte entre paquets. Cette contrainte stipule que
deux paquets consécutifs ne peuvent pas être transmis en moins de g uni-
tés de temps. Ce paramètre g représente la durée pendant laquelle le réseau
transmet un paquet. Le modèle LogP donne des résultats efficaces pour des
données de petite taille. Néanmoins, pour des données de grande taille les
résultats sont moins précis. En effet, les valeurs de g et o sont identiques
quel que soit la taille des données, et il paraît tout à fait logique que le sur-
coût logiciel est plus important pour de grandes données que pour de petites
données. Pour remédier à cette perte de prédiction, le modèle LogGP a été
introduit.
2.2.2.2 Modèle pLogP
Le modèle pLogP (parameterized LogP) [18] introduit une nouvelle façon
de considérer les paramètres du modèle LogP. Ce modèle a pour paramètre
19