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

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 La histoire de la grille en Europe European DataGrid ( )  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 ( )  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 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

5 Disciplines scientifiques Application Database 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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