1 Réunion ANR-CIGC GCPMF 15 mars 2006 Architecture de grille générique, multi- paradigmes et tolérante aux pannes, pour le temps contraint. Application aux calculs financiers. Sébastien Bezzine, Virginie Galtier, Stéphane Vialle

2 Architecture de Grille : - tolérante aux pannes - récupération sur panne en temps limité - assimilation dynamique de nouvelles ressources - équilibrage dynamique de charge - mixant les concepts n-tiers et distribués - supportant limplantation dalgorithmes distribués à couplage faible et à couplage fort Introduction Grilles de nombreux composants : - ressources hétérogènes - pannes inévitables - pannes « fréquentes » … Applications industrielles : - en temps contraint - architecture n-tiers avec BdD - algorithmes variés Paradigme RMI/envoi de messages ET paradigme de mémoire partagée

3 ProActive Middleware de grille et environnement de développement, sous la forme dune bibliothèque Java développée par léquipe OASIS de lINRIA Sophia-Antipolis. Création dobjets actifs sur des machines distantes. Communications asynchrones entre des objets actifs se trouvant sur des machines différentes. Appels de méthodes sur des groupes dobjets actifs. Processeur Objet actif Objet passif Une distribution par « RMI » et « envois de messages » (approximativement), et fortement « extensible » (applicable à des architectures « larges échelles »)

4 JavaSpaces Programmation parallèle aisée, mais a priori destinée à un nombre limité de machines. Existence dun mode « transactionnel » (commit) et dun mode « persistant », plus lent mais tolérant aux pannes, Services sous-jacents (ré)activables en cas de nécessité Une distribution par partage de données dans une mémoire partagée virtuelle sur une grille de PCs (grille de JVM).

5 Architecture de grille + des PCs de réserve ( ε %) Server Client Server TCP SubServer Worker ProActive Worker BD Architecture n-tiers typique des applications industrielles ProActive ? BD JavaSpace « mémoire partagée virtuelle » (on demand)

6 Tolérance aux pannes (1) PC objet actif Server… objet actif Alive PCs de réserve : Détection des pannes Envoi des résultats partiels Server SubServers Workers

7 Tolérance aux pannes (2) PC objet actif Server… objet actif Alive Server SubServers Workers envoi du groupe de workers et du résultat partiel relance des calculs PCs de réserve : Détection des pannes Envoi des résultats partiels

8 Tolérance aux pannes (3) PC objet actif Server… objet actif Alive Server SubServers Workers SubServer Plus aucun PCs de réserve ! Détection des pannes Envoi des résultats partiels

9 Tests avec Pricing Européen Test de larchitecture avec des « pricing européen » par simulations de Monte-Carlo : –Grand nombre de simulations de Monte-Carlo réparties sur les workers (random() sur chaque worker … ), –Problème embarrassingly parallel, –Test de tolérance aux pannes. 3 versions de pricing européen développés à Nice à inclure dans notre testbed n sim. Somme des n résultats jusquà N N « M-C simulations » Workers SubServer Equilibrage dynamique de charge

10 Tolérance aux pannes : res 1 Tests de tolérance aux pannes de workers avec PCs de réserve : –10 Millions de simulations avec 3 SubServers et 24 Workers : 27 minutes. 1 tâche élémentaire de 1000 simulations sur un worker : 3s –Surcoût des pannes de workers dans un même groupe de 5 workers : Pannes simultanées pendant les calculs Panne après envoi des résultats Panne avant envoi des résultats 1 worker0,4 - 0,62,2 – 3,1 2 workers0,7 - 1,92,3 – 3,2 3 workers1,1 - 2,93,8 – 4,8 4 workers1,4 - 3,54,0 – 5,4 5 workers2,5 - 5,55,4 – 7,4 Surcoût de récupération sur panne : - important vis-à-vis dune tâche élémentaire (3s), - faible vis-à-vis de toute lapplication (27mn). Temps supplémentaires de calcul (en secondes)

11 Tolérance aux pannes : res 1 Tests de tolérance aux pannes de workers avec PCs de réserve : –10 Millions de simulations avec 3 SubServers et 24 Workers : 27 minutes. 1 tâche élémentaire de 1000 simulations sur un worker : 3s –Surcoût des pannes de SubServers dans un groupe de 3 SubServers : Surcoût de récupération sur panne : - supérieur aux récupérations de pannes de workers (normal !) - reste faible vis-à-vis de toute lapplication Temps supplémentaires de calcul (en secondes) Pannes simultanées pendant les calculs Panne après envoi du résultat Panne avant envoi du résultat 1 SubServer3,3 - 4,15,1 – 6,7 2 SubServers4,9 - 6,56,4 – 9,2 3 SubServers5,4 – 8,67,6 – 11,5

12 Conclusion et perspectives Distribution en Java & ProActive, équilibrage dynamique de charge, speedup = 20 sur 24 processeurs (efficacité = 83%). Détection et correction automatique des pannes, temps de correction de lordre de quelques secondes, utilisation de machines de réserve si disponibles. Résultats actuels sur des calculs embarrassingly parallel : Développements en cours : Incorporation de JavaSpaces activables à la demande, entre un subserver et ses workers. Incorporation des 3 algorithmes de « pricing européens » développés à Nice (Omega & Oasis).

13 Conclusion et perspectives Amélioration des heuristiques de tolérance aux pannes. Implantation de calculs de risques distribués fortement couplés. Expérimentations sur Grille : Grid5000 en multi-sites. S. Bezzine (stagiaire ingénieur CNAM), V. Galtier et S. Vialle en collaboration avec Omega et Oasis. Perspectives 2006 : Premières expérimentation dutilisation de GPU et insertion dans larchitecture Java développée. M. Ifrim (stagiaire Master UPB), V. Galtier et S. Vialle + … collaborations avec les autres partenaires bienvenues. Bibliothèque générique à base de Java-1.5/Generics, ProActive, JavaSpaces, sur grille de CPU et de GPU.

14 Architecture de grille générique, multi- paradigmes et tolérante aux pannes, pour le temps contraint. Application aux calculs financiers. Questions ?