Le 20 mai 1998

Création d'un outils d'admisitration répartie

Sommaire

Sommaire *
Introduction à JavaPVM *
Planning *
Les fonctionnalités de l’application *
Fonctionnalités des esclaves *
Fonctionnalités des maîtres *
Structure des données *
Les messages *
La table des maîtres *
Structure d’une table *
Maintient de la cohérence entre les maîtres *
Les changements d’état : *
L’inplentation du programme *
La décomposition en Thread *
Les primitives JavaPVM *
Fonctionnement de l’Applet *
Bilan, continuation et développement *
Annexes *
Table des illustrations *
Références * Introduction à JavaPVM

Nous avons supposé que lors du démarrage d’une machine un deamon pvm été lancé et que la machine été ajouté à la machine virtuelle pvm.

Nous avons utilisé JavaPVM comme une sur-couche du réseau physique. Nous avons établi qu’une machine est en fonction lorsque notre application tourne et éteinte dans les autres cas. Cela nous permet de simuler l’arrêt, le démarrage, le crash des machines.

Planning

DIAGRAMME DE GANTT

Université de la Méditerranée

Ecole Supérieure d’Ingénieurs de Luminy

Etudes Supérieures en Ingénierie Informatique

PROJET : JavaPVM

Début : 20.03.1998

Fin : 10.05.1998

Tâches :

Analyse

préliminaire

Aquisition et Structuration

Des algoritmes à implanter

Maitrise des

Communications

Organisation

Multithreading

Interfaçe

table de routage

Rédaction du

rapport

Etabli par : Stéphane BENOLIEL, Philippe ELDIN

Les fonctionnalités de l’application

Cette application a pour but de créer une gestion parallèle des machines dans le but de faciliter la tache du ou des administrateurs systèmes d’un réseau. Le système se compose d’un ou de plusieurs maîtres, et de plusieurs machines esclaves à administrer. Les machines sont incluses dans un même domaine, et peuvent être divisées en groupe. L’application comporte les fonctionnalités suivantes :

A tous moments :

? Connaître le nombre et le nom des machines du réseau

? Connaître le nombre et le nom des machines allumées

? Connaître le nombre et le nom des machines éteintes

? Les niveaux de contrôle des machines connectées :

L’occupation du disque.
La charge processeur.
Le nombre d’utilisateur.

L’Administrateur doit pouvoir gérer les groupes :

? Ajouter et supprimer des groupes.

? Ajouter et supprimer des machines à un groupe.

? Connaître l’état des machines d’un groupe.

Il doit pouvoir communiquer :

? Envoie d’un message à une machine.

? Envoie d’un message aux machines d’un groupe. Un groupe particulier comprend tous les maîtres. Il doit finalement pouvoir envoyer différents types de messages :

? Des messages de commande (top,df... voir Reboot)

? Des messages de contrôle (existence et mort des machines, capacité disque...).

? Des messages de communication simple.

L’administrateur doit pouvoir demander une exclusivité sur une station à administrer.

Cette application a une interface utilisateur permettant d’exécuter et de visualiser toutes les commandes décrites.

Fonctionnalités des esclaves L’esclave a le comportement suivant :

? Avertir de sa naissance : Il envoi le message Je suis là

? Avertir de sa mort : Il envoi le message Je vous quitte

? Envoyer régulièrement ses états à tous les maîtres: Je suis là, état de mes disques xxx, ... ?Répondre aux commandes des maîtres (uniquement)

Fonctionnalités des maîtres

Le maître doit avoir le comportement suivant :

? Avertir de sa naissance : Il envoie le message Je suis là

? Avertir de sa mort : Il envoie le message Je vous quitte

? Envoyer régulièrement à tous les maîtres: Je suis là ? Gérer la liste des maîtres actifs :

Ajout et suppression en fonction des stimuli
Un maître peut savoir si un autre disparaît, si ce dernier l’informe ou si l’information d’existence n’est pas rafraîchie dans les temps

? Gérer la liste des esclaves actifs :

Ajout et suppression en fonction des stimuli

? Répond aux commandes de l’administrateur, utilisateur de l’application.

? Recevoir des messages des autres maîtres.

? Demander une exclusivité de gestion d’une station esclave :

Envoie de la demande à l’esclave
Attend la réponse en broadcast de l’exclusivité.

? Tous les DT envoyer en BroadCast à tous les maîtres mes tables pour la vérification de la cohérence des informations :

