OpenStack 1 Introduction

POUR DES COMPÉTENCES TOUJOURS À LA POINTE
Introduction à
Openstack
Emmanuel Braux
Institut Mines Telecom / IMT Atlantique
emmanuel.braux@imt-atlantique.fr
Institut Mines-Télécom
Objectifs
 Connaitre le fonctionnement du projet OpenStack

et ses possibilités
 Comprendre le fonctionnement de chacun des
composants d’OpenStack
2 Institut Mines-Télécom Introduction à Openstack

Plan
Introduction à Openstack
 Définitions
 L’écosystème OpenStack
 L’architecture
 Les sous-Projets
 Les Grands Principes d’utilisation
 Premiers pas

► Définitions
L’écosystème OpenStack
L’architecture
Les sous-Projets
Les Grands Principes d’utilisation
Premiers pas

Définitions
 Wikipédia
OpenStack est un ensemble de logiciels open source
permettant de déployer des infrastructures de cloud Computing
(IaaS).
 Openstack.org
OpenStack is a cloud operating system that controls large
pools of compute, storage, and networking resources
throughout a datacenter, all managed through a dashboard that
gives administrators control while empowering their users to
provision resources through a web interface.

Framework Iaas Modulaire
 Iaas
• Infrastructure libre service, à la demande
 Framework
• Ensemble de composants logiciels
• Bases d'une infrastructure IT
 Modulaire
• un ensemble de modules, pas tous nécessaires
• chaque module peut être configuré en fonction de besoins
• chaque module peut-être étendu (drivers)

Définitions
► L’écosystème OpenStack
L’architecture
Les sous-Projets
Premiers pas

Définitions
► Historique
Gouvernance
Communauté
Packaging
Développement
L’architecture
Les sous-Projets
Premiers pas
Historique
2010 : Rackspace Hosting + NASA

lancent un projet communautaire et
Open source
Objectif : créer et offrir des

services de Cloud Computing
avec du matériel standard
Introduction à
Openstack
Institut Mines-Télécom 9
Cycle de vie des versions
 2 releases annuelles,
 1 version « stable, »
 2 versions « supportées »
https://www.objectif-libre.com/fr/
Releases Timeline
https://releases.openstack.org/
Définitions
Historique
► Gouvernance
Communauté
Packaging
Développement
L’architecture
Les sous-Projets
Premiers pas
La fondation OpenStack
 Créé en 2012
 Entité indépendante de gouvernance principale du projet
 Les membres du « board of directors » sont issus des
entreprises sponsors et élus par les membres individuels
 Tout le monde peut devenir membre individuel
(gratuitement)
 Supporte le projet par différents moyens :
• Evénements : organisation (Summits) ou participation (OSCON,
etc.)
• Infrastructure de développement (serveurs)
• Ressources humaines : marketing, release manager, quelques
développeurs (principalement sur l’infrastructure)
 Plus de 850 organisations à travers le monde
 Plus de 9500 membres individuels dans 100 pays

OpenStack Nation
“define and steward the “provides strategic and “represent a broad set
technical direction of financial oversight of of enterprise, academic
OpenStack” Foundation resources and service provider
and staff”. users”
https://www.openstack.org/foundation/
OpenStack Summit
 Aux USA jusqu’en 2013

 Aujourd’hui : alternance USA et Asie/Europe
 Quelques centaines au début à 4500 de
participants aujourd’hui
 En parallèle : conférence (utilisateurs, décideurs)
et Design Summit (développeurs)
 Détermine le nom de la release : lieu/ville à
proximité du Summit

Définitions
Historique
Gouvernance
► Communauté
Packaging
Développement
L’architecture
Les sous-Projets
Premiers pas
Quelques soutiens/contributeurs
 Rackspace et la NASA
 Canonical, Red Hat, Suse, HP, IBM, Dell, Intel
 Huawei, Cisco, Juniper,
 NetApp, VMWare
 Yahoo, Bull
 Mirantis, StackOps, …
 …
https://www.openstack.org/foundation/companies/

... et utilisateurs
 Tous les contributeurs précédemment cités

 CloudWatt (Orange) et Numergy (SFR)
 CERN,
 Wikimedia
 Paypal, Comcast, Etc.
 Sans compter les implémentations confidentielles
 …
