Les défaillances dans Condor

Précédemment, nous avons vu que la plateforme Condor n’offre pas beaucoup de mécanisme de traitements des défaillances du système à part la technique des points de reprise (checkpoint) et le gestionnaire des graphes acycliques dirigés (DAGMan).
Condor étant un environnement de calcul haut débit (High-Throughput Computing), son objectif est de gérer et exploiter efficacement toutes les ressources informatiques disponibles. Donc le système doit prendre en charge le plus possible la gestion des défaillances, de façon à minimiser les indisponibilités, et faire travailler les machines le plus longtemps possible sans intervention.
C’est ainsi que nous avons orienté notre étude au niveau de l’étape d’exécution des programmes. En effet, quand l’utilisateur soumet un travail au Condor, il établit ses besoins dans un fichier ClassAd dans lequel il spécifie les caractéristiques de la ressource, par exemple le type de machine, taille du disque, système d’exploitation, …
A partir de là, une ressource est attribuée et le programme commence à s’exécuter.
Nous avons pu constaté que pendant l’exécution, la mémoire utilisée par le travail n’était pas contrôlée,ce qui entraîne des erreurs de saturation mémoire, donc d’indisponibilité de la ressource utilisée.
Précisément, un programme est une série d’instructions dont l’exécution modifie l’état mémoire de la machine. Cette mémoire est constituée principalement des valeurs créées ou manipulées par le programme. Or, comme toute ressource informatique, la mémoire disponible pour une application est finie ; un programme tentant d’utiliser plus de ressources que le système ne lui en attribue se retrouvera dans un état incohérent. Au fil de l’utilisation, les performances du système ont tendance à se dégrader.
Certes l’utilisateur a la possibilité de mentionner la taille de la mémoire nécessaire dans sa classAd, mais il s’agit bien sur de la taille totale de la mémoire de la machine, mais pas ce qu’il en reste à un instant T.
Les problèmes de saturation mémoire ne sont pas pris en charge par Condor.

Utilisations des agents mobiles

L’idée est de mettre un agent qui surveille l’évolution de la mémoire, et de notifier la machinerie Condor en cas de dépassement.

Les agents mobiles dans les grilles de calcul

Les agents mobiles constituent un outil d’adaptation des applications aux variations de la qualité des services offerts par le système et le réseau ; ils doivent eux-mêmes s’adapter dynamiquement à des conditions d’exécution variables. Les réseaux à grande échelle, tels l’Internet, les grilles de calcul ou de stockage donnent accès à des quantités de données, de services et de ressources répartis.
La programmation par agents mobiles est un paradigme complémentaire pour la programmation des applications réparties. Un agent mobile possède la faculté de se déplacer en emportant son code, ses données, ainsi que son état d’exécution ; il décide lui-même de manière autonome, de ses déplacements. Le rapprochement du client (représenté par un agent) et du serveur permet de diminuer les interactions distantes (en recherche d’information, par exemple) ou de spécialiser un service (adaptation du flux de données d’un serveur multimédia aux capacités du client, par exemple). Le principe de délégation permet à l’agent d’opérer en étant déconnecté du client. La mobilité des agents et leur autonomie améliorent la sûreté (tolérance aux pannes par redéploiement des agents sur des noeuds en service) et permettent le suivi de matériel ou d’utilisateurs mobiles (réseaux actifs, informatique nomade). Enfin, le mode de communication asynchrone permet de s’accommoder de la latence et des perturbations des réseaux à grande échelle ou sans fil. Les agents mobiles sont donc un outil à part entière pour l’adaptation des systèmes.
Avec les grilles de calcul, les agents mobiles trouvent un champ d’application naturel.
En effet, les caractéristiques de déplacement, d’adaptation, de coopération vont permettre de tirer partie de ces environnements.
Les agents mobiles vont pouvoir adopter ce comportement naturel de négociation. Dans les grilles, les organisations offrent, généralement, des expertises de haut niveau nécessitant de longue phases de traitement et/ou la mise en oeuvre d’un ensemble de sous-services. Avec un utilisateur nomade, se connectant de manière intermittente à la grille, l’utilisation des agents mobiles permet de déléguer la réalisation de la tâche que l’utilisateur souhaite exécuter.

Nos agents mobiles

Conceptuellement, les agents doivent surveiller le niveau de mémoire de chaque machine du pool Condor et dès l’instant que l’utilisation dépasse 90 %, ils signalent un risque de saturation mémoire et donc d’indisponibilité de la machine exécutant le travail soumis.
Dans cette section, nous allons détailler les fonctionnalités et spécificités de notre agent mobile au sein de Condor.

Structure de l’agent mobile

