1

FORMATION OPENSTACK ADMINISTRATEUR

2 . 1

CONCERNANT CES SUPPORTS DE COURS

2 . 2

CONCERNANT CES SUPPORTS DE COURS 1/2Supports de cours réalisés par OsonesOsones https://osones.com

Logo OsonesAUTEURS

Adrien Cunin Pierre Freund Jean-François Taltavull Romain Guichard Kevin Lefevre

adrien.cunin@osones.compierre.freund@osones.com

jft@osones.comromain.guichard@osones.com

kevin.lefevre@osones.com

2 . 3

CONCERNANT CES SUPPORTS DE COURS 2/2Copyright © 2014-2017 OsonesLicence : Sources : Online :

Creative Commons BY-SA 4.0https://github.com/Osones/Formations/

https://osones.com/formations.html

Licence Creative Commons BY-SA 4.0

3 . 1

INTRODUCTION

3 . 2

OBJECTIFS DE LA FORMATION : CLOUDComprendre les principes du cloud et son intérêtConnaitre le vocabulaire inhérent au cloudAvoir une vue d’ensemble sur les solutions existantes encloud public et privéPosséder les clés pour tirer parti au mieux du IaaSPouvoir déterminer ce qui est compatible avec la philosophiecloud ou pasAdapter ses méthodes d’administration système à unenvironnement cloud

3 . 3

OBJECTIFS DE LA FORMATION : OPENSTACKConnaitre le fonctionnement du projet OpenStack et sespossibilitésComprendre le fonctionnement de chacun des composantsd’OpenStackPouvoir faire les bons choix de configurationSavoir déployer manuellement un cloud OpenStack pourfournir du IaaSConnaitre les bonnes pratiques de déploiement d’OpenStackÊtre capable de déterminer l’origine d’une erreur dansOpenStackSavoir réagir face à un bug

3 . 4

PRÉ-REQUIS DE LA FORMATIONCompétences d’administration système Linux tel qu’Ubuntu

Gestion des paquetsManipulation de fichiers de configuration et de servicesLVM et systèmes de fichiersSQL

Notions :Virtualisation : KVM, libvirtRéseau : iptables, namespaces

Peut servir :À l’aise dans un environnement Python

4 . 1

LE CLOUD, VUE D'ENSEMBLE

4 . 2

DÉFINITION FORMELLE

4 . 3

CARACTÉRISTIQUESFournir un (des) service(s)...

Self serviceÀ travers le réseauMutualisation desressourcesÉlasticité rapideMesurabilité

Inspiré de la définition du NISThttp://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-

145.pdf

4 . 4

SELF SERVICEL'utilisateur accède directement au servicePas d'intermédiaire humainRéponses immédiatesCatalogue de services permettant leurdécouverte

4 . 5

À TRAVERS LE RÉSEAUL'utilisateur accède au service à travers le réseauLe fournisseur du service est distant du consommateurRéseau = internet ou pasUtilisation de protocoles réseaux standards (typiquement :HTTP)

4 . 6

MUTUALISATION DES RESSOURCESUn cloud propose ses services à de multiplesutilisateurs/organisations → Multi-tenantLes ressources sont disponibles en grandes quantitésLa localisation précise et le taux d'occupation des ressourcesne sont pas visibles

4 . 7

ÉLASTICITÉ RAPIDEProvisionning et suppression des ressources quasi instantanéPossibilité d'automatiser ces actions de scaling (passage àl'échelle)Virtuellement pas de limite à cette élasticité

4 . 8

MESURABILITÉL'utilisation des ressources cloud est monitorée par lefournisseurLe fournisseur peut gérer son capacity planning à partir deces informationsL'utilisateur est facturé en fonction de son usage précis desressources

4 . 9

MODÈLESOn distingue :

modèles de service : IaaS, PaaS, SaaSmodèles de déploiement : public, privé,hybride

4 . 10

IAASInfrastructure as a ServiceInfrastructure :

Compute (calcul)Storage (stockage)Network (réseau)

Utilisateurs cibles : administrateurs (système, stockage,réseau)

4 . 11

PAASPlatform as a ServiceEnvironnement permettant de développer/déployer uneapplicationSpécifique à un language/framework (exemple :Python/Django)Ressources plus haut niveau que l'infrastructure, exemple :BDDUtilisateurs cibles : développeurs d'application

4 . 12

SAASSoftware as a ServiceUtilisateurs cibles : utilisateurs finaux

4 . 13

QUELQUECHOSE AS A SERVICE ?Load balancing as a Service (Infra)Database as a Service (Platform)MonApplication as a Service(Software)etc.

4 . 14

LES MODÈLES DE SERVICE EN UN SCHÉMA

IaaS - PaaS - SaaS

4 . 15

CLOUD PUBLIC OU PRIVÉ ?À qui s'adresse le cloud ?

Public : tout le monde, disponible sur internetPrivé : à une organisation, disponible sur son réseau

Concernant le cloud hybride : utilisation mixte de multiplesclouds privés et/ou publics

4 . 16

CLOUD HYBRIDEConcept séduisantMise en œuvre a priori difficileCertains cas d'usages s'y prêtent très bien

Exemple : jobs de CICloud bursting

4 . 17

L'INSTANT VIRTUALISATIONMise au point.

La virtualisation est une technologie permettantd'implémenter la fonction computeUn cloud fournissant du compute peut utiliser lavirtualisationMais peut également utiliser :

Du bare-metalDes containers

4 . 18

LES APIS, LA CLÉ DU CLOUDRappel : API pour Application Programming Interface

Au sens logiciel : Interface permettant à un logicield’utiliser une bibliothèqueAu sens cloud : Interface permettant à un logiciel d’utiliserun service (XaaS)

Interface de programmation (via le réseau, souvent HTTP)Frontière explicite entre le fournisseur (provider) etl'utilisateur (user)Définit la manière dont l'utilisateur communique avec lecloud pour gérer ses ressourcesGérer : CRUD (Create, Read, Update, Delete)REST

4 . 19

RESTUne ressource == une URI (Uniform Resource Identifier)Utilisation des verbes HTTP pour caractériser les opérations(CRUD)

GETPOSTPUTDELETE

Utilisation des codes de retour HTTPReprésentation des ressources dans le corps des réponsesHTTP

4 . 20

REST - EXEMPLESGET http://endpoint/volumes/GET http://endpoint/volumes/?size=10POST http://endpoint/volumes/DELETE http://endpoint/volumes/xyz

4 . 21

EXEMPLE CONCRETGET /v2.0/networks/d32019d3-bc6e-4319-9c1d-6722fc136a22{ "network":{ "status":"ACTIVE", "subnets":[ "54d6f61d-db07-451c-9ab3-b9609b6b6f0b" ], "name":"private-network", "provider:physical_network":null, "admin_state_up":true, "tenant_id":"4fd44f30292945e481c7b8a0c8908869", "provider:network_type":"local", "router:external":true, "shared":true, "id":"d32019d3-bc6e-4319-9c1d-6722fc136a22", "provider:segmentation_id":null }}

