Organisation gŽnŽrale

Nous avons vu, dans le Chapitre 3 (Architecture du noyau PARX) que sur chaque pro-cesseur de la machine parall•le sÕexŽcute le micro-noyau qui offre diffŽrents niveaux de machines virtuelles. Au dessus, des sous-syst•mes fournissent un environnement de dŽ-veloppement et dÕexŽcution des applications, chaque syst•me mettant en Ïuvre un en-semble de politiques qui lui est propre, ˆ partir des mŽcanismes de base fournis par ce µ-noyau. ParObj fait partie de ces sous-syst•mes.

Chaque sous-syst•me est constituŽ dÕun certain nombre de clusters sur lesquels sÕexŽcu-tent des Pt‰ches dont le r™le est la gestion et lÕadministration des Pt‰ches utilisateurs de la machine.

Dans PARX, un cluster fournit un domaine de communication dans lequel chaque processeur dispose dÕune table de routage qui lui permet dÕenvoyer un message vers nÕimporte quel autre processeur du cluster. Ceci Žtant, en dehors du cluster, il nÕest pas toujours possible de trouver un chemin pour atteindre nÕimporte quel processeur de la machine (cÕest le cas par exemple, pour les machines de type Supernode). Dans ce cas, il est fort possible quÕˆ la suite dÕune reconfiguration de la machine, deux Pt‰ches quelconques ne puissent pas ou plus communiquer entre elles, Cf. figure 5.1, ce qui peut sÕavŽrer relativement problŽmatique !

?

?

?

Chapitre 5 : Gestion des entitŽs dans ParObj

ƒvidemment sur des machines ˆ topologies fixes (i.e. non reconfigurables) ces pro-bl•mes ne se posent pas, puisque nÕimporte quel processeur de la machine peut •tre at-teint. Mais comme nous devons tenir compte de toutes les architectures, nous devons aussi traiter le cas des machines dynamiquement reconfigurables.

Le seul moyen alors pour faire communiquer deux clusters, indŽpendamment de lÕar-chitecture, et de disposer de un ou plusieurs processeurs sur chaque clusters et qui Žta-blissent un pont de communication entre les clusters (ces ponts, que nous appelons

P-connecteurs, peuvent Žventuellement changer de place au cours du temps, au fur et ˆ

mesure que des nouveaux clusters se crŽent ou disparaissent).

Ainsi tout message qui sort du cluster devra passer par ce ou ces processeurs, qui sont les seuls ˆ avoir dans leurs tables de routages les informations nŽcessaires pour envoyer le message en dehors du cluster, Cf. figure 5.2.

Cluster Syst•me Cluster Utilisateur Ponts de communication Cluster Utilisateur

Figure 5.2. Ponts de communication entre cluster

Nous avons donc rŽsolu nos probl•mes de communication. Cependant la solution pro-posŽe nÕest pas satisfaisante pour plusieurs raisons :

¥ Les Pt‰ches utilisateur (qui sont sur les clusters utilisateurs) ont directement ac-c•s, via le pont de communication, au cluster syst•me, ce qui peut entra”ner des probl•mes de protection du syst•me.

¥ Chaque Pt‰che utilisateur a besoin dÕ•tre contr™lŽe (pour garantir sa bonne exŽcu-tion). Cela signifie que le syst•me doit assigner un certain nombre de processeurs de son cluster ˆ la rŽalisation de ce travail. Conclusion, plus le nombre de Pt‰ches va croitre, et plus le syst•me risque de rŽserver de processeurs pour leur gestion, entra”nant un temps de rŽponse de plus en plus lent de la part du syst•me (soit

Chapitre 5 : Gestion des entitŽs dans ParObj

parce quÕil aura de moins en moins de processeurs pour ses propres activitŽs, soit, dans le cas de machines reconfigurables, parce quÕil passera son temps ˆ reconfi-gurer son cluster en y ajoutant rŽguli•rement des processeurs, paralysant ainsi toutes ou une partie des communications entre lui et le reste de la machine). Nous pensons donc quÕil est nŽcessaire dÕintroduire un nouveau cluster syst•me dont le r™le sera la gestion des diffŽrentes Pt‰ches utilisateurs et la communication entre toutes les Pt‰ches (utilisatrices ou syst•me) de la machine.

