FORMATION OPENSTACK OP��RATEUR

1
CONCERNANT CES SUPPORTS DE COURS

2.1
 SUPPORTS DE COURS RÉALISÉS PAR PARTICULE

ex Osones/Alterway
Expertise Cloud Native
Expertise DevOps
Nos offres de formations:
[Link]
Sources : [Link]
HTML/PDF : [Link]

2.2
 COPYRIGHT
Licence : Creative Commons BY-SA 4.0
Copyright © 2014-2019 alter way Cloud Consulting
Copyright © 2020 particule.
Depuis 2020, tous les commits sont la propriété de
leurs auteurs respectifs

2.3
INTRODUCTION

3.1
 OBJECTIFS DE LA FORMATION : OPENSTACK
Connaitre le fonctionnement du projet OpenStack et
ses possibilités
Comprendre le fonctionnement de chacun des
composants d’OpenStack
Pouvoir faire les bons choix de configuration
Savoir déployer manuellement un cloud OpenStack
pour fournir du IaaS
Connaitre les bonnes pratiques de déploiement
d’OpenStack
Être capable de déterminer l’origine d’une erreur
dans OpenStack
Savoir réagir face à un bug

3.2
 PRÉ-REQUIS DE LA FORMATION
Compétences d’administration système Linux
Gestion des paquets
Manipulation de fichiers de
configuration/services
LVM et systèmes de fichiers
Notions :
Virtualisation : KVM, libvirt
Réseau : iptables, namespaces
SQL
Optionnel:
À l’aise dans un environnement Python

3.3
OPENSTACK : LE PROJET

4.1
VUE HAUT NIVEAU (1/2)

Vue haut niveau

4.2
VUE HAUT NIVEAU (2/2)

Vue haut niveau

4.3
 HISTORIQUE
Démarrage du projet en 2010
Objectif : le Cloud Operating System libre
Fusion de deux projets : Rackspace (Storage) et la
NASA (Compute)
Logiciel libre distribué sous licence Apache 2.0
Naissance de l' OpenStack Foundation en 2012,
rebaptisée Open Infrastructure Foundation en
octobre 2020

4.4
 MISSION
"To produce an 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
 OPENSTACK EN 2021
"OpenStack is one of the top 3 most active open source
projects and manages 10 million compute cores."
[Link]

4.6
 LES RELEASES
Austin (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), Rocky (2018.2)
Stein (2019.1), Train (2019.2)
Ussuri (2020.1), Victoria (2020.2)
Wallaby (2021.1)
Second semestre 2021 : Xena
4.7
 SPONSORS/CONTRIBUTEURS ...
Editeurs : Red Hat, Canonical, Mirantis, VMware, ...
Constructeurs/puces et serveurs : IBM, Intel
Constructeurs/réseau : Cisco, Huawei, ...
Constructeurs/stockage : Dell EMC
Fournisseurs de services cloud et telco : Rackspace,
Vexxhost, OVH, ...
Telco : Deutsche Telekom, Tencent, China Mobile,
NTT, ATT, ...
Google (depuis juillet 2015)

4.8
 ... ET UTILISATEURS
BBC
Banco Santander, Société Générale
BMW, Volkswagen AG
Cathay Pacific
CERN
China Railway
Ministère de l'Intérieur (France)
Walmart
Wikimedia
et beaucoup d'autres
[Link]

4.9
 LES PRINCIPAUX COMPOSANTS D'OPENSTACK (1/3)
Identity : Keystone
Compute : Nova, Placement
Storage : Cinder (block), Swift (object), Manila (shared
file system)
Networking : Neutron (sdn), Octavia (lbaas),
Designate (dns)
Image : Glance
Dashboard : Horizon
Telemetry : Ceilometer
Alerting : AODH
Orchestration : Heat (infra as code), Mistral
(workflow), Blazar (resource reservation)
[Link]
4 . 10
LES PRINCIPAUX COMPOSANTS D'OPENSTACK (2/3)
Et aussi :
Bare metal : Ironic
Container : Magnum
Message Queue : Zaqar
Database : Trove
Data processing : Sahara
Key management : Barbican
Billing : Cloudkitty
Application catalog : Murano
...

4 . 11
 LES PRINCIPAUX COMPOSANTS OPENSTACK (3/3)
