Télécharger la présentation
La présentation est en train de télécharger. S'il vous plaît, attendez
Publié parArsène Gascon Modifié depuis plus de 8 années
1
La grille et le « cloud » Les technologies complémentaires pour les infrastructures informatiques distribuées C. Loomis (CNRS/LAL) Jounées Informatique 2010 (Aussois) 20 mai 2010 The StratusLab project is partially funded by the European Commission through the grant agreement RI-261552
2
2 Agenda La technologie grille Une initiative académique Les avantages et désavantages La technologie « cloud » (nuage) Des initiatives commerciales Les avantages et désavantages Le projet StratusLab Les buts du projet Les informations sur le projets Le plan de travaille (et vos contributions!) Conclusions
3
3 La histoire de la grille en Europe European DataGrid (2001-2004) R&D pour la grille en Europe Résultats : une distribution middleware, des communautés européennes, une prototype pour les opérations européennes Les projets EGEE-I, II, et III (2004-2010) Une infrastructure stable et paneuropéenne Résultats : la plus grosse infrastructure grille du monde, l’utilisation habituelle dans 7+ domaines différentes Les autres projets DORII, int.eu.grid, NorduGrid, EDGeS, … European Grid Infrastructure (début 1 mai 2010) Fournir une infrastructure grille pérenne pour l’Europe Constitué des « National Grid Initiatives » dans chaque pays
4
4 European Grid Infrastucture Dimensions humaineRessources 55 pays> 260 sites 14k utilisateurs150k cœurs CPU 200 organisations virtuelles330K tâches / jour >7 disciplines scientifiques28 Po disque Real Time Monitor http://gridportal.hep.ph.ic.ac.uk/rtm/
5
5 Disciplines scientifiques Application Database http://appdb.eu.egee.org/ Disciplines scientifiques Astronomie et astrophysique Chimie Systèmes complexes* Fusion Humanités* Informatique et ingénerie Science des photons* Physique des hautes énergies Science de la vie Science de la terre
6
6 Les avantages et désavantages de la grille Architecture CPU : conçu comme système de batch distribué Données : gestionnaire des fichiers Avantages Une modèle de sécurité homogène Partage des ressources, des algorithmes, et des expériences vers les organisations virtuelles Désavantages Tendance vers la complexité (APIs, services, etc.) Utilisation difficile pour les applications « non-batch » Environnement inhomogène qui réduit le taux de succès Impossibilité de déployer les services « VO » sur l’infrastructure
7
7 Le « cloud » Convergence des plusieurs idées La maturation de la technologie pour la virtualisation Apparence des APIs simplifiés (REST, …) Une grosse capacité informatique pour valorisée Une besoin des ressources ponctuelle La taxonomie du « cloud » Infrastructure as a Service (IaaS) Platform as a Service (PaaS) Software as a Service (SaaS)
8
8 Infrastructure as a Service (IaaS) Architecture Fournir les « matériels » virtualisés à la distance Apparaître comme machine physiques : CPU, disque, mémoire, … Ex. Amazon Web Services, GoGrid, FlexiScale, ElasticHosts Avantages Environnement de l’exécution personnalisée Accessible à toute moment avec une API simple Contrôle complet de la ressource virtualisée Désavantages Interfaces non standardisées La création des machines virtuelles est difficile
9
9 Platform as a Service (PaaS) Architecture Plateforme pour la développement des applications web Aussi une infrastructure pour déployer et tourner ces applications Ex. Google App Engine, Azure Avantages Fonctionnalités comme équilibration du charge, redondances des services, etc. sont fournis par le système Programmeurs peuvent éviter de faire les plomberie de bas niveau Désavantages La plateforme requis un langage de programmation spécifique Les applications créer ne sont pas portables
10
10 Software as a Service (SaaS) Architecture Une application accessible vers le web Plus ou moins une service « hosting » Ex. Google Apps, SalesForce Avantages Utilisation très simple : aucune déploiement du logiciel, interface web Très accessible : portable, téléphone, … Désavantages Questions : accès aux informations, propriétaire des informations, pérennité des services, etc. Des fois difficile à utiliser plusieurs services ensemble
11
11 Virtualisation ≠ Cloud CPU Machines virtuelles créées par les utilisateurs Dépôt des images virtuelles Gestion des données Le « cloud » doit avoir les moyennes pour gérer les donnés Gestion des fichiers, gestion des disques Réseau Gestion (dynamique) des ports entrants et sortants Existence d’une adresse IP publique (sur demande) Logiciels « cloud » Nimbus, Eucalyptus, OpenNebula
12
12 Les technologies complémentaires Grille : Fédérer les ressources distribuées vers des interfaces génériques Une modèle de sécurité homogène Partage des ressources vers les organisations virtuelles Une architecture « système de batch » Gestion des fichiers « Cloud » : Déploiement ponctuelle des ressources personnalisées Environnement dynamique, élastique, et personnalisée Des abstractions aux plusieurs niveaux (IaaS, PaaS, et SaaS) Basé sur les technologies pour la virtualisation
13
13 La vision du projet StratusLab Créer une distribution « cloud » complète et open-source Utiliser les technologies grille et « cloud » ensemble Optimiser et simplifier le mise en œuvre des sites Permettre une accès « cloud » aux infrastructures existantes Faire preuve la qualité production de la distribution Utiliser au minimum de deux sites grilles en production Vérifier la performance pour les applications concrètes Des « benchmarks » « Simulation » : CPU-intensive « Analysis » : IO-intensive (entrée) « Filtering » : IO-intensive (entrée and sortie) « Shared Memory » : application avec plusieurs threads « Parallel » : application MPI sur plusieurs machines
14
14 StratusLab en chiffres StratusLab (StratusLab.eu) Enhancing Grid Infra. with Virtualization and Cloud Technologies Début : 1 June 2010 (24 mois) Budget Total : ~3,3 M€ (2,3 M€ de la CE) Effort : 340 hommes mois (~14 EPT) Activités NA—Project Coordination, Community Interactions, Dissemination SA—Integration & Distribution, Infrastructure Operation JRA—Innovative Management of Services & Resources Participation française Budget : ~470 k€ (54 PM LAL, 27 PM IBCP) Activités : Project coordination, user interaction, production site
15
15 Partenaires du projet StratusLab Centre Nationale de la Recherche Scientifique (CNRS, LAL et IBCP) Coordination du projet, liaison avec les utilisateurs Universidad Complutense de Madrid (UCM) Coordination technique, développeurs du OpenNebula Greek Research and Technology Network (GRNET) Gestion des infrastructures du test et de la production SixSq Sàrl (SixSq) Intégration des outils « cloud », gestion des processus du « build » Telefónica Investigación y Dessarrollo (TID) Développement des fonctionnalités avancées Trinity College Dublin (TCD) Dissémination, dépôt des images des machines
16
16 Project’s Vision over a Medium to Long-Term Timeframe StratusLab Grid Services StratusLab Cloud API Community Services Community Services Novel Services E.g. Hadoop, PaaS, Web 2.0 User Communities Y0: Grid and community services running directly on RC hardware. Y1: Grid services running on private clouds. Scaling out to commercial providers possible. Y2: Cloud API provided. Virtualized machines available to end users. Y3: Community services run on standard resources via StratusLab cloud API. Y4: Additional community services and novel services are built on top of cloud API. Public Clouds
17
17 Environnement personnalisée Réduire des problèmes qui vient des environnements inhomogènes Fournir une infrastructure plus attractive pour les disciplines scientifiques autre que HEP Serveurs/services déployés par les organisation virtuelles Plusieurs exemples existent : VOBoxes, DIRAC Task Queue, … Actuellement hors grille ou quasi hors grille Bénéfices concrets pilot job controller grille
18
18 Collaboration Communauté des utilisateurs Chercheurs Ingénieurs informatiques, chercheurs « informatisés » Administrateurs de services « VO » Administrateurs des systèmes Ingénieurs responsables pour les services grilles, … Techniciens pour dépanner les matériels On cherche : Chercheurs intéressés par un accès « cloud » aux ressources grilles Les gens qui veulent déployé leurs services « VO » dynamiquement Sites qui veulent installer la distribution StratusLab Feedback des toutes les acteurs
19
19 Conclusions StratusLab But : créer une distribution « cloud » complète et open-source Résultat : une infrastructure mixte plus fonctionnelle et plus attractive aux utilisateurs Processus « agile » pour faire évoluer rapidement et garantir une haute qualité Première version septembre (M3) et une nouvelle version chaque mois après On veut collaborer avec : Les utilisateurs qui veulent utiliser une ressource « cloud » Les administrateurs des systèmes qui veulent installer la distribution
Présentations similaires
© 2024 SlidePlayer.fr Inc.
All rights reserved.