Quelques éléments de mise en œuvre 103 une grille où les actions réalisées par le système sont infimes par rapport au coût de communi-cation entre deux nœuds, ce qui est le cas pour un bon nombre de grilles expérimentales comme Grid’5000. Compte-tenu de l’abstraction de la couche de communication, les services reposant dessus ne nécessitent que de faibles modifications pour fonctionner en mode simulation.
Nous avons étendu ce mode de simulation pour les services que nous avons mis en œuvre.
En particulier, nous avons modifié l’interface d’accès aux ressources. En effet, en mode simu-lation, nous n’exécutons pas d’applications réelles mais des applications synthétiques et les ressources sont émulées. SoitU TV une unité de temps virtuel, les caractéristiques d’un nœud se résument à :
– son typeTyperessourcedont la valeur appartient àN, – sa capacité de calcul (cf. 6.1).
Capacite_calcul´ =Nbinstructions
U TV (6.1)
Une application est simplement définie par le type de ressourceTyperessourcequ’elle requiert et le nombre d’instructions qu’elle comporteNbinstructions.
Le mode de simulation permet également l’exécution de plusieurs tâches en concurrence sur une ressource. À chaque fois qu’une tâche est lancée sur une ressource, la date de terminai-son de toutes les tâches est ré-évaluée. SoitT l’ensemble des tâches en cours d’exécution sur la ressource etTi∈T, alors le temps de calcul restant de chaque tâche est calculé par :
Temps_virtuel_restant(Ti) = NbTinstructions_totali −NbTinstructions_calculi es´
Capacite_calcul´ × |T| (6.2) De même, lorsqu’une tâche se termine, les temps de terminaison de toutes les tâches en exécution sur la ressource sont recalculés avec la fonction définie dans 6.2.
En mode simulation, il n’y a pas d’échange de fichiers entre les nœuds, ni d’interface externe. Les opérations à réaliser comme l’ajout d’un nœud dans le système ou la soumission d’une application sont définies dans une trace qui est injectée dans le simulateur.
6.1.1.3 Code développé
Le prototype Vigne avait été développé par Louis Rilling en langage C. Ainsi, l’extension que nous y avons apportée a également été développée en langage C. Cette extension représente environ 15000 lignes de code sur les 30000 lignes au total que compte le prototype.
Le code source peut être compilé sur un système Linux et une machine dotée d’un proces-seur d’architecture i386 ou x86-64.
Le code est lié à trois librairies externes qui sontglib2 (gestion des listes et des tables de hachage),gcrypt11(fonctions de hachage MD5 et SHA-1), etxml2(analyse syntaxique des fichiers XML).
D’un point de vue système, le système Vigne s’exécute en espace utilisateur, sans privilèges spéciaux. Cela permet de limiter l’inquiétude que pourrait avoir un fournisseur de ressources à installer Vigne sur les ressources qu’il met à disposition dans la grille.
104 Éléments de mise en œuvre et évaluation du système Vigne
Quelques éléments de mise en œuvre 105
FIG. 6.3 – Schéma de communication pour les requêtes émises parclient_cde type 1
FIG. 6.4 – Schéma de communication pour les requêtes émises parclient_cde type 2
106 Éléments de mise en œuvre et évaluation du système Vigne
FIG. 6.5 – Schéma de communication pour les requêtes émises parclient_cde type 3 La figure 6.5 montre le troisième schéma de communication pour la requête GET_-OUTPUT_FILES. Dans ce schéma de communication, le gestionnaire d’application demande aux ressources d’effectuer un transfert direct d’un ensemble de fichiers sur un nœud choisi par l’utilisateur. Une fois le transfert terminé, le nœud récepteur avertit le gestionnaire d’applica-tion. La synchronisation avec le gestionnaire d’application est nécessaire car des fichiers de sortie ne peuvent être transférés qu’une fois car ils sont effacés en fin de transfert. Une fois que le gestionnaire d’application a reçu l’avertissement de bonne terminaison du transfert, il rend finalement la main à l’utilisateur. Ce type de requête est également synchrone.
6.1.2.2 Surveillance de l’exécution des tâches sur les ressources exploitées en mode in-teractif
Le service de gestion d’application est capable de réagir à la défaillance de tâches qui composent une application pour mener à bien l’exécution de cette application. Pour cela, le service de gestion d’application repose sur un mécanisme de détection de défaillance de tâche implémenté dans le superviseur de tâche (cf. partie 5.2.2) qui dépend du type de ressource utilisé.
Pour les ressources exploitées à l’aide d’un gestionnaire de traitement par lots, le super-viseur de tâches récupère les informations d’exécution grâce au gestionnaire de traitement par lots. Les informations récupérées dépendent bien entendu du gestionnaire de traitement par lots utilisé, mais d’une manière générale elles se résument à un état qui détermine si l’exécution est en cours ou non, ceci en surveillant l’exécution du premier processus système de la tâche.
Pour les ressources exploitées en mode interactif, le superviseur de tâche que nous avons mis en œuvre peut avoir deux comportements. Avec son comportement simple, il surveille les
Évaluation 107 tâches de la même façon qu’un gestionnaire de traitement par lots, c’est-à-dire qu’il ne surveille que le premier processus de chaque tâche. Avec son comportement avancé, il surveille tous les processus d’une tâche.
Comportement simple Lorsqu’une tâche est exécutée (avec les fonctionsfork()et exec()), le superviseur de tâche enregistre lePID du premier processus système exécuté.
Ensuite la fonctionwaitpid()est exécutée pour attendre la fin de l’exécution du processus dont l’identifiant est PID. En fonction du code de retour dewaitpid(PID), le superviseur de tâche retourne au gestionnaire d’application qu’il y a eu une défaillance ou que l’exécution s’est convenablement déroulée.
Comportement avancé En collaboration avec Thomas Ropars durant son stage de Master de recherche [148], nous avons proposé un mécanisme de surveillance avancé des tâches. Ce mécanisme repose sur la surveillance fine de chaque processus système qui constitue une tâche.
Cela permet de détecter une terminaison anormale même si ce n’est pas le processus père qui connaît une défaillance et cela permet également de déterminer avec précision l’origine de la défaillance.
Pour mettre en œuvre le comportement avancé, nous avons implémenté une fonctionnalité permettant d’intercepter en cours d’exécution les appels aux fonctions liées au cycle de vie d’un processus système :fork(),exit(),wait() etwaitpid(). Cette interception a été réalisée en utilisant une librairie dynamique contenant une version modifiée de ces quatre fonctions. Cette librairie dynamique est chargée à l’exécution de la tâche en positionnant la variable d’environnementLD_PRELOADet sa portée permet de sur-définir les quatre fonctions pour tous les processus systèmes créés par une tâche. À tout instant, le superviseur de tâches connaît les processus système en cours d’exécution, et cela de façon passive puisqu’il n’a pas besoin de scruter le répertoire /procpour s’apercevoir de la création de processus. La dé-tection d’une défaillance des processus système créés après l’exécution de la tâche est donc possible.
Cette méthode permet de surveiller très finement l’exécution d’une tâche mais possède toutefois une limitation puisqu’elle n’est pas utilisable avec des binaires compilés statiquement.
Dans ce cas, le pré-chargement d’une libraire dynamique sur-définissant les fonctions liées au cycle de vie d’un processus n’a aucun effet puisque le code des librairies, en l’occurrence celui de lalibc, est directement inclus dans l’exécutable. Une solution pourrait être de mettre cela en œuvre directement dans le noyau du système d’exploitation en sur-définissant les fonctions do_fork(),do_exit() etdo_wait(). L’inconvénient d’une telle solution réside dans son niveau d’intrusion qui n’est pas envisageable si le système d’exploitation des nœuds ne peut pas être modifié.
108 Éléments de mise en œuvre et évaluation du système Vigne
Bordeaux Grenoble Lille Lyon Nanc y
Orsay Rennes Sophia Toulouse
Bordeaux - 17,1 10,8 18,4 12,6 8,3 8 10,3 3,8
Grenoble 17,1 - 12,8 3,2 13,2 14,9 15,2 9,8 10,7
Lille 10,8 12,8 - 10,2 9,2 4,3 11,2 16,8 17,4
Lyon 18,4 3,2 10,2 - 10,5 9,1 12,5 7,2 7,9
Nancy 12,6 13,2 9,2 10,5 - 5,6 11,6 17,1 17,8
Orsay 8,3 14,9 4,3 9,1 5,6 - 8,8 28,9 15,5
Rennes 8 15,2 11,2 12,5 11,6 8,8 - 19,1 19,8
Sophia 10,3 9,8 16,8 7,2 17,1 28,9 19,1 - 14,5
Toulouse 3,8 10,7 17,4 7,9 17,8 15,5 19,8 14,5