4 . 22

POURQUOI LE CLOUD ? CÔTÉ ÉCONOMIQUEAppréhender les ressources IT comme des services“fournisseur”Faire glisser le budget “investissement” (Capex) vers lebudget “fonctionnement” (Opex)Réduire les coûts en mutualisant les ressources, etéventuellement avec des économies d'échelleRéduire les délaisAligner les coûts sur la consommation réelle des ressources

4 . 23

POURQUOI LE CLOUD ? CÔTÉ TECHNIQUEAbstraire les couches basses (serveur, réseau, OS, stockage)S’affranchir de l’administration technique des ressources etservices (BDD, pare-feux, load-balancing, etc.)Concevoir des infrastructures scalables à la voléeAgir sur les ressources via des lignes de code et gérer lesinfrastructures “comme du code”

4 . 24

LE MARCHÉ

4 . 25

AMAZON WEB SERVICES (AWS), LE LEADER

Lancement en 2006À l'origine : services web "e-commerce" pourdéveloppeursPuis : d'autres services pour développeursEt enfin : services d'infrastructureRécemment, SaaS

4 . 26

ALTERNATIVES IAAS PUBLICS À AWSGoogle Cloud PlatformGoogle Cloud PlatformMicrosoft AzureMicrosoft AzureRackspaceDreamHostDigitalOceanEn France :

Cloudwatt (Orange BusinessServices)Numergy (SFR)OVHIkoulaScalewayOutscale

4 . 27

FAIRE DU IAAS PRIVÉOpenStackOpenStackCloudStackEucalyptusOpenNebula

4 . 28

OPENSTACK EN QUELQUES MOTS

Naissance en 2010Fondation OpenStack depuis 2012Écrit en Python et distribué sous licence Apache 2.0Soutien très large de l'industrie et contributions variées

4 . 29

EXEMPLES DE PAAS PUBLICAmazon Elastic Beanstalk( )Google App Engine ( )Heroku ( )

https://aws.amazon.com/fr/elasticbeanstalkhttps://cloud.google.com/appengine

https://www.heroku.com

4 . 30

SOLUTIONS DE PAAS PRIVÉCloud Foundry ( )OpenShift ( )Solum ( )

https://www.cloudfoundry.orghttp://www.openshift.org

https://wiki.openstack.org/wiki/Solum

4 . 31

LES CONCEPTS INFRASTRUCTURE AS A SERVICE

4 . 32

LA BASEInfrastructure :

ComputeStorageNetwork

4 . 33

RESSOURCES COMPUTEInstanceImageFlavor (gabarit)Paire de clé(SSH)

4 . 34

L'INSTANCEÉphémère, durée de vie typiquementcourteDédiée au computeNe doit pas stocker de donnéespersistantesDisque racine non persistant

4 . 35

IMAGE CLOUDImage disque contenant un OS déjà installéInstanciable à l'infiniSachant parler à l'API de metadata

4 . 36

API ... DE METADATAhttp://169.254.169.254Accessible depuis l'instanceFournit des informations relatives àl'instancecloud-init permet d'exploiter cette API

4 . 37

FLAVOR (GABARIT)Instance type chez AWSDéfinit un modèle d’instance en termes de CPU, RAM, disque(racine), disque éphémèreLe disque éphémère a, comme le disque racine, l’avantaged’être souvent local donc rapide

4 . 38

PAIRE DE CLÉClé publique + clé privée SSHLe cloud manipule et stocke la clé publiqueCette clé publique est utilisée pour donner un accès SSH auxinstances

4 . 39

RESSOURCES RÉSEAU 1/2Réseau L2

Port réseauRéseau L3

RouteurIP flottanteGroupe de sécurité

4 . 40

RESSOURCES RÉSEAU 2/2Load Balancing as aServiceVPN as a ServiceFirewall as a Service

4 . 41

RESSOURCES STOCKAGELe cloud fournit deux types de stockage

BlockObjet

4 . 42

STOCKAGE BLOCKVolumesVolumes attachables à une instanceAccès à des raw devices type /dev/vdbPossibilité d’utiliser n’importe quel système de fichiersPossibilité d'utiliser du LVM, du chiffrement, etc.Compatible avec toutes les applications existantes

4 . 43

"BOOT FROM VOLUME"Démarrer une instance avec un disque racine sur un volumevolume

Persistance des données du disqueracineSe rapproche du serveur classique

4 . 44

STOCKAGE OBJETPousser et retirer des objets dans un container/bucketPas de hiérarchie des données, pas de système de fichiersAccès par les APIsL’application doit être conçue pour tirer parti du stockageobjet

4 . 45

ORCHESTRATIONOrchestrer la création et la gestion des ressources dans lecloudDéfinition de l'architecture dans un templateLes ressources créées à partir du template forment la stack

4 . 46

BONNE PRATIQUES D'UTILISATION

4 . 47

HAUTE DISPONIBILITÉ (HA)Le control plane (les APIs) du cloud est HALes ressources provisionnées ne le sont pasforcément

4 . 48

PETS VS CATTLEComment considérer ses instances ?

PetCattle

4 . 49

INFRASTRUCTURE AS CODEAvec du code

Provisionner les ressources d'infrastructureConfigurer les dites ressources, notamment lesinstances

Le métier évolue : Infrastructure Developer

4 . 50

SCALING, PASSAGE À L'ÉCHELLEScale out plutôt que Scale up

Scale out : passage à l'échellehorizontalScale up : passage à l'échelle vertical

Auto-scaling

4 . 51

APPLICATIONS CLOUD READYStockent leurs données au bon endroitSont architecturées pour tolérer lespannesEtc.

Cf. http://12factor.net/

4 . 52

DERRIÈRE LE CLOUD

4 . 53

COMMENT IMPLÉMENTER UN SERVICE DECOMPUTEVirtualisationContainersBare metal

4 . 54

IMPLÉMENTATION DU STOCKAGE : (SOFTWAREDEFINED STORAGE) SDS

AttentionAttention : ne pas confondre avec le sujet block vs objet

Utilisation de commodity hardwarePas de RAID matérielLe logiciel est responsable de garantir les donnéesLes pannes matérielles sont prises en compte et géréesLe projet CephCeph et le composant OpenStack SwiftOpenStack Swiftimplémentent du SDS

Voir aussi ScalityScality

SDS - THÉORÈME CAP

4 . 55

Consistency - Availability - Partition tolerance

5 . 1

OPENSTACK : LE PROJET

5 . 2

TOUR D'HORIZON

5 . 3

VUE HAUT NIVEAU

Version simple

5 . 4

HISTORIQUEDémarrage en 2010Objectif : le Cloud Operating System libreTo produce a ubiquitous Open Source Cloud Computing platform that is easy to use, simple to implement, interoperable between deployments, works well at all scales, and meets the needs of users and operators of both public and private clouds.Fusion de deux projets de Rackspace (Storage) et de la NASA (Compute)Logiciel libre distribué sous licence Apache 2.0Naissance de la Fondation en 2012

