La technologie « cloud » Sa place en physique des hautes énergies C. Loomis (CNRS/LAL) Seillac mai 2010 The StratusLab project is partially funded by the European Commission through the grant agreement RI

2 Agenda La technologie « cloud » (nuage)  Les acronymes chics : IaaS, PaaS, et SaaS  Les avantages et désavantages La comparaison avec la grille  Les différences et les similarités Le projet StratusLab  Les buts du projet  Les informations sur le projets L’utilisation en physique des hautes énergies Conclusions

3 Le « cloud » Le « cloud » est le nouveau « grid »  Le mot a plusieurs définitions (incompatibles!)  Une étiquette utilisée pour vendre les trucs existants  Malgré cela, il y a des idées intéressantes à l’intérieur Convergence de plusieurs idées  La maturation de la technologie pour la virtualisation  Apparition des APIs simplifiées (REST, XMLRPC, …)  Une grosse puissance informatique (commerciale) pour valoriser Les différents types de « cloud »  Infrastructure as a Service (IaaS)  Platform as a Service (PaaS)  Software as a Service (SaaS)

4 Infrastructure as a Service (IaaS) Architecture  Fournir les « matériels » virtualisés à la distance  Apparaître comme machines physiques : CPU, disque, mémoire, …  Au minimum doit gérer le CPU, les données, et le réseau  Ex. Amazon Web Services, GoGrid, FlexiScale, ElasticHosts Avantages  Environnement d’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

5 Platform as a Service (PaaS) Architecture  Plateforme pour le développement des applications web  Aussi une infrastructure pour déployer et exécuter ces applications  Ex. Google App Engine, Azure Avantages  Fonctionnalités comme équilibrage de la charge, redondances des services, etc. sont fournies par le système  Les programmeurs peuvent éviter de faire la plomberie de bas niveau Désavantages  La plateforme requiert un langage de programmation spécifique  Les applications créées ne sont pas portables

6 Software as a Service (SaaS) Architecture  Une application accessible via le web  Pas beaucoup plus que « hosting » déguisé  Ex. Google Apps, SalesForce Avantages  Utilisation très simple : aucun déploiement du logiciel, interface web  Très accessible : portable, téléphone, … Désavantages  Questions : accès aux informations, qui est propriétaire des informations, pérennité des services, etc.  Parfois difficile de combiner plusieurs services

7 Est-ce qu’on va remplacer la grille? Non, les technologies sont complémentaires! Grille : Fédérer les ressources distribuées via des interfaces génériques  Une modèle de sécurité homogène  Partage des ressources via les organisations virtuelles  Une architecture « système de batch »  Gestion des fichiers « Cloud » : Déploiement ponctuel de ressources personnalisées  Environnement dynamique, élastique, et personnalisé  Des abstractions à plusieurs niveaux (IaaS, PaaS, et SaaS)  Basé sur les technologies de virtualisation

8 Virtualisation ≠ Cloud CPU  Machines virtuelles créées par les utilisateurs  Dépôt des images virtuelles Gestion des données  Le « cloud » doit avoir la capacité de 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

9 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 Démontrer la qualité production de la distribution  Mettre en production au minimum deux sites grilles en production  Vérifier la performance pour des applications réelles Des « benchmarks »  « Simulation » : CPU-intensive  « Analysis » : IO-intensive (entrée)  « Filtering » : IO-intensive (entrée/sortie)  « Shared Memory » : application multi-threads  « Parallel » : application MPI sur plusieurs machines

10 StratusLab en chiffres StratusLab (StratusLab.eu)  Enhancing Grid Infra. with Virtualization and Cloud Technologies  Début : 1 June 2010 (24 mois) Budget  Total : ~3,1 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 : Coordination, interactions avec utilisateurs, site grille

11 Partenaires du projet StratusLab Centre Nationale de la Recherche Scientifique (CNRS)  Coordination (LAL), liaison avec les utilisateurs (LAL, IBCP) Universidad Complutense de Madrid (UCM)  Coordination technique, développeurs d’OpenNebula Greek Research and Technology Network (GRNET)  Gestion des infrastructures de test et de production SixSq Sàrl (SixSq)  Intégration des outils, gestion des process de reconstruction 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

12 Centre des ressources Centre des ressources grille avec StratusLab Distribution StratusLab Cloud privé Cloud API Grid Services clouds publics utilisateurs

13 Environnement personnalisé  Réduire les problèmes dus aux environnements inhomogènes  Déployer les distributions (complexes et volumineuses) du soft des expériences Evolution découplée du matériel, des OS et des applications  Les environnements des services et des utilisateurs sont indépendants  Migrer entre SL4, SL5, … indépendamment les uns des autres Serveurs/services déployés dynamiquement  Services des VOs : VOBoxes, DIRAC Task Queue, …  Systèmes personnalisés : Proof cluster, …  Services utilisateurs déployés à l’intérieur de l’infrastructure Bénéfices concrets

14 Conclusions StratusLab  Créer une distribution « cloud » complète et open-source  Garder la possibilité de fédérer les ressources distribuées  Une infrastructure hybride à partir de septembre 2010 La technologie cloud  Très mature (voir Amazon)  Fournit des bénéfices concrets  Pas encore standardisée  Supportée par l’industrie (potentiellement cher)