openstack-ops · objectifs de la formation : openstack connaitre le fonctionnement du projet...

OPENSTACK-OPS

1

CONCERNANT CES SUPPORTS DE COURS

2 . 1

SUPPORTS DE COURS RÉALISÉS PAR ALTER WAY CLOUDCONSULTING

ex Osones -

Copyright © 2014 - 2019 alter way CloudConsultingLicence : Sources : HTML/PDF :

Licence Creative Commons BY-SA 4.0

https://cloud-consulting.alterway.fr

Creative Commons BY-SA 4.0https://github.com/Alterway/formations/

https://osones.com/formations/

2 . 2

INTRODUCTION

3 . 1

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 . 2

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

Gestion des paquetsManipulation de fichiers de configuration et de servicesLVM (Logical Volume Management) et systèmes defichiers

Notions :Virtualisation : KVM (Kernel-Based Virtual Machine), libvirtRéseau : iptables, namespacesSQL

Optionnel :À l’aise dans un environnement Python

3 . 3

OPENSTACK : LE PROJET

4 . 1

TOUR D'HORIZON

4 . 2

VUE HAUT NIVEAU

Version simple

4 . 3

HISTORIQUEDémarrage en 2010Objectif : le Cloud Operating System libreFusion de deux projets de Rackspace (Storage) et de la NASA(Compute)Logiciel libre distribué sous licence Apache 2.0Naissance de la Fondation en 2012

4 . 4

MISSION STATEMENTTo 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.

4 . 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), Pike (2017.2)Queens (2018.1), RockyRocky (2018.2)Stein (2019.1), Train (2019.2)Premier semestre 2020 : Ussuri

4 . 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/

4 . 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/

4 . 8

LES DIFFÉRENTS SOUS-PROJETS

OpenStack Compute - NovaOpenStack (Object) Storage - SwiftOpenStack Block Storage - CinderOpenStack Networking - NeutronOpenStack Image Service - GlanceOpenStack Identity Service -KeystoneOpenStack Dashboard - HorizonOpenStack Telemetry - CeilometerOpenStack Orchestration - Heat

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

4 . 9

LES DIFFÉRENTS SOUS-PROJETS (2)

Mais aussi :Bare metal (Ironic)Queue service (Zaqar)Database Service (Trove)Data processing (Sahara)DNS service (Designate)Shared File Systems (Manila)Key management (Barbican)Container (Magnum)

AutresLes clients CLI et bibliothèquesLes outils de déploiement d'OpenStackLes bibliothèques utilisées par OpenStackLes outils utilisés pour développerOpenStack 4 . 10

APISChaque projet supporte son API OpenStackCertains projets supportent l'API AWS équivalente (Nova/EC2,Swift/S3)

4 . 11

LES 4 OPENSOpen SourceOpen DesignOpen DevelopmentOpen Community

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

https://www.openstack.org/four-opens/

4 . 12

LA FONDATION OPENSTACKEntité de gouvernance principale et représentation juridiquedu projetLes membres du board sont issus des entreprises sponsors etélus par les membres individuelsTout le monde peut devenir membre individuel(gratuitement)Ressources humaines : marketing, événementiel, releasemanagement, quelques développeurs (principalement surl’infrastructure)600 organisations à travers le monde80000 membres individuels dans 170 pays

4 . 13

LA FONDATION OPENSTACK

Les principales entités de la Fondation

4 . 14

OPEN INFRASTRUCTURERécemment, la Fondation OpenStack s'élargit à l'OpenOpenInfrastructureInfrastructureAu-delà d'OpenStack, nouveaux projets chapeautés :

Kata ContainersZuulAirshipStarlingX

4 . 15

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

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

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

openstack-announce@lists.openstack.org

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

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

https://ask.openstack.org/

4 . 16

RESSOURCESActualités :

Blog officiel : Planet : Superuser :

Ressources commerciales : entre autres