5 . 5

LES RELEASESAustin (2010.1)Bexar (2011.1), Cactus (2011.2), Diablo (2011.3)Essex (2012.1), Folsom (2012.2)Grizzly (2013.1), Havana (2013.2)Icehouse (2014.1), Juno (2014.2)Kilo (2015.1), Liberty (2015.2)Mitaka (2016.1), Newton (2016.2)Ocata (2017.1)PikePike (2017.2)Début 2018 : Queens

5 . 6

QUELQUES SOUTIENS/CONTRIBUTEURS ...Editeurs : Red Hat, Suse, Canonical, Vmware, ...Constructeurs : IBM, HP, Dell, ...Constructeurs/réseau : Juniper, Cisco, ...Constructeurs/stockage : NetApp, Hitachi, ...En vrac : NASA, Rackspace, Yahoo, OVH, Citrix, SAP, ...GoogleGoogle ! (depuis juillet 2015)

https://www.openstack.org/foundation/companies/

5 . 7

... ET UTILISATEURSTous les contributeurs précédemment citésEn France : CloudwattCloudwatt et NumergyNumergyWikimediaCERNPaypalComcastBMWEtc. Sans compter les implémentations confidentielles

https://www.openstack.org/user-stories/

5 . 8

LES DIFFÉRENTS SOUS-PROJETSOpenStack Compute - NovaOpenStack (Object) Storage - SwiftOpenStack Block Storage - CinderOpenStack Networking - NeutronOpenStack Image Service - GlanceOpenStack Identity Service -KeystoneOpenStack Dashboard - HorizonOpenStack Telemetry - CeilometerOpenStack Orchestration - HeatOpenStack Database Service - Trove

5 . 9

LES DIFFÉRENTS SOUS-PROJETS (2)Mais aussi :

Bare metal (Ironic)Queue service (Zaqar)Data processing (Sahara)DNS service (Designate)Shared File Systems (Manila)Key management (Barbican)Container (Magnum)

AutresLes bibliothèques utilisées par OpenStackLes clients (python-*client), CLI etbibliothèquesLes outils de déploiement d'OpenStackLes outils utilisés pour développer OpenStack

5 . 10

LES 4 OPENSOpen SourceOpen DesignOpen DevelopmentOpen Community

https://governance.openstack.org/tc/reference/opens.html

5 . 11

LA FONDATION OPENSTACKEntité de gouvernance principale du projetReprésentation juridique du projetLes membres du board sont issus des entreprises sponsors etélus par les membres individuelsTout le monde peut devenir membre individuel(gratuitement)

5 . 12

LA FONDATION OPENSTACKLa fondation supporte le projet par différents moyens :

Événements : organisation (Summits) ou participation(OSCON, etc.)Infrastructure de développement (serveurs)Ressources humaines : marketing, release manager,quelques développeurs (principalement surl’infrastructure)

500 organisations à travers le monde60000 membres individuels dans 160 pays

5 . 13

LA FONDATION OPENSTACK

Les principales entités de la fondation

5 . 14

RESSOURCESAnnonces (nouvelles versions, avis de sécurité) :

Portail documentation : SDK/APIs : Gouvernance du projet : Versions : Support :

openstack@lists.openstack.org#openstack@Freenode

openstack-announce@lists.openstack.org

https://docs.openstack.org/http://developer.openstack.org/

https://governance.openstack.org/https://releases.openstack.org/

https://ask.openstack.org/

5 . 15

RESSOURCESActualités :

Blog officiel : Planet : Superuser : OpenStack Community Weekly Newsletter

Ressources commerciales : entre autres

http://www.openstack.org/blog/http://planet.openstack.org

http://superuser.openstack.org/

http://www.openstack.org/marketplace/

5 . 16

RESSOURCES - COMMUNAUTÉ FRANCOPHONE

Logo OpenStack-frSite web : Association des utilisateurs francophones d’OpenStack :

Meetups : Paris, Rhônes-Alpes, Toulouse, Montréal, etc.Présence à des événements tels que Paris Open SourceSummitCanaux de communication :

openstack-fr@lists.openstack.org#openstack-fr@Freenode

http://openstack.fr/

https://asso.openstack.fr/

5 . 17

FONCTIONNEMENT INTERNE

ARCHITECTURE

5 . 18

Vue détaillée des services

5 . 19

IMPLÉMENTATIONChaque sous-projet est découpé en plusieurs servicesCommunication entre les services : AMQP (RabbitMQ)Base de données : relationnelle SQL (MySQL/MariaDB)Réseau : LinuxBridge, OpenVSwitchEn général : réutilisation de composants existantsTout est développé en Python (Django pour la partieweb)APIs supportées : OpenStack et équivalent AWSMulti tenancy

5 . 20

APISChaque projet supporte son API OpenStackCertains projets supportent l'API AWSéquivalente

5 . 21

MODE DE DÉVELOPPEMENT

5 . 22

STATISTIQUES2581 contributeurs à Newton309 organisations contributrices à Newton20 millions de lignes de code écrites depuis le début duprojetDéveloppement hyper actif : 25000 commits dans Liberty

5 . 23

DÉVELOPPEMENT DU PROJET : EN DÉTAILSOuvert à tous (individuels et entreprises)Cycle de développement de 6 mois débuté par un (design)summit

5 . 24

LES OUTILSRevue de code (peer review) : GerritIntégration continue (CI: Continous Integration) : ZuulBlueprints/spécifications et bugs :

LaunchpadStoryboard

Code : Git (GitHub est utilisé comme miroir)

5 . 25

COMMUNICATIONIRCMailing-lists

5 . 26

DÉVELOPPEMENT DU PROJET : EN DÉTAILS

Workflow de changements dans OpenStack

5 . 27

CYCLE DE DÉVELOPPEMENT : 6 MOISLe planning est publié, exemple :

Milestone releasesFreezes : FeatureProposal, Feature, StringRC releasesStable releasesCe modèle de cycle de développement a évolué depuis ledébut du projetCas particulier de Swift et de plus en plus de composantsDepuis Liberty, chaque composant gère son propreversionnement

https://releases.openstack.org/ocata/schedule.html

5 . 28

VERSIONNEMENT DEPUIS LIBERTYSemantic versioningChaque projet est indépendantDans le cadre du cycle de releasenéanmoinshttp://releases.openstack.org/

5 . 29

LE NOUVEAU MODÈLE “BIG TENT”Évolutions récemment implémentéesObjectif : résoudre les limitations du précédent modèleincubation/intégréInclusion a priori de l’ensemble de l’écosystème OpenStackPrograms → Project Teams

Utilisation de tags factuels et objectifshttp://governance.openstack.org/reference/projects/index.html

https://www.openstack.org/software/project-navigator/

5 . 30

QUI CONTRIBUE ?Active Technical ContributorATC : personne ayant au moins une contribution récente dansun projet OpenStack reconnuLes ATC sont invités aux summits et ont le droit de voteCore reviewer : ATC ayant les droits pour valider les patchsdans un projetProject Team Lead (PTL) : élu par les ATCs de chaque projetStackalytics fournit des statistiques sur les contributions