https://www.openstack.org/user-stories/

Définitions
Historique
Gouvernance
Communauté
► Packaging
Développement
L’architecture
Les sous-Projets
Premiers pas
Packaging : 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

Les autres distributions
 OpenStack est intégré dans les dépôts officiels

de Debian
 Red Hat est très actif dans la communauté, et
propose :
• Une distribution avec support : RHOS
• le cycle de release de Fedora est synchronisé avec
celui d’OpenStack
 StackOps
 Mirantis
 HP, Nokia, Ericsson, …
https://www.openstack.org/marketplace/distros/

Définitions
Historique
Gouvernance
Communauté
Packaging
► Développement
L’architecture
Les sous-Projets
Premiers pas
Développement
 Python
 Ouvert à tous (individuels et entreprises)
 Cycle de développement de 6 mois débuté par un
(design) summit, et Planning public
 Outils :
• Launchpad (blueprints, bugs) + Git (développement) +
GitHub (diffusion des sources)
• Sur chaque commit : peer review (Gerrit) + intégration
continue
• Exécution de différents tests par Jenkins
• Plateforme de référence et modèle de développement :
Ubuntu

Informations
 Principalement sur le wiki : https://wiki.openstack.org

 Le planning : https://releases.openstack.org/
 Les blueprints et bugs : https://launchpad.net/openstack
 Les patchs et leurs reviews : https://review.openstack.org
 Le code : https://git.openstack.org
 Les sources (tarballs) : http://tarballs.openstack.org/
 Les statistiques :
http://stackalytics.com/?release=queens

Statistiques company contributions
http://stackalytics.com/?release=train
Statistiques Modules contributions
http://stackalytics.com/?release=train
Stackforge
 Forge pour les nouveaux projets en lien avec

OpenStack
 Bénéficient de l’infrastructure du projet
OpenStack, mais la séparation reste claire
 Les projets démarrent dans Stackforge et peuvent
ensuite rejoindre le projet OpenStack
https://github.com/stackforge

Définitions
► L’architecture
Les sous-Projets
Premiers pas

Design Tenets
1. Scalability and elasticity are our main goals