Job board :

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

http://superuser.openstack.org/

https://www.openstack.org/marketplace/https://www.openstack.org/community/jobs/

4 . 17

USER SURVEYSondage réalisé régulièrement par la Fondation (tous les 6mois)Auprès des déployeurs et utilisateursDonnées exploitables : https://www.openstack.org/analytics

4 . 18

CERTIFICATION CERTIFIED OPENSTACK ADMINISTRATOR (COA)

La seule certification :Validée par la Fondation OpenStackNon liée à une entreprise particulière

Contenu :Essentiellement orientée utilisateur de cloud OpenStack

Aspects pratiques :Examen pratique, passage à distance, durée : 2,5 heuresCoût : $300 (deux passages possibles)

Ressources

Tips : Handbook : Exercices (non-officiels) :

https://www.openstack.org/coa/requirements/

https://www.openstack.org/coa/https://www.openstack.org/coa/tips/

http://www.openstack.org/coa/handbook

https://github.com/AJNOURI/COA 4 . 19

RESSOURCES - COMMUNAUTÉ FRANCOPHONE ET ASSOCIATION

Logo OpenStack-fr -

Meetups : Paris, Lyon, Toulouse, Montréal, etc.OpenStack Days France (Paris) :

Présence à des événements tels que Paris Open SourceSummitCanaux de communication :

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

https://openstack.fr/ https://asso.openstack.fr/

https://openstackdayfrance.fr/

4 . 20

FONCTIONNEMENT INTERNE

4 . 21

ARCHITECTURE

Vue détaillée des services

4 . 22

IMPLÉMENTATIONTout est développé en Python (Django pour la partie web)Chaque projet est découpé en plusieurs services (exemple :API, scheduler, etc.)Réutilisation de composants existants et de bibliothèquesexistantesUtilisation des bibliothèques oslo.* (développées par et pourOpenStack) : logs, config, etc.Utilisation de rootwrap pour appeler des programmes sous-jacents en root

4 . 23

IMPLÉMENTATION - DÉPENDANCESBase de données : relationnelle SQL (MySQL/MariaDB)Communication entre les services : AMQP (RabbitMQ)Mise en cache : MemcachedStockage distribué de configuration (à venir) : etcd

4 . 24

MODÈLE DE DÉVELOPPEMENT

4 . 25

STATISTIQUES (2017)2344 développeurs65823 changements(commits)

https://www.openstack.org/assets/reports/OpenStack-AnnualReport2017.pdf

4 . 26

DÉVELOPPEMENT DU PROJET : EN DÉTAILSOuvert à tous (individuels et entreprises)Cycle de développement de 6 moisChaque cycle débute par un Project Team Gathering (PTG)Pendant chaque cycle a lieu un OpenStack Summit

4 . 27

LES OUTILS ET LA COMMUNICATIONCode : Git (GitHub est utilisé comme miroir)Revue de code (peer review) : GerritIntégration continue (CI: Continous Integration) : ZuulBlueprints/spécifications et bugs :LaunchpadStoryBoardCommunication : IRC et mailing-listsTraduction : Zanata

4 . 28

DÉVELOPPEMENT DU PROJET : EN DÉTAILS

Workflow de changements dans OpenStack

4 . 29

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

Milestone releasesFreezes : Feature, Requirements, StringRC releasesStable releasesCas particulier de certains composants :

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

https://releases.openstack.org/reference/release_models.html

4 . 30

PROJETSÉquipes projet (Project Teams) :

Chaque livrable est versionné indépendamment - Semanticversioning

https://governance.openstack.org/reference/projects/index.html

https://releases.openstack.org/

4 . 31

QUI CONTRIBUE ?Active Technical Contributor (ATC)Personne ayant au moins une contribution récente dans unprojet OpenStack reconnuDroit de vote (TC et PTL)Core 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 contributionshttp://stackalytics.com/

4 . 32

