Utilisation de la plate-forme haute performance de communication

Dans cette section, nous décrivons notre portage de JXTA-C au-dessus de la plate-forme haute performance de communication pour grilles PadicoTM [71]. Par ailleurs, nous présentons également une évaluation de cette réalisation. L’objectif de cette intégration est de pouvoir bénéficier de manière transparente des fonctionnalités avancées fournies par PadicoTM au-dessus des réseaux haute performance des grilles de calcul.

10.2.3.1 Présentation de PadicoTM

PadicoTM, pourParallel and distributed Task Manager, est une plate-forme haute perfor-mance de communication pour grilles de calcul. Son principal objectif est d’implémenter le modèle de communications proposé et défini dans [71]. Ce modèle vise à supporter les ap-plications utilisant à la fois les exécutifs qui suivent le paradigme du calcul parallèle et ceux qui suivent celui du calcul réparti. L’objectif de PadicoTM est d’autoriser l’utilisation de n’importe quel exécutif sur n’importe quel type de réseau. Pour ce faire, PadicoTM s’appuie sur des mécanismes de virtualisation et d’abstraction avecadaptateurs trans-paradigme. Ainsi, PadicoTM offre l’interface de programmation sur laquelle l’exécutif repose, même si les res-sources utilisées pour implémenter cette interface sont différentes. L’objectif est alors pour, par exemple, un intergiciel CORBA de pleinement tirer parti des hautes performances des SAN, sans nécessiter de modifications de son code source (solution habituelle). Par ailleurs, desadaptateurs alternatifspermettent de changer, toujours de manière transparente du point de vue de l’exécutif, l’implémentation de l’interface utilisée, en ajoutant par exemple des flux parallèles sur une communication WAN. Enfin, PadicoTM résout des problèmes tels que la cohabitation d’exécutifs, le chargement dynamique de code et l’utilisation efficace du

multi-threading.

Les intergiciels respectant la spécification JXTA sont des exécutifs du calcul réparti. Deux fonctionnalités de PadicoTM nous intéressent plus particulièrement : 1) l’adaptateur trans-paradigme vers le paradigme du calcul parallèle pour une utilisation transparente des capacités des SAN et 2) les adaptateurs alternatifs qui permettent d’ajouter de manière trans-parente les flux parallèles et la compression à la volée sur des communications WAN. La première fonctionnalité est celle des sockets virtuelles. Elle permet aux exécutifs du réparti d’accéder de manière transparente aux interfaces de programmation des drivers des SAN, tels que Myrinet, Infiniband ou Quadrics par exemple. Les appels aux opérations de l’in-terface des socketsBSD sont alors liés aux opérations de l’interface équivalente fournie par PadicoTM, lors de l’édition de liens dynamiques. Ces dernières reposent directement sur l’interface de programmation du driver de la carte réseau. Une telle fonctionnalité permet de passer outre la couche TCP/IP du noyau et donc d’éviter son surcoût. En conséquence, ces intergiciels peuvent pleinement exploiter les capacités de ces réseaux. Toutefois, l’ex-ploitation de telles capacités n’est possible que si l’intergiciel implémente une couche de communication zéro-copie. À tire d’exemple, ce mécanisme permet sur un réseau Myri-10G,

10.2 – Optimisation des performances pour les environnements de type grille 155

µPM2 Circuit Socket virtuelles

Madeleine Marcel

Adaptateurs alternatifs

(compression à la volée, flux parallèles, etc)

Adaptateurs transparadigme PadicoTM Application

MPI Corba JXTA−C Autre ...

FIG. 10.7 – Empilement des couches logicielles d’une application basée à la fois sur MPI et sur CORBA et qui repose sur PadicoTM.

d’offrir de manière transparente auxsockets C une bande passante de 915 Mo/s et une la-tence de 6 µs8. Rappelons que sur un tel réseau, une latence de 2,5µs peut être atteinte au niveau driver avec une bande passante de 1 150 Mo/s9. PadicoTM supporte les intergiciels suivants : deux implémentations de CORBA (OmniORB et MICO), deux implémentations de MPI (MPICH/Madeleineet GRIDMPI), la machine virtuelle Kaffe et gSOAP.

La figure 10.7 présente l’empilement des couches logicielles d’une application, basée sur MPI et CORBA, qui repose sur PadicoTM. Elle illustre également les deux types d’adapta-teurs présents dans l’architecture interne de PadicoTM. Enfin, PadicoTM repose sur Made-leine [29] et Marcel [132], respectivement une bibliothèque de communication et un or-donnanceur de processus légers. Ces deux bibliothèques forment ce qui est appeléµPM2

