Action Concertée Incitative masses de donnees descriptif complet du projet
Yüklə 0,54 Mb.
|
II.2.4 Références[1] Francoise Baude, Denis Caromel, Fabrice Huet, Julien Vayssière, Objets actifs mobiles et communicants Technique et science informatiques, 21:6 1-36, 2002. [2] S. Alouf, F. Huet and P. Nain, Forwarders vs. Centralized Server: An Evaluation of Two Approaches for Locating Mobile Agents, Performance Evaluation Review , Volume 49, September 2002. II.3 Gestion des fautes dans les systèmes à large échelle L. Arantes (LIP6), M. Bertier (LIP6), P. Sens (LIP6 / INRIA), II.3.1 Objectifs et contexte Les environnements à large échelle induisent de nouveaux problèmes pour détecter les fautes. Il y a deux difficultés majeures liées à ce type d'environnement : (1) les bornes sur les délais de transmissions ne sont pas connues (réseaux asynchrones) (2) le nombre de sites à surveiller est très important. Dans le modèle asynchrone, il n'est pas possible de détecter les défaillances avec un délai de garde car il impossible de distinguer le cas où le processus distant est fautif de celui où la réponse est encore en transit. Pour apporter tout de même une solution satisfaisante, le concept détecteur de faute non fiable a été introduit pour T.D. Chandra et S. Toueg. Un détecteur de faute est chargé d'informer les processus corrects des fautes des autres processus (éventuellement en commettant temporairement des erreurs ou des fausses détections). La grande difficulté est alors de trouver un bon compromis entre la justesse des informations fournies par les détecteurs et le temps de réaction en cas de faute réelle. Dans les implémentations, les paramètres sont généralement fixés de manière empirique et peuvent s'avérer peu adaptés aux conditions courantes de fonctionnement. Un second constat est que ces implémentations ne passent pas à l'échelle en termes de nombre de sites. Ainsi le trafic généré par les messages de détection peut, dans un contexte à large échelle, complètement écrouler le réseau.
A partir des travaux de W. Chen, S. Toueg et M. Aguilera, nous avons conçu un nouveau détecteur de faute hiérarchique. L'originalité de ce détecteur est sa capacité à adapter dynamiquement sa qualité de détection en fonction de la charge du réseau. Notre projet d'expérience sur la détection de faute à large échelle vise à étudier différentes heuristiques d'adaptation prenant en compte plusieurs critères comme la charge réseau, la qualité de détection exigée par l'application, l'intrusion induite par le mécanisme de détection. Or, dans un environnement incontrôlé, il pratiquement impossible de définir des heuristiques efficaces. En effet, l'environnement d'expérimentation étant non reproductible, il n'est pas possible de caractériser finement les conditions dans lesquelles telle configuration du détecteur est plus adaptée. Dans le cadre de Data Grid Explorer, nous allons pouvoir 1) définir des scénarii d'injection de fautes 2) concevoir une plate-forme d'injection de différents type de fautes et 3) expérimenter plusieurs configurations à large échelle. II.3.3. L’échéancier des résultats et réalisations T0 + 12 : Conception et implémentation la plate-forme d'injection de fautes (faute de machine et du réseau) T0 + 18 : Test de la plate-forme et comparaison avec des résultats obtenus en grandeur nature : Phase de calibrage T0 + 24 : Implémentation d'heuristiques de détection de fautes T0 + 32 : Evaluation et expérimentation des détecteur sur différents scénarii T0 + 36 : Retour d'expériences, diffusion des résultats II.6 Mise au point et évaluation de stratégies d’ordonnancement pour le calcul grande échelle pair à pair Serge Petiton, Isaac Scherson et Lamine Aouad (LIFL, GrandLarge, INRIA Futur)
Le calcul scientifique intensif à grande échelle ne concerne pas uniquement des applications et méthodes bien adaptées au task farming du type seti@home (i.e. un même logiciel sur chaque machine avec des données et des paramètres différents). Il est nécessaire de pouvoir utiliser des algorithmes parallèles à gros grains sur des environnements de type pair à pair pour pouvoir résoudre de très grandes applications. Les temps d’exécution des calculs numériques sont alors souvent au moins d’un ordre de grandeur moindre que les temps de migrations de données entre les pairs et ceux des entrées-sorties. Pour de nombreuses méthodes, les calculs sont donc bien plus courts que ces migrations de données. La programmation est donc dépendante des temps de migrations de très grandes données entre pairs et les critères d’efficacité sont différentes de ceux du calcul intensif usuel. Les applications que nous ciblons dans ce projet peuvent manipuler jusqu’à près de 1O13 octets de données (matrice de taille un million), réparties entre pairs et/ou les unités de stockage. Plusieurs dizaines de milliers de machines peuvent être utilisées pour effectuer près de 1018 opérations. Pour minimiser les échanges de données, nos études de méthodes numériques à grande échelle nous ont déjà permis de conclure qu’il est nécessaire de prévoir des clouages de données sur les pairs et d’anticiper les migrations de données. Il convient donc de spécifier et d’étudier des stratégies d’ordonnancement adaptées à cet environnement et cette algorithmique en cours de définition. II.6.2 Description du projet Nous souhaitons spécifier le type d’ordonnancement adéquat. Plusieurs stratégies sont prises en compte. Nous sommes en train également de spécifier de nouveaux critères spécifiques au calcul grande échelle pair à pair à prendre en compte pour attribuer des ressources à des composants de calcul ; tels que, par exemple, l’hétérogénéité des machines, les paradigmes de programmation disponibles, la volatilité des machines, les logiciels présents sur les machines et les débits réseaux. Nous utiliserons le langage de composants YML que nous avons introduis pour spécifier des programmes pair à pair à grandes échelles. Si nécessaire, nous développerons un backend pour GRIDExplorer permettant d’interfacer directement la description du graphe de composants avec l’émulateur.. Plusieurs stratégies d’ordonnancement seront proposées pour plusieurs middlewares. L’utilisation d’un émulateur de grille pair à pair à grande échelle pour étudier leurs comportements est souhaitable pour permettre d’affiner certaines heuristiques et de vérifier la pertinence des critères retenus. Nous pouvons ainsi mettre au point des traces d’ordonnancement bien adaptées pour certaines grilles à grande échelle. Il est alors envisageable de les sauvegarder afin de proposer une aide à l’ordonnancement sur des grilles réelles. Nous proposons donc d’utiliser GRID Explorer pour :
En plus de la mise au point de stratégies d’ordonnancement et de tester le passage à l’échelle et au pair à pair de stratégies éprouvées, la synthèse de ces travaux devrait nous permettre également de généraliser l’utilisation d’un outil d’émulation pour pré-ordonnancer l’exécution de calcul pair à pair sur les grilles réelles. Cet outil pourra aussi être proposé pour mettre au point les programmes pair à pair. II.6.3. L’échéancier des résultats et réalisations T0 à T0+12 : Définition des stratégies d’ordonnancement. Développement des programmes YML sous forme de graphe de composants, qui vont servir en entrée de l’ordonnanceur. Etude sur l’écriture éventuelle d’un backend de YML pour GRIDExplorer. Etude pour simuler des ordonnancements pour l’émulateur GRIDexplorer (lien entre YML, l’ordonnancement et les traces liées à l’émulateur). T0+12 à T0+24 : Ecriture éventuelle du backend. Tests des stratégies d’ordonnancement sur l’émulateur, pour des programmes simples. Equilibrage des divers paramètres des méthodes et des stratégies retenues. T0+24 à T0+36 : Expérimentation avec des valeurs réalistes et plusieurs algorithmes par blocs. Evaluation comparative des stratégies retenues ; en particulier en fonction des techniques de migrations de données et des clouages de données. II.7 Compilation de communications volatiles pair à pair Serge Petiton, Guy Bergère et Haiwu He (LIFL, GrandLarge INRIA Futur)
Dans les grilles de calcul intensif à grande échelle pair à pair, si l’on considère les algorithmes à gros grains liés à de nombreuses applications numériques classiques, les communications sont souvent plusieurs ordres de grandeur moins rapides que les calculs. Les temps de calcul devenant souvent négligeables par rapport au temps de migration de données dès que l’on utilise des pairs reliés par internet. Il convient donc d’optimiser ces communications. Pour cela nous proposons d’adapter les techniques de compilation de communications au cas des grilles pair à pair. Néanmoins, les pairs sont ici volatiles et nous ne pouvons obtenir des traces de communications optimisées stables dans la mesure ou les pairs utilisés lors de la “ compilation ” ne seront peut-être pas présents sur la grille lors de l’ “exécution ”. Plutôt que des traces stables reflétant des schémas de communications “ optimisés ”, nous introduisons des “ traces floues ”, décrivant des flots de communications optimisées entre voisinages des pairs. Un tel voisinage est introduit comme un sous-réseau fortement connecté autour d’un pair. Une trace “ floue ” sera dite “ compacte ” lorsqu’elle peut être décomposée en un nombre fini de communications entre voisinage de pair non disjoints (i.e. nombre fini de voisinages recouvrant la trace). La compilation des communications volatiles pair à pair devra générer de telles traces floues compactes optimisant les échanges de données générées par une application. Nous souhaitons tester expérimentalement ces idées nouvelles et formaliser une technique plus générale dans ce sens pour les grilles de calcul. Néanmoins, la volatilité des grilles pair à pair est un handicape pour la phase de “ compilation de communications ”. L’utilisation d’un émulateur de grille pair à pair à grande échelle est donc souhaitable pour pouvoir y compiler les communications en émulant la volatilité ; mais sans à avoir à la gérer lors des optimisations de traces. Ces techniques demandent donc l’utilisation d’un instrument informatique comme GridExplorer pour la mise au point des traces de communications optimisées lors du développement de programme.
Ces travaux sont très exploratoires. Les résultats ne sont pas garantis, il s’agit vraiment d’idées prometteuses mais très nouvelles que nous introduisons ici pour la première fois. A notre connaissance, il n’y a pas d’autres travaux sur le sujet. Dans le cadre du projet décrit ici, nous proposons de :
L’émulateur servira à la fois pour obtenir des traces de communications sans optimisations et avec optimisations, puis pour simuler l’exécution dans les deux cas. Ce qui permettra d’évaluer un gain potentiel. Une phase d’exécution sur une grille réelle pair à pair sera ensuite nécessaire pour valider cette idée et montrer l’importance d’avoir un émulateur pour la mise au point de programmes et de traces de communications. L’émulateur devenant alors un outil important dans la chaîne de programmation scientifique à grande échelle et non uniquement un outil pour mettre au point des middlewares. Cette phase d’expérimentation n’est pas concernée directement pas ce projet. II.7.3 L’échéancier des résultats et réalisations T0 à T0+12 : Définition des communications liées aux méthodes Gauss-Jordan et LU par blocs. Etudes des diverses optimisations algorithmiques liées à ces méthodes et aux ordonnancements ciblés. Définition plus formelle des traces floues compactes. Détermination de ces traces pour les exemples choisis. T0+12 à T0+24 : Tests sur GRIDExplorer. Calcul de traces optimisées et non optimisées. Etudes de plusieurs techniques d’optimisation des traces. T0+24 à T0+36 : Simulation de l’exécution ensuite avec pairs volatiles, dans les deux cas. Evaluation du gain potentiel. Selon les résultats ce travail peut ouvrir la voie vers des recherches plus théoriques sur le sujet.
Pascale Vicat-Blanc Primet, CongDuc Pham, Mathieu Goutelle (doctorant), Faycal Bouhaf (DEA)(INRIA LIP RESO)
On constate aujourd'hui que les applications de grille nécessitant du transport fiable s'appuient en quasi totalité sur le protocole TCP. Or TCP d’une part, n'offre aucun contrôle des délais et des débits et d’autre part, n’est pas conçu pour diffuser des données à large échelle. TCP n'est pas une fatalité, mais une facilité! La communauté réseau active dans le domaine des grilles (Data Transport Research Group au GGF) a donc initié des travaux dans le domaine des protocoles de transport pour réfléchir à des solutions plus adéquates et répondant aux besoins hétérogènes de transferts fiables dans la grille. D'autre part, si IP est aujourd'hui incontournable dans le domaine des grilles, il s'avère que l'utilisation des mécanismes de différenciation de paquets IP peuvent apporter des solutions à un meilleur contrôle des délais et des taux de perte. De nouveaux modèles sont aujourd'hui explorés et déployés dans les réseaux. Par exemple, dans le projet DataGRID, nous avons contribué à faire déployer sur le réseau européen de la recherche GEANT le service Less Than Best Effort qui pourrait permettre aux flux très volumineux d'utiliser la bande passante inexploitée. Cependant les protocoles de transport actuels n'exploitent pas du tout les services offerts par ces traitements différentiés au niveau paquets. TCP a, par exemple, été conçu pour s'adapter à une couche réseau IP "plate" dite "best effort" et ne permet pas le contrôle des délais d’acheminement. D’autre part, pour un certain nombre d’applications de la grille, la diffusion d’une même donnée vers un grand nombre de récepteurs est un réel goulet d’étranglement lorsqu’il faut le réaliser avec un simple protocole de transport fiable point à point tel que TCP. Cependant, aujourd’hui on ne dispose pas de solution de transport multicast fiable réellement opérationnelle et efficace. Le problème de la fiabilité dans le contexte du multicast est un problème ardu et les solutions sont complexes, surtout sur des réseaux étendus et hétérogènes. La conception de protocoles de diffusion fiable efficaces doit en particulier tenir compte des contraintes imposées par la résistance au facteur d'échelle. L'implosion et la surcharge de la source par les messages de contrôle (ACK/NACK) ou l'exposition des récepteurs à des transmissions dupliquées en sont des exemples. Une autre propriété souhaitable, et non des moindres, est la co-habitation des flux multicast avec les autres flux unicast gérés essentiellement par TCP. C'est que ce que l'on nomme communément le contrôle de la congestion. Dans le cas du multicast, il est ardu de concevoir des mécanismes de contrôle de la congestion qui offrent à la fois une bonne utilisation du réseau pour tous les récepteurs, et une compatibilité avec les flux TCP. De manière générale, la fiabilité et le contrôle de la congestion en utilisant l'Internet tel qu'il est actuellement, c'est-à-dire avec un service IP non intelligent, est très difficile (manque d'information sur la topologie, sur le nombres de récepteurs, sur leur capacité...). Certaines approches qui ont été proposées (comme PGM ou LMS par exemple) ajoutent de nouvelles fonctionnalités dans les routeurs (et nécessitent donc des routeurs spécialisés!). Cette démarche montre la nécessité de pouvoir adapter et ajouter dynamiquement des fonctionnalités de haut-niveau dans l'Internet pour offrir un support performant pour les communications de groupe.
Cette étude a pour but d’explorer la problématique du transport fiable de masses importantes de données dans des réseaux hétérogènes. L'objectif est d'étudier et de comparer différentes solutions de transport haute performance exploitant ou non les techniques innovantes de traitements différentiés par classes de paquets ou d'ajout de traitements pertinents réalisés sur les flux lors de leur transfert dans le réseau (technologie des réseaux actifs). La validation actuelle de ces protocoles de transport par simulation n’est pas satisfaisante car elle fait abstraction d’éventuels goulets d’étranglement sur les machines d’extrémité, et d’autre part ne permet pas d’explorer les comportements à des échelles de débit de l’ordre du gigabit. Par ailleurs, les tests sur les plate-formes réelles sont difficiles à exploiter et à comparer dans la mesure où les conditions d’expérience sont mal connues et qu’un grand nombre de paramètres peuvent varier. Dans le cadre de cette étude nous analyserons en particuler l'interaction entre les protocoles et les techniques d'interconnexion Locales, facteur qui est loin d’être négligeable à l’échelle de débits gigabit. La manipulation des paramètres de performance des liaisons longue distance émulées permettra d’isoler plus aisément, pour chaque protocole et pour chaque configuration la part locale de la part WAN. Cette étude se décompose en deux types de travaux:
2) Evaluation des protocoles multicast exploitant l'ajout de traitements pertinents dans le réseau. Evaluation des protocoles transport exploitant efficacement les services IP différentiés Nos études analytiques et expérimentales antérieures nous ont enseigné que les modèles prometteurs de différenciation relative et qui se développent aujourd'hui (Proportionnal DiffServ, Less Than Best Effort) mais aussi les modèles standardisés tels que Assured Forwarding, doivent être associés à des protocoles de transport adoptant un comportement adaptatif qui utilise au mieux, c'est à dire selon leurs besoins propres, l'acheminement différencié offert par le réseau. Les travaux que nous menons actuellement concentrent plus particulièrement nos efforts sur l'étude de protocoles de transport fiables pour petits paquets sensibles aux délais (les souris) et de protocoles de transport fiables pour les transfert de masse (les éléphants) mettant en oeuvre des algorithmes de marquage adaptatif de paquets IP pour honorer des contraintes de performances bout en bout déterministes. Nous projetons en particulier d'étudier le comportement des protocoles de transport haute performance HighSpeed TCP et scalableTCP ainsi que nos protocoles de transport différenciés basés sur SCTP sur plusieurs types de liens émulés. Ces liens offriront soit un service Best effort avec des caractéristiques de délai et de taux de perte maîtrisés, soit des services différenciés non avantagés de type Proportionnal DiffServ ou Equivalent Differentiated Service ainsi que sur le service "Less than Best Effort" dont la validation de bout en bout demeure encore très partielle. Toutes ces évaluations seront comparées au comportement de TCP dans les mêmes conditions expérimentales. Les études menées d’abord sur un seul flux et un seul chemin seront ensuite complétées par des études plus complexes considérant plusieurs flux et un seul chemin ou un même flux et plusieurs chemins. Nous évaluerons aussi des scénarii avec plusieurs chemins alternatifs ainsi que plusieurs scénarii de flux multiples, avec traversée de portions communes. Nous menons actuellement une série d'expérimentations sur un seul flux dans le contexte de l'émulateur NistNet qui permet le contrôle fin du délai et des pertes de bout en bout et qui servira de base au développement d’une méthodologie d’évaluation des protocoles unicast dans un contexte d’émulation de grille et de réseau DiffServ très haut débit. Les résultats obtenus sur cette plate-forme d'émulation seront dans la mesure du possible confrontés aux valeurs effectives obtenues sur les plate-formes expérimentales réelles et auxquelles nous participons : le réseau VTHD et la liaison transatlantique opérée dans le cadre du projet européen DataTAG par exemple. Evaluation des protocoles multicast exploitant l'ajout de traitements pertinents dans le réseau. Nos propositions sur les protocoles de multicast fiable actifs concernent les mécanismes de retransmission (agrégation de message de contrôle, élection de retransmetteurs) et le contrôle de la congestion (agrégation des informations de RTTs, partitionnements). Des tests réels avec plusieurs centaines de machines et de routeurs actifs, organisées en une topologie similaire à celle d'Internet, seront menés pour la validation des solutions actives que nous proposons. II.9.3 L’échéancier des résultats et réalisations De T0 à T12 : pré-étude et/ou développement et instrumentation des protocoles et des services réseaux qui seront évalués. Elaboration d’un méthodologie de validation des protocoles sur l’émulateur précisant en particulier le type et le scénario d’expérience (protocoles comparés, paramètres évalués, topologie choisie), les résultats attendus, les conditions d’expérience (configuration des équipements, sites cibles, valeurs des caractéristiques de performance de chaque lien WAN émulées), le type de trafic injecté, les instruments de mesure utilisés. De T12 à T24 : Evaluation des protocoles de transport unicast sur scénarii simples (n flux hétérogènes sur un seul chemin, un flux sur n chemins). Evaluation des protocoles de transport multicast et des mécanismes de retransmission sur scénarii simples (un flux multicast vers n récepteurs) De T24 à T36 : Evaluation des protocoles de transport unicast sur scénarii complexes (n flux hétérogènes sur n chemins, n flux hétérogènes sur n chemins avec portion commune). Evaluation des protocoles de transport multicast et des mécanismes de contrôle de congestion sur scénarii complexes (flux multicast et unicast ensemble, nombre de récepteurs plus grand, facteur de partitionnement supérieur) A T12 : Document de spécification des protocoles et logiciels évalués + document de méthodologie d’expérimentation. A T24 : Document de résultats d’évaluation des protocoles unicast et multicast dans les scénarii simples. A T36, Document de résultats d’évaluation des protocoles unicast et multicast dans les scénarii complexes. Document de retour d’expérience sur l’utilisation de l’instrument pour ce type d’étude sera produit. Ce document tâchera de comparer les résultats d’évaluation sur l’émulateur et sur les plate-formes réelles accessibles
Jens Gustedt LORIA & INRIA Lorraine Stéphane Vialle Supélec II.11.1 Contexte et Objectif de l’expérience La volonté de vouloir utiliser des dispositifs de calculs très variés pour effectuer un calcul d’une manière transparente, nécessite un changement de paradigme de parallélisation qui prend mieux en compte la localité spatiale et temporelle des données et du calcul. Ce sont les recherches que nous avons commencées avec l’étude théorique et expérimentale des modèles dis à gros grain qui assurent justement une bonne prise en compte de ces deux types de localité. Ce parallélisme à gros grain se prête à simuler de nombreux algorithmes ou modèles à grain fin, si certaines précautions sont prises. Une grande famille de tels modèles peuvent être décrit par des automates cellulaires ; modèles utilisés par grand nombre de travaux théoriques, expérimentaux et pratiques dans d’autres disciplines. Mais quelques extensions de ces modèles les enrichissent considérablement, comme la possibilité pour chaque cellule de posséder son propre code, et son propre voisinage d’influence sur les autres cellules. Des capacités de création et destruction dynamique de cellules et de connexions entre cellules permettent notamment d’envisager des applications de type corticales développées au LORIA (équipe Cortex) et à Supélec (équipe Ersidp). Nous nous intéressons donc aux modèles de programmation cellulaires étendus. II.11.2 Description de l’expérience Le cadre applicatif Les systèmes de calculs distribués d’orientation cellulaire sont constitués d’un grand nombre d’entités de calcul autonomes, échangeant des informations. Ce sont par exemple des automates cellulaires employés dans diverses simulations de phénomènes physiques modélisés simplement à partir d’équations locales (lorsque des modèles de plus haut niveau ne sont pas connus), ou bien certains systèmes multi-agents situés modélisant des colonies d’insectes, ou encore des systèmes corticaux (réseaux de neurones d’inspiration neurobiologique) constitués de milliers d’unités interconnectées. La richesse de ces systèmes se trouve autant dans les calculs de leurs nombreuses entités que dans leurs communications. En conséquence, cette distribution des calculs et ces communications doivent être modélisées et implantées, et surtout pas éludées. Afin de rendre la programmation des systèmes de calculs distribués d’orientation cellulaire plus simple et plus efficace, des recherches en conception de modèles de programmation parallèle adaptés à ces systèmes ont été entreprises depuis 1989 à Supélec et au LORIA (modèles ParCeL). Plusieurs thèses ont été menées sur ce thème, et plusieurs outils de programmation parallèle ont vu le jour, cherchant à la fois une sémantique adaptée au besoin de l’utilisateur, et une implantation efficace sur machines parallèles généralistes modernes (machines MIMD). Aujourd’hui nous proposons d’étendre nos recherches de modèles de programmation parallèle pour des systèmes cellulaires étendus, à des grilles de calcul, afin de pouvoir les exécuter sur des architectures parallèles variées, et notamment sur des ensembles de grappes de PC. C’est-à-dire sur des architectures parallèles bon-marché facilement accessibles. Nous souhaitons développer ainsi rapidement et naturellement des systèmes corticaux à travers une grille de calcul, pour accomplir des tâches de vision en robotique qui demandent trop de ressources de calcul pour être embarquées, et des simulations de phénomènes physiques basées sur des équations locales. Utilisation d’un modèle algorithmique et d’une bibliothèque adaptée L’obtention de bonnes performances sur des grilles de calcul n’est pas simple, les communications ne sont pas négligeables, et leurs performances peuvent être très variables. De plus, il nous faut intégrer des contraintes de gestion mémoire optimisées si nous voulons concurrencer les programmes écrit avec des modèles de programmation de plus bas niveau permettant par exemple d’optimiser l’exploitation des mémoires caches. Enfin, nous souhaitons aboutir à une algorithmique et une implantation portables, et non pas dédiées à une grille particulière. Pour cela nous souhaitons aborder la parallélisation de systèmes corticaux en suivant le modèle algorithmique PRO, et en exploitant la librairie SSCRAP associé à ce modèle. PRO permet d’exprimer diverses contraintes de programmation correspondant par exemple à une gestion mémoire rigoureuse, et à une optimisation des communications. SSCRAP est disponible sur de nombreuses architectures parallèles, et une implantation de nos systèmes de calculs distribués en SSCRAP nous assurera une grande portabilité, très utile dans le cadre des grilles de calcul. SSCRAP est implanté en mémoire partagée à partir de threads et en mémoire distribué à partir d’envois de messages (MPI). Nous chercherons donc à finaliser la conception d’un environnement de développement parallèle et d’un modèle de programmation de haut niveau pour les systèmes cellulaires étendus (ParCeL-6), en suivant le modèle algorithmique PRO, et en exploitant la bibliothèque SSCRAP pour son implantation sur la grille. II.11.3 L’échéancier des résultats et réalisations T0 à T0+12 : Développement de la plate-forme ParCeL-6+SSCRAP sur d’autres dispositifs déjà existant, grappe Myrinet spécialisé au LORIA, grappe Beowulf et grappe Gigabit à Supélec, Origin 3000 au LORIA. T0+12 à T0+18 : Déploiement (avec pour la premiere fois plus de 16 nœuds distribués) sur Grid-Explorer et première mesures de performances à large échelle. T0+18 à T0+24 : Optimisation poussée du code pour les architectures à large échelle et pour une grande variété de problèmes (réseaux de neurones statiques, réseaux de neurones dynamiques, simulation physiques, mécanismes internes de SSCRAP). T0+24 à T0+36 : Déploiement d’applications complètes et répétition des expériences (sous différents contextes de réseaux et différents charges externes) pour la demonstration de la reproductibilité des résultats. Publications. Diffusion du savoir faire à différents types de publics (étudiants d’école doctorale et d’école d’ingénieurs, communauté d’utilisateurs potentiels (physiciens et connexionistes)).
Joffroy Beauquier, Brigitte Rozoy, Sébastien Tixeuil, Cécile Germain, LRI et INRIA "Grand Large", Colette Johnen, LRI II.14.1 Objectifs et contexte Les systèmes de la prochaine génération "petascale" grouperont de 50 000 à 100 000 processeurs. Pour de tels systèmes les études prospectives sur la fiabilité indiquent que le temps moyen entre deux défaillances (panne crash) sera seulement de quelques minutes. Les techniques majoritairement utilisées actuellement, à base de points de reprise, seront totalement inadaptées, car il est irréaliste de relancer 99 999 processeurs parce qu'un seul est tombé en panne. De toutes façons, relancer globalement un tel système est un problème en soi et on peut s'attendre à ce que le temps nécessaire pour exécuter le redémarrage excède largement cinq minutes. Il importe donc que la propriété de résistance aux défaillances soit réalisée d'une autre manière, la plus locale possible pour pouvoir passer à l'échelle. II.14.2 Description du projet Nous proposons d'attaquer ce problème au travers de deux approches, qui, loin de s'exclure mutuellement, se complètent et pourraient donner lieu à des solutions hybrides : 1) La première approche consiste à "durcir" les protocoles qui gèrent le système, soit en les rendant totalement insensibles aux défaillances (approche dite masquante, à base de redondance, puis de consensus [4]), soit en leur donnant une propriété d'auto-récupération (approche dite non masquante, comme l'auto-stabilisation [1]), signifiant qu'après une période aussi courte que possible, le système retrouve, de lui-même, sans redémarrage et sans intervention extérieure, un comportement correct. Bien entendu ce "durcissement" doit passer à l'échelle et des travaux existent qui prouvent que cela est possible (early stopping pour le consensus, time adaptivity pour l'auto-stabilisation [2,3]). 2) Parallèlement il nous paraît urgent d'établir une fondation pour une nouvelle classe d'applications, dont les deux caractéristiques fondamentales seraient la faculté de passer à l'échelle (c'est-à-dire de conserver un comportement raisonnable même lorsque le nombre de processeurs augmente considérablement), et de posséder des propriétés de point fixe leur permettant de résister aux défaillances, même en l'absence de mesures spécifiques au niveau système. Des applications à la biologie ont montré qu'une certaine indépendance des tâches garantit de telles propriétés mais il serait intéressant à notre sens d'établir des conditions nécessaires. Nous proposons d'intervenir sur ces deux axes tout d'abord de manière expérimentale pour tester les principales solutions "proportionnelles" au nombre de défaillances connues, dans un environnement réel et pas seulement du point de vue de la complexité abstraite. Nous proposons aussi, à la lumière de ces expérimentations, de concevoir des méthodes de durcissement au niveau système. Enfin, nous voulons donner un début de classification des types d'algorithmes vis à vis du passage à l'échelle et là encore, des expérimentations seront nécessaires. II.14.3 L’échéancier des résultats et réalisations Nous souhaitons tout d’abord montrer la faisabilité de la propriété d’auto-récupération sur une plate-forme homogène distribuée. T0 -> T0+12 : Etude théorique du problème en attendant la réalisation de Grid Explorer. T0+12 -> T0+24 : Ecriture d’un prototype permettant le durcissement des protocoles réseau et système sur les nœuds. De Grid Explorer. T0+24 -> T0+30 : Mise en œuvre du prototype sur Grid-Explorer. Test du prototype en exécutant un middleware de grille dans l’environnement émulé. T0+30 -> T0+36 : Validation de l’expérience, amélioration du prototype, publication. A terme émuler de manière efficace les algorithmes auto-récupérants permettra de tester des algorithmes conçus pour fonctionner en milieu hétérogène et de valider les simulateurs. I.14.4 Références [1] S. Dolev. Self-stabilization. The MIT Press. 2000. [2] S. Kutten and D. Peleg, "Tight Fault-Locality" SIAM J. on COMPUTING 30(1): 247-268 (2000). A preliminary version appeared in Proceedings of the 36th Annual IEEE Symposium on Foundations of Computer Science(FOCS 95), Milwaukee, WI, USA, October 1995. [3] Shay Kutten and Boaz Patt-Shamir "stabilizing Time Adaptive Protocols", Theoretical Computer Science 220(1): 93-111 (1999). A preliminary version ("Time Adaptive Self Stabilization") appeared in Proceedings of ACM PODC 1997. [4] Tushar Deepak Chandra, Sam Toueg: Unreliable Failure Detectors for Reliable Distributed Systems. JACM 43(2): 225-267 (1996)
Joffroy Beauquier, Thomas Hérault, Frédéric Magniette, Ludovic Mé, Eric Totel, LRI, INRIA "Grand Large", et Supélec Rennes. II.15.1 Objectifs et contexte Il s'agit d'un domaine très vaste et nous considérons que le travail à effectuer dans cet axe doit se fixer sur un sujet précis, spécialement relevant de la grande échelle. De manière générale, en matière de sécurité, le point qui est souvent considéré comme essentiel est l'authentification (comment prouver que quelqu'un est bien celui qu'il prétend ?), en connotation avec le concept de signature. Le problème de l'autorisation (comment faire en sorte que ce que quelqu'un fait, il a bien le droit de le faire ?) est également un problème important. On peut dire qu'il reçoit des solutions assez satisfaisantes avec le système d'autorités de certification. Un organisme centralisé, de confiance, délivre des certificats qui garantissent que les accès sont bien autorisés. Or il est bien connu que les solutions centralisées passent difficilement à l'échelle [1]. Il est intéressant de noter que dans le projet Datagrid, si 17 problèmes documentés relèvent de l'authentification, 32 relèvent de l'autorisation (Réf. Datagrid document D7.5). On peut penser que dans un système à grande échelle performant et efficace, la partie qui relève d'un traitement plus ou moins centralisé doit être renforcée localement par un contrôle des accès. Les pare-feu et les serveurs proxy sont des techniques qui permettent d'améliorer des paquets suspects, mais personne ne considère qu'il s'agit de solutions absolues. II.15.2 Description du projet Nous proposons, en complément de ces outils, d'étudier des solutions plus locales renforçant le contrôle d'accès, la détection d'intrusion [2,4] et le sandboxing [5]. L'idée derrière un système de détection d'intrusions est simple : un agent examine l'activité d'une machine ou le trafic et rapporte tout comportement jugé étrange à un administrateur. Le système peut se trouver sur la machine elle-même, ce qui lui permet de détecter les dysfonctionnements à la fois externes et internes, ce que ne peut pas faire un pare-feu. L'intérêt d'un système interne provient du fait qu'une partie des attaques peut provenir d'utilisateurs régulièrement enregistrés. D'autre part, installer un autre contrôle au niveau du réseau, qui examine le trafic paquet par paquet et qui analyse des signatures d'attaques, permet une réaction rapide, ce qui est important pour contrer les diverses formes d'attaques Nous proposons également d'étudier le mécanisme des sandboxes [5], qui sont des environnements qui imposent des restrictions irrévocables, à la fois qualitatives et quantitatives, à l'utilisation des ressources, en contrôlant de manière très précise les interactions entre une application et le système sous-jacent. Il est pratiquement impossible d'analyser abstraitement de tels mécanismes et c'est pourquoi nous proposons de réaliser des études expérimentales et comparatives des différentes solutions. II.15.3 L’échéancier des résultats et réalisations Nous souhaitons tout d’abord monter un dispositif expérimental pour tester et valider des concepts de sécurité appliqués à la soumission et à l’exécution de binaires non validés sur une plate-forme homogène distribuée. T0 -> T0+12 : Etude théorique du problème en attendant la réalisation de Grid Explorer. T0+12 -> T0+24 : Ecriture et adaptation d’une sandbox avec détecteur d’intrusion. T0+24 -> T0+30 : Mise en œuvre du prototype sur Grid-Explorer. Ecriture de tests d’intrusion. T0+30 -> T0+36 : Validation de l’expérience, publication. II.15.4 Références [1] J. C. Laprie, J. Arlat, J.-P. Blanquart, A. Costes, Y. Crouzet, Y. Deswarte, J.-C. Fabre, H. Guillermain, M. Kaâniche, K. Kanoun, C. Mazet, D. Powell, C. Rabéjac, and P. Thévenod, Guide de la sûreté de fonctionnement, 2ème édition ed: Cépaduès Éditions, 1996. [2] A. Avizienis, "Design of Fault-Tolerant Computers," presented at Fall Joint Computer Conference, Washington D.C., 1967. [3] D. Powell and R. Stroud, "MAFTIA Conceptual Model and Architecture," LAAS-CNRS MAFTIA deliverable D2, November 20 2001. [4] J. P. Anderson, "Computer Security Threat Monitoring and Surveillance," James P. Anderson Company, Fort Washington, Pennsylvania 1980. [5] P. Loscocco, S. Smalley. “Integrating Flexible Support for Security Policies into the Linux Operating System”. Proceedings of the USENIX Annual Technical Conference. 2001 B4 – Summary (in English) : (1 to 2 pages) Le Conseil Scientifique pourra solliciter des experts non francophones auxquels sera envoyé l’ensemble des documents. Le présent résumé, entièrement rédigé en anglais, visera à fournir une présentation synthétique de l’ensemble du projet. C – Moyens financiers et humains demandés par chaque équipe13 Comme indiqué dans les tableaux ci-dessous, on distinguera - les financements via le Fonds National pour la Science qui peuvent inclure * du fonctionnement * de l’équipement * des mois de personnel temporaire (CDD) pour un montant ne pouvant excéder 50% du financement total attribué. La durée du ou des contrat(s) prévus, qui ne peuvent excéder 24 mois chacun, sera précisée. - les moyens demandés aux organismes de recherche qui peuvent inclure * des postes de post-doc * des demandes de délégation ou détachement pour des enseignants-chercheurs * des accueils de chercheurs étrangers - les demandes d’allocations de recherche Les diverses possibilités concernant l’attribution de moyens pour recruter ou accueillir des personnels seront globalement très limitées pour l’ensemble des ACI. Leurs demandes devront donc être particulièrement justifiées. Si les bénéficiaires de ces demandes sont connus ou pressentis, les CV correspondants seront joints à la présente demande. Dans le cas des moyens alloués par les organismes, il n’est pas nécessaire de préciser à quel organisme (CNRS ou INRIA) ces moyens seront demandés, sauf cas particulier à expliciter. Ces moyens seront en effet répartis globalement au niveau de l’ACI, en tenant compte bien sûr des règles et contraintes propres à chaque organisme. On présentera une justification scientifique des moyens demandés pour chacune des équipes impliquées dans le projet. Yüklə 0,54 Mb. Dostları ilə paylaş:
|