Si les infos sont les même alors ne rien faire
Si elles sont différentes, vérifier l’information :

Si l’autre à raison, faire une modification de ses tables
Si non, établir la priorité est réagir en fonction....

Structure des données

Les messages Pour permettre une gestion plus facile des échanges sur la couche PVM, nous avons implanté un protocole de messages permettant une identification rapide et efficace. Le principe est base sur un String dont les champs sont découpés de la façon suivante :

@destinataire	@source	type	Nom	Message
6	6	2	10	? ? ?

Les différents types de message sont :

Message d’état : 00

User	Load	Disque
2	3	2

Message de naissance de maître :

01 :C’est un message identique à celui des états.

Message de contrôle entre maîtres :

10 : envoie des tables.

11 : demande d’envoi des groupes.

12 : envoie des groupes (réponse à 11).

Message de communication entre administrateurs :

20 : Message de communication simple.

Message de routage des données :

30 : Indication de message routé.
31 : Message by qui indique la station de transit.

Si on envoie un message de A vers B en passant vers C, le message se compose de la sorte :

ID C

ID A

ID B

ID A

ID C

type

Message

Le message de retour, donc de B vers A se construit de la sorte :

ID C

ID B

ID A

ID B

type

Message

Message de gestion de l’exclusivité :

40 : Demande d’exclusivité.
41 : Réponse d’exclusivité. Le principe est le suivant, une station maître demande une exclusivité à un esclave, celle-ci lui répond en lui envoyant un ID, correspondant sa station moniteur. Cette réponse est effectuer en broadcast sur le groupe maître.
42 : Libération de l’exclusivité. En réponse à cette libération l’esclave renvoie la trame précédente.

Message de commande :

50 : Commande à exécuter : le message se compose d’une chaîne d’un String étant la commande UNIX à effectuer.
51 : Message join pour l’ajout à un groupe.

52 : Message leave pour enlever une station à un groupe.

53 : Message arrêt pour demander l’arrêt d’une station.

La table des maîtres Structure d’une table

Pour permettre la gestion des différentes machines, les maîtres possèdent une table regroupant les informations de chaques machines. Cette table et unique pour chaque maître et se compose de la façon suivante :

Nom	ID	Etat	Groupe (x3)	Exclusivité	Date du dernier Message	Disque	Utilisateurs	Charge CPU	Provide
10	8	2	10	1	? ? ?	2	2	3	8

Les différentes informations de la tables sont les suivantes :

Nom : Le nom de la machine sur 10 caractères.
ID : C’est l’identificateur de la machine en PVM.
Etat : 0 off ou 2^eme TimeOut, 1 on, 2 incohérences des informations ou TimeOut dépassé, 3 routage, 4 problème de groupe.
Groupe : Il existe trois champs de groupe, le premier est pour identifier l’esclave ou le maître, et les suivant pour la gestion des groupes utilisateurs.
Exclusivité : 0 si aucune exclusivité, 1 si c’est le maître qui détient cette exclusivité et 2 si c’est un autre maître.
Date : Contient une date permettant la gestion du TimeOut.
Disque, Utilisateurs,Charge CPU : Informations sur la machine
Provide :ID de l’utilisateur par lequel on peut transité les messages lorsque l’état est à 3.

Ces tables doivent être, pour des raisons évidentes de validité des informations, identiques sur tous les différents maîtres du système. C’est pourquoi nous avons mis en place un algorithme de maintient de la cohérence des tables.

Maintient de la cohérence entre les maîtres

Pour la gestion des informations d’états et de la cohérence entre maîtres, il existe des priorités.

S’il y a contradiction sur le champ id nous passons en état 2
Si une station est en état 0 alors qu’un autre maître dit qu’elle est dans l’état 1 alors le premier maîtres n’y accède plus, nous introduisons l’id du maître qui permettra la transmission indirect des informations dans un champ provide ; l’état de la station passe alors en état 3.
Si la station est en état 1 et que nous recevons des informations contradictoires alors nous n’en tenons pas compte.
S’il y a contradiction sur les champs groupes nous passons en état 4

Remarque : Nous ne tenons pas compte de la datation des trames. Le champ Date du dernier message n’est pas contrôlé, car il dépend de chaques machines. Nous ne prenons pas en compte les éventuels conflits sur les champs load,user,disque qui ne sont que des indications.

Les changements d’état :

Quand une machine rencontre un problème elle passe en état 2 ou 4; 4 si c’est un problème sur la cohérence des groupes sinon 2, ces états blocs le processus d’envoi de commandes.