OÙ TROUVER DES INFORMATIONS SUR LE DÉVELOPPEMENTD’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/openstack/https://storyboard.openstack.org/https://specs.openstack.org/

4 . 33

OÙ TROUVER DES INFORMATIONS SUR LE DÉVELOPPEMENTD’OPENSTACK

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.org/https://tarballs.openstack.org/

http://eavesdrop.openstack.org/

http://lists.openstack.org/

4 . 34

UPSTREAM TRAININGDeux jours de formationApprendre à devenir contributeur àOpenStackLes outilsLes processesTravailler et collaborer de manière ouverte

4 . 35

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 : Infrastructure as code open sourceopen source

Utilise du cloud (hybride)Développe certains outilsZuulyaml2ical

https://opensourceinfra.org/

4 . 36

OPENSTACK SUMMITTous les 6 mois en milieu de cycle de développpementAux USA jusqu’en 2013, aujourd'hui alternance Amérique deNord et Asie/EuropeQuelques dizaines au début à des milliers de participantsaujourd’huiEn parallèle : conférence (utilisateurs, décideurs) et Forum(développeurs/opérateurs, remplace une partie du précédentDesign Summit)Détermine le nom de la prochaine release : lieu/ville àproximité du Summit

4 . 37

EXEMPLE DU SUMMIT D’AVRIL 2013 À PORTLAND

4 . 38

EXEMPLE DU SUMMIT D’OCTOBRE 2015 À TOKYO

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

4 . 39

EXEMPLE DU SUMMIT D’OCTOBRE 2015 À TOKYO

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

4 . 40

EXEMPLE DU SUMMIT D’OCTOBRE 2015 À TOKYO

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

4 . 41

EXEMPLE DU SUMMIT D’OCTOBRE 2015 À TOKYO

4 . 42

PROJECT TEAM GATHERING (PTG)Depuis 2017Au début de chaque cycleRemplace une partie du précédent DesignSummitDédié aux développeurs

4 . 43

TRADUCTIONÉquipe officielle i18nSeules certaines parties sont traduites, comme HorizonLa traduction française est aujourd’hui une des plus avancéesUtilisation d'une plateforme web basée Zanata :https://translate.openstack.org/

4 . 44

DEVSTACK : FAIRE TOURNER RAPIDEMENT UN OPENSTACK

4 . 45

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

4 . 46

FONCTIONNEMENT DE DEVSTACKSupport d'Ubuntu 16.04/17.04, Fedora 24/25, CentOS/RHEL 7,Debian, OpenSUSEUn 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

4 . 47

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

4 . 48

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

4 . 49

DÉPLOYER OPENSTACK

5 . 1

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

https://docs.openstack.org/install-guide/

5 . 2

ARCHITECTURE DÉTAILLÉE

Vue détaillée des services5 . 3

ARCHITECTURE SERVICES

5 . 4

QUELQUES ÉLÉMENTS DE CONFIGURATION GÉNÉRAUXTous 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

5 . 5

SYSTÈME D’EXPLOITATIONOS Linux avec PythonUbuntuRed HatSUSEDebian, Fedora, CentOS,etc.

5 . 6

PYTHON

Logo PythonOpenStack est compatible Python 2.7Comptabilité Python 3 presque complèteAfin de ne pas réinventer la roue, beaucoup de dépendancessont nécessaires

5 . 7

BASE DE DONNÉES MYSQL/MARIADBPermet 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 SQLAlchemy (etsupport des migrations)MySQL/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

5 . 8

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

5 . 9

RABBITMQ

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

5 . 10

“HELLO WORLD” RABBITMQ

Illustration simple du fonctionnement de RabbitMQ

5 . 11

CACHE MEMCACHEDPlusieurs services tirent parti d'un mécanisme decacheMemcached est l'implémentation par défaut

5 . 12

KEYSTONE : AUTHENTIFICATION, AUTORISATION ET CATALOGUEDE SERVICES