http://stackalytics.com/

5 . 31

OÙ TROUVER DES INFORMATIONS SUR LEDÉVELOPPEMENT D’OPENSTACK

Comment contribuer

Informations diverses, sur le wiki

Les blueprints et bugs sur Launchpad/StoryBoard

https://docs.openstack.org/project-team-guide/https://docs.openstack.org/infra/manual/

https://wiki.openstack.org

https://launchpad.net/openstackhttps://storyboard.openstack.orghttp://specs.openstack.org/

OÙ TROUVER DES INFORMATIONS SUR LEDÉVELOPPEMENT D’OPENSTACK

5 . 32

Les patchs proposés et leurs reviews sont sur Gerrit

L’état de la CI (entre autres)

Le code (Git) et les tarballs sont disponibles

IRCRéseau FreenodeLogs discussions et infos réunions :

Mailing-lists

https://review.openstack.org

http://status.openstack.org

https://git.openstack.orghttp://tarballs.openstack.org/

http://eavesdrop.openstack.org/

http://lists.openstack.org/

5 . 33

OPENSTACK INFRAÉquipe projet en charge de l’infrastructure dedéveloppement d’OpenStackTravaille comme les équipes de dev d’OpenStack et utilise lesmêmes outilsRésultat : une infrastructure entièrement open source etdéveloppée comme tel

5 . 34

OPENSTACK SUMMITAux USA jusqu’en 2013Aujourd’hui : alternance Amérique de Nord et Asie/EuropeQuelques dizaines au début à 6000 participants aujourd’huiEn parallèle : conférence (utilisateurs, décideurs) et DesignSummit (développeurs)Détermine le nom de la release : lieu/ville à proximité duSummitUpstream Training

EXEMPLE DU SUMMIT D’AVRIL 2013 ÀPORTLAND

5 . 35

Photo : Adrien Cunin

EXEMPLE DU SUMMIT D’OCTOBRE 2015 À TOKYO

5 . 36

Photo : Elizabeth K. Joseph, CC BY 2.0, Flickr/pleia2

EXEMPLE DU SUMMIT D’OCTOBRE 2015 À TOKYO

5 . 37

Photo : Elizabeth K. Joseph, CC BY 2.0, Flickr/pleia2

EXEMPLE DU SUMMIT D’OCTOBRE 2015 À TOKYO

5 . 38

Photo : Elizabeth K. Joseph, CC BY 2.0, Flickr/pleia2

EXEMPLE DU SUMMIT D’OCTOBRE 2015 À TOKYO

5 . 39

Photo : Elizabeth K. Joseph, CC BY 2.0, Flickr/pleia2

5 . 40

TRADUCTIONLa question de la traduction est dorénavant prise en compte(officialisation de l’équipe i18n)Seules certaines parties sont traduites, comme HorizonLa traduction française est aujourd’hui une des plus avancéesUtilisation d'une plateforme web basée sur Zanata :https://translate.openstack.org/

5 . 41

DEVSTACK : FAIRE TOURNER RAPIDEMENT UNOPENSTACK

5 . 42

UTILITÉ DE DEVSTACKDéployer rapidement un OpenStackUtilisé par les développeurs pour tester leurs changementsUtilisé pour faire des démonstrationsUtilisé pour tester les APIs sans se préoccuper dudéploiementNe doit PAS être utilisé pour de la production

5 . 43

FONCTIONNEMENT DE DEVSTACKUn script shell qui fait tout le travail : stack.shUn fichier de configuration : local.confInstalle toutes les dépendances nécessaires(paquets)Clone les dépôts git (branche master par défaut)Lance tous les composants dans un screen

5 . 44

CONFIGURATION : LOCAL.CONFExemple

[[local|localrc]]ADMIN_PASSWORD=secreteDATABASE_PASSWORD=$ADMIN_PASSWORDRABBIT_PASSWORD=$ADMIN_PASSWORDSERVICE_PASSWORD=$ADMIN_PASSWORDSERVICE_TOKEN=a682f596-76f3-11e3-b3b2-e716f9080d50#FIXED_RANGE=172.31.1.0/24#FLOATING_RANGE=192.168.20.0/25#HOST_IP=10.3.4.5

5 . 45

CONSEILS D’UTILISATIONDevStack installe beaucoup de choses sur la machineIl est recommandé de travailler dans une VMPour tester tous les composants OpenStack dans de bonnesconditions, plusieurs Go de RAM sont nécessairesL’utilisation de Vagrant est conseillée

5 . 46

UTILISER OPENSTACK

5 . 47

LE PRINCIPEToutes les fonctionnalités sont accessibles par l’APILes clients (y compris Horizon) utilisent l’APIDes crédentials sont nécessaires

API OpenStack : utilisateur + mot de passe + tenant (+domaine)API AWS : access key ID + secret access key

5 . 48

LES APIS OPENSTACKUne API par service OpenStack

Chaque API est versionnée, la rétro-compatibilité est assuréeRESTCertains services sont aussi accessibles via une API différentecompatible AWS

http://developer.openstack.org/api-ref.html

5 . 49

AUTHENTIFICATION ET CATALOGUE DE SERVICEUne fois authentifié, récupération d’un jeton (token)Récupération du catalogue de servicesPour chaque service, un endpoint HTTP (API)

5 . 50

ACCÈS AUX APISDirect, en HTTP, via des outils comme curlAvec une bibliothèque

Les implémentations officielles en PythonOpenStackSDKD’autres implémentations, y compris pour d’autreslangages (exemple : jclouds)Shade

Avec les outils officiels en ligne de commandeAvec Horizon

5 . 51

CLIENTS OFFICIELSLe projet fournit des clients officiels : python-PROJETclientBibliothèques PythonOutils CLI

L’authentification se fait en passant les credentials parparamètres ou variables d’environnementL’option --debug affiche la communication HTTP

5 . 52

OPENSTACK CLIENTClient CLI unifiéCommandes du type openstack <ressource ><action >Vise à remplacer à terme les clients spécifiquesPermet une expérience utilisateur plus homogèneFichier de configuration clouds.yaml

6 . 1

DÉPLOYER ET OPÉRER OPENSTACK

6 . 2

CE QU’ON VA VOIRInstaller OpenStack à la main

Donc comprendre son fonctionnementPasser en revue chaque composant plus en détailsTour d’horizon des solutions de déploiement

http://docs.openstack.org/ocata/install-guide-ubuntu/

6 . 3

ARCHITECTURE DÉTAILLÉE

Vue détaillée des services

ARCHITECTURE SERVICES

6 . 4

Machines "physiques" et services

6 . 5

QUELQUES ÉLÉMENTS DE CONFIGURATIONGÉNÉRAUX