En état 0 : Lors de la réception d’une trame d’information l’état de l’esclave passe en état 1.

En état 1 : Si aucun trame ne parvient au maître dans les délais impartis par notre timer, l’état de l’esclave passe en état 2.

En état 2 : l’état est rétabli à 1 lors de la réception d’une trame d’information émise par l’esclave. Si aucun trame ne parvient au maître dans les délais impartis par notre timer, l’état de l’esclave passe en état 0.

En état 3 : l’état est rétabli à 1 lors de la réception d’une trame d’information émise par l’esclave. Si aucun trame ne parvient au maître dans les délais impartis par notre timer, l’état de l’esclave passe en état 2.

En état 4 : une demande de groupe est envoyée à cette machine. Lors de la réception de la trame de groupe le maître remettra l’état de la machine à 1, si se dernier est resté à 4 (c’est à dire aucun problème n’est survenu entre le moment de la demande et la réception de la trame de groupe )

Remarque : à chaque réception d’information, le maître remet à jour sa table et en particulier le champ date. A chaque nouvelle connexion ou à chaque reconnexion (suite à un état 0) le maître demande les groupes de la machine qui vient de se connecter.

L’inplentation du programme La décomposition en Thread Nous avons utilisé une programmation multithread pour gérer les différentes fonctionnalités de notre application. Elle se divise en deux partie indépendantes : Esclave et Maître. Pour ces deux parties on retrouve des fonctionnalités identiques .

L’applet interaction : c’est un thread qui tourne au lancement de l’applet il a pour but de faire la liaison entre l’utilisateur et le produit.

Affichage : c’est un thread qui rafraîchit les champs de l’applet ou qui modifie son aspect lors d’une manipulation de l’utilisateur.

Réception : c’est un thread qui attend les informations et les traite si ce sont des informations de tables il lance un thread de traitement spécifique réception table.

Réception table : Il gère la réception des tables des autres serveurs, et maintient la cohérence en effectuant des mises à jour le cas échéant.

Emission : Il transmet les informations des esclaves (deamon), les tables des maîtres ainsi que les commandes et réception de commande.

Timer : Déclenche des émissions de tables aux autres maîtres

Les primitives JavaPVM Nous avons utilisé exclusivement les primitives de transmission d’informations et de gestion de groupe. En effet la version 1.1.3 de JavaPVM est amené à etre remplacé par JPVM dont les primitives se rapprochent de CPVM.

initsend(PvmDataRaw) initialise un buffer en mémoire partagée

pkstr(content) met dans le buffer le string content

upkstr(msg) récupère le contenu du buffer dans un tableau de char

nrecv(-1, _StringMsg) réception depuis tout les horizons (-1) d’un message de type string en mode non bloquant

bcast("maître", _StringMsg) envoie le contenu du buffer en tant que caractère sur les machines appartenant au groupe maître

send(addexp, _StringMsg) envoie le contenu du buffer en tant que caractère sur la machine ayant l’id addexp

joingroup(pipo) associe la machine qui exécute cette commande au groupe pipo et retourne –1 s’il y a eu une erreur

lvgroup(legroupe) dissocie la machine qui exécute cette commande du groupe pipo et retourne –1 s’il y a eu une erreur

mytid()retourne le numéro du processus

Fonctionnement de l’Applet Cette applet se lance à partir de l’appletviewer, une suite de boutons et de menu déroulant vous permettrons de piloter votre machine et les machines sur lesquels un deamon pvm et présent.

L’accès aux différentes fonctionnalités se fait par interaction avec les boutons et les menus déroulants, des ensembles de boutons, de champs, et de menu déroulant pilotent une fonction.

Création d’une nouvelle machine sur le réseau pvm : Soit en se loggant sur la machine elle-même, suivi du lancement de l’appletviewer. Soit en indiquant dans le champ approprié un nom de machine sur laquelle tourne un deamon pvm puis en choisiant dans le menu déroulant New maître ou New esclave verifier le champ display !.

Pour envoyer une commande il faut indiquer la commande elle même, choisir la machine à qui la commande est destinée parmi le menu déroulant créé à cet effet ou saisir son nom dans le champ approprié, le display dans le cas de l’ouverture d’une fenetre, puis presser le bouton Commande.

Pour afficher les tables d’informations du maître presser sur Table info l’affichage aura lieu dans la zone de contrôle.

Le bouton Effacer permet d’effacer la zone de contrôle

