Infrastructure web élastique avec OpenStack

Infrastructure web élastique avec OpenStack Auteurs : Pierre Boesch, Florentin Clouet, Gwenaël Coulombet, Sébastien Philippot Tuteur : M. Lucas Nussbaum Lundi 24 Mars 2014 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. 1

Table des matières 1 Remerciements 4 2 Introduction et problématique 5 2.1 Le Cloud computing.................................. 5 2.1.1 OpenStack et le cloud............................. 6 2.2 Grid 5000........................................ 6 2.2.1 Le Grid 5000.................................. 6 2.2.2 Présentation de Grid 5000........................... 6 2.3 Gestion de projet.................................... 7 3 OpenStack pour une infrastructure web élastique 8 3.1 Tour d horizon..................................... 8 3.1.1 Introduction.................................. 8 3.1.2 Architecture.................................. 8 3.1.3 Version actuelle................................. 9 3.1.4 Web élastique.................................. 9 3.2 Les modules : services d OpenStack.......................... 10 3.2.1 Keystone, le service d identité......................... 10 3.2.2 Glance, la gestion d images.......................... 12 3.2.3 Nova, le Compute............................... 12 3.2.4 Horizon, l interface web............................ 15 3.2.5 Cinder, le service de disques persistants................... 16 3.2.6 Neutron, la gestion de réseaux........................ 17 3.2.7 Swift, le stockage d objet........................... 19 3.2.8 Heat, le service d orchestration........................ 20 3.2.9 Ceilometer, le service de métrologie...................... 21 4 Déploiement d une infrastructure web élastique 22 4.1 Pré-requis........................................ 22

4.2 Création d une infrastructure de test......................... 22 4.2.1 L installation d OpenStack, un long fleuve tranquille?........... 22 4.2.1.1 La familiarisation avec Grid5000.................. 23 4.2.1.2 Les contraintes matérielles..................... 23 4.2.1.3 Choix d une distribution...................... 23 4.2.1.4 Une architecture simple?...................... 24 4.2.1.5 Réseau as a service......................... 26 4.2.2 Choix du mode d installation :........................ 26 4.2.2.1 Installation manuelle........................ 26 4.2.2.2 DevStack............................... 26 4.2.2.3 Puppet................................ 26 4.2.2.4 La méthode Ubuntu : MAAS et Juju............... 27 4.2.2.5 RDO : OpenStack à la sauce Red Hat............... 27 4.2.2.6 Utilisation de scripts......................... 27 4.3 Choix final : Fuel.................................... 28 4.3.1 Grid or not Grid.................................. 29 4.3.2 Matériel..................................... 29 4.3.3 Réseaux..................................... 29 4.3.4 Tests....................................... 30 5 Conclusion - Perspectives 32 6 Annexes 33 6.1 Les commandes OpenStack.............................. 33 6.2 Les scripts python pour le déploiement des nœuds................. 34 6.2.1 Le controller.................................. 34 6.2.2 Le compute................................... 44 6.2.3 Le network................................... 50 6.3 Modèle Heat...................................... 54 6.4 Bibliographie & Webographie............................. 59

1 Remerciements Nous remercions Lucas Nussbaum, notre tuteur, pour sa disponibilité, son suivi et pour son aide. Nous souhaitons aussi remercier l ensemble de l équipe du Grid5000, qui nous a permis de travailler sur cette plate-forme. Nous souhaitons également remercier Sébastien Badia ainsi que Stefania Costache, pour leur gentillesse et leur aide précieuse. page 4