2. Any feature that limits our main goals must be optional
3. Everything should be asynchronous (If you can’t do
something asynchronously, see #2)
4. All required components must be horizontally scalable
5. Always use “shared nothing architecture (SN)” or
“sharding” (If you can’t Share nothing/shard, see #2)
6. Distribute everything (Especially logic. Move logic to
where state naturally exists)
7. Accept “eventual consistency” and use it where it is
appropriate.
8. Test everything. We require tests with submitted code

Technologies mises en œuvre
 Approche « micro-services »
 Communications inter-services via API
(synchrone) limitées
 Utilisation massive de commandes par messages
(AMPQ)
 Une base de donnée par services
 Majorité de services sans états (state-less)

Pour résumer
 Des composants indépendants

 Qui dialoguent entre eux via une file d'attente
(RabitMQ, protocole AMQP)
 Et qui peuvent échanger des informations via les
API qu'ils exposent

Composants principaux
 Composants Individuels et autonomes

Aperçu : pour un utilisateur

Ce que ça cache …
http://docs.openstack.org/ops-guide/architecture.html
Zoom …
Introduction à
Openstack
Institut Mines-Télécom 35
Grands principes d’ implémentation
 Développement en Python (Django pour Horizon)

 Réutilisation de composants existants
 Tous les composants doivent être configurés pour
communiquer avec le référentiel central (keystone)
 La plupart doivent être configurés pour communiquer
avec le gestionnaire message (RabbitMQ)
 Chaque sous-projet est découpé en plusieurs services
 Un fichier de configuration par service
 Toutes les fonctionnalités doivent être accessibles par
l’API

Définitions
L’architecture
► Les sous-Projets
Les Grands Principes
d’utilisation
Premiers pas

Définitions
L’architecture
Les sous-Projets
► "Core", "Big tent" et "Tools"
Détail des principaux projets
Premiers pas

Les sous-projets « Core »
 Indispensables :
• Gestion/execution des instances (Compute) : Nova
• Authentification, Autorisations (Identity Service) :
Keystone
• Catalogue de services : Keystone
• Registre d’images (Image Service) : Glance
• Réseau (Networking) : Neutron
 Stockage :
• Stockage block (Block Storage) : Cinder
• Stockage objet (Object Storage ) : Swift

Sous-projets « Big Tent »
 Suivi / management
• Console web (Dashboard) : Horizon
• Orchestration des ressources (Orchestration) : Heat
• Collecte de métriques (Metering) : Ceilometer
 Données
• Bases de données : Trove
• Traitement de masse : Sahara
...

« Big Tent » et « Core »

Panorama des composants d’OpenStack
https://www.openstack.org/software/

Evolution
https://fr.wikipedia.org/wiki/OpenStack
Evolution : accélération …
https://fr.wikipedia.org/wiki/OpenStack
Maturité / Statistiques
https://www.openstack.org/software/project-navigator

CORRESPONDANCE OPENSTACK -
AWS
 Compute : EC2 → Nova

 Block storage : EBS → Cinder
 Object storage : S3 → Swift
 Orchestration : CFN → Heat
 DNS : Route53 → Designate
 …

Sous-projets « Tools »
 Oslo (ou OpenStack common) :

• contient le code commun à plusieurs composants d’OpenStack
• Son utilisation est transparente pour le déployeur
 rootwrap
• wrapper pour les commandes root utilisée par les projets
 TripleO
• OpenStack On OpenStack
• Objectif : pouvoir déployer un cloud OpenStack (overcloud) à
partir d’un cloud OpenStack (undercloud)
 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
 …

Définitions
L’architecture
Les sous-Projets
"Core", "Big tent" et "Tools"
► Détail des principaux projets
Premiers pas

Keystone (identity)
 Service de renseignements (utilisateurs, groupes,

projets. . . )
 Authentifie les utilisateurs en leur donnant des
jetons
 Valide l’authenticité d’un jeton
 Dépositaire du catalogue de service

Nova (compute)
 Gère le catalogue des instances
 Traite les demandes de création d’instance (en relation
avec l’hyperviseur)
 Gère le placement des instances sur les noeuds compute
 Fournit les métadonnées (systèmes et utilisateurs) aux
instances
 Assure des fonctions réseaux (limitées : création de
bridge, DHCP, firewall. . . ), bientôt abandonnées.
 Fournit un accès aux instances (console, VNC, Spice. . . )
 KVM, Xen, ESX, Hyper-V, Docker et LXC

Glance (images)
 Service « images» de l’infrastructure virtualisée

 Stocke et distribue les images d’instance
 Appelé par Compute (Nova) lors de l’instanciation
d’une nouvelle Instance.
 Format des images : raw, vmdk, qcow , iso, …
 Gère les métadonnées des images (type, OS,
architecture. . . )
 Plusieurs backend de stockage :
• Système de fichier local ou NFS (NAS/SAN)
• Swift (OpenStack Object Service)
• S3 (Object Service Amazon)
• Ceph

Neutron (Network)
 Virtualisation du réseau
 API Unifiée, pour piloter plusieurs architectures
réseau :
• Linux Bridge,
• OpenVSwitch
• SDN (Software-Defined Network) : OpenContrail,
OpenDaylight, Cisco Nexus1000, VmWare NSX, …

Horizon (dashboard)
 Interface web
 Fournit une interface graphique pour gérer les
ressources
 Permet de surveiller l’utilisation des ressources

Choix et contraintes sur les composants
 Keystone est indispensable

 L’utilisation de Nova va de paire avec Glance
 Nova propose une couche réseau simpliste, mais
souvent suffisante
 Neutron est puissant, mais complexe
 Cinder s’avèrera souvent utile
 Ceilometer et Heat vont souvent ensemble
 Swift est indépendant des autres composants

Définitions
L’architecture
Les sous-Projets
► Les Grands Principes d’utilisation
Premiers pas

Grands principes d’utilisation
 Les instances sont éphémères, les données sont

persistantes
 On est prêt à perdre l'instance, mais pas le
service.
 Les données doivent être stockée sur un
stockage persistant.
 Il faut séparer les données des instances
 Une instance doit être utilisée comme ressource
de calcul
 Une image se personnalise lors de son
instanciation grâce à l’API de metadata

Les instances
 Image : le master, généralement un OS bootable et

“cloud ready”.
 Instance : forme dynamique d’une image (la VM).
 Gabarit (flavor) : Type d’instance, mensurations (cpu,
ram, capacité disque,...).
On lance une instance à partir d’une image, en lui

affectant des ressources via un gabarit.
57 Institut Mines-Télécom Cloud et Openstack - Introduction

Configuration des instances
 Des métadonnées sont associées aux différents objets

• Metadata : définie par le système
• Userdata : définie par l’utilisateur
 Cloud-init : mécanisme de personnalisation des
instances lors de la création
Une image se configure/personnalise lors de son

instanciation grâce à l’API de metadata, et le
mécanisme Cloud-Init

Les volumes
 Volume : espace de stockage persistant. Peut être de

type bloc ou objet.
 Une instance est éphémère. C’est une ressource de

calcul.
 Les données sont persistantes.
Il faut séparer les données des instances, et les

stocker sur un stockage persistant : un volume

Le réseau
 IP Fixe : adresse IP « interne » associée à chaque instance »

 IP flottantes (Floating IP) : adresse IP allouée à la demande
et utilisée pour communiquer avec le réseau “externe”.
 Groupe de sécurité (Security groups) : ensemble de règles
de filtrage de flux appliqué à l’entrée des instances.
Pour pouvoir accéder à une instance, il faut lui

affecter une IP flottante, et définir des règles de
sécurité.

Connection aux instances
 Paire de clés (Keypairs) : clé privée + clé publique

permettant les connexions aux instances via SSH.
On n’utilise plus de mot de passe pour se connecter

aux instances, mais des paires de clés.

Gestion des utilisateurs
 Projet (Project/Tenant) : unité d’appartenance de base

= propriétaire des ressources.
 Utilisateur (User) : compte autorisé à utiliser les API
 Quota : contrôle l’utilisation des ressources (vcpu,
ram, fip, security groups,...) dans un projet
On associe les ressources à un projet, via des

quotas.
Les utilisateurs deviennent membre des projets.

Cycle de vie des instances et continuité
de service
 Stack : ensemble des ressources IaaS utilisées par une

application.
 Infrastructure « as code » : les stacks sont décrits
dans des fichiers (yaml, python, …), et sont de
préférence placé en gestion de version Infrastructure
« jetable » : tout ce qui est déployé doit pouvoir être
redéployé, dupliqué, …
On est prêt à perdre une instance mais pas le

service. C’est l’application doit assurer la continuité
du service, pas (plus) l’infrastructure.

Accès aux services
 APIs REST : Interface permettant à un logiciel

d’utiliser un service ou une bibliothèque, via des
requêtes HTTP
 Endpoint : URL permettant l’accès à une API. Un
endpoint par service.
 Catalogue de services : services disponibles et
accessibles via les API.
Toutes les opérations peuvent être réalisées par des

appels via les API REST.

Définitions
L’architecture
Les sous-Projets
► Premiers pas

La console : Horizon

Les APIs
 Les clients (y compris Horizon) utilisent l’API

 Des crédentials sont nécessaires
• utilisateur + mot de passe + projet
 Direct, en HTTP, via des outils comme curl
 Avec une bibliothèque
• Les implémentations officielles en Python
• D’autres implémentations pour d’autres langages
(exemple : jclouds)

Les clients
 Des clients en ligne de commande :

• python-<service>client
 Bibliothèques Python
 L’authentification se fait en passant les
« credentials » par paramètres ou variables
d’environnement
 S’appuie sur les API
• L’option « --debug » affiche la communication HTTP

Démarrer avec Openstack
 Devstack
• http://docs.openstack.org/developer/devstack/
• “a series of extensible scripts used to quickly bring up a
complete OpenStack environment”
• Ubuntu, RedHat
 Packstack
• https://www.rdoproject.org/install/packstack/
• “installation utility that lets you spin up a proof of concept cloud
on one node”
• RedHat
 Offres providers :
• https://www.citycloud.com/get-free-trials-on-openstack-clouds-
across-the-world/ http://trystack.org/ : 100$ / 1 mois
• …
https://www.openstack.org/software/start/

En conclusion
 projet Opensource, viable, géré par une large

communauté
 Rythme Évolution rapide
 Ensemble de briques
 Architecture complexe
 Compétences variées (système, réseau,
développement, …)

Auteur : emmanuel.braux@imt-atlantique.fr
Cette présentation est sous License Créative Commons

3.0 France (CC BY-NC-SA 3.0 FR)
Selon les options : Attribution - Pas d’Utilisation
Commerciale - Partage dans les Mêmes Conditions.
http://creativecommons.fr/licences
71 Institut Mines-Télécom Openstack -Installation

OpenStack 1 Introduction

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

OpenStack 1 Introduction

Transféré par

Droits d'auteur :

Formats disponibles

POUR DES COMPÉTENCES TOUJOURS À LA POINTE

 Connaitre le fonctionnement du projet OpenStack

2 Institut Mines-Télécom Introduction à Openstack

3 Institut Mines-Télécom Introduction à Openstack

4 Institut Mines-Télécom Introduction à Openstack

5 Institut Mines-Télécom Introduction à Openstack

6 Institut Mines-Télécom Introduction à Openstack

7 Institut Mines-Télécom Introduction à Openstack

2010 : Rackspace Hosting + NASA

Objectif : créer et offrir des

13 Institut Mines-Télécom Introduction à Openstack

 Aux USA jusqu’en 2013

15 Institut Mines-Télécom Introduction à Openstack

17 Institut Mines-Télécom Introduction à Openstack

 Tous les contributeurs précédemment cités

18 Institut Mines-Télécom Introduction à Openstack

 Le packaging est fait dans de multiples

20 Institut Mines-Télécom Introduction à Openstack

 OpenStack est intégré dans les dépôts officiels

21 Institut Mines-Télécom Introduction à Openstack

23 Institut Mines-Télécom Introduction à Openstack

 Principalement sur le wiki : https://wiki.openstack.org

24 Institut Mines-Télécom Introduction à Openstack

 Forge pour les nouveaux projets en lien avec

27 Institut Mines-Télécom Introduction à Openstack

28 Institut Mines-Télécom Introduction à Openstack

1. Scalability and elasticity are our main goals

29 Institut Mines-Télécom Introduction à Openstack

30 Institut Mines-Télécom Introduction à Openstack

 Des composants indépendants

31 Institut Mines-Télécom Introduction à Openstack

 Composants Individuels et autonomes

32 Institut Mines-Télécom Introduction à Openstack

33 Institut Mines-Télécom Introduction à Openstack

 Développement en Python (Django pour Horizon)

36 Institut Mines-Télécom Introduction à Openstack

37 Institut Mines-Télécom Introduction à Openstack

38 Institut Mines-Télécom Introduction à Openstack

39 Institut Mines-Télécom Introduction à Openstack

40 Institut Mines-Télécom Introduction à Openstack

41 Institut Mines-Télécom Introduction à Openstack

42 Institut Mines-Télécom Introduction à Openstack

45 Institut Mines-Télécom Introduction à Openstack

 Compute : EC2 → Nova

46 Institut Mines-Télécom Introduction à Openstack

 Oslo (ou OpenStack common) :

47 Institut Mines-Télécom Introduction à Openstack

48 Institut Mines-Télécom Introduction à Openstack

 Service de renseignements (utilisateurs, groupes,

49 Institut Mines-Télécom Introduction à Openstack

50 Institut Mines-Télécom Introduction à Openstack

 Service « images» de l’infrastructure virtualisée

51 Institut Mines-Télécom Introduction à Openstack

52 Institut Mines-Télécom Introduction à Openstack

53 Institut Mines-Télécom Introduction à Openstack

 Keystone est indispensable

54 Institut Mines-Télécom Introduction à Openstack

55 Institut Mines-Télécom Introduction à Openstack

 Les instances sont éphémères, les données sont

56 Institut Mines-Télécom Introduction à Openstack

 Image : le master, généralement un OS bootable et

On lance une instance à partir d’une image, en lui

57 Institut Mines-Télécom Cloud et Openstack - Introduction