Télécharger le fichier original (Mémoire de fin d’études)
Environnements d’ex´ecution communicants
Les grappes de calculateurs repr´esentent une architecture distribu´ee. Par cons´equent, les ´echanges de messages sur le r´eseau d’interconnexion sont obligatoires pour toute ap-plication parall`ele d´eploy´ee sur plusieurs nœuds.
Dans un syst`emes a` image unique les applications peuvent ˆetre programm´ees selon deux mod`eles distincts : la programmation par m´emoire partag´ee et la programma-tion par ´echange de messages. Nous ´ecartons le cas des applications hybrides. Une application hybride est une application exploitant a` la fois un mod`ele de m´emoire par-tag´ee pour certains calculs, et un mod`ele par ´echange de messages pour d’autres types d’op´erations. Par d´efinition, une application hybride est (sous l’angle des communica-tions) la combinaison des caract´eristiques de chacun des deux mod`eles d´ej`a cit´es.
Dans la suite de ce chapitre, nous abordons tout d’abord tr`es bri`evement les en-vironnements d’ex´ecution d’applications parall`eles communiquant par m´emoire par-tag´ee. Dans un second temps, nous ´etudions de mani`ere d´etaill´ee les environnements d’ex´ecution d’application parall`ele communiquant par ´echange de messages.
Notre ´etude des environnements d’ex´ecution d’application communiquant par ´echange de messages est cibl´ee sur les aspects de communication. Plus pr´ecis´ement, nous nous int´eressons a` la fa¸con dont sont mises en œuvre, dans ces environnements, les propri´et´es qui nous semblent souhaitables d’offrir aux applications fond´ees sur le mod`ele de com-munication par message dans les syst`emes a` image unique. Le paragraphe 2.5 r´esume les points cl´es du chapitre.
Ce chapitre ne constitue pas une ´etude exhaustive de ces probl´ematiques. Au contraire, il s’agit de pr´esenter certains des travaux les plus significatifs ayant trait´e de ces diff´erents aspects.
Environnement d’ex´ecution d’applications communi-quant par m´emoire partag´ee
Le mod`ele de programmation a` m´emoire partag´ee est issu des machines parall`eles a` m´emoire partag´ee. Dans ce mod`ele, les diff´erents processus d’une application parall`ele partagent une m´emoire commune. Lorsqu’un processus a besoin d’une donn´ee, il lui suffit de consulter son espace m´emoire. Les probl`emes de synchronisation peuvent ˆetre r´esolus par l’emploi de verrous directement contenus dans la m´emoire partag´ee. Il n’est donc pas n´ecessaire d’utiliser une autre forme de communication entre les processus.
Dans le monde des machines parall`eles, le partage de la m´emoire est r´ealis´e de mani`ere mat´erielle par la machine. Dans le monde des grappes de calculateurs, il est n´ecessaire de simuler le partage de la m´emoire a` l’aide d’un syst`eme de m´emoire par-tag´ee r´epartie (Distributed Shared Memory –DSM[51]). Les DSM ont ´et´e d´evelopp´ees en tant qu’extension du syst`eme d’exploitation (SCIOS[45]) ou plus fr´equemment en tant qu’intergiciel (Shasta[72], Blizzard-S[74], Mome[37]). A l’aide d’un tel syst`eme, des applications exploitant le principe de la m´emoire partag´ee peuvent ˆetre d´eploy´ees et ex´ecut´ees sur des grappes de calculateurs sans modification majeure de leur mod`ele de programmation .
Par cons´equent, l’ensemble des communications sur le r´eseau d’interconnexion n’est pas directement r´ealis´e par l’application mais par le syst`eme DSM suite aux d´efauts de page de celle-ci. Ce principe reste vrai, lorsque pour des raisons de performance, le syst`eme de verrou est pris en charge par un service d´edi´e et non plus directement par la DSM : les communications par le r´eseau d’interconnexion, sont masqu´ees par l’environnement de la grappe de calculateurs (syst`emes d’exploitation ou intergiciel sp´ecifique).
Dans le reste du chapitre, nous nous int´eressons aux mod`eles de programmation fond´es sur des communications explicites.
Environnement d’ex´ecution d’applications communi-quant par message
A la diff´erence du mod`ele pr´ec´edent, le concepteur d’une application parall`ele peut vouloir contrˆoler lui-mˆeme les ´echanges de messages sur le r´eseau d’interconnexion. Pour cela, il peut choisir de programmer a` partir de primitives de communication de bas niveau, ou au contraire de s’appuyer sur des environnements de communication existants.
Primitives de communication de bas niveau
D´efinition 19 Primitive de communication: Nous appelons primitive de com-munication un outil logiciel ne traitant que la probl´ematique des communications.
Les primitives de communication se caract´erisent par un service enti`erement ax´e sur un mod`ele de communication. Les primitives de communication correspondent :
Environnement d’ex´ecution d’applications communiquant par message 27
– aux interfaces de programmation fournies pour le mat´eriel d’interconnexion choisi : GM[59, 60], MX[61] pour Myrinet, SCICI[34] pour SCI, IB access[69] pour Infi-niband, etc.
– aux protocoles de communication, par exemple l’interface socket [83].
Une ´etude des propri´et´es li´ees aux performances de ces primitives de communication est r´ealis´ee dans le chapitre suivant.
Chacune de ces primitives de communication est sp´ecifique a` un mat´eriel ou un protocole de communication. Par cons´equent, une application parall`ele utilisant de telles primitives, est sp´ecifiquement ´ecrite pour un mat´eriel ou pour un protocole de communication donn´e. L’int´erˆet d’utiliser de telles primitives de communication est :
– de pouvoir mettre en œuvre un mod`ele de communication tr`es sp´ecifique non offert par un environnement de communication,
– d’esp´erer b´en´eficier des meilleurs performances possibles (en terme de bande passante ou de latence) en r´eduisant les interm´ediaires entre l’application et le syst`eme de communication.
Consid´erons maintenant la propri´et´e de calcul de point de reprise et celle du chan-gement dynamique de configutation de la grappe de calculateurs. Le support de ces propri´et´es dans des applications exploitant des primitives de communication de bas niveau ne peut ˆetre r´ealis´e que dans l’application elle-mˆeme. Un tel ajout pr´esente deux inconv´enients. D’une part, il est r´ealis´e application par application. D’autre part, le code utile (pour fournir le r´esultat attendu) de l’application est noy´e dans le code g´erant le syst`eme de communication et les propri´et´es associ´ees.
Environnement de communication
Comme soulign´e pr´ec´edemment, le foisonnement des technologies de communica-tion a entraˆın´e la cr´eation d’un grand nombre d’interfaces de communication sp´ecifiques ainsi que de protocoles de communication. De plus, ces primitives de communication ne fournissent pas toutes le mˆeme niveau d’abstraction des communications, ni mˆeme des fonctionnalit´es ´equivalentes. Par cons´equent, la r´ealisation d’une application avec de telles primitives limite grandement leur portabilit´e sur d’autres architectures de com-munication. C’est en partie pour r´epondre au probl`eme de l’h´et´erog´en´eit´e des mat´eriels de communication que des environnement de communication ont ´et´e cr´e´es.
D´efinition 20 Environnement de communication: Nous appelons environne-ment de communication un intergiciel offrant, a` partir de primitives de communi-cation vari´ees, un mod`ele commun des communications ainsi qu’un mod`ele commun d’ex´ecution.
Architectures de type parall`ele Les ancˆetres des environnements de communica-tion sont des outils comme la biblioth`eque P4[22] ou PARMACS[66]. P4 est un ensemble de macros et de fonctions, d´evelopp´e par le Argonne National Laboratory afin d’aider au d´eveloppement d’applications distribu´ees ind´ependantes de l’architecture mat´erielle
28 Environnements d’ex´ecution communicants
(principalement des machines parall`eles). Ainsi, P4 fournit notamment les briques de base pour ´emettre et recevoir des donn´ees et cr´eer des processus sur des nœuds distants.
L’aboutissement des abstractions successives des syst`emes de communication ainsi que des mod`eles d’ex´ecution aura ´et´e le syst`eme PVM[92] qui propose un mod`ele d’abs-traction de la machine elle-mˆeme. A partir d’un fichier de configuration, PVM d´eploie un ensemble de processus (appel´es daemons) repr´esentant la machine parall`ele. Lors-qu’une application ´ecrite pour PVM lui est soumise, les daemons cr´eent les processus de l’application parall`ele et en assurent le contrˆole. Les communications entre processus de l’application sont intercept´ees et transmises par les daemons (figure 2.1). Dans cet exemple, afin de communiquer avec le processus applicatif P3, les processus P1 et P2 passent par l’interm´ediaire des daemons D1 et D2.
Table des matières
Introduction
1 Introduction aux grappes de calculateurs
1.1 Denitions et proprietes generales
1.1.1 Le systeme d’exploitation
1.1.2 Les systemes de communication
1.2 Grappes de calculateurs
1.3 Systeme a image unique
1.4 Synthese
2 Environnements d’execution communicants
2.1 Environnement d’execution d’applications communiquant par memoire
partagee
2.2 Environnement d’execution d’applications communiquant par message .
2.2.1 Primitives de communication de bas niveau
2.2.2 Environnement de communication
2.3 Recherche de la performance dans les environnements de communication
par message
2.4 Support au deplacement des processus dans les environnements de communication
2.4.1 Tolerance aux fautes dans les environnement de communication
par des techniques de point de reprise
2.5 Conclusion
3 Infrastructure de communication dans les grappes de calculateurs
3.1 Infrastructure materielle et gestionnaires de communication
3.1.1 Systeme de communication par le SE
3.1.2 Acces direct aux materiels de communication
3.2 Modeles de communication
3.3 Conclusion
4 Introduction aux systemes a image unique
4.1 Classication des systemes a image unique
4.2 Presentation d’un systeme a image unique : Kerrighed
4.3 Gestion globale de la memoire
4.3.1 Architecture de la memoire
4.3.2 Prol de communication
4.4 Gestion globale des processus
4.4.1 Architecture de la gestion des processus
4.4.2 Prol de communication
4.5 Gestion globale des synchronisations
4.6 Synthese
5 Systeme de communication pour un systeme a image unique
5.1 Synthese des communications dans les grappes
5.2 Modele de communication d’un service systeme distribue
5.3 Modele de communication pour une application communiquant par echange
de messages
5.4 Transaction de communication
5.5 Flux dynamiques
5.6 Architecture globale du systeme de communication
6 Architecture de communication pour un systeme a image unique
6.1 Caracteristiques des materiels et des protocoles de communication envisages
6.2 Modele de communication au sein d’un SSI
6.3 Modele de materiel de communication
6.4 Modele de protocoles de communication
6.5 Gestion des proprietes generiques dans l’infrastructure de protocoles .
6.5.1 Gestion de l’identication des nuds
6.5.2 Gestion de la fragmentation
6.5.3 Gestion des retransmissions
6.5.4 Gestion de l’ordre des messages
6.5.5 Modele d’emission de message
6.5.6 Modele de reception de message
6.6 Resume
7 Systeme de communication pour services distribues
7.1 Cadre de l’etude
7.2 Concepts generaux lies aux transactions de communication
7.3 Les transactions de communication
7.3.1 Transaction de communication
7.3.2 Element de transaction
7.3.3 Contexte de transaction
7.4 Resume