Pour adjoindre une machine a un groupe : il faut choisir le nom de la machine par le menu déroulant ou le saisir, saisir le nom du groupe auquel cette machine doit être associée dans le champ approprié puis faire glisser le menu déroulant sur join group.

Pour dissocier une machine d’un groupe : il faut choisir le nom de la machine par le menu déroulant ou le saisir, puis choisir le groupe dans le menu déroulant sous le champ de saisi du nom de machine puis faire glisser le menu déroulant sur leave group. Pour fermer une machine avec répercussion sur les tables des maîtres : il faut choisir le nom de la machine par le menu déroulant ou le saisir, puis faire glisser le menu déroulant sur exit.

Pour killer une machine c’est a dire simuler un crash d’une : il faut choisir le nom de la machine par le menu déroulant ou le saisir, puis faire glisser le menu déroulant sur kill.

Pour demander ou abandonner une exclusivité sur un groupe ou une machine il faut choisir le nom du groupe ou de la machine par le menu déroulant ou le saisir puis faire glissé le menu déroulant sur exclusivité ON ou exclusivité OFF.

Pour envoyer un simple message à une autre machine taper le texte dans la zone de contrôle puis pressez sur le bouton commande, avec le champ commande vide.

Champ de saisi du nom de machine déclenche l’affichage dans le menu déroulant sous le champ de saisi du nom de machine des groupes auxquels la machine appartient, parallèlement est extrait de la table d’information du maître les informations sur l’état d’administration de la machine. Cas particulier : si vous saisissez le nom d’un groupe à la place d’un nom de machine le menu déroulant sous le champ de saisi vous indiquera les machines appartenant au groupe saisi et parallèlement le nombre de machines de se groupe sera indiqué dans le champ contiguë au menu déroulant join leave ...

Bilan, continuation et développement Ce projet peut être très vaste. Les options que nous avons prises, nous ont permis d’aboutir. Malgré cela, l’utilisation de ce logiciel dans un cas réel est difficilement envisageable. Bien que simple d’utilisation, PVM demande des ressources très importantes. Dans tous les cas, le concept que nous avons établi reste intéressant et les tests que nous avons effectués sont concluants.

La réalisation nous a demandé environ 200 heures de travail, décomposée en plusieurs phases. Une grande partie a été consacrée à la réflexion et au choix des algorithmes à utiliser, en particulier pour la synchronisation des informations, sur un système distribué. Ce travail nous a apporté une connaissance accrue des différentes méthodes de partage d’informations, et de maintient de la cohérence sur un environnement distribué. En effet, pour choisir la méthode la plus adaptée, nous avons essayé de faire le tour des différentes méthodes possibles.

Après avoir tester longuement notre application, nous nous sommes rendu compte des difficultés d’utilisation lié à JavaPVM. Un certain nombre de modifications pourrait être utile pour l’amélioration du logiciel :

Le premier point est lié au transfert des informations sous forme de trames dynamiques. Il serrait intéressant d’inclure la longueur de la trame au début de celle-ci lors de l’envoie ; notamment pour les trames de contrôles, souvent petite et envoyées en broadcast.

Le choix d’un autre langage d’interfaçage de Pvm serrait une autre amélioration à apporter. Utiliser C++ aurait été plus rapide, bien que plus complexe à manipuler.

L’amélioration de l’interface graphique permettrait une convivialité accrue, offrant aux utilisateurs potentiels, un confort d’utilisation.

La dernière optimisation envisageable, serait un réglage des Timers en fonction de l’environnement de travail, de la vitesse du réseau, du nombre de machines...

Annexes

Table des illustrations

Protocole de communication ............................................................................ 3

Diagramme de la station esclave .................................................................... 6

Diagramme de la station Maître ...................................................................... 8

Transition d’états dans la table d’information .................................. 11

Decomposition Multi-Threading ...................................................................... 12

Utilisation de l’Applet ........................................................................................... 14

Références Voici quelques sites relatifs à PVM, JavaPVM.... qui nous semblent intéressants :

De la documentation sur l’API de JavaPVM sur le site de l’ES2I : http://www.esil.univ-mrs.fr/java/docs/pvm/
La Page de référence sur JavaPVM :

http://www.isye.gatech.edu/chmsr/JavaPVM/

Une page sur les performances des communications en jPVM :

http://www.cs.virginia.edu/~ajf2j/jpvm.html

La page officiel de PVM :

http://www.epm.ornl.gov/pvm