Le système condor

Checkpointing et Migration

La capacité de faire migrer un travail en cours d’exécution sur une machine oisive (disponible et non utilisée par son propriétaire) est fondamental à l’ordonnancement des travaux dans un pool Condor. Pour permettre à ces travaux de progresser, Condor utilise un « checkpoint » ou point de contrôle de l’état de ces travaux. Le checkpoint (dans condor) d’un programme revient à faire une copie :
• du programme (le code binaire exécuté par la machine),
• de la pile d’exécution (position dans le code du programme),
• de l’état des descripteurs de fichier (pointeurs vers les fichiers ouverts et position dans ces fichiers). Il suffit ensuite de relancer le programme avec ces informations pour le retrouver dans le même état qu’au moment du checkpoint.
Un checkpoint est généré juste avant la migration d’un travail. Il est alors employé comme point de départ pour le travail après migration.
Ainsi, Condor fournit aux programmes la bibliothèque « checkpointing library » contenant le signal de point de contrôle appelé « Condor checkpoint signal ». Quand un travail reçoit un signal, il crée un fichier contenant les données des processus, aussi bien que des informations sur les dossiers ouverts, les signaux suspendus et l’état actuel de l’unité centrale. Quand le travail est redémarré, l’état contenu dans le fichier de sauvegarde est restauré et le processus reprend le calcul à partir du point où le checkpoint a été généré.

Checkpoint server (serveur de point de contrôle)

Par défaut, un checkpoint est écrit sur un fichier du disque local de la machine où la tâche a été soumise. Dans ce cas une quantité suffisante d’espace disque doit être disponible pour stocker les images du checkpoint. Cette image est approximativement égale à la mémoire virtuelle consommée par la tâche pendant son exécution. C’est ainsi qu’un serveur de checkpoint a été développé pour sauvegarder les checkpoint de tout un pool Condor. Quand un ordinateur est configuré pour utiliser ce serveur, les travaux soumis sur cette machine écrivent et lisent les checkpoint du serveur au lieu de son disque local.

DAGMan

Un graphique acyclique dirigé (DAG) est employé pour représenter des programmes dont l’exécution dépend d’un ou plusieurs autres programmes. Dans ce graphe, les noeuds (sommets) sont les programmes, et les arcs identifient les dépendances.
Le Directed Acyclic Graph Manager (DAGMan) est un méta-ordonnanceur pour les travaux dans Condor. DAGMan soumet les travaux au condor dans l’ordre représenté par le DAG et traite les résultats. Un dossier d’entrée défini avant la soumission décrit le DAG, et un fichier de soumission pour chaque programme du DAG est utilisé par Condor.
Chaque noeud (programme) dans le DAG indique un fichier de soumission. Pendant que DAGMan soumet les travaux au condor, il surveille les fichiers de notation de condor pour imposer l‘ordre exigée par le DAG.
Le Directed Acyclic Graph Manager est responsable de l’ordonnancement et du rétablissement de l’ensemble de travaux soumis au Condor. Le schéma ci dessous montre le langage accepté par DAGMan :

Architecture

Un pool Condor comprend :
• une machine unique qui sert de Manageur central
• et un nombre arbitraire d’autres machines qui joignent le pool au fur et à mesure
Conceptuellement, le pool est une collection de ressources (machines) et de ressources demandeurs (jobs). Le rôle du Condor est de joindre les demandes en attente avec les ressources disponibles. Toutes les ressources du Condor envoient les mises à jours périodiques au manageur central, le dépôt d’information central sur l’état du pool. Le manageur central évalue périodiquement l’état présent du pool et essaie de joindre les demandes avec les ressources appropriées.

Les démons du Condor