Cette idŽe dÕune interface entre le syst•me et les utilisateurs nÕest pas nouvelle. Ainsi, par exemple dans PEACE [Sc90], chaque cluster de la machine SUPRENUM est constituŽ de plusieurs nÏuds (un ou plusieurs processeurs) dont un certain nombre est rŽservŽ pour lÕinterface entre des disques, pour Žtablir la communication entre les clus-ters (appelŽs nÏuds de communication), et pour rŽaliser des diagnostics.

Ce cluster ayant pour r™le la gestion des Pt‰ches utilisateurs, lÕinterface avec le syst•me et la communication entre Pt‰ches, nous lÕappellerons cluster de contr™le. Ce cluster nÕŽtant constituŽ que dÕune seule Pt‰che, nous la dŽsignerons sous le nom de Pt‰che de

contr™le.

SÕil existe un ou plusieurs cluster mŽmoire dans la machine, ils devront avoir des ponts de communication non seulement avec le cluster syst•me, mais aussi avec le cluster de contr™le, ceci afin dÕaugmenter le dŽbit de transfert des donnŽes entre le syst•me et les Pt‰ches utilisateurs. En aucun cas cependant, pour les m•mes raisons Žvidentes de sŽcu-ritŽ, un cluster mŽmoire ne devra avoir un pont en commun avec un cluster utilisateur. La figure 5.3 donne un aper•u gŽnŽral de lÕarchitecture du syst•me ParObj. Nous expli-quons plus en dŽtail, dans les sections suivantes, le r™le des diffŽrents clusters et des diffŽrentes Pt‰ches du syst•me.

Chapitre 5 : Gestion des entitŽs dans ParObj

Figure 5.3. Architecture du sous-syst•me ParObj

5.2.1.1 Le cluster de contr™le

Chaque fois quÕune Pt‰che est lancŽe, le chargeur (qui est une Pt‰che du cluster sys-t•me) choisi un processeur de ce cluster. Ce processeur devient alors le processeur de

contr™le de gestion de la Pt‰che qui vient dÕ•tre lancŽe (Cf. chapitre 5.2.3 chargement

dÕune Pt‰che pour plus dÕinformations). IdŽalement, ˆ chaque crŽation dÕune Pt‰che

utilisateur, un processeur de contr™le devrait lui •tre assignŽe. Cependant, cette solution sÕavŽre cožteuse en processeurs lorsque un nombre important de Pt‰ches sÕexŽcutent sur la machine. Aussi, chaque processeur du cluster de contr™le devra •tre capable de gŽrer plusieurs Pt‰ches utilisateurs.

Un autre avantage de disposer dÕun cluster de contr™le, rŽside dans le fait que la recon-figuration de ce cluster (par exemple ˆ la suite de lÕajout de nouveaux processeurs) nÕentra”ne pas lÕarr•t du cluster syst•me, seules les communications entre les diffŽrentes Pt‰ches Žtant affectŽes.

5.2.1.2 Le cluster mŽmoire

Comme nous lÕavons dŽjˆ expliquŽ dans le chapitre 5.1.2 sur la gestion mŽmoire, le r™le de la Pt‰che mŽmoire est dÕoffrir une zone de mŽmoire auxiliaire aux applications. Ce service doit Žvidemment •tre compl•tement transparent ˆ lÕutilisateur.

Chapitre 5 : Gestion des entitŽs dans ParObj

CÕest le nerf du syst•me, et il est composŽ de plusieurs Pt‰ches (Cf. figure 5.4) que nous appelons Pt‰ches syst•mes par opposition aux Pt‰ches utilisateurs.

Pt‰che de distribution

des services ^{Pt‰che des} services syst•mes Pt‰che de contr™le du syst•me Pt‰che mŽmoire syst•me chargeur

Pt‰che de gestion des pŽriphŽriques

Figure 5.4. Le cluster syst•me

DŽcrivons maintenant un peu plus en dŽtail le contenu de chaque Pt‰che. Dans le clus-ter syst•me nous avons :

¥ la Pt‰che de contr™le du syst•me qui enregistre la localisation et lÕŽtat (suspendu, en cours dÕexŽcution, etc.) des diffŽrentes Pt‰ches de la machine, qui garde la trace des diffŽrents environnements et des diffŽrentes pŽriphŽriques disponibles (disques, Žcrans, imprimantes, etc.), et qui tient ˆ jour lÕŽtat des ressources dispo-nibles (processeurs, fichiers, ports, etc.).

¥ la Pt‰che des services syst•me qui contient des programmes syst•mes tels que le