de l’environnement de programmation parallèle par RPC PM2

[133].

10.2.3.2 Portage de JXTA-C au-dessus de PadicoTM

Porter JXTA-C au-dessus de PadicoTM, via sessockets virtuelles offre donc théorique-ment la possibilité d’utiliser de manière transparente les capacités des SAN, en termes de débit et de latence. En outre comme nous l’avons vu dans la section précédente, ce portage permet d’utiliser des adaptateurs alternatifs pour ajouter de manière transparente : des flux parallèles et/ou de la compression à la volée pour tout échange de messages en WAN. Dans cette section, nous décrivons les modifications que nous avons effectuées pour la réalisation du portage de JXTA-C au-dessus de PadicoTM.

Aucune modification dans le code source de JXTA-C n’a été nécessaire. Toutefois, des modifications ont été nécessaires dans la bibliothèque sur laquelle JXTA-C repose. En effet, JXTA-C utilise une bibliothèque d’abstraction des interfaces de programmation fournies

8Machines AMD Opteron à 2 GHz avec 2 Go de mémoire vive et tournant sous un Linux 2.6.

9Notons toutefois que lors des ces évaluations le support des derniers drivers Myrinet (MX) par PadicoTM était expérimental et en cours d’amélioration (août 2006).

par le système d’exploitation, appeléeApache Portable Runtime(APR [196]). Le portage de JXTA-C au-dessus de PadicoTM consiste en réalité à porter APR au-dessus de PadicoTM. L’objectif d’APR est de fournir aux développeurs une interface de programmation leur as-surant un comportement prévisible, si ce n’est identique, et indépendant de la plate-forme sur laquelle s’exécutent leurs applications. Ainsi, les développeurs n’ont pas à se préoccu-per du codage des cas particuliers pour pallier ou utiliser des carences ou des fonctionnalités spécifiques à une plate-forme d’exécution. L’interface de programmation mise à disposition couvre le chargement de bibliothèque dynamique, les opérations sur les fichiers et sur la mé-moire, la programmation réseau, les processus lourds et légers, diverses structures de don-nées, etc. APR est implémenté dans le langage C et peut s’exécuter sur Windows, Netware, Mac OS X, OS/2 et les variantes existantes d’Unix. JXTA-C utilise principalement d’APR les processus légers, lessocketsBSD et diverses structures de données.

Comme nous l’avons décrit dans la section précédente, PadicoTM est basé sur la bi-bliothèque de processus léger Marcel. Ainsi, l’utilisation de la bibi-bliothèque native POSIX Thread(NPTL), choisie par défaut par APR sous les variantes d’Unix, n’est pas possible : une seule bibliothèque pouvant être utilisée. Cependant, PadicoTM fournit les commandes nécessaires pour « marceliser » les primitives pthread utilisées par APR. Le prototype des fonctions commençant parpthreadest remplacé parmarcel. Malheureusement, l’utilisation de ces commandes n’est pas suffisante. En effet, l’utilisation réalisée par APR de la spécifi-cation des processus légers POSIX est exhaustive. Or, l’implémentation fournie par la biblio-thèque Marcel de cette spécification n’est pas complète, tout du moins via l’interfacemarcel

de Marcel. Les verrous récursifs ne sont notamment pas supportés dans cette interface, mais uniquement dans l’interface pmarcel de Marcel. Une modification dans le code d’APR a donc été nécessaire afin de distinguer le type de verrou utilisé. Par ailleurs, la gestion des signaux n’est pas entièrement implémentée dans Marcel : certains appels ne sont pas dispo-nibles. En conséquence, les fonctions APR de gestion des signaux retournent une constante indiquant que ceux-ci ne sont implémentés. Toutefois, l’intergiciel JXTA-C n’utilise pas de signaux pour sa mise en œuvre. Enfin, les prototypes des fonctions pour l’acquisition et le relâchement d’un sémaphore entre les bibliothèques respectant la spécification des proces-sus légers POSIX et Marcel sont différents, nécessitant également une modification du code d’APR.

