Etude à plus « grande échelle » – 20.000 oligonucléotides

Pour la deuxième série de test, nous avons considéré un fichier d‘entrée de 20.000 séquences d‘oligonucléotides. L‘exécution de ce fichier d‘entrée contre la même base de référence de BLAST et sur la même machine (cf. partie 4.4.2.1) a pris 2 jours et 19 heures environ. Sachant que la VO Biomed compte 20.000 CPUs, nous avons lancé un calcul à grande échelle mais avec des jobs s‘exécutant rapidement afin de tester le comportement de BLASTOG et de la grille (Tableau 12). En fait, chaque job est estimé à 4 minutes environ mais nous en avons lancé un millier donc chaque fichier contient 20 séquences oligonucléotidiques. Les résultats donnés par le tableau suivant sont ceux attendus.

Mohieddine MISSAOUI Page 159 Tableau 12: Résultat de la simulation pour 1000 petits jobs.

Temps (mn) 0 108 203 1354 1500 2876 3060

Done 0 164 358 598 617 657 662

Other 1000 120 2 0 0 0 0

Running 0 434 423 294 266 237 232

Scheduled 0 282 217 108 117 106 106 En effet, les performances données par la Figure 50 montrent que ce plan d‘exécution représente l‘inconvénient de solliciter la grille pour des jobs très courts. Cela a comme incidence directe de voir le nombre de jobs (Done) parmi les 1000 soumis croitre rapidement jusqu‘à atteindre 600 jobs après 1500 minutes puis ralentir considérablement pour atteindre seulement 660 jobs après 3000 minutes. Ces résultats montrent que la soumission d‘un grand nombre de jobs courts à la grille EGEE, ne permet pas l‘obtention de tous les alignements au bout de la durée théorique d‘exécution sur une seule machine (dans l‘exemple, 2 jours et 19 heures). Cette simulation ne donne pas de bons résultats pour le calcul de l‘alignement en question car nous n‘avons pas obtenu le résultat final escompté. Le problème de fragmentation sur grille de calcul nécessite de connaitre le comportement de chaque fragment mais également d‘être conscients des délais de soumission sur une grille.

Figure 50: Performances de BLASTOG sur la Grille EGEE pour 1000 jobs courts.

Notre algorithme permet de superviser l‘évolution de chaque job correspondant à une partie du calcul. Chaque fragment doit donner son résultat d‘alignement BLAST, faute de quoi, le résultat global est erroné car des alignements manquent. Il est donc primordial de récupérer les

Mohieddine MISSAOUI Page 160 résultats de chaque alignement. En effet, tant que le résultat d‘un fragment n‘est pas disponible, l‘alignement final n‘est pas fini. L‘état de chaque job donne une idée de la disponibilité des résultats des fragments, mais il est obligatoire de vérifier son existence à la fin du calcul sur la grille. Dans la simulation de la Figure 50, seuls les jobs terminés avec des résultats respectifs disponibles sont considérés. Enfin, environ 2 jobs sur 3 sont resoumis à la grille après 12 heures de calcul pour notre exemple.

Afin de trouver un meilleur compromis pour l‘obtention des résultats d‘alignement, un test de 10 jobs longs (environ 6 heures et 40 minutes pour chaque job sur la grille) a été lancé. Dans cet exemple, nous avons lancé 10 fois la même simulation à la grille EGEE. Les calculs sont lancés l‘un après l‘autre en respectant la même charge de calcul. Les résultats sont donnés par le Tableau 13. Les résultats des jobs sont mesurés toutes les 12 heures, jusqu‘à 72 heures. Les simulations qui ont rencontré des problèmes d‘exécution sont surlignées en rose.

Tableau 13: Résultats des simulations pour 10 jobs sur la grille EGEE.

Temps H 0 12 24 36 48 60 72 Simu 1 0 3 4 7 7 10 10 Simu 2 0 0 0 0 0 0 0 Simu 3 0 0 0 0 0 0 0 Simu 4 0 0 0 0 0 1 1 Simu 5 Erreur NC NC NC NC NC NC Simu 6 Erreur NC NC NC NC NC NC Simu 7 0 0 3 8 10 10 10 Simu 8 0 4 10 10 10 10 10 Simu 9 0 6 10 10 10 10 10 Simu 10 0 0 10 10 10 10 10

