Infrastructure web élastique avec OpenStack

Transcription

1 Infrastructure web élastique avec OpenStack Auteurs: Pierre Boesch, Florentin Clouet, Gwenaël Coulombet, Sébastien Philippot Résumé OpenStack est une solution de Cloud. L objectif de ce projet est de mettre en place un Cloud privé OpenStack et de l utiliser pour y déployer une infrastructure web élastique avec HaProxy. 1

2 Table des matières 1 Introduction Présentation de la problématique Le cloud computing OpenStack et le cloud Le Grid Présentation de Grid État de l art Openstack Petite introduction Architecture Les modules Version actuelle Web élastique Cahier des charges Présentation du projet Objet du projet Objectifs Délai Composition de l équipe Environnement Réalisations Suivi de projet Tâches réalisées Installation dans la salle 501 d OpenStack sur Ubuntu Avancé dans la largeur : Compréhension dans la profondeur

3 4.2 Installation sur Grid Planning prévisionnel pour le reste du projet 15 3

4 1 Introduction 1.1 Présentation de la problématique L objectif de notre projet tuteuré est d étudier le fonctionnement d une plate-forme de cloud computing (IAAS 1 ). Cette solution repose sur la mise en place d un load balancer 2 HTTP, OpenStack permet de fournir de manière centralisée et automatisée des ressources virtuelles. La finalité de ce type d infrastructure est de pouvoir allouer dynamiquement et automatiquement des services (Web, machines virtuelles, stockage...) par rapport au nombre de ressources demandées. La principale raison d utiliser une telle infrastructure est financière. En effet, beaucoup de structures disposant d un site web se confrontent à une problématique : Comment garantir une disponibilité de services lorsque les ressources demandées explosent sur une courte période? Pendant un temps, les structures confrontées à cette problématique ont surdimensionné leurs serveurs pour faire face au plus grand pic de charge de l année. Ainsi, ils pouvaient garantir une continuité de services. Cependant le reste de l année, une grande partie de leurs serveurs restaient non sollicités, ce qui implique un fort coût de fonctionnement non amorti. Pour prendre un exemple concrêt, nous pouvons citer l effet Capital 3. Lorsque une référence à une entité est faite, cette dernière subit systématiquement un pic de fréquentation sur son infrastructure. Quelques articles 4 illustrent l évolution du besoin de ressources sur une courte période. Environ 3 5 millions de personnes regardent Capital, lorsque l émission fait référence à une entreprise, les gens se ruent sur le site web de cette dernière. Pour l entreprise, c est une exposition médiatique qu il ne faut pas rater, cependant il est difficile de faire face à la charge sur une très courte période. L entité pourrait alors surdimensionner ces serveurs, cependant ces derniers seront inutilisés le reste de l année. La solution dans ce type de situation est de faire du Web élastique, ainsi grâce à des équilibreurs de charges, on peut définir suivant différents critères (heure précise, charge CPU, charge réseaux...) un déploiement d une infrastructure virtuelle pouvant garantir la continuité de services pour une courte durée. Cette solution permet de déployer rapidement une infrastructure en interne ou en externe (chez Amazon par exemple) et d être facturé en fonction de la consommation. 1.2 Le cloud computing Depuis quelques années, les médias et publicitaires usent (et abusent) du mot cloud. C est un buzzword 5 plutôt nébuleux qui cache derrière lui plusieurs principes. Cependant le terme cloud ainsi utilisé dans les médias et les publicités concerne souvent le SaaS, c est à dire Software As a Service. Le cloud computing n est pas (seulement) du SaaS, il englobe en fait trois modèles qui englobent trois types de services : Les solutions de cloud peuvent être divisées en trois modèles en 1. Infrastructure as a Service 2. répartition de charge 3. Émission diffusé le dimanche soir par le groupe M6 4. http :// 5. Un buzzword est un terme qui est utilisée comme slogan pour désigner une nouveauté et pour attirer l attention sur cette nouveauté. (Source :Wikipédia) 4

