Conservatoire national des arts et métiers

MÉMOIRE présenté en vue d'obtenir

le DIPLÔME d'INGÉNIEUR CNAM

Spécialité : informatique

Parcours : réseaux, systèmes et multimédia

par

Xavier BUCHE

Cloud universitaire avec OpenStack

Soutenu le 1er décembre 2015, à Lille, devant le jury :

PrésidenteMadame Isabelle WATTIAU

MembresMonsieur Didier BOUCHART Monsieur Vincent BRABANT Monsieur Thomas DINNYES

Monsieur Frédéric VAST

Les représentants de l'Université Lille 1 :Monsieur Didier LAMBALLAIS, directeur des systèmes d'information

Monsieur Mohammed KHABZAOUI, ingénieur systèmes

RésuméLe nouveau paradigme du cloud computing est en ce moment sur toutes les lèvres. Tout le monde en parle, mais bienpeu connaissent les rouages de son fonctionnement. Et c'est la conséquence de l'une de ses caractéristiquesattendues : celle d'être opaque. L'utilisateur n'a pas à connaître les détails de sa mise en œuvre.

Ce mémoire d'ingénieur du CNAM s'adresse aux administrateurs systèmes et aux informaticiens curieux, avecl'ambition de leur révéler la machinerie intime d'un nuage et de le leur présenter sous un angle de vue inhabituel :celui de l'intérieur.

Mais des nuages, il en existe moult variétés. Celui dont je parle dans ces lignes est de type infrastructure. En d'autrestermes, les choses manipulées en son sein sont les pendants virtuels d'objets du monde réel (serveurs, réseaux,routeurs, etc.).En outre, bien que les services de cloud public soient pléthoriques, l'Université Lille 1 a considéré que sa taille et sesbesoins étaient suffisants pour projeter la création d'un cloud privé. De nombreuses solutions logicielles permettent de mettre en place ce type de nuage. Le choix s'est porté surOpenStack, et l'essentiel de ce texte est consacré à sa configuration.

L'objet de ce mémoire est ainsi de partager mon expérience de la mise en œuvre d'une plate-forme de cloud privébasée sur OpenStack. Y sont décrites les différentes phases du projet : l'étude de l'état de l'art, l'analyse de la solutionretenue, son test et sa mise en production.

Mots-clefsOpenStack, cloud privé, IaaS, virtualisation, consolidation, mutualisation, système, réseau

AbstractNowadays, the new paradigm of cloud computing is all the rage. Everybody talks about it, but very few know the insand outs of its working. And that's the consequence of one of its expected feature: to be opaque. The user doesn'thave to know the details of its implementation.

This CNAM engineer's report is intended for system administrators as well as interested computer scientists, with theaim of disclosing the intimate machinery of the cloud and presenting it from an unusual point of view: the inner side.

But there are many cloud varieties. The one I am dealing with here is infrastructure type. In other words, the thingsused inside it are the twins of real-life objects (servers, networks, routers, etc.).Furthermore, although there are countless public cloud services, Lille 1 University has deemed its size and its needssuited the project of creating a private cloud.Lots of software solutions make it possible to implement that sort of cloud. The choice fell on OpenStack, and themain part of this text is devoted to its configuration.

The purpose of this report is thus to share my experience of the setting up of a cloud platform based on OpenStack.The different stages of the project are described: the study of the state of the art, the analysis of the adopted solution,its test and its production launch.

KeywordsOpenStack, private cloud, IaaS, virtualization, consolidation, mutualization, system, network

Remerciements

Je tiens avant tout à remercier Didier Lamballais, qui est à l'origine de cet ambitieux projet.

Je remercie, bien évidemment, Mohammed Khabzaoui et Sébastien Fillaudeau, pour leur aide précieuse, leur soutien technique, et pour les foisonnantes discussions qui ont fait de ce projet ce qu'il est.

Je n'oublie pas mes collègues pour leurs conseils avisés.

J'adresse également mes remerciements aux enseignants du CNAM, qui m'ont ouvert l'esprit et initié à des sujets que je n'aurais sans doute jamais explorés sans eux.

Je remercie enfin mes proches, qui finissaient par se demander s'il était bien raisonnable de travailler le soir, le week-end, parfois la nuit, et même pendant les vacances !

Conventions d'écriture

Les icônes ci-dessous mettent en évidence certaines parties qui peuvent concerner :

une remarque, une annotation, une parenthèse1

un exemple, une démonstration1

un choix2

une critique, un bémol3

des perspectives à venir, une évolution attendue4

1 icône réalisée par Oliver Scholtz (and others) sous licence GNU GPL2 icône réalisée par Everaldo Coelho sous licence GNU LGPL3 icône réalisée par New Mooon sous licence GNU GPL4 icône réalisée par Visual Pharm sous licence CC BY-ND

Sommaire1 Introduction9

1.1 Naissance d'un projet91.2 L'informatique en nuage91.3 Contexte10

1.3.1 L'Université Lille1101.3.2 Le système d'information101.3.3 Le groupe de travail111.3.4 Les objectifs du projet de cloud privé111.3.5 Chronologie synthétique du projet121.3.6 Organisation12

2 Etat de l'art142.1 Définitions14

2.1.1 Virtualisation142.1.2 Cloud computing14

2.2 Histoire152.3 Franchir le pas ? Hésiter ? Résister ?162.4 Quelques éléments de réflexion162.5 Le cloud privé17

3 Présentation d'OpenStack193.1 Le soutien de l'industrie193.2 L'éclosion d'un standard193.3 Un nuage fait de briques20

3.3.1 Keystone (gestion des identités)203.3.2 Glance (gestion des images)203.3.3 Nova (gestion des instances)203.3.4 Cinder (stockage en mode bloc)203.3.5 Swift (stockage en mode objet)203.3.6 Neutron (gestion des réseaux)213.3.7 Ceilometer (mesures)213.3.8 Horizon (interface web de management)213.3.9 Heat (orchestration)21

3.4 Et les autres ?224 Mise en œuvre23

4.1 Choix du matériel234.1.1 Les besoins234.1.2 Les serveurs23

4.1.2.1 Rack ou blade234.1.2.2 La gamme Dell PowerEdge244.1.2.3 Choix du processeur254.1.2.4 Quantité de mémoire vive25

4.1.3 Le stockage264.1.4 Le réseau26

4.1.4.1 Les interfaces ethernet26 Broadcom26 Intel26

4.1.4.2 Le commutateur274.2 Installation et adaptation à l'environnement28

4.2.1 Le réseau294.2.2 Les outils Tiers29

4.2.2.1 Le système d'exploitation294.2.2.2 Le SGBD304.2.2.3 La gestion du temps324.2.2.4 Le bus de données logiciel32

4.2.3 Dans le vif du sujet334.2.3.1 Les versions d'OpenStack334.2.3.2 Les services33

Le catalogue33 Les comptes35 Les pipelines WSGI35 Les bases de données35 Dialogue avec les API36

Panneau de contrôle36 Ligne de commande36 Requêtes HTTP37

4.3 Keystone et l'authentification404.3.1 Vocabulaire404.3.2 Les jetons414.3.3 RBAC : Role Based Access Control414.3.4 Apache HTTPD424.3.5 Authentification43

4.3.5.1 Des comptes pour OpenStack434.3.5.2 Tentatives avec le SSO CAS434.3.5.3 LDAP45

Réplication ou synchronisation45 Authentification sur l'annuaire LDAP de l'université45 Compromis45 Identités46 Assignation47 Groupes48 Configuration49 Gestion des projets et des rôles50

4.3.6 Vérification514.4 Glance et les images51

4.4.1 Fonctionnement514.4.2 Configuration514.4.3 Gestion des images52

4.5 Nova et les machines virtuelles544.5.1 Vue d'ensemble544.5.2 L'hyperviseur554.5.3 L'ordonnanceur564.5.4 Partitionnement57

4.5.4.1 Agrégats d'hôtes574.5.4.2 Zone de disponibilité59

4.5.5 Distribution604.5.5.1 Cellules604.5.5.2 Régions60

4.5.6 Focus sur les instances614.5.6.1 Optimisations61

Cache des images61 Format raw61 Format qcow262 Redimensionnement62 Pré-allocation de blocs64

4.5.6.2 Stockage644.5.6.3 Migration66

A chaud66 Par ssh67

4.5.6.4 Redimensionnement d'instance67

4.5.6.5 Évacuation684.5.6.6 Une instance dans tous ses états684.5.6.7 Mettre une instance de côté694.5.6.8 Adaptation des images704.5.6.9 Connexion aux instances72

Clefs SSH72 Compte utilisateur73 Console73

VNC73 SPICE74

Injection de mots de passe754.5.6.10 Instantanés77

4.6 Neutron et le réseau784.6.1 Neutron ou Nova-network ?78

4.6.1.1 Nova-network784.6.1.2 Neutron78

4.6.2 Réseaux internes et réseaux externes784.6.3 NAT794.6.4 Adresse fixe et adresse flottante814.6.5 Espaces de noms réseaux814.6.6 Cheminement des données83

4.6.6.1 Entre les nœuds83 VLAN83 GRE et VXLAN84 Changement du protocole88

4.6.6.2 Sur les nœuds de calcul884.6.6.3 Sur le contrôleur91

4.6.7 Les réseaux externes934.6.8 Agrégation de liens94

4.6.8.1 Configuration côté switch944.6.8.2 Configuration côté contrôleur95

4.6.9 Les agents964.6.10 Simplification et partage964.6.11 Les groupes de sécurité97

4.6.11.1 Qu'est ce donc ?974.6.11.2 Règles par défaut98

4.6.12 Le serveur de métadonnées994.6.13 Redirection vers le proxy web100

4.6.13.1 Préambule1004.6.13.2 Configuration101

4.7 Horizon et l'interface web1024.7.1 Choix de l'interface1024.7.2 Sécurisation de l'accès1034.7.3 Test de charge104

4.8 Quotas1054.8.1 Glance1054.8.2 Nova1054.8.3 Neutron107

4.9 Ceilometer et la facturation1074.10 Supervision1084.11 Plan catastrophe1094.12 Sauvegardes110

4.12.1 Parer à l'erreur humaine1104.12.2 Parer à la catastrophe1104.12.3 NDMP111

4.12.3.1 NDMP et la sécurité des transferts1114.12.3.2 Conclusion sur NDMP112

4.12.4 rsync1124.12.4.1 Données des utilisateurs1124.12.4.2 Données systèmes113

4.12.5 Restauration1145 Bilan et perspectives115

5.1 Bilan1155.2 Perspectives115

6 Conclusion1166.1 Apports pour l'université1166.2 Apports personnels116

7 Références1187.1 Bibliographie1187.2 Webographie1187.3 Liste des figures1197.4 Liste des tableaux1197.5 Index des abréviations1207.6 Lexique121

8 Annexes1238.1 Adaptation de l'interface web1238.2 Test de charge de l'interface web1258.3 Tutoriel d'utilisation126

1 Introduction

1.1 Naissance d'un projetDébut 2013, le DSI5 de l'Université Lille 1, Didier Lamballais, initiait un groupe de travail chargé d'étudier les solutionsde cloud computing. Emprunt de curiosité et quelque peu incrédule, je décidai d'y prendre part.

A cette époque, le cloud était pour moi une sorte de nuage obscur, impénétrable, un cumulonimbus auréolé d'uneépaisse couche de marketing. Mais derrière le voile, j'ai rapidement découvert la nature exacte et la véritable utilité dece nouveau concept. J'ai pu discerner ses moindres subtilités, ses plus infimes nuances, et désormais il m'apparaît toutà fait clair et limpide.

Vous aussi peut-être, en lisant ce texte, dissiperez-vous le brouillard qui tapisse les arcanes du cloud computing.

1.2 L'informatique en nuageDepuis quelques années, c'est le mot qui revient dans toutes les discussions de responsable informatique. Est-ce unerévolution ou un effet de mode ? La question semble ne plus se poser : en décembre 2014, 55 % des entreprises etorganismes publics déclarent utiliser l'informatique en nuage [Cloudindex].

Avant d'aller plus loin, il est nécessaire de savoir ce qu'est le cloud. Donnons-en donc une première définition.

A l'origine, la métaphore du cloud provient des schémas de réseau informatique, sur lesquels, depuis toujours, lenuage représente le réseau externe, comme Internet. Autrement dit, ce qui est au-delà des frontières du sujet duschéma.De ce point de vue, le nuage est donc un vaste ensemble d'objets indéterminés. Plus précisément, il contient un réseauqui relie un grand nombre d'ordinateurs et de ressources informatiques. Mais peu importe ce qu'il y a dedans, carl'utilisateur n'a pas à le savoir ! L'essentiel est d'obtenir le service demandé.

Voilà donc le nouveau paradigme du cloud : on mutualise les ressources (matériels, plates-formes, logiciels) et on lespartage au plus grand nombre, chacun consommant juste ce dont il a besoin et payant juste ce qu'il consomme.

L'annonce de la création du projet OpenStack, en 2010, se termine par une prémonition qui résume bien l'ampleur dece bouleversement, et que j'ai traduite ainsi : « L'ère du PC a mis un ordinateur sur chaque bureau. L'ère du cloudmettra la puissance des superordinateurs à la portée de tout un chacun. » [Annonce de Rackspace]

Voyons maintenant ce que peut apporter un nuage à une université, mis à part la pluie…

5 Directeur des Systèmes d'Information

Xavier Buche Cloud universitaire avec OpenStack – CNAM Nord-Pas de Calais 9

1.3 Contexte

1.3.1 L'Université Lille1L'université Lille 1 est l'une des trois universités de la communauté urbaine de Lille. Elle se trouve sur le domaineuniversitaire Cité Scientifique de Villeneuve d'Ascq, au sud-est de la métropole lilloise.L’université délivre plus de 200 diplômes nationaux dans les domaines des sciences et technologies. Elle accueilleenviron 20000 étudiants en formation initiale et 12000 auditeurs en formation continue. Plus de 1500 enseignants-chercheurs sont regroupés en 39 laboratoires dont les trois quarts sont associés au CNRS. L'Université Lille 1 est encours de fusion avec les deux autres universités de l'agglomération pour former l'Université de Lille. De plus, elle estmembre de la ComUE (Communauté d'universités et d'établissements) Lille Nord de France, qui regroupe lesuniversités et écoles publiques du Nord-Pas-de-Calais.

1.3.2 Le système d'informationLe Centre de Ressources Informatiques (CRI) de l'université gère l’ensemble des moyens informatiques d’intérêtcollectif. Il contribue au développement et à la mise en œuvre de nombreux services numériques, dont les suivants :– messagerie, agenda et prise de rendez-vous– maintenance/sécurité/antivirus des machines de bureau et portables, accès WIFI et VPN– réalisation/hébergement de sites Web– accès au calcul intensif– formation (calcul, langages, portail-ENT, système)– mise en œuvre et déploiement des applications de gestion (scolarité, comptabilité, ressources humaines,

recherche, paie)– espace numérique de travail (inscriptions étudiantes, consultation de notes et de documents administratifs).– hébergement de serveurs (laboratoires, ICARE, GRID 5000,…)

Xavier Buche Cloud universitaire avec OpenStack – CNAM Nord-Pas de Calais 10

Figure 1 : cloud computing (source : fr.wikipedia.org)par Sam Johnston / CC BY-SA 3.0

– distribution de logiciels (conseil et assistance dans le cadre du marché logiciels).– statistiques (constitution de la base ORES et traitement d’enquêtes)– participation à la diffusion des logiciels libres

En plus des services fournis par le CRI, de nombreux départements ou laboratoires disposent de leurs propresressources informatiques (équipes techniques, infrastructures, etc.). Le DSI suit actuellement une politique deconcentration des moyens informatiques qui vise globalement à délester les informaticiens des tâches à faible valeurajoutée (installation manuelle de machines, gestion de comptes utilisateurs, etc.) de manière à ce qu'ils se focalisentsur les besoins des utilisateurs (amélioration de la qualité de service, apport de solutions innovantes, etc.).Le projet de cloud privé entre dans le cadre de cette volonté de mutualisation.

1.3.3 Le groupe de travailL'augmentation continue des performances et des capacités des serveurs physiques ainsi que le développement destechniques de virtualisation ont permis ces dernières années la consolidation des infrastructures informatiques. Cettetendance de fond permet de tirer les bénéfices d'une mutualisation qui peut se faire soit dans le cadre d'uneexternalisation en recourant aux services d'hébergement commerciaux (Amazon, Google, Microsoft, OVH, etc.) soiten interne pour un établissement d'une taille suffisante, comme c'est le cas de l'Université Lille 1, ou bien encore dansun cadre multi-établissements. Cette mutualisation de l'infrastructure informatique permet de diminuer les coûts d'investissement et defonctionnement et l'impact environnemental des activités de l'université. Elle s'inscrit dans une démarche dedéveloppement durable.

L'offre de service actuelle du CRI repose sur la solution de virtualisation VMware ESX, qui nécessite l'interventiond'un administrateur pour l'allocation des ressources. Cette solution, qui supporte aussi l'offre d'hébergement deserveurs web ou d'applications web, correspond à nos besoins à court terme mais ne supportera pas un changementd'échelle.

Pour amplifier la dynamique de mutualisation des serveurs informatiques et répondre aux nouveaux besoins pour lapédagogie ou la recherche, un groupe de travail a été constitué début 2013 afin d'étudier les nouvelles solutionslogicielles qui permettent de proposer un service d'hébergement de serveurs virtuels à grande échelle et pouvoir ainsipréparer l'évolution de l'offre de service d'hébergement mutualisée.

Une fois la solution choisie, un trio d'ingénieurs s'est proposé de mettre en place ce nouveau service et del'administrer : Sébastien Fillaudeau (pôle systèmes du CRI), Mohammed Khabzahoui (UFR6 de mathématiques) et moi-même (UFR d'Informatique, Electronique, Electrotechnique, et Automatique).

1.3.4 Les objectifs du projet de cloud privéL’Université Lille 1 doit fournir à ses utilisateurs un nouveau service simplifié de mise à disposition de machinesvirtuelles à la demande, c'est-à-dire une infrastructure de type IaaS (Infrastructure as a Service).

La mise en place d'un cloud privé offre plusieurs avantages :– mutualiser des ressources matérielles éparpillées et sous ou sur-utilisées– permettre aux utilisateurs (enseignants, chercheurs, personnels des composantes, étudiants) de gérer eux-

mêmes leurs machines virtuelles (création, suppression, allocation de ressources, etc.)

Un certains nombres de critères doivent orienter les décisions prises et les choix réalisés :– allocation de ressources immédiate et à la demande– supervision centralisée de l'infrastructure et facturation des utilisateurs en fonction de métriques précises– gestion poussée des autorisations (droits d'accès, délégations, etc.)– ergonomie de l'interface utilisateur– facilités dans l'ajout ou la suppression de ressources matérielles– sécurité et performances– normalisation de l'API (Application Programming Interface)– coûts

6 Unité de Formation et de Recherche. Équivalent d'une faculté.

Xavier Buche Cloud universitaire avec OpenStack – CNAM Nord-Pas de Calais 11

Quelques exemples d'utilisation plausibles :– un étudiant doit réaliser un projet d'application web avec un cadriciel de son choix– un enseignant souhaite organiser des séances de Travaux Pratiques de nosql avec hbase et hadoop– un chercheur désire lancer ponctuellement des calculs– un ingénieur voudrait mettre à disposition un nouveau service, comme une forge– un développeur veut faire quelques tests ou mettre en ligne son travail avant de le valider

1.3.5 Chronologie synthétique du projetLe groupe de travail lancé par Didier Lamballais en 2013 et animé, dans sa phase d'étude, par Cyrille Bonamy s'estrapidement orienté vers le système OpenStack. En novembre 2013, j'ai ainsi commencé le projet en mettant en placeune maquette qui faisait office de preuve de concept. Elle m'a permis de m'initier aux différentes notions propres aucloud, et de faire mes premières armes sur certaines des technologies employées. Quelques mois plus tard,Mohammed Khabzaoui et Sébastien Fillaudeau me rejoignaient pour me seconder et m'apporter une aide précieusedans les décisions techniques qui allaient être prises.

En juillet 2014, un pas était franchi : la commande du matériel qui constituerait l'infrastructure physique était le pointde départ qui conduira à la plate-forme actuelle. En répliquant une grande partie de la configuration de la maquette, iln'a pas fallu longtemps pour que le nouveau système soit opérationnel et testé par quelques utilisateurs. Maisopérationnel ne signifie pas utilisable à grande échelle, et il restait encore beaucoup à faire avant le passage enproduction. C'est dans la période allant du mois d'octobre 2014 à avril 2015 que l'essentiel des difficultés ont étésurmontées. Une quantité conséquente de problèmes très divers ont trouvés leur solution. Ce mémoire en témoigneen partie.

Au mois de mai dernier, une nouvelle phase était atteinte : le service OpenStack était ouvert au test à la centained'ingénieurs et techniciens en informatique de l'université, et à la centaine d'enseignants informaticiens du FIL 7. Acette occasion, j'ai demandé la création d'un alias de messagerie et d'une liste de diffusion pour faciliter lacommunication avec les beta-testeurs.Jusqu'à présent, j'étais intervenu à plusieurs reprises lors de différentes réunions pour leur présenter l'idée de manièreassez générale. Cette fois, j'organisais des réunions pour décrire de façon détaillée l'utilisation de la plate-forme,suivies de travaux pratiques en salle machine.Un mois plus tôt, j'avais profité de la journée retours d'expérience du réseau métier MIn2RIEN8 pour faire uneprésentation technique destinée à un public d'administrateurs systèmes.

En cette rentrée 2015, même si le service OpenStack a été testé par de nombreux utilisateurs exigeants, il est toujoursen phase d'essai et s'apprête à franchir une nouvelle étape, celle de son utilisation à une plus grande échelle,potentiellement par les 700 étudiants du FIL plus quelques autres formations.

1.3.6 OrganisationPour faciliter le travail d'équipe, nous avons utilisé les outils ownCloud pour le partage de fichiers et Redmine pour leplanning. Nous nous réunissions généralement une demi-journée par semaine pendant les périodes intenses duprojet, dans l'objectif de présenter le travail réalisé les jours précédents, d'en discuter et de prendre des décisionsd'ordre technique.

Voici décrites les principales tâches qui ont été réalisées :1) étudier la documentation technique d'OpenStack et les principaux sites spécialisés2) mettre en place une maquette– installer OpenStack en suivant le guide officiel– comprendre, par la pratique, le fonctionnement du système– écrire un script d'installation automatique de la plate-forme– estimer les besoins matériels et lancer les commandes

3) installer les machines et les systèmes d'exploitation4) appliquer et corriger le script d'installation automatique d'OpenStack5) configurer la grappe de SGBD

7 Formations Informatiques de Lille 1, département d'enseignement de l'informatique appartenant à l'UFR d'IEEA8 réseau des informaticiens des établissements d'enseignements supérieurs, laboratoires de recherche et rectorats du Nord Pas-de-Calais

Picardie

Xavier Buche Cloud universitaire avec OpenStack – CNAM Nord-Pas de Calais 12

6) configurer l'authentification– configurer le composant Keystone– installer et configurer le serveur/cache LDAP– écrire un script de gestion automatique des projets et des rôles en fonction des comptes LDAP

7) configurer un partage NFS sur la baie de stockage8) configurer la gestion des images– configurer Glance– résoudre le problème de création d'une image à partir d'un lien HTTP

9) configurer la gestion des instances– configurer le composant Nova– paramétrer l'ordonnanceur– configurer la manière dont les instances sont créées et comment le cache est alimenté– configurer et tester les différents modes de migration et le redimensionnement d'instances– tester la reprise en cas de panne, de coupure de courant, d'arrêt d'un nœud, etc.– configurer et tester la fonction instantané– réaliser un test de charge processeur, mémoire et stockage– créer plusieurs images de machine virtuelle– configurer et tester les différents moyens d'accéder aux instances– configurer et tester la console des instances avec VNC et SPICE– résoudre le problème de connexion au serveur de métadonnées

10) configurer la gestion des réseaux– configurer le composant Neutron– comparer Nova-network avec Neutron– corriger les problèmes liés au MTU– réaliser un test de charge du réseau– simplifier l'utilisation des réseaux– résoudre le problème du switch br-tun qui bloque les paquets– créer un réseau externe supplémentaire– réaliser un agrégat de liens– remplacer GRE par 802.1Q– modifier les règles du groupe de sécurité par défaut– paramétrer une redirection vers le proxy web avec Redsocks

11) configurer et tester le composant Cinder12) configurer les outils de supervision13) mettre en place la sauvegarde des données systèmes et utilisateurs14) adapter l'interface web Horizon15) réaliser un test de charge de l'interface web16) réaliser un tutoriel d'utilisation d'OpenStack

Xavier Buche Cloud universitaire avec OpenStack – CNAM Nord-Pas de Calais 13

2 Etat de l'art

2.1 Définitions

2.1.1 VirtualisationBien que sa vulgarisation soit récente (elle date d'une quinzaine d'années), la technique de la virtualisation estétonnamment ancienne. Déjà en 1968, le système CP/CMS9, qui équipait la fameuse série 360 d'IBM, permettait defaire tourner différents systèmes d'exploitation en parallèle sur la même machine physique. Il s'agit du tout premierhyperviseur.Cela dit, le véritable essor de la virtualisation est lié à une société, VMware, qui popularisa cette technologie dans lesannées 2000 sur l'architecture x86. Aujourd'hui, VMware détient encore l'essentiel du marché de la virtualisation, avecMicrosoft HyperV comme challenger.

Il existe cependant plusieurs alternatives libres à ces solutions propriétaires :– KVM/QEMU10 : intégré au noyau Linux, il permet de le transformer en hyperviseur. Le logiciel QEMU utilise

KVM notamment pour accéder aux instructions d'accélération de la virtualisation des processeurs récents.– Xen est l'autre hyperviseur du monde libre. Il est resté longtemps le plus performant des hyperviseurs libres

grâce à son système de paravirtualisation, où les machines invitées doivent être modifiées pour prendreconnaissance de la machine hôte.

– LXC : dernier né d'une lignée comprenant chroot, Vserver ou encore OpenVZ, LXC ne fait pas de lavirtualisation complète. Au lieu de cela, les machines virtuelles sont isolées dans des conteneurs, qui separtagent le noyau du système.

Aujourd'hui, Xen et KVM/QEMU partagent de plus en plus de code similaire. Leurs performances et leursfonctionnalités n'ont jamais été aussi proches.Comparé à Xen et KVM, LXC est plus performant, mais au prix d'une moins bonne isolation des machines virtuelles,ce qui peut poser des problèmes de fiabilité et de sécurité.

A ce stade, vous vous demandez peut-être pourquoi parler de virtualisation alors que le thème de ce mémoire est lecloud. C'est que ces deux sujets vont de pair : même s'il est possible de provisionner des machines et des ressourcesphysiques, les avantages de la virtualisation prennent tout leur sens à l'échelle du cloud. En particulier, lavirtualisation permet de partager les ressources physiques et d'optimiser leur taux d'utilisation.Le développement de l'informatique en nuage est donc lié et succède directement à celui de la virtualisation.

2.1.2 Cloud computingNous allons maintenant tenter de cerner aussi précisément que possible les contours du nuage. A cet effet, le NIST(National Institute of Standards and Technology) américain nous aide en en donnant une définition qui fait référence.Selon cet institut, le cloud computing permet d'accéder facilement, à la demande, à tout moment et en tout lieu, à desressources informatiques partagées et configurables (réseaux, serveurs, stockage, applications et services). Cesressources peuvent être allouées et libérées rapidement et sans intervention de l'hébergeur.Cette définition est censée changer au cours du temps selon l'évolution des cas d'utilisation, des technologies utilisées,etc.

5 caractéristiques essentielles définissent le cloud computing :– self-service à la demande : un utilisateur peut, unilatéralement, allouer des ressources sans interaction

humaine avec le fournisseur– accès réseau élargi : les ressources sont accessibles via le réseau par des systèmes hétérogènes (clients légers,

clients lourds, etc.)– partage de ressources : les ressources sont dynamiquement affectées, libérées puis réaffectées à différents

utilisateurs. L'utilisateur n'a pas besoin de connaître la localisation (pays, région, centre de donnée) des

9 Control Program/Cambridge Monitor System10 Quick Emulator/Kernel-based Virtual Machine

Xavier Buche Cloud universitaire avec OpenStack – CNAM Nord-Pas de Calais 14

ressources qui lui sont affectées, mais il peut la préciser s'il le souhaite, pour des raisons de performance oude sécurité.

– élasticité : les ressources peuvent être augmentées ou diminuées facilement, voire automatiquement, pourqu'elles s'adaptent aux besoins en temps réel. Les capacités offertes paraissent infinies, et l'utilisateur peut enconsommer davantage, à tout moment, sans se soucier d'une éventuelle limite.

– mesures : le système contrôle et optimise l'usage des ressources en mesurant régulièrement leurconsommation. Ces mesures sont indiquées de manière transparente aux utilisateurs et au fournisseur pourle calcul de la facturation.

3 modèles de service distinguent les différents types de cloud :– Software as a Service (SaaS) : la ressource fournie consiste en applications exécutées par le système de cloud.

Le consommateur n'a pas à se préoccuper de l'infrastructure d'exécution des applications, ni de saconfiguration, sauf dans des limites restreintes. Les applications sont accessibles en tout lieu et le plussouvent avec un client léger (un navigateur web par exemple). Elles sont parfois appelées cloudware et sontpartagées par plusieurs clients (multi-tenant)

– Platform as a Service (PaaS) : la ressource fournie consiste en un environnement d'exécution capabled'héberger les applications du consommateur. Le consommateur n'a pas à se soucier de l'infrastructureutilisée par l'environnement d'exécution (réseaux, serveurs, systèmes d'exploitation et stockage), mais il doitdéployer, configurer et, plus généralement, gérer les applications et, dans certaines limites, l'environnementd'exécution de ces applications.

– Infrastructure as a Service (IaaS) : la ressource fournie consiste en capacités de traitement et de stockage, ainsiqu'en bande passante réseau. Le consommateur peut utiliser ces capacités pour déployer du logicielarbitraire. Il met en place et contrôle entièrement le système d'exploitation, les applications et leurenvironnement d'exécution.

4 modèles de déploiement :– cloud privé : l'infrastructure du cloud est mise en œuvre uniquement pour une même organisation. Elle peut

être gérée par l'organisation ou par un tiers, sur site ou hors-site.– cloud communautaire : l'infrastructure du cloud est mise en œuvre pour plusieurs organisations qui ont les

mêmes centres d'intérêts (mission, stratégie, besoins en sécurité, en performances, en conformité, etc.). Ellepeut être gérée par l'organisation ou par un tiers, sur site ou hors-site. Les coûts sont partagés par un plusgrand nombre d'utilisateurs qu'avec un cloud privé, mais moins qu'avec un cloud public.

– cloud public : l'infrastructure du cloud est mise en œuvre pour tout le monde (organisations, individus, etc.).Elle appartient à une organisation qui vend ses services.

– cloud hybride : l'infrastructure du cloud est un mélange de deux des types de cloud mentionnésprécédemment (privé, public ou communautaire). Les types de cloud sont liés par l'utilisation de technologiesqui permettent la portabilité des applications et des données. Exemple : le cloud bursting (voir le chapitre 2.5sur le cloud privé page 17).

Dans notre contexte, il s'agit d'un projet de cloud privé de type IaaS avec déploiement sur site.A l'avenir, il sera éventuellement envisagé un élargissement communautaire à d'autres établissements d'enseignementsupérieur, voire une hybridation vers un cloud public.

2.2 HistoireRemontons il y a une dizaine d'années. Une époque lointaine. Les prémisses de ce qui deviendra le cloud computing.La bulle internet a éclaté quelques années auparavant, et seules les entreprises high tech les plus fortes ont résisté àcette épreuve.

Parmi ces entreprises, Amazon. Une librairie en ligne qui s'est rapidement diversifiée dans la vente de toutes sortes defournitures.Les infrastructures informatiques nécessaires pour satisfaire les millions d'utilisateurs d'Amazon sont phénoménales.Elles sont largement sur-dimensionnées pour résister aux périodes de pointe, comme Noël. Mais en temps normal,elle sont sous-utilisées.

Pour les dirigeants de l'entreprise, il s'agit là d'un investissement qui dort. Et ils ont trouvé le moyen de le réveiller.

L'idée est simple : tirer avantage d'une technique rodée, la virtualisation, pour rentabiliser les ressourcesinformatiques inutilisées en les louant à d'autres utilisateurs (simples particuliers, entreprises, administrations, etc.).

Xavier Buche Cloud universitaire avec OpenStack – CNAM Nord-Pas de Calais 15

De nombreux rivaux vont rapidement émerger et concurrencer Amazon dans ce qu'on appellera désormais le « cloudcomputing ».

Une conjonction de facteurs propices a conduit à l'essor des nuages :– l'augmentation des débits des réseaux– la diminution des coûts des capacités de traitement et de stockage– l'utilisation massive de la virtualisation– l'adoption croissante des architectures logicielles orientées services– l'informatique mobile/ubiquitaire11

2.3 Franchir le pas ? Hésiter ? Résister ?Aujourd'hui le cloud est un véritable phénomène. Tous les responsables informatiques se posent ou se sont posé laquestion. Que faire ? Comment réagir face à ce raz-de-marée ? Faut-il migrer toutes ses infrastructures dans le cloud ?Seulement une partie ? Quel type de cloud choisir ? Quel prestataire ? Quel contrat ?

Le problème est particulièrement complexe, et la solution dépend de nombreux facteurs : taille de l'entreprise,quantité de ressources informatiques utilisées, sensibilité au risque, à la sécurité, etc.

Pour ne rien simplifier, les avantages réels de l'informatique en nuage sont souvent noyés dans un argumentairemarketing stéréotypé, ou encore par le cloud washing, qui consiste à renouveler un service existant en ajoutant justeun mot-clef au message commercial. Ici, le mot-clef est cloud comme il pourrait être naturel sur une boîte d’œufs…

Dans un tel contexte, on peut comprendre que bien des décideurs hésitent à franchir le pas, et choisissent d'attendre.

2.4 Quelques éléments de réflexionCaractérisation financière et organisationnelle de l'informatique en nuage :

– le budget est focalisé sur le métier plutôt que sur l'infrastructure– paiement au fur et à mesure : la consommation en ressources liée aux activités de l'entreprise est répercutée

dans le budget au fur et à mesure– pas d'investissement initial : utilisation de ressources à la demande– modèle de consommation basé sur les services et sur l'usage : les coûts fixes deviennent variables, les

immobilisations (CAPEX12) se transforment en dépenses d'exploitation (OPEX13)– pas d'engagement à utiliser une quantité fixe de ressources : leur consommation change en temps réel– flexibilité de l'organisation : réponse rapide aux changements dans le volume ou la nature des besoins. Les

ressources s'ajustent rapidement à une demande fluctuante et imprévisible.– cœur de métier / cœur de compétences du fournisseur, économies d'échelle

– obtenir le matériel aux meilleurs prix et en optimiser l'usage– réduire la consommation d'énergie électrique et l'impact environnemental– employer moins de personnel, mais du personnel hautement spécialisé

– coûts interchangeables : exécuter un serveur longtemps coûte autant que de nombreux serveurs peu detemps. Ouvre de nouvelles perspectives et une réflexion innovante sur le partitionnement de problèmes àgrande échelle.

Caractérisation technique :– partage des ressources : grande efficience dans l'utilisation des ressources physiques– le grain de l'allocation est fin, en durée et en ressources– le consommateur n'a pas à gérer les pics et la croissance de la demande– ressources abstraites et non différentiées : le consommateur n'a pas à se soucier des détails techniques des

ressources utilisées, seuls comptent les résultats et les performances obtenues– briques de construction à assembler : les ressources et les services sont fournis sont la forme de briques de

construction individuelles facturées séparément– grâce au cloud, les décisions d'adaptation des infrastructures, qui étaient rares, manuelles, et effectuées par

11 les applications sont utilisables depuis n'importe où et quelque soit le matériel, souvent par une interface web12 CApital EXpenditure13 OPerational EXpenditure

Xavier Buche Cloud universitaire avec OpenStack – CNAM Nord-Pas de Calais 16

des administrateurs systèmes, peuvent être faites automatiquement et régulièrement

Inconvénients :– marketing omniprésent (surtout pour le SaaS) : « Quel est votre niveau de maturité ? Si vous n'êtes pas dans

le cloud, c'est que vous n'êtes pas encore mature », autrement dit, vous le serez un jour ou l'autre, mais vousaurez alors pris beaucoup de retard…

– réécriture des applications : vrai uniquement si on veut tirer tous les bénéfices du cloud– pas de contrôle direct sur les données stockées sur le cloud public, qui deviennent externes à l'organisation.

Problème de leur appartenance légale.– les contrats doivent être lus à la loupe, sous peine d'éventuelles mauvaises surprises– sécurisation du nuage : les fournisseurs mettent en œuvre des systèmes de sécurité avancés pour rassurer

leurs clients (ex : certification SAS 70)– coûts des ressources en nuage public : pas forcément intéressant pour les grands comptes

Le cloud computing est à la croisée des chemins entre plusieurs concepts d'actualité :– la convergence des infrastructures : consiste à grouper les composants du système d'information (serveurs,

baies de stockages, équipements réseaux, etc.) en un lieu unique et disposant de ressources adéquates(puissance électrique, capacités de refroidissement, espace, etc.). La gestion de ces ressources est centraliséeet constitue la base du déploiement du cloud computing.

– l'informatique ubiquitaire : la miniaturisation des composants électroniques a favorisé l'omniprésence determinaux numériques alternatifs au PC de bureau. Il en découle la possibilité, pour l'utilisateur, d'accéder aucloud de différentes manières, en tout lieu et à tout moment.

– les infrastructures programmables : SDN (Software Defined Network) et SDDC (Software Defined DataCenter) permettent d'automatiser la gestion des réseaux et des machines virtuelles. Par exemple, on peutainsi développer une infrastructure qui s'adapte automatiquement à la charge en ajoutant ou supprimant desnœuds de calcul ou de la bande passante réseau (auto-provisionning).

Le cloud computing est jeune. Les standards sont en cours de développement. Ils rendent les systèmes interopérableset portables. Plus que dans d'autres domaines, il faut prendre garde à l'enfermement propriétaire (lock-in) : les outils etprotocoles non standards empêchent la migration vers un autre système.

Le lock-in peut se situer à plusieurs niveaux :– plate-forme : lien entre le système de cloud et la plate-forme de virtualisation– donnée : si les données hébergées sur le cloud sont considérées comme étant la propriété de l'hébergeur, le

transfert de ces données hors de ce cloud peut être problématique– outils : le cloud propriétaire utilise des outils de gestion qui peuvent n'être compatible qu'avec son propre

système de cloud

Quelques cas d'utilisation générale des infrastructures en nuage :– sites et applications web– développement logiciel (tests de déploiement, environnement d'intégration continue, etc.)– formations– démonstrations– traitement de données

2.5 Le cloud privéComme il s'agit pour nous de mettre un œuvre un cloud privé, penchons-nous de plus près sur ses particularités.

Avantages :– maîtrise du système (supervision, contrôle)– maîtrise du niveau de sécurisation des infrastructures (sauvegardes, confidentialité des données, etc.)– sécurisation des données sensibles et des applications critiques– protection des données privées d'une utilisation commerciale, de l'espionnage, etc.– adaptation des fonctionnalités et du type de ressources physiques aux besoins– localité et donc performance et fiabilité des accès réseaux sur site– coût financier avantageux au dessus d'un certain seuil, d'une certaine taille critique de l'infrastructure

Xavier Buche Cloud universitaire avec OpenStack – CNAM Nord-Pas de Calais 17

Inconvénients :– L'organisation a à sa charge l'achat, la construction et le maintient de l'infrastructure du cloud.– Seules les grandes organisations ont les compétences et les moyens financiers nécessaires à la mise en place

d'un cloud privé.– Le modèle économique du cloud est basé sur la mutualisation des infrastructures. Si chaque organisation a

son propre cloud privé, les économies d'échelle sont réduites.

Le cloud bursting est un modèle de déploiement hybride dans lequel une application ou une machine virtuelle tournehabituellement dans un cloud privé. Lors de pics de demande (ex : un site de vente de jouets avant les vacances deNoël), les requêtes qui ne peuvent être traitées en local sont transférées à un cloud public. L'avantage est quel'organisation paye uniquement pour les ressources de traitement supplémentaires utilisées temporairement etexceptionnellement.

Le cloud bursting est recommandé pour les applications nécessitant beaucoup de performances, sans détenird'informations sensibles. Une application peut également être entièrement basculée sur le cloud public pour libérerdes ressources locales pour des applications critiques.

Le cloud bursting fonctionne mieux avec les applications qui ne dépendent pas d'une infrastructure complexe oud'une intégration avec d'autres applications ou composants internes à l'organisation. Enfin, il nécessite lacompatibilité des environnements d'exécution fournis par les clouds.

Voyons maintenant de plus près quelles sont les particularités du logiciel que nous avons choisi pour mettre en placenotre cloud privé.

Xavier Buche Cloud universitaire avec OpenStack – CNAM Nord-Pas de Calais 18

3 Présentation d'OpenStackOpenStack est LA solution de cloud IaaS sujet de toutes les discussions. Impossible qu'un spécialiste évoque le sujetdu cloud privé IaaS sans mentionner le fameux mot-clef dans la phrase qui suit. Cet ensemble logiciel a acquis unetelle popularité que « cloud privé » est désormais presque synonyme d'« OpenStack ».

Quelles sont les raisons d'une pareille audience ? En quoi ce succès est-il mérité ? Quels sont les atouts et lesfaiblesses de cette solution ?

3.1 Le soutien de l'industrieUne fois choisie, une plate-forme de cloud privé ne peut pas être remplacée facilement par une autre. L'expertise de samise en place, son administration, les développements qu'elle engendre nécessitent un investissement conséquent.La pérennité de cet engagement est un critère de décision essentiel. Et OpenStack constitue, de ce point de vue, lasolution libre offrant les meilleures garanties : la plupart des grands noms du secteur de l'informatique participent àce projet.

Voici les principaux acteurs actuels :– Rackspace : société d'hébergement focalisée sur le support et le service, Rackspace a fortement contribué au

développement du projet OpenStack et en est l'instigateur, avec la NASA 14, dans le but de le voir devenir unstandard du cloud, et que ce standard soit libre.

– Canonical : l'éditeur d'Ubuntu est un contributeur de la première heure. La plupart des développementsd'OpenStack se font sur cette distribution Linux.

– Red Hat : société la plus active dans le domaine du logiciel libre, Red Hat est à l'origine de l'une desdistributions Linux les plus anciennes. Même si elle a pris le train en marche, elle est l'un des plus groscontributeurs actuels au code d'OpenStack.

– SUSE : société allemande spécialisée dans le logiciel libre.– HP (Hewlett-Packard) : l'une des plus grandes multinationales du domaine de l'informatique, ainsi que le plus

grand fabricant d'ordinateurs et d'imprimantes.– IBM (International Business Machines) : entreprise mythique et géant de l'informatique s'il en est, IBM est

aujourd'hui un acteur majeur du service et de l'infogérance.– AT&T (American Telephone and Telegraph Company) : ce qu'il reste du démantèlement du géant américain

demeure l'un des principaux groupes de télécommunication.– Intel : le plus grand fabricant de semi-conducteur mondial est surtout connu pour ses processeurs x86.

A noter que VMware participe au projet OpenStack, alors qu'il propose un produit concurrent, Vcloud. Par contre,aucune trace de Microsoft parmi les contributeurs. Pour l'instant…

3.2 L'éclosion d'un standardEn Juillet 2010, lorsque Rackspace et la NASA se joignent pour lancer le projet OpenStack, ils ont une idée en tête :éviter à tout prix le verrouillage du marché du cloud par des technologies propriétaires et fermées [Annonce deRackspace].Le but : créer un standard pour l'accès au cloud et sa gestion. Un utilisateur devra pouvoir changer de fournisseursans réécrire ses applications.

Rackspace libère alors le code source de son système Cloud Files, qui deviendra le composant OpenStack ObjectStorage (Swift). Quant à la NASA, elle rend public le code de son projet Nebula, qui deviendra OpenStack Compute(Nova).Rapidement, de nombreux contributeurs rejoignent la communauté.

14 National Aeronautics and Space Administration

Xavier Buche Cloud universitaire avec OpenStack – CNAM Nord-Pas de Calais 19

3.3 Un nuage fait de briquesAinsi OpenStack naquit de l'union de Cloud Files avec Nebula, et de nombreuses autres briques s'y ajouteront au furet à mesure des versions. Chaque brique a une fonction particulière. Et cette fonction est implémentée par un, voireplusieurs programmes, au choix.

Cette forte modularité fait partie des principaux avantages d'OpenStack par rapport à ses concurrents. Elle permet àchaque opérateur de créer sa propre architecture, parfaitement adaptée à son environnement et ses cas d'utilisation.

3.3.1 Keystone (gestion des identités)Comme son nom le suggère, Keystone est la pierre angulaire de la sécurité. Il réalise (ou sous-traite) l'authentificationet assure les autorisations d'accès.

Il se base essentiellement sur trois « entités » :– l'utilisateur– le rôle– le projet

On peut simplifier la relation entre ces trois entités en une phrase : un utilisateur a un certain rôle dans un certainprojet.

Une ressource virtuelle (instance de machine, réseau, etc.) ne peut pas être associée directement à un utilisateur. Elleest associée soit à un projet, soit à un couple utilisateur-projet.

Des jetons à usage limité dans le temps, générés par Keystone lors de l'authentification, permettent d'identifier lesutilisateurs et de vérifier leurs droits d'accès.Ces droits d'accès sont configurés dans des fichiers qui associent chaque action à des rôles. Par exemple, on peutdéfinir que seul le rôle admin dispose du droit de créer un nouveau projet.

3.3.2 Glance (gestion des images)Glance est le composant qui gère les images de machine virtuelle. Autrement dit les modèles qui servent à créer desinstances de machine virtuelle.

3.3.3 Nova (gestion des instances)Nova constitue le cœur du cloud OpenStack. Glance lui fournit des images qu'il « transforme » en instances demachine virtuelle exécutées sur les différents nœuds de calcul.Nova est capable de contrôler les principaux hyperviseurs actuels, dont voici une liste non exhaustive :– KVM/QEMU– Xen– LXC– VMware Vcenter– Microsoft Hyper-V

3.3.4 Cinder (stockage en mode bloc)Cinder permet aux utilisateurs de se créer des volumes, sortes de disques durs externes virtuels qu'ils peuventattacher à une instance de machine virtuelle.

3.3.5 Swift (stockage en mode objet)Le mode de stockage objet est généralement utilisé dans les très grands environnement de stockage, où la quantitétotale de données se compte en centaines de téraoctets.

Xavier Buche Cloud universitaire avec OpenStack – CNAM Nord-Pas de Calais 20

En mode objet, contrairement au mode fichier, il n'y a pas de notion d'arborescence. Chaque objet est associé à desméta-données qui permettent de le retrouver.

Swift fournit un stockage distribué et redondant des objets sur une grappe15 de stockage.Le stockage objet d'OpenStack est parfois implémenté par Ceph, une alternative populaire à Swift.

3.3.6 Neutron (gestion des réseaux)Deux composants, au choix, peuvent être utilisés pour fournir un accès réseau aux machines virtuelles :

– Nova-network est le composant historique. Ses possibilité son limitées.– Neutron est la solution d'avenir. Il fournit aux utilisateurs la possibilité de gérer ses propres ressources

virtuelles (réseaux, routeurs, pare-feu, etc.)

3.3.7 Ceilometer (mesures)La définition du cloud indique que les services fournis doivent être mesurés. Cette mesure permet de facturerl'utilisation des ressources selon un processus en trois étapes :

– mesure– classification– facturation

Dans ce processus, Ceilometer assure uniquement la première étape. Il récolte régulièrement des données diversespour une exploitation ultérieure (temps processeur, mémoire, espace disque, etc.). Les autres étapes sont à la charge d'outils tiers.

3.3.8 Horizon (interface web de management)Horizon est l'application web faisant office de panneau de contrôle d'OpenStack. Les utilisateurs se connectent à cetteinterface pour gérer leurs machines virtuelles, leurs images, leurs réseaux, etc.Mais Horizon est plus qu'une simple interface, c'est aussi un cadriciel, basé sur Django16 [GABORY et al., 2013], que l'onpeut utiliser pour modifier facilement l'apparence du site et ses possibilités.

3.3.9 Heat (orchestration)Heat est un moteur d'orchestration de cloud. Derrière ces mots impressionnants, se cache un moyen pour l'utilisateurde prédéfinir et automatiser la gestion de son infrastructure virtuelle. A partir d'un modèle, il est possible de créerautomatiquement, par exemple, une architecture multitier composée de deux serveurs web connectés à internet et àtrois serveurs de base de données sur un réseau séparé.

15 aussi appelée cluster16 le cadriciel web du langage Python

Xavier Buche Cloud universitaire avec OpenStack – CNAM Nord-Pas de Calais 21

3.4 Et les autres ?OpenNebula, Nimbus, CloudStack, Stratuslab, Eucalyptus. Ces noms ne vous disent rien ? C'est normal : ce sont lesautres solutions libres de cloud privé, et elles sont toutes éclipsées par OpenStack. La raison ? En quelques années,OpenStack s'est imposé comme un standard de fait. Et même si certaines de ces alternatives, comme CloudStack, sonttrès abouties, il est peu probable qu'elles lui fassent un jour de l'ombre.

Dans l'avenir, les interactions entre des plates-formes de cloud différentes vont avoir tendance à se multiplier.L'infonuagique17 est donc un domaine de l'informatique qui, à l'instar des réseaux, favorise l'émergence detechnologies convergentes. En d'autres termes, OpenStack risque fort, dans quelques années, d'être au cloudcomputing ce que le protocole IP est au réseau Internet : incontournable.

Dans ces conditions, les produits commerciaux comme VMware Vcloud ou Microsoft Azure ont un réel handicap, carils tendent à emprisonner leurs clients dans l'utilisation de technologies (logiciels, protocoles, API) qui fonctionnentuniquement dans un cercle limité au bon vouloir du fournisseur. Et une fois à l'intérieur de ce cercle, difficile d'ensortir… (voir le paragraphe sur le lock-in dans l'introduction, chapitre 2.4).

17 C'est ainsi que nos amis québécois traduisent le cloud computing.

Xavier Buche Cloud universitaire avec OpenStack – CNAM Nord-Pas de Calais 22

Figure 2 : schéma conceptuel (source : docs.OpenStack.org)

4 Mise en œuvreLes éléments rapportés dans ce chapitre ne sont volontairement pas exhaustifs. L'objectif est de focaliser votreattention sur les points clefs et de vous faire part de mon expérience acquise lors des différentes phases quiconduisent à la mise en production d'une plate-forme de cloud OpenStack. En particulier, plutôt que de faire uneprésentation générale à l'intérêt limité, j'insiste sur les raisons qui nous ont poussés à faire tel ou tel choix, ainsi quesur les nombreuses pierres d'achoppement auxquelles nous avons été confrontés. Autrement dit, mon but est demettre l'accent sur certains détails, et le diable qui s'y cache…

4.1 Choix du matérielLe cloud peut maintenant prendre substance. Mais avant cela, il nous faut un matériel adapté. Et les choix en lamatière ne sont pas aisés, car au-delà des aspects objectifs et des critères mesurables, il y a l'empirisme et lasubjectivité.

Heureusement, l'Université Lille 1 adhère à un marché public national d'équipements informatiques coordonné parl'AMUE (l'Agence de Mutualisation des Universités et Établissements) : le marché matinfo, qui offre, à mes yeux, aumoins deux avantages :– un choix restreint à un matériel de qualité présélectionné par un comité d'experts– une offre de tarifs particulièrement agressive due au caractère concurrentiel et à la taille de ce marché, dont

le chiffre d'affaire se monte à environ 30 millions d'euros par an, et ce uniquement pour la partieinfrastructure (serveurs, baies de stockage, etc.)

Les choix se feront essentiellement avec comme objectif d'atteindre le rapport le plus élevé entre, d'un côté, puissancede calcul, mémoire, capacités de stockage et capacités réseaux, et de l'autre, le coût total de l’infrastructure matérielle.Quant aux décisions de nature plus subjective, elles se baseront sur des benchmarks et autres expériences ou exemplesd'infrastructures comparables à la nôtre et documentées sur des sites web spécialisés. En ce domaine, le guide desopérations d'OpenStack [Guide opérationnel] est un bon point de départ.

4.1.1 Les besoinsLes besoins ont été définis en fonction de l'architecture OpenStack choisie (voir le chapitre 4.2 sur la configuration dela plate-forme), mais aussi de la capacité budgétaire des participants au projet18 et de leur volonté d'y prendre part. Le but : mettre en place un embryon de plate-forme permettant d'accueillir quelques centaines de machines virtuelles.

Le matériel prévu sera ainsi constitué de :– 2 contrôleurs redondants, qui feront également office de nœuds de routage : les capacités en mémoire et en

calcul ne sont pas particulièrement importantes, mais il faut qu'elles soient amplement suffisantes pour évitertout goulet d'étranglement à ce niveau.

– 4 nœuds de calcul, qui exécuteront les instances de machine virtuelle, et dont la puissance de traitement et laquantité de mémoire seront à déterminer judicieusement

– 1 baie de stockage centralisé fournie par l'UFR de mathématiques– 1 commutateur pour les liaisons internes à la plate-forme, avec une bande passante de 10 Gb/s. Pour la

redondance, un second commutateur identique est prévu dans un deuxième temps.

4.1.2 Les serveurs

4.1.2.1 Rack ou bladeLe fournisseur du marché des infrastructures est actuellement Dell. Les serveurs de cette marque se déclinent enplusieurs formats :– tour : ce format ne convient pas car il ne s'intègre pas dans les armoires (appelées racks) du centre de

données du CRI

18 Le FIL, l'UFR de mathématiques et le CRI ont investi environ à parts égales.

Xavier Buche Cloud universitaire avec OpenStack – CNAM Nord-Pas de Calais 23

– montable en rack : le format usuel des serveurs installés dans les armoires standards des centres de données– modulaire (aussi appelé blade) : ce format consiste à installer un châssis « rackable » intégrant des capacités

d'entrée/sortie (et parfois de stockage), dans lequel viendront s'emboîter des serveurs (appelés lames) auformat réduit

Le format modulaire est conçu pour intégrer, dans un minimum d'espace, de nombreux nœuds de calcul. Les serveursrackables prennent plus de place, mais ils sont tout à fait autonomes et peuvent être déplacés individuellement dansun autre rack, par exemple, ce qui rend leur utilisation plus flexible. A l'inverse, les lames des châssis modulaires sontliés à une technologie et un format d'une pérennité limitée à quelques années, alors que le format 19 pouces des rackset baies de brassage est un standard qui date des années 60.D'autre part, les serveurs en rack embarquent généralement des possibilités d'extension des entrées/sorties plusimportantes, ce qui est un réel avantage dans notre cas, où de nombreux réseaux seront utilisés, comme nous leverrons par la suite.Enfin, le coût d'achat d'une infrastructure complète basée sur des serveurs en rack est sensiblement moins importantque son équivalent modulaire.

Actuellement, et suite à la mouvance de la virtualisation des années 2000, la salle blanche du CRI n'est pasrestreinte en espace. Le choix s'orientera donc vers des serveurs montés en rack.

4.1.2.2 La gamme Dell PowerEdgeLa gamme des serveurs rackable Dell PowerEdge se décline en plusieurs modèles :– R220 : le bas de gamme est limité à 32 Go de mémoire vive et 1 processeur, ce qui est bien trop limité pour

notre usage– R420 : équipé de la gamme de processeurs Intel Xeon E5-24xx ; avec le jeu des options (cartes ethernet

10Gbps, alimentation redondante, etc.) le R420 n'est pas moins onéreux que son grand frère le R620– R620 : équipé de la gamme de processeurs Intel Xeon E5-26xx légèrement plus performante que le E5-24xx,

le R620 dispose, dans son format 1 U19, d'une capacité d'extension de 2 slots PCI express20. Dans sa version2 U, cette capacité passe à 3 slots, mais aussi 10 emplacements pour disque dur 2,5 pouces, ce qui n'a pasd'utilité dans notre cas, où le stockage sera centralisé.

– R720 : au format 2 U, celui-ci dispose de la plus grande flexibilité avec de nombreuses possibilités d'extension.Exemple : 7 emplacements PCI express.

– R820 : jusqu'au R720, on ne dépasse pas les 1000 euros pour une machine sans options. Avec le R820, on entredans la gamme des serveurs de calcul avec quatre processeurs. Le prix s'en ressent puisque qu'on passe à2000 euros sans option et avec deux processeurs et on se rapproche vite des 8000 euros, toujours sans option,avec quatre processeurs respectables et 16 petits Go de mémoire vive.

– R920 : au format 4 U, le serveur R920 allie des capacités d'extension encore plus grandes, avec une gamme deprocesseurs quadri-sockets encore plus performante

En résumé, le R220 n'est pas assez performant, les R820 et R920 sont trop chers, le R420 n'a pas d'atout, le R720 prendplus de place mais il est plus extensible que le R620.

La question est donc celle du compromis : faut-il sacrifier l'espace à la capacité d'extension ?La réponse est non, pour deux raisons :– à priori, la capacité d'extension du R620 est suffisante– dans un centre de données, consommer moins d'espace, c'est aussi réduire la taille des infrastructures qui

entourent les serveurs (nombre et taille des couloirs froids, des systèmes de climatisation, etc.) et l'énergienécessaire à leur fonctionnement

Notre choix se focalisera donc sur le Dell PowerEdge R620.

19 Le format des serveurs rackable se mesure par leur hauteur en unités (ou U) correspondant à 1,75 pouces. 20 la norme actuelle des cartes d'extension

Xavier Buche Cloud universitaire avec OpenStack – CNAM Nord-Pas de Calais 24

4.1.2.3 Choix du processeurL'idée étant toujours de trouver le juste milieu entre puissance et prix, j'ai tenté un calcul rationnel du rapportperformance/coût des processeurs disponibles sur le R620, en m'aidant du site www.cpubenchmark.net [Benchmarks].

Le résultat est favorable au processeur Intel E5-2620v2 à 6 cœurs hyper-threads21, soit, avec deuxprocesseurs, 24 cœurs vus par le système d'exploitation.

4.1.2.4 Quantité de mémoire viveLes processeurs (ou plutôt les cœurs) peuvent facilement être partagés entre les processus, et donc entre les instancesde machine virtuelle. Les systèmes d'exploitation multi-tâches existent depuis les années 60, et le sont aujourd’huiquasiment tous.Par contre, le principe même de la virtualisation étant d'isoler les machines virtuelles les unes des autres, chaqueinstance doit disposer de son propre espace mémoire, même s'il n'est pas entièrement utilisé.Certains hyperviseurs proposent des moyens de limiter ce gâchis, mais ces mécanismes consomment du tempsprocesseur. Il vaut donc mieux ne pas quantifier la mémoire en se basant sur les possibilités logicielles d'en optimiserl'usage.

En définitive, nous devons estimer la quantité de mémoire vive nécessaire en fonction du nombre maximum demachines virtuelles au-delà duquel les processeurs risquent la saturation, ainsi qu'en fonction de la consommationmoyenne de mémoire par les machines virtuelles. Voilà un probant exemple de choix singulièrement subjectif !

Par expérience, mes collègues qui administrent des systèmes de virtualisation, comme moi-même, constatons que laconsommation CPU22 moyenne est généralement faible (sauf utilisation particulière, comme le calcul scientifique), etque le facteur limitant est presque toujours la mémoire, qui est sous-dimensionnée la plupart du temps.La quantité maximale de mémoire adressable par le processeur choisi est de 256 Go. Basons notre réflexion sur cettevaleur.

Les hyperviseurs récents ont tous la capacité de « migrer » une machine virtuelle d'une machine hôte vers une autre.En cas de panne d'un hôte, il est ainsi possible de déplacer les machines virtuelles qui s'y trouvaient vers d'autresnœuds fonctionnels. C'est d'ailleurs l'un des nombreux avantages de la virtualisation.Dans ce cas de figure, les nœuds de calcul restants doivent disposer de suffisamment de ressources pour accueillir lesexilées. La quantité de mémoire laissée libre sur chacun des quatre nœuds doit donc être de 256 / 4 = 64 Go, et laquantité maximale de mémoire utilisée de 256 - 64 = 192 Go. Ce problème s'atténuera avec les nœuds supplémentairesqui s'ajouteront au cluster actuel à mesure du succès de notre projet.En considérant qu'en moyenne chaque machine virtuelle utilisera 2 Go de mémoire, et en négligeant la consommationde mémoire par la machine hôte, il y a aura donc au maximum 96 machines virtuelles sur chaque machine physique.Dans ce cas, chaque cœur virtuel exécute environ quatre instances, ce qui n'est probablement pas excessif. Le seul

21 L'hyper-threading est une technologie matérielle permettant de partager de manière efficiente le temps processeur d'un cœur de manière àcréer deux cœurs virtuels.

22 Central Processing Unit

Xavier Buche Cloud universitaire avec OpenStack – CNAM Nord-Pas de Calais 25

Figure 3 : un serveur Dell PowerEdge R620 (source : www.dell.com)

moyen de le savoir sera d'analyser aussi finement que possible l'utilisation des ressources par les utilisateurs (voir lechapitre 4.9 sur Ceilometer et celui sur la supervision). Précisons que ce que feront les utilisateurs des ressourcesmises à leur disposition n'est pas prédictible et constitue, par conséquent, une inconnue majeure.

En conclusion, et malgré l'inévitable imprécision du calcul, 256 Go de mémoire vive pour les nœuds decalcul est un chiffre raisonnable.

Pour les contrôleurs, sur lesquels tournent la plupart des services d'OpenStack et des outils tiers, nousavons retenu une quantité de 16 Go de RAM23. Selon la documentation d'OpenStack [guide des

opérations], 12 Go de mémoire sont recommandés pour une petite installation. Précisons que, en cas de pénurie, l'ajout de mémoire additionnelle est facile à réaliser, même si elle implique l'arrêt dela machine.

4.1.3 Le stockageUn stockage centralisé simplifie beaucoup l'architecture de la plate-forme et offre de nombreux avantages qui serontexpliqués dans le détail tout au long des chapitres qui concernent la configuration d'OpenStack.Or, il se trouve que l'UFR de mathématiques met à disposition de notre projet un matériel de première qualité : unebaie de disques Netapp, modèle FAS2240. Cette baie de type NAS24 permettra de centraliser facilement et efficacementles images et les instances de machine virtuelle, au minimum.

4.1.4 Le réseauComme nous le verrons plus loin dans le chapitre 4.6 sur le paramétrage du réseau, quelle que soit l'architecturechoisie, la plate-forme nécessite de nombreux réseaux (réseau des machines virtuelles, réseau de communication desmodules d'OpenStack, réseau de stockage, de supervision…).

4.1.4.1 Les interfaces ethernetLe nombre et la bande passante des interfaces ethernet équipant les nœuds de calcul, les contrôleurs et le switchdoivent être déterminés avec soin. Mais avant cela, c'est le modèle de ces interfaces qu'il faut choisir, et ce choix n'estpas si évident qu'il en à l'air…

Sur ses serveurs PowerEdge du marché public, Dell propose deux marques.

BroadcomBroadcom est l'option par défaut : moins onéreuses, les interfaces de cette marque ne sont pas pour autant moins bienpourvues en fonctionnalités. L'une d'elle permet de prendre en charge, au niveau matériel, l'analyse des entêtesiSCSI25. Ce qui pourrait améliorer les performances d'accès à la baie de disques et surtout décharger les processeurs decette tâche, à condition que ce protocole soit utilisé.

IntelIntel offre des interfaces plus chères, mais aussi réputées plus performantes, avec des pilotes plus stables. Pourtant ledéchargement iSCSI n'est proposé sur aucun des modèles de cette marque. J'ai donc cherché à en comprendre laraison.Un document d'Intel [Intel iSCSI] m'a convaincu de leur raisonnement : le protocole iSCSI étant transporté par leprotocole TCP, un déchargement iSCSI implique que la pile TCP/IP soit implémentée dans le pilote de l'interfaceréseau. Or la couche TCP/IP est essentielle sur de nombreux plans (performance, fiabilité, sécurité), et celle du noyauLinux est connue pour sa grande qualité. On viendrait donc remplacer un code ouvert qui a prouvé sa robustessependant des années par le code propriétaire, donc fermé, d'un pilote plus ou moins bien adapté au système et dont laqualité reste à démontrer.J'ai par ailleurs déjà eu l'occasion d'activer sous Linux le déchargement iSCSI sur une interface Broadcom, etl'opération s'est avérée tout sauf triviale…

23 Random Acces Memory, un autre nom pour la mémoire vive, ou encore la mémoire de travail.24 Network Access Storage : les baies de stockage de ce type fournissent, en plus d'un accès en mode bloc par des protocoles tels que iSCSI, un

accès en mode fichier par des protocoles comme NFS, CIFS ou WebDAV.25 Internet Small Computer System Interface

Xavier Buche Cloud universitaire avec OpenStack – CNAM Nord-Pas de Calais 26

Pour les interfaces 10 Gb/s, la différence de tarif étant faible, on privilégiera Intel. Quant aux cartesd'extension 1 Gb/s, nous considérons la différence de coût trop importante (elle se monte à environ 300euros pour 4 ports).

4.1.4.2 Le commutateurLe choix du commutateur est également réduit par les marchés publics : Cisco est le fournisseur du marché du réseau.Cependant, dans le cadre d'une infrastructure comme une grappe de serveurs ou une plate-forme comme la nôtre parexemple, il est possible de s'équiper par le biais du marché infrastructure détenu par Dell.

Grosso-modo, dans la gamme des switches 10Gb/s, les modèles Cisco sont environ deux fois plus chers que l'entrée degamme Dell Powerconnect, qui satisfera nos besoins. Nous nous focalisons donc sur le N4032.

La technologie de transmission 10 GbE26 se décline en une série de normes. Ces normes définissent en particulier lesupport de transmission et la connectique utilisés. Pour simplifier, le choix se résume aux normes suivantes :– 10Gbase-T utilise les classiques et ultra-répandus ports RJ45 et câbles à paires torsadées. De plus il est

compatible avec la norme 1Gbase-T, ce qui est très pratique quand on a, comme nous, un mix d'interfaces1 Gb/s et 10 Gb/s. L'inconvénient est la consommation électrique, qui est de l'ordre de quelques watts pourune interface.

– SFP+ consomme moins d'énergie électrique, et la latence27 de transmission est plus faible. Le prix est, enmoyenne, légèrement voire sensiblement plus élevé que le 10Gbase-T.

La méthode de calcul de la latence peut varier en fonction du nombre de couches du modèle OSI 28 traversées par lesdonnées. Les documents constructeurs indiquent des valeurs calculées au niveau du matériel, qui sont de l'ordre de0,1 micro-secondes pour le SFP+ et de 10 à 20 fois plus pour le 10Gbase-T, ce qui laisse penser que les performancesglobales seront nettement meilleures avec le SFP+.Or, un simple benchmark de latence avec netperf et une carte 10Gbase-T (Intel X540) révèle que ce n'est pas le cas.

En utilisant TCP :netperf -H compute2 -l 1 -b 1 -w 1000 -t TCP_RR -- -m 512 -O MEAN_LATENCY

MIGRATED TCP REQUEST/RESPONSE TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to compute2 () port 0AF_INET : demo : first burst 0

Mean Latency Microseconds

76.73

En utilisant UDP :netperf -H compute2 -l 1 -b 1 -w 1000 -t UDP_RR -- -m 512 -O MEAN_LATENCY

MIGRATED UDP REQUEST/RESPONSE TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to compute2 () port 0AF_INET : demo : first burst 0

Mean Latency Microseconds

69.15

netperf calcule la latence de la couche application de l'émetteur à la couche application du destinataire, ce qui serapproche davantage des cas d'usage courants. Et il nous indique que cette latence est de l'ordre de 70 micro-secondes,devant lesquels le gain de 1 à 2 micro-secondes du SFP+ est insignifiant.

L'impact du SFP+ sur les performances, par rapport au 10Gbase-T peut donc être négligé. Dans ce cas le10Gbase-T sera privilégié pour sa compatibilité avec le gigabit ethernet.

Pour information, la latence est nettement plus importante sur une interface gigabit ethernet :

26 Gigabit Ethernet27 Dans le domaine des télécommunication, la latence est le temps entre l'envoi d'un signal (une donnée, un bit) et sa réception par le

destinataire.28 Open Systems Interconnection : le modèle en couche sur lequel se basent toutes les architectures réseaux

Xavier Buche Cloud universitaire avec OpenStack – CNAM Nord-Pas de Calais 27

En utilisant TCP :netperf -H 192.168.3.52 -l 1 -b 1 -w 1000 -t TCP_RR -- -m 512 -O MEAN_LATENCY

MIGRATED TCP REQUEST/RESPONSE TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 192.168.3.52 ()port 0 AF_INET : demo : first burst 0

Mean Latency Microseconds

121.05

En utilisant UDP :netperf -H 192.168.3.52 -l 1 -b 1 -w 1000 -t UDP_RR -- -m 512 -O MEAN_LATENCY

MIGRATED UDP REQUEST/RESPONSE TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 192.168.3.52 ()port 0 AF_INET : demo : first burst 0

Mean Latency Microseconds

112.23

4.2 Installation et adaptation à l'environnementA présent que les choix matériels ont été faits, nous allons commencer à entrevoir le cœur de notre problème. Maisauparavant, il nous faut préparer un terrain propice à l'éclosion de notre nuage…

La ligne directrice des nombreuses décisions qui seront exposées dans ce chapitre et ceux qui suivent consiste àprivilégier les solutions les plus éprouvées, les plus populaires, les plus utilisées, pour bénéficier du support de la pluslarge communauté.

Xavier Buche Cloud universitaire avec OpenStack – CNAM Nord-Pas de Calais 28

Figure 4 : infrastructure matérielle (sources : www.dell.com, www.netapp.com)

commutateurs

nœuds de calcul

contrôleurs

baie de disques

4.2.1 Le réseau

– Le réseau de gestion nous permet d'accéder aux machines pour les configurer, via le protocole SSH 29. Uneinterface de gestion supplémentaire appelée iDRAC (integrated Dell Remote Access Controller) nous permet,en plus, un accès hors bande30 au paramétrage matériel des serveurs et à une console qui simule uneconnexion locale.

– Le réseau interne OpenStack relie les processus OpenStack qui tournent sur les différentes machines.– Le réseau des machines virtuelles fait transiter les données entre les instances de machine virtuelle et vers

l'extérieur.– Le SAN (Storage Area Network) permet aux nœuds de la plate-forme d'accéder à leurs données situées sur la

baie de disques.

Mon collègue Sébastien Fillaudeau s'est chargé, après avoir physiquement installé les machines dans le centre dedonnées du CRI, de les interconnecter selon ce schéma. Il a ensuite configuré le commutateur de manière à ce quechaque réseau soit cloisonné dans son propre domaine de diffusion.

4.2.2 Les outils TiersPour que prenne forme un nuage OpenStack, quelques ingrédients sont nécessaires.

4.2.2.1 Le système d'exploitationOpenStack peut être installé sur la plupart des systèmes d'exploitation, y compris Windows. Cependant, ladistribution Linux Ubuntu est la plus populaire. Sans doute parce que Canonical, l'éditeur de cettedistribution, a participé très tôt au projet OpenStack, et que la majorité des développeurs utilisent, paraît-il, cette distribution. Étant donné, en outre, que je connais déjà ce système, c'est un choix qui s'impose. Sébastien Fillaudeau a pris soin d'installer la dernière version « serveur » d'Ubuntu, nom de code Trusty

(14.04), avec un support de type LTS31.

29 Secure Shell est le protocole d'accès à distance standard des systèmes de type Unix.30 En théorie, sur un réseau séparé. Dans notre cas, seule l'interface est séparée.31 Le Long-Term Support garantie les mises à jour du système pendant une période de cinq ans.

Xavier Buche Cloud universitaire avec OpenStack – CNAM Nord-Pas de Calais 29

Figure 5 : architecture générale du réseau

noeuds de calcul contrôleurs

stockage

SAN (10Gb/s)

gestion / supervision

réseau interne openstack

réseau des machines virtuelles

réseau public

réseau privé

4.2.2.2 Le SGBDParmi les outils tiers utilisés par le projet OpenStack, il y a le système de gestion de bases de données.Le SGBD32 est un élément très sensible de l'infrastructure. Tous les composants d'OpenStack reposent sur des bases dedonnées pour le stockage d'informations comme l'état des instances de machine virtuelle (Nova), la description desimages (Glance) ou les ressources consommées par un utilisateur (Ceilometer).Le choix du SGBD est donc crucial.

De plus, sur une plate-forme qui doit être fonctionnelle en quasi permanence, l'accès aux bases de données doitpouvoir être rétabli rapidement en cas de catastrophe ou de panne physique du contrôleur.– contre la panne physique : un second contrôleur est un réplicat temps réel du premier. Si le premier

contrôleur tombe en panne, le deuxième peut prendre le relais rapidement et sans aucune perte de données– contre la catastrophe : si les deux contrôleurs tombent en panne au même moment (à cause d'un incendie en

salle blanche, par exemple), les bases de données peuvent être récupérées à partir de la sauvegarde réalisée lanuit précédente sur un autre site du campus

Si on envisage, comme c'est notre cas, un contrôleur secondaire pour assurer une reprise sur panne rapide en cas dedéfaillance du premier, il est nécessaire d'étudier les capacités de mise en grappe du SGBD. Autrement dit, installerplusieurs nœuds de base de données avec une réplication en temps réel.

MySQL est fiable, performant, facile d'utilisation et surtout extrêmement répandu. C'est par ailleurs, et deloin, le SGBD le plus utilisé sur les plates-formes OpenStack. Sans la contrainte du clustering, le choixs'oriente donc naturellement vers ce SGBD. Avec cette contrainte, c'est encore davantage le cas.Le couple MariaDB33 + Galera est en effet une solution très avancée de clustering multi-maître34. Après presque un an d'utilisation et de tests avec de multiples redémarrages des machines, nous n'avons

constaté aucun problème et nos nombreuses bases de données sont restées cohérentes. Cela dit, précisons que lesécritures ne se font jamais sur plusieurs nœuds simultanément.

Mon collègue Mohammed Khabzaoui s'est occupé de configurer le SGBD. Il faut installer le paquetage avec lacommande :

apt-get install mariadb-galera-server

Il faut ensuite ajouter ces lignes dans le fichier de configuration de MariaDB (/etc/mysql/conf.d/mariadb.conf) :

# Galera Provider Configuration

# chargement du module Galera

wsrep_provider=/usr/lib/galera/libgalera_smm.so

# Galera Cluster Configuration

wsrep_cluster_name="my_db_cluster"

# les adresses IP de tous les nœuds du cluster

wsrep_cluster_address="gcomm://10.1.1.10,10.1.1.20,10.1.1.51"

# Galera Synchronization Congifuration

wsrep_sst_method=rsync

# Galera Node Configuration

# l'adresse IP et le nom du nœud local

wsrep_node_address="10.1.1.51"

wsrep_node_name="compute1"

32 Système de Gestion de Bases de données : gère et fournit un accès à des bases de données33 MariaDB est un fork de MySQL, mais il en est très proche.34 Configuré avec trois nœuds (nos deux contrôleurs et le premier nœud de calcul) la réplication est multidirectionnelle : on peut écrire sur

n'importe quel nœud, la modification est aussitôt répliquée sur les deux autres.

Xavier Buche Cloud universitaire avec OpenStack – CNAM Nord-Pas de Calais 30

Voyons plus précisément comment fonctionne la réplication. Plusieurs méthode permettent de répliquer les données :– synchrone : les données écrites sur un nœud le sont également sur tous les autres nœuds du cluster, et ce de

manière garantie. Les bases de données sont cohérentes et il n'y a pas de perte de données quand un nœudtombe en panne.La réplication synchrone est habituellement implémentée en utilisant un commit en 2 phases ou un systèmede verrous distribués, qui sont particulièrement lents et complexes. La réplication synchrone est, de ce fait,peu utilisée.

– asynchrone : aucune garantie n'est fournie sur le délai de propagation des modifications d'une base de donnéesur tous les nœuds du cluster. Si un nœud tombe en panne, les dernières modifications peuvent être perdues.

– synchrone « amélioré » ou réplication basée sur la certification : allie les avantages des méthodes synchroneset asynchrones, tout en limitant leurs inconvénients

Galera est une librairie utilisable par n'importe quel SGBD compatible avec l'API WSREP (Write Set REPlication). Ilimplémente la réplication basée sur la certification. Détaillons quelques-unes de ses propriétés.

La réplication intervient au moment du commit de la transaction. Les données modifiées de la base sont alorstransmises aux autres nœuds de la grappe.

Le problème du split-brain se produit quand la liaison entre deux nœuds est coupée. Sur ces nœuds, les commandes delecture fonctionnent, mais les commandes d'écriture renvoient l'erreur suivante :

ERROR 1047 (08S01): WSREP has not yet prepared node for application use

Pour éviter le split-brain, un calcul de majorité est réalisé : seuls les nœuds situés dans le composant primaire restentaccessibles en écriture. Pour qu'un composant soit primaire, il doit contenir la majorité des nœuds. Dans le cas d'un cluster de deux nœuds, la majorité ne peut jamais être obtenue. Les deux serveurs sont donc bloquésen écriture. Pour éviter ce problème, il faut un nombre de nœuds impaire et supérieur ou égal à trois.

Dans le cas d'un cluster à trois nœuds :– si un nœud est injoignable, il est bloqué en écriture, mais les deux autres nœuds restent fonctionnels– si les trois nœuds se retrouvent isolés les uns des autres, par exemple suite à la panne des commutateurs

internes, alors ils seront tous bloqués en écriture. Mais cela n'a pas d'incidence sur le fonctionnementd'OpenStack, car dans ce cas de figure le réseau des services est lui aussi coupé.

Sur un cluster à deux nœuds, il est possible de désactiver le calcul de majorité avec la directive suivante :pc.ignore_quorum=true

Ou de laisser les nœuds isolés accessibles en écriture :pc.ignore_sb=true

En cas de split-brain, les deux nœuds, même isolés l'un de l'autre, restent accessibles en lecture/écriture. Les bases dedonnées peuvent donc diverger. Par exemple, le même enregistrement peut prendre des valeurs différentes. Une foisla panne corrigée et le cluster recréé, la resynchronisation des bases de données est manuelle et complexe et elleinduit une perte de données.

Autre avantage d'avoir un troisième nœud : les sauvegardes peuvent se faire facilement sur ce nœud, sansinterrompre les services des contrôleurs.

Quand un nœud rejoint le cluster, il envoie une requête de synchronisation des données à un autre nœud. Cetterequête peut être de deux types :

– SST (Snapshot State Transfer) : copie toute la base de données ou une sous-partie– IST (Incremental State Transfer) : copie uniquement les différences entre la base de données à jour située sur

le cluster et celle du nœud qui se joint au cluster

Pour démarrer un nouveau cluster, il faut lancer la commande suivante sur le premier nœud :service mysql start --wsrep-new-cluster

Puis sur les nœuds qui viennent s'ajouter au cluster :service mysql start –wsrep_cluster_address=gcomm://adresse_ip_locale

Xavier Buche Cloud universitaire avec OpenStack – CNAM Nord-Pas de Calais 31

Pour connaître le nombre de nœuds opérationnels, on lance la commande SQL35 suivante :SHOW STATUS LIKE 'wsrep_cluster_size%';

qui renvoie :+--------------------+-------+

| Variable_name | Value |

+--------------------+-------+

| wsrep_cluster_size | 3 |

+--------------------+-------+

Faisons quelques essais sur trois nœuds : controller1, controller2 et compute1– j'isole controller2 en coupant l'interface réseau : ifdown em3– je crée une table sur compute1 : create table essai1 (id int) ;– la table est présente sur compute1 et controller1 : show tables ; renvoie essai1– la table n'est pas visible sur controller2 : show tables ; ne renvoie pas essai1– je tente de créer une table sur controller2 : create table essai2 (id int) ; renvoie l'erreur

« ERROR 1047 (08S01): WSREP has not yet prepared node for application use »

– je répare la coupure réseau : ifup em3– la base de données est synchronisée quelques secondes plus tard : show tables ; renvoie essai1

4.2.2.3 La gestion du tempsLes machines de la plate-forme OpenStack doivent impérativement être synchrones. Le protocole NTP (NetworkTime Protocol) est donc utilisé pour garantir que toutes les machines sont en permanence à la même heure. Lacomplexité de ce protocole est inversement proportionnel à la facilité de sa mise en œuvre.

L'installation se fait par un :apt-get install ntp

Et sa configuration en indiquant à la directive server du fichier /etc/ntp.conf le nom ou l'adresse d'un serveur de temps(celui de l'université dans notre cas).

4.2.2.4 Le bus de données logicielChaque brique du cloud OpenStack se base sur un certain nombre de processus lancés simultanément, chacun ayantun rôle particulier. Ces démons communiquent entre eux via un bus de données logiciel, appelé aussi queue demessagerie, en utilisant le protocole AMQP (Advanced Message Queuing Protocol).

Ce protocole est implémenté par plusieurs logiciels, au choix : les principaux sont RabbitMQ, Qpid et ZeroMQ.Dans le cadre de l'utilisation basique que nous en ferons, il n'y pas de différence notable entre ces programmes.Généralement, le choix est fonction de la distribution Linux utilisée. Par exemple, les distributions à base de Red Hatutilisent Qpid, alors que sur Ubuntu, on utilise habituellement RabbitMQ.

Après l'installation, qui se fait avec la simplicité d'un :apt-get install rabbitmq-server

la configuration consiste uniquement à créer un compte qui sera ensuite utilisé par les composants d'OpenStack pouraccéder à la queue.

Exemple de fonctionnement : un utilisateur envoie une requête à un point d'accès à l'API (appelé endpoint)d'un service OpenStack. Le serveur d'API vérifie l'identité de l'utilisateur et s'il est autorisé à effectuercette requête. Si oui, la tâche est envoyée sur le bus de messagerie à destination du processus concerné.Ce dernier fait ce qu'on lui demande et renvoie le résultat au serveur d'API, qui renvoie le résultat àl'utilisateur.

35 Structured Query Language : langage servant à effectuer des requêtes sur des bases de données relationnelles

Xavier Buche Cloud universitaire avec OpenStack – CNAM Nord-Pas de Calais 32

4.2.3 Dans le vif du sujetComme il a été expliqué dans le chapitre de présentation d'OpenStack, cette application repose sur un projetfédérateur regroupant un certain nombre de « briques » (Nova, Keystone, etc.). Chaque brique, que j'appelle souvent« composant », remplit une fonction bien identifiée. Au total, plusieurs milliers de directives permettent de configurerl'ensemble dans ses moindres détails.

4.2.3.1 Les versions d'OpenStackLe rythme de sortie des nouvelles versions d'OpenStack est rapide. Le projet évolue vite et de nouvellesfonctionnalités apparaissent régulièrement.Au moment de la mise en place de notre configuration, en septembre 2014, la version courante était la dénomméeIcehouse et c'était également la version fournie sur notre système Linux. Nous avons donc choisi cette version et nousbénéficions donc du support LTS de la distribution Ubuntu.

4.2.3.2 Les servicesAvant d'explorer chacun des composants, voyons au préalable les éléments qui leurs sont communs.

Le catalogueOn accède aux services correspondant à chaque brique d'OpenStack par des API36 RESTful37 basées sur le protocoleHTTP38.Un service est défini par une API qui fournit l'ensemble des actions possibles et des comportements de ce service.Chaque API est implémentée par un composant d'OpenStack. Par exemple, l'API compute est implémentée par Novaet l'API networking est implémentée par Neutron.

Voici ce que renvoie la commande keystone catalog à un utilisateur authentifié :Service: image

+-------------+----------------------------------+

| Property | Value |

+-------------+----------------------------------+

| adminURL | http://controller1:9292 |

| id | a28fac59bd0548f8942e09b5508c41ce |

| internalURL | http://controller1:9292 |

| publicURL | http://cloud.univ-lille1.fr:9292 |

| region | regionOne |

+-------------+----------------------------------+

Service: compute

+-------------+-------------------------------------------+

| Property | Value |

+-------------+-------------------------------------------+

| adminURL | http://controller1:8774/v2/buche |

| id | 263909e2e5b54eac80f1aad4c5692a68 |

| internalURL | http://controller1:8774/v2/buche |

| publicURL | http://cloud.univ-lille1.fr:8774/v2/buche |

| region | regionOne |

+-------------+-------------------------------------------+

Service: network

+-------------+----------------------------------+

| Property | Value |

36 Application Programming Interface : donne l'accès à une bibliothèque logicielle37 Une API Representational State Transfer doit satisfaire un certains nombre de contraintes telles qu'un accès client-serveur, sans état, etc.38 Hyper-Text Transfer Protocol : le protocole du web

Xavier Buche Cloud universitaire avec OpenStack – CNAM Nord-Pas de Calais 33

+-------------+----------------------------------+

| adminURL | http://controller1:9696 |

| id | 261bbe19ea654e7ea62c6e3426701437 |

| internalURL | http://controller1:9696 |

| publicURL | http://cloud.univ-lille1.fr:9696 |

| region | regionOne |

+-------------+----------------------------------+

Service: identity

+-------------+---------------------------------------+

| Property | Value |

+-------------+---------------------------------------+

| adminURL | http://controller1:35357/v2.0 |

| id | 61d4a9c37bdf45dba98730350d30e9ea |

| internalURL | http://controller1:5000/v2.0 |

| publicURL | http://cloud.univ-lille1.fr:5000/v2.0 |

| region | regionOne |

+-------------+---------------------------------------+

Service: metering

+-------------+----------------------------------+

| Property | Value |

+-------------+----------------------------------+

| adminURL | http://controller1:8777 |

| id | 2c3716ed3973450a8f29668a9520462e |

| internalURL | http://controller1:8777 |

| publicURL | http://cloud.univ-lille1.fr:8777 |

| region | regionOne |

+-------------+----------------------------------+

Avec ce catalogue, les utilisateurs savent quels services sont disponibles. Ici par exemple, le service Cinder, qui fournitdes espaces de stockage, est absent. Et ils savent aussi comment y accéder :– si l'utilisateur est un humain, il utilisera l'URL39 publique– si l'utilisateur est un humain avec un accès privilégié, il choisira l'URL admin– si l'utilisateur est un service OpenStack, il utilisera l'URL interne

Comme on peut le voir dans cet exemple, les deux dernières URL (admin et internal) sont locales. On ne peut donc pass'y connecter à distance pour des raisons de sécurité. Alors que la première, qui fournit un jeu de commandesrestreint, a été rendue publique pour que les utilisateurs puissent en faire usage.

Pour qu'un service apparaisse dans ce catalogue, il faut l'y inscrire avec une commande du type :keystone service-create --name <name>

--type <type>

--description <service-description>

Il faut ensuite préciser les points d'accès de ce service :keystone endpoint-create --service <service>

--publicurl <public-url>

--adminurl <admin-url>

--internalurl <internal-url>

39 Uniform Resourse Locator : une adresse web

Xavier Buche Cloud universitaire avec OpenStack – CNAM Nord-Pas de Calais 34

Les comptesNous avions précisé auparavant que les processus d'un même composant OpenStack s'échangent des messages via unbus de données. L'exemple précédent me permet d'ajouter que les composants communiquent entre eux en utilisantleurs API.Chaque service a donc besoin d'un compte, avec un login et un mot de passe, pour s'authentifier auprès des autrescomposants, au même titre que les utilisateurs humains. Néanmoins ils sont particuliers en cela qu'ils sont associés auprojet service (la notion de projet sera détaillée au chapitre sur Keystone, page 40).

Exemple avec Glance, dans le fichier /etc/glance/glance-api.conf :[keystone_authtoken]

auth_host = 127.0.0.1

auth_port = 35357

auth_protocol = http

admin_tenant_name = service

admin_user = glance

admin_password = ...

Les mots de passe des services sont générés aléatoirement par le script d'installation automatique que j'ai réalisé (voirpage 50).

Les pipelines WSGILes services d'OpenStack sont basés sur Paste, un système utilisé pour configurer les applications basées sur PythonWSGI40.

Paste emploie la notion de pipeline. Une connexion à l'API passera successivement par les filtres présents dans unpipeline. Par exemple, un filtre peut assurer une fonction d'authentification, un autre collecter des statistiques, ouencore fournir une implémentation d'EC241 pour la compatibilité avec l'API d'Amazon. Ce système permet de configurer facilement des applications web composites.

Les définitions de pipeline sont généralement dans des fichiers dont le nom se termine par paste.ini, tandis que lesdirectives de configuration générales ou propres aux backends42 sont dans le fichier de configuration principal duservice, comme par exemple keystone.conf.

Les bases de donnéesChaque composant d'OpenStack dispose de sa propre base de données, qu'il faut créer, et y installer le schéma enutilisant un script fournit.Il faut ensuite créer un compte avec des droits d'accès suffisants pour que le service puisse accéder à sa base dedonnées. Le script de configuration automatique génère également les mots de passe de ces comptes.

Voici par exemple un extrait du script d'installation automatique qui concerne la création de la basedonnées de Glance :

echo "creation de la bdd"

mysql -u root --password=$ROOT_DBPASS <<-FIN

CREATE DATABASE glance;

GRANT ALL PRIVILEGES ON glance.* TO 'glance'@'localhost' IDENTIFIED BY "$GLANCE_DBPASS";

GRANT ALL PRIVILEGES ON glance.* TO 'glance'@'%' IDENTIFIED BY "$GLANCE_DBPASS";

FIN

echo "creation des tables"

su -s /bin/sh -c "glance-manage db_sync" glance || arreter

40 Web Server Gateway Interface : une interface qui fait office de passerelle entre une application Python et un serveur web.41 Elastic Compute Cloud42 Les backends (appelés aussi drivers) permettent aux composants de déléguer certaines opérations, comme l'authentification par exemple, à

différents modules.

Xavier Buche Cloud universitaire avec OpenStack – CNAM Nord-Pas de Calais 35

Une fois la base de données créée, il faut configurer les composants pour qu'ils sachent comment y accéder.Heureusement, cette configuration suit toujours le même modèle : plusieurs directives doivent être renseignées dansle fichier de configuration principal du composant.

Exemple avec Glance :[database]

backend = sqlalchemy

connection = mysql://glance:secret@controller1/glance

L'option backend permet de choisir le module Python qui sera utilisé pour prendre en charge les requêtes à la base dedonnées.

Dialogue avec les APIIl y a trois manières de communiquer avec OpenStack. Voyons lesquelles, en commençant par la plus simple.

Panneau de contrôleOpenStack fournit aux utilisateurs et administrateurs une interface web appelée panneau de contrôle et basée sur lecadriciel Horizon. Cette interface relaye les ordres des utilisateurs aux API d'OpenStack. Un chapitre lui est réservéplus loin, page 102.

Ligne de commandeUne série de scripts Python transforment des commandes en requêtes aux API et affichent les résultats. Ces scriptspeuvent être installés soit à partir des paquetages de la distribution Linux, comme nous l'avons fait…

Exemple avec Keystone :apt-get install python-keystoneclient

… ou alors à partir de la librairie Python, pour avoir une version plus récente : pip43 install python-keystoneclient

Une fois le client installé, si on cherche à l'utiliser sans être authentifié :keystone catalog

Expecting an auth URL via either --os-auth-url or env[OS_AUTH_URL]

Il y a deux façons de s'authentifier :

- en passant des options aux commandeskeystone --os-username buche

--os-password mon_secret

--os-tenant-name mon_projet

--os-auth-url "http://cloud.univ-lille1.fr:5000/v2.0"

catalog

Ce qui est, comme vous l'imaginez, assez vite rébarbatif et peu sécurisé, puisque le mot de passe s'affiche sur laconsole de l'utilisateur.

- en utilisant des variables d'environnementOS_USERNAME=buche

OS_PASSWORD=mon_secret

OS_TENANT_NAME=mon_projet

OS_AUTH_URL=http://cloud.univ-lille1.fr:5000/v2.0

Ce qui est fait une fois pour toute pour la durée de la session de l'utilisateur sur sa console.

43 La commande pip permet d'installer des paquetages Python à partir d'un dépôt, le Python Package Index.

Xavier Buche Cloud universitaire avec OpenStack – CNAM Nord-Pas de Calais 36

Pour faciliter l'entrée de ces variables, j'ai fait un petit script :read -p "login : " login

read -s -p "mot de passe : " pass

read -p "tenant : " tenant

export OS_USERNAME=$login

export OS_PASSWORD=$pass

export OS_TENANT_NAME=$tenant

export OS_AUTH_URL=http://cloud.univ-lille1.fr:5000/v2.0

Il faut veiller à exécuter ce script avec la commande source pour que les variables soit exportées vers le shell44 del'utilisateur.

Requêtes HTTPLa méthode la plus laborieuse consiste à créer soi-même une requête HTTP au format JSON45.

Exemple :curl -i -X POST http://controller1:5000/v2.0/tokens

-H "Content-Type: application/json"

-d '{"auth":

{"tenantName": "projet_test",

"passwordCredentials":

{"username": "buche",

"password": "mon_secret"}}}'

L'URL de destination dépend de l'action que l'on souhaite effectuer. Ici, il s'agit juste d'une requête d'authentification,l'équivalent de la commande keystone token-get.Toutes ces opérations sont référencées dans la documentation des API d'OpenStack [Benchmarks].

Ensuite on analyse la réponse :{

"access": {

"metadata": {

"is_admin": 0,

"roles": [

"enseignant"

]

},

"serviceCatalog": [

{

"endpoints": [

{

"adminURL": "http://controller1:9292",

"id": "a28fac59bd0548f8942e09b5508c41ce",

"internalURL": "http://controller1:9292",

"publicURL": "http://cloud.univ-lille1.fr:9292",

"region": "regionOne"

}

44 l'interpréteur de commandes sur les systèmes de type Unix45 JavaScript Object Notation permet de stocker et de transmettre des données structurées

Xavier Buche Cloud universitaire avec OpenStack – CNAM Nord-Pas de Calais 37

],

"endpoints_links": [],

"name": "glance",

"type": "image"

},

{

"endpoints": [

{

"adminURL": "http://controller1:8774/v2/projet_test",

"id": "263909e2e5b54eac80f1aad4c5692a68",

"internalURL": "http://controller1:8774/v2/projet_test",

"publicURL": "http://cloud.univ-lille1.fr:8774/v2/projet_test",

"region": "regionOne"

}

],

"endpoints_links": [],

"name": "nova",

"type": "compute"

},

{

"endpoints": [

{

"adminURL": "http://controller1:9696",

"id": "261bbe19ea654e7ea62c6e3426701437",

"internalURL": "http://controller1:9696",

"publicURL": "http://cloud.univ-lille1.fr:9696",

"region": "regionOne"

}

],

"endpoints_links": [],

"name": "neutron",

"type": "network"

},

{

"endpoints": [

{

"adminURL": "http://controller1:35357/v2.0",

"id": "61d4a9c37bdf45dba98730350d30e9ea",

"internalURL": "http://controller1:5000/v2.0",

"publicURL": "http://cloud.univ-lille1.fr:5000/v2.0",

"region": "regionOne"

}

],

"endpoints_links": [],

"name": "keystone",

"type": "identity"

},

Xavier Buche Cloud universitaire avec OpenStack – CNAM Nord-Pas de Calais 38

{

"endpoints": [

{

"adminURL": "http://controller1:8777",

"id": "2c3716ed3973450a8f29668a9520462e",

"internalURL": "http://controller1:8777",

"publicURL": "http://cloud.univ-lille1.fr:8777",

"region": "regionOne"

}

],

"endpoints_links": [],

"name": "ceilometer",

"type": "metering"

}

],

"token": {

"expires": "2015-04-14T23:26:39Z",

"id": "MIII3wYJKoZIhvcNAQcCoIII0DCCCMwCAQExDTALBglghkgBZQMEAgEwggctBgkqhkiG9w0BBwGgggceBIIHGnsiYWNjZXNzIjogeyJ0b2tlbiI6IHsiaXNzdWVkX2F0IjogIjIwMTUtMDUtMTRUMTM6MjY6MzkuNTA4NDI2IiwgImV4cGlyZXMiOiAiMjAxNS0wNS0xNFQyMzoyNjozOVoiLCAiaWQiOiAicGxhY2Vob2xkZXIiLCAidGVuYW50IjogeyJlbmFibGVkIjogdHJ1ZSwgIm5hbWUiOiAicHJvamV0X3Rlc3QiLCAiaWQiOiAicHJvamV0X3Rlc3QifX0sICJzZXJ2aWNlQ2F0YWxvZyI6IFt7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly9jb250cm9sbGVyMTo5MjkyIiwgInJlZ2lvbiI6ICJyZWdpb25PbmUiLCAiaW50ZXJuYWxVUkwiOiAiaHR0cDovL2NvbnRyb2xsZXIxOjkyOTIiLCAiaWQiOiAiYTI4ZmFjNTliZDA1NDhmODk0MmUwOWI1NTA4YzQxY2UiLCAicHVibGljVVJMIjogImh0dHA6Ly9jbG91ZC51bml2LWxpbGxlMS5mcjo5MjkyIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogImltYWdlIiwgIm5hbWUiOiAiZ2xhbmNlIn0sIHsiZW5kcG9pbnRzIjogW3siYWRtaW5VUkwiOiAiaHR0cDovL2NvbnRyb2xsZXIxOjg3NzQvdjIvcHJvamV0X3Rlc3QiLCAicmVnaW9uIjogInJlZ2lvbk9uZSIsICJpbnRlcm5hbFVSTCI6ICJodHRwOi8vY29udHJvbGxlcjE6ODc3NC92Mi9wcm9qZXRfdGVzdCIsICJpZCI6ICIyNjM5MDllMmU1YjU0ZWFjODBmMWFhZDRjNTY5MmE2OCIsICJwdWJsaWNVUkwiOiAiaHR0cDovL2Nsb3VkLnVuaXYtbGlsbGUxLmZyOjg3NzQvdjIvcHJvamV0X3Rlc3QifV0sICJlbmRwb2ludHNfbGlua3MiOiBbXSwgInR5cGUiOiAiY29tcHV0ZSIsICJuYW1lIjogIm5vdmEifSwgeyJlbmRwb2ludHMiOiBbeyJhZG1pblVSTCI6ICJodHRwOi8vY29udHJvbGxlcjE6OTY5NiIsICJyZWdpb24iOiAicmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly9jb250cm9sbGVyMTo5Njk2IiwgImlkIjogIjI2MWJiZTE5ZWE2NTRlN2VhNjJjNmUzNDI2NzAxNDM3IiwgInB1YmxpY1VSTCI6ICJodHRwOi8vY2xvdWQudW5pdi1saWxsZTEuZnI6OTY5NiJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJuZXR3b3JrIiwgIm5hbWUiOiAibmV1dHJvbiJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly9jb250cm9sbGVyMTozNTM1Ny92Mi4wIiwgInJlZ2lvbiI6ICJyZWdpb25PbmUiLCAiaW50ZXJuYWxVUkwiOiAiaHR0cDovL2NvbnRyb2xsZXIxOjUwMDAvdjIuMCIsICJpZCI6ICI2MWQ0YTljMzdiZGY0NWRiYTk4NzMwMzUwZDMwZTllYSIsICJwdWJsaWNVUkwiOiAiaHR0cDovL2Nsb3VkLnVuaXYtbGlsbGUxLmZyOjUwMDAvdjIuMCJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJpZGVudGl0eSIsICJuYW1lIjogImtleXN0b25lIn0sIHsiZW5kcG9pbnRzIjogW3siYWRtaW5VUkwiOiAiaHR0cDovL2NvbnRyb2xsZXIxOjg3NzciLCAicmVnaW9uIjogInJlZ2lvbk9uZSIsICJpbnRlcm5hbFVSTCI6ICJodHRwOi8vY29udHJvbGxlcjE6ODc3NyIsICJpZCI6ICIyYzM3MTZlZDM5NzM0NTBhOGYyOTY2OGE5NTIwNDYyZSIsICJwdWJsaWNVUkwiOiAiaHR0cDovL2Nsb3VkLnVuaXYtbGlsbGUxLmZyOjg3NzcifV0sICJlbmRwb2ludHNfbGlua3MiOiBbXSwgInR5cGUiOiAibWV0ZXJpbmciLCAibmFtZSI6ICJjZWlsb21ldGVyIn1dLCAidXNlciI6IHsidXNlcm5hbWUiOiAiYnVjaGUiLCAicm9sZXNfbGlua3MiOiBbXSwgImlkIjogImJ1Y2hlIiwgInJvbGVzIjogW3sibmFtZSI6ICJldHVkaWFudCJ9XSwgIm5hbWUiOiAiYnVjaGUifSwgIm1ldGFkYXRhIjogeyJpc19hZG1pbiI6IDAsICJyb2xlcyI6IFsiZXR1ZGlhbnQiXX19fTGCAYUwggGBAgEBMFwwVzELMAkGA1UEBhMCVVMxDjAMBgNVBAgMBVVuc2V0MQ4wDAYDVQQHDAVVbnNldDEOMAwGA1UECgwFVW5zZXQxGDAWBgNVBAMMD3d3dy5leGFtcGxlLmNvbQIBATALBglghkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAEggEAjLac9N5uktKzQSei3y-E0tlPMave67XY3O0TL+05da4M6e78T0MKjSK+QV6pBHLjc4T9U3xHzo4v-fFMPxb9NtPOwtScn56VfNVnxc9nlf22tf5VQ+yeCfn08TX+RyEEYGCTYBESyT4ZIo5ryB+17V1MgfVEs+kvEEG9zbrEE81dt1QJFFVj3mT4QwduOnPklngwWam+i5pGjfwi2X00InlxtEeYPUkqQEWVsCFWwYMjHJBjs8q7xHkSQJkGpmGb0uCGbyABGVcji873gdJ3sEMnAdtDaNbq-vghUUvHahhRtiOaSZYrI2jm6abb089uBEK180Bq2dV3ynf5KvGWaA==",

"issued_at": "2015-04-14T13:26:39.508426",

"tenant": {

"enabled": true,

"id": "projet_test",

"name": "projet_test"

}

},

"user": {

"id": "buche",

Xavier Buche Cloud universitaire avec OpenStack – CNAM Nord-Pas de Calais 39

"name": "buche",

"roles": [

{

"name": "enseignant"

}

],

"roles_links": [],

"username": "buche"

}

}

}

On peut constater que la réponse à notre requête contient notamment le catalogue des services et un jeton associé àmon projet test et d'une durée de validité de 10 heures.Vous pourrez revenir sur le résultat de cette requête pour vérifier les explications qui vont suivre sur lefonctionnement de Keystone.

J'utilise cette méthode d'accès dans certains cas de figure :– pour comprendre plus clairement le fonctionnement d'OpenStack– pour le débogage– pour accéder à des fonctions des API qui ne sont pas encore implémentées par les clients.

On peut aussi procéder de cette manière pour réaliser soi-même une interface web, par exemple.

Focalisons-nous désormais sur la première des briques de notre jeu de construction : Keystone.

4.3 Keystone et l'authentificationLe composant Keystone assure deux fonctions :– la gestion des utilisateurs, de leur authentification et de leurs autorisations– le catalogue des services et de leurs points d'accès (sous la forme d'URL)

4.3.1 VocabulairePour sa gestion des utilisateurs, Keystone emploie des termes dont il est nécessaire de saisir les nuances :– user : représente un utilisateur humain ou un service– project (appelé aussi tenant) : contient des ressources (réseaux, volumes, instances, images, etc.)– role : indique les opérations qu'un utilisateur peut réaliser dans un projet donné– group : collection d'utilisateurs. Au lieu d'affecter le même rôle à chaque utilisateur, ce qui est fastidieux, on

affecte un rôle à un groupe qui contient les utilisateurs. Tout groupe fait partie d'un domaine.– domain : définit des frontières administratives pour la gestion des identités. Ensemble de projets, utilisateurs,

groupes et rôles. Un utilisateur dont le rôle est admin de domaine peut effectuer les opérations de gestion dece domaine (créer des utilisateurs, des groupes, assigner des rôles, etc.).

Le principe de fonctionnement est le suivant : un projet contient des ressources, un groupe contient des utilisateurs.Si je veux que ces utilisateurs accèdent à ces ressources, j'associe le groupe avec le projet.Mais lors d'une telle association, il faut préciser ce que les utilisateurs auront le droit de faire avec ces ressources. Ondoit donc préciser quel rôle ils auront dans ce projet avec une commande du type :

keystone user-role-add --user <le_groupe> --role <le_role> --tenant <le_projet>

Un utilisateur peut avoir différents rôles dans le même projet ou dans des projets différents. Par exemple unutilisateur peut avoir le droit d'éteindre la machine des autres utilisateurs dans un projet particulier, mais que lamême opération lui soit interdite dans un autre projet.

Xavier Buche Cloud universitaire avec OpenStack – CNAM Nord-Pas de Calais 40

4.3.2 Les jetonsPour fournir des autorisations aux utilisateurs, Keystone se base sur des jetons.

Exemple : je souhaite lancer une machine virtuelle.– Je transmet à Keystone mon login et mon mot de passe pour qu'il m'authentifie.– Keystone m'envoie, en retour, un jeton temporaire ainsi qu'un catalogue des services.– Je lui renvoie ce jeton avec une demande pour obtenir la liste des projets auxquels j’appartiens.

– Keystone me transmet la liste de ces projets.– Je communique à Keystone le projet que j'ai choisi parmi ceux de la liste.– Keystone m'envoie un jeton associé à ce projet, ainsi que la liste des services disponibles dans ce projet et

leurs points d'accès.– Parmi ces services, je choisis celui qui pourra lancer une machine virtuelle (c'est Nova), et j'utilise son point

d'accès pour lui envoyer une requête accompagnée du jeton du projet.– À réception de ma requête, Nova fait suivre le jeton à Keystone pour qu'il le valide.– Nova vérifie que je suis autorisé à lancer une machine virtuelle, en fonction de mon rôle dans ce projet et des

droits associés à ce rôle.– Nova peut enfin créer l'instance de machine virtuelle que je lui ai demandée, et me renvoie un message pour

me le signaler

Un jeton a une durée de validité limitée, au-delà de laquelle il est révoqué. La portée d'un jeton est limitée par lesfrontières d'un domaine.

4.3.3 RBAC : Role Based Access ControlChaque service permet de configurer des autorisations qui associent indirectement les utilisateurs avec des actions. Le contrôle de ces permissions se fait par le biais de règles dans des fichiers texte au format JSON.

Au premier abord, le RBAC d'OpenStack est parfaitement abscons. Et pas la moindre documentationofficielle sur le sujet. J'ai dû reconstituer l'information qui circule au compte-goutte sur Internet etprocéder par essai-erreur pour comprendre le fonctionnement particulièrement puissant du contrôle desautorisations.

Pour commencer, un exemple simple : les étudiants ne doivent pas pouvoir rendre une image de machinevirtuelle publique.Dans le fichier /etc/glance/policy.json, il faut remplacer la ligne :

"publicize_image": "",

… qui permet à tout le monde d'effectuer cette opération, par cette ligne :"publicize_image": "not role:etudiant",

… qui restreint cette action à tout utilisateur qui n'a pas le rôle etudiant.

Un exemple un peu plus ardu : seuls les administrateurs et les enseignants d'informatique doivent pouvoirchanger les quotas des étudiants d'informatique.

On crée une nouvelle règle appelée ens_quota_etu :"ens_quota_etu": "role:enseignant_info and 'etudiant_info':%(target.role.name)s",

… et on ajoute cette règle aux conditions nécessaires à l'application de la règle compute_extension: quotas: update :"compute_extension:quotas:update": "role:admin or rule:ens_quota_etu",

Ici on voit qu'il y a deux règles qui n'ont pas la même signification : – La première est une sorte d'alias qui sera référencée par la seconde.– La seconde indique que l'opération indiquée dans le premier champ, qui correspond à un appel à l'API

compute_extension du service Nova, ne peut être lancée qu'à la condition que les clauses du deuxième champsoient vraies.

Dans notre exemple, la mise à jour des quotas sera réalisée uniquement si le jeton de l'utilisateur qui a formulé larequête indique que le rôle de cet utilisateur est admin ou que la règle ens_quota_etu est respectée.

Xavier Buche Cloud universitaire avec OpenStack – CNAM Nord-Pas de Calais 41

Or cette règle indique que l'utilisateur qui a envoyé la requête doit être un enseignant d'informatique et que le rôlequi apparaît dans la requête, c'est-à-dire celui de l'utilisateur objet de la modification des quotas, doit êtreetudiant_info.

Comme vous pouvez le constater, et bien que ce ne soit là qu'une présentation partielle du potentiel du moteur destratégies d'accès d'OpenStack, ses possibilités ne semblent pas souffrir d'une quelconque limite.

4.3.4 Apache HTTPDPar défaut, Keystone utilise son propre serveur web interne basé sur le projet Eventlet, lui-même basé sur Greenlet.Cependant il est recommandé, en production, d'utiliser le serveur web Apache.

Car Eventlet est très limité :– authentication basique avec mot de passe en clair– IPv6 non supporté– performances et stabilité en retrait par rapport à Apache

Keystone est une application WSGI, et a peu de dépendance avec Eventlet. Il peut donc facilement être couplé avec unautre serveur web, comme Apache, qui est beaucoup plus fiable, performant et sécurisé. En outre, le serveur webApache dispose de nombreuses extensions, en particulier des modules d'authentification qui pourront nous intéresser.

Comment utiliser Apache :– copier dans /usr/lib/cgi-bin/keystone/ le script WSGI récupéré à l'adresse suivante :

https://github.com/OpenStack/keystone/blob/stable/icehouse/httpd/keystone.py

– créer les liens suivants :ln /usr/lib/cgi-bin/keystone/keystone.py /var/www/cgi-bin/keystone/main

ln /usr/lib/cgi-bin/keystone/keystone.py /var/www/cgi-bin/keystone/admin

– créer un fichier /etc/apache2/sites-enabled/keystone.conf contenant :Listen 5000

WSGIDaemonProcess keystone user=keystone group=nogroup processes=8 threads=1

<VirtualHost *:5000>

LogLevel warn

ErrorLog ${APACHE_LOG_DIR}/error.log

CustomLog ${APACHE_LOG_DIR}/access.log combined

WSGIScriptAlias / /var/www/cgi-bin/keystone/main

WSGIProcessGroup keystone

</VirtualHost>

Listen 35357

<VirtualHost *:35357>

LogLevel warn

ErrorLog ${APACHE_LOG_DIR}/error.log

CustomLog ${APACHE_LOG_DIR}/access.log combined

WSGIScriptAlias / /var/www/cgi-bin/keystone/admin

WSGIProcessGroup keystone

</VirtualHost>

– arrêter le serveur web de Keystone :service keystone stop

– désactiver le service upstart de Keystone :echo "manual" > /etc/init/keystone.override

Xavier Buche Cloud universitaire avec OpenStack – CNAM Nord-Pas de Calais 42

– relancer le démon Apache :service apache2 restart

4.3.5 AuthentificationDiscutons maintenant de la manière dont les utilisateurs vont s'authentifier à la plate-forme, car de nombreusessolutions sont envisageables, chacune ayant ses avantages et inconvénients.

4.3.5.1 Des comptes pour OpenStackLes comptes OpenStack sont « sensibles », car ils permettent de gérer, par exemple, des machines virtuellesaccessibles sur Internet. Un principe général de la sécurité informatique consiste à justifier différemment de sonidentité pour accéder à des services dont le niveau de sécurité est différent.Exemple : je n'utilise pas le même couple login/mot de passe pour accéder au site web de ma banque et pour accéder àun forum de discussion.D'où l'idée de fournir aux utilisateurs un compte séparé, avec un mot de passe différent de celui de l'université.L'environnement OpenStack resterait ainsi inaccessible à un utilisateur dont le compte « université » aurait été piraté.

Concrètement, on pourrait laisser aux utilisateurs le soin de créer eux-mêmes leur compte sur une page webaccessible depuis la page d'accueil d'OpenStack. Ce cette manière, ils définiraient un login et un mot de passe qu'ilspourraient ensuite utiliser pour se connecter à OpenStack.

Problème : la probabilité pour qu'un utilisateur oublie son mot de passe au bout d'un certain temps est proportionnelà la masse d'utilisateurs.Comment changer un mot de passe oublié ?– manuellement : implique une trop grande surcharge de travail d'administration– automatiquement : un nouveau mot de passe (ou un lien vers celui-ci) est envoyé à l'utilisateur

Or le seul moyen raisonnable pour contacter l'utilisateur est l'e-mail. Pirater la boîte mail de l'utilisateur permettraitdonc de modifier le mot de passe du compte OpenStack, et donc d'accéder au service.Dans ces conditions, l'idée du compte séparé n'a aucun intérêt en matière de sécurité. Au contraire même, car lesutilisateurs qui ont trop de comptes différents finissent souvent par utiliser partout le même mot de passe, ou pire :écrire les mots de passe sur des post-its collés à l'écran…

Solution : utiliser l'annuaire LDAP46 des comptes utilisateurs de l'université.

4.3.5.2 Tentatives avec le SSO CASPlutôt que d'utiliser directement l'annuaire LDAP pour authentifier les utilisateurs d'OpenStack, il serait préférabled'utiliser le service SSO47 de l'université. D'abord parce qu'il évite aux utilisateurs d'avoir à saisir leur mot de passe àchaque fois qu'ils se connectent à une application différente. Ensuite parce que le mécanisme d'authentification duCAS48 fonctionne de telle sorte que le mot de passe de l'utilisateur ne transite pas par l'application qui demande àl'authentifier.

Mettons cela en place :– on active tout d'abord le module SSO CAS d'Apache :

a2enmod auth_cas

– puis on le configure :<IfModule mod_auth_cas.c>

CASValidateServer Off

CASDebug On

46 Lightweight Directory Access Protocol : un protocole d'accès à des bases de données hiérarchiques47 Le Single Sign On est un concept dont le principe est de permettre d'accéder à différentes ressources de manière authentifiée, sans avoir à

entrer à chaque fois ses informations d'authentification (credentials)48 Central Authentication Service est une implémentation mettant en œuvre le SSO

Xavier Buche Cloud universitaire avec OpenStack – CNAM Nord-Pas de Calais 43

CASCookiePath /var/cache/apache2/mod_auth_cas/

CASLoginURL https://sso-cas.univ-lille1.fr/login

CASValidateURL https://sso-cas.univ-lille1.fr/serviceValidate

CASProxyValidateURL https://sso-cas.univ-lille1.fr/proxyValidate

</IfModule>

Quand le démon Apache httpd reçoit une demande d'authentification, il redirige la requête HTTP vers le serveurCAS.

Exemple : une simple requête, au format JSON, du client Keystone vers le serveur (commande keystonetoken-get)…

POST /v2.0/tokens HTTP/1.1

Host: controller1:35357

Content-Length: 103

Content-Type: application/json

Accept-Encoding: gzip, deflate, compress

Accept: */*

User-Agent: python-keystoneclient

{"auth": {"tenantName": "admin", "passwordCredentials": {"username": "mon_login", "password": "mon_mot_de_passe"}}}

… renvoie une redirection HTTP vers le serveur CAS :<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">

<html><head>

<title>302 Found</title>

</head><body>

<h1>Found</h1>

<p>The document has moved <a href="https://sso-cas.univ-lille1.fr/login?service=http%3a%2f%2fcloud.univ-lille1.fr%3a35357%2fv2.0%2ftokens">here</a>.</p>

<hr>

<address>Apache/2.4.7 (Ubuntu) Server at controller1 Port 35357</address>

</body></html>

Cette réponse est incomprise du client Keystone.

Une requête HTTP vers le serveur Keystone incluant un ticket49 CAS obtenu préalablement…http://controller1:35357/Login?ticket=ST-393035-G0Kcn1FvKowDXvNYXEE6-sso-cas.univ-lille1.fr

… retourne également une redirection…Redirect to: http://cloud.univ-lille1.fr/Login

… toujours incomprise du client Keystone.

La seule solution serait de pouvoir lier d'une manière ou d'une autre le ticket CAS et le jeton Keystone. Toutes mesrecherches sur le sujet sont restées infructueuses. Le SSO CAS n'est actuellement pas à l'ordre du jour du projetOpenStack.

Par contre, la fédération d'identité Shibboleth devrait être utilisable avec les toutes dernières versions d'OpenStack(Juno et Kilo). Ce qui permettrait d'authentifier éventuellement des membres de l'Enseignement Supérieur extérieursà l'université.C'est une prochaine étape importante du projet.

49 Obtenu après s'être authentifié, le ticket permet à un utilisateur d'accéder, pendant un temps limité, aux applications qui lui sont autorisées.

Xavier Buche Cloud universitaire avec OpenStack – CNAM Nord-Pas de Calais 44

4.3.5.3 LDAPKeystone dispose d'un backend LDAP officiel et documenté.Il est possible, et c'est une nouveauté de la version Icehouse d'OpenStack, d'utiliser un backend différent pour lagestion des identités et la gestion des assignations. Dans le vocabulaire de Keystone, la gestion des identités concerneles utilisateurs et les groupes. Tandis que la gestion des assignations concerne les projets, les rôles et les domaines.

Nous ne nous encombrerons pas de la notion de domaine qui ne nous sera, au moins dans les premierstemps de l'exploitation de la plate-forme, d'aucune utilité.

De nombreuses possibilités s'offrent à nous. Les voici exposées.

Réplication ou synchronisationD'abord concernant l'authentification. Une première option pourrait consister à répliquer les comptes des utilisateursdans une base LDAP ou SQL locale, sur le contrôleur. Ou alors synchroniser le serveur LDAP local avec le serveurLDAP de l'université.

Avantage : les performances de l'accès local

Inconvénients :– Par principe, il est toujours préférable d'accéder directement à la source d'une information plutôt qu'à un

réplicat.– Les condensats de mot de passe des comptes utilisateurs sont stockés sur les contrôleurs OpenStack. Si ces

machines sont piratées, l'assaillant peut effectuer des attaques par dictionnaire ou par « force brute » pourretrouver les mots de passe.

Authentification sur l'annuaire LDAP de l'universitéAvantage : simplicité. On a juste à renseigner quelques directives dans le fichier de configuration de Keystone.

Inconvénients : – Je constate avec regret que Keystone est un piètre client LDAP. En effet, plusieurs options quasi-

indispensables en environnement de production sont absentes :– cache : les résultats des recherches ne sont pas mis en cache, ce qui grève sensiblement les performances

et l'expérience utilisateur lors de la navigation sur l'interface web.– serveurs multiples : on ne peut pas configurer l'adresse d'un second serveur LDAP, qui serait utilisé en

cas de panne du premier.– pool de connexions : pour améliorer les performances, les connexions aux serveurs LDAP restent

ouvertes un certain temps et sont réutilisées pour toutes les requêtes. Avec Keystone, qui ne gère pas lespools de connexion, une connexion est ouverte avant l'envoi d'une requête, puis systématiquementfermée après réception de la réponse.

– le backend de gestion des identités s'occupe également des groupes. Si on utilise directement les serveursLDAP de l'université, il ne sera pas possible de gérer nous-mêmes les groupes.

CompromisPour pallier les inconvénients des deux premières propositions, nous avons opté pour un compromis. Ils'agit d'installer, en local sur le contrôleur, un serveur LDAP qui sera configuré comme mandataire etcache pour la branche people, qui contient les comptes des utilisateurs. La branche groups restera localepour avoir tout loisir de créer des groupes, modifier leurs membres, etc.

Détaillons sans plus attendre le fonctionnement de ce serveur.

Les requêtes de recherche reçues par le serveur LDAP et qui concernent la branche people sont transmises à l'un desserveurs LDAP de l'université. Une fois reçue, la réponse est envoyée à Keystone et mise en cache temporairement.Si la même requête est reçue par le serveur LDAP quelques temps plus tard, il trouvera la réponse dans son cache etpourra la fournir beaucoup plus vite.

Xavier Buche Cloud universitaire avec OpenStack – CNAM Nord-Pas de Calais 45

Voyons comment cela se configure.

IdentitésOn installe OpenLDAP par la commande :

apt-get install slapd

Les versions récentes d'OpenLDAP se configurent dynamiquement via des directives stockées dans la branchecn=config de l'arborescence LDAP.L'avantage est que la configuration peut être modifiée sans nécessiter un redémarrage du serveur. L'inconvénient estque les changements de configuration sont nettement plus compliqués (notamment l'ajout de nouveaux schémas),puisqu'au lieu de modifier un simple fichier texte (/etc/ldap/slapd.conf), il faut lancer des commandes du type :– pour lister les schémas :

ldapsearch -LLLx -H ldapi:/// -b cn=schema,cn=config "(objectClass=olcSchemaConfig)" dn

– pour lister la configuration :ldapsearch -Y EXTERNAL -H ldapi:/// -b "cn=config"

– pour modifier la configuration :ldapmodify -Y EXTERNAL -H ldapi:/// -f <fichier-config.ldif>

Pour une plus grande simplicité, on utilisera donc le fichier de configuration, puisque c'est toujours possible enprécisant son emplacement à la directive SLAPD_CONF du fichier /etc/default/slapd :

SLAPD_CONF=/etc/ldap/slapd.conf

On y ajoute les lignes suivantes :– inclusion des schémas propres à l'annuaire de l'université :

include /etc/ldap/schema/internet2.schema

include /etc/ldap/schema/samba.schema

include /etc/ldap/schema/supann.schema

include /etc/ldap/schema/ustl.schema

– chargement du module qui assure la fonction de mandataire et de cache :moduleload pcache

– adresse des serveurs LDAP de l'université et de la branche people :database ldap

uri "ldap://ldap1.univ-lille1.fr/ ldap://ldap2.univ-lille1.fr/"

suffix "ou=people,dc=univ-lille1,dc=fr"

– type de la base de données utilisée pour stocker les entrées du cache (hdb), le nombre maximum d'entrées(50000), le nombre de directives pcacheAttrset (1), le nombre maximum d'entrées à mettre en cache suite àune requête (5000) et la durée entre chaque suppression des entrées périmées (100 secondes) :

overlay pcache

pcache hdb 50000 1 5000 100

Les réponses aux requêtes sont mises en cache uniquement si ces requêtes correspondent à des modèles, spécifiés parles directives pcacheAttrset et pcacheTemplate.pcacheAttrset définit un numéro référencé par les directives pcacheTemplate qui s'y rattachent, ainsi que la liste desattributs à mettre en cache.pcacheTemplate définit un modèle sous la forme d'une requête de laquelle on aurait supprimé les valeurs des attributs.Le modèle est associé à la directive pcacheAttrset par un entier (ici 0). Et la dernière valeur de la ligne est le TTL (TimeTo Live) des entrées mises en cache, au-delà duquel elles sont déclarées périmées et susceptibles d'être supprimées.

Il n'y a malheureusement pas la possibilité de mettre en cache tous les résultats de requête sansdistinction. J'ai donc dû analyser les journaux du serveur LDAP lors d'un usage classique d'OpenStack(authentification, gestion des machines virtuelles, des réseaux, etc.) pour déterminer les modèles derequête les plus fréquents. Le format de ces requêtes dépend du filtre d'accès au serveur LDAP définit dans la configuration de

Keystone (voir plus loin dans ce chapitre, page 49). Si ce filtre est modifié, par exemple pour autoriser davantage

Xavier Buche Cloud universitaire avec OpenStack – CNAM Nord-Pas de Calais 46

d'étudiants à utiliser OpenStack, il faut également modifier le modèle pcache, ce qui est lourd, mais inévitable.

Exemple :pcacheAttrset 0 userPassword mail gidNumber uid

pcacheTemplate (&(uid=)(objectClass=)) 0 3600

pcacheTemplate (&(uid=)(|(uid=)(uid=)(uid=)(title=))(objectClass=)) 0 3600

pcacheTemplate (&(|(uid=)(uid=)(uid=)(title=))(objectClass=)) 0 3600

Dans cette configuration, les demandes d'authentification (bind) ne sont pas mandatées et les mots depasse ne sont pas stockés dans le cache, pour une meilleure sécurité.

AssignationConcernant la partie assignation, c'est-à-dire la gestion des rôles et des projets, elle ne peut pas se faire directementsur le serveur LDAP de l'université, sur lequel nous n'avons pas de droits d'écriture.

Deux options s'offrent à nous :– une gestion des assignations dans la base de données SQL de Keystone

Avantage : elle existe déjà et elle est répliquée– une gestion des assignations dans un annuaire LDAP local

Avantages : une base de données hiérarchique est, par principe, plus performante en lecture. De plus, lesbases de données SQL d'OpenStack sont nombreuses et fortement sollicitées. Il vaut donc mieux, à priori,séparer les torchons (données d'assignation) et les serviettes (données propres à OpenStack).

Ainsi nous décidons d'utiliser notre serveur LDAP pour y stocker les projets et les rôles. Reste à savoircomment les associer avec les utilisateurs…

La méthode habituelle et documentée pour faire cette association est la commande :keystone user-role-add --user <user> --role <role> --tenant <tenant>

Cette commande ajoute une entrée à la table assignment de la base de donnée MySQL de Keystone. Ce qui signifie queles utilisateurs, les projets et les rôles sont dans la base LDAP, mais le lien entre ces trois entités se retrouve dans labase Mysql. Cette solution n'est évidemment pas la meilleure. Et dans ce cas, il serait préférable de placer l'ensemblede la partie assignation dans la base de données MySQL.

A force de recherche, j'ai fini par trouver la solution, avec mon collègue Mohammed Khabzaoui, pour que cetteassociation soit faite au niveau de la base LDAP.

C'est ici l'emplacement adéquate pour une légère digression qui me fait dire que le métierd'administrateur systèmes a parfois ce quelque chose d'ingrat consistant à rechercher la solution d'unproblème pendant de nombreuses heures, voire des jours entiers, pour aboutir à un résultat qui se résumefréquemment à quelques instructions ou directives placées là où il faut. Et ce résultat est alorsridiculement proportionné devant l'effort déployé pour l'obtenir.

Voici en définitive la manière dont on peut lier les utilisateurs, les rôles et les projets dans une arborescence LDAP.

Xavier Buche Cloud universitaire avec OpenStack – CNAM Nord-Pas de Calais 47

Comme on peut le voir sur cette capture d'écran, l'OU50 mon_projet, située dans l'OU tenants51, contient l'objetpersonnel. Ce dernier, qui correspond à un rôle présent dans l'OU roles, est associé à l'utilisateur buche parl'intermédiaire de son attribut roleOccupant.

Toutes les combinaisons sont possibles :– plusieurs rôles peuvent être associés au même projet : dans cet exemple j'ai le rôle personnel et le rôle biatos

dans le projet mon_projet– le même rôle peut être associé à différents projets : par exemple, un rôle enseignant_master_info pourrait être

associé aux projets des étudiants de Master Informatique– plusieurs utilisateurs peuvent avoir le même rôle : par exemple, tous les enseignants qui interviennent en

Master Informatique pourraient avoir le rôle enseignant_master_info– un utilisateur peut avoir plusieurs rôle : par exemple un doctorant pourrait avoir le rôle d'étudiant dans

certains projets, et le rôle de chercheur dans les projets de son laboratoire

GroupesPlutôt que d'assigner directement des utilisateurs à des rôles, on peut associer des groupes d'utilisateurs à des rôles :un utilisateur est membre d'un groupe, un groupe est lié à un rôle dans un projet.

On retrouve ici un concept puissant utilisé par Microsoft avec Active Directory et les notions de groupes globaux et degroupes locaux : les utilisateurs sont regroupés dans les groupes globaux et les ressources (PC, imprimantes,applications, etc.) sont regroupées dans des groupes locaux sur lesquels on affecte des droits d'accès. Il suffit ensuited'associer les groupes globaux aux groupes locaux.Les groupes locaux peuvent ici être assimilés aux projets et les groupes globaux aux groupes d'utilisateurs. Les rôlesdéfinissent les permissions.

Lorsqu'LDAP est utilisé, l'interface web ne fonctionne pas avec les groupes. En attendant de trouver unesolution à ce problème, les groupes d'utilisateurs ne sont donc pas utilisés.

50 Organizational Unit : un type de branche de l'arborescence LDAP51 Rappelons que le mot "tenant", selon la terminologie de Keystone, est équivalent au mot "projet"

Xavier Buche Cloud universitaire avec OpenStack – CNAM Nord-Pas de Calais 48

Figure 6 : arbre LDAP

ConfigurationPour terminer, il ne reste plus qu'à paramétrer Keystone dans le fichier /etc/keystone/keystone.conf.

# le backend ldap est utilisé pour les parties "identity" et "assignment" :

[identity]

driver = keystone.identity.backends.ldap.Identity

[assignment]

driver = keystone.assignment.backends.ldap.Assignment

[ldap]

# adresse du serveur LDAP local et suffixe de recherche :

url=ldap://localhost

suffix=dc=univ-lille1,dc=fr

# base de recherche pour les utilisateurs :

user_tree_dn=ou=people,dc=univ-lille1,dc=fr

# exemple de filtre : le personnel et les étudiants du FIL peuvent s'authentifier :

user_filter=(|(objectClass=ustlPerson)(ustlDepartement=MASTER-FIL)(ustlDepartement=LICENCE-FIL))

# Keystone reconnaît les objets utilisateurs par la valeur "person" de leur attribut "objectclass" :

user_objectclass=person

# l'identifiant et le nom des utilisateurs dans le contexte d'OpenStack correspondent à la valeurde l'attribut LDAP "uid" :

user_id_attribute=uid

user_name_attribute=uid

# étant donné qu'on ne gère pas les comptes utilisateurs qui, je le rappelle, sont localisés dansles serveurs LDAP du CRI, on ne permet pas à Keystone de les gérer :

user_allow_create=false

user_allow_update=false

user_allow_delete=false

# base de recherche pour les projets :

tenant_tree_dn=ou=tenants,dc=univ-lille1,dc=fr

# les objets "projets" sont de type "organizationalUnit" :

tenant_objectclass=organizationalUnit

# l'identifiant et le nom des projets dans le contexte d'OpenStack correspondent à la valeur de l'attribut LDAP "ou" :

tenant_id_attribute=ou

tenant_name_attribute=ou

# comme les projets sont gérés actuellement avec des scripts (voir le chapitre suivant), on ne permet pas à Keystone de le faire lui-même :

Xavier Buche Cloud universitaire avec OpenStack – CNAM Nord-Pas de Calais 49

tenant_allow_create=false

tenant_allow_update=false

tenant_allow_delete=false

# base de recherche pour les rôles :

role_tree_dn=ou=roles,dc=univ-lille1,dc=fr

# les objets "rôles" sont de type "organizationalRole" :

role_objectclass=organizationalRole

# l'identifiant et le nom des rôles dans le contexte d'OpenStack correspondent à la valeur de l'attribut LDAP "cn" :

role_id_attribute=cn

role_name_attribute=cn

# l'attribut "roleOccupant" contient l'identifiant de l'utilisateur associé à ce rôle :

role_member_attribute=roleOccupant

# comme les rôles sont gérés actuellement avec des scripts, on ne permet pas à Keystone de le faire lui-même :

role_allow_create=false

role_allow_update=false

role_allow_delete=false

Gestion des projets et des rôlesLa gestion des projets et des rôles pourrait être manuelle si elle concernait quelques dizaines d'utilisateurs. Mais pourquelques milliers, l'automatisation est une nécessité.

Les ressources d'OpenStack (machines virtuelles, réseaux, etc.) sont toujours associées à des projets. Il n'est paspossible de lier une ressource à un utilisateur indépendamment d'un projet. Chaque utilisateur doit donc disposer deson propre projet individuel, que l'on peut considérer comme un environnement de travail personnel.

Pour y parvenir, deux solutions sont envisageables :– la solution « intelligente » : on crée le projet d'un utilisateur et on les associe tous les deux à un ou des rôles,

en fonction des informations fournies par le service LDAP du CRI, au moment où cet utilisateur s'authentifiepour la première fois.

– la solution « bête » : pour tous les utilisateurs susceptibles d'utiliser OpenStack, on crée à l'avance un projetpour chacun d'eux et on leur donne un rôle dans ce projet, en fonction des informations fournies par leservice LDAP du CRI.

La première solution est plus complexe, puisqu'elle nécessite d'exécuter une procédure au moment où l'utilisateurs'authentifie. Une déclinaison de cette solution aurait pu consister à développer une page web d'inscription au serviceOpenStack. Les personnes qui s'y inscrivent reçoivent un attribut particulier, ou sont inclus dans un groupe LDAP. Oncrée un projet uniquement pour ces utilisateurs.

Pour l'instant, la solution de simplicité a été choisie : on crée à l'avance les projets et les associations. Etceci se fait par le biais d'un script que j'ai écrit en Python [PUISEUX, 2012] [DUPRÉ, 2011] [CHAZALLET,2014] et qui est lancé régulièrement par le service cron52 de Linux.

Que fait ce script ?– Il définit des rôles en fonction des valeurs des classes d'objet LDAP des utilisateurs. Par exemple, seuls les

utilisateurs de type ustlEtuPerson ont le rôle d'étudiant.– Il crée les nouveaux rôles, les nouveaux projets et leurs associations avec les utilisateurs.

52 le « planificateur de tâches » du monde Unix

Xavier Buche Cloud universitaire avec OpenStack – CNAM Nord-Pas de Calais 50

– Il supprime les rôles, les projets et les associations superflus.– Il modifie les associations en fonction du changement de situation des utilisateurs.– Il définit des exclusions. Par exemple, les projets créés manuellement, comme le projet des services

OpenStack, ne doivent pas être supprimés.– Un mode « simulation » permet de voir ce que le script s'apprête à faire, mais sans que ces actions ne soient

réellement effectuées.– Tout est journalisé.

On peut facilement envisager de futures évolutions. Comme définir des attributs LDAP qui seront utiliséspour créer des projets secondaires. Un chercheur pourrait ainsi se voir automatiquement associé à unprojet OpenStack commun à son équipe, par exemple.

Actuellement un projet du CRI vise à permettre à certains utilisateurs de créer des groupes LDAP via uneinterface web. Même si pour l'instant le besoin ne s'est pas fait sentir, on pourra imaginer, en se basant sur ce futurnouveau service, que le script mentionné précédemment utilise ces groupes pour créer de nouveaux projets. Unenseignant pourrait alors créer lui-même un projet et l'associer à quelques étudiants, par exemple.

4.3.6 VérificationLe composant Keystone est maintenant prêt et les utilisateurs peuvent d'ores et déjà s'authentifier. Pour vérifier quec'est bien le cas, on peut lancer la commande suivante, après avoir rempli les variables d'environnement commel'indique le chapitre ligne de commande, page 36 :

keystone token-get

Cette commande renvoie un message au format JSON (voir le chapitre sur le dialogue avec les API via HTTP, page 37)qui contient un jeton temporaire utilisable pour accéder aux autres services, dont il est désormais temps de parler.

4.4 Glance et les imagesAvant de chercher à instancier une machine virtuelle, ce qui est, finalement, l'une des principales raisons d'être decette plate-forme, il nous faut accéder à des images de machine virtuelle. Une image peut être considérée comme un modèle, une espèce de gabarit servant de base pour les instances demachine virtuelle. C'est le service Glance qui gère les images.

4.4.1 FonctionnementGlance est l'implémentation de l'API image. Il se base sur deux démons :– glance-api, qui traite les requêtes à l'API et y répond– glance-registry, qui gère les métadonnées des images, comme le nom, la taille, etc.

Ces métadonnées sont stockées dans une base de donnée (Mysql, dans notre cas).

4.4.2 ConfigurationLa configuration de Glance est triviale et n'a posé aucun problème particulier.

L'objectif est que chaque utilisateur puisse, selon un certain quota, transférer sur le cloud des images de machinevirtuelle, qui sont alors stockées sur la baie de disques et éventuellement partagées avec d'autres utilisateurs.

On peut définir le type de l'espace de stockage des images en configurant le backend approprié parmi les suivants,notamment :– file (système de fichiers « local »)– http– swift (stockage objet)– s3 (Amazon S3)

Xavier Buche Cloud universitaire avec OpenStack – CNAM Nord-Pas de Calais 51

Nous choisissons le backend file de manière à ce que les images soient enregistrées dans l'arborescence ducontrôleur. Plus précisément dans le répertoire :

/var/lib/glance/images/

Ce répertoire n'est pas sur le contrôleur lui-même, mais sur la baie de stockage, par l'intermédiaire d'un montageNFS53 réalisé par la ligne suivante dans le fichier /etc/fstab :

filer:/vol/vol1/images /var/lib/glance/images nfs rw 0 0

Ceci pour deux raisons :– L'espace disque de la baie de stockage est beaucoup plus important (plusieurs téraoctets contre environ

300 Go sur le contrôleur).– La reprise sur panne du contrôleur primaire vers le secondaire est largement simplifié, puisque le partage

NFS de la baie est accessible sur les deux contrôleurs.

J'ajoute ensuite les directives suivantes dans le fichier /etc/glance/glance-api.conf :default_store = file

filesystem_store_datadir = /var/lib/glance/images/

Il est utile de savoir qu'il est possible de définir plusieurs répertoires différents. Dans l'avenir, en cas depénurie d'espace disque sur notre baie de stockage, nous pourrons facilement ajouter de l'espacesupplémentaire provenant d'une autre source.

4.4.3 Gestion des imagesDes images de la plupart des systèmes d'exploitation et distributions Linux ont été adaptées à une utilisation avecOpenStack par leurs éditeurs.Commençons par télécharger une de ces images. Par exemple, la dernière et toute fraîche émoulue version de Debian,disponible à cette adresse :

http://cloudfront.debian.net/cdimage/OpenStack/current/debian-8.1.0-OpenStack-amd64.qcow2

Une fois sur mon poste de travail, je peux créer, sur la plate-forme OpenStack, une image basée sur cette distributionen lançant la commande :

glance image-create --name debian-jessie --file /tmp/debian-8.1.0-OpenStack-amd64.qcow2 --disk-format qcow2 --container-format bare --is-public False --is-protected True --progress

Détaillons les quelques paramètres utilisés ici :– name : le nom de l'image vu sous OpenStack– file : le fichier local utilisé pour créer l'image– is-public : une image publique est visible par tous les utilisateurs, alors qu'une image privée est visible, par

défaut, uniquement par son propriétaire. Mais nous verrons plus loin qu'un utilisateur peut changer lavisibilité d'une image en la partageant.

– protected : certaines métadonnées ne sont pas modifiables, et certaines actions sont bloquées (par exemple, lasuppression d'une image protégée est impossible)

– progress : fait apparaître un indicateur de la progression de la création de l'image– container-format : un conteneur est un fichier qui contient une image de machine virtuelle et des

metadonnées). OpenStack connaît les types de conteneurs suivants :– bare : pas de conteneur– OVF (Open Virtualization Format) : format de package contenant des images de machine virtuelle– AMI/AKI/ARI : utilisés sur le cloud public Amazon

– disk-format : indique le format de l'image, qui peut être :– raw : copie bit à bit d'un disque, en mode bloc– Qcow2 (QEMU copy-on-write version 2) : fournit des fonctionnalités supplémentaires (CoW, snapshot,

etc.)

53 Network File System, un protocole d'accès à des fichiers par le réseau

Xavier Buche Cloud universitaire avec OpenStack – CNAM Nord-Pas de Calais 52

– AMI/AKI/ARI : formats utilisés sur le cloud Amazon– VMDK (Virtual Machine Disk) : format de Vmware– VDI (Virtual Disk Image) : format d'Oracle Virtualbox (n'est supporté par aucun des hyperviseurs utilisés

avec OpenStack)– VHD (Virtual Hard Disk) et VHDX : formats de Microsoft Hyper-V– ISO : image disque formatée avec le système de fichiers en lecture seule ISO 9660 souvent utilisé sur les

CD et DVD

Nous verrons plus loin qu'OpenStack se charge, au moment de la création d'une instance de machine virtuelle, deconvertir l'image dans un format utilisable avec les hyperviseurs situés sur les nœuds de calcul.

Les métadonnées associées aux images par Glance ou incluses dans les conteneurs peuvent être utilisées par certainscomposants d'OpenStack. Par exemple l'ordonnanceur de Nova peut choisir le nœud sur lequel sera exécutéel'instance de la machine virtuelle en fonction de la valeur de certaines métadonnées d'image.

Plutôt que de télécharger le fichier image sur mon poste et de le transférer, dans un second temps, sur la plate-formeOpenStack, il est possible de demander à Glance de récupérer l'image à la source, en lui indiquant l'adresse HTTP oùelle se trouve :

glance image-create --name debian-jessie --location http://cloudfront.debian.net/cdimage/OpenStack/current/debian-8.1.0-OpenStack-amd64.qcow2 --disk-format qcow2 --container-format bare --is-public False --is-protected True

L'option --file a été remplacée par --location, suivie de l'URL du fichier.

A noter que l'option --progress n'est pas utilisable avec l'option --location.

Quelques secondes plus tard, on peut vérifier que l'image a correctement été créée :glance image-list

+--------------------------------------+-------------+-------------+------------------+-------------+--------+ | ID | Name | Disk Format | Container Format | Size | Status | +--------------------------------------+-------------+-------------+------------------+-------------+--------+ | ce94138b-31be-4199-ab79-934f1b161ca5 | debian-test | qcow2 | bare | 480938496 | active | +--------------------------------------+-------------+-------------+------------------+-------------+--------+

glance image-show debian-test

+------------------+--------------------------------------+ | Property | Value | +------------------+--------------------------------------+ | container_format | bare | | created_at | 2015-04-13T12:13:29 | | deleted | False | | disk_format | qcow2 | | id | ce94138b-31be-4199-ab79-934f1b161ca5 | | is_public | False | | min_disk | 0 | | min_ram | 0 | | name | debian-test | | owner | buche | | protected | True | | size | 480938496 | | status | active | | updated_at | 2015-07-13T12:13:29 | +------------------+--------------------------------------+

Le statut d'une image peut être :– queued : un identifiant a été réservé mais l'image n'a pas encore été transmise– saving : l'image est en cours de transfert– active : l'image est disponible– killed : une erreur s'est produite durant le transfert et l'image est illisible– deleted : l'image n'est plus disponible et sera supprimée– pending_delete : l'image n'est plus disponible, mais peut encore être récupérée car les données sont encore

accessibles

Xavier Buche Cloud universitaire avec OpenStack – CNAM Nord-Pas de Calais 53

Maintenant je veux partager mon image avec un autre utilisateur :glance member-create debian-test pinocchio

Dans cet exemple, Pinocchio pourra désormais utiliser mon image pour créer une instance de machine virtuelle. Maisil ne pourra pas la partager. A moins que je le précise :

glance member-create --can-share debian-test pinocchio

S'il le souhaite, Pinocchio peut récupérer l'image de Debian sur son poste de travail :glance image-download --file /tmp/debian8.qcow2 --progress debian-jessie

Pour finir, essayons de supprimer cette image de test :glance image-delete debian-jessie

Request returned failure status.

403 Forbidden

Image is protected

(HTTP 403): Unable to delete image debian-test

Rappelons-nous qu'une image « protégée » ne peut pas être détruite. Il faut donc d'abord changer la valeur de lamétadonnée :

glance image-update --is-protected False debian-test

Tous les éléments sont désormais réunis pour que l'on passe à la configuration du cœur d'OpenStack : Nova.

4.5 Nova et les machines virtuellesAvec ce chapitre, nous entrons dans les entrailles du système OpenStack. Car Nova en est la brique essentielle, et sanselle, l'édifice est sans fondement.

En substance, le rôle de Nova est de gérer les instances de machine virtuelle, c'est-à-dire les créer, les redémarrer, lessupprimer, etc. Mais il peut faire bien davantage, car souvenons-nous que, dans son plus jeune âge, OpenStackreposait uniquement sur Nova et sur Cinder. Nova est maintenant considéré comme trop gros et trop complexe. La tendance actuelle est donc à l'amaigrissement :on élimine certaines de ses fonctions et on les intègre dans d'autres composants créés de toute pièce. Évidemment onen profite pour apporter une bonne dose de nouveautés. Je pense en particulier à Neutron, qui remplace Nova-network ; ou encore à Ceilometer, qui récupère la métrologie.

4.5.1 Vue d'ensembleBien qu'il soit l'élément le plus important, Nova n'est pas une exception. Il fonctionne de la même manière que lesautres composants de la plate-forme : une série de démons communiquent ensemble via la messagerie AMQP etstockent leurs informations dans une base de données. La communication avec les autres composants et avec lesutilisateurs se fait par l'intermédiaire d'une API.

Le démon nova-api implémente la spécification de l'API compute. Il implémente également l'API EC2 pour assurer lacompatibilité avec le cloud public d'Amazon. Il reçoit les requêtes des utilisateurs ou des autres composantsd'OpenStack et y répond. Enfin, il initie la plupart des actions de gestion des instances de machine virtuelle enenvoyant des messages sur la queue.

Ces messages sont traités par nova-scheduler, qui détermine sur quel nœud de calcul doivent être exécutées lesactions. Sur le nœud choisi, nova-compute transforme la requête en une série de commandes envoyées à l'API del'hyperviseur. Le résultat, par exemple l'état d'une instance qui vient d'être créée, est envoyé au démon nova-conductor sur le contrôleur pour être enregistré dans la base de données.

Xavier Buche Cloud universitaire avec OpenStack – CNAM Nord-Pas de Calais 54

4.5.2 L'hyperviseurL'un des avantages d'OpenStack est qu'il est capable de fonctionner avec les principales solutions de virtualisationactuelles. Nous avons donc l'embarras du choix.

Au moins dans un premier temps, nous allons éviter les solutions propriétaires : Vmware, Microsoft Hyper-V. Lapremière raison relève de la doctrine. Une université publique comme la nôtre est l'environnement idéal pourprivilégier les logiciels libres. La plupart des enseignants-chercheurs travaillent sur des produits à code source ouvertet une bonne part des administrateurs systèmes sont compétents dans leur utilisation. Par ailleurs, une consigneexplicite de notre ministère indique que les logiciels libres doivent être utilisés en priorité [Loi Fioraso].

Mais cet argument n'est pas suffisant : selon moi, les motifs de choix purement pragmatiques doivent prendre le passur les grands principes. Or, dans notre cas et sur ce plan, les deux solutions commerciales posent problème.

VMware ESXi est certes gratuit, mais il n'est utilisable avec OpenStack qu'en lecture seule. Autrement dit, on peutafficher et accéder à des ressources déjà existantes, mais on ne peut pas en créer de nouvelles. Pour cela, il faudraitinvestir dans la solution basée sur vCenter.Néanmoins, gardons à l'esprit que l'idée même de ce projet de cloud privé est notamment partie du constat que, dansles conditions tarifaires actuelles, la solution de virtualisation du CRI, basée sur VMware, ne pourrait pas être mise àl'échelle. Par conséquent, le critère du coût est à considérer comme essentiel.

Quant à Hyper-V, même s'il est gratuit, il n'apporte aucun avantage par rapport aux hyperviseurs libres, et il requiertl'utilisation de machines hôtes dont le système d'exploitation est celui de Microsoft.

Quoiqu'il en soit, nous n'excluons pas l'utilisation de ces hyperviseurs dans l'avenir. Par exemple, pourcoupler OpenStack avec des plates-formes de virtualisation existantes (au CRI ou ailleurs). Nous verronsun peu plus loin qu'OpenStack est capable de contrôler plusieurs systèmes de virtualisationsimultanément.

Les principaux hyperviseurs libres sont Xen et KVM. Comme il en a déjà été fait mention dans le chapitred'introduction au cloud computing, page 14, ils sont tous deux très performants. A priori, le choix n'est pas simple. J'aiune plus grande expérience de Xen, mais KVM est plus facile d'utilisation.

Pour simplifier ce choix cornélien, OpenStack nous met à disposition une matrice de comparaison desdifférents hyperviseurs [Hypervisor support matrix]. Ce tableau montre que les fonctionnalités des deuxpilotes sont quasi-identiques. Cependant, les hyperviseurs sont classés en trois catégories, selon leurniveau de support et d'intégration. Et il s'avère que KVM est le seul membre de la première catégorie, etdemeure la solution privilégiée pour les développements d'OpenStack. Nous nous sommes donc focalisésur cet hyperviseur.

Pour préciser à un nœud de calcul quel hyperviseur utiliser, il suffit de modifier le fichier /etc/nova/nova.conf. Parexemple, si je souhaite utiliser KVM :

[libvirt]

virt_type = kvm

Ensuite il faut redémarrer nova :service nova-compute restart

Bien sûr KVM doit être installé :apt-get install kvm

A ce stade, le lecteur attentif que vous êtes objectera sans doute que j'ai omis de faire mention d'une alternativeintéressante à la virtualisation, et dont j'ai parlé succinctement au début de ce mémoire : l'isolation.Cette technologie consiste à cloisonner l'environnement d'exécution des applications dans des zones qui partagententre elles le noyau du système hôte. Ici, aucune pénalité sur les performances, contrairement à la virtualisation. Parcontre, l'isolement des processus est moins fort : par exemple, si une application malveillante parvient à exploiter unefaille du noyau, alors tous les autres conteneurs en subiront le préjudice. Précisons de surcroît que l'isolation est une technique propre aux systèmes de type Unix (Linux, *BSD, Solaris, etc.).Tout autre système d'exploitation, comme Microsoft Windows, est donc exclu.

Xavier Buche Cloud universitaire avec OpenStack – CNAM Nord-Pas de Calais 55

En outre, LXC54, le système d'isolation pris en charge par OpenStack, reste moins bien et plus récemment supporté etintégré55 que KVM ou Xen.

Signalons, pour être complet, qu'en plus de la virtualisation et de l'isolation, OpenStack permet de gérerdes machines physiques (bare metal).

4.5.3 L'ordonnanceurAvant qu'une instance de machine virtuelle ne soit provisionnée, l'ordonnanceur 56 de Nova sélectionne un nœud decalcul sur lequel sera exécutée l'instance. Comment le choisit-il ?

En deux étapes :– Le filtrage, qui élimine les nœuds qui ne satisfont pas une série de critères déterminés. Par exemple, le filtre

ComputeFilter supprime les hôtes inactifs, tandis que RamFilter exclut les nœuds qui ne disposent pas desuffisamment de mémoire.

– La pondération, qui classe, selon des critères définis, les nœuds sélectionnés à l'étape précédente.

Actuellement, la seule métrique utilisable pour la pondération est la mémoire vive. Autrement dit,l'ordonnanceur répartit les machines virtuelles sur les machines hôtes en se basant uniquement sur lamémoire libre. Il faut reconnaître qu'il est surprenant que d'autres critères ne puissent être employés pourchoisir les machines cibles. Cela dit, celui de la mémoire est le seul vraiment nécessaire, car la mémoireest le seul élément qui ne se partage pas, contrairement aux processeurs, à la bande passante réseau, etc.

Un blueprint57 appelé Scheduling based on actual utilization [Utilization based scheduling] permettraéventuellement, dans de futures versions d'OpenStack, de définir nous-mêmes des critères de pondérationsupplémentaires, comme le nombre de processeurs occupés.

D'autre part, un filtre appelé CoreFilter exclut les nœuds qui n'ont aucun processeur libre. Avec ce filtre, il est possiblede surévaluer le nombre de processeurs réels58 en les associant dynamiquement à des processeurs virtuels (vCPU)selon un certain ratio spécifié par la directive cpu_allocation_ratio.

Exemple : avec les paramètres suivants, au maximum huit instances pourront se partager un processeurréel.

scheduler_default_filters = ..., CoreFilter, ...

cpu_allocation_ratio=8.0

Au moins dans un premier temps, nous n'utiliserons pas ce filtre. En d'autres termes, le seul élément limitant sera lamémoire vive. Si, en moyenne, les machines virtuelles utilisent un seul vCPU et peu de mémoire, par exemple 1 Go,alors notre système OpenStack exécutera simultanément au maximum environ 1000 machines sur environ 100processeurs. Donc chaque processeur exécutera, dans ce cas défavorable, environ 10 vCPU. Savoir si ce ratio estraisonnable dépend de l'usage qui sera fait des machines (calcul, développement, services web…).

En définitive, il sera nécessaire de superviser correctement la consommation des ressources (voir le chapitre 4.9 surCeilometer et celui sur la supervision), de manière à modifier la configuration de l'ordonnanceur ou ajouter dumatériel supplémentaire en fonction des besoins.

A ce propos, il est à noter que l'extension des capacités d'un système informatique se fait généralement demanière verticale (scale up), c'est-à-dire qu'on ajoute des éléments (mémoire vive, mémoire de masse,processeurs) à un serveur existant. A l'inverse, OpenStack tend à faciliter l'extension horizontale ( scaleout), où il suffit d'ajouter des machines supplémentaires à un cluster. Dans ce cas, l'augmentation descapacités est presque sans limite.

54 Linux Container55 De nombreuses fonctionnalités manquent à l'appel, comme le montage de volumes, la mise en veille d'une instance ou la migration d'un hôte

vers un autre.56 ou scheduler57 les blueprints définissent des plans détaillés des améliorations programmées d'OpenStack58 processeurs vus par le système d'exploitation, qui ne correspondent pas, en fait, à des processeurs réels, car la technologie de l'hyperthreading

est activée (voir chapitre sur les choix matériels)

Xavier Buche Cloud universitaire avec OpenStack – CNAM Nord-Pas de Calais 56

Enfin, il est possible de remplacer le scheduler par défaut par notre propre version, sous la forme d'une classe écriteen Python. Mais nous ne le prévoyons pas car celui fourni par OpenStack convient finalement très bien.

4.5.4 Partitionnement

4.5.4.1 Agrégats d'hôtesL'ordonnanceur de Nova permet de sélectionner des nœuds candidats en fonction du groupe auquel ils appartiennent,grâce au filtre AggregateInstanceExtraSpecsFilter. Ces groupes se nomment agrégats d'hôtes. Généralement lesmachines regroupées dans ces agrégats ont des caractéristiques communes, qui sont précisées dans les métadonnéesassociées à l'agrégat. Par exemple, des machines disposant de nombreux et puissants processeurs pourraient êtregroupées dans un agrégat d'hôtes.

Par ailleurs, lorsqu'un utilisateur décide de lancer l'instance d'une nouvelle machine virtuelle, il doit, entre autres,choisir un type d'instance (flavor). Ce paramètre caractérise les capacités physiques de la machine. Il définit deséléments comme la quantité de mémoire vive, la taille du disque système, ou encore le nombre de processeurs. Maison peut également préciser des spécifications « sur mesure » (xtra_specs).

Lors de la création d'une instance, l'ordonnanceur va effectuer sa sélection parmi les hôtes qui appartiennent àl'agrégat dont les métadonnées correspondent aux spécifications précisées par le type d'instance.

Exemple :

– je crée d'abord un nouvel agrégat nommé calcul :nova aggregate-create calcul

+----+--------+-------------------+-------+----------+

| Id | Name | Availability Zone | Hosts | Metadata |

+----+--------+-------------------+-------+----------+

| 3 | calcul | - | | |

+----+--------+-------------------+-------+----------+

– j'associe à cet agrégat des métadonnées sous la forme d'un couple clef-valeur :nova aggregate-set-metadata calcul calcul=true

Metadata has been successfully updated for aggregate 3.

+----+--------+-------------------+-------+---------------+

| Id | Name | Availability Zone | Hosts | Metadata |

+----+--------+-------------------+-------+---------------+

| 3 | calcul | - | | 'calcul=true' |

+----+--------+-------------------+-------+---------------+

– j'ajoute un nœud de calcul dans cet agrégat :nova aggregate-add-host calcul compute4

Host compute4 has been successfully added for aggregate 3

+----+--------+-------------------+------------+---------------+

| Id | Name | Availability Zone | Hosts | Metadata |

+----+--------+-------------------+------------+---------------+

| 3 | calcul | - | 'compute4' | 'calcul=true' |

+----+--------+-------------------+------------+---------------+

Xavier Buche Cloud universitaire avec OpenStack – CNAM Nord-Pas de Calais 57

– je crée un type d'instance spécialisé dans le calcul :nova flavor-create calcul_rapide auto 8192 10 4

+--------------------------------------+---------------+-----------+------+-----------+------+-------+-------------+-----------+

| ID | Name | Memory_MB | Disk | Ephemeral | Swap | VCPUs | RXTX_Factor | Is_Public |

+--------------------------------------+---------------+-----------+------+-----------+------+-------+-------------+-----------+

| 74dec7b8-398f-44f0-8c48-0485a8e8e1f3 | calcul_rapide | 8192 | 10 | 0 | | 4 | 1.0 | True |

+--------------------------------------+---------------+-----------+------+-----------+------+-------+-------------+-----------+

– j'associe ce nouveau type avec le couple clef-valeur défini précédemment :nova flavor-key calcul_rapide set aggregate_instance_extra_specs:calcul=true

Ici un petit aparté s'impose. Côté agrégat, j'ai nommé la clef calcul. Alors que pour le type d'instance, je suis obligé depréciser l'espace de noms dans lequel se trouve ma clef (aggregate_instance_extra_specs:calcul). C'est que ces attributspeuvent être utilisés par d'autres filtres.Par exemple, si je ne précise pas l'espace de noms, le filtre ComputeCapabilitiesFilter va rechercher, sans succès, la clefcalcul parmi les attributs xtra_specs propres aux nœuds de calcul. Et donc ce filtre indiquera qu'aucun hôte n'a lescapacités d'exécuter l'instance.C'est d'ailleurs l'erreur que j'ai commise avant de m'en rendre compte en lisant le journal de l'ordonnanceur(/var/log/nova/nova-scheduler.log), qui indiquait alors :

INFO nova.filters [req-a59fa785-2b34-4633-a97c-a13c5debaed7 buche projet_test] Filter ComputeCapabilitiesFilter returned 0 hosts

– enfin je vérifie les valeurs en affichant le détail du nouveau type d'instancenova flavor-show calcul_rapide

+----------------------------+---------------------------------------------------+

| Property | Value |

+----------------------------+---------------------------------------------------+

| OS-FLV-DISABLED:disabled | False |

| OS-FLV-EXT-DATA:ephemeral | 0 |

| disk | 10 |

| extra_specs | {"aggregate_instance_extra_specs:calcul": "true"} |

| id | 74dec7b8-398f-44f0-8c48-0485a8e8e1f3 |

| name | calcul_rapide |

| os-flavor-access:is_public | True |

| ram | 8192 |

| rxtx_factor | 1.0 |

| swap | |

| vcpus | 4 |

+----------------------------+---------------------------------------------------+

– dernière étape : activer le filtre AggregateInstanceExtraSpecsFilter en l'ajoutant à la directivescheduler_default_filters du fichier /etc/nova/nova.conf :scheduler_default_filters=AggregateInstanceExtraSpecsFilter,RamFilter,ComputeFilter,AvailabilityZoneFilter,ComputeCapabilitiesFilter,ImagePropertiesFilter,ServerGroupAntiAffinityFilter,ServerGroupAffinityFilter

Désormais, toutes les instances de type calcul_rapide sont orientées vers le nœud compute4 par l'ordonnanceur.

Comme le démontre ce cas d'utilisation, cette méthode de regroupement des hôtes offre des perspectivesintéressantes. Au delà de cet exemple basique, il est également possible de définir différents ratiosd'utilisation CPU ou RAM avec les filtres AggregateCoreFilter et AggragateRamFilter et les clefscpu_allocation_ratio et ram_allocation_ratio. Un type d'instance calcul pourrait donc avoir un ratio

d'utilisation CPU de 1. Les instances de ce type monopoliseraient donc les processeurs sur lesquels elles tournent.Je mettrai en production ces fonctionnalités si le besoin se manifeste.

Xavier Buche Cloud universitaire avec OpenStack – CNAM Nord-Pas de Calais 58

4.5.4.2 Zone de disponibilitéImaginons qu'un utilisateur souhaite mettre en ligne un nouveau service. Comme ce service est important, il doit êtreredondant. Or si la redondance est assurée par deux machines virtuelles situées sur la même machine physique, alorsla redondance sera uniquement virtuelle et par conséquent d'un intérêt plutôt restreint.Pour augmenter nettement le degré de disponibilité de son service, l'utilisateur doit avoir la certitude que laredondance est matérielle. En d'autres termes, les instances doivent être situées sur des machines physiquesdifférentes, avec une alimentation électrique et une connectivité réseau aussi distinctes que possible. L'utilisateurchoisira donc, lors de la création de ses instances, des zones de disponibilité différentes. Voilà un cas d'utilisationclassique.

Comme vous le constatez probablement, le concept de zone de disponibilité est assez proche de celui d'agrégatd'hôtes. La principale différence réside dans son utilisation : la zone de disponibilité est choisie par l'utilisateur, alorsque le choix de l'agrégat se fait par l'ordonnanceur, via des métadonnées. On pourrait résumer la chose en disantqu'une zone de disponibilité n'est rien d'autre qu'un agrégat d'hôtes que l'utilisateur peut choisir explicitement.

C'est d'ailleurs exactement de cette manière que l'on crée une zone de disponibilité :

– je modifie l'agrégat créé précédemment en laissant son nom inchangé et en indiquant qu'il s'agit égalementd'une zone de disponibilité nommée calcul-zd :nova aggregate-update calcul calcul calcul-zd

Aggregate 3 has been successfully updated.

+----+--------+-------------------+------------+-------------------------------+

| Id | Name | Availability Zone | Hosts | Metadata |

+----+--------+-------------------+------------+-------------------------------+

| 3 | calcul | calcul-zd | 'compute4' | 'availability_zone=calcul-zd' |

+----+--------+-------------------+------------+-------------------------------+

– quand je lance une instance, je précise la zone de disponibilité :nova boot --flavor normale --image Ubuntu-Trusty --availability-zone calcul-zd --nic net-id=11c5b2b2-c022-44b7-ac1d-18a0a4d82ede instance

– une fois démarrée, l'instance apparaît bien comme faisant partie de la zone de disponibilité calcul-zd :nova show instance

+--------------------------------------+----------------------------------------------------------+

| Property | Value |

+--------------------------------------+----------------------------------------------------------+

| Accès campus network | 10.10.6.25 |

| OS-DCF:diskConfig | MANUAL |

| OS-EXT-AZ:availability_zone | calcul-zd |

| OS-EXT-SRV-ATTR:host | compute4 |

| OS-EXT-SRV-ATTR:hypervisor_hostname | compute4 |

| OS-EXT-SRV-ATTR:instance_name | instance-00000f1a |

| OS-EXT-STS:power_state | 1 |

| OS-EXT-STS:task_state | - |

| OS-EXT-STS:vm_state | active |

| OS-SRV-USG:launched_at | 2015-03-21T08:18:10.000000 |

| OS-SRV-USG:terminated_at | - |

| accessIPv4 | |

| accessIPv6 | |

| config_drive | |

| created | 2015-03-21T08:17:31Z |

| flavor | normale (e5367872-27cb-414a-bac8-1be2c9474aa0) |

| hostId | 0bc668850a36d5e61ecaf27701dddadf0ab5bd8f3edcb45c421f9352 |

Xavier Buche Cloud universitaire avec OpenStack – CNAM Nord-Pas de Calais 59

| id | 6ae5984d-5994-4e2a-b631-59ca7daae646 |

| image | Ubuntu-Trusty (bb62bddb-4f9b-4589-8302-7cc70ddbdb17) |

| key_name | - |

| metadata | {} |

| name | instance |

| os-extended-volumes:volumes_attached | [] |

| progress | 0 |

| security_groups | default |

| status | ACTIVE |

| tenant_id | buche |

| updated | 2015-03-21T08:18:10Z |

| user_id | buche |

+--------------------------------------+----------------------------------------------------------+

On ne peut pas affecter plusieurs zones de disponibilité à un même agrégat d'hôtes. Par contre, il est possibled'associer plusieurs agrégats à une même zone de disponibilité. Dans ce cas, cette zone contiendra la somme des hôtesappartenant aux différents agrégats. Pour conclure sur les zones de disponibilité, elles ne sont que des agrégats exposés aux utilisateurs. Contrairement àce que leur nom laisse penser, elles ne sont donc pas réduites aux cas d'utilisation cité plus haut. On pourrait tout àfait, par exemple, les utiliser pour donner aux utilisateurs le choix du système de virtualisation (KVM, LXC, etc.).

4.5.5 DistributionLes agrégats et les zones seront de bons moyens, à court terme, de segmenter notre plate-forme en fonction desbesoins. A plus long terme, il sera possible d'« orchestrer » des plates-formes situées sur des sites éloignés grâce aumécanisme des cellules et à celui des régions.

On peut ainsi envisager, dans la dynamique impulsée par le regroupement à venir des universités de Lille,que plusieurs sites géographiques soient utilisés pour héberger le cloud OpenStack.

4.5.5.1 CellulesComme nous l'avons vu, l'ordonnanceur de Nova permet de répartir les instances sur les nœuds de calcul. Il permetégalement de les distribuer sur des cellules, c'est-à-dire des infrastructures OpenStack à part entière.Ce concept de cellule permet d'ajouter un niveau supplémentaire de répartition des instances :– l'API de Nova et un ordonnanceur tournent sur un contrôleur central, ainsi que le service Keystone et

l'interface web Horizon– tous les autres services (sauf nova-compute) tournent sur des contrôleurs répartis– les démons nova-compute sont exécutés sur les nœuds de calcul

Selon la documentation d'OpenStack, ce système est encore expérimental à l'heure actuelle.

4.5.5.2 RégionsComme les cellules, les régions permettent de réaliser un déploiement distribué d'OpenStack. Mais contrairement àcelles-ci, les instances ne sont pas réparties automatiquement dans les différentes régions. C'est à l'utilisateur depréciser la région dans laquelle il souhaite gérer son infrastructure virtuelle. Seuls Keystone, pour l'authentification etla gestion des permissions, et Horizon, pour l'interface web, sont centralisés. C'est donc au niveau de ces deuxcomposants qu'il faut configurer les régions. En particulier, Keystone doit connaître les URL des points d'accès auxservices de chaque région. De cette manière, il aiguille un utilisateur vers le contrôleur correspondant à la région qu'ila indiquée.

Encore une fois, il ne faut pas se fier aux apparences : les régions, contrairement à ce qu'évoque leur nom, ne sont pasutilisées uniquement pour une répartition géographique des services d'OpenStack. Elles peuvent tout à fait êtreutilisées au sein d'un même centre de données, dans un objectif de redondance, par exemple.

Xavier Buche Cloud universitaire avec OpenStack – CNAM Nord-Pas de Calais 60

4.5.6 Focus sur les instancesVoyons maintenant comment se déroule le processus de création d'une instance de machine virtuelle, tel que je l'aiconfiguré. Commençons par une vision simplifiée :

1. Une fois que l'ordonnanceur a choisi un nœud de calcul, un message AMQP est envoyé à destination du servicenova-compute de cet hôte. Ce message précise notamment les caractéristiques de l'instance.

2. Nova envoie alors une requête à l'API de Glance pour qu'il transfère l'image de la machine virtuelle sur l'hôteconcerné.

3. Le service nova-compute de cet hôte copie l'image de la machine virtuelle dans un fichier qui sera le disquesystème de la machine virtuelle.

4. Nova-compute donne à l'hyperviseur l'ordre de démarrer l'instance, en lui précisant notamment le nom du fichierdu disque système, ainsi que les caractéristiques de la machine (nombre de processeurs, quantité de mémoire, etc.).

Pour améliorer l'efficacité de cet enchaînement, ajoutons quelques précisions.

4.5.6.1 Optimisations

Cache des imagesD'abord, concernant la deuxième étape : pour éviter d'avoir à transmettre l'image à chaque nouvelle créationd'instance, un cache est utilisé sur les nœuds de calcul.Au moment de la création, nova-compute consulte le répertoire /var/lib/nova/instances/_base. Si une copie de l'imagerequise n'y figure pas, un ordre est passé à Glance pour qu'il la transfère. Si elle y est déjà présente, alors le transfertest inutile et on peut passer directement à l'étape suivante en gagnant un temps non négligeable (à titre d'exemple,une image de Microsoft Windows serveur standard « pèse » 16 Go, au bas mot…).

Ce mécanisme de cache est tout à fait bénéfique. Cependant il l'est d'autant moins que le nombre de nœuds de calculest grand, car le cache est local à chacun de ces nœuds. Le chapitre suivant, sur le stockage des instances, montreracomment nous pallions ce problème.

Format rawLa deuxième optimisation a trait à la manière dont sont stockés les fichiers du cache. Pour en augmenter lesperformances d'accès en lecture et en écriture, ces copies d'images sont converties au format raw. Ce format offredeux avantages :– le mode sparse est utilisé de manière à ce que le fichier occupe, sur le disque physique de l'hôte, non pas la

taille totale du disque virtuel de l'instance, mais uniquement l'espace utilisé par les données– le format raw élimine la pénalité sur les performances de l'éventuelle compression des données au format

Qcow2

Exemple du fichier cache d'une image de Linux Ubuntu :ls -lsh /var/lib/nova/instances/_base/a302dc0ade83d1f9794886f528b4c26bad8ab5c9

811M -rw-r--r-- 1 libvirt-qemu kvm 2,2G juil. 22 08:05 /var/lib/nova/instances/_base/a302dc0ade83d1f9794886f528b4c26bad8ab5c9

Xavier Buche Cloud universitaire avec OpenStack – CNAM Nord-Pas de Calais 61

Figure 7 : processus de création d'une instance de machine virtuelle

contrôleur

image

transfert de l'image

noeud de calcul

disqueinstance

copie

qemu-img info /var/lib/nova/instances/_base/a302dc0ade83d1f9794886f528b4c26bad8ab5c9

image: /var/lib/nova/instances/_base/a302dc0ade83d1f9794886f528b4c26bad8ab5c9

file format: raw

virtual size: 2.2G (2361393152 bytes)

disk size: 811M

Le disque système des machines virtuelles qui utilisent cette copie d'image a une taille de 2,2 Go et contient 811 Mode données. Sur le disque physique de la machine hôte, seuls 811 Mo sont réellement occupés.

Pour utiliser le format raw, j'ai activé la directive force_raw_images dans le fichier /etc/nova/nova.conf sur les nœudsde calcul :

force_raw_images=True

Format qcow2L'amélioration qui suit est liée à l'étape 3. Plutôt que de recopier entièrement le fichier de base, situé dans le cache,avant de pouvoir lancer la machine virtuelle, j'ai configuré nova de manière à tirer parti d'une technique parfaitementadaptée à notre cas de figure. Il s'agit du Copy on Write.

Prenons l'exemple du disque système d'une instance basée sur l'image précédente :qemu-img info /var/lib/nova/instances/a2f6a4f9-df32-4df9-989a-83ad0112f5dc/disk

image: disk

file format: qcow2

virtual size: 10G (10737418240 bytes)

disk size: 66M

cluster_size: 65536

backing file: /var/lib/nova/instances/_base/a302dc0ade83d1f9794886f528b4c26bad8ab5c9

Format specific information:

compat: 1.1

lazy refcounts: false

Ce système est basé sur le format Qcow259, dont il tire sont nom. Comme on peut le constater dans cet exemple, lesmétadonnées incluses dans ce fichier indiquent l'emplacement d'un backing file, qui est le fichier image du cache,accessible uniquement en lecture. Les écritures disques sont, quant à elles, réalisées dans le fichier disk propre àl'instance. Le disque système vu par l'instance est la réunion de l'image et du fichier d'instance, qui contient toutes lesmodifications de l'image depuis la création de la machine virtuelle.

Cette méthode rend la création de l'instance beaucoup plus rapide que de recopier entièrement le fichier image. Deplus, et surtout, elle permet une économie d'espace disque considérable, puisque les données ne sont jamaisdupliquées.

Cette fonctionnalité est activée en donnant la valeur True à la variable use_cow_images du fichier /etc/nova/nova.confsitué sur les nœuds de calcul :

use_cow_images=True

Enfin, le format Qcow2 dispose, comme le format raw, d'un mode sparse qui permet de consommer, sur le disque del'hôte, uniquement les données stockées sur le disque virtuel, et non la totalité de l'espace du disque virtuel.

RedimensionnementRemarquons au passage que la taille du disque virtuel de l'exemple précédent a changé : la taille du disque de l'imageétait de 2,2 Go. Maintenant, sur l'instance, elle est de 10 Go. C'est que la machine virtuelle que j'ai créée pour cetexemple est basée sur un type d'instance dont le disque système a une taille de 10 Go. Donc lors du processus decréation de l'instance, il a fallu redimensionner le disque virtuel et le système de fichiers.

59 QEMU Copy On Write

Xavier Buche Cloud universitaire avec OpenStack – CNAM Nord-Pas de Calais 62

C'est nova-compute qui effectue cette tâche avec la fonction suivante, située dans /usr/lib/python2.7/dist-packages/nova/virt/disk/api.py, sur les nœuds de calcul :

def extend(image, size, use_cow=False):

"""Increase image to size."""

if not can_resize_image(image, size):

return

utils.execute('qemu-img', 'resize', image, size)

# if we can't access the filesystem, we can't do anything more

if not is_image_partitionless(image, use_cow):

return

def safe_resize2fs(dev, run_as_root=False, finally_call=lambda: None):

try:

resize2fs(dev, run_as_root=run_as_root, check_exit_code=[0])

except processutils.ProcessExecutionError as exc:

LOG.debug(_("Resizing the file system with resize2fs "

"has failed with error: %s"), exc)

finally:

finally_call()

# NOTE(vish): attempts to resize filesystem

if use_cow:

if CONF.resize_fs_using_block_device:

# in case of non-raw disks we can't just resize the image, but

# rather the mounted device instead

mounter = mount.Mount.instance_for_format(

image, None, None, 'qcow2')

if mounter.get_dev():

safe_resize2fs(mounter.device,

run_as_root=True,

finally_call=mounter.unget_dev)

else:

safe_resize2fs(image)

Ce code utilise d'abord la commande qemu-img resize pour changer la taille du disque virtuel. Ensuite, ça secomplique, car il faut « monter » le disque virtuel pour pouvoir y accéder depuis la machine hôte et redimensionnerle système de fichiers. C'est la méthode mount.Mount.instance_for_format qui s'en charge.

Comme le code nous le montre, le redimensionnement du système de fichiers dépend de deux éléments :– le disque virtuel ne doit pas être partitionné– la directive resize_fs_using_block_device doit être activée dans /etc/nova/nova.conf

Nous décidons de conserver la valeur par défaut de cette directive, qui est désactivée pour des raisons desécurité. Car monter le disque d'une instance crée, en quelque sorte, un « pont » entre cette instance et lamachine qui l'héberge. Cela dit, les versions récentes d'OpenStack (dont la nôtre) utilisent une méthode demontage beaucoup plus sécurisée que les précédentes. La contre-partie est que la création d'une instanceprend plus de temps. Nous détaillerons ce point dans le chapitre 4.5.6.8 sur l'adaptation des images demachine virtuelle, un peu plus loin.

Xavier Buche Cloud universitaire avec OpenStack – CNAM Nord-Pas de Calais 63

Nous verrons également dans le prochain chapitre que le redimensionnement du système de fichiers est généralementréalisé par le système invité lui-même, qui tourne sur l'instance, ce qui facilite nettement le travail de Nova, qui n'aplus à sa charge que le redimensionnement du disque.

Quelle que soit l'option choisie, le retaillage est à sens unique : on ne peut pas diminuer la taille d'uneimage Qcow2.

Dans ce cas, voilà ce qu'affiche le fichier journal de nova-compute (/var/log/nova/nova-compute.log) :TRACE oslo.messaging.rpc.dispatcher FlavorDiskTooSmall: Flavor's disk is too small for requested image

Et si je tente une opération « manuelle » :qemu-img info debian

image: debian

file format: qcow2

virtual size: 25G (26843545600 bytes)

disk size: 256M

cluster_size: 65536

Format specific information:

compat: 1.1

lazy refcounts: false

qemu-img resize debian.qcow2 5G

qemu-img: qcow2 doesn't support shrinking images yet

Pré-allocation de blocsPour achever cette partie sur l'optimisation des instances, précisons qu'il est également possible de configurer nova-compute pour qu'il utilise une particularité de Linux qui permet de pré-allouer un espace disque à un fichier 60, quelqu'il soit. Cela présente deux avantages :– pas de perte de temps en allocation dynamique de blocs lors des écritures– les blocs pré-alloués ont plus de chance d'être contigus, ce qui limite la fragmentation des données et par

conséquent améliore les performances sur les disques durs magnétiques

Les images en cache n'ont aucun bénéfice à en tirer, car elles ne sont jamais modifiées. Par contre, les fichiers desdisques systèmes des instances pourraient en bénéficier pleinement.

Cependant, ce système de pré-allocation est dépendant du système de fichiers utilisé sur la machine hôte.Et malheureusement, le système de fichiers que nous utilisons, et dont nous allons parler dans les lignesqui suivent, ne le supporte pas.

Voilà d'ailleurs l'erreur pas très explicite qu'affiche le fichier journal de nova-compute lorsqu'on active la pré-allocation :

ERROR nova.virt.libvirt.imagebackend [req-c9fe3812-617a-441e-a852-eb73f5a44579 buche projet_test]Unable to preallocate_images=space at path: /var/lib/nova/instances/23ad5367-8279-4d8d-8267-32dca22c50c0/disk

4.5.6.2 StockageLe cache des images et le copy on write améliorent substantiellement la vitesse de création des instances etrestreignent drastiquement l'espace disque qu'elles occupent. Cependant, leur rayon d'action est circonscrit à chacundes nœuds de calcul.Pour tirer tout le potentiel de ces mécanismes, il faudrait que l'espace disque utilisé par le cache et les disques virtuelsdes instances soit accessible par tous les nœuds. Ceci permettrait, en outre, de pouvoir déplacer des instances d'un

60 voir le manuel de la commande "fallocate"

Xavier Buche Cloud universitaire avec OpenStack – CNAM Nord-Pas de Calais 64

nœud à l'autre presque instantanément, sans avoir à copier leur disque virtuel. Et si un nœud tombe en panne, lesinstances qui s'y trouvaient pourraient être facilement relancées sur les autres nœuds.

Le besoin de partager un espace de stockage sur un réseau n'est pas nouveau, tout au contraire, et les moyens d'yrépondre sont légion. On peut les ranger dans deux catégories :– le stockage distribué– le stockage centralisé

Le stockage distribué a le vent en poupe actuellement, surtout dans le monde des centres de données et du cloudcomputing. Les capacités de stockage y dépassent souvent l'entendement. A l'université, le projet Icare, qui étudiecertaines des interactions qui ont lieu dans l'atmosphère, utilise des masses colossales de données satellitaires. Dansde tels cas, on ne peut évidemment pas tout enregistrer sur une même machine. Les données sont réparties sur unegrappe de plusieurs dizaines de machines. Autre exemple : le centre de données du CERN61 accumule les résultats desinstruments de physique des particules, qui se comptent en dizaines de pétaoctets ! Ce foisonnement de donnéesporte un nom : le big data.Pour accéder à ces montagnes de bits, le mode distribué est incontournable. Des systèmes de fichiers et des protocolesparticuliers sont utilisés. Souvent complexes, ils génèrent un trafic réseau important et requièrent, dans certains cas,des réseaux ultra-rapides, à très haut débit et très faible latence.

Beaucoup plus simple est le stockage centralisé. Et en ce domaine comme dans d'autres, la simplicité est gage defiabilité. Ici, un seul et même système accède à l'ensemble des données. Souvent, ce système consiste en une baie destockage qui partage les données via un protocole réseau.

En ce qui concerne notre projet, nous disposons d'une baie NAS Netapp (voir le chapitre 4.1 sur les choix matériels,page 23). Netapp est particulièrement réputé pour son implémentation du protocole NFS pour le partage de fichiers.Même si NFS n'est pas un protocole aussi simple qu'il n'y paraît (gestion des verrous, des caches, etc.), il demeure l'undes protocoles les plus faciles à utiliser : le partage d'un volume sur la baie et son montage sur les machines du clusterOpenStack ne posent pas la moindre difficulté.

Sur chacun des nœuds de calcul, on ajoute une ligne dans /etc/fstab (je rappelle que /var/lib/nova/instances contient lesdisques virtuels des instances en cours d'exécution ainsi que le cache des images) :

filer:/vol/vol1/instances /var/lib/nova/instances nfs rw 0 0

Néanmoins cela ne veut pas dire qu'aucun problème ne s'est manifesté par la suite… En effet, quelquesjours après avoir mis en place cette configuration, je me rend compte que le premier nœud refused'exécuter les machines virtuelles.

NFS utilise le système des droits Unix pour contrôler l'accès aux fichiers. Ces autorisations se basent sur unpropriétaire, doté d'un identifiant d'utilisateur (UID), et sur un groupe, doté d'un identifiant de groupe (GID). Or je mesuis vite aperçu que les UID et GID associés aux disques virtuels des instances n'étaient pas les mêmes sur le nœud 1

61 Organisation européenne pour la recherche nucléaire

Xavier Buche Cloud universitaire avec OpenStack – CNAM Nord-Pas de Calais 65

Figure 8 : stockage centralisé

noeuds de calcul contrôleurs

stockage

accès NFS

transfert de l'image

accès NFS

et sur les autres. Les fichiers d'instances et du cache appartiennent notamment aux utilisateurs et aux groupesneutron et mysql, alors qu'ils devraient appartenir aux utilisateurs et aux groupes nova et libvirt-qemu. Ça n'a pas desens !

Le fait est que cette machine a été installée différemment. En effet, en plus de son rôle d'hyperviseur, elle participeégalement au cluster de base de données. Les services n'ont donc pas été installés dans le même ordre, et leurs UID etGID ne correspondent pas tous avec ceux des autres nœuds. Incontestablement, le diable se cache dans le détail !

J'ai donc dû remettre de l'ordre avec des commandes de ce type :usermod -u 109 nova

groupmod -g 116 nova

find /etc/nova -uid 110 ! -type l -exec chown 109 {} \;

find /var/log/nova -uid 110 ! -type l -exec chown 109 {} \;

find /var/log/neutron -uid 109 ! -type l -exec chown 110 {} \;

find /var/lib/nova -gid 117 ! -type l -exec chgrp 116 {} \;

find /etc/nova -gid 117 ! -type l -exec chgrp 116 {} \;

find /var/lib/neutron -gid 116 ! -type l -exec chgrp 117 {} \;

find /etc/neutron -gid 116 ! -type l -exec chgrp 117 {} \;

Désormais, le cache des images est accessible par tous les nœuds de calcul, ce qui amplifie son efficacité. Mais lesfichiers d'instances sont également mutualisés, ce qui offre de nouvelle perspectives…

4.5.6.3 Migration

A chaudTout administrateur systèmes sait qu'il est régulièrement nécessaire de redémarrer un serveur à la suite d'une mise àjour du noyau du système d'exploitation. Mais lorsque ce système est un hyperviseur qui exécute des dizaines demachines virtuelles, l'opération est d'autant plus ennuyeuse, et une coupure de service de plusieurs minutes n'estparfois pas admissible. C'est là qu'intervient l'un des nombreux avantages de la virtualisation : la migration à chaud (live migration enanglais), qui permet de déplacer une machine virtuelle d'une machine hôte vers une autre avec un impact minimumpour ses utilisateurs. Pour cela, il suffit que les disques virtuels des instances soient accessibles par tous leshyperviseurs de la grappe.

Avec OpenStack, la manœuvre est on ne peut plus simple :nova live-migration instance1 compute2

Cette commande migre la machine virtuelle instance1 vers l'hôte compute2.

Seul un administrateur de la plate-forme OpenStack dispose des droits suffisants pour effectuer cetteopération.

Et voici le résultat d'une requête ICMP62 auprès d'une machine en cours de déplacement :ping -i 0.01 172.28.1.11

64 bytes from 172.28.1.11: icmp_seq=187 ttl=63 time=0.532 ms

64 bytes from 172.28.1.11: icmp_seq=188 ttl=63 time=0.516 ms

64 bytes from 172.28.1.11: icmp_seq=204 ttl=63 time=64.9 ms

64 bytes from 172.28.1.11: icmp_seq=205 ttl=63 time=0.392 ms

64 bytes from 172.28.1.11: icmp_seq=206 ttl=63 time=0.345 ms

En envoyant un paquet toutes les 10 millisecondes, l'une des réponses est reçue après 65 ms, ce qui signifie que lamachine est restée injoignable entre 65 et 75 ms. Autant dire que la migration à chaud passera inaperçue pour lagrande majorité des applications. 62 Internet Control Message Protocol

Xavier Buche Cloud universitaire avec OpenStack – CNAM Nord-Pas de Calais 66

Comment le transfert de la machine peut-il être aussi rapide ? Tout d'abord, l'espace disque est partagé entre lesnœuds de calcul. Le nœud source et le nœud cible du transfert accèdent donc tous deux au disque système de lamachine virtuelle à migrer. Le défi technique de la migration à chaud réside plutôt dans le transfert des données de lamémoire vive du nœud source vers la mémoire vive du nœud de destination, car les modifications qui ont lieupendant le transfert doivent être prises en compte.

L'hyperviseur du nœud source garde trace des pages mémoires modifiées en cours de progression de la copiemémoire. Une fois cette copie terminée, la pages mémoires modifiées sont transférées. Mais au cours de ce deuxièmetransfert, d'autres pages peuvent encore être modifiées. Une fois de plus, l'hyperviseur en garde trace pour lestransférer à l'étape suivante. Il s'agit donc d'un processus répétitif, avec des incréments de plus en plus petits. Au boutd'un certain nombre de cycles, l'instance est suspendue, les dernières pages mémoires sont copiées sur l'hôte cible oùune machine virtuelle identique est lancée. Une fois que cette nouvelle instance est en cours d'exécution, l'instanced'origine est supprimée.

Par sshIl est possible de réaliser une migration sans stockage partagé. Nova utilise alors une connexion SSH pour copier lefichier d'instance sur l'hôte cible et y recréer une nouvelle instance.Les nœuds de calcul doivent donc être configurés de manière à ce que Nova puisse, sur chacun d'eux, se connecter àtous les autres en utilisant une paire de clefs de chiffrement. Pour simplifier, nous utilisons une seule clef privée, enexécutant ces quelques commandes sur un nœud, et en répliquant sur les autres les fichiers créés dans ~/.ssh :

su - nova

ssh-keygen -t rsa

cat << EOF > ~/.ssh/config

Host *

StrictHostKeyChecking no

UserKnownHostsFile=/dev/null

EOF

cat ~/.ssh/id_rsa.pub > .ssh/authorized_keys

chmod 600 .ssh/authorized_keys

Exemple de migration :nova migrate instance1

La destination de la machine instance1 est sélectionnée par l'ordonnanceur, et le contenu de ses disques etde sa mémoire y est copié par SSH.

Comme une nouvelle instance est créée sur le nœud cible, notons que le type de l'instance peut différer de celui del'instance d'origine, qui tournait sur le nœud source. Il est ainsi possible d'utiliser ce mécanisme non pas pour migrerune instance, mais uniquement pour en changer le type. Et contrairement à l'évacuation d'hôte et aux diverses formesde migration d'instances, cette fonctionnalité, mal nommée « redimensionnement », est accessible aux utilisateurs.

4.5.6.4 Redimensionnement d'instanceLe redimensionnement d'une instance consiste à en changer le type.

Exemple : un utilisateur souhaite rendre puissante sa machine instance1. Il lance la commande suivante :nova resize --poll instance1 puissante

Ce n'est pas fini. L'instance passe dans un état intermédiaire avant que l'ordre soit confirmé :nova show test-shut

+--------------------------------------+----------------------------------------------------------+

| Property | Value |

+--------------------------------------+----------------------------------------------------------+

| status | VERIFY_RESIZE |

+--------------------------------------+----------------------------------------------------------+

| ... | ... |

Xavier Buche Cloud universitaire avec OpenStack – CNAM Nord-Pas de Calais 67

nova resize-confirm test-shut

Pour éviter cette inutile et fastidieuse demande de confirmation, j'ai configuré Nova pour qu'elle soit soit acceptéeautomatiquement, en ajoutant cette ligne au fichier /etc/nova/nova.conf :

resize_confirm_window=1

Pour que le redimensionnement d'instance soit actif, il faut également que cette ligne soit présente :allow_resize_to_same_host = True

Cela revient à migrer une instance avec un hôte d'origine et un hôte de destination identiques. En d'autres termes,cette directive permet de choisir entre la fonctionnalité de redimensionnement d'instances ou celle de migration parSSH.

Enfin, à moins d'avoir activé la directive resize_fs_using_block_device, le système de fichiers ne sera pas de ladimension du disque virtuel et son éventuel retaillage sera à la charge de l'utilisateur.

Précisons pour terminer que le type en lequel on souhaite transformer une instance doit avoir un disqueau moins aussi grand que le type d'origine.

4.5.6.5 ÉvacuationDans le cas où un nœud tombe en panne, on peut « évacuer » les instances qui s'y trouvaient vers d'autres nœuds.

Exemple : transférer toutes les instances depuis le nœud compute1 inactif vers le nœud compute2.nova host-evacuate --on-shared-storage --target_host compute2 compute1

Si l'option on-shared-storage n'est pas précisée, alors Nova crée de nouveaux disques systèmes pour lesinstances déplacées.

Malgré ce qu'indique l'aide, l'option target_host est obligatoire. Avec notre version de Nova, on ne peutdonc pas laisser l'ordonnanceur répartir efficacement les instances sur tous les nœuds restants. Et c'estbien dommage.

Cependant une commande permet d'évacuer les instances une à une :nova evacuate --on-shared-storage compute1 instance1

Dans ce cas, l'ordonnanceur choisit le nœud sur lequel la machine instance1 doit être lancée. Un simple script permetdonc de réaliser cette opération sur toutes les instances de l'hôte inactif.

4.5.6.6 Une instance dans tous ses étatsTout au long de son cycle de vie, une instance peut se trouver dans de nombreux états. En voici quelques-uns :– active : la machine est en cours d'exécution– paused : la machine est en mode veille, elle occupe son espace mémoire– syspended : la machine est en veille, mais elle n'occupe pas d'espace mémoire, car le contenu de sa mémoire a

été enregistré dans un fichier– stopped : la machine a été arrêtée et est virtuellement hors tension

Précisons au passage qu'une instance peut être redémarrée par Nova de deux manières :– à chaud : redémarrage logiciel, équivalant à lancer la commande reboot ou cliquer sur le bouton redémarrer

du système d'exploitation– à froid : redémarrage matériel, équivalant à appuyer sur le bouton reset du boîtier

Voici les résultats et les conclusions des tests que j'ai effectués selon les différents états d'origine d'une instance.

Xavier Buche Cloud universitaire avec OpenStack – CNAM Nord-Pas de Calais 68

On ne peut pas évacuer une instance suspendue ou en pause, même avec un stockage partagé :nova evacuate --on-shared-storage test-susp compute2

ERROR: Cannot 'evacuate' while instance is in vm_state suspended (HTTP 409)

nova evacuate --on-shared-storage test-pause compute2

ERROR: Cannot 'evacuate' while instance is in vm_state paused (HTTP 409)

Ceci est un problème connu par la communauté OpenStack. Les machines dans cet état ne sont pasutilisée, donc une défaillance temporaire de l'hôte passera probablement inaperçue. Sauf pour lesmachines en pause : si elles sont mises hors tension suite à la panne de l'hôte, elles devront être démarréepar l'utilisateur une fois l'hôte rétabli, et le contenu de la mémoire sera perdu.

On ne peut pas migrer à chaud une instance arrêtée, suspendue ou en pause :nova live-migration test-shut compute2

ERROR: Cannot 'os-migrateLive' while instance is in vm_state stopped (HTTP 409)

nova live-migration test-susp compute2

ERROR: Cannot 'os-migrateLive' while instance is in vm_state suspended (HTTP 409)

nova live-migration test-pause compute1

ERROR: Cannot 'os-migrateLive' while instance is in vm_state paused (HTTP 409)

Autrement dit, seules les instances actives peuvent être migrées à chaud. En effet, la migration à chaud est destinéeaux machines en cours de fonctionnement. Il est donc cohérent que les machines arrêtées ou suspendues ne puissentpas être déplacées de cette manière. Dans ce cas il faut utiliser la migration par SSH. Quant au problème de migrationdes machines en pause, il a été résolu dans les versions plus récentes d'OpenStack (à partir de la Juno).

Notons que la commande nova restore permet aux utilisateurs de ramener à la vie une image préalablementsupprimée. Cette fonctionnalité est activée en paramétrant la directive reclaim_instance_interval du fichier/etc/nova/nova.conf sur le contrôleur. Cette directive contient la durée pendant laquelle les instances suppriméespourront être restaurée. Les machines supprimées se mettent dans l'état soft-deleted pendant cette durée.

Nous n'avons pas activé ce système de restauration pour deux raisons. Premièrement, les machinesvirtuelles sont régulièrement sauvegardées par une procédure automatique décrite au chapitresauvegardes, page 110. Deuxièmement, les instances en état soft-deleted réservent des ressourcesmatérielles, en particulier de la mémoire vive. Voyons pourquoi.

4.5.6.7 Mettre une instance de côtéRevenons un instant sur les machines suspendues ou arrêtées. J'ai précisé quelques lignes plus haut que ces machinesne consomment pas de ressources matérielles. En d'autres termes, elles ne sont pas en cours d'exécution.

Exemple :

– sur le contrôleur :

nova show mon_instance

+--------------------------------------+----------------------------------------------------------+

| Property | Value |

+--------------------------------------+----------------------------------------------------------+

| OS-EXT-SRV-ATTR:host | compute3 |

| OS-EXT-SRV-ATTR:instance_name | instance-00001039 |

| OS-EXT-STS:vm_state | suspended |

...

– sur le nœud de calcul compute3…virsh list |grep instance-00001039

… ne retourne rien.

Xavier Buche Cloud universitaire avec OpenStack – CNAM Nord-Pas de Calais 69

– pourtant, sur le contrôleur…nova hypervisor-servers compute3

+--------------------------------------+-------------------+---------------+---------------------+

| ID | Name | Hypervisor ID | Hypervisor Hostname |

+--------------------------------------+-------------------+---------------+---------------------+

| f3e3782e-7b5a-41ec-ac9c-ba025c20674e | instance-00001039 | 8 | compute3 |

...

… indique bien que cette instance est associée à compute3.

En fait, l'ordonnanceur réserve un espace mémoire aux machines virtuelles même si elles sont « hors tension » oudans l'état soft-deleted. De cette manière, lors de son prochain démarrage ou de sa restauration, une machine estcertaine d'obtenir les ressources matérielles qui lui sont dues.

Il est cependant possible de mettre de côté63 une instance de manière à ce que ses ressources soient libérées :nova shelve mon_instance

nova show mon_instance

+--------------------------------------+------------------------------------------------+

| Property | Value |

+--------------------------------------+------------------------------------------------+

| OS-EXT-SRV-ATTR:host | - |

| OS-EXT-SRV-ATTR:instance_name | instance-00001039 |

| OS-EXT-STS:vm_state | shelved_offloaded |

...

Une fois mise de côté, notre instance n'est désormais plus associée à aucun hôte. Et plus aucune trace de la machinesur compute3 :– le répertoire /var/lib/nova/instances/f3e3782e-7b5a-41ec-ac9c-ba025c20674e/, qui contenait l'image disque de

l'instance, n'existe plus– le fichier /etc/libvirt/qemu/instance-00001039.xml, qui contenait les paramètres de la machine, a été supprimé

Mais alors, où se trouve donc notre machine ? Eh bien, elle a tout simplement été transformée en une image de typeinstantané et copiée sur le contrôleur. Pour la relancer, il suffit d'exécuter la commande nova unshelve mon_instance.L'instantané est alors supprimé.

Précisons que cette fonctionnalité n'est utilisable qu'en ligne de commande.

4.5.6.8 Adaptation des imagesDans le chapitre 4.4 sur Glance, page 51, nous avons téléchargé, comme exemple, une image de Linux Debian adaptéeau cloud. Nous n'avions alors pas précisé pourquoi une simple image ne suffit-elle pas, et pourquoi il est quasimentnécessaire d'utiliser une image modifiée.

C'est qu'au moment de la création d'une instance, OpenStack tente d'y apporter quelques modifications. Entre autres :– le disque système est redimensionné pour correspondre à la taille choisie via le type d'instance– le système prend le nom de l'instance– la clef publique SSH est injectée– les journaux de démarrage sont récupérés

Tout cela nécessite que le système installé sur l'image soit préparé à une utilisation dans le cloud.Voyons donc comment une telle image peut être modifiée.

63 traduction de to shelve

Xavier Buche Cloud universitaire avec OpenStack – CNAM Nord-Pas de Calais 70

La façon la plus simple d'adapter une image au cloud OpenStack, et celle que nous avons choisie, consiste à utiliser unlogiciel appelé cloud-init [Documentation de cloud-init]. Ce programme automatise, par le biais d'un fichier deconfiguration et de scripts, toutes les modifications réalisées sur une instance au moment de sa création. Cesmodifications se font essentiellement sur la base des métadonnées d'instances, qui sont obtenues par cloud-init selonun processus décrit dans le chapitre 4.6.12 sur Neutron et le serveur de métadonnées, page 99.

L'installation de cloud-init sur une instance est très simple :apt-get install cloud-init

Une fois installé, sa configuration se fait dans un simple fichier texte : /etc/cloud/cloud.cfgLe paramétrage de base de cloud-init réalise notamment les modifications citées plus haut.

Voici quelques exemples de modifications supplémentaires que j'ai réalisées sur les images rendues publiques etdisponibles dans le catalogue de Glance.

Tout d'abord, pour accéder à Internet, les machines doivent passer par un serveur mandataire, le proxy de l'université.Et pour éviter à chaque utilisateur d'avoir à configurer systématiquement son adresse sur chaque nouvelle instance,j'ai ajouté ces quelques lignes dans le fichier /etc/environment des différentes images Linux :

http_proxy="http://cache.univ-lille1.fr:3128/"

HTTP_PROXY="http://cache.univ-lille1.fr:3128"

https_proxy="http://cache.univ-lille1.fr:3128"

HTTPS_PROXY="http://cache.univ-lille1.fr:3128"

ftp_proxy="http://cache.univ-lille1.fr:3128"

FTP_PROXY="http://cache.univ-lille1.fr:3128"

Nous verrons dans le chapitre 4.6.13 sur Neutron que j'ai, par la suite, configuré le routeur principal pour, en quelquesorte, rendre le proxy transparent, et que le paramétrage explicite de l'adresse du proxy devienne accessoire.

La console est un des moyens de se connecter à une instance. Par défaut, les images pré-configurées par les éditeursde distribution Linux sont en anglais. Il faut donc changer le langage.Ceci peut se faire de plusieurs façons, selon la distribution. Par exemple, avec Ubuntu, on peut ajouter la lignesuivante au fichier /etc/rc.local :

loadkeys fr

Enfin j'ai configuré cloud-init de manière à ce que les instances soient automatiquement mises à jour lors de leurcréation, en indiquant dans /etc/cloud/cloud.cfg :

package_upgrade: true

Les utilisateurs peuvent se servir de cloud-init par l'intermédiaire de scripts qu'ils doivent écrire dans l'onglet post-création du panneau de création d'instance, dans l'interface web, ou en ligne de commande, en écrivant le script dansun fichier, lui-même précisé par le paramètre --user-data de la commande nova boot.

Ils peuvent ainsi, par exemple :- installer de nouveaux paquetages automatiquement :

#cloud-config

packages:

- davfs2

- monter automatiquement un répertoire distant :mounts:

- [ https://owncloud.univ-lille1.fr, /mnt, davfs, "defaults,noexec" ]

- créer de nouveaux comptes :users:

- name: buche

gecos: Xavier Buche

primary-group: admin

groups: users

Xavier Buche Cloud universitaire avec OpenStack – CNAM Nord-Pas de Calais 71

expiredate: 2016-09-01

lock-passwd: false

password: mdp

cloud-init peut donc être très utile aux utilisateurs, et leur éviter d'avoir à créer systématiquement une nouvelle imagepour chaque besoin. Par exemple, un enseignant pourrait demander aux étudiants de se créer, à partir d'une imagegénérique, chacun une instance qui s'auto-configurerait selon les besoins du TP, simplement en leur communiquantun script cloud-init.

OpenStack n'offre pas la possibilité de fabriquer une image. Cette opération est à la charge de l'utilisateuret sort quelque peu du cadre de notre sujet, c'est pourquoi nous ne détaillerons pas ici la procédure decréation d'une image. D'autre part, de nombreux tutoriels traitant de cette question sont disponibles surInternet.

4.5.6.9 Connexion aux instancesUne machine virtuelle n'a pas grande utilité, une fois qu'on l'a créée, si on ne peut pas s'y connecter. Ce qui peut sefaire de plusieurs manières.

Clefs SSHLe fonctionnement standard d'OpenStack est calqué sur celui des clouds publics. Or, sur ces derniers, on accèdehabituellement aux instances de machine virtuelle via le protocole SSH en utilisant une paire de clefs asymétriques.

Le principe : – Soit l'utilisateur crée une paire de clefs et fournit la clef publique à OpenStack, qui l'injectera dans les

machines virtuelles au moment de leur création.

Exemple :ssh-keygen -t rsa

Une clé privée est écrite dans le fichier ~/.ssh/id_rsa et la clé publique correspondante est stockée dansle fichier ~/.ssh/id_rsa.pub.nova keypair-add --pub-key ~/.ssh/id_rsa.pub ma_clef

La clef publique est communiquée à OpenStack.

– Soit OpenStack crée lui-même une paire de clefs et fournit à l'utilisateur la clef privée, qu'il dispose en lieusûr sur son poste de travail.

Exemple :nova keypair-add ma_clef > ~/.ssh/id_rsa

Nova crée une paire de clefs, conserve uniquement la clef publique et renvoie la clef privée, qui estcopiée dans le fichier ~/.ssh/id_rsa.

– Finalement, la clef publique est injectée dans l'instance au moment de sa construction.

Exemple :nova boot --key-name ma_clef --flavor normale --image Ubuntu-Trusty --nic net-id=11c5b2b2-c022-44b7-ac1d-18a0a4d82ede mon_instance

OpenStack copie la clef publique dans le fichier ~/.ssh/authorized_keys de mon_instance lors de sacréation, ~ représentant le répertoire personnel du compte par défaut configuré par cloud-init. Lescomptes par défaut diffèrent selon les distributions. Par exemple sur Ubuntu, le compte est ubuntu, surCentOS, le compte est centos.

Cette méthode d'accès aux machines virtuelles implique une phase de création d'une paire clefs qui pourrait paraîtrequelque peu obscure à certains utilisateurs, comme les étudiants débutants. Mais une fois cette étape accomplie,l'accès à la machine par SSH se fait sans avoir à entrer un mot de passe, qu'il n'y a donc pas besoin de retenir.Cela dit, la clef privée, qui sert à authentifier l'utilisateur, est le maillon faible en matière de sécurité. Elle n'est pasdans le cerveau de l'utilisateur, mais sur son disque dur. Si elle n'est pas bien protégée, elle peut se retrouver dans demauvaises mains. De plus, si l'utilisateur change de poste de travail, il doit récupérer cette clef et la copier sur le

Xavier Buche Cloud universitaire avec OpenStack – CNAM Nord-Pas de Calais 72

nouveau poste. Enfin, pour accéder par SSH à son instance, elle doit être accessible par le réseau externe et doit doncdisposer d'une adresse IP flottante (voir le chapitre 4.6.2 sur Neutron, page 78).

Pour pallier ces inconvénients, l'utilisateur dispose de méthodes d'accès alternatives.

Compte utilisateurComme nous l'avons vu précédemment, cloud-init offre la possibilité aux utilisateurs de modifier automatiquementune instance au moment de sa création. Un utilisateur peut donc facilement créer un nouveau compte, ou alors, plussimplement, modifier le mot de passe du compte par défaut avec un script de cette nature :

#cloud-config

password: mon_mot_de_passe

Par défaut, cloud-init est configuré pour désactiver la connexion SSH avec mot de passe. Pour que les utilisateurspuissent utiliser des mots de passe, j'ai donc activé la directive ssh_pwauth du fichier /etc/cloud/cloud.cfg :

ssh_pwauth: True

Cette méthode d'accès aux machines virtuelles nécessite de connaître la syntaxe des scripts cloud-init. Elle n'est doncpas idéale, si l'objectif est de rendre la connexion réellement triviale. De plus, et comme la méthode précédente, lamachine virtuelle doit avoir une adresse IP externe à la plate-forme OpenStack.

ConsoleDepuis de nombreuses années, les serveurs donnent aux administrateurs un moyen d'accéder au système via leréseau, comme si l'on était connecté sur place, en local. Je parle de fonctionnalités comme iDRAC chez Dell ou iLO 64

chez HP. On en comprend vite l'intérêt quand il s'agit, à distance, de dépanner un dysfonctionnement du systèmed'exploitation ou de réaliser un changement de la configuration réseau, par exemple.

Dans le cas d'une machine virtuelle, on réalise l'équivalent en utilisant des protocoles d'affichage déporté. OpenStackoffre le choix entre VNC et SPICE.

VNCLa connexion à un serveur VNC65 requiert l'utilisation d'un logiciel client VNC. Pour éviter aux utilisateurs d'avoir àinstaller et configurer un tel programme sur leur poste, OpenStack a choisi d'utiliser noVNC. Grâce à ce programme,la console VNC s'affiche directement dans un navigateur web. En effet, le client noVNC est implémenté en utilisantles canvas et les websockets HTML566. Il fonctionne donc sur tous les navigateurs modernes, y compris sur mobile(iPhone et Android).

Le widget67 noVNC se connecte au service nova-novncproxy qui tourne sur le contrôleur en utilisant le protocole vnc-over-websockets. Le service nova-novncproxy communique ensuite avec les hyperviseurs situés sur les nœuds de calcul(QEMU/KVM via libvirt dans notre cas).

Voici la manière dont j'ai configuré le proxy noVNC sur le contrôleur, dans le fichier /etc/nova/nova.conf :# activer le proxy vnc

vnc_enabled = True

# les directives qui suivent ne sont pas dans la doc d'Icehouse. Elles ont été trouvées dans des documents plus récents.

novncproxy_host = cloud.univ-lille1.fr

# le port a été modifié pour éviter d'avoir à changer les règles du pare-feu du VPN de l'université

novncproxy_port = 5900

# la connexion est sécurisée par SSL

ssl_only=True

cert=/chemin/vers/le/certificat.pem

64 integrated Lights-Out65 Virtual Network Computing66 Hypertext Markup Language, version 567 composant de l'interface web

Xavier Buche Cloud universitaire avec OpenStack – CNAM Nord-Pas de Calais 73

key=/chemin/vers/la/clef/privee.key

# l'endroit où se trouve la toute dernière version du proxy noVNC, que j'ai installée en cherchant à corriger certains problèmes (voir plus bas)

web=/opt/noVNC

Et voici la configuration des nœuds de calcul, dans le fichier /etc/nova/nova.conf :vnc_enabled = True

vncserver_listen = 0.0.0.0

vncserver_proxyclient_address = IP_computeX

# l'adresse à laquelle le client noVNC doit se connecter

novncproxy_base_url = https://cloud.univ-lille1.fr:5900/vnc_auto.html

vnc_keymap=fr

La console VNC est loin d'être une solution idéale. Dans le tutoriel que j'ai réalisé à destination desutilisateurs (voir en annexe, page 126), je leur recommande d'ailleurs de ne l'utiliser qu'en cas de nécessité(configuration initiale de l'instance, dépannage, etc.).

Pourquoi en déconseiller l'utilisation ? Pour trois raisons :– le mappage du clavier pose problème : la touche alt gr et le pavé numérique ne fonctionnent pas– les performances sont très faibles comparées à SSH, en ligne de commande et surtout en mode graphique– des bogues d'affichage apparaissent parfois sous X

Ces problèmes sont connus et sont dus essentiellement au client noVNC.

SPICEEssayons de parer aux problèmes de noVNC avec SPICE68.Le principe de connexion de l'utilisateur avec SPICE est exactement le même qu'avec VNC, sauf que le widget utilisele protocole spice-over-websockets et le proxy qui tourne sur le contrôleur se nomme spicehtml5proxy.

On installe ce dernier avec la commande :apt-get install nova-spiceproxy

Puis on configure le contrôleur ainsi, dans le fichier /etc/nova/nova.conf :[default]

spicehtml5proxy_host = cloud.univ-lille1.fr

spicehtml5proxy_port = 5900

[spice]

enabled = True

agent_enabled = True

Enfin voici les paramètres des nœuds de calcul, toujours dans /etc/nova/nova.conf :[default]

vnc_enabled = False

[spice]

enabled = True

agent_enabled = True

html5proxy_base_url = http://cloud.univ-lille1.fr:5900/spice_auto.html

keymap = fr

server_listen = 0.0.0.0

server_proxyclient_address = ip_computeX

68 Simple Protocol for Independent Computing Environments

Xavier Buche Cloud universitaire avec OpenStack – CNAM Nord-Pas de Calais 74

SPICE est un protocole d'affichage distant censé surpasser VNC en matière de performances et de fonctionnalités. Ilpourrait même remplacer avantageusement RDP69 pour l'accès aux machines Windows et X11 pour les machinesLinux depuis un simple navigateur. Il permettrait de fournir un service de VDI (Virtual Desktop Infrastructure), quiconsiste à mettre dans le cloud les postes de travail, sans que l'expérience utilisateur soit trop dégradée.

Tout cela reste au conditionnel, car actuellement SPICE sur websockets est à l'état de preuve de concept.Après l'avoir mis en place, je constate en effet des problèmes rédhibitoires : décalage des curseurs,rafraîchissement de la console en mode texte et bogues d'affichage en mode graphique.

Le client HTML5 de SPICE doit encore être amélioré avant de pouvoir remplacer noVNC.

Injection de mots de passenoVNC permet d'accéder très facilement à une instance, sans même que celle-ci ne soit connectée à un réseau. C'estun gros avantage par rapport aux connexions SSH sous Linux ou RDP sous Windows, qui nécessitent uneconnectivité externe des machines virtuelles.Cependant, l'authentification reste problématique, car l'utilisateur doit créer un nouveau compte ou modifier le motde passe d'un compte pré-existant, au moment de la création de l'instance, par l'intermédiaire d'un script cloud-init,dont il faut connaître la syntaxe.

OpenStack a la faculté de pouvoir modifier lui-même une instance au moment de sa construction, sans passer par unlogiciel comme cloud-init. Il en a déjà été question dans le chapitre 4.5.6.8 sur l'adaptation des images, page 70. J'avaisalors précisé que, quand le choix est possible, il est préférable de laisser l'instance se modifier elle-même. C'était le casconcernant le redimensionnement du disque système.Ici, le choix de cloud-init n'est clairement pas le meilleur en matière de facilité d'usage pour les utilisateurs. J'ai doncconfiguré une fonctionnalité particulière de Nova qui lui permet d'injecter, lors de la création d'une instance, un motde passe root défini par l'utilisateur.

69 Remote Desktop Protocol, le protocole d'accès à distance aux machines Microsoft Windows

Xavier Buche Cloud universitaire avec OpenStack – CNAM Nord-Pas de Calais 75

Figure 9 : problèmes d'affichage avec la console SPICE HTML5

Pour cela, Nova doit pouvoir écrire sur le disque système. L'image utilisée pour créer l'instance ne doit donc pas avoirété partitionnée de façon trop spéciale, et le système de fichiers de doit pas être trop exotique.

Les premières versions d'OpenStack utilisaient des moyens classiques pour monter, sur la machine hôte, le système defichiers d'une machine invitée pour le modifier. Il s'est rapidement avéré que ces méthodes, qui se basent surl'utilisation de pseudo-dispositifs comme les loop devices ou les Network Block Devices (NBD), n'étaient passuffisamment sécurisées. En effet, à partir d'une machine virtuelle, il était alors possible d'exploiter les failles desécurité du système de fichiers pour, dans le pire des scénarios, accéder de manière privilégiée au système hôte.

Depuis que ce constat a été fait, une solution beaucoup plus sécurisée a été trouvée. Elle consiste à monter le systèmede fichiers dans une mini-machine virtuelle chargée sur la machine hôte. libguestfs [Libguestfs], le logiciel qui réalisecette tâche, est indépendant d'OpenStack.

Voilà comment l'installer et le configurer sur les nœuds de calcul :apt-get install libguestfs-tools python-guestfs

La supermin appliance est une simple liste de fichiers présents sur le système hôte et utilisés par libguestfs pour créerune machine virtuelle. Cette commande met à jour cette liste en fonction des fichiers de l'hôte.

update-guestfs-appliance

libguestfs est fortement lié au système hôte. Une commande permet donc de vérifier que ses dépendances sontsatisfaites et que toutes ses fonctionnalités sont opérationnelles.

libguestfs-test-tool

libguestfs a notamment besoin de KVM. La commande qui suit lui en donne l'accès :usermod -a -G kvm nova

En plus, il doit pouvoir accéder au noyau de l'hôte. Or, contrairement aux autres distributions Linux, Ubuntu Trustyne donne qu'à root la permission de lire les fichiers du noyau. Il faut donc également lancer la commande suivante :

chmod 0644 /boot/vmlinuz*

Le problème est que cette opération doit être réalisée après chaque mise à jour du noyau. J'ai donc fait en sorte quesoient vérifiées et modifiées, si nécessaire, les permissions d'accès à ces fichiers à chaque démarrage du serveur enajoutant ces lignes dans /etc/rc.local :

for i in $(ls /boot/vmlinuz*)

do

sudo -u nova test -r $i || chmod 0644 $i

done

Il reste finalement à activer l'injection de mots de passe sur les nœuds de calcul, en ajoutant dans /etc/nova/nova-compute.conf :

[libvirt]

inject_password=true

# si le disque est partitionné, libguestfs choisit lui-même la partition à monter :

inject_partition = -1

Désormais, après la création d'une instance avec la commande nova boot ., Nova génère un mot de passe aléatoirequ'il indique à l'utilisateur dans le résultat de la commande.

Quant à l'interface web, il faut la configurer pour que soit ajouté un champ mot de passe sur le panneau de créationd'instances, en activant la variable can_set_password du fichier /etc/OpenStack-dashboard/local_settings.py :

OpenStack_HYPERVISOR_FEATURES = {

'can_set_password': True,

}

Xavier Buche Cloud universitaire avec OpenStack – CNAM Nord-Pas de Calais 76

Couplé à la console VNC, ce moyen d'accéder à une instance est on ne peut plus simple. Il suffit de préciser le mot depasse root dans le champ adéquate de l'interface web Horizon au moment de la création de la machine virtuelle. Seulinconvénient : l'instance prend plus de temps à se construire. Une machine Linux met environ dix secondes pour secréer. Quand on active l'injection de mots de passe, elle met alors environ vingt secondes.

L'utilisateur peut ainsi choisir une ou plusieurs de ces méthodes pour accéder à son instance, selon ses besoins, selonses compétences, selon ses préférences :– renseigner le mot de passe root– créer un nouveau compte ou changer le mot de passe d'un compte existant avec un script cloud-init– créer ou sélectionner une paire de clef SSH

4.5.6.10 InstantanésParfois il est utile de conserver l'état d'un système à un instant donné. Par exemple, avant de réaliser un changementimportant dans la configuration, une mise à jour, etc. Cet état figé dans le temps se nomme cliché, ou instantané, ouencore snapshot en anglais.

Dans l'univers d'OpenStack, l'instantané est converti en image et ajouté au catalogue de Glance. J'en veux pour preuvele nom même de la commande qui sert à réaliser un instantané : nova image-create .Un instantané est donc une image. Soit. Mais pas tout à fait. Ou plutôt un peu plus : un instantané présente en effetdes caractères qui lui sont propres. Les propriétés d'une image de type instantané comportent deux champsparticuliers :– instance_uuid, qui référence l'instance à la base de l'instantané– base_image_ref, qui contient l'identifiant de l'image source de l'instance ayant généré l'instantané

La notion d'instantané peut tout à fait être comprise comme une sauvegarde classique par les utilisateurs. Cependant,si cloud-init est installé sur la machine « photographiée », ce qui est probable, il modifiera toute nouvelle instancecréée à partir de l'instantané : taille du disque, suppression de l'historique des commandes, etc. Même si cloud-initn'est pas installé, l'adresse IP sera changée.

Nova peut être configuré pour que les instantanés soient compressés. Si c'est le cas, le temps nécessaire pour lacréation du cliché d'une instance de 532 Mo est de 1 minute et 37 secondes. L'image occupe alors 220 Mo. Sanscompression, la création du cliché dure 54 secondes.Lors de l’instanciation d'une image compressée, le temps de transfert est plus court, mais il faut ajouter un temps dedécompression (nettement moindre que le temps de compression). Au total, une instance est créée un peu plusrapidement à partir d'une image compressée. Cela dit, grâce au mécanisme de cache décrit dans le chapitre sur lesinstances, page 61, seule la première machine virtuelle sera affectée par ce gain de temps.

Il s'agit donc de choisir entre un instantané plus rapide (sans compression) ou une première créationd'instance plus rapide et une moindre occupation disque (avec compression). Actuellement nous avonschoisi de désactiver la compression, mais si les instantanés ont la cote auprès des utilisateurs, je l'activeraiprobablement pour économiser de l'espace disque.

Une prochaine version d'OpenStack proposera un nouveau service de Data Protection as a Service nomméRaksha, actuellement en cours de développement, et dont l'objectif sera la protection des données par lesutilisateurs en se basant sur les clichés.Ce service permettra de réaliser des sauvegardes qui ne seront pas transformées en images. Elles neseront donc pas modifiées par cloud-init et occuperont beaucoup moins d'espace disque grâce à la

compression et la déduplication des données. Il sera donc possible et facile pour les utilisateurs de planifier dessauvegardes très régulières.

Enfin, c'est ici l'occasion opportune de compléter le chapitre 4.5.6.8 sur l'adaptation des images enprécisant que, plutôt que de modifier une image par ses propres moyens, l'utilisateur peut facilement lefaire par le biais d'un instantané.Les instantanés peuvent donc typiquement être employés, par exemple, par un enseignant désirant créerune nouvelle image à partir d'une image existante après l'avoir modifiée pour y inclure les applicationsnécessaires à son TP.

Xavier Buche Cloud universitaire avec OpenStack – CNAM Nord-Pas de Calais 77

4.6 Neutron et le réseauA ce stade, le lecteur attentif aura compris que nova est l'élément cardinal et fondateur de la plate-forme. Lorsqu'il aintégré OpenStack en 2010, il faisait l'essentiel du travail, et il s'occupait notamment du réseau.Depuis, on ne cesse de le dénuder pour le rendre plus léger et facile à maintenir. C'est pourquoi la gestion du réseauest maintenant dévolue à un composant à part entière : Neutron.Cependant les développeurs d'OpenStack on décidé de laisser aux administrateurs, pendant quelques temps, le choixd'utiliser Neutron ou son prédécesseur, Nova-network.

4.6.1 Neutron ou Nova-network ?

4.6.1.1 Nova-networkLa simplicité a de multiples vertus, mais elle est souvent synonyme de minimalisme. C'est le cas de Nova-network.

Nova-network offre le choix entre deux gestionnaires de réseau, qui régissent principalement la manière dont lesréseaux sont segmentés :– flat : toutes les instances sont situées sur le même domaine de diffusion ethernet– vlan : chaque projet d'utilisateur dispose de son propre segment ethernet

Nova-network offre également de choisir entre deux architectures physiques, indépendamment du choix dugestionnaire :– single-host : un nœud, par exemple le contrôleur, joue le rôle de passerelle, par laquelle transite le flux des

données des machines virtuelles– multi-host : les nœuds de calcul ont un accès direct sur l'extérieur

Nova-network est plus simple mais aussi plus limité que Neutron. Mais surtout, il est obsolète, et toutes les sources dedocumentation recommandent désormais d'utiliser son successeur.

4.6.1.2 NeutronNeutron concrétise le concept d'Infrastructure as a Service pour la partie réseau. L'utilisateur peut manipuler desobjets réseaux comme dans la vraie vie (routeurs, réseaux ethernet, serveurs, interfaces, adresses IP, voire même pare-feu ou répartiteurs de charge) et les agencer pour constituer une véritable infrastructure aussi complexe soit-elle.

Après avoir examiné Keystone et Nova sous tous les angles, vous pensez peut-être que l'essentiel a été vu et que leplus ardu est passé. Détrompez-vous. Neutron est sans doute la partie la plus épineuse. En particulier pour investigueret résoudre les problèmes qui ne manquent pas de se poser.

Décortiquons maintenant la manière dont sont mises en œuvre les infrastructures réseaux virtuelles avec Neutron.

4.6.2 Réseaux internes et réseaux externesAvec Neutron il faut bien différentier les réseaux externes des réseaux internes :– Les réseaux internes sont les réseaux virtuels qui constituent les infrastructures des utilisateurs.– Les réseaux externes correspondent à des segments ethernet (que j'appellerai également VLAN70 ou encore

domaine de diffusion) qui existent sur le campus de l'université, qui sont gérés par le CRI et indépendants dusystème OpenStack, et qui sont utilisés pour assurer une connectivité externe aux infrastructures virtuelles.

70 Virtual Local Area Network

Xavier Buche Cloud universitaire avec OpenStack – CNAM Nord-Pas de Calais 78

Ces deux types de réseau peuvent être connectés entre eux par l'intermédiaire de routeurs virtuels exécutés sur unemachine physique qui fait office de passerelle entre la grappe des nœuds de calcul et l'extérieur. Pour éviterd'augmenter le risque de pannes et les opérations de maintenance en multipliant les machines physiques, nous avonschoisi d'installer cette « passerelle » sur le contrôleur, dont les performances seront amplement suffisantes pouraccueillir cette fonction, au moins dans un premier temps.

4.6.3 NATLes routeurs du campus n'ont pas connaissance des réseaux internes. Seules les adresses IP externes des routeursvirtuels leur sont visibles. Pour que les communications d'une instance soient correctement transmises versl'extérieur, les routeurs doivent remplacer l'adresse IP source des paquets envoyés par celle de leur interface externe,et remplacer l'adresse IP de destination des réponses par celle de la machine virtuelle. Ce mécanisme est bien connuet largement déployé sur les réseaux locaux. Il est parfois appelé PNAT (Port-based Network Address Translation) car

Xavier Buche Cloud universitaire avec OpenStack – CNAM Nord-Pas de Calais 79

Figure 10 : réseau(x) interne(s) (à gauche) et réseau(x) externe(s) (à droite)

réseau virtuel 2

réseau virtuel 3

réseau virtuel 1

routeurvirtuel

réseau externe

Figure 11 : les routeurs virtuels

réseau virtuel 2

réseau virtuel 1

routeurvirtuel 1

réseau externerouteurvirtuel 2

routeurvirtuel N

réseau virtuel 3

réseau virtuel 4

réseau virtuel 5

réseau virtuel 6

contrôleur

le routeur n'a qu'une seule adresse IP externe, et pour qu'il sache à quelles machines renvoyer les réponses, ilmaintient dynamiquement une table d'association entre les adresses IP internes des machines virtuelles et le port TCPou UDP source des paquets envoyés au destinataire par le routeur.

Cette technique fonctionne très bien pour qu'une machine interne accède aux réseaux externes, mais comment unemachine de l'extérieur peut-elle accéder à une instance ? Impossible avec le PNAT.

L'une des possibilités est d'utiliser la fonction NAT statique, où on associe à chaque instance, de façon permanente,une adresse IP externe différente. La tâche du routeur est alors plus simple : un tableau statiquement défini associedes adresses internes à des adresses externes. Les paquets sortants voient leur adresse IP source remplacée parl'adresse externe correspondante, et inversement, les paquets entrants ont leur adresse de destination remplacée parl'adresse IP interne associée.

Xavier Buche Cloud universitaire avec OpenStack – CNAM Nord-Pas de Calais 80

Figure 12 : NAT dynamique

routeur virtuel R

réseau externe

Instance A

réseau interne

Requête envoyée vers C :- ip src : 10.20.30.40- ip dst : 50.60.70.80

10.20.30.40

machine distante C

Requête envoyée vers C :- ip src : 12.34.56.78- ip dst : 50.60.70.80- port src : 1234

12.34.56.78

50.60.70.80

Réponse envoyée vers R à destination de A :- ip src : 50.60.70.80- ip dst : 12.34.56.78- port dst : 1234

Réponse envoyée vers A :- ip src : 50.60.70.80- ip dst : 10.20.30.40

10.2.3.4

10.20.30.40

Réponse envoyée vers C :- ip src : 10.2.3.4- ip dst : 50.60.70.80

Requête envoyée vers C :- ip src : 10.2.3.4- ip dst : 50.60.70.80

Réponse envoyée vers R à destination de B :- ip src : 50.60.70.80- ip dst : 12.34.56.78- port dst : 5678

Requête envoyée vers C :- ip src : 12.34.56.78- ip dst : 50.60.70.80- port src : 5678

Instance B

table d'association

10.20.30.40 1234

10.2.3.4 5678

1 2

34

21

4 3

4.6.4 Adresse fixe et adresse flottanteC'est ici qu'intervient la notion d'adresse IP flottante, qui provient des clouds publics sur lesquels OpenStack tend à secalquer.

Il y a ainsi deux types d'adresses :– Les adresses IP fixes sont les adresses IP configurées sur les instances, généralement attribuées

automatiquement par un serveur DHCP71. Elles sont considérées comme fixes car associées à une instancetout au long de son cycle de vie.

– Les adresses IP flottantes sont des ressources à part entière, que l'utilisateur peut créer et associermanuellement à telle machine ou à telle autre (d'où le qualificatif de « flottante »). Ces adresses sontconfigurées uniquement au niveau du routeur pour qu'il réalise la traduction d'adresse, et sont accessibles del'extérieur de la plate-forme.

4.6.5 Espaces de noms réseauxLes adresses fixes et flottantes, ainsi que la technique du NAT, sont également utilisés par Nova-network. Là oùNeutron se distingue, c'est dans la possibilité, pour les utilisateurs, de définir eux-mêmes leurs propres réseaux etleurs propres routeurs. Nous avons vu précédemment que nous avions affecté la fonction de routage à notre contrôleur. Avec Nova-network,le contrôleur jouait le rôle de routeur unique pour le ou les réseaux virtuels. Avec Neutron, les routeurs peuvent êtredes dizaines comme des centaines ou des milliers, avec autant, voire davantage de réseaux virtuels.

En principe, un système d'exploitation dispose d'une seule table de routage, et peut donc être vu comme un et un seul

71 Dynamic Host Configuration Protocol

Xavier Buche Cloud universitaire avec OpenStack – CNAM Nord-Pas de Calais 81

Figure 13 : NAT statique

routeur virtuel R

réseau externe

Instance A

réseau interne

Requête envoyée vers C :- ip src : 10.20.30.40- ip dst : 50.60.70.80

10.20.30.40

machine distante C

Requête envoyée vers C :- ip src : 12.34.56.78- ip dst : 50.60.70.80

12.34.56.78

50.60.70.80

Réponse envoyée vers R à destination de A :- ip src : 50.60.70.80- ip dst : 12.34.56.78

Réponse envoyée vers A :- ip src : 50.60.70.80- ip dst : 10.20.30.40

12.34.56.79

10.2.3.4

10.20.30.40

Réponse envoyée vers C :- ip src : 10.2.3.4- ip dst : 50.60.70.80

Requête envoyée vers B :- ip src : 50.60.70.80- ip dst : 10.2.3.4

Réponse envoyée vers C :- ip src : 12.34.56.79- ip dst : 50.60.70.80

Requête envoyée vers R à destination de B :- ip src : 50.60.70.80- ip dst : 12.34.56.79

Instance B

table d'association

10.20.30.40 12.34.56.78

10.2.3.4 12.34.56.79

1 2

34

12

3 4

routeur. Pour qu'un système puisse assurer la fonction équivalente à de multiples routeurs, Linux dispose des espacesde noms réseaux, une fonctionnalité utilisée, par ailleurs, par les conteneurs LXC, dont il a été question dans lechapitre 2.1.1 sur les différents mode de virtualisation, page 14.

Les espaces de noms réseaux permettent de partitionner logiquement la fonction de routage du systèmed'exploitation, comme si elle était réalisée par des systèmes différents. Elle permet par exemple à plusieurs utilisateursde configurer leur réseau avec les mêmes plages d'adresses IP. Neutron utilise cette technologie pour compartimenterla fonction de routage.

Exemple : je souhaite afficher la configuration des interfaces ethernet du routeur nommé Routeur duréseau privé.

neutron router-show "Routeur du réseau privé"

+-----------------------+-----------------------------------------------------------------------------+

| Field | Value |

+-----------------------+-----------------------------------------------------------------------------+

| admin_state_up | True |

| external_gateway_info | {"network_id": "3ba1af49-9ee1-478e-9a1d-f4b766218c1a", "enable_snat": true} |

| id | efef4586-cc19-4e54-800e-6d655c432167 |

| name | Routeur du réseau privé |

| routes | |

| status | ACTIVE |

| tenant_id | buche |

+-----------------------+-----------------------------------------------------------------------------+

L'espace de noms reprend l'identifiant du routeur en le faisant précéder de la chaîne de caractères qrouter-.

Pour lancer la commande ifconfig dans le contexte de l'espace de nom du routeur Routeur du réseau privé, il faututiliser la syntaxe suivante :

ip netns exec qrouter-efef4586-cc19-4e54-800e-6d655c432167 ifconfig

lo Link encap:Local Loopback

inet addr:127.0.0.1 Mask:255.0.0.0

inet6 addr: ::1/128 Scope:Host

UP LOOPBACK RUNNING MTU:65536 Metric:1

RX packets:8 errors:0 dropped:0 overruns:0 frame:0

TX packets:8 errors:0 dropped:0 overruns:0 carrier:0

collisions:0 txqueuelen:0

RX bytes:784 (784.0 B) TX bytes:784 (784.0 B)

qg-367b3fe3-39 Link encap:Ethernet HWaddr fa:16:3e:72:b6:17

inet addr:172.28.1.2 Bcast:172.28.255.255 Mask:255.255.0.0

inet6 addr: fe80::f816:3eff:fe72:b617/64 Scope:Link

UP BROADCAST RUNNING MTU:1500 Metric:1

RX packets:224449 errors:0 dropped:0 overruns:0 frame:0

TX packets:156330 errors:0 dropped:0 overruns:0 carrier:0

collisions:0 txqueuelen:0

RX bytes:613096092 (613.0 MB) TX bytes:11387823 (11.3 MB)

qr-9fdf4419-ca Link encap:Ethernet HWaddr fa:16:3e:df:56:e9

inet addr:10.10.0.1 Bcast:10.10.255.255 Mask:255.255.0.0

inet6 addr: fe80::f816:3eff:fedf:56e9/64 Scope:Link

UP BROADCAST RUNNING MTU:1500 Metric:1

RX packets:146273 errors:0 dropped:0 overruns:0 frame:0

Xavier Buche Cloud universitaire avec OpenStack – CNAM Nord-Pas de Calais 82

TX packets:195600 errors:0 dropped:0 overruns:0 carrier:0

collisions:0 txqueuelen:0

RX bytes:11370022 (11.3 MB) TX bytes:611188524 (611.1 MB)

4.6.6 Cheminement des donnéesIl est temps désormais de comprendre comment, concrètement, les données sont transmises par les instances demachine virtuelle.

4.6.6.1 Entre les nœudsL'une des liaisons qui relie physiquement les nœuds de calcul avec les contrôleurs est dévolue au transit des donnéescirculant sur les réseaux des utilisateurs. Comment ces données sont-elles discriminées sur le lien physique ?

VLANCette question peut facilement être traitée en recourant aux VLAN, autrement dit au protocole IEEE 72 802.1Q, qui,schématiquement, ajoute un numéro à chaque trame ethernet transmise sur le lien. Chacun de ces numéros estassocié par Neutron au réseau d'un utilisateur. Les interfaces ethernet physiques jouent donc un rôle que l'on pourraitqualifier de multiplexeur/démultiplexeur.

En réalité, la numérotation n'est pas faite au niveau des interfaces physiques mais par un commutateur virtuel que j'aiappelé br-vlan, lequel se contente de numéroter les trames sortantes et dé-numéroter les trames entrantes.

Nova-network réalise l’interconnexion des machines virtuelles par des bridges Linux, qui sont des commutateursvirtuels, malgré ce que leur nom suggère. Neutron, quant à lui, par son système de plug-ins, offre le choix entredifférents outils. On peut donc utiliser les bridges Linux comme Nova-network. Mais la documentation suggèred'utiliser Open vSwitch, un gestionnaire de switches virtuels plus récent, mais plus rapide et offrant plus depossibilités.

Pour créer le commutateur br-vlan et le connecter à l'interface physique, j'ai lancé la commande suivante sur lesnœuds de calcul et le contrôleur :

ovs-vsctl add-br br-vlan

ovs-vsctl add-port br-vlan em3

Le lien physique ne relie pas directement les nœuds entre eux, mais par l’intermédiaire d'un commutateur ethernet.

72 Institute of Electrical and Electronics Engineers

Xavier Buche Cloud universitaire avec OpenStack – CNAM Nord-Pas de Calais 83

Figure 14 : tronçon 802.1Q

liaison physique

réseau virtuel 1

réseau virtuel 6

réseau virtuel 5

réseau virtuel 4

réseau virtuel 3

réseau virtuel 2

réseau virtuel 1

réseau virtuel 2

réseau virtuel 3

réseau virtuel 4

réseau virtuel 5

réseau virtuel 6

br-vlan br-vlan

Figure 15 : estampillage des trames 802.1Q

br-vlan

en-queueen-tête charge utile en-queueen-tête charge utilenuméro

trame ethernet provenant d'une instance trame ethernet transmise sur le trunk

Ce commutateur physique doit pouvoir interpréter les numéros de VLAN pour transmettre correctement les trames.Pour cela, les VLAN susceptibles d'être utilisés doivent être créés, et les interfaces concernées doivent être mises enmode trunk73.

Voici les commandes (précédées d'un prompt) que j'ai employées pour changer la configuration du commutateur :console>enable

console#configure terminal

# on crée des VLAN qui seront réservés aux réseaux des utilisateurs

console(config)#vlan 100-4093

console(config-vlan100-4093)#exit

# les liaisons qui transportent les réseaux des utilisateurs sont connectés aux ports 1 à 8

console(config)#interface range Tengigabitethernet 1/0/1-8

# le mode trunk est activé sur ces ports

console(config-if)#switchport mode trunk

# sur les trunks, on autorise uniquement les VLAN créés précédemment et on interdit implicitementles autres vlan utilisés pour l'administration d'OpenStack, le SAN, etc.

console(config-if)#switchport trunk allowed vlan 100-4093

Vous pouvez le constater : le nombre maximum de réseaux est relativement limité. Ceci vient du fait que le champ duprotocole 802.1Q qui contient le numéro du VLAN a une taille de 12 bits. Cependant cette restriction peut êtreoutrepassée par le choix d'un protocole alternatif. Nous y reviendrons plus loin.

Enfin, voici la manière dont j'ai configuré Neutron, dans le fichier /etc/neutron/plugins/ml2/ml2_conf.ini :– dans la section ml2, la directive tenant_network_types doit au minimum avoir la valeur vlan, pour préciser de

quelle façon s'effectue la ségrégation des réseaux virtuels sur les réseaux physiques– dans la section ml2_type_vlan, la directive network_vlan_ranges doit au moins contenir vmnet:100:4093,

vmnet étant une sorte d'alias référençant le switch virtuel indiqué dans la section ovs, et l'associant à la plagedes numéros de vlan utilisables

– dans la section ovs, la directive bridge_mappings doit au moins contenir la valeur vmnet:br-vlan, poursignifier que br-vlan est l’extrémité du trunk

GRE et VXLANDans le tutoriel officiel d'installation d'OpenStack, c'est GRE74 qui est utilisé pour encapsuler les réseaux desutilisateurs. Pour quelles raisons ?

GRE est un protocole qui établit un tunnel point à point entre deux machines. Les trames ethernet envoyées dans letunnel son encapsulées dans des paquets IP avec comme adresse de destination celle de la machine qui se trouve àl'autre extrémité du tunnel. De ce fait, et c'est la raison pour laquelle il a été choisi dans le guide d'installation, GRE nerequiert aucun paramétrage des commutateurs physiques.

En outre, les passerelles GRE (les extrémités des tunnels), peuvent se situer sur des réseaux IP distants, contrairementaux VLAN, qui sont forcément circonscrits à un domaine local (comme le campus par exemple). Par conséquent, onpeut imaginer, grâce à GRE, avoir un même réseau virtuel accessible sur des plates-formes OpenStack différentes etéloignées.Voici une capture, réalisée avec tcpdump, d'un échange de messages ICMP entre deux instances exécutées sur deuxhôtes différents et situées sur le même réseau. La capture est faite sur l'interface physique d'un hôte, sur le réseau desmachines virtuelles.

19:13:50.016240 IP (tos 0x0, ttl 64, id 26573, offset 0, flags [DF], proto GRE (47), length 126)

10.10.0.52 > 10.10.0.53: GREv0, Flags [key present], key=0x1, length 106

IP (tos 0x0, ttl 64, id 59663, offset 0, flags [DF], proto ICMP (1), length 84)

10.10.0.252 > 10.10.0.255: ICMP echo request, id 1080, seq 74, length 64

0x0000: ecf4 bbc5 146d ecf4 bbc5 22dd 0800 4500 .....m...."...E.

73 Ce terme est usité pour désigner une sorte de tunnel où transitent différents réseaux virtuels.74 Generic Routing Encapsulation

Xavier Buche Cloud universitaire avec OpenStack – CNAM Nord-Pas de Calais 84

0x0010: 007e 67cd 4000 402f be07 0a0a 0034 0a0a .~g.@.@/.....4..

0x0020: 0035 2000 6558 0000 0001 fa16 3e2f 403c .5..eX......>/@<

0x0030: fa16 3ed4 a24a 0800 4500 0054 e90f 4000 ..>..J..E..T..@.

0x0040: 4001 3b8b 0a0a 00fc 0a0a 00ff 0800 26a7 @.;...........&.

0x0050: 0438 004a ddb4 0d55 0000 0000 1bfa 0700 .8.J...U........

0x0060: 0000 0000 1011 1213 1415 1617 1819 1a1b ................

0x0070: 1c1d 1e1f 2021 2223 2425 2627 2829 2a2b .....!"#$%&'()*+

0x0080: 2c2d 2e2f 3031 3233 3435 3637 ,-./01234567

19:13:50.016720 IP (tos 0x0, ttl 64, id 15345, offset 0, flags [DF], proto GRE (47), length 126)

10.10.0.53 > 10.10.0.52: GREv0, Flags [key present], key=0x1, length 106

IP (tos 0x0, ttl 64, id 46008, offset 0, flags [none], proto ICMP (1), length 84)

10.10.0.255 > 10.10.0.252: ICMP echo reply, id 1080, seq 74, length 64

0x0000: ecf4 bbc5 22dd ecf4 bbc5 146d 0800 4500 ...."......m..E.

0x0010: 007e 3bf1 4000 402f e9e3 0a0a 0035 0a0a .~;.@.@/.....5..

0x0020: 0034 2000 6558 0000 0001 fa16 3ed4 a24a .4..eX......>..J

0x0030: fa16 3e2f 403c 0800 4500 0054 b3b8 0000 ..>/@<..E..T....

0x0040: 4001 b0e2 0a0a 00ff 0a0a 00fc 0000 2ea7 @...............

0x0050: 0438 004a ddb4 0d55 0000 0000 1bfa 0700 .8.J...U........

0x0060: 0000 0000 1011 1213 1415 1617 1819 1a1b ................

0x0070: 1c1d 1e1f 2021 2223 2425 2627 2829 2a2b .....!"#$%&'()*+

0x0080: 2c2d 2e2f 3031 3233 3435 3637 ,-./01234567

tcpdump fait ressortir la surcouche d'encapsulation de GRE. Dans la version hexadécimale des trames, j'ai surligné lemessage GRE, situé entre l'entête IP le transportant et l'entête de la trame transmise par les instances. Le messageGRE contient, entre autres, le numéro du tunnel. A ce numéro, Neutron associe l'adresse IP des deux extrémités dutunnel.

Les interfaces ethernet sont généralement configurée pour que les trames transmises transportent unmaximum de 1500 octets. Cette quantité se nomme MTU (Maximum Transmission Unit). Or, comme lescaptures le montrent, GRE ajoute une quarantaine d'octets aux trames ethernet envoyées par les machinesvirtuelles. La MTU des interfaces constituant les extrémités des tunnels GRE ne suffit donc pas.

Il faut l'augmenter en lançant une commande comme celle-ci :ifconfig em4 mtu 1600

Une autre possibilité consiste à diminuer la MTU des instances en modifiant la configuration du serveur DHCP, enajoutant dans le fichier /etc/neutron/dnsmasq/dnsmasq-neutron.conf :

dhcp-option-force=26,1400

Autre avantage de GRE : le numéro d'un tunnel est définit sur 32 bits, ce qui porte leur nombre maximum à plus de lamoitié de la population humaine !

Xavier Buche Cloud universitaire avec OpenStack – CNAM Nord-Pas de Calais 85

Comme on peut le constater sur ce joli schéma (Figure 16), un tunnel est créé entre chaque nœud du réseau. Leurnombre croit donc plus vite que le nombre de nœuds n, selon la formule n(n-1)/2. Avec 5 nœuds, il y a 10 tunnels.Avec 50 nœuds, le nombre de connexions point à point passe à 1225 ! Heureusement, Neutron se charge de créer cesliens de manière tout à fait transparente.

Passons maintenant aux inconvénients. Ou plutôt au seul véritable inconvénient, mais un inconvénient à ne pasnégliger. Là où 802.1Q insère quelques octets entre l'entête ethernet et l'entête IP, GRE double ces entêtes. D'une partcela consomme de la bande passante en réduisant le ratio données utiles / données de contrôles. Mais surtout, celaentraîne un temps de traitement notablement plus long et une consommation de cycles processeur beaucoup plusimportante.

A ce propos, la plupart des interfaces ethernet ont de nos jours une fonctionnalité de déchargement 802.1Qqui leur permet de réaliser elles-mêmes, en lieu et place du processeur, les tâches d'ajout, de suppressionet d'analyse des champs liés aux VLAN. Alors que seules quelques rares et onéreux modèles disposentd'une fonction de déchargement GRE ou VXLAN.

Mais tout cela demeure bien théorique. Voyons quelles sont les différences concrètes entre GRE et 802.1Q en matièrede performance. Commençons par créer un tunnel GRE entre deux nœuds :

- sur compute1 :iptunnel add tun0 mode gre remote 10.1.2.52 local 10.1.2.51

ifconfig tun0 192.168.111.51

ifconfig tun0 up

ifconfig tun0 pointopoint 192.168.111.52

- sur compute2 :iptunnel add tun0 mode gre remote 10.1.2.51 local 10.1.2.52

ifconfig tun0 192.168.111.52

ifconfig tun0 up

ifconfig tun0 pointopoint 192.168.111.51

Ensuite je lance un benchmark avec l'outil iperf.- sur compute2, j'exécute le serveur :

iperf -s

- et sur compute1, je me connecte au serveur pour commencer le test :iperf -c 192.168.111.52

[ ID] Interval Transfer Bandwidth

[ 3] 0.0-10.0 sec 6.56 GBytes 5.63 Gbits/sec

- en parallèle, je sonde la consommation CPU :sar 1 8

CPU %user %nice %system %iowait %steal %idle

Average: all 0,15 0,00 3,59 0,14 0,00 96,12

Xavier Buche Cloud universitaire avec OpenStack – CNAM Nord-Pas de Calais 86

Figure 16 : topologie d'un réseau basé sur leprotocole GRE : maillage complet

contrôleur

compute4

compute3compute2

compute1

Comparons avec 802.1Q sur une interface virtuelle.- je charge le module du noyau Linux qui prend en charge les VLAN :

modprobe 8021q

- j'installe les outils de gestion des VLAN :apt-get install vlan

- je crée l'interface virtuelle em4.10 pour le vlan 10 sur l'interface physique em4 :vconfig add em4 10

- et j'affecte une adresse à cette interface :ifconfig em4.10 10.1.2.51

- je fais la même chose sur l'interface d'un autre nœud et lui affecte l'adresse 10.1.2.52.iperf -c 10.1.2.52

[ ID] Interval Transfer Bandwidth

[ 3] 0.0-10.0 sec 7.78 GBytes 6.68 Gbits/sec

sar 1 8

CPU %user %nice %system %iowait %steal %idle

Average: all 0,55 0,00 3,64 0,09 0,00 95,72

Résultat : le débit passe de 5,63 Gb/s avec GRE à 6,68 Gb/s avec 802.1Q et la consommation CPU est beaucoup moinsélevée avec les VLAN, même si elle reste très faible en mode GRE.

Essayons avec un autre outil : netperf.

- avec GRE :netperf -H 192.168.111.52 -c -C

MIGRATED TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 192.168.111.52 () port 0 AF_INET : demo

Recv Send Send Utilization Service Demand

Socket Socket Message Elapsed Send Recv Send Recv

Size Size Size Time Throughput local remote local remote

bytes bytes bytes secs. 10^6bits/s % S % S us/KB us/KB

87380 16384 16384 10.00 5342.55 4.11 2.85 1.511 1.048

- avec 802.1Qnetperf -H 10.1.2.52 -c -C

MIGRATED TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 10.1.2.52 () port 0 AF_INET : demo

Recv Send Send Utilization Service Demand

Socket Socket Message Elapsed Send Recv Send Recv

Size Size Size Time Throughput local remote local remote

bytes bytes bytes secs. 10^6bits/s % S % S us/KB us/KB

87380 16384 16384 10.00 6780.46 2.98 3.17 0.864 0.918

netperf confirme les résultats obtenus avec iperf : le débit est plus important et la consommation processeur plusfaible avec les VLAN.

Après avoir commencé les essais d'OpenStack avec GRE, et constatant les résultats de ce benchmark, nousavons donc décidé d'utiliser 802.1Q à la place.

Avant d'aller plus loin en montrant que cette transition n'est pas d'une simplicité anodine, disons quelques mots sur letroisième choix proposé par neutron pour la virtualisation des réseaux d'utilisateurs : VXLAN.

Xavier Buche Cloud universitaire avec OpenStack – CNAM Nord-Pas de Calais 87

Presque tout ce que nous venons de dire sur GRE est également valable avec VXLAN75. Ces protocoles sont tous deuxsi proches, en matière de fonctionnalités, que certains spécialistes pensent qu'ils devraient fusionner.La différence fondamentale entre GRE et VXLAN tient dans la prise en charge des transmissions appelées parfoisBUM, pour Broadcast, Unknown unicast, Multicast. Avec GRE, lorsqu'un réseau virtuel veut réaliser ce type detransfert, les données sont physiquement envoyées à tous les autres nœuds du cluster, inconditionnellement. AvecVXLAN, ces données sont envoyées à destination d'un groupe multicast dont les membres sont les nœuds quiexécutent des instances connectées au réseau virtuel. Autrement dit, seuls les nœuds potentiellement « intéressés »par les données les reçoivent, ce qui est particulièrement avantageux dans les gros centre de données.

Changement du protocoleAprès avoir remplacé GRE par 802.1Q, les réseaux préexistants ne sont plus joignables, alors que les réseauxnouvellement créés fonctionnent bien.Si on crée une instance sur un réseau préexistant, l'erreur suivante apparaît sur le nœud de calcul dans/var/log/nova/nova-compute.log :

Returning exception Unexpected vif_type=binding_failed to caller

Tentons de mettre à jour les options du réseau Accès campus pour qu'il passe du type GRE au type VLAN.neutron net-update --provider:network_type=vlan --provider:physical_network=vmnet --provider:segmentation_id=101 11c5b2b2-c022-44b7-ac1d-18a0a4d82ede

400-{u'NeutronError': {u'message': u'Invalid input for operation: Plugin does not support updating provider attributes.', u'type': u'InvalidInput', u'detail': u''}}

Ça ne fonctionne pas. L'API de Neutron ne fournit pas cette possibilité.

Essayons de modifier directement la table ml2_network_segments de la base de données de Neutron, qui associe desnuméros de tunnel ou de VLAN avec des réseaux d'utilisateurs.

update ml2_network_segments set network_type='vlan',physical_network='vmnet', segmentation_id=101where network_id='11c5b2b2-c022-44b7-ac1d-18a0a4d82ede';

Query OK, 1 row affected (0.01 sec)

Rows matched: 1 Changed: 1 Warnings: 0

Après avoir redémarré neutron sur le contrôleur et les nœuds de calcul, le réseau est de nouveau opérationnel.

Généralisons finalement à tous les anciens réseaux : update ml2_network_segments set network_type='vlan',physical_network='vmnet', segmentation_id=(100+segmentation_id) where network_type='gre';

Précisons pour conclure que les anciens réseaux doivent avoir des numéros situés hors de la plage configurée dansNeutron. Par exemple, si les anciens VLAN ont des numéros qui vont de 100 à 199, alors, dans le fichier/etc/neutron/plugins/ml2/ml2_conf.ini, la directive network_vlan_ranges devrait contenir quelque chose commevmnet:200:4093.

4.6.6.2 Sur les nœuds de calculNous venons d'entrevoir la partie émergée de l'iceberg, c'est-à-dire la manière dont les données sont échangées entreles nœuds physiques. Voyons maintenant ce qui se passe à l'intérieur de ces machines. Commençons par les nœuds decalcul.

Lorsqu'une instance de machine virtuelle est construite, Neutron crée un port, c'est-à-dire une interface virtuelleconnectée à un réseau virtuel. Le port est associé à cette instance dans une table de la base de données de Neutron.Concrètement, une interface virtuelle est alors créée sur l'hôte. Elle porte un nom qui commence par tap, suivi d'unidentifiant constitué des onze premiers caractères de celui du port Neutron.

Exemple :

- on crée un port sur le réseau mon_reseau :neutron port-create --name nouveau_port mon_reseau

75 Virtual eXtended Local Area Network

Xavier Buche Cloud universitaire avec OpenStack – CNAM Nord-Pas de Calais 88

+-----------------------+-------------------------------------------------------------------------------------+

| Field | Value |

+-----------------------+-------------------------------------------------------------------------------------+

| admin_state_up | True |

| allowed_address_pairs | |

| binding:host_id | |

| binding:profile | {} |

| binding:vif_details | {} |

| binding:vif_type | unbound |

| binding:vnic_type | normal |

| device_id | |

| device_owner | |

| fixed_ips | {"subnet_id": "51ec1a38-e8a6-4ab5-baab-0db473e52574", "ip_address": "192.168.0.10"} |

| id | dfb2ee89-17a3-45ed-9484-bcac127cb076 |

| mac_address | fa:16:3e:37:8d:81 |

| name | nouveau_port |

| network_id | 581b80e7-e71c-494b-a3a4-ce5c8eee5e0b |

| security_groups | 317efb9b-f851-4930-b3e1-1ef03c0da0ed |

| status | DOWN |

| tenant_id | buche |

+-----------------------+-------------------------------------------------------------------------------------+

- on associe ce port à notre instance :nova interface-attach --port-id $(neutron port-show -f shell nouveau_port |grep ^id= |cut -d'"' -f2) mon_instance

- on constate alors qu'une nouvelle interface tap a été créée sur l'hôte :ip link show tapdfb2ee89-17

35: tapdfb2ee89-17: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master qbrdfb2ee89-17 stateUNKNOWN mode DEFAULT group default qlen 500

link/ether fe:16:3e:37:8d:81 brd ff:ff:ff:ff:ff:ff

Toutes les interfaces tap sont reliées à un commutateur commun appelé br-int. Le trafic des réseaux d'utilisateurs estdifférentié par l'ajout d'un numéro aux trames, selon le protocole 802.1Q. Ce numéro est différent du numéroéventuellement utilisé lors du transfert des trames sur le trunk physique, dans le cas où le mode VLAN a été choisi(voir chapitre précédent).

En réalité, les interfaces tap ne sont pas directement connectées au switch br-int, mais par l'intermédiaire d'un bridgeLinux. Pourquoi ? Les règles de pare-feu configurées avec Neutron et associées aux instances (voir le chapitre 4.6.11 sur les groupes desécurité, page 97) doivent être appliquées au plus près de celles-ci. Or, elles ne peuvent techniquement pas êtreaffectées à un commutateur Open vSwitch comme br-int. Neutron crée donc des bridges Linux intermédiaires surlesquels sont appliquées les règles de filtrage.

Enfin, br-int est connecté à un commutateur dépendant du protocole choisi pour l'interconnexion des nœuds : br-vlandans notre cas, et br-tun si on utilise GRE ou VXLAN.

Mis à part le switch br-vlan qu'il faut créer manuellement, tous les autres commutateurs virtuels, ainsique leurs interconnexions, sont gérés par Neutron.

La commande suivante affiche la configuration générale des commutateurs Open vSwitch d'un nœud de calcul :ovs-vsctl show

ed2f537c-6a36-45f9-92fc-9d451b8285f3

Xavier Buche Cloud universitaire avec OpenStack – CNAM Nord-Pas de Calais 89

Bridge br-int

fail_mode: secure

Port "qvo7b0f5f3b-fe"

tag: 1

Interface "qvo7b0f5f3b-fe"

Port "qvof5896946-4d"

tag: 2

Interface "qvof5896946-4d"

Port "qvoae5fa0f0-38"

tag: 1

Interface "qvoae5fa0f0-38"

Port int-br-vlan

Interface int-br-vlan

Port "qvodfb2ee89-17"

tag: 3

Interface "qvodfb2ee89-17"

Port br-int

Interface br-int

type: internal

Bridge br-vlan

Port br-vlan

Interface br-vlan

type: internal

Port phy-br-vlan

Interface phy-br-vlan

Port "em4"

Interface "em4"

ovs_version: "2.0.2"

L'interface tap créée précédemment est connectée, via un bridge Linux, à une interface de br-int qui porte unidentifiant similaire et qui commence par qvo : qvodfb2ee89-17.Le « tag » est un numéro utilisé par 802.1Q pour différentier les réseaux les uns des autres sur un même nœud.Enfin l'interface int-br-vlan de br-int est connectée par un trunk à l'interface phy-br-vlan de br-vlan.

Et puisqu'un bon croquis vaut mieux qu'un long discours, voici un schéma synthétique du réseau virtuel d'un nœudde calcul. Pour une plus grande clarté, les identifiants des interfaces tap, qvb, qvo et qbr n'ont pas été représentés.

Xavier Buche Cloud universitaire avec OpenStack – CNAM Nord-Pas de Calais 90

Figure 17 : infrastructure réseau virtuelle d'un nœud de calcul

liaison physique (trunk)

instance br-vlan

trunk logicielqvbtapeth0

phy-br-vlanint-br-vlanqvo

qbr br-int

em4

noeud de calcul

Voici ce que signifient les sigles propres à OpenStack :– qbr : Quantum BRidge (bridge Linux utilisé par Quantum, l'ancien nom de Neutron)– qvb : Quantum Veth pair, côté Bridge Linux (le lien qui relie qbr et br-int est appelé paire d'interfaces ethernet

virtuelles, ou veth pair en anglais et en abrégé)– qvo : Quantum Veth pair, côté Open vSwitch

4.6.6.3 Sur le contrôleurCôté contrôleur, un switch virtuel Open vSwitch joue le rôle d'extrémité du tunnel. Il pourra s'appeler br-tun si onutilise GRE ou VXLAN. Mais dans notre cas, nous utilisons les VLAN et avons nommé ce switch br-vlan, comme surles nœuds de calcul.Un commutateur d'intégration, br-int, est également utilisé. D'un côté, il est connecté à br-vlan via un trunk, del'autre, aux interfaces internes des routeurs virtuels. Rappelons que chacun de ces routeurs est exécuté sur un espacede noms différent.Leur interface externe est de nouveau reliée à br-int. Enfin, br-int est connecté au switch br-ex, qui est lui-même reliéaux interfaces d'accès aux réseaux externes.

Une fois de plus, un schéma est certainement plus intelligible que de longues phrases.

Pour une meilleure lisibilité, les identifiants ne sont pas indiqués.

Voici ce que signifient les sigles propres à OpenStack :qr : Quantum Router (interface du routeur côté interne)qg : Quantum Gateway (interface du routeur côté externe)

Le serveur DHCP exécute des processus pour fournir une configuration réseau aux instances de machinevirtuelle. Exactement comme les routeurs, chacun de ces processus est connecté à un réseau virtuel etdispose de son propre espace de noms.

Revenons un instant sur l'exemple du routeur dont nous avions listé les interfaces réseaux au chapitre 4.6.5 sur lesespaces de noms réseaux, page 81. On peut constater que ce routeur dispose bien, en plus de son interface loopback (lo),d'une interface « interne » (qr-9fdf4419-ca ) et d'une interface « externe » (qg-367b3fe3-39 ).

Enfin, vous avez peut-être remarqué que le schéma fait mention de plusieurs réseaux externes transportés par untrunk et d'une interface bond0 qui suggère une redondance de liens. Cet aspect de Neutron mérite une partie à lui

Xavier Buche Cloud universitaire avec OpenStack – CNAM Nord-Pas de Calais 91

Figure 18 : infrastructure réseau virtuelle du contrôleur

br-vlan br-ex

trunk logicielem3

int-br-vlanphy-br-ex

qg

br-int

phy-br-vlan bond0 trunk physiquetrunk physique

contrôleur

qr

qrouter

DHCP

tap

RESEAUXEXTERNES

RESEAUXINTERNES

trunk logicielint-br-ex

seul. Mais avant d'y venir et pour clore ce chapitre, voici l'allure de la configuration générale d'Open vSwitch sur lecontrôleur.

ovs-vsctl show

Bridge br-int

fail_mode: secure

...

Port "qr-234d932b-83"

tag: 6

Interface "qr-234d932b-83"

type: internal

Port "tap2a733a98-75"

tag: 4

Interface "tap2a733a98-75"

type: internal

Port "qg-ff0e8b10-d8"

tag: 3

Interface "qg-ff0e8b10-d8"

type: internal

Port int-br-vlan

Interface int-br-vlan

Port int-br-ex

Interface int-br-ex

Port br-int

Interface br-int

type: internal

...

Bridge br-vlan

Port "em3"

Interface "em3"

Port br-vlan

Interface br-vlan

type: internal

Port phy-br-vlan

Interface phy-br-vlan

Bridge br-ex

Port phy-br-ex

Interface phy-br-ex

Port br-ex

Interface br-ex

type: internal

Port "bond0"

trunks: [0, 28]

Interface "em4"

Interface "p1p4"

ovs_version: "2.0.2"

Xavier Buche Cloud universitaire avec OpenStack – CNAM Nord-Pas de Calais 92

4.6.7 Les réseaux externesIl peut être utile de donner aux utilisateurs la possibilité d'utiliser des adresses IP flottantes situées sur différentsréseaux externes. Par exemple, on peut imaginer laisser habituellement aux utilisateurs l'accès à un réseau privé, etdans le cas où l'un d'eux demande à ce que son serveur soit accessible depuis Internet, il pourrait utiliser une adresseIP publique. J'ai donc configuré deux réseaux externes : un réseau privé et un réseau public.

Ce que j'ai l'habitude de nommer réseau interne et réseau externe est appelé, selon la terminologie d'OpenStack,réseau de projet (tenant network) et réseau de fournisseur (provider network). Les premiers sont gérés par lesutilisateurs, qui ne connaissent pas la manière dont ils sont physiquement mis en œuvre. Les seconds sont gérés parles administrateurs d'OpenStack et sont configurés de manière à correspondre à des réseaux extérieurs à la plate-forme.

Voici les commandes que j'ai exécutées pour créer les deux réseaux de fournisseur :neutron net-create "Réseau externe public" -- --router:external=true --provider:network_type=flat--provider:physical_network=extnet

neutron net-create "Réseau externe privé" -- --router:external=true --provider:network_type=vlan --provider:physical_network=extnet -–provider:segmentation_id=28

Un trunk relie l'interface ethernet externe du contrôleur avec le commutateur géré par le CRI qui donne accès auxréseaux externe. Sur ce lien, les trames du réseau privé sont identifiées par le numéro 28, tandis que les trames duréseau public sont identifiées par l'absence de numéro. Autrement dit, ce sont des trames ethernet « normale ».

De ce fait, en paramètre des commandes précédentes, le réseau privé est de type VLAN, avec un identifiant desegment de 28, et le réseau public est de type flat. On indique que ces réseaux se situent du côté « externe » des routeurs. Ils ne sont donc pas directement joignable parles utilisateurs, mais par l'intermédiaire d'un processus de traduction d'adresses (NAT). Pour terminer, on référence un nom de réseau physique (extnet) qui sera utilisé dans un fichier de configuration deNeutron pour préciser le nom du switch virtuel connecté à l'extérieur (br-ex).

Voici les commandes que le pôle réseau du CRI a exécutées sur le commutateur pour configurer ce trunk surl'interface connectée au contrôleur :

# on active le mode trunk

Switch(config-if)# switchport mode trunk

# choix du protocole de numérotation des trames

Switch(config-if)# switchport trunk encapsulation dot1q

# seuls les VLAN 308 (public) et 28 (privé) sont transmis sur le trunk

Switch(config-if)# switchport trunk allowed vlan add 308,28

# les trames du VLAN 308 n'ont pas de champ 802.1Q

Switch(config-if)# switchport trunk native vlan 308

Passons à la configuration du contrôleur, dans le fichier /etc/neutron/plugins/ml2/ml2_conf.ini :– Dans la section ml2_type_vlan, on ajoute extnet à la directive network_vlan_ranges, qui contient déjà une

référence au réseau physique des machines virtuelles des utilisateurs (vmnet).– Dans la section ovs, on ajoute extnet:br-ex à la directive bridge_mappings pour indiquer que le switch virtuel

qui est connecté aux réseaux externes est br-ex.

Le contrôleur est ainsi configuré de cette manière :[ml2_type_vlan]

network_vlan_ranges = extnet,vmnet:110:4093

[ovs]

bridge_mappings = extnet:br-ex,vmnet:br-vlan

Il ne reste plus qu'à créer les « sous-réseaux », c'est-à-dire les réseaux IP et les plages d'adresses louées par le serveurDHCP.

neutron subnet-create --disable-dhcp –allocation-pool start=134.206.8.30, end=134.206.8.250 --gateway 134.206.8.1 "Réseau externe public" 134.206.8.0/24

Xavier Buche Cloud universitaire avec OpenStack – CNAM Nord-Pas de Calais 93

neutron subnet-create --disable-dhcp "Réseau externe privé" 172.28.0.0/16

4.6.8 Agrégation de liensPlutôt que d'utiliser un seul lien pour interconnecter les nœuds de la plate-forme, il est préférable d'utiliser, pourchaque réseau, plusieurs liaisons mises en parallèle. Tout d'abord cette redondance améliore la fiabilité : si uneinterface, un câble, voire un switch tombe en panne, un autre chemin est choisi. Mais l'agrégation peut égalementaugmenter la bande passante, et donc le débit maximum de transmission, en répartissant les données sur les différentsliens.

Voyons comment appliquer cette technique sur la liaison externe reliant le contrôleur avec le commutateur externe.

Lorsqu'une trame ethernet est envoyée sur l'agrégat, le choix de l'interface physique se fait selon certainescaractéristiques de cette trame ou du paquet IP qu'elle contient :

– l'adresse matérielle76 source– l'adresse matérielle de destination– une combinaison des adresses matérielles source et destination– l'adresse IP source– l'adresse IP de destination– une combinaison des adresses IP source et destination

Ce critère doit être choisi avec clairvoyance, sous peine d'obtenir une distribution non équitable de la charge entre lesinterfaces physiques. Le principe est de se fonder sur un élément qui varie beaucoup d'un paquet à l'autre. Or lesadresses matérielles varient très peu : il y a actuellement deux réseaux externes, soit deux passerelles, ce qui n'est passuffisant, côté switch, pour faire une distribution basée sur l'adresse MAC source. Côté serveur, quelque soit lasolution basée sur l'adresse MAC, le trafic risque de se concentrer sur le lien choisi pour les connexions au routeurOpenStack.

Du point de vue de la répartition de la charge, l'idéal est donc de se baser sur les adresses IP. L'inconvénient de cetteméthode est qu'elle oblige le switch à inspecter le contenu des trames ethernet (l'entête IP). Au lieu d'utiliser sesprocesseurs spécialisés dans la commutation ethernet (ASIC, Application-Specific Integrated Circuit), le switch utiliseson CPU (Central Processing Unit), ce qui peut avoir une influence sur les performances.

4.6.8.1 Configuration côté switchSur le commutateur, l'agrégation de lien se nomme etherchannel. Sa configuration passe par la création d'une interfacevirtuelle appelée port-channel, qui contient les interfaces physiques membres de l'agrégat. Les instructions utilisées auchapitre précédent pour créer le trunk doivent être appliquées au port-channel.

Voici les commandes que le pôle réseau du CRI a lancées sur le commutateur relié au contrôleur :Switch# configure terminal

Switch(config)# interface range gigabitethernet 0/13 -14

Switch(config-if-range)# channel-group 10 mode active

Creating a port-channel interface Port-channel 10

Switch(config-if-range)# no shutdown

Switch(config-if-range)# exit

# la répartition de la charge se fonde sur le résultat d'une opération de ou exclusif appliquée aux adresses IP source et destination des paquets

Switch(config)# port-channel load-balance src-dst-ip

Switch(config)# end

Un etherchannel peut utiliser un protocole de contrôle pour :– vérifier que les interfaces du dispositif distant sont bien configurées (vitesse, mode de duplex, etc.)– informer le dispositif distant de la défaillance d'un lien, au cas où il ne pourrait pas le détecter lui-même– éventuellement contrôler dynamiquement les interfaces distantes membres de l'agrégat

76 souvent appelée adresse MAC, Media Access Control

Xavier Buche Cloud universitaire avec OpenStack – CNAM Nord-Pas de Calais 94

Sur les switches Cisco Catalyst, on a le choix entre ces deux protocoles de contrôle :– PAgP (Port Aggregation Protocol), plus ancien mais propriétaire, et donc compatible uniquement avec le

matériel Cisco– LACP (Link Aggregation Control Protocol), standardisé par l'IEEE sous le code 802.3ad

Le CRI a pour habitude d'utiliser le protocole LACP, à côté duquel PAgP n'offre aucun véritable intérêt. C'est le modeactive mis en paramètre de la commande channel-group qui indique que LACP est sélectionné.

Précisons qu'avec LACP, toutes les interfaces d'un agrégat doivent être du même type (même vitesse,même mode de duplex).

4.6.8.2 Configuration côté contrôleurSous Linux, l'agrégation de liens est pris en charge par un module du noyau appelé bonding. Cependant, une interfacevirtuelle créée avec ce module ne peut pas être connectée à un switch Open vSwitch comme br-ex.

Heureusement, Open vSwitch intègre une fonctionnalité équivalente. Mettons-là en place :ovs-vsctl add-bond br-ex bond0 em4 p1p4 lacp=active bond_mod=balance-tcp other_config:lacp-time=fast

trunks=0,28

Par cette commande, on crée une interface virtuelle77, bond0, qui agrège les interfaces physiques em4 et p1p4. Leprotocole LACP est activé, ce qui a pour effet, comme sur le switch, d'envoyer régulièrement des paquets de contrôle.La période d'émission est de une seconde au lieu de trente par défaut car le mode fast est sélectionné. On préciseégalement que cette interface de bonding doit charrier le vlan 28 ainsi que les trames ethernet non numérotées (vlannatif).

L'argument bond_mode permet de choisir selon quels critères les paquets sont répartis sur les interfaces physiques.Les possibilités sont moins fournies que le module du noyau Linux, mais l'essentiel y est. Le choix le plus approprié,balance-tcp, consiste à sélectionner l'interface physique sur laquelle transmettre une trame en fonction d'un condensatcalculé sur la base d'informations de niveau 2, 3 et 478 contenues dans cette trame. En d'autres termes, les valeurs decertains champs des entêtes ethernet, IP et TCP ou UDP sont utilisées.

Les options de configuration du bonding avec Open vSwitch sont bien trop nombreuses pour que je m'étendedavantage sur le sujet.Résultat :

ovs-vsctl show

...

Bridge br-ex

...

Port "bond0"

trunks: [0, 28]

Interface "em4"

Interface "p1p4"

...

N'oublions pas d'activer les interfaces physiques :ifconfig em4 up

ifconfig p1p4 up

Et terminons par quelques essais.J'envoie des requêtes d’écho ICMP sur l'agrégat :

ping 172.28.0.10

77 appelée port dans la terminologie d'Open vSwitch78 couches du modèle OSI

Xavier Buche Cloud universitaire avec OpenStack – CNAM Nord-Pas de Calais 95

Une capture de trames sur em4 révèle que les requêtes passent par cette interface.

Je lance une capture sur p1p4 et je désactive em4 :tcpdump -i p1p4

ifconfig em4 down

Tout le trafic est alors basculé sur p1p4 en moins d'une seconde.

Je lance l'opération inverse :ifconfig em4 up

tcpdump -i em4

ifconfig p1p4 down

De la même manière, tout le trafic est basculé sur em4 en moins d'une seconde.ifconfig p1p4 up

Pour l'instant, nous nous bornons à cet agrégat, entre le contrôleur et le commutateur externe. Mais par lasuite, nous comptons installer un deuxième switch externe et un deuxième switch interne, ainsi queréaliser des agrégats sur l'ensemble des interconnexions entre les nœuds OpenStack, afin d'augmenter larésilience et les performances du réseau.

4.6.9 Les agentsComme avec les autres briques d'OpenStack, les instructions sont envoyées à Neutron par les utilisateurs ou lesautres composants par l'intermédiaire d'une API RESTful exposée par le démon neutron-server sur le contrôleur.Par exemple, lorsque nova vient de créer une machine virtuelle, il se connecte à l'API de Neutron pour lui demanderde connecter l'instance à son réseau.

Le démon neutron-server communique avec les agents Neutron via le bus de messagerie AMQP. À chaque agent estconfié une tâche précise :– neutron-dhcp-agent : comme son nom l'indique, il s'agit d'un serveur DHCP exécuté sur le contrôleur et qui

fournit une configuration réseau aux instances de machine virtuelle– neutron-l3-agent : assure la fonction de routage et de traduction d'adresses sur le contrôleur– neutron-metering-agent : collecte des mesures sur le trafic réseau des utilisateurs– neutron-*-agent : fournit les plug-ins qui assurent la fonction de segmentation de niveau 2 (ethernet)

La configuration de Neutron est largement modulable. Elle se fonde sur la notion de plug-in, qui permet de choisir lamanière dont seront mises en œuvre les instructions de l'API.

Par exemple, Neutron peut lui-même commander les commutateurs physiques de la plate-forme pour que les VLANsoient créés à la volée. Ou encore, on peut choisir de déléguer certaines fonctions, comme affecter le routage à unrouteur physique spécialisé, qui sera très performant et pourrait décharger le contrôleur de cette tâche. C'est d'ailleursune option que l'on envisage en cas de saturation du contrôleur.

Concernant la segmentation ethernet, il est possible de choisir directement un plug-in, comme Open vSwitch ou lesbridges linux, mais la documentation recommande d'utiliser dorénavant un plug-in intermédiaire, ML2 (ModularLayer 2), qui permet notamment d'utiliser simultanément plusieurs plug-ins et de simplifier leur développement. Parexemple, c'est avec ML2 que j'ai indiqué à Neutron que je souhaitais utiliser 802.1Q plutôt que GRE comme protocolede tunneling (voir le chapitre 4.6.6 sur le cheminement des données, page 83).

4.6.10 Simplification et partageA ce stade, Neutron est désormais correctement configuré. Néanmoins, un nouvel utilisateur souhaitant simplementcréer une machine virtuelle doit d'abord créer son réseau et son sous-réseau, ce qui est, vous en conviendrez,particulièrement laborieux.

Pour simplifier les choses, l'une des solutions possibles est d'automatiser cette tâche. Soit systématiquement et àl'avance. De nombreux réseaux seront alors créés pour des utilisateurs qui ne se connecteront jamais à la plate-forme.Soit au moment où l'utilisateur se connecte ou exécute une instance, ce qui est complexe car nécessite un

Xavier Buche Cloud universitaire avec OpenStack – CNAM Nord-Pas de Calais 96

développement logiciel à intégrer au code d'OpenStack.

L'autre solution, que nous avons choisie pour l'instant, est de créer un réseau interne partagé. Lesinstances de tous les utilisateurs peuvent s'y connecter. Ce réseau est connecté à un routeur, et ce routeurest connecté au réseau externe privé.

Je crée le réseau partagé et le sous-réseau associé :neutron net-create --tenant-id admin --shared "Accès au réseau privé"

neutron subnet-create --tenant-id admin --name "Sous-réseau accès réseau privé" 10.10.0.0/16

Je crée un routeur et je le connecte d'une part au réseau interne et de l'autre au réseau externe :neutron router-create --tenant-id admin "Routeur du réseau privé

neutron router-interface-add "Routeur du réseau privé" "Sous-réseau accès réseau privé"

neutron router-gateway-set "Routeur du réseau privé" "Réseau externe privé"

Lors de la création d'une instance avec l'interface web, ce réseau, comme il est le seul utilisable, est automatiquementsélectionné. Les utilisateurs n'ont donc pas à ce soucier de la partie réseau s'ils n'en ont cure.

4.6.11 Les groupes de sécurité

4.6.11.1 Qu'est ce donc ?Sécuriser l'accès à un serveur passe toujours par la configuration d'un pare-feu. Cette opération importante peut êtreréalisée directement sur le serveur, mais dans ce cas, elle dépend du système d'exploitation et requiert unecompétence certaine de la part de l'utilisateur de la machine.

Pour simplifier ce paramétrage, OpenStack met à disposition les groupes de sécurité. Il s'agit de listes de règles defiltrage réseau que l'utilisateur peut facilement créer, éditer et appliquer aux instances de ses machines virtuelles.De plus, associer une instance à un groupe de sécurité peut constituer un critère de filtrage. Par exemple, on peutdécréter, par une règle de contrôle d'accès, que les communications entre toutes les instances associées à un groupede sécurité particulier ne subissent aucune restriction.

La gestion des groupes de sécurité peut se faire indifféremment avec l'API de Nova ou celle de Neutron.

Commençons par créer un groupe de sécurité :neutron security-group-create mon_pare-feu

Created a new security_group:

| id | be594c66-0f05-41db-b508-ad35db6f8717

| name | mon_pare-feu

| security_group_rules | {"remote_group_id": null, "direction": "egress", "remote_ip_prefix": null, "protocol": null, "tenant_id": "admin", "port_range_max": null, "security_group_id": "be594c66-0f05-41db-b508-ad35db6f8717", "port_range_min": null, "ethertype": "IPv4", "id": "3f6296a0-6990-4008-be84-8ee31a41b4f0"} |

| | {"remote_group_id": null, "direction": "egress", "remote_ip_prefix": null, "protocol": null, "tenant_id": "admin", "port_range_max": null, "security_group_id": "be594c66-0f05-41db-b508-ad35db6f8717", "port_range_min": null, "ethertype": "IPv6", "id": "075ab589-9168-460a-9f8b-bb9324654dd1"} |

| tenant_id | buche

Par défaut, un nouveau groupe est paré de deux règles de filtrage, qui autorisent l'envoi (direction egress) de toustypes de donnée (ethertype "IPv4" et "IPv6", protocol "null") vers n'importe quelle destination (IP distante "null").Implicitement, une règle autorise les paquets de retour des connexions sortantes. Par exemple, si j'émets une requêteICMP depuis mon instance, elle sera explicitement acceptée grâce aux règles ci-dessus, mais la réponse seraégalement autorisée, car le pare-feu aura reconnu qu'il s'agit d'une réponse à un paquet qu'il vient de laisser passer.

Admettons maintenant que je souhaite que toutes les instances associées à ce groupe de sécurité puissent se

Xavier Buche Cloud universitaire avec OpenStack – CNAM Nord-Pas de Calais 97

« pinguer » entre elles, et uniquement entre elles :neutron security-group-rule-create --direction ingress --remote-group-id mon_pare-feu --protocol icmp mon_pare-feu

Created a new security_group_rule:

+-------------------+--------------------------------------+

| Field | Value |

+-------------------+--------------------------------------+

| direction | ingress |

| ethertype | IPv4 |

| id | b9b4ffbb-74a5-486b-aa9c-5d4a6cde68fc |

| port_range_max | |

| port_range_min | |

| protocol | icmp |

| remote_group_id | be594c66-0f05-41db-b508-ad35db6f8717 |

| remote_ip_prefix | |

| security_group_id | be594c66-0f05-41db-b508-ad35db6f8717 |

| tenant_id | buche |

+-------------------+--------------------------------------+

Cette règle ouvre la voie aux paquets ICMP (protocol) en provenance (direction ingress) des instances associées augroupe de sécurité mon_pare-feu (remote-group-id). Cette règle est ajoutée au groupe de sécurité mon_pare-feu(argument en dernière position).

On peut associer plusieurs groupes de sécurité à une même instance. Dans ce cas les autorisations secumulent.

Les groupes de sécurité peuvent être associés dynamiquement aux instances en cours d'exécution et lesrègles peuvent être modifiées « à la volée ». Tout changement est pris en compte instantanément.

Précisons pour terminer qu'à chaque projet est attribué un groupe de sécurité par défaut. Cependant, les règles de cegroupe sont particulièrement restreintes et ne permettent pas, par exemple, de joindre les instances par SSH ou testerleur connectivité par ICMP.

4.6.11.2 Règles par défautDans l'ancienne version de la brique réseau d'OpenStack, Nova-network, il était possible de modifier les règles desgroupes de sécurité qui s'appliquent aux nouveaux utilisateurs. Avec Neutron, ce n'est malheureusement plus le cas.Qu'à cela ne tienne ! Allons explorer son code pour trouver une solution à ce problème.

Après plusieurs heures de recherches et quelques cheveux blancs de plus, j'ai fini par trouver le fichier concerné. Ils'agit de /usr/lib/python2.7/dist-packages/neutron/db/securitygroups_db.py. Comme son nom le suggère, il contient lesmodèles de données utilisés par Neutron pour enregistrer les règles de filtrage, notamment, dans sa base de données.Dans ce fichier, un bloc indique les règles qui seront utilisées pour créer le groupe de sécurité par défaut s'il estabsent :

if s.get('name') == 'default':

# Allow intercommunication

ingress_rule = SecurityGroupRule(

id=uuidutils.generate_uuid(), tenant_id=tenant_id,

security_group=security_group_db,

direction='ingress',

ethertype=ethertype,

source_group=security_group_db)

context.session.add(ingress_rule)

Xavier Buche Cloud universitaire avec OpenStack – CNAM Nord-Pas de Calais 98

Cette règle permet la communication sans restriction entre les instances qui appartiennent au même groupe desécurité. J'ajoute les règles suivantes pour accepter les requêtes ICMP (ping) et les connexions SSH en entrée :

ingress_rule_ssh = SecurityGroupRule(

id=uuidutils.generate_uuid(), tenant_id=tenant_id,

security_group=security_group_db,

direction='ingress',

protocol='tcp',

ethertype=ethertype,

remote_ip_prefix='0.0.0.0/0',

port_range_min='22',

port_range_max='22')

context.session.add(ingress_rule_ssh)

ingress_rule_icmp = SecurityGroupRule(

id=uuidutils.generate_uuid(), tenant_id=tenant_id,

security_group=security_group_db,

direction='ingress',

protocol='icmp',

ethertype=ethertype,

remote_ip_prefix='0.0.0.0/0')

context.session.add(ingress_rule_icmp)

Pour terminer je redémarre le service Neutron pour qu'il prenne en compte les modifications du code :service neutron-server restart

4.6.12 Le serveur de métadonnéesGénéralement, lors de la création d'une instance, son système d'exploitation doit connaître certaines informations surla machine virtuelle, comme son nom, la taille du disque système, etc. L'utilisateur peut également vouloir lancerautomatiquement un script cloud-init, par exemple, comme nous l'avons vu dans le chapitre 4.5.6.8 sur l'adaptationdes images, page 70.Pour que ces métadonnées lui soit accessible, l'instance doit se connecter à un serveur HTTP situé sur le contrôleur.Mais le chemin pour y parvenir est quelque peu tortueux…

L'URL utilisée par l'instance commence par http://169.254.169.254/. Sur l'espace de nom correspondant au réseau del'instance, une règle iptables indique que toute requête sur le port TCP 80 et à destination de l'adresse 169.254.169.254doit être redirigée vers le port TCP 9697, où le proxy de méta-données (neutron-ns-metadata-proxy) est à l'écoute.

Exemple :ip netns exec qrouter-efef4586-cc19-4e54-800e-6d655c432167 iptables -S -t nat | grep 169.254.169.254

-A neutron-l3-agent-PREROUTING -d 169.254.169.254/32 -p tcp -m tcp --dport 80 -j REDIRECT --to-ports 9697

ip netns exec qrouter-efef4586-cc19-4e54-800e-6d655c432167 netstat -anpe

Active Internet connections (servers and established)

Proto Recv-Q Send-Q Local Address Foreign Address State User Inode PID/Program name

tcp 0 0 0.0.0.0:9697 0.0.0.0:* LISTEN 0 25495414 3596/python

Le proxy relaye la requête à l'agent de méta-données (neutron-metadata-agent), via la socket unix/var/lib/neutron/metadata_proxy.

Xavier Buche Cloud universitaire avec OpenStack – CNAM Nord-Pas de Calais 99

Pour que l'agent réponde, l'entête HTTP de la requête doit contenir un champ x-instance-id-signature ayant unevaleur calculée sur la base de l'identifiant de l'instance et d'un secret partagé. Ainsi, chaque instance ne peut accéderqu'à ses propres méta-données.

4.6.13 Redirection vers le proxy web

4.6.13.1 PréambuleDans le chapitre 4.5.6.8 sur l'adaptation des images, page 70, nous avons pu voir qu'il était nécessaire de passer par unmandataire79 pour se connecter à Internet depuis une instance de machine virtuelle. En effet, le réseau du campusutilisé habituellement par les machines virtuelles est un réseau privé. Il ne peut donc pas être routé sur Internet.

La solution retenue par le CRI pour communiquer vers Internet depuis ce réseau est celle du proxy-cache. Desserveurs sont « mandatés » pour effectuer les requêtes en lieu et place des clients. Ces serveurs, appelés proxy-cache,retiennent les réponses aux requêtes et peuvent ainsi y répondre plus rapidement lors d'une éventuelle prochainedemande similaire. Les protocoles HTTP et HTTPS sont supportés, entre autres.

Avantages :– une sécurité maximale, car le réseau n'est pas accessible depuis Internet– des possibilités avancées de filtrage et de journalisation des communications

Inconvénients :– chaque application cliente qui accède à Internet doit connaître l'adresse d'un proxy, ce dont la configuration

est souvent laborieuse– seuls quelques protocoles sont supportés

Les serveurs proxy sont largement et depuis longtemps utilisés sur le campus de l'université. L'expérience a montréque le problème de leur configuration sur les postes clients est prégnant. Toutes les applications qui doivent accéder àl'extérieur du campus, comme les navigateurs web, mais aussi les environnement de développement, les cadriciels,etc., doivent donc être configurées pour avoir connaissance de l'adresse de ce mandataire. On peut comprendre quecette manipulation devienne rapidement rébarbative et source de problèmes pour les utilisateurs. Il faut leur faciliterla tâche.

La solution typique à ce problème se résume en un mot : transparence, qui signifie que l'utilisateur communique avecInternet sans savoir qu'il passe par un proxy. Les paquets à destination des ports TCP 80 (HTTP) et 443 (HTTPS) sontredirigés vers le mandataire par le routeur du campus.

Cette possibilité semble parfaite. Mais « semble » seulement. Car il y a un hic !Les données transmises en HTTPS sont chiffrées. Le proxy ne peut donc pas connaître l'adresse de destination despaquets, puisqu'elle a été modifiée par le routeur lors de la redirection. Cependant, un protocole, WCCP80, devraitpermettre de transmettre les paquets IP du routeur vers le proxy sans en modifier l'entête, en passant par un tunnelGRE.

En attendant que cette solution ait été testée et mise en œuvre par l'équipe réseau du CRI, j'ai choisi unpis-aller tout à fait fonctionnel.

Le principe est de rediriger les paquets vers le proxy, tout en lui fournissant l'adresse de destination finaledes paquets. Autrement dit, faire l'équivalent de ce que fait WCCP, mais au niveau du contrôleur OpenStack. Pourcela, j'y ai installé un programme, nommé redsocks, qui tire parti d'une singularité du protocole HTTP. Détaillons-là,pour commencer, lorsqu'elle est utilisée de manière conventionnelle, lors des connexions HTTPS « proxyfiées ».

Actuellement le proxy n'est pas en mode transparent. Lorsqu'on se connecte, par exemple, sur le site web d'OpenStacken HTTPS, le navigateur établit une sorte de tunnel avec le proxy en utilisant la méthode connect. Il commence parenvoyer un message HTTP avec l'entête suivante :

CONNECT www.OpenStack.org:443 HTTP/1.1

79 appelé également "proxy"80 Web Cache Communication Protocol

Xavier Buche Cloud universitaire avec OpenStack – CNAM Nord-Pas de Calais 100

Le proxy lui répond par le message :HTTP/1.0 200 Connection established

Ensuite, la communication chiffrée par le protocole TLS passe par ce « tunnel » HTTP.

Redsocks modifie tous les paquets qu'il réceptionne pour les faire passer dans ce type de tunnel. En argument de laméthode connect, il place l'adresse IP de destination des paquets, qu'il remplace par l'adresse IP du proxy. Ainsi, grâceà la méthode connect, le proxy connaît la destination des paquets qu'il reçoit. Et plus besoin de configurer lesapplications clientes : le proxy devient transparent du point de vue des utilisateurs, même s'il ne l'est pas réellement.

4.6.13.2 ConfigurationLa première étape consiste à rediriger les paquets destinés à Internet vers le processus redsocks. Le programme quiréalise cette redirection doit être compatible avec redsocks, car il a besoin de récupérer l'adresse de destination avantqu'elle n'ait été modifiée. C'est le cas de netfilter, le pare-feu de Linux.

Appliquons les redirections sur le routeur d'accès au réseau privé.

Je crée une nouvelle chaîne :ip netns exec qrouter-efef4586-cc19-4e54-800e-6d655c432167 iptables -t nat -N REDSOCKS

Les réseaux locaux et autres adresses spéciales ne sont pas concernées. Toutes les autres connexions TCP sontredirigées vers redsocks :

ip netns exec qrouter-efef4586-cc19-4e54-800e-6d655c432167 iptables -t nat -A REDSOCKS -d 127.0.0.0/8,10.0.0.0/8,172.16.0.0/12,192.168.0.0/16,0.0.0.0/8, 169.254.0.0/16,224.0.0.0/4,240.0.0.0/4,134.206.0.0/16,193.49.225.0/24 -j RETURN

Les connexions au port TCP 443 sont redirigées sur le port local 12345 :ip netns exec qrouter-efef4586-cc19-4e54-800e-6d655c432167 iptables -t nat -A REDSOCKS -p tcp --dport 443 -j REDIRECT --to-ports 12345

Les connexions vers les autres port TCP, dont le port 80, sont redirigées vers le port local 1234 :ip netns exec qrouter-efef4586-cc19-4e54-800e-6d655c432167 iptables -t nat -A REDSOCKS -p tcp -j REDIRECT --to-ports 1234

Tous les paquets TCP sont envoyés dans la chaîne REDSOCKS avant d'être éventuellement routés :ip netns exec qrouter-efef4586-cc19-4e54-800e-6d655c432167 iptables -t nat -A PREROUTING --in-interface qr-9fdf4419-ca -p tcp -j REDSOCKS

La prise en charge des connexions HTTP et HTTPS est configurées dans des sections séparées du fichier/etc/redsocks.conf.

redsocks {

# connexions HTTP

type = http-relay;

# adresse de l'interface du routeur sur laquelle les paquets arrivent

local_ip = 10.10.0.1;

# port d'écoute du démon redsocks

local_port = 1234;

# adresse et port du proxy

ip = 193.49.225.10;

port = 3128;

}

redsocks {

# connexions HTTPS

type = http-connect;

# adresse de l'interface du routeur sur laquelle les paquets arrivent

local_ip = 10.10.0.1;

# port d'écoute du démon redsocks

Xavier Buche Cloud universitaire avec OpenStack – CNAM Nord-Pas de Calais 101

local_port = 12345;

# adresse et port du proxy

ip = 193.49.225.10;

port = 3128;

}

Pour terminer je lance le processus redsocks dans l'espace de noms du routeur :ip netns exec qrouter-efef4586-cc19-4e54-800e-6d655c432167 /usr/sbin/redsocks -c /etc/redsocks.conf

Exemple de connexion HTTP redirigée par redsocks :CONNECT 74.82.3.171 HTTP/1.0

Exemple de connexion HTTPS redirigée par redsocks :CONNECT 173.194.40.191:443 HTTP/1.0

Ce procédé entraîne cependant plusieurs inconvénients :– Il faut le répéter sur chaque routeur virtuel, et, au-delà de la plate-forme OpenStack, on ne peut pas

facilement l'étendre à un grand nombre d'utilisateurs.– Redsocks ne permet de configurer l'adresse que d'un seul des trois proxies web de l'université. S'il tombe en

panne, les autres ne pourront pas le remplacer automatiquement.

En théorie, WCCP est la réponse à ces problèmes. En attendant son éventuelle mise en place, les utilisateursd'OpenStack n'ont plus à se soucier des mandataires. Merci redsocks !

4.7 Horizon et l'interface webOn peut s'attendre à ce qu'une bonne partie des utilisateurs d'OpenStack ne se contente pas de quelques puissantsmais frustres clients en ligne de commande pour gérer leurs infrastructures « infonuagiques ». Et encore moins deforger eux-mêmes des messages HTTP en JSON. La plupart, au contraire, choisirons la manière la plus ergonomique,qui repose sur une interface graphique accessible par le web.

Cette interface, OpenStack la fournie. Elle est souvent nommée panneau de contrôle et elle se fonde sur un cadricielappelé Horizon.

4.7.1 Choix de l'interfaceNous avons ainsi trois possibilités non exclusives.

Xavier Buche Cloud universitaire avec OpenStack – CNAM Nord-Pas de Calais 102

Tableau 1 : choix d'une interface web

avantages inconvénients

utiliser le panneau de contrôle d'OpenStack

l'interface est déjà toute faite - l'interface a quelques lacunes. Exemple : on ne peut pas partager une image avec certains utilisateurs

- si on modifie l'interface pour l'adapter aux besoins, alors tous les changement sont systématiquement supprimés à chaque mise à jour logicielle

développer notre propre panneau de contrôle en nous basant sur le cadriciel Horizon

plus rapide et avec probablement un meilleur résultat qu'un développement en partant de zéro

- nécessite un développement et un suivi conséquents

- dépendance vis-à-vis du cadriciel

développer notre propre panneau de contrôle sans le cadriciel Horizon

flexibilité développement très important si l'on veut aboutir à un résultat proche de celui du panneau de contrôle d'OpenStack

Pour l'instant, nous avons choisi l'option la plus simple : utiliser la solution fournie par OpenStack, et lamodifier légèrement, ce qui oblige à réitérer l'opération à chaque mise à jour, soit tous les deux ou troismois.

En annexe, page123, vous trouverez la liste des modifications apportées et comment elles ont été faites.

Cette interface, même si elle est moderne et ergonomique, ne dispose pas de toutes les possibilitésqu'offrent les API d'OpenStack. Par exemple, elle ne permet pas de partager une image avec desutilisateurs particuliers, ni de connecter une machine virtuelle à plusieurs réseaux. Elle mérite doncquelques améliorations que nous envisageons de réaliser par la suite.

A l'inverse, cette interface fournit des possibilités qui vont bien au-delà des besoins d'une grande partie desutilisateurs, comme celles relatives aux réseaux virtuels. Par conséquent, nous prévoyons de développer une interfacesimplifiée à l'extrême et intégrée au portail de l'université, pour satisfaire les besoins les plus basiques (créer unemachine virtuelle, l'arrêter, la redémarrer, la supprimer, etc.).

4.7.2 Sécurisation de l'accèsMême si la plate-forme OpenStack n'est pas accessible de l'extérieur du campus, sauf via un VPN81, il est de bon ton desécuriser les connexions à l'interface web par HTTPS. En d'autres termes, paramétrer le serveur web de manière à cequ'un tunnel TLS82 soit établi avant tout échange de données HTTP avec le client.

Passons aux actes en commençant par activer le module SSL83 d'apache et le fichier de configuration par défaut :a2enmod ssl

a2ensite default-ssl

81 Virtual Private Network82 Transport Layer Security est un protocole qui permet d'établir un tunnel sécurisé entre un client et un serveur pour garantir leur identité et

assurer la confidentialité et l'intégrité des données transmises83 dans ce contexte, SSL est synonyme de TLS

Xavier Buche Cloud universitaire avec OpenStack – CNAM Nord-Pas de Calais 103

Pour remplir son office, ce module a besoin qu'on lui fournisse trois fichiers contenant la clef privée du serveur web,son certificat et le certificat de l'autorité qui a certifié sa validité. Il tombe sous le sens que la clef privée doitimpérativement être localisé en lieu sûr, c'est-à-dire dans un fichier que seul le processus httpd d'Apache peut lire.

Je crée donc un répertoire où seront localisés les fichiers :mkdir /etc/apache2/ssl

Je copie le certificat de l'autorité de certification :cp ca.pem /etc/apache2/ssh

le certificat du serveur :cp OpenStack.pem /etc/apache2/ssh

et la clef secrète :cp OpenStack.key /etc/apache2/ssh

Le propriétaire est le serveur web :chown www-data.www-data /etc/apache2/ssl/*

Seul le serveur web peut accéder à ces fichiers, et uniquement en lecturechmod 400 /etc/apache2/ssl/*

Et pour terminer, je modifie le fichier de configuration d'Apache qui concerne les connexions au port TCP 443, enajoutant dans /etc/apache2/sites-enabled/default-ssl.conf :

SSLEngine On

SSLProtocol +TLSv1 +TLSv1.1 +TLSv1.2

SSLCipherSuite HIGH:!RC4:!MD5:!aNULL:!eNULL:!EXP:!LOW:!MEDIUM

SSLCACertificateFile /etc/apache2/ssl/ca.pem

SSLCertificateFile /etc/apache2/ssl/OpenStack.pem

SSLCertificateKeyFile /etc/apache2/ssl/OpenStack.key

Sans oublier de rediriger les connexions non sécurisées, faites sur le port TCP 80, vers le port 443, en ajoutant dans/etc/apache2/sites-enabled/000-default.conf :

RedirectPermanent / https://cloud.univ-lille1.fr/

4.7.3 Test de chargeBon nombre de logiciels permettent d'évaluer la capacité d'un serveur web à répondre à des sollicitations qui simulentle parcours d'un site web par une quantité définie d'utilisateurs.Jmeter est sans aucun doute le plus connu. Il est de surcroît puissant et gratuit.

Il offre tant de possibilités que son utilisation, même basique, n'est pas d'une évidence élémentaire. Tout au contraire.Je suis tout de même parvenu à « dompter l'animal » pour examiner comment réagit notre serveur selon différentsniveaux de charge.

Les résultats sont en annexe, page 125.

On peut constater qu'à partir de 50 threads84, des erreurs apparaissent, et le temps de réponse moyen dépasse souventla seconde. Mais 50 threads ne correspond pas à 50 utilisateurs, loin de là. En effet, chaque thread exécute 10 fois unscénario pré-configuré correspondant à une série de requêtes émises à la cadence d'une cinquantaine par seconde.

Pourtant, la taux d'utilisation des processeurs ne dépasse pas les 50 % et le load average, qui indique le degré decharge du processeur, est de 4 alors que la machine dispose de 8 processeurs. De plus, la bande passante réseauutilisée se limité à 110 Ko/s.

Ce problème ne provient apparemment pas du serveur, mais plutôt du côté client. En effet, la documentation deJmeter stipule qu'au delà d'une certaine charge, il est nécessaire de disperser les requêtes en utilisant des agentsrépartis sur un ensemble de machines, ce qui est réputé nettement plus complexe à mettre en place.

Toujours est-il que notre petit benchmark révèle que, même soumis à une charge de travail conséquente et continue,notre serveur a encore une bonne réserve de puissance.

84 tâches qui s'exécutent en parallèle

Xavier Buche Cloud universitaire avec OpenStack – CNAM Nord-Pas de Calais 104

4.8 QuotasIl est évident que des milliers d'utilisateurs ne peuvent pas se partager des ressources sans que des limites ne leurssoient imposées. Un des éléments primordiaux d'un logiciel de cloud computing est donc la gestion de quotasd'utilisation des ressources.

Avec OpenStack, les quotas des images, des instances et des réseaux ne sont pas administrés de manière identique.

4.8.1 GlanceAvec Glance, la gestion des quotas est incroyablement limitée. Quelques directives permettent de fixer deslimites générales, qui s'appliquent à l'ensemble des utilisateurs, quels qu'il soient. Impossible doncd'affecter des limites à un utilisateur ou un groupe d'utilisateurs individuellement.

Par exemple, le paramètre user_storage_quota, configuré dans la section [default] du fichier/etc/glance/glance-api.conf, permet d'indiquer l'espace de stockage maximal accordé à chaque utilisateur pour sesimages. Pour le moment, je l'ai fixé à 50 Go. Mais j'aurais préféré allouer plus de place aux enseignants-chercheurs, etmoins pour les étudiants.

Néanmoins, et comme pour beaucoup d'autres limitations d'OpenStack, il semble que les développeurstravaillent à corriger ces lacunes. Ils projettent en effet de réunir dans un même code l'administration desquotas des différents composants (nova, neutron, glance, etc.).

4.8.2 NovaHeureusement, Nova gère les quotas beaucoup plus finement que Glance. Voyons cela de plus près.

Tout d'abord on peut commencer par modifier le quota par défaut, qui s'applique à l'ensemble des projets, pourl'utilisation d'une série de ressources.

Par exemple, on peut définir que, sauf indication contraire, un utilisateur pourra créer au maximumquatre instances dans un projet :

nova quota-class-update --instances 4 default

Après avoir utilisé cette commande avec les autres ressources, voici les quotas par défaut que j'ai configurés :nova quota-defaults

+-----------------------------+-------+

| Quota | Limit |

+-----------------------------+-------+

| instances | 4 |

| cores | 4 |

| ram | 8192 |

| floating_ips | 4 |

| fixed_ips | -1 |

| metadata_items | 128 |

| injected_files | 5 |

| injected_file_content_bytes | 10240 |

| injected_file_path_bytes | 255 |

| key_pairs | 4 |

| security_groups | 10 |

| security_group_rules | 20 |

+-----------------------------+-------+

Xavier Buche Cloud universitaire avec OpenStack – CNAM Nord-Pas de Calais 105

Une valeur négative signifie « sans limite ».

Ensuite, on peut définir des quotas particuliers pour certains projets :nova quota-update --instances 8 projet_test

nova quota-show --tenant projet_test

+-----------------------------+-------+

| Quota | Limit |

+-----------------------------+-------+

| instances | 8 |

...

On peut ainsi envisager de définir des quotas différents pour le personnel de l'université et les étudiants, par exemple.Ou alors augmenter les quotas du chef, car il est très aimable !

La commande suivante est l'inverse de la précédente. Elle permet de supprimer les quotas particuliers d'un projet oud'un couple utilisateur-projet pour qu'ils reprennent les valeurs par défaut.

nova quota-delete --tenant projet_test

Enfin on peut fixer un quota pour un utilisateur dans un projet :nova quota-update --user buche --instances 10 projet_test

ERROR: Quota limit must be less than 6. (HTTP 400)

Évidemment le quota de l'utilisateur ne peut pas excéder celui du projet.nova quota-update --user buche --instances 2 projet_test

nova quota-show --user buche --tenant projet_test

+-----------------------------+-------+

| Quota | Limit |

+-----------------------------+-------+

| instances | 2 |

...

On pourrait donc faire en sorte que, dans un projet partagé entre plusieurs membres, les utilisateurs ne puissent passaturer le quota du projet au détriment des autres.Cependant, dans ce cas, l'affichage des quotas dans la vue d'ensemble du panneau de contrôle horizon indique lequota du projet, et non le quota de l'utilisateur sur ce projet. L'utilisateur qui utilise l'interface web ne connaît doncpas son quota réel.

La commande suivante permet d'afficher la quantité actuelle de ressources consommées par un projet ou un coupleutilisateur-projet. Focalisons-nous sur le nombre d'instances :

nova absolute-limits --tenant projet_test

+-------------------------+-------+

| Name | Value |

+-------------------------+-------+

| totalInstancesUsed | 3 |

...

Suite à mes diverses manipulations, j'ai identifié un dysfonctionnement : lors de la suppression d'unquota, l'usage actuel des ressources est remis à zéro.

nova quota-delete --tenant projet_test

nova absolute-limits --tenant projet_test

Xavier Buche Cloud universitaire avec OpenStack – CNAM Nord-Pas de Calais 106

+-------------------------+-------+

| Name | Value |

+-------------------------+-------+

| totalInstancesUsed | 0 |

...

L'usage reprendra sa valeur normale, dans cet exemple, lorsque qu'un utilisateur supprimera ou créera une instancedans ce projet.

4.8.3 NeutronLa configuration des quotas avec Neutron est un mélange entre celle de Glance et celle de Nova : les valeurs desquotas par défaut sont fixées dans la section quotas du fichier de configuration de Neutron (/etc/neutron/neutron.conf),tandis que les quotas propres à certains projets sont définis par la commande neutron quota-update, dont lesarguments ressemblent fortement à ceux de la commande nova quota-update.Il n'est cependant pas possible, avec Neutron, d'appliquer des quotas à des couples utilisateur-projet.

Pour terminer précisons que seuls les utilisateurs ayant le rôle admin peuvent modifier les quotas.

4.9 Ceilometer et la facturationLe projet Ceilometer est le module d'OpenStack qui fournit la fonction telemetry.Ceilometer assure uniquement l'étape de mesure des ressources consommées par les utilisateurs. Il collecte desinformations sur le système et les stocke sous forme d'échantillons ou d'événements. Ces informations, appeléesmétriques, peuvent ensuite être traitées par des outils d'analyse ou de facturation.

Un blueprint en cours de traitement propose d'ajouter le calcul de la facturation à Ceilometer [Facturationavec Ceilometer].

Ceilometer collecte les données de trois façons différentes :– traiter les notifications envoyées par les autres composants d'OpenStack sur le bus de messagerie AMQP

(service ceilometer-agent-notification)– sonder les hyperviseurs (ceilometer-agent-compute), les machines hôtes (ceilometer-agent-ipmi) et les autres

composants d'OpenStack via leurs API (ceilometer-agent-central)– recevoir les informations sur l'API de Ceilometer (ceilometer-api)

Les services de Ceilometer :– ceilometer-api : permet d'accéder aux données collectées– ceilometer-agent-central : sonde les autres composants d'OpenStack, par l'intermédiaire de leurs API, ainsi

que les machines hôtes via SNMP– ceilometer-agent-compute : sonde l'hyperviseur local pour en obtenir des échantillons de données– ceilometer-agent-notification : récupère les messages AMQP envoyés par les autres composants d'OpenStack

sur le bus de messagerie– ceilometer-agent-ipmi : sonde les nœuds de calcul en utilisant IPMI (Intelligent Platform Management

Interface), une interface qui permet d'obtenir des informations sur le matériel (ventilateurs, température, etc.)– ceilometer-collector : récupère les notifications envoyées par les agents Ceilometer sur le bus de messagerie

AMQP, puis les stocke dans la base de données– ceilometer-alarm-evaluator : déclenche une alarme si certaines valeurs dépassent certains seuils pendant une

certaine durée– ceilometer-alarm-notifier : lance une action suite à une alarme

Ceilometer collecte notamment des données sur les machines virtuelles. Il est donc en relation étroite avec leshyperviseurs, avec un degré de compatibilité variable (les données qu'il est possible de collecter ne sont pas forcémentles mêmes entre les différents hyperviseurs).

Xavier Buche Cloud universitaire avec OpenStack – CNAM Nord-Pas de Calais 107

La procédure de configuration de Ceilometer est triviale et son principe ne diffère aucunement des autres briquesd'OpenStack (création d'une base de données, de tables, d'un compte Keystone, connexion au bus de messagerie, etc.).Je vous en épargnerai donc les détails, qui n'apporterait rien de plus à cet exposé, sauf quelques lignes absconses etsans intérêt.

L'essentiel réside plutôt dans la traduction des données recueillies par Ceilometer en statistiques, et dans le calcul decoûts liés aux utilisateurs. A l'heure actuelle, nous n'avons pas développé cet aspect qui sort du cadre des possibilités d'OpenStack. Néanmoinsnous avons configuré Ceilometer pour qu'il récupère régulièrement des données suffisantes pour une exploitationultérieure (temps processeur, mémoire, espace disque, etc.).

Ceilometer permet tout de même d'effectuer des requêtes pour récupérer des échantillons. Exemple :ceilometer sample-list -m cpu_util -q 'resource_id=25717249-1fad-4810-ba66-bf7f82391714;timestamp>2015-01-24T09:08;timestamp<=2015-01-24T10:08'

+--------------------------------------+----------+-------+-----------------+------+---------------------+

| Resource ID | Name | Type | Volume | Unit | Timestamp |

+--------------------------------------+----------+-------+-----------------+------+---------------------+

| 25717249-1fad-4810-ba66-bf7f82391714 | cpu_util | gauge | 0.145 | % | 2015-01-24T10:01:13 |

| 25717249-1fad-4810-ba66-bf7f82391714 | cpu_util | gauge | 0.0316139767055 | % | 2015-01-24T09:51:13 |

| 25717249-1fad-4810-ba66-bf7f82391714 | cpu_util | gauge | 0.0416666666667 | % | 2015-01-24T09:41:12 |

| 25717249-1fad-4810-ba66-bf7f82391714 | cpu_util | gauge | 0.0383333333333 | % | 2015-01-24T09:31:12 |

| 25717249-1fad-4810-ba66-bf7f82391714 | cpu_util | gauge | 0.0433333333333 | % | 2015-01-24T09:21:12 |

| 25717249-1fad-4810-ba66-bf7f82391714 | cpu_util | gauge | 0.045 | % | 2015-01-24T09:11:12 |

+--------------------------------------+----------+-------+-----------------+------+---------------------+

Et il permet même d'obtenir des résultats agrégés. Exemple :ceilometer statistics -m cpu_util -q 'resource_id=25717249-1fad-4810-ba66-bf7f82391714;timestamp>2015-01-24T09:08;timestamp<=2015-01-24T10:08'

+-------+-----------------+-------+----------------+-----------------+----------+---------------------+---------------------+

| Count | Min | Max | Sum | Avg | Duration | Duration Start | Duration End |

+-------+-----------------+-------+----------------+-----------------+----------+---------------------+---------------------+

| 6 | 0.0316139767055 | 0.145 | 0.344947310039 | 0.0574912183398 | 3001.0 | 2015-10-24T09:11:12 | 2015-01-24T10:01:13 |

+-------+-----------------+-------+----------------+-----------------+----------+---------------------+---------------------+

Dans l'objectif de libérer automatiquement des ressources consommées inutilement, nous réfléchissons àla mise en place d'un dispositif pour détecter et désactiver les machines virtuelles inutilisées, après envoide messages de confirmation aux utilisateurs.

4.10 SupervisionCeilometer fournit un grand nombre d'informations sur la consommation de ressources par les utilisateurs. Mais unadministrateur systèmes a besoin de données plus générales sur le taux d'utilisation des différents éléments physiquesde l'infrastructure, comme le pourcentage d'occupation de la baie de stockage, la quantité de mémoire libre sur lescontrôleurs et sur les nœuds de calcul, le taux d'encombrement des liaisons réseaux, etc.

Un nombre étonnant de logiciels propose ce genre de fonction. On peut les séparer en deux types :– ceux qui détectent les défaillances et génèrent des alarmes– ceux qui affichent, sous forme de graphes, l'évolution de certaines métriques avec le temps, ce que l'on

nomme parfois métrologie

De plus en plus de produits assurent ces deux fonctions à la fois.

Xavier Buche Cloud universitaire avec OpenStack – CNAM Nord-Pas de Calais 108

Faire un choix au milieu de cette quantité foisonnante de solutions n'est pas simple, si bien que je me suiscontenté d'opter pour les seuls logiciels que je connais et qui s'avèrent être parmi les plus populaires :Nagios pour la remontée d'alertes et Cacti pour la métrologie.

Je ne m'étendrai pas davantage sur leur paramétrage qui pourrait probablement, à lui seul, faire l'objet d'un autremémoire.

4.11 Plan catastropheÊtre alerté dès qu'un problème survient est un gros avantage, car cela fournit un temps précieux pour réagir et lerésoudre, parfois même sans que l'utilisateur ne s'en rende compte.Cependant, si le problème en question pose trop de difficultés pour être corrigé en un temps restreint (quelquesheures grand maximum), il faut un plan de secours. Ce plan repose sur la redondance.

Cette redondance est déjà assurée au niveau du stockage : la baie de disque dispose de deux contrôleurs (à ne pasconfondre avec les contrôleurs OpenStack). Si le contrôleur utilisé habituellement n'est plus fonctionnel pour unequelconque raison, le contrôleur secondaire le détecte et prend le relais.

Quant aux nœuds de calcul, ils sont interchangeables. Nous avons vu dans le chapitre 4.5.6.5 sur Nova, page 68, qu'ilétait possible d'« évacuer » un hôte injoignable, c'est-à-dire de transférer sur un autre nœud toutes les instances qui yétaient exécutées.

Enfin, même si les commutateurs installés sont réputés très fiables et que celui de la plate-formeOpenStack dispose d'une alimentation redondante, il est prévu de les doubler et de généraliserl'agrégation de liens, pour l'instant utilisée uniquement sur la liaison externe (voir le chapitre 4.6.8 surNeutron, page 94).

Le dernier maillon de la chaîne qui permet d'obtenir une redondance complète est le contrôleur. Et c'est sans aucundoute le plus complexe à mettre en place. L'idée est tout à fait classique : une deuxième machine, copie conforme de lapremière, doit en prendre le relais en cas de problème. J'ai volontairement assez peu parlé du contrôleur secondairejusqu'à présent, pour ne pas compliquer inutilement les explications.

Des solutions logicielles et matérielles existent pour réaliser une reprise sur panne automatique et presqueinstantanée. Leur mise en œuvre n'est généralement pas triviale pour assurer la redondance d'un service simple,comme un serveur web. Or, en lisant ce mémoire, vous avez peut-être remarqué que ce qui tourne sur le contrôleurn'est pas tout à fait ce qu'on pourrait qualifier de « simple ». On peut donc sans mal imaginer la complexité deconfigurer une redondance automatique des nombreux services exécutés sur le contrôleur.

Le problème de l'automatisation de la redondance est qu'elle requiert une certaine « intelligence » dans la détectiondes problèmes et les actions entreprises pour y répondre. Ce qui implique une surcouche logicielle et ajoute un degréde complexité à l'ensemble. Cette complexité, si elle n'est pas parfaitement maîtrisée, risque elle-même de devenir unesource de problèmes inextricables.

De ce fait, et au moins dans les premiers temps de la mise en production de la plate-forme OpenStack,nous avons opté pour une solution plus simple et plus pragmatique : réaliser une copie manuelle desdonnées statiques du contrôleur 1 vers le contrôleur 2. Les données qui évoluent régulièrement sont soitdans les bases de données, qui sont, je le rappelle, répliquées en temps réel entre les deux contrôleurs etun nœud de calcul grâce au cluster Galera (voir le chapitre 4.2.2.2 sur le SGBD, page 30), soit sur la baie destockage (images).

Avec cette méthode, la seule partie délicate est la configuration réseau. En temps normal, la plupart des interfaces ducontrôleur 2, qui ont la même configuration que le contrôleur 1, doivent être désactivées, hormis les interfacesd'administration (SSH et iDRAC). En cas de dysfonctionnement du contrôleur 1, il suffit de désactiver ses interfacesréseaux (si elles ne le sont pas déjà) et d'activer les interfaces du contrôleur 2 pour qu'il prenne sa place.

Précisons pour terminer que les pannes matérielles sur ce type de serveur sont très rares, et que quand ellessurviennent, elles affectent généralement des éléments redondants de l'ordinateur (disque dur, alimentationélectrique) qu'il suffit alors de changer sans impact sur son fonctionnement. Le contrôleur secondaire sera surtoututile pour pallier les défaillances logicielles du primaire, par exemple suite à une mise à jour système ou unchangement de configuration.

Xavier Buche Cloud universitaire avec OpenStack – CNAM Nord-Pas de Calais 109

Cette procédure paraît donc tout à fait acceptable. Le temps nous dira si elle est suffisante. Par la suite,néanmoins, nous n'excluons pas la possibilité de mettre en œuvre un système de haute disponibilitéautomatique, au moins partiellement, si cette solution se justifie.

Précisons enfin que le deuxième contrôleur sert également à exécuter les scripts de sauvegarde et les logiciels desupervision.

4.12 SauvegardesÉvidemment aucun administrateur systèmes ne peut décemment entreprendre la conception d'un service tel quel'objet de ce mémoire sans y intégrer la sauvegarde périodique des données des utilisateurs et des données systèmes.Même un matériel parfaitement fiable et résiliant ne peut pas recouvrer des données supprimées par inadvertance parun utilisateur ou un administrateur étourdi, ou altérées par un logiciel bogué.

De plus, même si la technologie du RAID85, employée sur la baie de disques, protège les données de la défaillance dessupports de stockage, elle ne peut rien contre un incendie, une inondation, un cambriolage. D'où la nécessitéimpérieuse d'une sauvegarde régulière de ces données.

4.12.1 Parer à l'erreur humainePour éviter la destruction de données provenant d'une négligence humaine, notre baie de disques dispose d'unefonction qui permet de réaliser fréquemment des clichés d'un volume. Les données de ces clichés sont accessiblesdans des répertoires cachés.

Par exemple, dans le répertoire racine du volume associé à OpenStack, un répertoire caché nommé .snapshots contientles clichés de ce volume pris à différents moments :– hourly.0 et hourly.1 : ces sous-répertoires contiennent des clichés du volume pris à heures régulières pendant

la journée– nightly.0 et nightly.1 : contiennent des clichés du volume tel qu'il était aujourd'hui et hier à minuit– weekly.0, weekly.1 et weekly.2 : contiennent les clichés de dimanche dernier à minuit, ainsi que des deux

dimanches précédents

L'avantage de ce mode de sauvegarde des données est multiple :– La restauration est très simple : elle revient typiquement à copier un fichier.– La sauvegarde est instantanée, par principe : suite à un cliché, les blocs de données sont en lecture seule, et la

modification d'un bloc se fera sur une copie. Par conséquent seuls les blocs modifiés après le cliché occupentde l'espace disque, ce qui revient à faire une sauvegarde différentielle en temps réel.

L'inconvénient : toutes les données sont situées sur le même volume. Or, même si le matériel est « ultra-redondant »(double alimentation électrique, double contrôleur, RAID6), il ne peut empêcher la survenue d'un désastre.

4.12.2 Parer à la catastropheMême s'il est impossible de prédire le volume des données qu'il sera nécessaire de sauvegarder, car par tropdépendant de l'usage que feront les utilisateurs de leur nouveau service, il est probable, étant donné le principe defonctionnement énoncé dans le chapitre sur Nova et basé sur la technique du Copy On Write, que l'espace de stockageconsommé reste tout à fait raisonnable.

De ce fait, plutôt que d'investir pécuniairement dans une solution de sauvegarde avec une estimationvraisemblablement erronée de son dimensionnement, nous choisissons de nous greffer au dispositif desauvegarde du CRI.

L'intérêt de cette option est que ce système est en place depuis des années. Il est donc éprouvé. De plus, la sauvegardeest réalisée sur un site distant du campus, avec des procédures de sécurité qui ne laissent rien au hasard.

85 Redundant Array of Inexpensive Disks

Xavier Buche Cloud universitaire avec OpenStack – CNAM Nord-Pas de Calais 110

Ce système de sauvegarde repose sur la sauvegarde des machines virtuelles du cluster Vmware du CRI. Le logiciel debackup réalise des sauvegardes incrémentales quotidiennes sur des dépôts locaux disposant d'un espace de stockagecapacitif86. La durée de rétention des données est de 40 jours. Il est donc possible, par exemple, de récupérer la versiond'un fichier qui date de 40 jours, même si, depuis, ce fichier a été modifié tous les jours. Deux autres dépôts de sauvegarde sont situés sur un site distant dont la localisation est tenue secrète. Chacuncontient un réplicat complet des sauvegardes du CRI, avec une durée de rétention des données de deux jours. Ils sontallumés ou éteints alternativement chaque semaine. Ce de fait, on dispose à tout moment d'une version hors ligne dela sauvegarde, qui se trouve physiquement protégée d'un éventuel accès frauduleux.

Pour la sauvegarde de données externes à la plate-forme VMWare, il faut donc copier les données à sauvegarder surune machine virtuelle VMware. Et c'est cette machine qui sera sauvegardée régulièrement.

A ce stade, la question est donc : comment copier efficacement les données d'OpenStack vers cette machine virtuelle ?

4.12.3 NDMPQuand un administrateur systèmes pense à la sauvegarde d'une baie de stockage, il pense à NDMP (Network DataManagement Protocol).

NDMP est un protocole ouvert et standard qui se fonde sur le triptyque suivant :– le serveur de données, généralement une baie de stockage– le serveur de sauvegardes, comme un robot de sauvegardes sur bandes– le logiciel de sauvegarde, qui envoie des commandes aux deux premiers pour contrôler les sauvegardes et les

restaurations

Avec NDMP, le flux de données transite directement du serveur de données au serveur de sauvegardes. Pas besoind'intermédiaire, et c'est là l'un des principaux avantages de ce protocole, qui est connu de la grande majorité des NAS,des systèmes et des logiciels de sauvegarde.

Cependant cet avantage est réduit à néant dans notre cas car, comme indiqué dans le chapitre précédent, lasauvegarde doit passer par une machine virtuelle pour se conformer aux pratiques du CRI.La solution serait donc d'employer notre propre application de sauvegarde pour synchroniser les données de la baiede stockage avec leur copie située sur la machine virtuelle VMware à sauvegarder.

Mais c'est sans compter les autres problèmes que pose le protocole…

4.12.3.1 NDMP et la sécurité des transfertsDans une architecture réseau telle que la nôtre, il est tout à fait acceptable, voire même préférable pour des raisons deperformance, de ne pas chiffrer les communications internes (accès à la baie de stockage, queues de messagerie etréseaux des machines virtuelles).Par contre, aucun réseau externe ne peut être considéré comme digne de confiance, et il faut donc s'assurer de lasécurisation des données qui y transitent :– confidentialité– intégrité des données– authentification de l’émetteur et du destinataire

Or NDMP est particulièrement limité dans ce domaine :– aucun chiffrement– deux modes pour l'authentification du client (l'application de sauvegarde) sur le serveur (baie de disques ou

système de sauvegardes) :– text : le client s'authentifie au serveur avec un couple login/mot de passe qui est transmis « en clair » sur

le réseau, laissant à un éventuel pirate tout loisir de l'intercepter et le réutiliser pour falsifier sonidentité.

– md5 : le mode d'authentification le plus sécurisé se base sur un protocole de type défi/réponse(challenge/response en anglais)

86 des disques durs lents, pas chers, mais dont la capacité de stockage est très grande

Xavier Buche Cloud universitaire avec OpenStack – CNAM Nord-Pas de Calais 111

Voyons comment fonctionne le type md5.

Le client envoie une demande d'authentification au serveur. En retour, le client reçoit un défi (une longue chaîne decaractères aléatoire), qu'il concatène avec le mot de passe avant de réaliser un condensat de l'ensemble avecl'algorithme MD5 et de renvoyer ce condensat au serveur avec le login. Le serveur réalise alors la même opération(condensat de la concaténation du défi envoyé au client et du mot de passe) et compare le résultat avec le condensatreçu de la part du client.La spécification du protocole NDMP ne dit rient de l'importance du caractère stochastique du défi. Ainsi denombreuses implémentations de ce protocole génèrent la chaîne de caractères de manière insuffisamment aléatoire, etcertains types d'attaque de piratage en tirent parti.Par ailleurs, si le défi est trop court, le protocole défi/réponse est alors sujet aux attaques de type rejeu. L'attaquantintercepte le défi et la réponse échangés entre un serveur et un client. Ensuite, il envoie au serveur des demandes dedéfi jusqu'à ce qu'il reçoive un défi identique à celui récupéré à l'étape précédente. Il n'a plus qu'à envoyer au serveurla réponse interceptée auparavant pour être authentifié.

4.12.3.2 Conclusion sur NDMPLe protocole NDMP a été conçu pour être utilisé sur un réseau intrinsèquement sécurisé, comme un SAN. Sonprincipal bénéfice, qui est la communication directe d'un NAS avec un système de sauvegarde, n'est pas exploitabledans un cas de figure comme le nôtre.Nous allons donc chercher un moyen de réaliser une sauvegarde qui soit à la fois sûre et adaptée aux circonstances.

4.12.4 rsyncPlutôt que d'utiliser une solution de sauvegarde pour transférer des données sur une machine qui sera elle-mêmesauvegardée, il est plus approprié de chercher à dupliquer et à synchroniser les données vers la machine qui serasauvegardée.

Pour ce genre de tâche, rsync est l'outil ad-hoc.

Selon la philosophie Unix, un programme doit faire une chose, mais la faire bien. Rsync en est un bon exemple. Ildispose d'une multitude d'options et d'algorithmes efficaces pour synchroniser des données d'une source vers unedestination.

Par défaut, Rsync utilise le protocole SSH87 pour le transfert des données, ce qui assure leur confidentialité, leurintégrité et l'authentification de l’émetteur et du destinataire. Comme la sauvegarde se fera périodiquement et qu'onne souhaite pas inscrire un mot de passe dans les commandes de synchronisation des données, on utilise une paire declefs asymétriques pour que le serveur OpenStack soit authentifié par le serveur de sauvegardes quand il s'y connecte.

En lançant la commande ssh-keygen sur le serveur OpenStack, une clef privée est écrite dans le fichier ~/.ssh/id_rsa etla clef publique correspondante est stockée dans le fichier ~/.ssh/id_rsa.pub. C'est cette dernière qu'il faut copier dansle fichier ~/.ssh/authorized_keys du serveur de sauvegardes.

Lorsqu'il souhaite s'authentifier auprès du serveur de sauvegardes, le serveur OpenStack lui envoie un HMAC ( Hash-based Message Authentication Code). Il s'agit d'une chaîne de caractères aléatoire, suivie par un condensat de cettechaîne chiffré avec la clé privée de l'émetteur.A réception de ce message, le serveur de sauvegardes déchiffre le condensat reçu avec la clé publique de l'émetteur etréalise le condensat de la chaîne de caractères. Si les deux résultats sont identiques, alors l'émetteur du message estbien celui qui a fourni la clé publique. Il est authentifié.

4.12.4.1 Données des utilisateursVoici les commandes que j'ai planifiées quotidiennement pour synchroniser les données à sauver de la plate-formeOpenStack vers la machine sauvegardée par le CRI :

rsync -avz --delete --log-file=/var/log/sauvegarde.log /mnt/backup/.snapshot/nightly.0/images login@11.11.11.11:/data

rsync -avz --delete --log-file=/var/log/sauvegarde.log --exclude '_base' --inplace /mnt/backup/.snapshot/nightly.0/instances login@11.11.11.11:/data

87 Utilisé généralement pour la connexion à la console d'une machine distante, en remplacement des antédiluviens rsh ou telnet, Secure SHell estsouvent utilisé comme tunnel sécurisé.

Xavier Buche Cloud universitaire avec OpenStack – CNAM Nord-Pas de Calais 112

rsync -avz --delete --log-file=/var/log/sauvegarde.log --sparse /mnt/backup/.snapshot/nightly.0/instances/_base login@11.11.11.11:/data/instances

Ces trois commandes sont lancées simultanément pour deux raisons :– l'option -z compresse les données pour économiser la bande passante réseau, mais ceci consomme beaucoup

de cycles processeurs. Pour éviter que le processeur soit saturé et devienne un goulet d'étranglement, onparallélise le travail.

– comme vous pouvez le constater, les paramètres ne sont pas exactement les mêmes et sont adaptés aux typesde fichiers à synchroniser

Attardons-nous sur les options qui sortent de l'ordinaire.

Le répertoire instances/_base contient le tronc commun utilisé par les machines virtuelles (voir le chapitre 4.5.6 surNova, page 61). Ces copies d'images utilisent une particularité de Linux qui permet de pré-allouer un espace disque àun fichier. Si on ne le précise pas à l'application qui l'utilise, le fichier peut lui sembler très grand, même s'il necontient presque aucune donnée.De ce fait, il faut indiquer à rsync que les fichiers situés dans ce répertoire sont de type sparse pour qu'il ne transfèreque les données contenues dans ces fichiers, et non les zéros qui suivent.

Rsync ne transfère pas l'ensemble d'un fichier s'il n'a subit qu'un changement partiel. Il découpe le fichier à transféreren tronçons dont il calcule les empreintes. Il compare ensuite ces empreintes avec celles du fichier cible. Il détermineainsi les seuls tronçons qui ont été modifiés et qui sont donc à transférer. Ceci est particulièrement avantageux dans le cas des images disque des machines virtuelles en cours defonctionnement, qui sont volumineux et régulièrement modifiés, même si la machine reste inactive (fichiers dejournalisation, messages systèmes, etc.). Une fois les tronçons arrivés à destinations, un nouveau fichier est créé à partir de l'ancien fichier et des nouveauxtronçons. Le nouveau fichier prend finalement la place de l'ancien.Pour gagner du temps et mettre à jour directement le fichier cible sans passer par un fichier intermédiaire, on utilisel'option inplace. Cette option est désactivée par défaut car elle peut poser problème dans des cas bien particuliers 88,mais pas dans le nôtre.

Pour diminuer le risque d'incohérences dans les données sauvegardées, la synchronisation est basée sur ledernier cliché des données, et non sur les données actuelles, qui peuvent changer entre le début et la finde leur copie.

4.12.4.2 Données systèmesSauvegarder les données des utilisateurs (leurs instances, leurs images de machine virtuelle) n'est pas suffisant. Pourremettre le système en état de marche suite aux pires éventualités, il faut également sauver toutes les donnéesnécessaires au fonctionnement d'OpenStack : les bases de données et les fichiers de configuration.

Le moteur de gestion de base de données utilisé par Mysql, InnoDB, fonctionne avec un système complexe de cacheset de journaux. De ce fait, il n'est pas possible de réaliser une sauvegarde fiable pendant que le serveur de bases dedonnées fonctionne. La solution la plus simple et la plus sûre consiste à arrêter le SGBD, sauvegarder les bases, puisrelancer le serveur. La sauvegarde des bases de données est réalisée sur le contrôleur secondaire. Par conséquent, durant la sauvegarde, leserveur de bases données peut être interrompu sans conséquences sur les services d'OpenStack, qui utilisent le SGBDsitué sur le premier contrôleur. Je rappelle que les bases de données sont synchronisées en temps réel sur trois nœuds,dont le contrôleur 1 et le contrôleur 2 (voir le chapitre 4.2.2.2 sur le SGBD, page 30).

Une première manière de sauvegarder les bases de données est de copier leurs fichiers, tout simplement. Cettesolution est parfaite pour une récupération rapide après un incident technique, mais pas idéale pour restaurer, sur unSGBD d'une certaine version, des données sauvées depuis un serveur d'une version différente. Les fichiers peuventêtre incompatibles. Dans ce cas, un autre type de sauvegarde est plus approprié : le dump, qui consiste à créer, à partir des bases dedonnées, un fichier de commandes SQL permettant de recréer exactement les mêmes bases. En théorie ces fichierssont utilisables avec différents SGBD.

88 voir le manuel de la commande "rsync"

Xavier Buche Cloud universitaire avec OpenStack – CNAM Nord-Pas de Calais 113

Nous utilisons les deux méthodes.

- la première pour les sauvegardes quotidiennes :service mysql stop

GZIP="--fast --rsyncable" tar czf /mnt/backup/conf/db.tgz /var/lib/mysql >> /var/log/sauvegarde.log 2>&1

service mysql start

- la seconde est plus longue et nécessite d'indiquer le mot de passe d'un utilisateur ayant un accès à toutes les bases,elle sera donc utilisée manuellement avant chaque mise à jour du SGBD

service mysql stop

mysqldump -u root -p --all-databases | gzip --fast --rsyncable > /mnt/backup/conf/mysql/db.sql.gz

service mysql start

On effectue également la sauvegarde de l'ensemble des fichiers de configuration du contrôleur 1 et du nœud decalcul 1, c'est-à-dire des deux serveurs qui ont une configuration différente. Sur le contrôleur 1 :

GZIP="--fast --rsyncable" tar czf /mnt/backup/conf/etc_ctrl1.tgz /etc >> /var/log/sauvegarde.log 2>&1

Sur le nœud de calcul 1 :GZIP="--fast --rsyncable" tar czf /mnt/backup/conf/etc_cmp1.tgz /etc >> /var/log/sauvegarde.log 2>&1

Dernière étape : on synchronise le répertoire /mnt/backup/conf situé sur la baie de stockage avec le serveur desauvegarde.

rsync -av --delete --log-file=/var/log/sauvegarde.log --inplace /mnt/backup/conf openuser@11.11.11.11:/data

Hormis le dump SQL, toutes les sauvegardes et les synchronisations sont réalisées par l'utilitaire cron en heurescreuses, quotidiennement.

4.12.5 RestaurationRien ne sert d'avoir misé la protection des données sur une procédure de sauvegarde infaillible si les donnéessauvegardées sont inexploitables à posteriori. Or, chacun sait que l'Histoire de l'informatique est jalonnée d'anecdotes selon lesquelles telle ou telle entreprise a vuedisparaître des données d'une importance cruciale, entraînant avec elles des pertes économiques inquantifiables.Après enquête, la même conclusion revient invariablement : les règles de base de l'état de l'art n'ont pas étérespectées.

Et l'une de ces règles, qui relèvent du sens commun pour la plupart, impose des exercices réguliers de restauration dedonnées, seuls garants de l'effectivité des sauvegardes.

Bien entendu, ces essais ne peuvent pas être réalisés sur la plate-forme de production, ce qui entraînerait, outre unecoupure temporaire du service, la perte de tous les changements réalisés depuis la dernière sauvegarde. De plus, sil'exercice n'est pas concluant, il risque de causer une indisponibilité prolongée du système, voire une lourde perte dedonnées.

Pour toutes ces raisons, il est nécessaire de réaliser ces tests périodiques sur une maquette identique à la version deproduction. La démarche de restauration est la suivante :– on arrête tous les démons OpenStack ainsi que les serveurs de base de données– on récupère les données depuis le serveur de sauvegardes avec la commande scp– on copie les fichiers à leurs emplacements respectifs (fichiers de configuration dans /etc, instances dans

/var/lib/nova/instances, bases de données dans /var/lib/mysql, etc.)– on relance les serveurs de base de données et les services d'OpenStack– on vérifie que la restauration s'est bien déroulée, que le système est opérationnel et que les données sont bien

celles de la sauvegarde en comparant les dates de modification

Xavier Buche Cloud universitaire avec OpenStack – CNAM Nord-Pas de Calais 114

5 Bilan et perspectives

5.1 BilanMaintenant qu'il arrive au terme de ce mémoire, je laisse au lecteur le soin de choisir l'adverbe qui lui sied pourqualifier le degré de complexité d'OpenStack. Même si peu de temps suffit à mettre en place une plate-formefonctionnelle, des mois sont nécessaires pour l'appréhender en profondeur et en maîtriser les rouages. En ce qui meconcerne, et malgré ma modeste mais néanmoins certaine expérience du domaine, je dirais qu'OpenStack est« singulièrement » complexe !

Cette complexité n'est cependant pas gratuite : elle est la contre-partie d'une richesse fonctionnelle hors du commun,d'une flexibilité considérable, d'une modularité poussée à l'extrême.

Et pourtant, à plusieurs reprise, je n'ai pas pu cacher ma déception en constatant certaines lacunes que je juge indigned'un produit aussi populaire. Comme par exemple l'impossibilité d'assigner un quota général par utilisateur, ou encorel'absence de fonction d'affectation automatique d'adresse flottante aux instances.

Par ailleurs, et malgré le soin et l'importance portées sur le développement d'OpenStack par des spécialistes du mondeentier, j'ai été confronté à un nombre non négligeable de dysfonctionnements ou d'incohérences. Certaines fois, unesimple mise à jour suffisait à en venir à bout. Mais d'autres fois, c'est une mise à jour qui était à l'origine de l'ennui… Ilfallait alors chercher des moyens de contournement, et parfois signaler certains problèmes sur le site communautairede gestion des bogues d'OpenStack.

Cela dit, et pour sa défense, OpenStack est très jeune, il évolue très vite et de nombreuses nouvelles fonctionnalitéssont régulièrement proposées et ajoutées. Précisons enfin que les problèmes se sont toujours posés après que desmodifications ont été faites. Jamais je n'ai constaté d’aléas ou d'imprévus inexpliqués dans le fonctionnementd'OpenStack. Une fois correctement configuré, il s'est toujours révélé parfaitement stable.

Le bilan est également mitigé en ce qui concerne la documentation officielle. Elle est conséquente et de bonne facture,et elle suffit à réaliser une installation basique et à comprendre les grandes lignes du fonctionnement d'OpenStack.Mais elle est tout sauf exhaustive : certaines parties essentielles, comme la gestion des droits d'accès, sont abordéestrop succinctement, et la plupart des milliers de directives de configuration sont expliquées de façon lapidaire, en unephrase.Heureusement, de nombreux blogs et autres wikis, souvent rédigés par des développeurs d'OpenStack reconnus,parsèment le réseau des réseaux et lèvent le voile sur les facettes obscures du paramétrage de certains composants.

5.2 PerspectivesMaintenant regardons devant nous. A ce stade, de nombreuses choses ont été réalisées, mais il reste encore beaucoupà faire :– affiner la supervision système en ajoutant des sondes Nagios et Cacti– traiter les données engrangées par Ceilometer pour obtenir des statistiques d'usage des ressources– détecter l'inactivité des machines virtuelles pour les désactiver automatiquement et économiser des

ressources– attribuer automatiquement un nom DNS89 aux instances, en plus d'une adresse IP externe– faire en sorte que seuls les utilisateurs autorisés puissent obtenir des adresses flottantes sur le réseau externe

public, et en quantité limitée– généraliser l'agrégation de liens– migrer vers la version Kilo d'OpenStack– utiliser le protocole shibboleth pour authentifier les utilisateurs– éventuellement, utiliser Cinder en conjonction avec les pilotes Netapp pour optimiser le processus de

89 Domain Name System

Xavier Buche Cloud universitaire avec OpenStack – CNAM Nord-Pas de Calais 115

création des volumes et des instances– intégrer une interface web simplifiée au portail de l'université– mettre en place une reprise sur panne automatique du contrôleur– synchroniser les projets avec les groupes LDAP de type OpenStack créés par les utilisateurs avec l'outil du

CRI– réaliser un questionnaire de satisfaction des utilisateurs

6 Conclusion

6.1 Apports pour l'universitéBien que moult améliorations restent à mettre en place, le système est d'ores et déjà exploitable et opérationnel. Il esten cours de test auprès d'utilisateurs ciblés et s'ouvre graduellement à un nombre croissant d'usagers. A l'heure oùj'écris ces lignes, une soixantaine de machines virtuelles sont utilisées en production, et ce chiffre est enaugmentation constante. A court terme, la plate-forme sera mise à disposition des 700 étudiants informaticiens duFIL, ce qui constituera un véritable test de charge en grandeur réelle. Après avoir subi cette épreuve et confirmé sastabilité, elle sera digne d'être ouverte à l'ensemble du campus. A plus longue échéance, il sera éventuellementquestion de la mutualiser avec les autres universités qui, bientôt, seront unies avec la nôtre sous la bannière del'Université de Lille.

Actuellement, le sujet des infrastructures de cloud computing, et tout particulièrement OpenStack, intéresse de près laplupart des équipes techniques des centres de données des universités, des rectorats et autres administrationspubliques. Pouvoir discuter avec mes homologues des succès et des déconvenues techniques que j'ai rencontrés estmutuellement très instructif. Ce fut déjà le cas en avril dernier, lors d'une présentation à une journée organisée par leréseau MIn2RIEN dont j'ai parlé en introduction. Ce sera bientôt le cas de nouveau, en décembre prochain. Cette fois,ce seront les JRES90 qui m'accueilleront et m'accorderont une petite heure pour, en quelque sorte, que je leur résumece que vous venez de lire.

6.2 Apports personnelsPar ce mémoire d'ingénieur du CNAM, j'espère avoir démontré que le cloud est plus qu'un simple mot, plus qu'unesimple bulle vide de tout élément novateur. Et que sous ses oripeaux marketing, il dissimule un véritable concentrédes meilleures et des plus récentes technologies informatiques.

La mise en place d'OpenStack, le fer de lance des plates-formes d'infrastructure en nuage, est à la croisée des cheminsentre de multiples domaines de l'informatique : architecture système, réseau, virtualisation, gestion de bases dedonnées, développement web… D'aucuns en parlent comme d'une « usine à gaz ». Force est de constater que laréalisation d'un tel projet exige une grande rigueur et mobilise des compétences éclectiques.

Je comparerai la mise en production d'OpenStack à un long chemin parsemé d'obstacles, jonché de pièges, parcourud'entraves plus incertaines les unes que les autres. J'ai perdu le compte du nombre de fois où je pensais, à tort, toucherau but. Chaque difficulté surmontée débouchait invariablement sur un lot nouveau de questions sans réponses et deproblèmes sans solutions. Mais pas à pas, petit à petit, j'apportai des réponses et je trouvai des solutions. Ainsi j'ai pumettre au jour un grand nombre d'écueils, des bogues, des anomalies ou incohérences diverses, qu'il m'a fallu corrigerou éluder, ce qui m'a doté d'une indéniable connaissance du sujet.

Même si la nature de ce projet était principalement technique, la composante humaine était essentielle. D'une part, letravail en équipe requiert une organisation particulière, sur laquelle nous nous sommes accordés. D'autre part, lecloud est un nouveau service dont les contours sont encore mal définis. Certains utilisateurs réclament desfonctionnalités jugées inutiles par d'autres. Mais OpenStack a cet avantage de pouvoir facilement s'adapter à desbesoins variés, et la configuration actuelle convient à la quarantaine de personnes (enseignants, étudiants etingénieurs) qui l'ont testée en profondeur.

90 les Journées RESeaux ont lieu tous les deux ans et s’adressent à l’ensemble de la communauté informatique de l’enseignement et de larecherche

Xavier Buche Cloud universitaire avec OpenStack – CNAM Nord-Pas de Calais 116

En définitive, la réalisation de ce projet m'a donné la satisfaction d'aboutir à un résultat en rapport avec la popularitéd'OpenStack. Et l'expérience qui en découle, aussi modeste soit-elle, est à mes yeux d'une richesse inattendue, quej'espère avoir su partager dans ces lignes.

Ainsi prend fin ce curieux voyage dans un nuage fait de bits, aux tréfonds d'un fabuleux dédale technologique.

Xavier Buche Cloud universitaire avec OpenStack – CNAM Nord-Pas de Calais 117

7 Références

7.1 BibliographieCHAZALLET S., Python 3 : les fondamentaux du langage, éd. ENI, 864 p., 2014

DUPRÉ X., Programmation avec le langage Python : un outil commode au service de l’ingénieur, éd. Ellipses, 332 p., 2011

GABORY Y., FERRARI N., PÉTILLON T., Django avancé : pour des applications web puissantes en Python, éd. Eyrolles, 401 p.,2013

PUISEUX P., Le langage Python : Python 3 par la pratique avec exercices corrigés, éd. Ellipses, 264 p., 2012

7.2 WebographieAnnonce de Rackspace. Annonce du lancement du projet OpenStack [en ligne] (page consultée le 10/03/2015)http://www.rackspace.com/blog/opening-the-rackspace-cloud/

API référence. La documentation des API d'OpenStack [en ligne] (page consultée le 22/04/2015)http://api.OpenStack.org

Benchmarks. Site web de compilation de benchmarks [en ligne] (page consultée le 12/04/2015)http://www.cpubenchmark.net/

Cloudindex. PAC cloudindex 2014 [en ligne] (page consultée le 8/03/2015)http://www1.montpellier.inra.fr/bartoli/moisa/bartoli/download/moisa2011_pdf/regles.pdf

Documentation de cloud-init. Des indications sur le paramétrage de cloud-init [en ligne] (page consultée le 7/05/2015)http://cloudinit.readthedocs.org

Facturation avec Ceilometer. Un blueprint de module pour facturer aux utilisateurs leur consommation de ressources en fonction des données recueillies par ceilometer [en ligne] (page consultée le 6/03/2015)https://wiki.OpenStack.org/wiki/Ceilometer/blueprints/Add_Billing_in_Ceilometer

Guide opérationnel. Guide des opération d'OpenStack [en ligne] (page consultée le 12/04/2015)http://docs.OpenStack.org/OpenStack-ops/content/OpenStack-ops_preface.html

Hypervisor support matrix. Tableau des fonctionnalités supportées par les différents pilotes des hyperviseurs [en ligne] (page consultée le 12/05/2015)https://wiki.OpenStack.org/wiki/HypervisorSupportMatrixhttp://docs.OpenStack.org/developer/nova/support-matrix.html

Intel iSCSI. Prise en charge du protocole iSCSI par les interfaces ethernet Intel [en ligne] (page consultée le 13/04/2015)http://download.intel.com/support/network/sb/inteliscsiwp.pdf

Libguestfs. Une librairie et des outils pour l'accès au système de fichiers des machines virtuelles depuis l'hôte [en ligne] (page consultée le 8/05/2015)http://libguestfs.org/

Loi Fioraso. Art. L. 123-4-1 de la loi du 22 juillet 2013 pour la priorité au logiciel libre dans l'enseignement supérieur [en ligne] (page consultée le 12/05/2015)http://www.legifrance.gouv.fr/affichCodeArticle.do?idArticle=LEGIARTI000006524413&cidTexte=LEGITEXT000006071191

Utilization based scheduling. Blueprint pour la définition de métriques d'ordonnancement par l'administrateur [en ligne] (page consultée le 26/04/2015)https://blueprints.launchpad.net/nova/+spec/utilization-based-scheduling

Xavier Buche Cloud universitaire avec OpenStack – CNAM Nord-Pas de Calais 118

7.3 Liste des figuresFigure 1 : cloud computing (source : fr.wikipedia.org)10

Figure 2 : schéma conceptuel (source : docs.OpenStack.org)22

Figure 3 : un serveur Dell PowerEdge R620 (source : www.dell.com)25

Figure 4 : infrastructure matérielle (sources : www.dell.com, www.netapp.com)28

Figure 5 : architecture générale du réseau29

Figure 6 : arbre LDAP48

Figure 7 : processus de création d'une instance de machine virtuelle61

Figure 8 : stockage centralisé65

Figure 9 : problèmes d'affichage avec la console SPICE HTML575

Figure 10 : réseau(x) interne(s) (à gauche) et réseau(x) externe(s) (à droite)79

Figure 11 : les routeurs virtuels79

Figure 12 : NAT dynamique80

Figure 13 : NAT statique81

Figure 14 : tronçon 802.1Q83

Figure 15 : estampillage des trames 802.1Q83

Figure 16 : topologie d'un réseau basé sur le protocole GRE : maillage complet86

Figure 17 : infrastructure réseau virtuelle d'un nœud de calcul90

Figure 18 : infrastructure réseau virtuelle du contrôleur91

7.4 Liste des tableauxTableau 1 : choix d'une interface web103

Xavier Buche Cloud universitaire avec OpenStack – CNAM Nord-Pas de Calais 119

7.5 Index des abréviationsAKI : Amazon Kernel ImageAMI : Amazon Machine ImageAMUE : Agence de Mutualisation des Universités et ÉtablissementsAPI : Application Programming InterfaceARI : Amazon Ramdisk ImageCAPEX : CApital EXpenditureCERN : Conseil Européen pour la Recherche NucléaireCNRS : Centre National de la Recherche ScientifiqueComUE : Communauté d'Universités et d’ÉtablissementsCP/CMS : Control Program/Cambridge Monitor SystemCPU : Central Processing UnitCRI : Centre de Ressources InformatiquesDHCP : Dynamic Host Configuration ProtocolDNS : Domain Name SystemDSI : Directeur des Systèmes d'InformationEC2 : Elastic Compute CloudGbE : Gigabit EthernetGRE : Generic Routing EncapsulationHMAC : Hash-based Message Authentication CodeHP : Hewlett PackardHTML : Hypertext Markup LanguageHTTP : Hypertext Transfer ProtocolIaaS : Infrastructure as a ServiceIBM : International Business MachinesICMP : Internet Control Message ProtocoliDRAC : integrated Dell Remote Access ControlleriLO : integrated Lights-OutIPMI : Intelligent Platform Management InterfaceiSCSI : internet Small Computer System InterfaceISO : International Organization for StandardizationKVM : Kernel-based Virtual MachineLACP : Link Aggregation Control ProtocolLDAP : Lightweight Directory Access ProtocolMAC : Media Access ControlMTU : Maximum Transmission UnitNASA : National Aeronautics and Space AdministrationNFS : Network File SystemNIST : National Institute of Standards and TechnologyOPEX : OPerational EXpenditureOSI : Open Systems InterconnectionOVF : Open Virtualization FormatPaaS : Platform as a ServicePagP : Port Aggregation ProtocolQcow2 : QEMU copy-on-write version 2QEMU : Quick EmulatorRAID : Redundant Array of Inexpensive Disks

Xavier Buche Cloud universitaire avec OpenStack – CNAM Nord-Pas de Calais 120

RDP : Remote Desktop ProtocolSaaS : Software as a ServiceSDDC : Software Defined Data CenterSDN : Software Defined NetworkSGBD : Système de Gestion de Bases de DonnéesSPICE : Simple Protocol for Independent Computing EnvironmentsSSH : Secure SHellTLS : Transport Layer SecurityURL : Uniform Resourse LocatorVDI : Virtual Desktop InfrastructureVDI : Virtual Disk ImageVHD : Virtual Hard DiskVLAN : Virtual Local Area NetworkVMDK : Virtual Machine DisKVNC : Virtual Network ComputingVPN : Virtual Private NetworkVXLAN : Virtual Extensible Local Area NetworkWSREP : Write Set REPlication

7.6 Lexiqueagrégat d'hôtes : technique permettant de segmenter un cluster OpenStack, le choix de l'agrégat sur lequel exécuterune instance étant fonction de ses métadonnées

benchmark : test de charge permettant de connaître les performances et les capacités d'un élément logiciel oumatériel

blueprint : document définissant un plan détaillé des améliorations à venir d'un logiciel

cellule : cluster OpenStack dépendant d'un ordonnanceur de plus haut niveau. Concept ajoutant un niveausupplémentaire dans l'ordonnancement des instances. Lors du processus de création d'une instance, un premierordonnanceur sélectionne une cellule sur laquelle un deuxième ordonnanceur sélectionne le nœud de calcul surlequel sera lancée l'instance.

cloud computing : système permettant d'accéder facilement, à la demande, à tout moment et en tout lieu, à desressources informatiques partagées et configurables

cloud washing : pratique qui consiste à renouveler un service existant en ajoutant juste le mot « cloud » au messagecommercial

domaine : ensemble d'objets Keystone (utilisateurs, projets, rôles, groupes) situés sous la même autoritéadministrative

domaine de diffusion : regroupe toutes les machines qui reçoivent directement les diffusions générales (broadcast)des autres machines

ethernet : norme et protocole définissant les caractéristiques physiques et logiques de transmissions réseaux deniveau 1 et 2 du modèle OSI

grappe (appelée aussi cluster) : ensemble d'ordinateurs qui fournissent un même service, chacun répondant auxrequêtes parallèlement aux autres, augmentant par conséquent les capacités du service (fiabilité et performances)

groupe de sécurité : liste de règles de filtrage réseau que l'utilisateur peut facilement créer, éditer et appliquer auxinstances de ses machines virtuelles

HMAC (Hash-based Message Authentication Code) : chaîne de caractères aléatoire, suivie par un condensat de cettechaîne chiffré avec une clé de chiffrement privée, le HMAC sert généralement à garantir l'authenticité d'un message.

Xavier Buche Cloud universitaire avec OpenStack – CNAM Nord-Pas de Calais 121

hyperviseur : logiciel qui gère le partage des ressources matérielles entre des systèmes virtualisés

instantané (aussi appelé snapshot ou encore cliché) : dans le contexte du stockage de données et des machinesvirtuelles, il s'agit de l'état d'un système de fichiers à un instant T

IPMI (Intelligent Platform Management Interface) : interface qui permet d'obtenir des informations sur le matériel(ventilateurs, température, etc.)

isolation : technique permettant de cloisonner des systèmes de type Unix qui se partagent le même matériel et lemême noyau, augmentant ainsi les performances par rapport à la virtualisation

LDAP (Lightweight Directory Access Protocol) : protocole d'accès aux bases de données hiérarchiques

Open vSwitch : logiciel open-source permettant de mettre en place des commutateurs virtuels

ordonnanceur (aussi appelé scheduler) : dans le contexte du composant Nova d'OpenStack, choisit, selon des critèresprécis, le nœud de calcul sur lequel sera exécuté une instance de machine virtuelle

paravirtualisation : technique de virtualisation de machines dans laquelle le système invité a conscience d'êtrevirtualisé, améliorant ainsi sa vitesse d'exécution

pare-feu : système permettant de filtrer (interdire ou accepter) les communications réseaux selon des critères variéscomme la valeur de certains champs d’en-tête, la taille des paquets, etc.

piratage par dictionnaire : acte par lequel un pirate tente de découvrir un mot de passe en essayant une à unetoutes les entrées d'un dictionnaire qui contient les chaînes de caractères les plus probablement utilisées

piratage par force brute : acte par lequel un pirate tente de découvrir un mot de passe en essayant une à une toutesles combinaisons possibles de chaînes de caractères, de manière exhaustive

région : concept de répartition des ressources matérielles dans des clusters OpenStack isolés les uns des autres.L'utilisateur choisit lui-même dans quelle région il souhaite exécuter ses machines virtuelles.

tunnel : dans le domaine des réseaux informatiques, abstraction permettant de faire transiter des données isolémentdes réseaux qu'elles traversent

VDI (Virtual Desktop Infrastructure) : consiste à centraliser et virtualiser l'exécution des postes de travail desutilisateurs

virtualisation : technique permettant de transformer des ressources concrètes (machines, réseaux, etc.) en ressourcesabstraites équivalentes, optimisant ainsi leur taux d'utilisation et la flexibilité de leur usage

VLAN : technologie permettant de segmenter virtuellement un réseau ethernet en utilisant le protocole 802.1Q pour« étiqueter » chaque trame

widget : composant d'une l'interface graphique, comme un bouton ou un menu

zone de disponibilité : technique permettant de segmenter un cluster OpenStack, le choix de la zone sur laquelleexécuter une instance étant fait par l'utilisateur

Xavier Buche Cloud universitaire avec OpenStack – CNAM Nord-Pas de Calais 122

8 Annexes

8.1 Adaptation de l'interface web

REMPLACER TERMINER INSTANCE PAR SUPPRIMER INSTANCE :Dans le fichier /usr/share/OpenStack-dashboard/OpenStack_dashboard/locale/fr/LC_MESSAGES/django.poremplacer :msgstr "Terminer"par :msgstr "Supprimer"

Dans le fichier /usr/share/OpenStack-dashboard/OpenStack_dashboard/locale/en/LC_MESSAGES/django.poremplacer :msgstr "Terminate"par :msgstr "Delete"

apt-get install gettextmsgfmt django.po -o django.moservice apache2 restart

MODIFIER L'AIDE EN LIGNE DE CREATION D'IMAGES :Dans le fichier/usr/share/OpenStack-dashboard/OpenStack_dashboard/dashboards/project/images/templates/images/images/_create.htmlremplacer :Currentlypar :If you select 'Image location'

Dans le fichier /usr/share/OpenStack-dashboard/OpenStack_dashboard/locale/fr/LC_MESSAGES/django.poremplacer :Actuellement par :Si vous selectionnez \"Emplacement de l'image\"

msgfmt django.po -o django.moservice apache2 restart

SUPPRIMER LE PANEL PASSWORD DANS LES SETTINGS :Dans /usr/share/OpenStack-dashboard/OpenStack_dashboard/dashboards/settings/dashboard.pysupprimer le panneau password de la liste de panneau en remplaçant la ligne :panels = ('user', 'password', )par :panels = ('user', )

SUPPRIMER LE CHOIX DE LA ZONE DE DISPONIBILITE DANS LA FENETRE DE CREATION DES INSTANCES :Dans le fichier /usr/share/OpenStack-

Xavier Buche Cloud universitaire avec OpenStack – CNAM Nord-Pas de Calais 123

dashboard/OpenStack_dashboard/dashboards/project/instances/workflows/create_instance.pysupprimer l'attribut availability_zone de la classe SetInstanceDetailsAction en commentant la ligne : availability_zone = forms.ChoiceField(label=_("Availability Zone"), required=False)

PRESELECTIONNER LE TYPE DE SOURCE LORS DE LA CREATION D'UNE INSTANCE :Dans le fichier /usr/share/OpenStack-dashboard/OpenStack_dashboard/dashboards/project/instances/workflows/create_instance.pyon renseigne l'attribut "initial" de l'objet source_type :Remplacer source_type = forms.ChoiceField(label=_("Instance Boot Source"), required=True, help_text=_("Choose Your Boot Source " "Type.")) par source_type = forms.ChoiceField(label=_("Instance Boot Source"), required=True, initial="image_id", help_text=_("Choose Your Boot Source " "Type."))

CHANGER L'ORDRE DU MENU DES INSTANCES :Dans le fichier /usr/share/OpenStack-dashboard/OpenStack_dashboard/dashboards/project/instances/tables.py

Tout à la fin du fichier, l'attribut row_actions de la classe Meta contient, dans l'ordre, la liste des entrées à afficher dansle menu des actions à effectuer sur les instances.

row_actions = (StartInstance, ConfirmResize, RevertResize, CreateSnapshot, SimpleAssociateIP, AssociateIP, SimpleDisassociateIP, EditInstance, DecryptInstancePassword, EditInstanceSecurityGroups, ConsoleLink, LogLink, TogglePause, ToggleSuspend, ResizeLink, SoftRebootInstance, RebootInstance, StopInstance, RebuildInstance, TerminateInstance)

On remplace par :

row_actions = (StartInstance, ConfirmResize, RevertResize, SimpleAssociateIP, AssociateIP, SimpleDisassociateIP, EditInstance, DecryptInstancePassword, EditInstanceSecurityGroups, CreateSnapshot, ConsoleLink, LogLink, TogglePause, ToggleSuspend, ResizeLink, SoftRebootInstance, RebootInstance, StopInstance, RebuildInstance, TerminateInstance)

pour que, en temps normal, SimpleAssociateIP soit utilisable directement en cliquant sur le bouton du menu.

AJOUTER UN LIEN VERS LE TUTORIEL/usr/share/OpenStack-dashboard/OpenStack_dashboard/templates/_header.htmlAjouter <a href="https://cloud.univ-lille1.fr/doc/tutoriel.pdf" target="_blank">Tutoriel</a>à la fin du fichier, juste avant<a href="{% url 'logout' %}">{% trans "Sign Out" %}</a>

Xavier Buche Cloud universitaire avec OpenStack – CNAM Nord-Pas de Calais 124

8.2 Test de charge de l'interface webSans charge, la commande "sar -r -u" renvoie :

Average: CPU %user %nice %system %iowait %steal %idle

Average: all 1,40 0,00 0,53 0,18 0,00 97,89

Average: kbmemfree kbmemused %memused kbbuffers kbcached kbcommit %commit kbactive kbinact kbdirty

Average: 2528826 13854350 84,56 254784 8743481 7424866 22,42 9787813 3430355 211

Commençons doucement avec 5 threads qui lancent 10 fois et simultanément la même séquence de requêtes :load average sur 1 min : 2.34

Avec 30 threads :

Average: CPU %user %nice %system %iowait %steal %idle

Average: all 36,80 0,00 9,11 0,25 0,00 53,84

Average: kbmemfree kbmemused %memused kbbuffers kbcached kbcommit %commit kbactive kbinact kbdirty

Average: 2369303 14013873 85,54 254784 8744560 7754074 23,42 9944473 3430393 538

load average sur 1 min : 3.01

Avec 40 threads :

Xavier Buche Cloud universitaire avec OpenStack – CNAM Nord-Pas de Calais 125

Average: CPU %user %nice %system %iowait %steal %idle

Average: all 37,02 0,00 9,14 0,35 0,00 53,49

Average: kbmemfree kbmemused %memused kbbuffers kbcached kbcommit %commit kbactive kbinact kbdirty

Average: 2370989 14012187 85,53 254784 8755200 7750457 23,40 9941245 3430483 472

load average sur 1 min : 3.32

Avec 50 threads :

Average: CPU %user %nice %system %iowait %steal %idle

Average: all 37,45 0,00 9,12 0,33 0,00 53,09

Average: kbmemfree kbmemused %memused kbbuffers kbcached kbcommit %commit kbactive kbinact kbdirty

Average: 2371307 14011869 85,53 254784 8748331 7756518 23,42 9941760 3430442 464

load average sur 1 min : 4.07

– Average, min et max correspondent respectivement aux temps de réponse moyen, minimum et maximumaux requêtes, en millisecondes.

– Std. dev. est de mesure de la variation du temps de réponse (http://en.wikipedia.org/wiki/Standard_deviation)– Throughput est le nombre de requêtes par seconde– Kb/sec correspond au taux de transfert des données– Avg. Bytes est la quantité de données transférée.

8.3 Tutoriel d'utilisation

Xavier Buche Cloud universitaire avec OpenStack – CNAM Nord-Pas de Calais 126

Tutoriel OpenStack

SommaireC'est quoi Openstack ?…………………………………………………………………………………………………………………………………………………………1Créer une machine virtuelle………………………………………………………………………………………………………………………………………………..2Vue d'ensemble……………………………………………………………………………………………………………………………………………………………………..4Accéder à votre instance……………………………………………………………………………………………………………………………………………………..5

… depuis la console…………………………………………………………………………………………………………………………………………………………5… depuis l'extérieur…………………………………………………………………………………………………………………………………………………………6… avec une paire de clés ssh…………………………………………………………………………………………………………………………………………..8

Proxy http/https………………………………………………………………………………………………………………………………………………………………….10Filtrer l'accès aux instances………………………………………………………………………………………………………………………………………………..11Gérer ses images…………………………………………………………………………………………………………………………………………………………………13

Importer une image………………………………………………………………………………………………………………………………………………………14Créer une image par soi-même……………………………………………………………………………………………………………………………………16

… à partir d'une autre image…………………………………………………………………………………………………………………………………..16… de A à Z……………………………………………………………………………………………………………………………………………………………….17

Réseaux……………………………………………………………………………………………………………………………………………………………………………….17Ligne de commande……………………………………………………………………………………………………………………………………………………………23

C'est quoi OpenStack ?OpenStack est une plate-forme de cloud de type « infrastructure ».Vous pouvez vous en servir pour créer vos propres infrastructures virtuelles (serveurs, machines de test, postes detravail, réseaux, etc.) accessibles depuis le campus ou le VPN.

Pour toute question ou demande de dépannage, vous pouvez contacter les administrateurs systèmes du serviceOpenStack à l'adresse caché@univ-lille1.fr

Si vous souhaitez être au courant des évolutions programmées de la plate-forme ou participer aux échanges sur sonutilisation, inscrivez-vous à la liste de discussion caché@univ-lille1.fr en envoyant un message vide à caché@univ-lille1.fr

Xavier Buche Cloud universitaire avec OpenStack – CNAM Nord-Pas de Calais 127

Créer une machine virtuelle- rendez-vous sur https://cloud.univ-lille1.fr- entrez vos login et mot de passe de l'université

- cliquez sur "images" dans le menu de gauche, puis sur "lancer", à droite de l'image qui sera utilisée pour créer votreinstance (par exemple Ubuntu-Trusty)

Remarques :instance = machine virtuelleimage = modèle de machine virtuelle

Xavier Buche Cloud universitaire avec OpenStack – CNAM Nord-Pas de Calais 128

- donnez un nom à votre future instance

- cliquez sur l'onglet "Accès et sécurité", entrez le mot de passe du compte root et cliquez sur "lancer" en bas à droite

Xavier Buche Cloud universitaire avec OpenStack – CNAM Nord-Pas de Calais 129

- l'instance est en cours de création

Remarque :Veillez à éteindre ou supprimer vos machines virtuelles inutilisées.

Vue d'ensemble- cliquez sur "vue d'ensemble" dans le menu de gauche

Cette page vous présente les quotas auxquels vous êtes soumis pour quelques ressources parmi d'autres, ainsi qu'unabrégé de vos consommations (pour connaître l'ensemble de vos quotas et le détail de vos consommations, voir lechapitre sur la ligne de commande, page 36).

Xavier Buche Cloud universitaire avec OpenStack – CNAM Nord-Pas de Calais 130

Accéder à votre instance.. depuis la console- dans le menu "instances", à droite de votre instance, cliquez sur le menu "plus", puis sur "console"

- cliquez sur la barre d'état grise située juste au dessus de la console, puis entrez le login (root) et le mot de passe quevous avez défini lors de la création de l'instance

Xavier Buche Cloud universitaire avec OpenStack – CNAM Nord-Pas de Calais 131

Remarques :

La console est très limitée :- performances réduites- pas de copier-coller- problèmes de clavier (touche AltGr, pavé numérique)

Elle devrait être utilisée uniquement pour la configuration initiale et le dépannage de vos machines virtuelles.

. depuis l'extérieur

Votre instance dispose par défaut d'une adresse IP interne à la plate-forme de cloud. Vous pouvez accéder au réseauexterne (campus, internet) depuis votre instance, mais on ne peut pas accéder à votre instance depuis l'extérieur. Laconsole est donc, pour l'instant, le seul moyen d'accéder à votre instance.

Pour pouvoir vous connecter à votre instance depuis le réseau externe, il faut lui associer une adresse IP flottante.

- cliquez sur "instances" dans le menu de gauche, puis sur le bouton "associer une adresse IP flottante" à droite

- cliquez sur le bouton "+" pour réserver une adresse

Xavier Buche Cloud universitaire avec OpenStack – CNAM Nord-Pas de Calais 132

- conservez la sélection par défaut ("réseau externe privé") et cliquez sur "allocation d'IP"

- cliquez sur "associer"

- l'adresse IP flottante s'ajoute dans la colonne "adresse IP" de l'instance

Vous pouvez désormais joindre votre instance depuis l'extérieur.

Xavier Buche Cloud universitaire avec OpenStack – CNAM Nord-Pas de Calais 133

Les images Ubuntu et Centos disposent d'un compte par défaut avec les droits root (via la commande sudo). Les loginssont respectivement "ubuntu" et "centos".

A partir de la console, définissez un mot de passe pour le compte par défaut (par exemple "ubuntu") avec lacommande "passwd ubuntu".Vous pouvez maintenant vous connecter à votre instance avec ce compte et l'adresse IP flottante en utilisant lacommande "ssh ubuntu@172.28.x.y" (ou tout autre client ssh).

Remarque :Vous pouvez définir le mot de passe du compte par défaut lors de la création d'une instance en ajoutant les lignessuivantes dans le champ "script de personnalisation" (onglet "post-création") :

#cloud-config

password: mon_secret

. avec une paire de clés ssh- dans le menu de gauche, cliquez sur "accès et sécurité", sur l'onglet "paires de clefs" et sur le bouton "importation dela paire de clefs"

Xavier Buche Cloud universitaire avec OpenStack – CNAM Nord-Pas de Calais 134

- sur votre poste de travail :- sous Linux : lancez la commande "ssh keygen" et laissez les réponses par défaut, sans passphrase ; récupérezla clé publique dans le fichier ~/.ssh/id_rsa.pub

- sous Windows, vous pouvez utiliser le programme puttygen.exe pour générer une paire de clés : copiez la clépublique, sauvegardez la clé privée dans un répertoire à accès resteint et importez-la dans le client sshputty.exe en allant dans le menu "Connection > SSH > Auth" et dans le champ "private key file".

- revenez sur l'interface d'OpenStack, donnez un nom à la clé, copiez-collez la clé publique dans le champ "clépublique" et cliquez sur le bouton "importation de la clé"

Désormais, cette clé publique sera injectée dans le fichier ~/.ssh/authorized_keys du compte par défaut (centos,ubuntu,…) de toutes les nouvelles instances. Vous pourrez donc vous y connecter directement sans devoir taper le motde passe.

Xavier Buche Cloud universitaire avec OpenStack – CNAM Nord-Pas de Calais 135

Proxy http/httpsL'accès à internet depuis les instances se fait par l'intermédiaire du proxy de l'université.Tout le trafic à destination d'Internet est automatiquement redirigé vers le proxy sans qu'aucune configuration ne soitnécessaire sur les machines virtuelles.Seuls les protocoles HTTP et HTTPS sont supportés. L'accès à Internet avec d'autres protocoles ne fonctionne doncpas ou requiert la configuration d'un autre proxy (ex : ssh).N'hésitez pas à signaler tout problème lié au proxy avec OpenStack à sos-cloud@univ-lille1.fr

Si vous utilisez un réseau virtuel autre que le réseau "accès campus" (voir le chapitre "réseaux"), vous devrezconfigurer le proxy manuellement, par exemple en lançant les commandes suivantes, sous linux :

export http_proxy=http://cache.univ-lille1.fr:3128

export https_proxy=http://cache.univ-lille1.fr:3128

export HTTP_PROXY=http://cache.univ-lille1.fr:3128

export HTTPS_PROXY=http://cache.univ-lille1.fr:3128

Filtrer l'accès aux instancesOpenStack vous permet de gérer les règles de filtrage réseau de vos machines virtuelles.Par défaut, seuls quelques services sont ouverts (ssh, ping, etc.).

- installez un serveur web sur une machine virtuelle (par exemple avec la commande "apt-get install apache2"), puisconstatez que la connexion sur votre serveur avec un navigateur web est bloquée- cliquez sur "accès et sécurité" dans le menu de gauche, puis sur le bouton "gérer les règles" du groupe de sécurité pardéfaut

Un groupe de sécurité est un ensemble de règles de filtrage à appliquer sur une instance.

Xavier Buche Cloud universitaire avec OpenStack – CNAM Nord-Pas de Calais 136

- cliquez sur le bouton "ajouter une règle"

- sélectionnez la règle "HTTP", qui ouvre le port 80 en entrée, laissez l'adresse IP distante "0.0.0.0/0", qui signifie"n'importe quelle adresse", et cliquez sur le bouton "ajouter"

Xavier Buche Cloud universitaire avec OpenStack – CNAM Nord-Pas de Calais 137

- vous pouvez différentier les règles appliquées à vos instances en créant plusieurs groupes de sécurité et ensélectionnant celui qui vous convient lors de la création de l'instance…

- … ou pour une instance déjà existante

- essayez de nouveau de vous connecter à votre serveur avec un navigateur web et constatez que l'accès est désormaisouvert

Xavier Buche Cloud universitaire avec OpenStack – CNAM Nord-Pas de Calais 138

Gérer ses imagesAu moment de la création d'une instance, OpenStack tente d'y apporter quelques modifications. Entre autres :- le disque système est redimensionné pour correspondre à la taille choisie via le type d'instance- le système prend le nom de l'instance- la clef publique ssh est injectée- les journaux de démarrage sont récupérés

Tout cela nécessite que le système installé sur l'image soit préparé à une utilisation dans le cloud.

Importer une imageCertains éditeurs ou distributions linux fournissent des images adaptées à OpenStack.- dans le menu de gauche, choisissez "images" puis cliquez sur le bouton "créer une image"

- sur le panneau "créer une image", remplissez les champs suivants et cliquez sur "créer une image" :• nom : Ma_Fedora• emplacement : http://ftp.lip6.fr/ftp/pub/linux/distributions/fedora/releases/22/Cloud/x86_64/Images/Fedora-

Cloud-Base-22-20150521.x86_64.qcow2• format : QCOW2• espace disque minimal : 5 Go• RAM minimale : 1000 Mo

Xavier Buche Cloud universitaire avec OpenStack – CNAM Nord-Pas de Calais 139

La source de l'image peut être un fichier local ou un emplacement sur le web.

- l'image est maintenant en cours de création

Une fois créée, il ne vous reste plus qu'à cliquer sur "lancer" pour profiter de votre nouvelle image.

Xavier Buche Cloud universitaire avec OpenStack – CNAM Nord-Pas de Calais 140

Créer une image par soi-même.. à partir d'une autre image- connectez-vous à l'instance créée au début de ce tutoriel et modifiez-là par un "touch modif", par exemple- sur la page des instances, cliquez sur le menu "plus" de votre instance de test et sélectionnez "créer un instantané"

- créez une instance à partir de votre instantané (qui est considéré comme une nouvelle image), connectez-vous àcette instance et constatez les faits suivants :

• votre fichier modif est bien présent• la machine prend le nom de la nouvelle instance• l'historique des commandes est vide• le mot de passe root a été réinitialisé

. de A à ZLa création d'une image de machine virtuelle n'est pas réalisable avec OpenStack et sort du cadre de ce tutoriel. Vouspouvez utiliser les outils livrés avec la plupart des hyperviseurs comme QEMU, VMware, Virtualbox, etc. pour créerune image dans un format compatible avec OpenStack.

Une fois l'image créée, vous devriez y installer et configurer le programme cloud-init pour que votre image soitadaptée à une utilisation dans le cloud (redimensionnement du disque, renommage de la machine, suppression desinterfaces réseaux, de l'historique, etc.).

Ensuite il ne reste plus qu'à importer votre image dans le cloud OpenStack de la manière décrite dans le chapitreprécédent.

Xavier Buche Cloud universitaire avec OpenStack – CNAM Nord-Pas de Calais 141

Réseaux

Les instances de machine virtuelle ne peuvent pas accéder directement aux réseaux externes, c'est-à-dire aux réseauxdu campus.Les instances sont connectées à des réseaux virtuels qui peuvent être reliés aux réseaux externes par l'intermédiairede routeurs virtuels.

Xavier Buche Cloud universitaire avec OpenStack – CNAM Nord-Pas de Calais 142

mon 1er réseau virtuel

VM6

VM5

VM4

mon

2èm

e rése

au v

irtue

lVM

9

VM8

VM7

réseau accès campus VM

3

VM2

VM1

routeuropenstack routeur

université

réseau externe public

réseau externe privé

campus,Internet, ...

- dans le menu de gauche, cliquez sur "réseau" et "topologie du réseau"

Par défaut, une nouvelle instance est connectée à un réseau nommé « accès campus » et partagé avec l'ensemble desutilisateurs d'OpenStack. Ce réseau, comme son nom l'indique, est connecté au réseau externe privé via un routeurvirtuel invisible sur ce schéma car appartenant à l'administrateur.

- cliquez sur "créer un réseau" en haut à droite, donnez-lui un nom et cliquez sur "suivant"

Xavier Buche Cloud universitaire avec OpenStack – CNAM Nord-Pas de Calais 143

- entrez l'adresse IP et le masque de votre réseau

- laissez vides les détails du sous-réseau et cliquez sur "créer"

Xavier Buche Cloud universitaire avec OpenStack – CNAM Nord-Pas de Calais 144

- créer une nouvelle instance en sélectionnant votre nouveau réseau dans l'onglet "réseaux"

Votre pauvre machine est isolée sur son réseau. Pour rompre sa solitude, créez un routeur et connectez-le à votreréseau et au réseau externe privé.

- sur la page "topologie du réseau", cliquez sur le bouton "créer un routeur", donnez un nom à votre futur routeur etcliquez sur "créer un routeur"

- dans le menu de gauche, cliquez sur "routeurs" et cliquez sur le bouton "définir la passerelle" de votre réseau

Xavier Buche Cloud universitaire avec OpenStack – CNAM Nord-Pas de Calais 145

- sélectionnez "réseau externe privé" et cliquez sur "définir la passerelle"

- cliquez sur "mon_reseau" sur la page "routeurs", puis sur "ajouter une interface" dans les détails du routeur

- parmi les réseaux disponibles, sélectionnez "mon_reseau" et cliquez sur "ajouter une interface"

Xavier Buche Cloud universitaire avec OpenStack – CNAM Nord-Pas de Calais 146

- revenez sur la page "topologie du réseau" pour constater que votre nouveau réseau est relié au réseau privé externepar l'intermédiaire de votre routeurLa machine qui se trouve sur ce réseau peut désormais accéder à Internet, et vous pouvez lui associer une adresse IPflottante sur le réseau externe privé.

Remarque :Vous ne pouvez pas supprimer un réseau tant qu'il reste des instances qui y sont connectées.

Ligne de commandeOpenStack est un conglomérat de composants :– glance gère les images– nova gère les instances– neutron gère les réseaux

Pour installer la dernière version des clients de ces composants, lancez la commande suivante :sudo pip install python-glanceclient python-novaclient python-neutronclient

Pour être utilisables, les clients en ligne de commande ont nécessairement besoin de 4 options :--os-username

--os-password

--os-tenant-name

--os-auth_url

Comme il serait rédhibitoire de renseigner ces options à chaque lancement d'une commande, il est également possibled'utiliser des variables d'environnement.

- revenez sur l'interface web pour ouvrir l'onglet "accès API" de la page "accès et sécurité" et cliquez sur "téléchargerle fichier RC d'OpenStack"

Une fois que vous aurez exécuté ce script en le précédant de la commande "source", vous pourrez utiliser lescommandes qui suivent.

Ce tutoriel n'ayant pas l'objectif d'être exhaustif, nous allons prendre quelques exemples pratiques qui ne peuvent pasêtre réalisés avec l'interface web.

1) Aidez-vous de la commande "glance help" pour télécharger une image OpenStack sur votre poste.Cette commande peut être utile si vous désirez utiliser une image OpenStack dans un autre contexte.

2) Toujours avec glance, partagez l'image Fedora créée précédemment avec votre voisin.

Xavier Buche Cloud universitaire avec OpenStack – CNAM Nord-Pas de Calais 147

3) Affichez votre quota de groupes de sécurité avec la commande "neutron …".

4) Aidez-vous des commandes suivantes pour déconnecter la machine test-instance du réseau "accès campus" et laconnecter à "mon_reseau".

neutron port-listnova interface-detachneutron port-createnova interface-attach

Correction inversée :1) ytsurT-utnubU ssergorp-- 2wocq.ytsurt/pmt/ elif-- daolnwod-egami ecnalg2) oihcconip arodeF etaerc-rebmem ecnalg3) wohs-atouq nortuen4) 2b95efb354bb-af53-21c4-a56e-b5fccb82 ecnatsni-tset hcated-ecafretni avon

uaeser_nom etaerc-trop nortuen ecnatsni-tset 29ac1edaaf7d-229b-add4-42b7-5e224385 di-trop-- hcatta-ecafretni avon

Xavier Buche Cloud universitaire avec OpenStack – CNAM Nord-Pas de Calais 148