Chapitre II : Le JMS pour la machine MPC
II.2 Les règles de fonctionnement du JMS pour MPC
Il est à retenir du paragraphe précédant, que le JMS de la machine MPC a deux objectifs principaux qui sont :
½ Gérer l’utilisation du réseau HSL et de PVM pour MPC ce qui signifie :
automatiser le chargement des drivers CMEM et HSL
automatiser le démarrage des démons KVOFOLHQW et KVOVHUYHU
automatiser le chargement du driver PVMDRIVER
automatiser le démarrage du démon PVM
½ Permettre à plusieurs utilisateurs de tester leur application PVM sur la machine MPC ce qui se rapproche des fonctionnalités de tous les JMS
,,3ULQFLSHJpQpUDO
La figure ci-dessous montre comment se décompose le JMS pour la machine MPC.
Le JMS pour la machine MPC se décompose en trois principaux éléments :
½ Les queues (ou files d’attente) qui permettent aux utilisateurs de lancer leurs applications PVM-MPC
½ Le calendrier qui permet de définir différents types de périodes et éventuellement d’attribuer certaines périodes à un utilisateur.
½ L’exécutif gère l’ensemble du JMS. En particulier, il applique les priorités définies à la fois par le calendrier et par la queue dans laquelle l’application à exécuter se trouve.
Le JMS a les caractéristiques suivantes :
½ /H-06QHSHUPHWG¶H[pFXWHUTX¶XQHVHXOHDSSOLFDWLRQ39003&jODIRLV
Ce choix est expliqué à la section &KDSLWUH,,3RXUTXRLFHVFKRL["
½ Le JMS est prévu pour fonctionner sur une architecture équivalente à celle de la machine MPC du LIP6. Cette architecture a été décrite à la section &KDSLWUH,,, 'HVFULSWLRQGHODPDFKLQH03&.
½ Le nombre de nœuds de calcul est paramétrable.
½ Chaque utilisateur doit posséder un compte UNIX non seulement sur la console mais aussi sur chacun des nœuds de calcul.
½ Le JMS de la machine MPC est prévu pour fonctionner sous Unix FreeBSD. Cependant, le JMS peut fonctionner sur la plupart des plates-formes UNIX à condition d’effectuer quelques modifications.
½ Les utilisateurs bénéficient de GHX[LQWHUIDFHV pour utiliser le JMS : une interface WEB et la ligne de commande.
,,/HVTXHXHV
La )LJXUH ci-dessus présente les files d’attente qui compose le JMS. L’utilisateur a le choix entre 3 files lorsqu’il veut exécuter une application PVM-MPC :
½ Une queue rapide 4
½ Une queue moyenne 4
½ Une queue lente 4
Ces queues sont des files d’attente de type FIFO (ILUVWLQILUVWRXW). Cela se traduit par une première règle de priorité :
3 si deux applications utilisateurs sont dans une même queue et ont des priorités égales par ailleurs, l’application qui a été mise en queue la première sera prioritaire sur l’autre.
Chacune de ces files d’attente a un paramètre 7PD[ fixé par l’administrateur. Tmax représente le temps (en minutes) d’exécution maximal des applications issues de la file. Il faut cependant respecter l’inégalité suivante :
7PD[4<7PD[4<7PD[4
On peut par exemple fixer TmaxQ1 = 10 mns, TmaxQ2 = 60 mns, TmaxQ3 = 600 mns. C’est pour cela que Q1 est appelée TXHXHUDSLGH, Q3 TXHXHOHQWH… Si le temps d’exécution d’une application issue d’une de ces 3 files dépasse le temps Tmax associée à cette file, l’application est tuée ainsi que tous les processus qu’elle a créés.
Cette classification des queues se traduit par une deuxième règle de priorité :
3 une application issue de la queue rapide est prioritaire sur une application issue de la queue moyenne, elle-même prioritaire sur une application issue de la queue lente. P2 est supérieure à P1.
Une dernière file compose le JMS : la queue 2/'. Celle-ci réceptionne les applications dont l’exécution a été lancée. Elle permet de garder une trace des applications qui ont été exécutées.
Quand une application est mise en queue, les informations suivantes doivent être conservées :
½ Le nom de l’utilisateur
½ Le nom du binaire à exécuter
½ Le numéro de nœud choisi pour l’exécution
½ L’application a-t-elle une assurance vie ? (cf. &KDSLWUH,,/HVIRQFWLRQQDOLWpV)
½ Le temps 7DY associé à une éventuelle assurance vie.
½ L’utilisateur souhaite-t-il rebooter les nœuds de calcul avant que son application soit exécutée ?
,,/HFDOHQGULHU
Un deuxième élément important compose le JMS de la machine MPC. Il s’agit du calendrier.
)LJXUH/HFDOHQGULHU
Le calendrier sert à définir des périodes. L’administrateur a la charge de la gestion de ce calendrier. Il y a trois types de périodes possibles :
½ Période de type %$7&+ : c’est la période utilisée en temps normal. Tous les utilisateurs sont équivalents. Les deux seules règles de priorité sont P1 et P2 énoncées à la section &KDSLWUH,,/HVTXHXHV.
½ Période de type 86(5 (ou utilisateur) : ce type de période permet de privilégier un utilisateur par rapport à tous les autres en donnant son ORJLQ. Si une application a été lancée dans une période BATCH et que la période a été ensuite attribuée à un utilisateur, cette application peut-être tuée avant la fin de son exécution si l’utilisateur en question veut lui-même lancer une application. Une nouvelle règle de priorité intervient alors :
3 : Si la période est réservée à un utilisateur (type USER) particulier alors ses applications sont prioritaires sur toutes les autres. P3 est supérieure à P1 et P2.
½ Période de type 5,(1 : ce type de période permet à l’administrateur de « geler » l’exécution des applications. Si une application est en cours d’exécution et que le type de la période devient RIEN alors l’application est tuée.
Le calendrier peut être consulté par tous les utilisateurs et doit être maintenu et mis à jour par l’administrateur.
,,/¶H[pFXWLI
L’exécutif est l’organe central du JMS pour la machine MPC.
)LJXUH/¶H[pFXWLI
Il gère l’ensemble du JMS et s’occupe de lancer les applications que les utilisateurs stockent dans les queues.
L’exécutif lit le calendrier pour savoir dans quel type de période il se trouve. Il lit ensuite le contenu des queues Q1, Q2, Q3 et, suivant le type de période, classe les applications contenues dans ces queues par ordre de priorité.
Par ailleurs, il lit le contenu de la file OLD pour connaître la dernière application à avoir été exécutée. Il regarde si celle-ci est effectivement en cours d’exécution. Si c’est le cas, il détermine alors si cette application doit être tuée ou non.
Enfin, il détermine si une application doit être lancée et, si c’est le cas, lance cette application sur le nœud 0. En effet, une application PVM-MPC se lance toujours sur le nœud 0 (FI &KDSLWUH ,,, $UFKLWHFWXUH JpQpUDOH GH 39003&). Avant chaque exécution, les démons PVM et MPC sont tués puis relancés.
L’exécutif est lancé toutes les 5 minutes afin de suivre l’évolution de l’exécution des applications.