La version 1.2.1 d’APR a été portée sur PadicoTM version 0.3 beta 2, permettant à la version 2.3 de JXTA-C en mode optimisé d’être testée. Compte tenu de l’absence de mo-difications au sein de JXTA-C, nous pensons que les versions supérieures de cet intergiciel peuvent être immédiatement supportées par PadicoTM. D’autre part, les minimes modifica-tions apportées à APR nous permettent de croire que les versions 1.2.x peuvent être portées très rapidement. L’implémentation Java de JXTA n’a pas été portée au-dessus de PadicoTM. En effet, PadicoTM ne supporte actuellement que la machine virtuelle Kaffe. Or, celle-ci n’im-plémente pas la spécification 1.4 requise par les versions de JXTA-J2SE inférieures à 2.3.7. En outre, à partir de la version 2.3.7, JXTA-J2SE nécessite une machine virtuelle respectant la spécification 5.0 de Java.

10.2.3.3 Évaluations

Dans cette section nous présentons les évaluations que nous avons faites de notre por-tage de JXTA-C et JUXMEM-C au-dessus de PadicoTM.

10.2 – Optimisation des performances pour les environnements de type grille 157 Socket C 100 200 300 400 500 600 700 800 900 1000 16Mo 4Mo 1Mo 256 64 32 16 8 4 2 1 0.5 Débit (Mo/s)

Taille des message (ko) JXTA−C 2.3 service point−à−point (mode zéro−copie)

JXTA−C 2.3 service point−à−point

0 Socket C 100 200 300 400 500 600 700 800 900 1000 16Mo 4Mo 1Mo 256 64 32 16 8 4 2 1 0.5 Débit (Mo/s)

Taille des message (ko) JXTA−C 2.3 canal unidirectionnel (mode zéro−copie)

JXTA−C 2.3 canal unidirectionnel

0

FIG. 10.8 – Débits comparés du service point-à-point (gauche) et d’un canal unidirection-nel (droite) de JXTA-C 2.3 en version optimisée au-dessus de PadicoTM sur un réseau Myri-10G, avec ou sans l’option zéro-copie activée, et en prenant pour courbe de référence le débit d’unesocketC.

Implémentation JXTA-C 2.3 (avec PadicoTM)

Service point-à-point 47µs

Canal unidirectionnel 52µs

BSDsockets 6µs

TAB. 10.3 – Performances en termes de latence du service point-à-point et d’un canal unidi-rectionnel de JXTA-C en version optimisée avec l’utilisation de PadicoTM et sur un réseau Myri-10G, comparées aux performances en latence d’unesocketC.

Évaluation des couches de communication de JXTA-C. La figure 10.8 compare les perfor-mances en termes de débit du service point-à-point et d’un canal unidirectionnel de JXTA-C 2.3 en version optimisée au-dessus de PadicoTM, avec ou sans l’option zéro-copie activée. Par ailleurs, cette figure présente également le débit d’unesocketC au-dessus de PadicoTM en guise de courbe de référence. Nous pouvons constater que l’allure des courbes de débit lorsque l’option zéro-copiée est activée suit celle d’unesocketC. En effet, les débits du service point-à-point et d’un canal unidirectionnel atteignent la valeur de 850 Mo/s, soit un écart de 75 Mo/s par rapport à unesocketC. En revanche, les débits du service point-à-point et d’un canal unidirectionnel lorsque le mode zéro-copie n’est pas activé stagnent à une valeur de 380 Mo/s. Ainsi, l’utilisation conjointe de notre optimisation zéro-copie pour JXTA-C et de PadicoTM permet de pleinement tirer parti des performances des SAN en termes de débit. Cela constitue une amélioration du débit des couches de communication de JXTA par un facteur de 2,2. L’impact sur les débits de notre optimisation zéro-copie est donc significative. En termes de latence, l’utilisation de PadicoTM permet comme attendu d’éviter le sur-coût du passage par la couche TCP/IP du noyau. En effet, les gains sont de 37µs et de 38µs pour respectivement le service point-à-point et un canal unidirectionnel de JXTA-C 2.3 au-dessus de PadicoTM. Ces valeurs correspondent bien à la latence d’unesocketC ne s’exécu-tant pas au-dessus de PadicoTM (pour rappel de 39 µs, voir tableau 10.2). Le tableau 10.3 résume ces performances.

Ecriture 20 40 60 80 100 120 140 160 8Mo 2Mo 512 128 64 32 16 8 4 2 1 0.5 Débit (Mo/s) Taille de la donnée en ko Lecture 0

FIG. 10.9 – Débits des opérations de lecture et d’écriture de JUXMEM-C 0.3 sur un réseau Myri-10G au-dessus de PadicoTM.