Pour comprendre l’architecture du Condor, la liste suivante décrit les principaux démons qui tournent dans le système et leur rôle : condor_master : son rôle est de simplifier l’administration du système. Il assure le bon fonctionnement des autres démons Condor s’exécutant sur les machines du pool. Le master engendre les autres démons. En somme, si l’un des démons d’une machine s’arrêtent anormalement, le condor_master enverra un mail à l’administrateur du système et le démon affecté est automatiquement redémarré. Il tourne sur toutes les machines du pool. condor_startd : ce démon représente une machine dans un pool Condor. Elle annonce la ClassAd d’une machine. Il permet aux machines d’exécuter les travaux. Le condor_startd est responsable d’imposer la politique sous laquelle des taches à distance seront démarrés, suspendus, repris, évacués, ou tués. Quand il est prêt à exécuter un travail de condor, il engendre le condor_starter, décrit ci-dessous. condor_starter : ce programme est l’entité qui engendre le travail à distance de condor sur une machine donnée. Il installe l’environnement d’exécution et surveille le travail une fois qu’il s’exécute. Le condor_starter détecte l’accomplissement de la tâche, envoie le statut de cette dernière à la machine de soumission, et s’arrête. condor_scheed : ce démon représente les jobs dans le pool. Ce démon doit tourne sur toutes les machines habilitées à soumettre des travaux. Les utilisateurs soumettent leur job au condor_scheed, où est stockée la queue des travaux. Les divers outils pour voir et manipuler la queue des travaux se connectent au condor_scheed pour accomplir leur tache.condor_shadow : ce programme fonctionne sur la machine où un travail a été soumis L’ombre sert des demandes des fichiers au transfert, enregistre la progression du travail, et établit des statistiques quand le travail est terminé. condor_collector : ce démon est responsable de la collection de toutes les informations sur l’état du pool. Tous les autres démons lui envoient périodiquement les mises à jour de classAd. Ces classAd contiennent toutes les informations sur l’état des démons, les ressources qu’elles représentent ou les ressources soumis au pool. Le condor_collector peut être vu comme une base de données dynamique des classAd. Il tourne sur la machine désignée comme manageur central. condor_negociator : il contrôle le matchmaking dans le système condor.

Le demon Condor en action

Une machine sert de manageur central. Le démon condor_master tourne sur chaque machine du pool. Le central manageur tourne fait tourner les démons condor_collector et le condor_negociator. N’importe quelle machine dans l’installation qui est capable d’exécuter des travaux doit avoir le condor_startd, et chaque machine qui peut maintenir une queue de job et aussi qui permet aux utilisateurs de cette machine de soumettre des jobs doit avoir le condor_schedd.

Mécanismes de tolérances aux pannes dans Condor

Le Condor actuel ne sait pas gérer toutes les défaillances. Par contre, il offre des mécanismes de base permettant de réaliser des solutions applicatives ou « services système » de gestion des défaillances telles que le mécanisme de point de reprise ou de sauvegarde (checkpoint), DAGMan.

Le mécanisme de point de reprise (checkpoint)

Rappelons que le checkpoint ou point de reprise est une sauvegarde en fichier image de l’état d’exécution d’un job Condor avec toutes le données nécessaires à un instant T.
Ces « checkpointing » sont effectués périodiquement dans le système Condor. Tout dépend de la configuration des ordinateurs du pool.
Par exemple : toutes les deux heures, jamais, etc.
Au moment du lancement du checkpoint périodique, le travail en cours suspend son traitement, exécute le checkpoint et continue immédiatement d’où il a cessé. Il y a également une commande condor_ckpt qui permet à l’utilisateur de forcer l’exécution immédiate d’un point de reprise. Dans tous les cas, les travaux de condor continuent leurs exécutions au point de reprise complet le plus récent.
C’est ainsi que ce mécanisme de checkpoint périodique fournit la tolérance aux pannes pour plusieurs raisons :
– Quand un utilisateur soumet une tâche, Condor trouve une machine disponible dans le pool et commence à l’exécuter sur cette machine. Condor a la possibilité de détecter qu’une machine exécutant un job Condor n’est plus disponible (par exemple son propriétaire commence à utiliser le clavier) : il lance alors un checkpoint et fait migrer le travail sur une autre machine.
– Les points de reprise périodique sont aussi indispensables en cas d’arrêt ou de panne totale de la machine d’exécution, dans ce cas le travail est migré sur une machine et continuera son exécution à partir du dernier point de reprise. Donc il n’y aura pas de perte de temps ce calcul.