Tous les composants doivent être configurés pourcommuniquer avec KeystoneLa plupart doivent être configurés pour communiquer avecMySQL/MariaDB et RabbitMQLes composants découpés en plusieurs services ont parfoisun fichier de configuration par serviceLe fichier de configuration policy.json précise les droitsnécessaires pour chaque appel API

6 . 6

SYSTÈME D’EXPLOITATIONOS Linux avec PythonHistoriquement : UbuntuRed Hat s’est largementrattrapéSUSE, Debian, CentOS, etc.

6 . 7

PYTHON

Logo PythonOpenStack est aujourd’hui compatible Python 2.7Afin de ne pas réinventer la roue, beaucoup de dépendancessont nécessairesUn travail de portage vers Python 3 est en cours

6 . 8

BASE DE DONNÉESPermet de stocker la majorité des données gérées parOpenStackChaque composant a sa propre baseOpenStack utilise l’ORM Python SQLAlchemySupport théorique équivalent à celui de SQLAlchemyMySQL/MariaDB est l’implémentation la plus largementtestée et utiliséeSQLite est principalement utilisé dans le cadre de tests etdémoCertains déploiements fonctionnent avec PostgreSQL

6 . 9

POURQUOI L’UTILISATION DE SQLALCHEMY

Logo SQLAlchemySupport de multiplesBDDGestion des migrations

Logo MySQL

6 . 10

PASSAGE DE MESSAGESAMQP : Advanced Message Queuing ProtocolMessages, file d’attente, routageLes processus OpenStack communiquent via AMQPPlusieurs implémentations possibles : Qpid, 0MQ,etc.RabbitMQ par défaut

6 . 11

RABBITMQ

Logo RabbitMQRabbitMQ est implémenté en ErlangUne machine virtuelle Erlang est doncnécessaire

6 . 12

“HELLO WORLD” RABBITMQ

Illustration simple du fonctionnement de RabbitMQ

6 . 13

KEYSTONE : AUTHENTIFICATION, AUTORISATIONET CATALOGUE DE SERVICES

6 . 14

PRINCIPESAnnuaire des utilisateurs et des groupesGère des domainesListe des tenants/projetsCatalogue de servicesGère l’authentification et l’autorisationFournit un token à l’utilisateur

6 . 15

APIAPI v2 (dépréciée) : admin port 35357, utilisateur port5000API v3 : port 5000Gère utilisateurs, groupes, domainesLes utilisateurs ont des rôles sur des projets (tenants)Les services du catalogue sont associés à des endpoints

SCÉNARIO D’UTILISATION TYPIQUE

6 . 16

Interactions avec Keystone

6 . 17

INSTALLATION ET CONFIGURATIONPaquet : keystoneIntégration serveur web WSGIBackends : SQL, LDAP (ou Active Directory)Backends tokens : SQL, Memcache, aucun (suivant le type detokens)BootstrapCréation des services et endpointsCréation d'utilisateurs, groupes, domaines

6 . 18

NOVA : COMPUTE

6 . 19

PRINCIPESGère les instancesLes instances sont créées à partir des images fournies parGlanceLes interfaces réseaux des instances sont associées à desports NeutronDu stockage block peut être fourni aux instances par Cinder

6 . 20

INTERACTIONS AVEC LES AUTRES COMPOSANTS

Instance, image et volume

6 . 21

PROPRIÉTÉS D’UNE INSTANCEÉphémère, a priori non hautement disponibleDéfinie par une flavorConstruite à partir d’une imageOptionnel : attachement de volumesOptionnel : boot depuis un volumeOptionnel : une clé SSH publiqueOptionnel : des ports réseaux

6 . 22

APIGère :

InstancesFlavors (types d’instance)KeypairsIndirectement : images, security groups (groupes desécurité), floating IPs (IPs flottantes)

Les instances sont redimensionnables et migrables d’un hôtephysique à un autre.

6 . 23

FLAVORSGabaritÉquivalent des “instance types” d’AWSDéfinit un modèle d’instance en termes de CPU, RAM, disque(racine), disque éphémèreUn disque de taille nul équivaut à prendre la taille de l’imagede baseLe disque éphémère a, comme le disque racine, l’avantaged’être souvent local donc rapide

6 . 24

NOVA APIDouble rôleAPI de manipulation des instances par l’utilisateurAPI à destination des instances : API de metadataL’API de metadata doit être accessible à l’adressehttp://169.254.169.254/L’API de metadata fournit des informations de configurationpersonnalisées à chacune des instances

6 . 25

NOVA COMPUTEPilote les instances (machines virtuelles ou physiques)Tire partie de libvirt ou d’autres APIs comme XenAPIDrivers : libvirt (KVM, LXC, etc.), XenAPI, VMWare vSphere,IronicPermet de récupérer les logs de la console et une consoleVNC

6 . 26

NOVA SCHEDULERService qui distribue les demandes d’instances sur les nœudscomputeFilter, Chance, Multi SchedulerFiltres, par défaut :AvailabilityZoneFilter,RamFilter,ComputeFilterTri par poids, par défaut : RamWeigher

6 . 27

LE SCHEDULER NOVA EN ACTION

Fonctionnement de nova-scheduler

6 . 28

NOVA CONDUCTORService facultatif qui améliore la sécuritéFait office de proxy entre les nœuds compute et la BDDLes nœuds compute, vulnérables, n’ont donc plus d’accès àla BDD

6 . 29

GLANCE : REGISTRE D’IMAGES

6 . 30

PRINCIPESRegistre d’images (et des snapshots)Propriétés sur les imagesEst utilisé par Nova pour démarrer des instancesPeut utiliser Swift comme back-end de stockage

6 . 31

PROPRIÉTÉS DES IMAGES DANS GLANCEL’utilisateur peut définir un certain nombre de propriétés dont

certaines seront utilisées lors de l’instanciation

Type d’imageArchitectureDistributionVersion de ladistributionEspace disque minimumRAM minimumPublique ou non

6 . 32

TYPES D’IMAGESGlance supporte un large éventail de types d’images, limité par

le support de l’hyperviseur sous-jacent à Nova

rawqcow2amivmdkiso

6 . 33

BACKENDSSwift ou S3CephHTTPRépertoirelocal

6 . 34

INSTALLATIONPaquet glance-api : fournit l’APIPaquet glance-registry : démon du registre d’images en tantque tel

6 . 35

NEUTRON : RÉSEAU EN TANT QUE SERVICE

6 . 36

PRINCIPESSoftware Defined Networking (SDN)Auparavant Quantum et nova-networkneutron-server : fournit l’APIAgent DHCP : fournit le service de DHCP pour les instancesAgent L3 : gère la couche 3 du réseau, le routagePlugin : LinuxBridge par défaut, d’autres implémentationslibres/propriétaires, logicielles/matérielles existent

6 . 37

FONCTIONNALITÉS SUPPLÉMENTAIRESOutre les fonctions réseau de base niveaux 2 et 3, Neutron peut

fournir d’autres services :

Load Balancing (HAProxy, ...)Firewall (vArmour, ...) : diffère des groupes de sécuritéVPN (Openswan, ...) : permet d’accéder à un réseau privé sansIP flottantes

