Laboratoire LSIIT-ICPS
Université Louis Pasteur
Pôle API, Bd Sébastien Brant
F-67400 Illkirch

SUJET DE STAGE DE DEA
 

Guillaume Latu, latu@icps.u-strasbg.fr, bureau B253b, 03.90.24.45.52
Romaric David david@icps.u-strasbg.fr, bureau B222, 03.90.24.45.48

Cadre :

Le développement récent d'infrastructures de type grille fait émerger de nombreuses problématiques au niveau des supportsd'exécution, et de l'algorithmique adaptée à ce type de plate-forme. Au niveau de la communauté du calcul scientifique, un consensus se dégage sur les éléments principaux à prendre en compte lors de la conception d'une application destinée à être implantée sur la grille :

  1. Un cadre typique de grille est celui de clusters interconnectés par un réseau de type WAN. Au sein d'un cluster, les noeuds sont reliés par un réseau rapide. La topologie du réseau est de type hiérarchique. Cette topologie peut par exemple être utilisée pour concevoir des communications collectives efficaces alors que les liens et la puissance des machines sont hétérogènes. Les performances du réseau sont fluctuantes car il n'est pas à usage dédié. L'application doit s'adapter dynamiquement à des liens dont les performances ne sont pas constantes ou alors accepter de subir des pertes d'efficacité. La latence des communications doit être recouverte au maximum grâce à des primitives non bloquantes.
  2. Il est indispensable de prendre en compte les erreurs ou problèmes durant l'exécution, lorsque survient une panne de machine ou de réseau (stratégies de récupération après panne) . Néanmoins, la tolérance aux pannes n'est possible que si l'algorithme utilisé le permet. Ce n'est pas qu'une question de bibliothèque. La connaissance et la gestion des états par lequel passe l'algorithme est une des clés pour réaliser des récupérations.


Objectifs :

  1. Les applications comportant des communications collectives sont extrêmement nombreuses. Mais, les communications collectives lourdes (MPI_Alltoall, MPI_allgather par exemple) sont elles encore possibles sur une architecture de type grille et à quel prix ? Comment prendre en compte pour ces communications, la latence du WAN et sa variabilité, les possibilités de recouvrement par le calcul ? Après une étude bibliographique, un premier travail consistera à évaluer les performances de plusieurs bibliothèques de communications collectives sur une grille [MagPie,MPICH-G2,Lac02,Pacx].
  2. La récupération après erreur par restauration d'un état précédent de l'application est une idée qui connaît actuellement des développements dans les supports exécutifs pour la grille. Dans un code comportant des communications collectives limitées par les latences du WAN, on peut envisager de simultanément sauvegarder l'état dans lequel se trouve chaque processus d'un noeud sur un ou des noeuds voisins de la grille. Cette stratégie permet-elle de réaliser une reprise sur panne dans l'hypothèse forte où un seul noeud tombe en panne à la fois ? Dans un premier temps il sera peut-être plus facile d'examiner le cas d'une sauvegarde inconditionnelle périodique sur disque de l'état du processus du processeurs et celui d'un des processeurs voisins. L'aspect dynamique de la reprise sur panne pourra être écartée dans un premier temps.
  3. Pour cette étude on pourra envisager de regarder tout d'abord MPI_Alltoall et Mpi_Allgather (puis d'autres communications collectives). Dans ce cadre, peut-on reprendre après une panne qui se produit durant l'opération collective ? Peut-on utiliser des protocoles qui permettent à l'opération d'aboutir, même si l'un des noeuds tombe en panne en cours d'opérations ? Peut-on profiter de l'envoi de messages pour passer une information concernant l'état des processus ?
Bibliographie