5 . 13

INSTALLATION ET CONFIGURATIONPaquet APT : keystoneIntégration serveur web WSGI (Apache par défaut)Fichier de configuration: /etc/keystone/keystone.confBackends utilisateurs/groupes : SQL, LDAP (ou ActiveDirectory)Backends projets/rôles/services/endpoints : SQLBackends tokens : SQL, Memcache, aucun (suivant le type detokens)

5 . 14

DRIVERS POUR TOKENSUuidPKIFernet

5 . 15

BOOTSTRAPCréation des services et endpoints (à commencer parKeystone)Création d'utilisateurs, groupes, domainesFonctionnalité de bootstrap

5 . 16

NOVA : COMPUTE

5 . 17

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

5 . 18

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

5 . 19

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

5 . 20

LE SCHEDULER NOVA EN ACTION

Fonctionnement de nova-scheduler

5 . 21

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

5 . 22

GLANCE : REGISTRE D’IMAGES

5 . 23

BACKENDSSwift ou S3CephHTTPRépertoirelocal

5 . 24

INSTALLATIONPaquet APT : glance-api

5 . 25

NEUTRON : RÉSEAU EN TANT QUE SERVICE

5 . 26

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

5 . 27

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

5 . 28

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

5 . 29

IMPLÉMENTATIONChaque réseau est un bridgeLes bridges sont étendus entre les machines via des tunnels(type VXLAN) si nécessairesNeutron 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

5 . 30

SCHÉMA

Vue utilisateur du réseau

5 . 31

SCHÉMA

5 . 32

CINDER : STOCKAGE BLOCK

5 . 33

PRINCIPESAuparavant nova-volumeFournit des volumesAttachement des volumes via iSCSI par défaut

5 . 34

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 (optionnel) : backup vers un objectstore

5 . 35

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

5 . 36

HORIZON : DASHBOARD WEB

5 . 37

PRINCIPESHorizon est un module DjangoOpenStack Dashboard est l’implémentation officielle de cemodule

Logo du framework web Python Django5 . 38

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

5 . 39

SWIFT : STOCKAGE OBJET

5 . 40

PRINCIPESSDS : Software Defined StorageUtilisation de commodityhardwareThéorème CAP : on en choisit deuxArchitecture totalement acentréePas de base de données centrale

5 . 41

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)

5 . 42

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

5 . 43

SCHÉMA

Architecture Swift5 . 44

CEILOMETER : COLLECTE DE MÉTRIQUES

5 . 45

SURVEILLER L’UTILISATION DE SON INFRASTRUCTURE AVECCEILOMETER

Indexer et stocker différentes métriques concernantl’utilisation des différents services du cloudFournir des APIs permettant de récupérer ces donnéesBase pour construire des outils de facturation (exemple :CloudKitty)

5 . 46

CEILOMETERRécupère les données et les stockeHistoriquement : stockage MongoDBAujourd'hui : stockage Gnocchi

5 . 47

GNOCCHI : TIME-SERIES DATABASEPourquoi Gnocchi ? Palier aux problème de scalabilité deCeilometer + MongoDBInitié par des développeurs de Ceilometer et intégré àl’équipe projet CeilometerFournit une API pour lire et écrire les donnéesSe base sur une BDD relationnelle et un système de stockageobjet

5 . 48

HEAT : ORCHESTRATION DES RESSOURCES

5 . 49

ARCHITECTUREheat-apiheat-engine

5 . 50

QUELQUES AUTRES COMPOSANTS INTÉRESSANTS

5 . 51

TROVE : DATABASE AS A SERVICEtrove-api : APItrove-taskmanager : gère les instances BDDtrove-guestagent : agent interne à l’instance

5 . 52

DESIGNATE : DNS AS A SERVICEGère différents backends : BIND, PowerDNS,etc.

5 . 53