Ces fonctionnalités se basent également sur des plugins

6 . 38

APIL’API permet notamment de manipuler ces ressources :

Réseau (network) : niveau 2Sous-réseau (subnet) : niveau 3Port : attachable à une interface sur une instance, un load-balancer, etc.RouteurIP flottante, groupe de sécurité

6 . 39

LES GROUPES DE SÉCURITÉÉquivalent à un firewall devant chaque instanceUne instance peut être associée à un ou plusieurs groupes desécuritéGestion des accès en entrée et sortieRègles par protocole (TCP/UDP/ICMP) et par portCible une adresse IP, un réseau ou un autre groupe desécurité

6 . 40

PLUGINS ML2Modular Layer 2Modular Layer 2LinuxBridgeOpenVSwitchOpenDaylightContrail, OpenContrailNuage NetworksVMWare NSXcf. OpenFlow

6 . 41

IMPLÉMENTATIONNeutron tire partie des namespaces réseaux du noyau Linuxpour permettre l’IP overlappingLe proxy de metadata est un composant qui permet auxinstances isolées dans leur réseau de joindre l’API demetadata fournie par Nova

SCHÉMA

6 . 42

Vue utilisateur du réseau

SCHÉMA

6 . 43

Vue infra du réseau

6 . 44

CINDER : STOCKAGE BLOCK

6 . 45

PRINCIPESAuparavant nova-volumeFournit des volumes (stockage block) attachables auxinstancesGère différents types de volumeGère snapshots et backups de volumesAttachement via iSCSI par défaut

6 . 46

DU STOCKAGE PARTAGÉ ?Cinder n’est paspas une solution de stockage partagé commeNFSLe projet OpenStack Manila a pour objectif d’être un NFS as aServiceAWS n’a introduit une telle fonctionnalité que récemment

6 . 47

UTILISATIONVolume supplémentaire (et stockage persistant) sur uneinstanceBoot from volume : l’OS est sur le volumeFonctionnalité de backup vers un object store (Swift ou Ceph)

6 . 48

INSTALLATIONPaquet cinder-api : fournit l’APIPaquet cinder-volume : création et gestion des volumesPaquet cinder-scheduler : distribue les demandes de créationde volumePaquet cinder-backup : backup vers un object store

6 . 49

BACKENDSUtilisation de plusieurs backends en parallèlepossibleLVM (par défaut)GlusterFSCephSystèmes de stockage propriétaires type NetAppDRBD

6 . 50

HORIZON : DASHBOARD WEB

6 . 51

PRINCIPESUtilise les APIs existantes pour fournir une interfaceutilisateurHorizon est un module DjangoOpenStack Dashboard est l’implémentation officielle de cemodule

Logo du framework web Python Django

6 . 52

CONFIGURATIONlocal_settings.pyLes services apparaissent dans Horizon s’ils sont répertoriésdans le catalogue de services de Keystone

6 . 53

UTILISATIONUne zone “admin”restreinteUne interface par tenant

6 . 54

SWIFT : STOCKAGE OBJET

6 . 55

PRINCIPESSDS : Software Defined StorageUtilisation de commodityhardwareThéorème CAP : on en choisit deuxAccès par les APIsArchitecture totalement acentréePas de base de données centrale

6 . 56

IMPLÉMENTATIONProxy : serveur API par lequel passent toutes les requêtesObject server : serveur de stockageContainer server : maintient des listes d’objects dans descontainersAccount server : maintient des listes de containers dans desaccountsChaque objet est répliqué n fois (3 par défaut)

6 . 57

LE RINGProblème : comment décider quelle donnée va sur quelobject serverLe ring est découpé en partitionsOn situe chaque donnée dans le ring afin de déterminer sapartitionUne partition est associée à plusieurs serveurs

6 . 58

SCHÉMA

Architecture Swift

6 . 59

CEILOMETER : COLLECTE DE MÉTRIQUES

6 . 60

SURVEILLER L’UTILISATION DE SONINFRASTRUCTURE AVEC CEILOMETER

Indexe différentes métriques concernant l’utilisation desdifférents services du cloudFournit des APIs permettant de récupérer ces donnéesBase pour construire des outils de facturation (exemple :CloudKitty)Utilise MongoDB (par défaut) pour le stockage

6 . 61

GNOCCHI : TIME-SERIES DATABASEPourquoi Gnocchi ? Palier aux problème de scalabilité deCeilometerInitié par des développeurs de Ceilometer et intégré àl’équipe projet CeilometerBack-end remplaçant MongoDB pour Ceilometer

6 . 62

HEAT : ORCHESTRATION DES RESSOURCES

6 . 63

ORCHESTRER SON INFRASTRUCTURE AVEC HEATÉquivalent d’Amazon Cloud FormationOrchestrer les ressources compute, storage, network, etc.Doit se coupler avec cloud-initDescription de son infrastructure dans un fichier template,format JSON (CFN) ou YAML (HOT)

6 . 64

AUTOSCALING AVEC HEATHeat implémente la fonctionnalité d’autoscaling

Se déclenche en fonction des alarmes produites parCeilometerEntraine la création de nouvelles instances

6 . 65

UN TEMPLATE HOTparameters - resources - outputs

heat_template_version: 2013-05-23description: Simple template to deploy a single compute instanceresources: my_instance: type: OS::Nova::Server properties: key_name: my_key image: F18-x86_64-cfntools flavor: m1.small

6 . 66

FONCTIONNALITÉS AVANCÉES DE HEATNested stacksEnvironmentsProviders

6 . 67

CONSTRUIRE UN TEMPLATE À PARTIRD’EXISTANT

Multiples projets en cours de développement

Flame (Cloudwatt)HOT builderMerlin

6 . 68

TROVE : DATABASE AS A SERVICE

6 . 69

PRINCIPEFournit des bases de données relationnelles, à la AWS RDSA vocation à supporter des bases NoSQL aussiGère notamment MySQL/MariaDB comme back-endSe repose sur Nova pour les instances dans lesquelles se faitl’installation d’une BDD

6 . 70

SERVICEStrove-api : APItrove-taskmanager : gère les instances BDDtrove-guestagent : agent interne à l’instance

6 . 71

DESIGNATE : DNS AS A SERVICE

6 . 72

PRINCIPEÉquivalent d’AWS Route 53Gère différents backends : BIND,etc.

6 . 73

BARBICAN - KEY MANAGEMENT AS A SERVICEGère des secrets / clés privéesBackends possibles :

Fichiers chiffrésPKCS#11KMIPDogtag

6 . 74

QUELQUES AUTRES COMPOSANTSINTÉRESSANTS

6 . 75

IRONICAnciennement Nova bare-metalPermet le déploiement d’instances sur des machinesphysiques (plutôt que VMs)Repose sur des technologies telles que PXE, TFTP

6 . 76

OSLO, OU OPENSTACK COMMONOslo contient le code commun à plusieurs composantsd’OpenStackSon utilisation est transparente pour le déployeur