Autres :
OpenStack sdk (bibliothèque python) et OpenStack
client (CLI)
Les outils de déploiement d'OpenStack (OSA)
Les bibliothèques utilisées par OpenStack (Oslo)
Les outils utilisés pour développer OpenStack (git,
gerrit, zuul,...)

4 . 12
 APIS
Chaque composant maintient sa propre API
OpenStack
Certains composants supportent l'API AWS
équivalente (Nova/EC2, Swift/S3)

4 . 13
 SOFTWARE MAP

Software map

4 . 14
 LA FONDATION OPENSTACK
Rebaptisée Open Infrastructure Foundation en 2020
Entité de gouvernance principale et représentation
juridique
Les membres du "Board of Directors" sont issus des
entreprises sponsors et des membres individuels élus
Tout le monde peut devenir membre individuel
(gratuit, pas de cotisation)
Ressources humaines : marketing, événementiel,
release management, quelques développeurs
(principalement sur l’infrastructure)
710 organisations dans le monde, 110 000 membres,
182 pays
Rapport annuel: [Link]
reports/2020-openinfra-foundation-annual-report/
[Link] 4 . 15
 OPEN INFRASTRUCTURE FOUNDATION

Les principales entités de la Fondation

4 . 16
 OPEN INFRASTRUCTURE
En 2018, la Fondation OpenStack s'élargit à l'Open
Infrastructure
[Link]
"The integration of open alternatives for all the different
forms that compute storage and networking are taking
now and in the future. The interoperable open source
components are production ready, scale easily, and
businesses can rely on them for real and emerging
workloads."
Au-delà d'OpenStack, des nouveaux projets sont
incubés :
Airship
Kata Containers
StarlingX
Zuul
4 . 17
 LES 4 OPENS
Open Source
Open Design
Open Development
Open Community
[Link]
[Link]

4 . 18
 RESSOURCES (1/3)
Membres et contributeurs :
[Link]
Annonces (nouvelles versions, avis de sécurité) :
openstack-announce@[Link]
Documentation : [Link]
API/SDK : [Link]
Bug report : [Link]
Gouvernance : [Link]
Versions : [Link]

4 . 19
 RESSOURCES (2/3)
Support :
[Link]
[Link]
openstack-discuss@[Link]
#openstack@Freenode
Actualités :
Blog officiel : [Link]
Planet : [Link]
Expériences utilisateurs :
[Link]

4 . 20
 RESSOURCES (3/3)
Ressources commerciales :
[Link]
Job board :
[Link]

4 . 21
 USER SURVEY
Enquête réalisée chaque année par la Fondation
Auprès des déployeurs et utilisateurs
Résultats publiés :
[Link]

4 . 22
 CERTIFICATION : CERTIFIED OPENSTACK ADMINISTRATOR (COA)
Seule certification OpenStack existante
Validée par la Fondation OpenStack
Contenu :
Essentiellement orienté utilisateur
Pré-requis :
[Link]
Modalités :
Examen pratique (hands on), à distance, durée 3
heures maxi
Coût : USD 400
Inscription : [Link]
Ressources :
Handbook :
[Link]
4 . 23
 COMMUNAUTÉ FRANCOPHONE ET ASSOCIATION

Logo OpenStack-fr

[Link] - [Link]
Meetups : Paris, Lyon, Toulouse, Montréal, etc.
Présence à des événements tels que Paris Open
Source Summit
Canaux de communication :
openstack-fr@[Link]
#openstack-fr@oftc

4 . 24
FONCTIONNEMENT INTERNE

4 . 25
 ARCHITECTURE

Vue détaillée des services

4 . 26
 IMPLÉMENTATION