BARBICAN : KEY MANAGEMENT AS A SERVICEBackends possibles:

Fichiers chiffrésPKCS#11KMIPDogtag

5 . 54

MAGNUM : CONTAINER INFRASTRUCTURE AS A SERVICEBackends: Swarm,Kubernetes

5 . 55

OPENSTACK EN PRODUCTION ET OPÉRATIONS

6 . 1

BONNES PRATIQUES POUR UN DÉPLOIEMENT EN PRODUCTION

6 . 2

QUELS COMPOSANTS DOIS-JE INSTALLER ?Keystone est indispensableL’utilisation de Nova va de paire avec Glance et NeutronCinder et Swift s'apprécient en fonction des besoins destockageSwift peut être utilisé indépendemment des autrescomposantsHeat coûte peuLes services plus haut niveau s'évaluent au cas par cas

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

6 . 3

PENSER DÈS LE DÉBUT AUX CHOIX STRUCTURANTSDistribution et méthode de déploiementPolitique de mise à jourDrivers/backends : hyperviseur, stockage block,etc.Réseau : quelle architecture et quels drivers

6 . 4

LES DIFFÉRENTES MÉTHODES D’INSTALLATIONDevStack est à oublier pour la productionLe 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 . 5

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 vos donnéesLire les release notesCf. articles de blog du CERNhttps://techblog.web.cern.ch/techblog/

6 . 6

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 . 7

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 . 8

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 :

Conférences par Florian Haas, Hastexo :

https://docs.openstack.org/ha-guide/

https://www.openstack.org/community/speakers/profile/398/florian-haas

6 . 9

HAUTE DISPONIBILITÉ DE L’AGENT L3 DE NEUTRONDistributed Virtual Router (DVR)L3 agent HA (VRRP)

6 . 10

CONSIDÉRATIONS APISDes URLs uniformes pour toutes les APIs :

Utiliser un reverse proxyMettre à jour le catalogue de services

Apache/mod_wsgi pour servir les APIs lorsque cela estpossible (Keystone, etc.)

Guide Operations : https://docs.openstack.org/openstack-ops/content/

6 . 11

DÉCOUPAGE RÉSEAUManagement network : réseau d’administrationData/instances network : réseau pour la communication interinstancesExternal network : réseau externe, dans l’infrastructureréseau existanteStorage network : réseau pour le stockage Cinder/SwiftAPI network : réseau contenant les endpoints API

6 . 12

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é : https://docs.openstack.org/security-guide/

6 . 13

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

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

6 . 14

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 . 15

AVAILABILITY ZONES / ZONES DE DISPONIBILITÉ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 . 16

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 . 17

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 . 18

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 . 19

UBUNTU CLOUD ARCHIVE (UCA)

Support d'OpenStack dans Ubuntu via l'UCA6 . 20

PACKAGING D’OPENSTACK DANS LES AUTRES DISTRIBUTIONSOpenStack 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 . 21

LES DISTRIBUTIONS OPENSTACKStackOps : historiqueMirantis : FuelHP Helion : Ansible custometc.

6 . 22

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 . 23

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 . 24

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 . 25

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

6 . 26

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 . 27

TEST ET VALIDATION : 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 . 28

GÉRER LES PROBLÈMES

6 . 29

LES RÉFLEXES EN CAS D’ERREUR OU DE COMPORTEMENT ERRONÉTravaille-t-on sur le bon projet ?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 . 30

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

6 . 31

OPÉRATIONS

6 . 32

GESTION DES LOGSCentraliser les logsLogs d'APILogs autres composantsOpenStackLogs BDD, AMQP, etc.

6 . 33

BACKUPBases de donnéesMécanisme de déploiement, plutôt que les fichiers deconfiguration

6 . 34

MONITORINGRéponse des APIsVérification des services OpenStack etdépendances

6 . 35

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

6 . 36

CONCLUSION

7 . 1

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

7 . 2