6 . 77

ROOTWRAPWrapper pour l’utilisation de commandes en rootConfiguration au niveau de chaque composant quil’utilisePermet d’écrire des filtres sur les commandes

6 . 78

TRIPLEOOpenStack On OpenStackObjectif : pouvoir déployer un cloud OpenStack (overcloud) àpartir d’un cloud OpenStack (undercloud)Autoscaling du cloud lui-même : déploiement de nouveauxnœuds compute lorsque cela est nécessaireFonctionne conjointement avec Ironic pour le déploiementbare-metal

6 . 79

TEMPESTSuite de tests d’un cloud OpenStackEffectue des appels à l’API et vérifie le résultatEst très utilisé par les développeurs via l’intégration continueLe déployeur peut utiliser Tempest pour vérifier la bonneconformité de son cloudCf. aussi Rally

6 . 80

BONNES PRATIQUES POUR UN DÉPLOIEMENT ENPRODUCTION

6 . 81

QUELS COMPOSANTS DOIS-JE INSTALLER ?Keystone est indispensableL’utilisation de Nova va de paire avec Glance et NeutronCinder s’avérera souvent utileCeilometer et Heat vont souvent ensembleSwift est indépendant des autres composantsNeutron peut parfois être utilisé indépendamment (ex : avecoVirt)

http://docs.openstack.org/arch-design/

6 . 82

PENSER DÈS LE DÉBUT AUX CHOIXSTRUCTURANTS

Distribution et méthode de déploiementHyperviseurRéseau : quelle architecture et quels driversPolitique de mise à jour

6 . 83

LES DIFFÉRENTES MÉTHODES D’INSTALLATIONDevStack est à oublier pour la productionTripleO est très complexeLe déploiement à la main comme vu précédemment n’est pasrecommandé car peu maintenableDistributions OpenStack packagées et prêtes à l’emploiDistributions classiques et gestion de configurationDéploiement continu

6 . 84

MISES À JOUR ENTRE VERSIONS MAJEURESOpenStack supporte les mises à jour N → N+1Swift : très bonne gestion en mode rolling upgradeAutres composants : tester préalablement avec vosdonnéesLire les release notesCf. articles de blog du CERN

6 . 85

MISES À JOUR DANS UNE VERSION STABLEFourniture de correctifs de bugs majeurs et de sécuritéOpenStack intègre ces correctifs sous forme de patchs dansla branche stablePublication de point releases intégrant ces correctifs issus dela branche stableDurée variable du support des versions stables, dépendantde l’intérêt des intégrateurs

6 . 86

ASSIGNER DES RÔLES AUX MACHINESBeaucoup de documentations font référence à ces rôles :

Controller node : APIs, BDD, AMQPNetwork node : DHCP, routeur, IPs flottantesCompute node : Hyperviseur/pilotage des instances

Ce modèle simplifié n’est pas HA.

6 . 87

HAUTE DISPONIBILITÉHaute disponibilité du IaaS

MySQL/MariaDB, RabbitMQ : HA classique (Galera, Clustering)Les services APIs sont stateless et HTTP : scale out et loadbalancersLa plupart des autres services OpenStack sont capables descale out également

Guide HA : http://docs.openstack.org/ha-guide/

6 . 88

HAUTE DISPONIBILITÉ DE L’AGENT L3 DENEUTRON

Plusieurs solutions et contournementspossiblesDepuis Juno : Distributed Virtual Router (DVR)

6 . 89

CONSIDÉRATIONS POUR UNE ENVIRONNEMENTDE PRODUCTION

Des URLs uniformes pour toutes les APIs : utiliser un reverseproxyApache/mod_wsgi pour servir les APIs lorsque cela estpossible (Keystone)Utilisation des quotasPrévoir les bonnes volumétries, notamment pour les donnéesCeilometerMonitoringBackupQoS : en cours d’implémentation dans Neutron

Guide Operations : http://docs.openstack.org/openstack-

ops/content/

6 . 90

UTILISATION DES QUOTASLimiter le nombre de ressourcesallouablesPar utilisateur ou par tenantSupport dans NovaSupport dans CinderSupport dans Neutron

http://docs.openstack.org/user-guide-admin/content/cli_set_quotas.html

6 . 91

DÉCOUPAGE RÉSEAUManagement network : réseau d’administrationData network : réseau pour la communication inter instancesExternal network : réseau externe, dans l’infrastructureréseau existanteAPI network : réseau contenant les endpoints API

6 . 92

CONSIDÉRATIONS LIÉES À LA SÉCURITÉIndispensable : HTTPS sur l’accès des APIs à l’extérieurSécurisation des communications MySQL/MariaDB etRabbitMQUn accès MySQL/MariaDB par base et par serviceUn utilisateur Keystone par serviceLimiter l’accès en lecture des fichiers de configuration (motsde passe, token)Veille sur les failles de sécurité : OSSA (OpenStack SecurityAdvisory), OSSN (... Notes)

Guide sécurité : http://docs.openstack.org/security-guide/

6 . 93

SEGMENTER SON CLOUDHost aggregates : machines physiques avec descaractéristiques similairesAvailability zones : machines dépendantes d’une mêmesource électrique, d’un même switch, d’un même DC, etc.Regions : chaque région a son APICells : permet de regrouper plusieurs cloud différents sousune même API

http://docs.openstack.org/openstack-ops/content/scaling.html#segregate_cloud

6 . 94

HOST AGGREGATES / AGRÉGATS D’HÔTESSpécifique NovaL’administrateur définit des agrégats d’hôtes via l’APIL’administrateur associe flavors et agrégats via des couplesclé/valeur communs1 agrégat ≡ 1 point commun, ex : GPUL’utilisateur choisit un agrégat à travers son choix de flavor àla création d’instance

6 . 95

AVAILABILITY ZONES / ZONES DEDISPONIBILITÉ

Spécifique Nova et CinderGroupes d’hôtesDécoupage en termes de disponibilité : Rack, Datacenter, etc.L’utilisateur choisit une zone de disponibilité à la créationd’instanceL’utilisateur peut demander à ce que des instances soientdémarrées dans une même zone, ou au contraire dans deszones différentes

6 . 96

RÉGIONSGénérique OpenStackÉquivalent des régions d’AWSUn service peut avoir différents endpoints dans différentesrégionsChaque région est autonomeCas d’usage : cloud de grande ampleur (comme certainsclouds publics)

6 . 97

CELLS / CELLULESSpécifique NovaUn seul nova-api devant plusieurs cellulesChaque cellule a sa propre BDD et file de messagesAjoute un niveau de scheduling (choix de lacellule)

6 . 98

PACKAGING D’OPENSTACK - UBUNTULe packaging est fait dans de multiples distributions, RPM,DEB et autresUbuntu est historiquement la plateforme de référence pourle développement d’OpenStackLe packaging dans Ubuntu suit de près le développementd’OpenStack, et des tests automatisés sont réalisésCanonical fournit la Ubuntu Cloud Archive, qui met àdisposition la dernière version d’OpenStack pour la dernièreUbuntu LTS