5 fonction de l ouverture de celles-ci : Le cloud privé : dans ce cas, l entreprise gère en interne sa solution de cloud. L avantage premier est que l entreprise garde le contrôle des systèmes et des données et n est pas dépendante d une solution externe. Le déploiement d une telle infrastructure est néanmoins très coûteuse, puisqu elle doit répondre à de nombreux critères, afin de garantir redondance, variation de charges, pannes, etc... On peut dissocier deux sous-types de cloud privé : l interne et l externe. En interne, c est l entreprise qui va entièrement gérer son infrastructure (électrique, réseaux, systèmes, etc...), alors qu en externe, l entreprise externalisera chez un prestataire. Le cloud public : est souvent proposé par de grosses entreprises spécialisées gérant de nombreux datacentres. Ces dernières offrent le service ou le louent à des particuliers ou à des professionnels. Les offres sont souvent attractives et facturées à la consommation. Dans ce cas, ce n est plus le client mais le prestataire qui gère l ensemble de l infrastructure. Cela apporte une souplesse au client mais le rend dépendant à une solution qu il ne contrôle pas. De plus, il est souvent plus facile d adopter une solution de cloud public que d en partir. Une solution de cloud public semble séduisante aux vues des nombreux attraits économiques qu elle apporte, il n y a en effet pas besoin de gérer de matériel, d équipe humaine, de maintenance, de locaux, etc... Cette dernière apporte de nombreuses problématiques notamment liées à la confidentialité ainsi qu à l intégralité des données. Les fournisseurs de cloud public se protègent souvent juridiquement en cas de piratage ou de perte des données. La confidentialité étant dans certains secteurs (aéronautique, recherche, santé...) primordiale pour le bon fonctionnement de l entité, il semble important de prendre en considération qu utiliser un service de cloud public dans ce type de domaine est non recommandé. Les différents événements récents ont démontré que certains pays étaient adeptes de ce type d intelligence économique. Les différents modèles de cloud englobent plusieurs types de services, que l on peut regrouper en trois parties (il existe néanmoins d autres types de «As a Service» comme le DaaS 6, STaaS 7 : IaaS - Infrastructure As a Service : Le but est d offrir un service de bas niveau, le consommateur peut alors choisir le système d exploitation et y installer les outils adaptés à ses besoins. Il est possible de louer dynamiquement des machines virtuelles pour une courte durée, mais il est également possible de louer un ensemble de machines constituant une infrastructure externe. Les acteurs français du IaaS sont Online.net, OVH (Kimsufi),... PaaS - Platform As a Service : Cette fois-ci, le système est déjà installé, c est le fournisseur qui gère le système et l infrastructure. Le consommateur profite alors de la plate-forme pour y installer les applications souhaitées. Un exemple illustrant bien le PaaS est l hébergement web, où l hébergeur fournit une plate-forme souvent LAMP 8, afin d y héberger des sites web ou des systèmes de gestion de contenus. SaaS - Software As a Service : C est une suite d application(s) proposée(s) aux consommateurs. Ces derniers ne s occupent de rien, c est le fournisseur qui gère l intégralité de l infrastructure, des systèmes et des logiciels. Gmail, Office Web Apps, Google Apps sont les 6. Data as a Service 7. Storage as a Service 8. Linux, Apache, MYSQL, PHP 5

6 fournisseurs de SaaS les plus connus OpenStack et le cloud Le cloud computing regroupe donc principalement trois catégories. OpenStack permet de faire du IaaS. C est un projet relativement jeune, il a débuté en 2010 par une initiative de RackSpace Hosting et de la NASA. L objectif du projet est de fournir un projet innovant et open source (sous licence Apache 2.0) pour monter une infrastructure dans le domaine du cloud computing. 1.3 Le Grid 5000 Afin d avoir une vrai infrastructure sur laquelle déployer OpenStack, nous avons eu la chance de pouvoir utiliser le Grid Présentation de Grid 5000 La plate-forme Grid 5000 est une grille informatique, c est-à-dire une infrastructure partagée sur différents sites géographiques. Dans ce cas, Grid 5000 est constitué de neuf sites répartis en France (Grenoble, Lyon, Toulouse, Bordeaux, Lille, Rennes, Reims et Nancy et Sophia) et un au Luxembourg. Le Grid 5000 offre à de nombreux chercheurs la possibilité d effectuer des expérimentations. Notre tuteur, Lucas Nussbaum, nous a fait visiter la salle serveur du Grid de Nancy. Il nous a fait une présentation du matériel, de l architecture et du réseau. Le Grid 5000 (ou G5K) est donc une plateforme nationale répartie sur différents sites. Elle dispose de 1171 nœuds uniquement des nœuds physiques. La totalité des nœuds représentent 2218 processeurs, soit pratiquemment 8000 cœurs. Les sites géographiques sont reliés par une fibre optique 10 Gbits/s. Cette fibre fait partie du réseau RENATER 9 2 État de l art Openstack Petite introduction Le projet est né en juillet 2010 par la société Rackspace associée à la NASA. Il est distribué librement sous licence Apache 2.0. C est une solution de cloud computing IaaS pour du cloud privé 9. Réseau National de télécommunications pour la Technologie l Enseignement et la Recherche. 6

7 ou public. Aujourd hui la fondation attire une communauté large et dynamique regroupant plus de membres actifs, dont contributeurs depuis le début du projet et 850 organisations différentes, dont Canonical et Red Hat Architecture Openstack est constitué d un ensemble de projets liés, qui constituent les différents composants d une plateforme de cloud computing. Son architecture est comparable à celle de Amazon Web Services. Il y a trois éléments capitaux autour du projet : Openstack Compute (provisionner et contrôler un large réseau de machines), Openstack Object Storage (créer une plateforme de stockage hautement disponible) et Openstack Image Service (gérer et organiser un large cataloge d images de machines). Ces différents services communiquent entre eux grâce à la solution de SpringSource, RabbitMQ qui implémente le protocole AMQP, ce dernier permet de faire du clustering 10 pour une meilleure tolérance de panne et une meilleure tenue de charge. L utilisation de cette solution permet une large modularité dans Openstack. En effet il est alors possible d imaginer différentes intégrations au sein de sa propre solution de cloud privé. C est d ailleurs la philosophie de la fondation : permettre une haute configuration selon ses besoins avec différentes options de stockage et réseau. En revanche l utilisation de RabbitMQ oblige la mise en place d un serveur NTP sur l ensemble de ses nœuds afin qu ils soient tous synchronisés sur une date système redondante et ne fonctionnera pas si les messages sont désorganisés au niveau temporel. Il faudra disposer également d une base de donnée SQL, nous avons opté pour MySQL comme le préconise la documentation officielle Les modules Le développement d Openstack est découpé en différents modules (projets). Nova - Gestion du Compute Nova est considéré comme le «cerveau» du projet. Toute l architecture d Openstack repose dessus. Il est, en outre, en charge de la gestion d instances de machines virtuelles. Ce module gère la gestion de droits (Security Groups), les tailles d instances. Nova est en relation directe avec l hyperviseur. Glance - Gestion d image Glance est le module en charge de la gestion des images systèmes virtuelles. Il dispose de sa propre base de données qui lui permet de stocker les informations relatives aux images. Glance offre à l infrastructure la gestion de service de stockage et de distribution des images disques des machines virtuelles (Cirros, Ubuntu,...). L utilisateur pourra alors utiliser les images mises en place par l administrateur. Cinder - Volume de stockage (anciennement nova volume) Cinder, jusqu à Folsom (sixième version) était une brique intégrée à Nova appelée Nova- Volume, mais est devenue un projet à part entière. Cinder est un module qui fournit une infrastructure pour la gestion des volumes. Il agit en quelque sorte comme les disques logiques d un SAN. C est un disque qu il sera possible d attacher à une seule instance, à un instant donné. 10. ferme de calcul 7

8 Neutron - Service réseau (anciennement Quantum) Neutron est le module permettant la mise en place de réseaux virtuels. Anciennement connu sous le nom de «Quantum» avant la version «Havana» de Openstack. Développé par Cisco, il permet la gestion de commutateurs (switch) linux, ainsi que les améliorations détaillées plus bas. Neutron est également en charge de gérer les règles de pare-feu, d attribution des adresses IP pour les instances. Swift - Stockage d objets Swift est le module de stockage d objets chargé de gérer les lots de données. C est un système de stockage clé/valeur de plusieurs pétabits de données. En revanche il ne s agit pas réellement d un système de fichiers ; il est conçut pour le stockage à long terme de gros volumes. Il s interface avec Glance afin d y stocker ses images. Swift dispose de sa propre base de données. Keystone - Service d authentification Keystone est le point d entrée. C est le service d identité et d authentification : les utilisateurs vont devoir s identifier afin d obtenir les autorisations nécessaires. Dans ce cas, Keystone leur fournit un token qui est un jeton autorisant l interaction avec le service désiré. Il repose sur un SGBD. Nous avons choisis MySQL. Il est conçu pour être utilisable avec un annuaire LDAP et ainsi faciliter la gestion de droits. Horizon - La console web (Dashboard) Horizon est la partie graphique d Openstack. C est un tableau de bord disponible par une interface web. Il est possible d administrer les différents modules cités ci-dessus donc de créer, administrer les machines virtuelles, gérer les volumes. Il utilise la base de données de Keystone, mais n utilise par la notion de jeton. Une fois connectés, l utilisateur et l administrateur peuvent agir sur les projets. En revanche, les possibilités offertes par Horizon ne sont pas aussi importantes qu en lignes de commandes. Il reste donc indispensable à l administrateur d utiliser son interpréteur de commandes à des fins d administration. Ce module a finalement été crée pour l utilisateur, afin de lui faciliter l utilisation Version actuelle A ce jour, Openstack est à la huitième version, sortie le 17 octobre 2013, surnommée «Havana». L ancienne version se nommait «Grizzly». Cette nouvelle version intègre désormais nativement le module Ceilometer, qui est une solution de metering 11 et de monitoring 12, ainsi que Heat, qui est un moteur d orchestration basé sur un modèle. Cette version aura eu une grande évolution par rapport à Grizzly, on peut ainsi noter une augmentation de 70% de contributeurs, une entrée en force de différents acteurs, dont IBM (2e) et Yahoo (25e) dans le top contributeur, 392 nouvelles fonctionnalités, correctifs, 55% de gain temps lors du déploiement Web élastique Avec cette nouvelle version, Openstack se tourne de plus en plus vers le monde de l entreprise. Le projet gère désormais l autoscaling, qui est une caractéristique permettant l ajout ou la suppression des ressources en fonction de l utilisation réelle, c est à dire le «web élastique» à la manière de AWS 13. Cette fonction se fait grâce aux nouveaux modules cités précédemment : Openstack 11. mesure 12. supervision 13. Amazon Web Services 8

9 Orchestration (Heat) et Openstack Metering (Ceilometer). Ceilometer : ce module supervise l environnement, afin d y collecter des données d utilisation et s intègre au module de gestion d identité Keystone et fournit des informations précises sur les comportements des utilisateurs. C est de cette façon qu il va pouvoir superviser l environnement du cloud computing et découvrir d éventuelles contraintes de ressources. C est là qu intervient Heat. Heat : c est une plateforme d orchestration assurant un approvisionnement plus facile de nouvelles ressources à la demande. Il déploie automatiquement ses ressources, permet de lancer des applications, créer des machines virtuelles et automatiser l ensemble du processus. On peut également citer d autres améliorations et nouveautés : Amélioration du Dashboard : possibilité d y redimensionner une instance, démarrage à partir d un volume simple Neutron remplace Quantum : supporte à présent les implémentations virtuelles Open vswitch et NSX (VMware), permettant de fonctionner sur des périphériques Cisco. Inclus la possibilité de créer facilement des VPN et des Pare-feux Pour la version suivante, Icehouse, prévue pour avril 2014, devrait introduire nativement, ce qui est pour le moment sur le banc d essai dans la version actuelle : TripleO (Openstack on Openstack), Ironic, Savannah, Trove (base de données relationelle) et Marconi (Messagerie). 3 Cahier des charges 3.1 Présentation du projet Objet du projet Notre projet consiste en la mise en place d une infrastructure web élastique avec OpenStack Objectifs La plate-forme OpenStack devra être fonctionnelle avec les modules nécessaires à l infrastructure web. L infrastructure web devra pouvoir s étendre automatiquement sur des machines supplémentaires en fonction du niveau de charge des serveurs Délai Le projet «Infrastructure web élastique avec OpenStack» sera réalisé sur un délai de 2 mois (soit 8 semaines). 9

10 3.1.4 Composition de l équipe Nom : Pierre BOESCH pierre.boesch5@etu.univ-lorraine.fr Statut : étudiant Nom : Florentin CLOUET florentin.clouet8@etu.univ-lorraine.fr Statut : étudiant Nom : Gwenaël COULOMBET gwenael.coulombet1@etu.univ-lorraine.fr Statut : étudiant Nom : Sébastien PHILIPPOT sebastien.philippot5@etu.univ-lorraine.fr Statut : étudiant Les différents rôles seront partagés par les étudiants (installation, tests, réalisation des scripts). 3.2 Environnement L infrastructure web élastique sera gérée à l aide de HAproxy au sein de la plate-forme de cloud computing OpenStack, elle-même installée sur Grid Réalisations Il incombe à l équipe les réalisations suivantes : la mise en place d un cloud privé OpenStack la vision globale d OpenStack, à la fois en largeur (tous les modules) et en profondeur (rôle des différents modules, install/config, fonctionnement interne) l évaluation de l intérêt des différents modules d OpenStack le déploiement d une infrastructure web élastique l automatisation de l installation à l aide de scripts la mise en place du chiffrement des données côté client 10

11 3.4 Suivi de projet L équipe devra fournir chaque semaine au tuteur de projet (M. Lucas NUSSBAUM), un rapport collectif comprenant : les tâches réalisées, ainsi que les succès/échecs les prévisions pour la semaine suivante les questions et les points bloquants Ainsi qu un rapport individuel comprenant : la participation et le temps passé sur les différentes tâches les difficultés d organisation au sein du groupe 4 Tâches réalisées La première semaine fut dédiée à la mise en place du dépôt GitHub, ainsi qu à l apprentissage de Grid 5000 par les différents tutoriels disponibles sur le wiki. mediawiki/index.php/category:portal:user Les premiers tests sur OpenStack ont été effectués sur des machines virtuelles (Ubuntu et Debian Wheezy). Les essaies ont dû être stoppés à cause de la récursivité de la virtualisation. Nous avons donc pris la décision de nous tourner vers une installation «en dur» sur deux ordinateurs de la salle de cours. 4.1 Installation dans la salle 501 d OpenStack sur Ubuntu Nous avons utilisé deux PC de la salle non utilisés et non ceux disponibles au fond pour deux raisons : leur capacité en mémoire vive : 4 Go et leur capacité de stockage : 250 Go. Au niveau du réseau, chaque ordinateur dispose de deux cartes réseaux. L une dédiée au réseau externe et l autre au réseau interne Avancé dans la largeur : Nous avons installé les services d OpenStack suivants : Sur le «controller» : keystone glance nova Api Cert Consoleauth Sheduler Conductor Novncproxy Dashboard 11

12 Applications externes : Mysql-server Rabbitmq-server Sur le «compute1» : Nova-compute Nova-network application externe : KVM Figure 1 Services installés Compréhension dans la profondeur Nous avons suivi le guide d installation pour Ubuntu havana/install-guide/install/apt/content/. Nous avons commencé par installer l ISO d Ubuntu Server sur le controller puis sur le compute1. Dans un premier temps, nous avons choisi de ne pas utiliser LVM et de tout installer dans une seule partition. Nous avons ensuite configuré les cartes réseaux pour les réseaux externes et internes comme mentionné plus haut et modifié le /etc/hosts des deux pour qu ils puissent se parler sur le réseau interne avec leurs noms d hôtes : Nous avons installé un serveur NTP sur le controller en retirant tous les serveurs externes et en le configurant pour qu il se synchronise sur sa propre horloge et également qu il se coordonne avec compute1. Pour les mots de passe, nous avons suivi les recommandations du guide et généré des mots de passe forts à 10 caractères avec Openssl 14. Nous avons installé une base de données MySQL avec la librairie pour Python 15. Nous avons augmenté le niveau de sécurité initial de la base grâce à la secure-install. Nous avons mis en place 14. librairie de chiffrement 15. Langage de programmation objet 12

13 le dépôt havana pour Ubuntu et installé rabbitmq-server 16. C est ce qui va permettre au compute1 de communiquer avec le controller. Ensuite, nous avons installé Keystone, qui est chargé de la gestion des identités des utilisateurs et des services. Pour cela, il manipule les objets suivants : User : représente un utilisateur, un système ou un service qui utilise les services d OpenStack. Credentials : contient les données permettant d authentifier un user comme son nom ou son mot de passe. Authentication : ce service est là pour confirmer l accès à des requêtes. Il a un rôle de vérification des Credentials. Token : c est un jeton provisoire permettant d accéder à une ou plusieurs ressources. Tenant : c est un conteneur dans lequel on regroupe ou isole des objets. Il est parfois comparé à un projet qui regroupe ses instances et ses utilisateurs. Service : ce sont les services ou modules d OpenStack tel que Nova, Glance, Role : définit le rôle de l utilisateur pour un Tenant. Un utilisateur peut avoir un ou plusieurs rôles sur différents Tenants. Comme pour chacun des services, Keystone a besoin d avoir une base de données propre. Ces opérations sont réalisées directement avec MySQL : création d une base de données Keystone avec tous les privilèges sur «localhost». Ensuite, on synchronise la base avec le service. Après ça, Keystone a besoin d un premier «token» généré par Openssl et entré dans le fichier de configuration de Keystone on doit définir pour ce service des utilisateurs admininisateurs, des Tenants et des rôles. Keystone a un utilisateur qui s appelle «Admin» avec un mot de passe et une adresse électronique. Deux tenants : «Admin tenant» et «Service tenant» un rôle : «admin» avec l utilisateur administrateur et le «tenant admin». Keystone définit aussi des «endpoint» qui sont le lien entre un service et une API. La vérification du bon fonctionnement de Keystone se fait par la demande d un token pour le tenant Keystone. On peut ensuite lister l utilisateur Keystone. Vient ensuite l installation du service Glance qui gère les images que l on utilise pour les machines virtuelles. Le répertoire par défaut de stockage est /var/lib/glance/images/ Glance ou «image Service» inclut deux composants : Glance-api : fait le lien avec les autres api pour gérer les images. Glance-registry : stocke les informations concernant les images, comme leur taille ou leur type. Toutes ces informations sont stockées dans la base de données. Glance dispose de deux fichiers de configurations : glance-api.conf glance-registry.conf Comme pour Keystone, Glance doit disposer d une base de donnée, d un utilisateur, d un «tenant» et d un rôle. l uri d authentification de Glance est sur le port Voir présentation Openstack 13

14 La vérification du bon fonctionnement de Glance se fait par le téléchargement d une image de test cirros.img et l insertion de cette image dans la base de Glance. Glance supporte les formats d images suivants : qcow2 : format de disque de type qemu raw : format disque brut vhd : format de disque générique couramment utilisé vmdk : format de disque reconnu par de nombreux hyperviseurs vdi : format de disque de type virtualbox iso : format de disque de type iso aki : format de disque de type Kernel Amazon ari : format de disque de type Ram Amazon ami : format de disque de type Machine Amazon Après l insertion de l image par la commande glance image-create, on vérifie le bon fonctionnement de la commande par glance image-list. Le service suivant est le «cœur» du système, il gère les instances de machines virtuelles, l espace disque et le réseau. C est Nova ou le «compute service». Il interagit avec tous les autres services. Il se décompose en plusieurs fonctionnalités : API : nova-api service : interfaçage entre les demandes de l utilisateur final et les API. nova-api-metadata service : utilisé en cas d hôtes multiples notamment avec nova-network. Compute core : nova-compute process : démon qui crée ou détruit les VMs, il communique avec l hyperviseur. nova-scheduler process : prend en compte les besoins des VMs en charge et détermine sur quel hôte il doit être exécuté. nova-conductor module : gère la relation entre compute et MySQL Networking for VMs : nova-network worker daemon : gère les demandes en file d attente du réseau nova-dhcpbridge script : gère les adresses du DHCP sur le bridge Console interface : nova-consoleauth daemon : autorise les jetons entre les utilisateurs et les mandataires. nova-novncproxy daemon : fournit un accès proxy pour VNC et les novnc sur navigateur. nova-console daemon : uniquement sur Havana nova-xvpnvncproxy daemon : client Java pour accéder aux instances par les mandataires. nova-cert daemon : gère les certificats X509. Image management : nova-objectstore daemon : principalement utilisé pour les installations qui doivent utiliser euca2ools. euca2ools client : client en ligne de commandes pour la prise en charge de euca2ools (optionnel). Command-line clients and other interfaces : nova client : permet aux utilisateurs de soumettre des commandes en tant qu administrateur ou utilisateur final. nova-manage client : uniquement pour les administrateurs. Gestion des clients. autres composants : 14

15 The queue ou file d attente : Gestion des messages entre démons par RabbitMQ en AMPQ. SQL database : pour nous MySQL (recommandé) Compute interagit aussi avec d autres services comme Keystone, Glance ou Dashboard. Ensuite, sur le Compute1, nous avons installé et configuré le client python-guestfs, novacompute-kvm, nova-network et nova-api-metadata. Les deux fichiers de configuration à compléter sont nova.conf et api-paste.ini Une fois ces services fonctionnels sur le compute1 (une vérification peut être effectuée par les journaux de nova-network), Nous avons créé le pont br100 sur l IP interne du compute1. Cette action se lance avec un nova-network-create sur le Controller validant ainsi la communication entre le controller et son node. Ce qui nous a permis de continuer sur le controller avec l installation du Dashboard. Le Dashboard utilise les paquets : memcached libapache2-mod-wsgi openstack-dashboard. Le mod_wsgi d Apache lui permet de communiquer avec python. Nous avons ensuite enlevé le thème Ubuntu du Dashboard car celui-ci empêche des traductions et crée quelques problèmes avec la cartographie réseau. Le fichier de configuration du Dashboard est local_settings.py se trouve sous /etc/openstackdashboard/. Il contient les clients (sous forme de nom d hôte ou d IPs) qui ont le droit de s y connecter. L accès se fait dans un navigateur web à l adresse http ://controller/horizon Nous avons pour l instant rencontré deux points bloquants : un sur Glance et un sur le Dashboard qui ont pu être résolus grâce à l étude des fichiers journaux. Figure 2 L accès au Dashboard de la salle

16 4.2 Installation sur Grid 5000 Dès la première semaine, nous avons étudié la manière de réserver, puis d installer une machine dans le Grid 5000 grâce au tutoriel «Getting Started». index.php/getting_started Une équipe fut dédiée à l étude du déploiement d OpenStack dans le Grid 5000, du fonctionnement de Kavlan, ainsi que des recettes puppet. Un problème de déploiement du master node (openstackg5k) a bloqué notre premier essai. Ce dernier était déjà reporté sur GitHub à l adresse issues/21 et a fait l objet d un rapport de bogues par notre tuteur. 5 Planning prévisionnel pour le reste du projet Dès la semaine prochaine, nous prévoyons trois axes : Continuer à installer les services suivants : Cinder, Swift, Neutron, Heat et Ceilometer. Création d un script bash d installation pour le Grid 5000 Test d un Devstack simple et multi-nodes sur Grid 5000 L étape suivante sera l étude des services permettant d effectuer du «web élastique» et de mettre en place un scénario de test avec un site internet. Les détails du scénario de fin de projet seront à discuter avec notre tuteur. 16