La technologie « cloud » Sa place en physique des hautes énergies C. Loomis (CNRS/LAL) Seillac 2010 27 mai 2010 The StratusLab project is partially funded.

Présentation au sujet: "La technologie « cloud » Sa place en physique des hautes énergies C. Loomis (CNRS/LAL) Seillac 2010 27 mai 2010 The StratusLab project is partially funded."— Transcription de la présentation:

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

2 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 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 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 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 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 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 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 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 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 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 12 Centre des ressources Centre des ressources grille avec StratusLab Distribution StratusLab Cloud privé Cloud API Grid Services clouds publics utilisateurs

13 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 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)