6 . 99

UBUNTU CLOUD ARCHIVE (UCA)

Support d'OpenStack dans Ubuntu via l'UCA

6 . 100

PACKAGING D’OPENSTACK DANS LES AUTRESDISTRIBUTIONS

OpenStack est intégré dans les dépôts officiels de DebianRed Hat propose RHOS/RDO (déploiement basé sur TripleO)Comme Ubuntu, le cycle de release de Fedora estsynchronisé avec celui d’OpenStack

6 . 101

LES DISTRIBUTIONS OPENSTACKStackOpsMirantisHP Helionetc.

6 . 102

DÉPLOIEMENT BARE-METALLe déploiement des hôtes physiques OpenStack peut se faireà l’aide d’outils dédiésMaaS (Metal as a Service), par Ubuntu/Canonical : se coupleavec JujuCrowbar / OpenCrowbar (initialement Dell) : utilise ChefeDeploy (eNovance) : déploiement par des imagesIronic via TripleO

6 . 103

GESTION DE CONFIGURATIONPuppet, Chef, CFEngine, Saltstack, Ansible, etc.Ces outils peuvent aider à déployer le cloudOpenStack... mais aussi à gérer les instances (section suivante)

6 . 104

MODULES PUPPET, PLAYBOOKS ANSIBLEPuppet OpenStack et OpenStack Ansible : modules Puppet etplaybooks AnsibleDéveloppés au sein du projet OpenStackhttps://wiki.openstack.org/wiki/Puppethttp://docs.openstack.org/developer/openstack-ansible/install-guide/

6 . 105

DÉPLOIEMENT CONTINUOpenStack maintient un master (trunk) toujours stablePossibilité de déployer au jour le jour le master (CD :Continous Delivery)Nécessite la mise en place d’une infrastructure importanteFacilite les mises à jour entre versions majeures

6 . 106

GÉRER LES PROBLÈMES

6 . 107

PROBLÈMES : RESSOURCES FAILED/ERRORPlusieurs causes possiblesPossibilité de supprimer la ressource?L’appel API reset-state peut servir

6 . 108

LES RÉFLEXES EN CAS D’ERREUR OU DECOMPORTEMENT ERRONÉ

Travaille-t-on sur le bon tenant ?Est-ce que l’API renvoie une erreur ? (le dashboard peutcacher certaines informations)Si nécessaire d’aller plus loin :

Regarder les logs sur le cloud controller(/var/log/<composant>/*.log)Regarder les logs sur le compute node et le network nodesi le problème est spécifique réseau/instanceÉventuellement modifier la verbosité des logs dans laconfiguration

6 . 109

EST-CE UN BUG ?Si le client CLI crash, c’est un bugSi le dashboard web ou une API renvoie une erreur 500, c’estpeut-être un bugSi les logs montrent une stacktrace Python, c’est un bugSinon, à vous d’en juger

7 . 1

TIRER PARTI DU IAAS

7 . 2

DEUX VISIONSUne fois un cloud IaaS en place, deux optiques possibles :

Garder les mêmes pratiques tout en profitant du self serviceet de l’agilité de la solution pour des besoins test/devFaire évoluer ses pratiques, tant côté applicatif que système“Pets vs Cattle”

7 . 3

SINON ?Faire tourner des applications legacy dans le cloud est une

mauvaise idée :

Interruptions de servicePertes de donnéesIncompréhensions “le cloud ça marchepas”

7 . 4

CÔTÉ APPLICATIONS

7 . 5

ADAPTER OU PENSER SES APPLICATIONS“CLOUD READY” 1/3

Cf. les design tenets du projet OpenStack et Twelve-Factorhttp://12factor.net/

Architecture distribuée plutôt quemonolithique

Facilite le passage à l’échelleLimite les domaines de failure

Couplage faible entre les composants

7 . 6

ADAPTER OU PENSER SES APPLICATIONS“CLOUD READY” 2/3

Bus de messages pour les communications inter-composantsStateless : permet de multiplier les routes d’accès àl’applicationDynamicité : l’application doit s’adapter à sonenvironnement et se reconfigurer lorsque nécessairePermettre le déploiement et l’exploitation par des outilsd’automatisation

7 . 7

ADAPTER OU PENSER SES APPLICATIONS“CLOUD READY” 3/3

Limiter autant que possible les dépendances à du matériel oudu logiciel spécifique qui pourrait ne pas fonctionner dans uncloudTolérance aux pannes (fault tolerance) intégréeNe pas stocker les données en local, mais plutôt :

Base de donnéesStockage objet

Utiliser des outils standards de journalisation

7 . 8

CÔTÉ SYSTÈME

7 . 9

ADOPTER UNE PHILOSOPHIE DEVOPSInfrastructure as CodeScale out plutôt que scale up (horizontalement plutôt queverticalement)HA niveau application plutôt qu’infrastructureAutomatisation, automatisation, automatisationTests

7 . 10

MONITORINGPrendre en compte le cycle de vie desinstancesMonitorer le service plus que le serveur

7 . 11

BACKUPÊtre capable de recréer ses instances (et le reste de soninfrastructure)Données (applicatives, logs) : block, objet

7 . 12

UTILISER DES IMAGES CLOUDUne image cloud c’est :

Une image disque contenant un OS déjà installéUne image qui peut être instanciée en n machines sans erreurUn OS sachant parler à l’API de metadata du cloud (cloud-init)Détails :

La plupart des distributions fournissent aujourd’hui desimages cloud.

http://docs.openstack.org/image-guide/openstack-images.html

7 . 13

CIRROSCirros est l’image cloud par excellenceOS minimalisteContient cloud-init

https://launchpad.net/cirros

7 . 14

CLOUD-INITCloud-init est un moyen de tirer parti de l’API de metadata, etnotamment des user dataL’outil est intégré par défaut dans la plupart des imagescloudÀ partir des user data, cloud-init effectue les opérations depersonnalisation de l’instancecloud-config est un format possible de user data

7 . 15

EXEMPLE CLOUD-CONFIG#cloud-configmounts: - [ xvdc, /var/www ]packages: - apache2 - htop

7 . 16

COMMENT GÉRER SES IMAGES ?Utilisation d’images génériques et personnalisation àl’instanciationCréation d’images intermédiaires et/ou totalementpersonnalisées : Golden images

libguestfs, virt-builder, virt-sysprepdiskimage-builder (TripleO)Packersolution “maison”

7 . 17

CONFIGURER ET ORCHESTRER SES INSTANCESOutils de gestion de configuration (les mêmes qui permettentde déployer OpenStack)Juju

8 . 1

CONCLUSION

8 . 2

POUR CONCLURELe cloud révolutionne l’ITOpenStack est le projet libre phare sur la partie IaaSDéployer OpenStack n’est pas une mince affaireL’utilisation d’un cloud IaaS implique des changements depratiqueLes métiers d’architecture logicielle et infra évoluent