Un agent mobile est défini par un modèle d’agent. Le modèle d’agent définit l’état d’un agent par un ensemble de paramètres d’une part et des primitives d’accès à cet état permettant d’initialiser et modifier les paramètres de l’agent, d’autre part.
Une instance d’agent mobile comporte trois parties :
• des données
• du code
• un contexte d’exécution
Les données sont les valeurs des paramètres définis par le modèle d’agent. Parmi les données d’un agent mobile on trouve son nom, son itinéraire, le programme de la tâche à exécuter, un dossier destiné à recevoir les résultats de l’exécution de ce dernier. Le code met en oeuvre les primitives d’accès aux valeurs des paramètres. Le contexte d’exécution reflète l’état d’exécution courant de l’agent mobile.

Création de notre agent

La création d’un agent consiste à créer une instance d’agent sur une place donnée. Elle s’effectue à partir du modèle d’agent. Les données d’un agent sont initialisées lors de sa création. Une fois créé, l’agent peut être actif c’est à dire que l’exécution du code de la tâche associée à l’agent est déclenchée. La création/activation d’un agent peut prendre plusieurs formes :
• création locale
• création et exécution à la demande
• création et exécution à distance
On parle de création locale lorsque l’agent est créé et activé sur la place située sur le site ayant émis la requête de création. Lorsque la création est locale et que l’activation a lieu sur un autre site à distance (l’agent est transféré après sa création et avant son activation), on parle de création avec exécution à distance. Dans ce cas, la place sur laquelle l’agent doit être activé est déterminée par l’entité ayant émis la requête de création de l’agent.
Dans le cas de la création avec exécution à la demande, une place initialise le transfert du code de l’agent. L’exécution à la demande peut être utile lorsque une place désire à un moment donné que l’on lui amène un agent mobile depuis une autre place.
Dans le cas de notre étude, la création de notre agent s’effectuera sous la troisième à savoir création et exécution à distance. Techniquement, nous allons placer un générateur d’agent mobile au niveau du manageur central, point de départ de toutes les tâches soumises au sein du pool Condor. Ainsi dés que la commande de soumission d’un travail, condor_submit, est lancée un agent mobile sera créé au niveau du serveur central de Condor, pour ensuite migrer vers la machine d’exécution.

Exécution de l’agent

Une fois initialisé, l’agent peut commencer son exécution. L’exécution de l’agent consiste en l’exécution du code de la tâche qui lui est associée. Elle a pour effet de modifier les données de l’agent.
Donc dés l’instant où l’agent mobile migre au niveau de la machine d’exécution, il commence à exécuter en même temps le programme soumis. Il surveille ainsi le niveau de la mémoire de l’ordinateur en effectuant des entrées/sorties.
En effet, les agents mobiles peuvent être amenés à accéder au système de gestion de fichiersou effectuer des entrées et sorties. Les agents ont donc besoin d’accéder au système hôte.
Toutefois, les mécanismes d’accès varient d’un système d’exploitation à l’autre. Notre agent mobile devra accéder aux ressources locales du site à savoir les paramètres et variables représentant l’état de la mémoire d’une machine.
Dés que son utilisation dépasse les 90%, l’agent lance un point de reprise (checkpoint) avec la commande condor_ckpt et le travail est migré sur une autre machine. L’agent mobile se déplace aussi en même temps que le travail et commence à exécuter ses tâches comme décrit précédemment.
Précisément, c’est la migration faible qui sera utilisé ici, puisque notre agent se déplace uniquement avec son code et ses données. Ces derniers seront enfin utilisés au niveau de la machine d’exécution pour instancier une nouvelle copie de l’agent. Ce processus continue jusqu’à la fin de l’exécution du travail soumis.

CONCLUSION

Au cours de ce stage, nous avons d’abord évalué l’environnement Condor particulièrement et nous avons constaté que très peu de mécanismes de gestion des défaillances sont développés dans le système Condor. Nous avons ainsi orienté notre étude au niveau de l’étape d’exécution des programmes dans le pool Condor. Nous avons découvert des problèmes de saturation mémoire que la machinerie Condor ne détectait pas. Ensuite, nous avons fait une étude sur les agents mobiles et surtout leur rôle dans les systèmes de calcul haut débit.
Au terme de cette étude, nous proposons une solution à base d’agents mobiles qui surveillent le niveau de mémoire de chaque machine et dès l’instant que l’utilisation dépasse 90%, ils signalent un risque de saturation mémoire et donc d’indisponibilité de la machine en lançant un point de reprise (ou checkpoint) avec la commande condor_ckpt. Ce qui fait migrer le programme sur une autre machine disponible avec une instance de l’agent mobile.
Ce stage a été un excellent moyen pour nous de découvrir l’univers des systèmes répartis et parallélisme, domaines de l’informatique en plein essor, avec pour perspective, des réflexions poussées sur les problèmes de gestion et d’accroissement de la disponibilité des infrastructures répartie, les technologies agents et les protocoles de mise en correspondance entre offre et demandes de ressource au sein d’une grille informatique.