2 Introduction et problématique 2.1 Le Cloud computing Depuis quelques années, les médias et publicitaires usent (et abusent) du mot cloud. Il s agit d un buzzword 1 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 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ûteux, puisqu il 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 data-centres. 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 d 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 2, STaaS 3 : 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 1. Un buzzword est un terme qui est utilisé comme slogan pour désigner une nouveauté et pour attirer l attention sur cette nouveauté. (Source :Wikipédia) 2. Data as a Service 3. Storage as a Service page 5

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 4, 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 fournisseurs de SaaS les plus connus. 2.1.1 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. 2.2 2.2.1 Grid 5000 Le Grid 5000 Afin d avoir une vrai infrastructure sur laquelle déployer OpenStack, nous avons eu la chance de pouvoir utiliser le Grid 5000. 2.2.2 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 dix sites répartis en France (Grenoble, Lyon, Toulouse, Bordeaux, Lille, Rennes, Reims, Nantes 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. 4. Linux, Apache, MYSQL, PHP page 6

Le Grid 5000 (ou G5K) est donc une plate-forme 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 pratiquement 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 5 Afin d accéder à l infrastructure Figure 1 Architecture Réseau de Grid (Crédit :grid5000.fr) G5K, il faut passer par un des deux accès principaux : access-north et access-south. Une fois la connexion SSH établie, il est possible d accéder aux différents serveurs frontaux. La connexion se fait obligatoirement via une authentification par clé. À partir de chaque site, il est possible d y effectuer des réservations. Les différents sites proposent plusieurs clusters de machines homogènes. La réservation des nœuds se fait via OAR, les commandes utiles sont : oarsub : Il permet d effectuer une réservation pour plusieurs nœuds en lui spécifiant de nombreux paramètres. (durée, type, etc.). oarstat : Il permet d obtenir des informations et un statut sur nos réservations. kavlan : Il nous a permis d isoler nos machines des autres nœuds du réseau par le biais de VLAN 6, nous permettant ainsi d utiliser un DHCP du Grid afin d y obtenir des adresses IP. $OAR_NODFILE : Variable nous permettant de connaître le nom d hôte de nos machines réservées. kadeploy3 : Nous a permis de déployer des images d Ubuntu, et de Debian offerte par Grid. 2.3 Gestion de projet Cette année, l IUT nous a mis à disposition des projets privés sous GitHub 7. Ainsi, nous avons utilisé tout au long de notre projet GitHub. Comme préconisé, nous avons crée une architecture à cinq dossiers que vous pouvez voir ci-dessous : 5. Réseau National de télécommunications pour la Technologie l Enseignement et la Recherche. 6. Réseau local virtuel 7. Service web d hébergement et de gestion de code source page 7

Figure 2 Arborescence du Git Dans le dossier Docs, nous avons partagé les différentes documentations utilisées. Dans le dossier GestionDeProjet, nous avons l ensemble des compte-rendus de réunion, ainsi que les compte-rendus hebdomadaires. Chaque semaine, nous avons également envoyé un compte-rendu individuel à notre tuteur afin de faire un point à la fois sur notre avancement personnel et sur celui du groupe. Le dossier Notes est là où nous avons rédigé quelques aide-mémoires et commandes utiles. Le dossier Projet contient nos scripts de déploiement en Python. Et le dossier Rapports contient notre rapport ainsi que nos slides en L A TEX. Nous nous sommes dans un premier attardé sur la documentation OpenStack et Grid5000. Cela nous a permis de comprendre le projet, ce qu il allait falloir faire, et s imaginer le temps nécessaire à la bonne réussite du projet. Dans un premier temps, nous avons découvert ensemble l environnement Grid5000 afin d en connaître l infrastructure et les commandes associées. Suite à cela, le groupe s est divisé en deux parties : une partie travaillant sur le déploiement d OpenStack dans Grid5000 et une autre sur une installation locale sur des postes de la salle. Plus tard, nous nous sommes rendus compte que le déploiement via Puppet dans le Grid5000 était dans une version antérieur sur laquelle nous devions travailler. Nous avons alors décidé de poursuivre sur l installation locale le reste du projet. 3 OpenStack pour une infrastructure web élastique 3.1 Tour d horizon 3.1.1 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é ou public. Aujourd hui la fondation attire une communauté large et dynamique regroupant plus de 9 500 membres actifs, dont 2 000 contributeurs depuis le début du projet et 850 organisations différentes, dont Canonical et Red Hat. 3.1.2 Architecture OpenStack est constitué d un ensemble de projets liés, qui constituent les différents composants d une plate-forme de cloud computing. Son architecture est comparable à celle d Amazon Web Services. Il y a trois éléments capitaux autour du projet : OpenStack Compute (provisionpage 8

ner et contrôler un large réseau de machines), OpenStack Object Storage (créer une plate-forme de stockage hautement disponible) et OpenStack Image Service (gérer et organiser un large catalogue 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 8 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ées SQL, nous avons opté pour MySQL comme le préconise la documentation officielle. Les développeurs du projet OpenStack utilisent des méthodes très innovantes afin de limiter l ajout de bug dans le code source. En premier lieu, le code est géré par un gestionnaire de version qui est désormais très répandu : GIT. Un principe que l on retrouve dans malheureusement trop peu de projet est un système d intégration continue : Jenkins. C est un logiciel libre permettant de faire une batterie de tests automatisés, avant l intégration dans le code source. Dans la même lignée, Gerrit 9 permet d analyser le code pour éviter d introduire des bugs dans le code source d OpenStack 3.1.3 Version actuelle À 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 10 et de monitoring 11, 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, 20 000 correctifs, 55% de gain temps lors du déploiement. 3.1.4 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 12. Cette fonction se fait grâce aux nouveaux modules cités précédemment : OpenStack Orchestration (Heat) et OpenStack Metering (Ceilometer). 8. ferme de calcul 9. Application Web permettant la revue de code 10. Mesure 11. Supervision 12. Amazon Web Services page 9

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 puis 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 plate-forme 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-feu Les API peuvent désormais communiquer via SSL/TLS 13 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 relationnelle) et Marconi (Messagerie). 3.2 Les modules : services d OpenStack Le développement d OpenStack est découpé en différents modules (projets). Les modules peuvent être indépendants, cependant ils sont souvent complémentaires et dépendants. Les modules d OpenStack sont souvent des technologies, architectures, langages et logiciels déjà approuvés dans le milieu. Les modules sont des agrégats de multiples technologies communicant ensemble par le biais d interface de programmation 14 et du protocole HTTP. Durant le projet, nous les avons installés et essayés, ils sont par ailleurs tous indispensables pour arriver au terme du projet, le web élastique. 3.2.1 Keystone, le service d identité Le module Keystone est en quelque sorte le point d entrée du projet. Ce service est chargé de l authentification et de la gestion d identité. C est le nom de code pour «OpenStack Identity Service». Grâce à lui les utilisateurs sont autorisés à obtenir un «jeton» (token) pour accéder au service de cloud d OpenStack. Pour être plus clair, c est lui qui va donner les droits d accès aux clients d accéder à l interface web d OpenStack selon leurs droits : administrateurs, clients, etc.... 13. Transport Layer Security - Protrocole de sécurisation des échanges 14. API page 10

L API de Keystone est prévue pour être le point central des autres API. Elle est basée sur une architecture «RESTful 15» basée sur des URIs et les méthodes HTTP GET et POST. Tous les modules d OpenStack doivent connaître, directement ou indirectement, l adresse du service d identité. La méthode POST est utilisée pour l authentification et la génération de tokens. Une fois la demande d identification lancée (nom et mot de passe) l API valide ou non la requête établie par des codes réponses. L architecture de l API est mise en place selon 8 concepts : User : représentation de la personne, système ou service ; Credentials : les données appartenant à un unique utilisateur et pouvant prouver son identité, par exemple correspondance entre un nom d utilisateur et une clé API ; Authentification : permet de confirmer une authentification selon les différentes de connexion puis un jeton est fourni que l utilisateur détient durant le temps de sa navigation et lui permet de confirmer son authenticité auprès des autres services ; Token : donnée associée à une authentification utilisée pour accéder à des ressources accessibles avec elle. Un jeton peut être révoqué à tout moment et est valable pour une durée limitée ; Tenant : il s agit d un conteneur regroupant les différentes ressources telles que les machines virtuelles, il s agit des différents projets mis en place pour l administrateur ; Services : définit les services d OpenStack tel que Nova, Swift, Glance et de Keystone luimême. Les services fournissent un ou plusieurs «endpoint» grâce auquel les utilisateurs peuvent accéder aux ressources et effectuer des opérations ; Endpoint : répertorient les adresses des points d accès aux API des services définis précédemment ; Rôles : un rôle comprend un ensemble de droits et de privilèges associés à un utilisateur sur les tenants. D après la présentation, il est alors évident de comprendre que Keystone est le premier module à installer pour faire fonctionner OpenStack. Après avoir installé et configuré un serveur SQL, dans notre cas MySQL est préconisé par la documentation officielle, il faut installer Keystone et le configurer. La configuration correspond à la création d une base de données sous MySQL que l on a nommé «Keystone» avec lequel un utilisateur «admin» a les droits d accès puis faire correspondre dans le fichier de configuration la connexion à cette base pour la synchroniser avec le service. En premier nous avons créé deux tenants : un pour les tâches administratives «admin» et un autre pour les services OpenStack «service». Puis nous avons par la suite créé un utilisateur «admin» disposant d un couple login/mot de passe et un rôle «admin». Enfin il faut associer l utilisateur et le tenant au rôle. Les services sont essentiels car ils doivent savoir où sont les autres modules d OpenStack sur le réseau. Dans un premier temps il faut créer un service Keystone pour obtenir un jeton d authentification afin de pouvoir lancer dans l avenir des commandes Keystone puis lui associer un point d accès (Endpoint) pour spécifier l API. Pour finir, nous avons créé un fichier d environnement afin de communiquer avec Keystone rapidement en chargeant le fichier. Puis, nous nous sommes familiarisés avec les commandes du module avant de poursuivre sur le service d image, Glance. 15. REpresentational State Transfer page 11

3.2.2 Glance, la gestion d images Glance est le module dédié à la gestion des images systèmes virtuelles. Il est en charge de leurs localisations, enregistrements et leurs récupérations. Il dispose de sa propre base de données qui lui permet d y stocker les méta-données des images, il n est donc pas en charge du stockage réel des machines. Il fournit aussi des technologies de stockages multiples comme des systèmes de fichiers simples pour les systèmes de stockages d objets comme le module Swift. Il gère également les snapshots 16. Glance offre la possibilité de stocker les images en local ou sur un serveur web externe. L API de Glance fournit des méthodes pour stocker et récupérer des images. Tout comme Keystone, il repose sur une API RESTful. Elle permet de gérer complètement les images : lister, accéder aux informations, partager ou rendre privé, ajouter, modifier, effacer, etc. Elle repose sur deux services distincts : Glance-API : reçoit les requêtes émises par l utilisateur, s interface avec Glance-Registry et transmet l information demandée ; Glance-Registry : le registre stocke les méta-données, comme la taille et le type des images et effectue les recherches qui seront synchronisés avec la base de données SQL. Pour simplifier l installation, nous avons installé le module sur le nœud «Controller» et non sur un nœud à part. Nous avons commencé par créer une base de données «Glance» et un utilisateur associé. Une fois le paquet installé, il faut configurer les deux services glance-api et glance-registry afin de permettre une communication avec la base données SQL, et synchroniser l accès à la base par la suite. Pour que Glance puisse être authentifié et obtenir un jeton il faut créer un utilisateur disposant du tenant «service» et du rôle «admin» crée précédemment avec Keystone. Il reste à préciser dans la configuration comment accéder au module Keystone. Le module étant correctement configuré, nous avons testé son fonctionnement à l aide d une image «cirros 17» au format QCOW2 18 puis nous avons vérifié qu elle était bien en place et que l on accédait à ses informations. Suite à quoi nous avons retenté l expérience avec une image Ubuntu afin de confirmer le fonctionnement et se familiariser avec les commandes. Pour déployer les images et en avoir l accès (Instance), c est le module Nova-Compute qui en a la charge. 3.2.3 Nova, le Compute Nova est le cœur du projet OpenStack, c est sur lui que repose l infrastructure matérielle de toute la plate-forme. Nova s occupe de la gestion des machines virtuelles et gère de multiples hyperviseurs 19. Il est comparable à l EC2 (Elastic Compute Cloud) de chez Amazon. Nova permet donc de créer et gérer de multiples instances mais aussi d y accéder et de gérer complètement indépendamment les machines. De plus, Nova permet de définir des tailles d instances (m1.tiny, m1.small, m1.large, etc.), cela permet d allouer des machines suivant les ressources demandées. Nova regroupe donc de multiples services que l on peut dissocier comme suit : L API : de Nova est très complète, elle permet aux utilisateurs finaux de piloter l ensemble des composants de Nova. Le nova-api service est capable de dialoguer avec sa 16. Enregistrement à un instant t d une machine virtuelle 17. Distribution Linux très minimaliste dédiée à des fins de test pour le cloud 18. Format d image compressé? 19. Plate-forme de virtualisation page 12

propre API, avec l API d Amazon et qui permet aux administrateurs d effectuer des tâches de maintenance. La nova-api offre aux utilisateurs ou consommateurs finaux la possibilité de recevoir, traiter et donner un retour aux commandes de l utilisateur. Compute Core : Il est composé de trois sous modules. Le premier est nova-compute process, c est un démon qui gère les instances à partir de l API. Nova-compute process gère la partie système et dialogue avec les différents hyperviseurs (Xen, KVM/Qemu, VMWare etc.). Le deuxième est nova-scheduler process, dans une utilisation multi-nodes, ce dernier sert a déterminer sur quels nodes installer l instance. Le scheduler sait déterminer sur quels nœuds la charge est moins importante et créer les instances sur ce dernier. C est un fonctionnement intelligent car ce démon permet de répartir la charge dès la création des instances. Le dernier est nova-conductor module, son rôle est de communiquer avec la base de données. Le réseau : Si l on ne souhaite pas utiliser Neutron, ou que l on souhaite déployer une infrastructure plus simple et minimaliste. Nova permet d inter-connecter les instances. Pour cela nova-network est un démon qui permet d inter-connecter et de gérer le réseau des instances. Il repose essentiellement sur l utilisation de iptables. Des bridges sont gérés grâce à nova-dhcpbridge. Afin de configurer le réseau sur nos instances avec nova-network, l on peut allouer des adresses fixes que l on rattache à un bridge. Cette méthode est peu utile, hormis pour des tests puisque l intérêt est d automatiser au maximum la gestion de l infrastructure. Pour ce faire il est possible d utiliser du FlatDHCP. Nova-network fournira alors un service DHCP 20, par l intermédiaire de Dnsmasq 21 les instances recevront une configuration réseau. Nova-network se charge également du routage, des traductions d adresses ainsi que de la sécurisation (Pare-feu). Les informations sont stockées dans une base de données propre à Nova. L accès aux instances : Il est géré par de multiples démons. Nova-consoleauth, c est lui qui se charge des autorisations pour l utilisateur. nova-novncproxy et nova-xvpnvncproxy permettent de créer un proxy pour accéder aux instances via VNC 22. Enfin nova-cert se charge de la gestion des certificats x509 23. Administrateurs : Pour faciliter les tâches d administration, on dispose de deux modules. nova client qui permet aux utilisateurs de faire de la ligne de commande. nova-manage est un outil destiné aux administrateurs de l infrastructure OpenStack qui peuvent ainsi administrer toutes les instances en ligne de commande. La file d attente : Nova étant le cœur d OpenStack, il dispose d un grand nombre de démons devant interagir entre eux. Pour cela, une AMQP 24 a été implémentée. Par défaut, c est RabbitMQ qui est utilisé mais des alternatives restent utilisable (Apache Qpid, ZeroMQ). La base de données : Là où Nova stocke les différents états des composants, des instances, des réseaux et d autres informations. Le système de gestion de base de données par défaut est MySQL, il est cependant possible d utiliser PostgreSQL. 20. Dynamic Host Configuration Protocol 21. Serveur très léger pouvant fournir de multiples protocoles réseaux 22. Informatique virtuelle en réseau 23. Norme de cryptographie 24. Protocole permettant de standardiser et centraliser les dialogues entre logiciels. page 13

En plus de ces communications «internes», Nova communique avec les autres modules OpenStack (Keystone, Horizon, etc.). Figure 3 Architecture de Nova (Crédit : RackSpace) Afin de déployer Nova pour l installation en locale, nous avons utilisé les paquets officiels (nova-api, nova-cert, nova-scheduler, etc.). Il faut ensuite configurer le fichier nova.conf afin qu il puisse communiquer avec le controller ainsi que sa base de données. Puis, il faut configurer le nœud Compute pour qu il utilise le système de file d attente, nous avons utilisé RabbitMQ. Par défaut, Ubuntu utilise une base SQLite sur Nova, nous avons utilisé MySQL comme SGBD. Il faut ensuite configurer le serveur vnc, ce qui permettra aux clients et utilisateurs d accéder à leurs instances. Afin de communiquer entre les différents modules, Nova a besoin de s authentifier avec Keystone. Il faut donc lier le Controller et le Compute. Pour cela, on utilise l API de Nova et on lui indique les informations de connexion afin de communiquer avec Keystone. Pour configurer nova-network, il faut éditer le fichier de configuration et y renseigner la configuration souhaitée (CIDR, DHCP, FLAT, etc.). Nova permet également de créer dynamiquement des réseaux qui seront bridgés. Une fois les communications établies entre les différents modules internes et les autres modules OpenStack, la création d instance est proche! Il faut alors configurer une paire de clé SSH via ssh-keygen puis via les outils Nova (nova keypair/flavor/image-list) l on vérifie et attribue un identifiant à notre image. Dans le but, d utiliser SSH ou ICMP, il faut créer des règles (Security Group). Ensuite il est possible de lancer une instance. C est là que nous nous sommes rendus compte que la configuration a dû être fausse à un moment ou un autre : ils nous étaient impossible d établir une connexion SSH avec l instance et pour cause le pont créé ne faisait pas la liaison. Grâce aux logs de Nova, nous avons pu découvrir pourquoi : la connexion SQL, donc l échange page 14

d identité avec Keystone, ne se faisait pas. En reprenant un à un la configuration nous avons vu que c était dû au mot de passe de Nova inscrit dans le fichier de configuration pour la connexion SQL qui n était pas bon. Suite au changement, les opérations se sont bien passées. 3.2.4 Horizon, l interface web Afin de rendre l utilisation d OpenStack plus conviviale, la communauté a développé une interface web permettant de gérer facilement la création d instance, de volume, d image, etc. Horizon est un tableau de bord permettant la gestion du cloud OpenStack via une interface web. Ce dashboard est développé en Python, basé sur le framework Django, et il utilise le module WSGI d Apache. On s y connecte avec le même couple login/mot de passe que pour Keystone, à l exception que l on ne précise pas de tenant/project à la connexion : on sélectionne le tenant/project sur lequel on souhaite travailler à partir d une liste déroulante. L administrateur dispose, lui, d un onglet supplémentaire lui permettant de paramétrer un certain nombre d éléments (comme les flavors, les images par défaut...) ou bien d avoir une visibilité sur les utilisateurs de son Cloud, sur les quotas des modules ou bien encore sur d autres informations système. Il est possible de personnaliser l apparence du dashboard avec ses propres couleurs, logo et le titre du site par le biais d un fichier CSS. Figure 4 Interface d Horizon Après avoir installé les paquets officiels, il a fallu configurer le fichier de configuration afin de lui spécifier le nom de l hôte pour OpenStack Identity Service. Horizon utilise les sessions du framework Django pour la gestion des données de session de page 15

l utilisateur. Cependant, deux types de caches peuvent être utilisés, soit le stockage dans la mémoire local, soit avec Memcached. Nous avons fait le choix d utiliser Memcached, car bien que plus complexe à installer, il s avère bien plus performant et propose en plus de la persistance après la fin d un processus et du stockage partagé entre ceux-ci. Cependant l utilisation de Memcached nous a causé un problème majeur lors de la première installation. Selon le refraichissement, donc aléatoirement, la panneau de connexion s affichait ou non. Les logs n étant pas très bavard, il nous a fallu activer le mode "debug" disponible de le fichier de configuration du dashboard pour obtenir un meilleur résultat sur la page internet. C est à ce moment-là que la page nous a affiché divers problèmes ce qui nous permis de recourir aux logs Apache 25 nous donnant une erreur avec python-lesscpy. Nous avons installé ce paquet pour résoudre le problème. 3.2.5 Cinder, le service de disques persistants Cinder est un service qui permet la création de volumes physiques qu il est ensuite possible de rattacher à une instance. Ils permettent le clonage direct de volumes. Ce service est similaire à ceux qu offre Amazon EC2 Elastic Block Storage (EBS). Cinder est composé de plusieurs services : Cinder-API : point d entrée pour Cinder. Il permet de créer et manipuler les volumes et en faire des snapshots. Il transmet les actions au service Cinder-Volume. Cinder-Volume : écrit dans la base de données de Cinder afin de la maintenir à jour. Il interagit avec le software et le hardware et avec le service Cinder-Scheduler. Cinder-Scheduler : choisit le nœud de stockage pour créer le volume. Cinder-backup : fournit un moyen de sauvegarder un volume de stockage de bloc à OpenStack Object Storage (Swift). Le service OpenStack Block Storage met en oeuvre une solution iscsi qui utilise le gestionnaire de volumes logiques LVM. Il est important de noter que ce service n est pas une solution de stockage partagé comme un SAN ou un volume NFS, où un même volume peut être joint à plusieurs serveurs. Ici, Cinder permet de joindre un volume à une seule instance à la fois. Il est possible de sauvegarder les disques du Block Storage Service en réalisant un instantané avec LVM. Lors de la sauvegarde, LVM réduit la taille de la sauvegarde en ne sauvegardant que l espace de stockage réellement occupé au lieu de l ensemble du volume. Pour sauvegarder un volume, il est nécessaire de créer un instantané de celui-ci. Avant tout, il faut s assurer que le système d exploitation n utilise pas le volume et que toutes les données ont été vidées sur le système de fichier du client. En effet, afin d éviter la corruption des données, le volume est «congelé» pour empêcher la modification des données lors du processus. Les systèmes de fichiers doivent être démonté lors de la création de l instantané et pourront être montés à nouveau dès que l instantané du volume aura été créé. Havana introduit la possibilité de migrer des volumes entre les back-ends. La migration d un volume déplace de façon transparente les données du back-end en cours à un autre. Il s agit d une fonction d administration et peut être utilisé pour faire de l évacuation de stockage (pour la maintenance ou la mise hors service), ou de l optimisation manuelle (par exemple, les performances, la fiabilité ou le coût). 25. serveur HTTP page 16

Lorsque nous sommes arrivés sur cette partie du module, un problème majeur s est présenté à nous : la documentation ne précisait pas qu il fallait disposer d une seconde partition sur un noeud (ou d un deuxième disque dur) ou un troisième noeud. Nous disposions seulement de deux ordinateurs sur lesquels l installation avait été faite sur la totalité d une partition. Cinder demande donc l utilisation d une partition à part afin de faire fonctionner ses volumes LVM. Heureusement nous avions à disposions un clone système de nos noeuds. Nous avons alors procéder au redimensionnement des partitions et à la remise du clone sur une partition unique. Seulement à partir de ce moment, toute l installation d OpenStack et en particulier la partie réseau ne marchait plus et il a été impossible de le remettre en place. C est à partir de ce moment que nous avons mis de côté l installation manuelle et que nous sommes partis sur une installation directement dans Grid5000 et avec KVM 26. 3.2.6 Neutron, la gestion de réseaux Neutron est le module réseau sur OpenStack «networking as a service». Il remplace Quantum qui remplaçait déjà nova-network, il est donc un projet à part entière sur lequel énormément de contributeurs y participent. Contrairement à ce dernier il permet une plus grande liberté, à comprendre de plus grandes possibilités, d administration de réseaux virtuels. En effet, il offre la possibilité de créer des réseaux, des routeurs tout en gardant la possibilité de donner la communication avec le réseau externe ainsi les machines virtuelles peuvent communiquer avec le reste du réseau comme une entité à part entière. De plus il est couplé avec le logiciel Open vswitch permettant de simuler un switch 27 sur l hôte. Il est facile d imaginer une topologie réseau avancé. Neutron fournit une API qui permet de délivrer des réseaux et des adresses IP aux machines virtuelles du Cluster à la demande de l utilisateur. Son framework, programmé en Python comme la presque totalité des modules OpenStack, offre deux plugins de création et gestion de réseaux poussés : Les plugins L2 et L3. Ils permettent donc en plus de pouvoir mettre en place un tunnel pour éviter les limites des VLANs, de fournir un QoS end-to-end 28. Avec Horizon, ces plugins sont dédiés à la création et suppression de sous-réseaux. Services réseaux. Là aussi Neutron prévoit plusieurs solutions : LB-aaS, VPN-aaS, pare-feu, IDS 29 etc. Il est clair que nous n avons malheureusement pas eu le temps de les explorer faute de temps. Le module réseau offre le choix entre plusieurs solutions techniques grâce aux différents plugins implémentés par exemple : Flat, Flat/DHCP, Local, VLAN, GRE 30, VxLan pour les connexions entre machines virtuelles IP statiques, DHCP, IP flottantes pour les connexions sur un réseau public. Il est également important de citer que son API gère trois principaux types d entités : 26. Kernel-based Virtual Machine - hyperviseur libre 27. commutateur 28. QoS=QDS=Qualité de Service : capacité à véhiculer un trafic de données dans les meilleures conditions 29. Système de détection d intrusion 30. VPN virtuel page 17

Réseaux : c est un réseau isolé virtuel qui est réservé, donc accessible seulement, par le Tenant qui l a créé. Bien sûr un projet peut disposer de plusieurs réseaux. Cette entité est la principale caractéristique de Neutron. Sous-réseaux : représente un bloc d adresses IP assignés aux machines virtuelles reliés au réseau choisie. Port : représente un port commutateur virtuel ou logique. Les instances relient leurs interfaces réseaux aux ports. Figure 5 Réseau avec Neutron(Crédit : doc OpenStack) Nous avons installé Neutron sur Grid5000 et sur machine virtuelle à l aide de scripts reprenant point à point la documentation officielle. Neutron a été le module le plus complexe du projet à prendre en main. Comprendre son fonctionnement n a pas été chose aisé. Il est relativement jeune dans le projet OpenStack, la documentation n explique pas avec précision son fonctionnement sur le réseau. En revanche l utilisation pour l édition de réseau est rapide à prendre en main : les commandes sont relativement explicites, par exemple pour créer un réseau et un sous-réseau il faudra lancer : neutron net-create nomdureseau neutron subnet-create nomsousreseau Nous avons épluché de long en large internet afin de recueillir le plus d informations possibles de documentations et d utilisateurs, de présentation vidéo / orale. Nous avons réussi à créer un réseau publique et un privé relié par un routeur puis y déployer une instance. Cette instance disposait bien d une adresse IP attribuée par Neutron, malheureusement il nous a été impossible de lui donner un accès extérieur ce qui rendait l utilisation d OpenStack non fonctionelle pour le web élastique. Ce module nous a pris 3 semaines entières pour le faire fonctionner sans pour tant obtenir le résultat escompté. page 18

3.2.7 Swift, le stockage d objet Swift est un service de stockage d objets. La finalité de Swift est de gérer de gros lots de données. Le stockage se veut adaptable, évolutif et redondant. Swift dispose d une API 31, ce qui lui permet de communiquer ainsi que de s interfacer avec d autres modules OpenStack. Glance se sert de Swift afin d y stocker les images des instances. Swift est très orienté Bug Data 32. Là, où auparavant, la gestion de très gros volumes de données n était plus possible avec les outils usuels. Ainsi, Swift est utilisable pour gérer plusieurs TeraBytes de données. Swift n est pas un système de fichiers. Figure 6 Architecture de Swift(Crédit : doc OpenStack) OpenStack Object Storage fonctionne avec 3 types d objets : L objet : le but est d associer un fichier à une somme MD5 33 de son contenu (appelée Etag). Le but de se fonctionnement est de pouvoir vérifier par la suite que l intégrité des données est correcte. Pour chaque objet, des méta-données (taille, date, etc.) sont également conservées. L ensemble des données est stocké sur n importe quel système de fichiers. Le conteneur : ce dernier contient les objets, et liste les objets qui lui sont rattachés afin de mieux «indexer» les objets. Le compte : le compte gère l ensemble des conteneurs via une base SQLite. Il gère une table pour les listes et une pour les méta-données. Ce type de fonctionnement est proche de celui de LVM 34. Un compte détient plusieurs conteneurs, et chaque conteneur détient des objets. Afin de garantir redondance, stabilité et réplication, Swift implémente un stockage distribué. Ainsi, chaque périphérique est rajouté aux grappes existantes, et l on peut agglomérer de multiples espaces de stockage de différents types (NAS, SAN, NFS, etc.). En stockant dans une base interne, Swift permet de faire une allocation intelligente, en permettant de répliquer sur différentes zones pour ainsi mieux gérer les disparités entre les espaces disques. Cela garantit une réplication efficace, souple et intelligente de l usage du stockage. L architecture REST (REpresentational State Transfer) est un principe d architecture inventé dans les années 2000. À ce jour, de nombreux produits utilisent ce principe. Le but est de faire 31. Application Programming Interface (Interface de programmation) 32. Gestion de gros volumes de données 33. Empreinte d un fichier effectuée à partir d une fonction de hashage 34. Gestion par volumes logiques page 19

dialoguer de nombreux services via des protocoles et méthodes simples. Dans notre cas, Swift utilise un serveur proxy et du protocole HTTP. Le fonctionnement est relativement simple : 1. Le client obtient un jeton, 2. Le client établit le dialogue avec le proxy, 3. Le proxy vérifie le jeton, met en cache et transmet la requête aux anneaux de stockage, 4. Le proxy transmet la réponse au client. Le serveur proxy Swift connaît la structure des anneaux, il sait qui interroger et en cas d indisponibilité d un anneau, le proxy sait récupérer le fichier par «une autre route». Le proxy est le chef d orchestre du module Swift, ce dernier sait où et comment, accéder aux informations, stocker les objets, ou interroger les conteneurs. Afin de mettre en place le module Swift, il faut tout d abord configurer le stockage. Pour gérer les conteneurs et la réplication, Swift utilise python (python-xattr, python-setuptools etc.). Pour la réplication, c est rsync qui est utilisé. Une fois la configuration des points de montage effectuée, il suffit de configurer rsync qui se chargera de répliquer intelligemment sur les différents espaces de stockage. Il faut ensuite configurer Memcached qui se chargera de la mise en cache des clés d authentification. L orchestration entre les différents modules de Swift est gérée par proxy-swift. Il faut le configurer correctement afin qu il puisse communiquer avec les anneaux, le keystone et le serveur cache memcached. Il est possible d utiliser plusieurs proxy-swift et faire ainsi de l équilibrage de charge. 3.2.8 Heat, le service d orchestration Heat est un nouveau module introduit avec la version Havana d OpenStack. Le service d orchestration fournit une orchestration basée sur un modèle (template) pour décrire une application cloud en exécutant les API d OpenStack qui appels à générer l exécution d application de cloud computing. Le logiciel intègre d autres éléments de base d OpenStack dans un système de fichier modèle. Les modèles permettent de créer la plupart des types de ressources OpenStack, tels que des instances, des IP flottantes, des volumes, des règles, etc. Il fournit aussi des fonctionnalités plus avancées comme par exemple de la haute disponibilité, de la mise à l échelle automatique (auto-scaling) et des piles imbriquées. Le service d orchestration est constitué des composants suivants : heat : une CLI qui communique avec heat-api pour exécuter l API AWS CloudFormation. heat-api : fournit une API REST native pour OpenStack qui traite les requêtes de l API en les envoyant à heat-engine sur RPC. heat-api-cfn : fournit une API Query AWS qui est compatible avec AWS CloudFormation et traite les demandes de l API en les en voyants à heat-engine sur RPC. heat-engine : orchestre le lancement de modèles et fournit des retours d événements à l API consumer. page 20

Heat permet des options de limitation pour limiter la taille des templates, le nombre de stacks par projet, le nombre d évènement par stack ou encore le nombre de stack imbriquées. Le mode standalone permet l interaction avec une autre plate-forme OpenStack. Nous n avons pas adapté nos scripts pour déployer Heat, néanmoins nous l avons déployé et configuré à partir de Fuel. 3.2.9 Ceilometer, le service de métrologie Ceilometer est un nouveau module. Il fût introduit à partir de la version Havana. Il permet de fournir un service de supervision et de facturation. L idée est arrivée suite à l implosion du nombre de statistiques qui à l époque, était dispatcher entre les différents modules. Afin de simplifier la démarche de collecte et de traitement de l information, le but de Ceilometer est de centraliser la gestion des statistiques. Ceilometer offre de multiples possibilités. Il peut entre autre collecter des données à propos de l usage de réseau (nova-network ou Neutron) ou du CPU (Compute - Nova). Le but est de regrouper en un module, de la «Supervision», c est-à-dire des données chiffrées sur l utilisation de ressources (Réseaux, CPU, RAM, etc.) afin de pouvoir effectuer une facturation à l usage. Les données sont collectées via deux principes, soit Ceilometer collecte les données à partir des notifications émises par les différents services et leurs APIs. Soit Ceilometer recherche dans l infrastructure dans un mode «découverte». À partir de l API REST, il est possible pour les utilisateurs finaux d interagir et d obtenir des données métriques. La collecte d informations : La facturation est la principale finalité du module Ceilometer. On peut la sous-diviser en plusieurs étapes. La première est le fait de devoir collecter les informations. Qui à fait quoi, comment et combien de temps, un ticket est alors généré en fonction de l usage. La deuxième étape est de pouvoir analyser, classifier un certain nombre de tickets en fonction des exigences marketing voulues. La facturation devient alors dynamique et peut fluctuer par rapport à la demande, au marché et/ou à l usage. La troisième étape est pouvoir se servir des données collectées, de la classification afin de facturer aux consommateurs finaux. le processus de collecte : Pour ce faire, Ceilometer implémente deux principes. Le premier est un agent de collecte qui se charge d interroger l ensemble des modules via leurs API. Le deuxième est une liste d attente (ou queue) 35 à laquelle les modules accèdent. Puis, via Oslo 36 L accès aux données : Une fois les données collectées, Ceilometer les stocke dans une base de données. Celle recommandée est MongoDB 37. C est via l API Ceilometer que l on accède aux données. L alerte : Un système d alerte est disponible. Les alertes sont définies suivant plusieurs situations. Un simple seuil peut être une alerte, cela peut être un ensemble de combinaison de seuil entraînant ainsi une alerte. Le système d alerte est disponible pour les administrateurs d OpenStack ou simplement pour les clients pouvant ainsi monitorer et alerter leurs instances à partir de l API Ceilometer. 35. Bus listener 36. Une librairie de file d attente 37. système de gestion de base de données orienté NoSQL page 21

Figure 7 Collecte d informations par Ceilometer (Crédit : doc OpenStack) Compte tenu du temps restant et de l avancement du projet, nous n avons pas installé Ceilometer sur notre configuation local. Nous l avons déployé via Fuel pour pouvoir l utiliser. 4 Déploiement d une infrastructure web élastique 4.1 Pré-requis Le déploiement d une infrastructure web élastique avec OpenStack nécessite l installation de certains modules obligatoires à son bon fonctionnement. En plus du cœur du système composé de Keystone, Glance, Nova et du Dashboard, nous avions besoin d une infrastructure réseau proche de celle d une entreprise. Nous avons donc choisi d utiliser le module Neutron plutôt que le Nova-network (celui-ci ne permettant pas de créer des sous-réseaux et des routeurs). Un environnement web élastique suit un (ou plusieurs) scénario prédéfini. C est le module Heat qui permet de créer ces scénarios et de les déployer. Les templates des scénarios peuvent être écrit en 3 formats différents : YAML 38, JSON 39 et HOT 40 Les scénarios d Auto Scaling 41 sont basés sur une modification environnementale (réseau, processeur, mémoire vive, etc.). Heat a donc besoin de recevoir cette information par un module de supervision. Pour ce faire, Heat interroge Ceilometer afin d être averti de la moindre modification de l environnement. 4.2 Création d une infrastructure de test 4.2.1 L installation d OpenStack, un long fleuve tranquille? Depuis le lancement d OpenStack en 2010, bon nombre d articles, de tutoriels et de vidéos ont fleuri sur Internet. Tous vous dirons que la compréhension de l installation d OpenStack n est pas accessible à tout le monde car cela demande du temps ainsi que des pré-requis techniques en systèmes et réseaux. 38. http://en.wikipedia.org/wiki/yaml 39. http://en.wikipedia.org/wiki/json 40. http://docs.openstack.org/developer/heat/template_guide/hot_guide.html 41. Web élastique page 22

4.2.1.1 La familiarisation avec Grid5000 Tous les groupes qui ont dû travailler dans l environnement de Grid5000 ont été confrontés aux mêmes problématiques : 1. Une prise en main qui demande du temps : Il faut compter une semaine pour bien maîtriser tous les tutoriels de départ. 2. Des contraintes de réservations : L utilisation de Grid5000 est soumise à l acceptation de sa charte utilisateur qui régit les limites d utilisation, les temps de réservations, etc. Ces limites de temps de réservations sont relativement faibles par rapport à la durée d une mise en place d une infrastructure complexe avec OpenStack. 3. L obligation de scripter les installations : Les réservations interactives sont détruites dès que l on quitte l environnement de notre node 42. Ce qui oblige donc à scripter les installations pour ne pas perdre de temps. 4. Des contraintes matérielles : Il faut trouver des machines ayant les pré-requis de la solution que l on veut installer (puissance, nombre de cartes réseaux, mémoire vive). 5. Des contraintes réseaux : Le Grid dispose d un serveur mandataire peu permissif qui empêche certaines installations. 6. Des contraintes systèmes : Les nodes que l on déploie n ont pas forcément le partitionnement adéquate pour la solution que l on veut installer et toute modification du système peut s avérer périlleuse. Au final et malgré toutes ces contraintes, l expérience Grid5000 fut très positive car elle reflète très bien les problématiques d infrastructures que nous rencontrerons dans notre carrière. De plus, la plate-forme du Grid nous a permit de pouvoir déployer OpenStack sur des machines adéquates. 4.2.1.2 Les contraintes matérielles L installation d un environnement de Cloud privé avec OpenStack impose des contraintes matérielles comme un certain nombre de machines possédant des caractéristiques particulières : une puissance processeur suffisante et disposent des instructions de virtualisation Intel VT ou AMD-V pour KVM 43 suffisamment de mémoire vive (indispensable en virtualisation) un nombre minimum de cartes réseaux (deux cartes pour nova-network et trois pour neutron) des disques durs rapide permettant une installation et un déploiement rapide Ce sont typiquement des machines de type serveurs comme l on peut retrouver dans le Grid5000. 4.2.1.3 Choix d une distribution L un des buts de notre projet était également de tester l installation d OpenStack sur différentes distribution libres. Le site d OpenStack propose dans sa documentation des guides d installation pour : 42. Comme le Grid est une infrastructure de clustering, les ordinateurs sont nommés des nodes 43. Kernel-based Virtual Machine :hyperviseur libre utilisé par OpenStack page 23

Debian 7 OpenSuse et SUSE Linux Entreprise Server Red Hat Entreprise Linux, CentOS et Fedora Ubuntu Server 12.04 (LTS 44 ) Nous avons confirmé les installations pour Ubuntu Server, CentOS et en partie pour Debian en local. La distribution qui semble le plus contribuer au projet et qui dispose de beaucoup de documentation est Ubuntu. 4.2.1.4 Une architecture simple? La difficulté liée à l installation d OpenStack, réside dans la complexité de son architecture. Il y a beaucoup de modules, ceux-ci sont indépendants les uns des autres en termes de projets et de technologies mais doivent néanmoins tous communiquer ensemble et être authentifiés par un service central. Le tout orchestré par une base de donnée. Sachant que selon l architecture choisie, le nombre de nodes peut être variable, il faut adapter la configuration en conséquence. La seconde difficulté vient du fait qu une telle architecture doit être définie à l avance en fonction du nombre d ordinateurs à notre disposition. En effet, l installation de tel ou tel module sera adaptée en conséquence. Durant toute la durée du projet, nous avons dû modifier plusieurs fois notre architecture pour s adapter à l environnement dans lequel nous installions OpenStack. La figure qui suit laisse apparaître la complexité du réseau de communication entre les différents services d OpenStack. Il est à votre convenance d imaginer le nombre de fichiers de configurations (3 à 4 par service) et la rigueur nécessaire quant à leurs rédactions. On doit ajouter à cela que chaque service doit disposer de sa propre base et d un utilisateur ayant les bons privilèges au sein de la base de données, chacune de ces bases est souvent liée à une spécificité (stockage d objet, stockage de somme md5, stockage de clé, etc.). 44. Long Term Support ou version maintenue pendant 5 ans page 24

Figure 8 Architecture des services d OpenStack page 25

4.2.1.5 Réseau as a service Le module Neutron qui peux gérer des réseaux complexes tel que l on peut en trouver dans les grandes structures nous a pris à lui seul deux semaines de compréhension. Encore une fois, il impose une réflexion préalable quant à la technologie à utiliser et doit suivre un schéma réseau précis pour être fonctionnel. 4.2.2 Choix du mode d installation : 4.2.2.1 Installation manuelle Nous avons opté très tôt dans la chronologie du projet pour une installation sur deux postes de la salle 501. Il nous semblait essentiel de débuter par une installation complète en manuel 45 pour comprendre le fonctionnement en profondeur du système et pouvoir scripter plus tard. Ainsi, nous bénéficions de la persistance de l installation par rapport au Grid5000 où elle est perdue à chaque fin de réservation (quelques heures). Mais ce choix d installation, même s il est le plus pédagogique, est aussi le plus long. Néanmoins, la configuration matérielle de ces deux postes a rapidement montré ses limites et le nombre de postes disponibles dans la salle est limité. Dans tous les cas, l étape par installation manuelle a été un point essentiel et indispensable pour appréhender correctement le reste du projet. Il n est pas essentiel de tout installer manuellement, on peut passer ensuite par la création d un script. Les modules que nous avons installés manuellement sont : 1. Keystone 2. Nova 3. Glance 4. Horizon 4.2.2.2 DevStack Figure 9 Devstack Devstack 46 est un projet d installation d OpenStack à base de scripts bash maintenu par une communauté de développeurs. Il permet de construire des environnements complets destinés au développement, aux tests. Il n est absolument pas destiné à une mise en production. Il permet d installer OpenStack sur en All-in-One 47 ou en Multi-Nodes ainsi que sur des machines virtuelles. Nous avons confirmé l installation de Devstack en machine virtuelle ainsi que sur une machine physique. Des test ont été effectués pour essayer d installer DevStack dans Grid5000 mais son serveur mandataire n autorisait pas l accès au site d OpenStack. 4.2.2.3 Puppet 45. http://docs.openstack.org/havana/install-guide/install/apt/content/ 46. http://devstack.org/ 47. Tous les modules sur une seule machine page 26

Figure 10 puppet Dans Grid5000, il existe un tutoriel d installation spécifique à OpenStack qui utilise un serveur Puppet 48 interne au Grid5000 et créé par Sébastien Badia. Les essais d installation par cette méthode nous ont aussi fait perdre beaucoup de temps car elle comportait des bugs. Le bug concernait une différence de version entre le serveur Puppet et le langage Ruby utilisé par un script. Le bug a été confirmé par notre tuteur et Sébastien Badia. Le tutoriel du Grid5000 a été rectifié le 25 février 2014. A partir de là, nous avons pu utiliser cette méthode pour déployer OpenStack dans le Grid. Malheureusement, il s est avéré que la version installée (trop ancienne) n était pas celle sur laquelle notre projet portait. À ce jour, la version OpenStack du Grid n a toujours pas été mise à jour. 4.2.2.4 La méthode Ubuntu : MAAS et Juju Ubuntu propose sa propre méthode de déploiement à grande échelle avec deux outils libres, MAAS et Juju. MAAS 49 est un logiciel dédié aux déploiements à grande échelle sur des serveurs physiques. Il permet d administrer de façon dynamique des installations de clusters ou de cloud. Il s occupe de déployer le système d exploitation Ubuntu à l aide d une interface web. Ensuite, il fait appel à Juju qui est le service d orchestration. Juju 50 permet d installer des applications à la volée sur les nodes connectés à MAAS. Il utilise des "charmes" 51 pour déployer des applications selon des scénarios prédéfinis. Il dispose également de sa propre interface web. L inconvénient de ce type de service d orchestration est qu il ajoute encore une couche logicielle supplémentaire et n apporte pas de plus-value pédagogique. 4.2.2.5 RDO : OpenStack à la sauce Red Hat L équipe de développement de Red Hat et la communauté des distributions dérivées proposent aussi leur outil pour déployer OpenStack : RDO 52. Ils utilisent l utilitaire Packstack 53 qui, lui même, déploie OpenStack en utilisant les recettes de Puppet de manière sécurisée à travers le protocole SSH. Pour des raisons de temps, nous n avons pas utilisé cette solution. 4.2.2.6 Utilisation de scripts L échec de déploiement d OpenStack par Puppet dans le Grid5000 nous a conduit à rechercher le langage de script le plus adapté à notre futur installation. Les modules étant tous en Python, 48. Puppet est un outil de gestion de la configuration de serveurs, il permet le télé-déploiement de configuration sur un ensemble de serveurs en quelques minutes. L intérêt de cette solution open source réside dans son support multiplateformes (basé sur Ruby), sa sécurité (SSL), son développement actif et sa relative simplicité à mettre en oeuvre. 49. Pour Metal As a Service - https://maas.ubuntu.com/ 50. http://www.ubuntu.com/cloud/tools/juju 51. Ce sont les recettes de l outil "CHEF" - http://www.getchef.com/chef/ 52. Red Hat to build a distribution of OpenStack - http://openstack.redhat.com/main_page 53. https://wiki.openstack.org/wiki/packstack page 27

nous avons décidé d utiliser ce langage. Nous sommes partis sur une base de 3 scripts : Le Controller : contenant Keystone, Glance, Neutron-server, Nova et le Dashboard Le Compute (dédié au stockage) : Nova et l agent Open vswitch de Neutron Le Network (qui gère les réseaux virtuels) : les agents DHCP, Open vswitch et L3 Ces scripts sont disponibles en annexes. Nous nous sommes inspirés des scripts de "Romil Gupta" (Développeur Indien et contributeur d OpenStack) après avoir obtenu son accord. L installation par ces scripts ont été validés en machines virtuelles puis dans l environnement Grid5000. Spécifiquement sur les nodes du Luxembourg car ils possèdent trois cartes réseaux. 4.3 Choix final : Fuel Figure 11 Une installation par Fuel A deux semaines de la fin du projet, nous étions toujours en train de travailler sur Neutron. N ayant plus le temps de tester manuellement les modules restants (Swift, Heat et Ceilometer) avant de les intégrer dans le script, nous avons décidé de terminer avec une installation automatisée pour se concentrer sur la partie web élastique du projet et travailler sur les templates de Heat. Nous avons choisi Fuel 54 de Mirantis. Il est distribué sous licence Apache. Cette solution 54. http://wiki.openstack.org/wiki/fuel page 28

permet de déployer OpenStack à grande échelle via une interface web de configuration. Fuel propose aussi de centraliser les logs des nœuds et des services qu il déploie. 4.3.1 Grid or not Grid... Malheureusement, la structure automatisée (kickstart) de l ISO utilisé par Fuel ne nous a pas permis de le déployer dans Grid5000. 4.3.2 Matériel Fuel a donc permis de déployer OpenStack sur 3 machines virtuelles avec malgré tout des configurations raisonnables : Figure 12 Notre déploiement 4.3.3 Réseaux La configuration réseau choisie pour notre installation finale est basée sur OpenVSwitch (Neutron). Cela permet d isoler les réseaux internes dans des VLAN. page 29