Évaluation de l’impact sur les performances de JUXMEM. L’évaluation que nous avons réalisée des performances de la couche de communication de JUXMEM-C 0.3, sur un réseau Myri-10G au-dessus de PadicoTM, montre des performances en termes de débit similaires à celles d’un un canal unidirectionnel de JXTA-C (850 Mo/s). La latence est améliorée de 55µs et atteint une valeur de 72µs. Cette diminution est supérieure à celle attendue et s’explique par des optimisations mineures réalisées dans la couche de communication de JUXMEM-C entre la version 0.2 et 0.3. Ces optimisations consistent en une réduction de la taille totale d’un message de 1 octet applicatif.

La figure 10.9 présente les débits des opérations de lecture et d’écriture de JUXMEM-C 0.3 sur un réseau Myri-10G et au-dessus de PadicoTM. Le débit maximal d’une lecture est de 143 Mo/s, alors que le débit maximal d’une écriture est de 130 Mo/s. Il sont atteints pour une taille de données de 2 Mo dans les deux cas. Par rapport aux résultats du même test sur un réseau Gigabit Ethernet (voir section 7.5), les gains en termes de débit pour une lecture et une écriture sont respectivement de 51 Mo/s et 38 Mo/s (soit des gains respec-tifs de 36 % et 30 %). Ces gains sont relativement faibles et s’expliquent principalement par le nombre de messages réseaux nécessaires pour une opération de lecture ou d’écriture : 4 mes-sages dans les deux cas (voir section 7.5 pour plus d’explications). Toutefois, une évaluation des zones de code les plus coûteuses grâce aux outilscallgrindetkcachegrindest nécessaire pour confirmer cette hypothèse ainsi qu’améliorer les latences de traitement de la couches, encore expérimentale, de gestion de tolérance aux fautes dans JUXMEM-C 0.3. Par ailleurs, la latence d’une lecture est de 660 µs. La latence d’une écriture est de 710µs. Cette absence de gain, pour l’opération de lecture, du fait de la non traversée de la couche TCP/IP du noyau n’est pas expliquée à ce jour. La dégradation de la latence pour l’opération d’écriture n’est également pas expliquée.

10.3 – Discussion et conclusion 159

10.3 Discussion et conclusion

Dans ce chapitre, nous avons tout d’abord présenté le fonctionnement interne des couches de communication de JXTA, telles qu’elles sont implémentées dans JXTA-C et JXTA-J2SE. Avant de détailler les optimisations que nous avons réalisées dans ces couches, nous avons introduit notre motivation ainsi que notre méthodologie de test. Notre démarche s’inscrit dans un contexte de convergence des systèmes P2P et des intergiciels pour les grilles de calcul. Elle fait naître, dans un premier temps, le besoin de tester l’adéquation des biblio-thèques P2P pour le développement d’intergiciels pour les grilles de calcul. Puis, dans un deuxième temps, apparaît la nécessité d’adapter ces bibliothèques P2P aux grilles de calcul, notamment afin de tirer parti des capacités offertes par les réseaux haute performance dispo-nibles dans ces infrastructures. Pour ce faire, nous avons détaillé les optimisations que nous avons réalisées ainsi que leurs impacts sur les performances des couches de communication de JXTA-C, mais également de JUXMEM-C. Enfin, dans une dernière étape pour pleinement et de manière transparente tirer parti des capacités des réseaux haute performance, nous avons montré comment obtenir des communications zéro-copie grâce au portage de JXTA-C au-dessus de la plate-forme haute performance de communication pour grilles PadicoTM. Afin de valider ce portage, des évaluations sur divers types de réseaux ont été menées sur la grille expérimentale Grid’5000, infrastructure présentée au chapitre 2.

L’évaluation que nous avons menée nous a permis de constater les mauvaises perfor-mances initiales des couches de communication de JXTA, notamment en termes de latence. Nous avons montré comment nous y avons remédié par diverses optimisations. Nous avons ainsi démontré l’adéquation des bibliothèques P2P dans le contexte des grilles de calcul, en particulier pour le transfert de données. En effet, les débits obtenus répondent aux exi-gences des performances des applications de calcul sur grilles. En particulier, l’utilisation conjointe : 1) de notre possibilité d’utiliser les couches de communications de JXTA-C en mode zéro-copie et 2) de PadicoTM, permet de pleinement tirer parti des performances des SAN en termes de débit. En outre, ces optimisations nous ont permis d’améliorer les per-formances de la couche de communication de JUXMEM, et en conséquence, d’améliorer les performances des lectures et des écritures au sein de JUXMEM.