chargeur dÕapplication, lÕallocateur dÕentitŽs aux processeurs, le gestionnaire de fichiers, etc.

¥ la Pt‰che de pilotage des pŽriphŽriques qui comme son nom lÕindique sÕoccupe de la gestion des pŽriphŽriques.

¥ la Pt‰che de reconfiguration de la machine qui sÕoccupe de tout lÕaspect reconfi-guration de la machine (quand cette fonctionnalitŽ est disponible). Ainsi, ˆ titre dÕexemple, sur les machines de type Supernode, cette Pt‰che englobera tout les transputers qui g•rent les commutateurs du deuxi•me niveau.

Chapitre 5 : Gestion des entitŽs dans ParObj

¥ la Pt‰che mŽmoire syst•me qui sert de zone mŽmoire tampon pour les diffŽrents Pt‰ches du cluster syst•me (par exemple pour stocker temporairement une Pt‰che en cours de chargement).

¥ la Pt‰che de distribution de services qui sert uniquement ˆ recevoir les requ•tes venant des Pt‰ches du Òmonde extŽrieurÓ (i.e. qui ne sont pas sur le cluster sys-t•me) et ˆ les rediriger vers les services correspondants (serveur de fichier, ges-tionnaire des Pt‰ches, etc.). Cette Pt‰che est tr•s utile lorsquÕil nÕest plus possible dÕatteindre directement un service syst•me donnŽ, par exemple parce que tous ces acc•s directs sont utilisŽs.

5.2.1.4 Les services syst•me

Il nous reste ˆ prŽciser le contenu de chaque processeur dÕun cluster dans PARX. Nous avons vu que tout processeur dispose dÕun µ-noyau qui offre diffŽrents niveaux de ma-chines virtuelles. Au dessus de ce noyau, sÕexŽcutent un certain nombre de services sys-t•me (des serveurs) qui assurent la dŽsignation, la gestion des entitŽs, la gestion mŽ-moire, etc. Cette approche serveur qui permet de bien structurer un syst•me et de le rendre facilement extensible, est utilisŽe dans la plupart des syst•mes distribuŽs actuels. Le serveur de noms se charge de gŽnŽrer les identificateurs dÕentitŽs, le serveur

dÕenti-tŽs supervise la crŽation et la destruction des entidÕenti-tŽs. Il se charge aussi de rŽsoudre les

acc•s aux entitŽs, et les probl•mes de localisation et de migration de ces m•mes entitŽs, Cf. chapitre 5.2.1 dŽsignation et 5.2.4 gestion des entitŽs ˆ lÕexŽcution pour plus dÕinformation. Le serveur mŽmoire, enfin, a pour responsabilitŽ la gestion mŽmoire au sein de la Pt‰che.

Tous ces serveurs fonctionnent de mani•re autonome lorsque lÕinformation demandŽe peut •tre satisfaite localement (par exemple pour la crŽation dÕune entitŽ statique), et sÕadresse ˆ des serveurs qui ont une vision plus globale dans le cas contraire. Ainsi la crŽation dÕune t‰che globale va obliger le serveur de nom local ˆ demander au serveur de nom du processeur de contr™le un identificateur pour cette t‰che. De m•me si un ser-veur du processeur de contr™le ne peut dŽcouvrir lÕinformation recherchŽe, il sÕadres-sera ˆ un serveur du cluster syst•me. Si le cluster syst•me ne peut satisfaire la requ•te, cÕest une erreur.

La figure 5.5 dŽtaille le cheminement dÕune requ•te adressŽe au serveur dÕentitŽs, qui ne pouvant pas •tre satisfaite localement, part vers le serveur dÕentitŽs du processeur de contr™le. Celui-ci nÕŽtant pas plus capable de traiter la requ•te, envoie finalement le message vers le cluster syst•me, o• le serveur dÕentitŽs syst•me pourra normalement rŽpondre ˆ la demande.

Chapitre 5 : Gestion des entitŽs dans ParObj

? Ok

Cluster Utilisateur

: d'entitŽs : divers : de nom : mŽmoire

Serveur

Processeur de contr™le de la Pt‰che

Cluster de contr™le Cluster syst•me

µ-noyau serveurs ParObj

Pt‰che utilisateur

requ•te non connue localement

Un autre processeur de contr™le Un processeur du syst•me

...

Figure 5.5. Communication entre les diffŽrents serveurs dans PARX