Tout est développé en Python (framework 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èques existantes
Utilisation des bibliothèques oslo.* (développées
par et pour OpenStack) : logs, config, etc.
Utilisation de rootwrap pour appeler des
programmes sous-jacents en root

4 . 27
 IMPLÉMENTATION - DÉPENDANCES
Base de données : relationnelle SQL (MariaDB-Galera)
Communication entre les services : AMQP
(RabbitMQ)
Mise en cache : Memcached
Load balancing: HAProxy

4 . 28
MODÈLE DE DÉVELOPPEMENT

4 . 29
 STATISTIQUES (2020)
1375 contributeurs
43650 changements (commits)
[Link]
openinfra-foundation-annual-report

4 . 30
 DÉVELOPPEMENT DU PROJET : EN DÉTAILS
Ouvert à tous (individuels et entreprises)
Cycle de développement de 6 mois
Chaque cycle débute par un Project Team Gathering
(PTG)
Pendant chaque cycle a lieu un OpenStack Summit

4 . 31
 LES OUTILS ET LA COMMUNICATION
Code : Git (GitHub est utilisé comme miroir)
Revue de code (peer review) : Gerrit
Intégration continue (CI: Continous Integration) : Zuul
Blueprints/spécifications et bugs :
Launchpad
StoryBoard
Communication : IRC et mailing-lists
Traduction : Zanata

4 . 32
 DÉVELOPPEMENT DU PROJET : EN DÉTAILS

Workflow de changements dans OpenStack

4 . 33
 CYCLE DE DÉVELOPPEMENT : 6 MOIS
Chaque release porte un nom :
[Link]
[Link]#release-name-criteria
Le planning est publié, exemple :
[Link]
Milestone releases
Freezes : Feature, Requirements, String
RC releases
Stable releases
Cas particulier de certains composants :
[Link]

4 . 34
 PROJETS
Équipes projet ( Project Teams) :
[Link]
Chaque livrable est versionné indépendamment - Semant
versioning
[Link]

4 . 35
 QUI CONTRIBUE ?
Active Technical Contributor (ATC)
Personne ayant au moins une contribution récente
dans un projet OpenStack reconnu
Droit de vote (TC et PTL)
Core reviewer : ATC ayant les droits pour valider les
patchs dans un projet
Project Team Lead (PTL) : élu par les ATCs de chaque
projet
Stackalytics fournit des statistiques sur les
contributions [Link]

4 . 36
OÙ TROUVER DES INFORMATIONS SUR LE DÉVELOPPEMENT D’OPENSTACK
Comment contribuer
[Link]
[Link]
Informations diverses, sur le wiki
[Link]
Les blueprints et bugs sur Launchpad/StoryBoard
[Link]
[Link]
[Link]

4 . 37
OÙ TROUVER DES INFORMATIONS SUR LE DÉVELOPPEMENT D’OPENSTACK
Les patchs proposés et leurs reviews sont sur Gerrit
[Link]
L’état de la CI (entre autres)
[Link]
Le code (Git) et les tarballs sont disponibles
[Link]
[Link]
IRC
Réseau Freenode
Logs des discussions et infos réunions :
[Link]
Mailing-lists
[Link]
4 . 38
 UPSTREAM TRAINING
Avant chaque summit
1,5 jours de formation, en anglais
Apprendre à devenir contributeur à OpenStack
Les outils
Les processes
Travailler et collaborer de manière ouverte
[Link]

4 . 39
 OPENSTACK INFRA
Équipe projet en charge de l’infrastructure de
développement d’OpenStack
Travaille comme les équipes de dev d’OpenStack et
utilise les mêmes outils
Résultat : Infrastructure as code open source
[Link]
Utilise du cloud (hybride)

4 . 40
 OPENSTACK SUMMIT
Tous les 6 mois
Aux USA jusqu’en 2013, aujourd'hui alternance
Amérique de Nord et Asie/Europe
Quelques dizaines au début à des milliers de
participants aujourd’hui
En parallèle : conférence (utilisateurs, décideurs) et
Forum (développeurs/opérateurs, remplace une
partie du précédent Design Summit)

4 . 41
EXEMPLE DU SUMMIT D’AVRIL 2013 À PORTLAND
Photo : Adrien Cunin

4 . 42
 EXEMPLE DU SUMMIT D’OCTOBRE 2015 À TOKYO

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

4 . 43
 EXEMPLE DU SUMMIT D’OCTOBRE 2015 À TOKYO

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

4 . 44
 EXEMPLE DU SUMMIT D’OCTOBRE 2015 À TOKYO

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

4 . 45
EXEMPLE DU SUMMIT D’OCTOBRE 2015 À TOKYO
Photo : Elizabeth K. Joseph, CC BY 2.0, Flickr/pleia2

4 . 46
 PROJECT TEAM GATHERING (PTG)
Depuis 2017
Au début de chaque cycle
Roadmap fonctionnelle et discussion de sujets
techniques
Remplace une partie du précédent Design Summit
Dédié aux développeurs, opérateurs et utilisateurs

4 . 47
 TRADUCTION
SIG officielle i18n
Seules certaines parties sont traduites, comme
Horizon
Utilisation d'une plateforme web basée sur Zanata :
[Link]

4 . 48
DEVSTACK : FAIRE TOURNER RAPIDEMENT UN OPENSTACK

4 . 49
 UTILITÉ DE DEVSTACK
Déployer rapidement un OpenStack
Utilisé par les développeurs pour tester leurs
changements
Utilisé pour faire des démonstrations
Utilisé pour tester les APIs sans se préoccuper du
déploiement
Ne doit PAS être utilisé pour de la production

4 . 50
 FONCTIONNEMENT DE DEVSTACK
Support d'Ubuntu, Debian, Fedora, CentOS/RHEL,
OpenSUSE
Un script shell qui fait tout le travail : [Link]
Un fichier de configuration : [Link]
Installe toutes les dépendances nécessaires (paquets)
Clone les dépôts git (branche master par défaut)
Lance tous les composants

4 . 51
 CONFIGURATION : [Link]
Exemple
[[local|localrc]]
ADMIN_PASSWORD=secrete
DATABASE_PASSWORD=$ADMIN_PASSWORD
RABBIT_PASSWORD=$ADMIN_PASSWORD
SERVICE_PASSWORD=$ADMIN_PASSWORD
SERVICE_TOKEN=a682f596-76f3-11e3-b3b2-e716f9080d50
#FIXED_RANGE=[Link]/24
#FLOATING_RANGE=[Link]/25
#HOST_IP=[Link]

4 . 52
 CONSEILS D’UTILISATION
DevStack installe beaucoup de paquets sur la
machine
Il est recommandé de travailler dans une machine
virtuelle
Pour tester tous les composants OpenStack dans de
bonnes conditions, plusieurs Go de RAM sont
nécessaires
L’utilisation de Vagrant est conseillée # Déployer
OpenStack

4 . 53
 CE QU’ON VA VOIR
Installer OpenStack à la main
[Link]
Donc comprendre son fonctionnement
Passer en revue chaque composant plus en détails
Tour d’horizon des solutions de déploiement

4 . 54
ARCHITECTURE SIMPLIFIÉE ET PRINCIPAUX COMPOSANTS

4 . 55
 ARCHITECTURE DÉTAILLÉE

Vue détaillée des services

4 . 56
ARCHITECTURE SERVICES
Machines "physiques" et services

4 . 57
 QUELQUES ÉLÉMENTS DE CONFIGURATION GÉNÉRAUX
Il s'agit de fournir un catalogue de services (APIs)
hautement disponibles
Tous les composants doivent être configurés pour
communiquer avec Keystone
La plupart doivent être configurés pour
communiquer avec MariaDB et RabbitMQ
Les composants découpés en plusieurs services ont
parfois un fichier de configuration par service
Le fichier de configuration [Link] précise les
droits nécessaires pour chaque appel API

4 . 58
 SYSTÈME D’EXPLOITATION
OS Linux avec Python
Ubuntu
Debian, Fedora, CentOS
Red Hat
SUSE

4 . 59
 PYTHON

Logo Python

OpenStack est compatible Python 2.7

Comptabilité Python 3 presque complète
Afin de ne pas réinventer la roue, beaucoup de
dépendances sont nécessaires

4 . 60
 BASE DE DONNÉES MARIADB
Permet de stocker la majorité des données gérées
par OpenStack
Chaque composant a sa propre base
OpenStack utilise l’ORM Python SQLAlchemy
Support théorique équivalent à celui de SQLAlchemy
(et support des migrations)
MariaDB est l’implémentation la plus largement
testée et utilisée
SQLite est principalement utilisé dans le cadre de
tests et démo
Certains déploiements fonctionnent avec
PostgreSQL

4 . 61
 PASSAGE DE MESSAGES
AMQP : Advanced Message Queuing Protocol
Messages, file d’attente, routage
Les processus OpenStack communiquent via AMQP
Plusieurs implémentations possibles : Qpid, 0MQ, etc.
RabbitMQ par défaut

4 . 62
 RABBITMQ

Logo RabbitMQ

RabbitMQ est implémenté en Erlang

Une machine virtuelle Erlang est donc nécessaire

4 . 63
 “HELLO WORLD” RABBITMQ

Illustration simple du fonctionnement de RabbitMQ

4 . 64
 CACHE MEMCACHED
Plusieurs services tirent parti d'un mécanisme de
cache
Memcached est l'implémentation par défaut

4 . 65
KEYSTONE : AUTHENTIFICATION, AUTORISATION ET CATALOGUE DE SERVICES

4 . 66
 INSTALLATION ET CONFIGURATION
Paquet APT : keystone
Intégration serveur web WSGI (Apache par défaut)
Fichier de configuration:
/etc/keystone/[Link]
Backends utilisateurs/groupes : SQL, LDAP (ou Active
Directory)
Backends projets/rôles/services/endpoints : SQL
Backends tokens : SQL, Memcache, aucun (suivant le
type de tokens)

4 . 67
DRIVERS POUR TOKENS
Uuid
PKI
Fernet

4 . 68
 BOOTSTRAP
Création des services et endpoints (à commencer par
Keystone)
Création d'utilisateurs, groupes, domaines
Fonctionnalité de bootstrap

4 . 69
NOVA : COMPUTE

4 . 70
 NOVA API
Double rôle
API de manipulation des instances par l’utilisateur
API à destination des instances : API de metadata
L’API de metadata doit être accessible à l’adresse
[Link]
L’API de metadata fournit des informations de
configuration personnalisées à chacune des
instances

4 . 71
 NOVA COMPUTE
Pilote les instances (machines virtuelles ou
physiques)
Tire partie de libvirt ou d’autres APIs comme XenAPI
Drivers : libvirt (KVM, LXC, etc.), XenAPI, VMWare
vSphere, Ironic
Permet de récupérer les logs de la console et une
console VNC

4 . 72
 NOVA SCHEDULER
Service qui distribue les demandes d’instances sur les
nœuds compute
Filter, Chance, Multi Scheduler
Filtres, par défaut :
AvailabilityZoneFilter,RamFilter,ComputeFilter
Tri par poids, par défaut : RamWeigher

4 . 73
 LE SCHEDULER NOVA EN ACTION

Fonctionnement de nova-scheduler

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

4 . 75
GLANCE : REGISTRE D’IMAGES

4 . 76
 BACKENDS
Swift ou S3
Ceph
HTTP
Répertoire local

4 . 77
 INSTALLATION
Paquet APT : glance-api

4 . 78
NEUTRON : RÉSEAU EN TANT QUE SERVICE

4 . 79
 PRINCIPES
Software Defined Networking (SDN)
Auparavant Quantum et nova-network
neutron-server : fournit l’API
Agent DHCP : fournit le service de DHCP pour les
instances
Agent L3 : gère la couche 3 du réseau, le routage
Plugin : LinuxBridge par défaut, d’autres
implémentations libres/propriétaires,
logicielles/matérielles existent

4 . 80
 FONCTIONNALITÉS SUPPLÉMENTAIRES
Outre 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é sans IP flottantes
Ces fonctionnalités se basent également sur des plugins

4 . 81
 PLUGINS ML2
Modular Layer 2
LinuxBridge
OpenVSwitch
OpenDaylight
Contrail, OpenContrail
Nuage Networks
VMWare NSX
cf. OpenFlow

4 . 82
 IMPLÉMENTATION
Chaque réseau est un bridge
Les bridges sont étendus entre les machines via des
tunnels (type VXLAN) si nécessaires
Neutron tire partie des namespaces réseaux du
noyau Linux pour permettre l’IP overlapping
Le proxy de metadata est un composant qui permet
aux instances isolées dans leur réseau de joindre l’API
de metadata fournie par Nova

4 . 83
SCHÉMA
Vue utilisateur du réseau

4 . 84
SCHÉMA
4 . 85
CINDER : STOCKAGE BLOCK

4 . 86
 PRINCIPES
Auparavant nova-volume
Fournit des volumes
Attachement des volumes via iSCSI par défaut

4 . 87
 INSTALLATION
Paquet cinder-api : fournit l’API
Paquet cinder-volume : création et gestion des
volumes
Paquet cinder-scheduler : distribue les demandes de
création de volume
Paquet cinder-backup (optionnel) : backup vers un
object store

4 . 88
 BACKENDS
Utilisation de plusieurs backends en parallèle
possible
LVM (par défaut)
GlusterFS
Ceph
Systèmes de stockage propriétaires type NetApp
DRBD

4 . 89
HORIZON : DASHBOARD WEB

4 . 90
 PRINCIPES
Horizon est un module Django
OpenStack Dashboard est l’implémentation officielle
de ce module
Généralement déployé sur les contrôleurs

Logo du framework web Python Django

4 . 91
 CONFIGURATION
local_settings.py
Les services apparaissent dans Horizon s’ils sont
répertoriés dans le catalogue de services de Keystone

4 . 92
SWIFT : STOCKAGE OBJET

4 . 93
 PRINCIPES
SDS : Software Defined Storage
Utilisation de commodity hardware
Théorème CAP : on en choisit deux
Architecture totalement acentrée
Pas de base de données centrale

4 . 94
 IMPLÉMENTATION
Proxy : serveur API par lequel passent toutes les
requêtes
Object server : serveur de stockage
Container server : maintient des listes d’objects dans
des containers
Account server : maintient des listes de containers
dans des accounts
Chaque objet est répliqué n fois (3 par défaut)

4 . 95
 LE RING
Problème : comment décider quelle donnée va sur
quel object server
Le ring est découpé en partitions
On situe chaque donnée dans le ring afin de
déterminer sa partition
Une partition est associée à plusieurs serveurs

4 . 96
 SCHÉMA

Architecture Swift

4 . 97
CEILOMETER : COLLECTE DE MÉTRIQUES

4 . 98
 SURVEILLER L’UTILISATION DE SON INFRASTRUCTURE AVEC CEILOMETER
Indexer et stocker différentes métriques concernant
l’utilisation des différents services du cloud
Fournir des APIs permettant de récupérer ces
données
Base pour construire des outils de facturation
(exemple : CloudKitty)

4 . 99
 CEILOMETER
Récupère les données et les stocke
Historiquement : stockage MongoDB
Aujourd'hui : stockage Gnocchi

4 . 100
 GNOCCHI : TIME-SERIES DATABASE
Pourquoi Gnocchi ? Palier aux problème de
scalabilité de Ceilometer + MongoDB
Initié par des développeurs de Ceilometer et intégré
à l’équipe projet Ceilometer
Fournit une API pour lire et écrire les données
Se base sur une BDD relationnelle et un système de
stockage objet

4 . 101
HEAT : ORCHESTRATION DES RESSOURCES

4 . 102
ARCHITECTURE
heat-api
heat-engine

4 . 103
QUELQUES AUTRES COMPOSANTS INTÉRESSANTS

4 . 104
 TROVE : DATABASE AS A SERVICE
trove-api : API
trove-taskmanager : gère les instances BDD
trove-guestagent : agent interne à l’instance

4 . 105
 DESIGNATE : DNS AS A SERVICE
Gère différents backends : BIND, PowerDNS, etc.

4 . 106
BARBICAN : KEY MANAGEMENT AS A SERVICE
Backends possibles :
Fichiers chiffrés
PKCS#11
KMIP
Dogtag

4 . 107
MAGNUM : CONTAINER INFRASTRUCTURE AS A SERVICE
Backends: Swarm, Kubernetes

4 . 108
OPENSTACK EN PRODUCTION ET OPÉRATIONS

5.1
BONNES PRATIQUES POUR UN DÉPLOIEMENT EN PRODUCTION

5.2
 QUELS COMPOSANTS DOIS-JE INSTALLER ?
Keystone est indispensable
L’utilisation de Nova va de paire avec Glance et
Neutron
Cinder et Swift s'apprécient en fonction des besoins
de stockage
Swift peut être utilisé indépendemment des autres
composants
Heat coûte peu
Les services plus haut niveau s'évaluent au cas par
cas
[Link]
5.3
 PENSER DÈS LE DÉBUT AUX CHOIX STRUCTURANTS
Distribution et méthode de déploiement
Politique de mise à jour
Drivers/backends : hyperviseur, stockage block, etc.
Réseau : quelle architecture et quels drivers

5.4
 LES DIFFÉRENTES MÉTHODES D’INSTALLATION
DevStack est à oublier pour la production
Le déploiement à la main comme vu précédemment
n’est pas recommandé car peu maintenable
Distributions OpenStack packagées et prêtes à
l’emploi
Distributions classiques et gestion de configuration
Déploiement continu

5.5
 MISES À JOUR ENTRE VERSIONS MAJEURES
OpenStack supporte les mises à jour N → N+1
Swift : très bonne gestion en mode rolling upgrade
Autres composants : tester préalablement avec vos
données
Lire les release notes
Cf. articles de blog du CERN
[Link]

5.6
 MISES À JOUR DANS UNE VERSION STABLE
Fourniture de correctifs de bugs majeurs et de
sécurité
OpenStack intègre ces correctifs sous forme de
patchs dans la branche stable
Publication de point releases intégrant ces correctifs
issus de la branche stable
Durée variable du support des versions stables,
dépendant de l’intérêt des intégrateurs

5.7
 ASSIGNER DES RÔLES AUX MACHINES
Beaucoup de documentations font référence à ces rôles :
Controller node : APIs, BDD, AMQP
Network node : DHCP, routeur, IPs flottantes
Compute node : Hyperviseur/pilotage des instances
Ce modèle simplifié n’est pas HA.

5.8
 HAUTE DISPONIBILITÉ
Haute disponibilité du IaaS
MySQL/MariaDB, RabbitMQ : HA classique (Galera,
Clustering)
Les services APIs sont stateless et HTTP : scale out et
load balancers
La plupart des autres services OpenStack sont
capables de scale out également
Guide HA : [Link]
Conférences par Florian Haas, City Network :
[Link]
haas

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

5 . 10
 CONSIDÉRATIONS APIS
Des URLs uniformes pour toutes les APIs :
Utiliser un reverse proxy
Mettre à jour le catalogue de services
Apache/mod_wsgi pour servir les APIs lorsque cela
est possible (Keystone, etc.)
Guide Operations : [Link]
ops/content/

5 . 11
 DÉCOUPAGE RÉSEAU
Management network : réseau d’administration
Data/instances network : réseau pour la
communication inter instances
External network : réseau externe, dans
l’infrastructure réseau existante
Storage network : réseau pour le stockage
Cinder/Swift
API network : réseau contenant les endpoints API

5 . 12
 CONSIDÉRATIONS LIÉES À LA SÉCURITÉ
Indispensable : HTTPS sur l’accès des APIs à
l’extérieur
Sécurisation des communications MySQL/MariaDB et
RabbitMQ
Un accès MySQL/MariaDB par base et par service
Un utilisateur Keystone par service
Limiter l’accès en lecture des fichiers de
configuration (mots de passe, token)
Veille sur les failles de sécurité : OSSA ( OpenStack
Security Advisory), OSSN ( ... Notes)
Guide sécurité : [Link]
guide/
5 . 13
 SEGMENTER SON CLOUD
Host aggregates : machines physiques avec des
caractéristiques similaires
Availability zones : machines dépendantes d’une
même source électrique, d’un même switch, d’un
même DC, etc.
Regions : chaque région a son API
Cells : permet de regrouper plusieurs cloud différents
sous une même API

5 . 14
 HOST AGGREGATES / AGRÉGATS D’HÔTES
Spécifique Nova
L’administrateur définit des agrégats d’hôtes via l’API
L’administrateur associe flavors et agrégats via des
couples clé/valeur communs
1 agrégat ≡ 1 point commun, ex : GPU
L’utilisateur choisit un agrégat à travers son choix de
flavor à la création d’instance

5 . 15
 AVAILABILITY ZONES / ZONES DE DISPONIBILITÉ
Spécifique Nova et Cinder
Groupes d’hôtes
Découpage en termes de disponibilité : Rack,
Datacenter, etc.
L’utilisateur choisit une zone de disponibilité à la
création d’instance
L’utilisateur peut demander à ce que des instances
soient démarrées dans une même zone, ou au
contraire dans des zones différentes

5 . 16
 RÉGIONS
Générique OpenStack
Équivalent des régions d’AWS
Un service peut avoir différents endpoints dans
différentes régions
Chaque région est autonome
Cas d’usage : cloud de grande ampleur (comme
certains clouds publics)

5 . 17
 CELLS / CELLULES
Spécifique Nova
Un seul nova-api devant plusieurs cellules
Chaque cellule a sa propre BDD et file de messages
Ajoute un niveau de scheduling (choix de la cellule)

5 . 18
 PACKAGING D’OPENSTACK - UBUNTU
Le packaging est fait dans de multiples distributions,
RPM, DEB et autres
Ubuntu est historiquement la plateforme de
référence pour le développement d’OpenStack
Le packaging dans Ubuntu suit de près le
développement d’OpenStack, et des tests
automatisés sont réalisés
Canonical fournit la Ubuntu Cloud Archive, qui met à
disposition la dernière version d’OpenStack pour la
dernière Ubuntu LTS

5 . 19
 UBUNTU CLOUD ARCHIVE (UCA)

Support d'OpenStack dans Ubuntu via l'UCA

5 . 20
 PACKAGING D’OPENSTACK DANS LES AUTRES DISTRIBUTIONS
OpenStack est intégré dans les dépôts officiels de
Debian
Red Hat propose RHOS/RDO (déploiement basé sur
TripleO)
Comme Ubuntu, le cycle de release de Fedora est
synchronisé avec celui d’OpenStack

5 . 21
 TRIPLEO
OpenStack On OpenStack
Objectif : pouvoir déployer un cloud OpenStack
(overcloud) à partir d’un cloud OpenStack
(undercloud)
Autoscaling du cloud lui-même : déploiement de
nouveaux nœuds compute lorsque cela est
nécessaire
Fonctionne conjointement avec Ironic pour le
déploiement bare-metal

5 . 22
 DÉPLOIEMENT BARE-METAL
Le déploiement des hôtes physiques OpenStack peut
se faire à l’aide d’outils dédiés
MaaS (Metal as a Service), par Ubuntu/Canonical : se
couple avec Juju
Crowbar / OpenCrowbar (initialement Dell) : utilise
Chef
Ironic via TripleO

5 . 23
 GESTION DE CONFIGURATION
Ansible, Puppet, Chef, CFEngine, Saltstack, etc.
Ces outils peuvent aider à déployer le cloud
OpenStack
... mais aussi à gérer les instances (section suivante)

5 . 24
 MODULES PUPPET, PLAYBOOKS ANSIBLE
Puppet OpenStack et OpenStack Ansible : modules
Puppet et playbooks Ansible
Développés au sein du projet OpenStack
[Link]
[Link]

5 . 25
 DÉPLOIEMENT CONTINU
OpenStack maintient un master (trunk) toujours
stable
Possibilité de déployer au jour le jour le master (CD :
Continous Delivery)
Nécessite la mise en place d’une infrastructure
importante
Facilite les mises à jour entre versions majeures

5 . 26
 TEST ET VALIDATION : TEMPEST
Suite de tests d’un cloud OpenStack
Effectue des appels à l’API et vérifie le résultat
Est très utilisé par les développeurs via l’intégration
continue
Le déployeur peut utiliser Tempest pour vérifier la
bonne conformité de son cloud
Cf. aussi Rally

5 . 27
GÉRER LES PROBLÈMES

5 . 28
 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
peut cacher certaines informations)
Si nécessaire d’aller plus loin :
Regarder les logs sur le(s) contrôleur(s)
(/var/log/<composant>/*.log)
Regarder les logs sur le compute node et le
network/controller node si le problème est
spécifique réseau/instance
Éventuellement modifier la verbosité des logs
dans la configuration

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

5 . 30
OPÉRATIONS

5 . 31
 GESTION DES LOGS
Centraliser les logs
Logs d'API
Logs autres composants OpenStack
Logs BDD, AMQP, etc.

5 . 32
 BACKUP
Bases de données
Mécanisme de déploiement, plutôt que backup des
fichiers de configuration

5 . 33
 MONITORING
Réponse des APIs
Vérification des services OpenStack et dépendances

5 . 34
 UTILISATION DES QUOTAS
Limiter le nombre de ressources allouables
Par utilisateur ou par projet
Support dans Nova
Support dans Cinder
Support dans Neutron

5 . 35
CONCLUSION

6.1
 POUR CONCLURE
Le cloud révolutionne l’IT
OpenStack est le projet libre phare sur la partie IaaS
Déployer OpenStack n’est pas une mince affaire
L’utilisation d’un cloud IaaS implique des
changements de pratique
Les métiers d’architecture logicielle et infra évoluent

6.2