La simulation (terminée) la plus rapide a mis 15 heures et 38 minutes pour s‘exécuter tandis que la simulation la plus longue a mis 53 heures et 27 minutes pour s‘exécuter, sur les 10 simulations que nous avons réalisées. Cinq simulations n‘ont donné aucun résultat, et deux simulations se sont terminées inopinément avec des erreurs, deux autres simulations ont continué à ne donner aucun résultat au bout de 72 heures et une simulation n‘ayant qu‘un seul job de terminé au bout de 63 heures environ. Dans le cas où les simulations se sont terminés brusquement, nous sommes remontés à l‘origine de l‘erreur et nous avons remarqué qu‘il s‘agissait souvent d‘un problème de connectivité réseau ou d‘un problème d‘arrêt de serveurs distants (élément de la grille : WMS, CE) comme par exemple l‘erreur suivante survenue lors de la récupération du statut d‘un job:

Mohieddine MISSAOUI Page 161 Error while calling the "Status:getStatus" native api

Unable to retrieve the status for:

https://wms.grid.sara.nl:9000/xTUlMm4Y5xvvQr3TneDKEw

edg_wll_JobStatus: Connection refused: edg_wll_gss_connect(): server closed the connection, probably due to overload

Les résultats des 10 simulations exécutées sur une période d‘un mois environ sont donnés par la Figure 51.

Figure 51: Résultats des simulations de BLASTOG pour 10 jobs longs.

Nous remarquons d‘après ces simulations, que BLASTOG dépend fortement de l‘état de la grille de calcul. Et même avec un algorithme de gestion de la supervision des jobs, la grille continue à poser des problèmes de fiabilité qui se répercutent directement sur notre logiciel. Avec 5 simulations sur 10 terminées avec succès, BLASTOG reste fiable lorsque la grille est disponible. D‘après les statistiques obtenues, une solution à ce problème consiste à lancer deux fois le même job sur la grille.

Enfin, pour comparer les résultats sur grille de calcul et les résultats sur Cluster pour notre échelle de données qui reste une échelle non adaptée à la grille de calcul, nous avons lancé les calcul pour les mêmes données sur le Cluster de l‘ISIMA en utilisant un nombre de CPUs croissant. Les résultats sont donnés par la Figure 52. Nous remarquons qu‘un speed-up de 51 est obtenu lorsque MPI-BLAST (Darling et al., 2003) est utilisé sur 128 CPUs. Nous remarquons

Mohieddine MISSAOUI Page 162 donc pour notre cas précis qu‘un Cluster local de petite taille s‘avère beaucoup plus performant que la grille.

Figure 52: Performances de MPI-BLAST sur la ferme de calcul du LIMOS.

Enfin, BLASTOG intègre la plupart des options de base de BLAST. En effet, l‘utilisateur peut choisir la e-value, la taille du mot, le nom du programme, le nombre d‘alignement affichés, le nom du fichier du sortie…etc. Il s‘agit d‘un logiciel totalement indépendant qui peut venir se greffer facilement à n‘importe quel autre logiciel nécessitant une comparaison de séquences à grande échelle. Ses performances sont prometteuses. Il est adapté à des recherches massives de similarités pour des oligonucléotides destinés à être utilisés pou les puces à ADN. En revanche, pour des recherches nécessitant un temps de calcul de l‘ordre de quelques jours (20000 séquences à 100000 séquences), une architecture de type Cluster est mieux adaptée. Des données plus importantes (quelques dizaines de millions à quelques milliards de séquences) nécessitant plusieurs années de calculs sont plus destinées à être traités pour la grille de calcul en espérant une meilleure fiabilité que celle constatée.

Mohieddine MISSAOUI Page 163

5. Conclusion

Dans le cadre de la conception de sondes pour biopuces à ADN destinées à une meilleure compréhension de la diversité microbienne et son impact sur l‘environnement, l‘un des défis majeurs est de traiter une masse très importante de données. L‘ingénierie logicielle d‘une part et le calcul haute-performance d‘autre part représentent des clés essentielles pour l‘exploitation à haut-débit de ces mines d‘informations dans des temps raisonnables. L‘ingénierie dirigée par les modèles permet à l‘aide d‘une démarche logicielle qui repose sur la méta-modélisation de représenter tous les aspects du développement d‘un logiciel, de sa conception à son exploitation et ainsi proposer des solutions plus performantes et/ou plus précises grâce notamment à la génération de code. Les architectures parallèles telles que les fermes et les grilles de calcul apportent quant à elles une plus-value précieuse au niveau du gain du temps. Dans la suite, nous étudierons les applications développées durant cette thèse et qui exploitent ces technologies.

Mohieddine MISSAOUI Page 165