Toutefois, le scénario de déploiement que nous considérons pour notre test bidirection-nel de bande passante suppose des communications directes entre toutes les machines. Ceci n’est toutefois pas toujours possible. En effet, sur certaines grilles de calcul les communi-cations entre les machines d’une grappe ne peuvent avoir lieu que par l’intermédiaire des machines ditsfrontauxde chaque grappe. Dans ce cas, d’autres évaluations sont nécessaires. Concernant l’implémentation du portage de JXTA au-dessus de PadicoTM, les modi-fications qu’il faut apporter à APR pour l’utilisation de Marcel ne seront plus nécessaires dans le futur. En effet, des travaux sont actuellement en cours dans la bibliothèque de pro-cessus léger Marcel pour un meilleur support de l’interfacepthread. Un meilleur support des signaux est également en cours d’implémentation, ce qui permet d’envisager à terme le por-tage de JXTA-J2SE au-dessus de PadicoTM. Enfin, le porpor-tage que nous avons réalisé d’APR permet également d’envisager le support dans PadicoTM d’autres intergiciels se basant sur APR. Nous pouvons notamment citer le serveur Web majoritairement utilisé aujourd’hui : Apache. Ce travail ouvre donc des perspectives pour, par exemple, l’équilibrage de charge entre différents serveurs Web et cela de manière transparente sur les SAN.

Chapitre

11

Déploiement d’applications JXTA sur

une infrastructure de type grille

Sommaire

11.1 Utilisation d’une approche pair-à-pair sur les grilles de calcul . . . 162 11.2 Déploiement d’applications basées sur JXTA . . . 163

11.2.1 Une première approche : JDF . . . 163 11.2.2 Proposition d’un langage de description . . . 164 11.2.3 Mise en œuvre au sein de l’outil de déploiement ADAGE . . . 166

11.3 Évaluation du passage à l’échelle de JXTA . . . 167

11.3.1 Protocole de gestion de vue . . . 167 11.3.2 Conditions expérimentales et résultats . . . 169

11.4 Discussion et conclusion . . . 172

Le dernier chapitre de cette partie présente notre contribution à l’utilisation d’applica-tions basées sur JXTA et s’exécutant sur une infrastructure de type grille. À cet effet, nous avons défini un langage qui permet de décrire le réseau de pairs à déployer à partir d’une application basée sur JXTA. Ensuite, afin de valider notre proposition, nous avons évalué le passage à l’échelle d’un protocole de la spécification JXTA. Toutefois, la première motivation de ces travaux a été de permettre le déploiement de JUXMEM à grande échelle, notamment sur la grille expérimentale Grid’5000 [51]. Ainsi, les expérimentations présentées dans le chapitre 8 ont pu être menées grâce à la contribution qui fait l’objet de ce chapitre.

Dans un premier temps, nous présentons le contexte de ce travail : la convergence entre grilles de calcul et environnements pair-à-pair (P2P). Puis, nous introduisons les étapes qui nous ont permis d’arriver à notre contribution actuelle : la proposition d’un langage de des-cription des réseaux virtuels JXTA. Ensuite, nous décrivons la mise en œuvre de ce langage au sein de l’outil de déploiement générique ADAGE, à travers un exemple d’utilisation. En

guise de validation et comme nous l’avons indiqué précédemment, nous présentons les ré-sultats de l’évaluation du passage à l’échelle d’un protocole de la spécification JXTA. Enfin, nous terminons par une discussion sur notre proposition.

11.1 Utilisation d’une approche pair-à-pair sur les grilles de calcul

L’utilisation d’une approche P2P pour la programmation d’intergiciels pour les grilles de calcul, énoncée dans la section 2.5 et rappelée dans la section 10.2.1, constitue notre contexte de travail pour cette contribution. Ainsi, comme nous l’avons vu dans ces sections, l’idée d’utiliser des mécanismes P2P pour bâtir les intergiciels pour les grilles de calcul est naturelle. En effet, les propriétés du modèle P2P, telles que le passage à l’échelle et la tolé-rance à la volatilité manquent aux intergiciels pour grilles de calcul. Cette utilisation peut être réalisée selon deux manières différentes.

– La première possibilité consiste à intégrer dans les couches basses des systèmes P2P les intergiciels pour grilles de calcul. Par exemple, ils peuvent utiliser les couches de