140 likes | 207 Views
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. Agenda. La technologie « cloud » (nuage)
E N D
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
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
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)
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
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
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
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
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
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
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
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
Centre des ressources grille avec StratusLab utilisateurs Centre des ressources Grid Services Cloud API Distribution StratusLab Cloud privé clouds publics
Bénéfices concrets • 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
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)