Cours Openstack Partie1-2 PDF

M211 - Implémenter un environnement Cloud
avec une solution libre
Introduction à
Openstack
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 ID Cloud Computing Introduction à Openstack

Sommaire de module
 Mettre en service OpenStack

 Explorer les services de base d’OpenStack
 Explorer les services avancés d’OpenStack
 Déployer des services d’OpenStack

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

Introduction

Les produits de cloud propriétaires
Introduction à
Openstack
ID Cloud Computing 9
Les produits de cloud propriétaires
Introduction à
Openstack
► 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 est un système d'exploitation cloud qui contrôle de
grands pools de ressources de calcul, de stockage et de mise en
réseau dans un centre de données, le tout géré via un tableau de
bord qui donne aux administrateurs le contrôle tout en
permettant à leurs utilisateurs de provisionner des ressources via
une interface Web.

Framework Iaas Modulaire
OpenStack est avant tout un "framework cloud modulaire"
permettant l’implémentation d’une infrastructure IT
scalable :
 Framework
• Ensemble de composants logiciels
• Bases d'une infrastructure IT
 Cloud (IaaS)
• Infrastructure libre service, à la demande
 Modulaire
• un ensemble de modules, pas tous nécessaires
• chaque module peut être configuré en fonction de besoins
• chaque module peut-être étendu (drivers)
0
Définitions
► L’écosystème OpenStack
L’architecture
Les sous-Projets
Premiers pas

1
Définitions
► Historique
Gouvernance
Communauté
Packaging
Développement
L’architecture
Les sous-Projets
Premiers pas
2
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
Cycle de vie des versions
 2 releases annuelles,
 1 version « stable, »
 2 versions « supportées »
2018 2019 2020 2021 2022
18 fev. 10 Avr. 13 Mai. 14 Avr. 30 Mai.

Queens Stein Ussuri Wallaby Yoga
30 aout 30 aout 16 Oct. 14 Oct. 6 Oct. 5 Oct.
Pike Rocky Train Victoria Xena Zed
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
“définir et superviser la “assure la supervision “représentent un large

direction technique stratégique et financière éventail d'utilisateurs
d'OpenStack” des ressources et du d'entreprises, d'universités
personnel de la Fondation”. et de fournisseurs de
services”
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
G ouvernance
► 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
G ouvernance
C ommunauté
► 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 : R HOS
• 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
G ouvernance
C ommunauté
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) + G it (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://stackal
ytics.com/?r
elease=train
Statistiques Modules contributions

Stackforge
 Un forum pour les projets relatifs à OpenStack

 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

Principes de conception
1. L'évolutivité et l'élasticité sont nos principaux objectifsToute

fonctionnalité qui limite nos objectifs principaux doit être facultative
2. Tout doit être asynchrone (si vous ne pouvez pas faire quelque chose
de manière asynchrone, voir #2)
3. Tous les composants requis doivent être évolutifs horizontalement
4. Utilisez toujours "l'architecture sans partage (SN)" ou le "sharding" (si
vous ne pouvez rien partager/fragment, voir #2)
5. Distribuez tout (en particulier la logique. Déplacez la logique là où
l'état existe naturellement)
6. Acceptez la « cohérence éventuelle » et utilisez-la là où elle est
appropriée.
7. Testez tout. Nous avons besoin de tests avec le code soumis

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
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
• C atalogue de services : Keystone
• Registre d’images (Image Service) : Glance
• R éseau (Networking) : Neutron
 Stockage :
• S tockage block (Block S torage) : Cinder
• S tockage objet (Object S torage ) : Swift

Sous-projets « Big Tent »
 Suivi / management
• C onsole 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 …
Evolution : accélération …
Maturité / Statistiques
https://www.openstack.org/software/project-navigator

CORRESPONDANCE OPENSTACK - AWS

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)
• S 3 (Object S ervice Amazon)
• Ceph

Neutron (Network)
 Virtualisation du réseau
 API Unifiée, pour piloter plusieurs architectures
réseau :
• Linux Bridge,
• OpenVSwitch
• S DN (S oftware-Defined Network) : OpenC ontrail,
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.
62 ID Cloud Computing C loud 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, …)

DEVSTACK : FAIRE TOURNER
RAPIDEMENT UN OPENSTACK
5 . 45
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
5 . 46
FONCTIONNEMENT DE DEVSTACK
Support d'Ubuntu 18.04/22.04, Fedora 24/25, CentOS/RHEL 7,

Debian,OpenSUSE
Un script shell qui fait tout le travail :stack.sh
Un fichier de configuration :local.conf
Installe toutes les dépendances nécessaires (paquets)
Clone les dépôts git (branche master par défaut)
Lance tous les composants
5 . 47
CONFIGURATION : LOCAL.CONF
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=172.31.1.0/24
#FLOATING_RANGE=192.168.20.0/25
#HOST_IP=10.3.4.5
5 . 48
CONSEILS D’UTILISATION
DevStack installe beaucoup de choses sur la machine

Il est recommandé de travailler dans une VM
Pour tester tous les composants OpenStack dans de bonnes
conditions,plusieurs Go de RAM sont nécessaires
L’utilisation de Vagrant est conseillée
LE PRINCIPE
Toutes les fonctionnalités sont accessibles par l’API

Les clients (y compris Horizon) utilisent l’API
Des crédentials sont nécessaires,avec l'API OpenStack
:
utilisateur
mot de passe
projet (tenant)
domaine
LES APIS OPENSTACK
Une API par service OpenStack

Versionnée, la rétro-compatibilité est assurée
Le corps des requêtes et réponses est formatté avec
JSON
Architecture REST
Les ressources gérées sont spécifiques à un projet
https://developer.openstack.org/#api
ACCÈS AUX APIS
Direct, en HTTP, via des outils comme curl

Avec une bibliothèque
Les implémentations officielles en Python
OpenStackSDK
D’autres implémentations,y compris pour d’autres langages
(exemple :jclouds)
Shade (bibliothèque Python incluant la business logic)
Avec les outils officiels en ligne de commande
Avec Horizon
Au travers d'outils tiers, plus haut niveau (exemple :
Terraform)
CLIENTS OFFICIELS
OpenStack fournit des clients officiels

Historiquement :pyt hon-PROJETclient (bibliothèque
Python et CLI)
Aujourd'hui :openst ackclient (CLI)
Outils CLI
L’authentification se fait en passant les crédentials par
paramètres,variables d’environnement ou fichier de
configuration
L’option --debug affiche la communication HTTP
OPENSTACK CLIENT
Client CLI unifié

Commandes du type
openstack < res so ur ce > < a c t i o n > (shell interactif
disponible)
Vise à remplacer les clients CLI spécifiques
Permet une expérience utilisateur plus homogène
Fichier de configuration clouds.yam l
https://docs.openstack.org/python-
openstackclient/latest/configuration/index.html#configuration-
files
KEYSTONE : AUTHENTIFICATION, AUTORISATION ET
CATALOGUE DE SERVICES
PRINCIPES
Keystone est responsable de l'authentification,

l'autorisation et le catalogue de services.
L'utilisateur standard s'authentifie auprès de
Keystone L'administrateur intéragit régulièrement
avec Keystone
API
API v3 :port 5000

Gère :
Utilisateurs,groupes
Projets (tenants)
Rôles (lien entre utilisateur et projet)
Domaines
Services et endpoints (catalogue de services)
Fournit :
Tokens (jetons d'authentification)
CATALOGUE DE SERVICES
Pour chaque service, plusieurs endpoints sont possibles en

fonction de :
la région
le type d'interface (public,internal,administration)
SCÉNARIO D’UTILISATION TYPIQUE
Interactions avec Keystone
6 . 11
INSTALLATION ET CONFIGURATION
PaquetAPT :keystone
Intégration serveur web WSGI (Apache par défaut)
Fichier de configuration: /etc/keystone/keystone.conf
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)
DRIVERS POUR TOKENS
Uuid
PKI
Fernet
BOOTSTRAP
Création des services et endpoints (à commencer par Keystone)

Création d'utilisateurs, groupes, domaines
Fonctionnalité de bootstrap
NOVA : COMPUTE
6 . 12
PRINCIPES
Gère principalement les instances

Les instances sont créées à partir des images fournies par
Glance
Les interfaces réseaux des instances sont associées à des
ports Neutron
Du stockage block peut être fourni aux instances par Cinder
6 . 13
PROPRIÉTÉS D’UNE INSTANCE
Éphémère, a priori non hautement disponible

Définie par une flavor
Construite à partir d’une image
Optionnel :attachement de volumes
Optionnel :boot depuis un volume
Optionnel :une clé SSH publique
Optionnel :des ports réseaux
6 . 14
API
Ressources gérées :
Instances
Flavors (types d’instance)
Keypairs :ressource propre à l'utilisateur (et non propre au
projet)
6 . 15
ACTIONS SUR LES INSTANCES
Reboot /shutdown
Snapshot
Lecture des logs
Accès VNC
Redimensionnement
Migration (admin)
6 . 16
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
http://169.254.169.254/
L’API de metadata fournit des informations de configuration
personnalisées à chacune des instances
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
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
LE SCHEDULER NOVA EN ACTION
Fonctionnement de nova-scheduler
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
GLANCE : REGISTRE D'IMAGES
6 . 17
PRINCIPES
Registre d'images et de snapshots

Propriétés sur les images
6 . 18
API
API v2 :version courante,gère images et

snapshots
API artifacts :version future, plus généraliste
6 . 19
TYPES D’IMAGES
Glance supporte un large éventail de types d’images, limité par

le support de la technologie sous-jacente à Nova
raw
qcow2
ami
vmdk
iso
6 . 20
PROPRIÉTÉS DES IMAGES DANS GLANCE
L’utilisateur peut définir un certain nombre de propriétés dont

certaines seront utilisées lors de l’instanciation
Type d’image
Architecture
Distribution
Version de la
distribution
Espace disque minimum
RAM minimum
6 . 21
PARTAGE DES IMAGES
Image publique :accessible à tous les projets

Par défaut,seul l'administrateur peut rendre une image
publique
Image partagée :accessible à un ou plusieurs autre(s)
projet(s)
6 . 22
TÉLÉCHARGER DES IMAGES
La plupart des OS fournissent des images régulièrement mises à

jour :
Ubuntu : https://cloud-images.ubuntu.com/
Debian : https://cdimage.debian.org/cdimage/openstack/
CentOS :https://cloud.centos.org/centos/
6 . 23
BACKENDS
Swift ou S3
Ceph
HTTP
Répertoire
local
INSTALLATION
PaquetAPT :glance-api
NEUTRON : RÉSEAU
6 . 24
API
L’API permet notamment de manipuler ces ressources :

Réseau (network) :niveau 2
Sous-réseau (subnet) :niveau 3
Port :attachable à une interface sur une instance, un load-
balancer,etc.
Routeur
IP flottante,groupe de sécurité
6 . 25
LES IP FLOTTANTES
En plus des fixedIPs portées par les instances

Allocation (réservation pour le projet) d'une IP depuis un pool
Association d'une IP allouée à un port (d'une instance, par
exemple)
Non portées directement par les instances
6 . 26
LES GROUPES DE SÉCURITÉ
Équivalent à un firewall devant chaque instance

Une instance peut être associée à un ou plusieurs groupes de
sécurité
Gestion des accès en entrée et sortie
Règles par protocole (TCP/UDP/ICMP) et par port
Cible une adresse IP, un réseau ou un autre groupe de
sécurité
6 . 27
FONCTIONNALITÉS SUPPLÉMENTAIRES
Outre les fonctions réseau de base niveaux 2 et 3, Neutron peut

fournir d’autres services :
Load Balancing
Firewall :diffère des groupes de sécurité
VPN :permet d’accéder à un réseau privé sans IP
flottantes
QoS
6 . 28
PRINCIPES
SoftwareDefined 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
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
PLUGINS ML2
Modular Layer 2
LinuxBridge
OpenVSwitch
OpenDaylight
Contrail,OpenContrail
Nuage Networks
VMWare NSX
cf.OpenFlow
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
SCHÉMA
Vue utilisateur du réseau

SCHÉMA
CINDER : STOCKAGE BLOCK
6 . 29
PRINCIPES
Fournit des volumes (stockage block) attachables aux

instances
Gère différents types de volume
Gère snapshots et backups de volumes
6 . 30
UTILISATION
Volume supplémentaire (et stockage persistant) sur une

instance
Boot from volume :l’OS est sur le volume
Fonctionnalité de backup vers un object store (Swift ou Ceph)
6 . 31
PRINCIPES
Auparavant nova-volume
Fournit des volumes
Attachement des volumes via iSCSI par défaut
7 . 34
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
7 . 35
BACKENDS
Utilisation de plusieurs backends en parallèle

possible
LVM (par défaut)
GlusterFS
Ceph
Systèmes de stockage propriétaires type NetApp
DRBD
7 . 36
HORIZON : DASHBOARD WEB
6 . 36
PRINCIPES
Fournit une interface web

Utilise les APIs existantes pour fournir une interface
utilisateur
Log in possible sans préciser un projet :Horizon détermine la
liste des projets accessible
6 . 37
UTILISATION
Une interface par projet (possibilité de switcher)

Catalogue de services accessible
Téléchargement d'un fichier de configuration
clouds.yaml
Une zone “admin” restreinte
6 . 38
PRINCIPES
Horizon est un module Django

OpenStack Dashboard est l’implémentation officielle de ce
module
Logo du framework web Python Django

7 . 38
CONFIGURATION
local_settings.py
Les services apparaissent dans Horizon s’ils sont répertoriés
dans le catalogue de services de Keystone
7 . 39
SWIFT : STOCKAGE OBJET
7 . 40
PRINCIPES
SDS : SoftwareDefined Storage

Utilisation de commodity
hardware
Théorème CAP :on en choisit deux
Architecture totalement acentrée
Pas de base de données centrale
7 . 41
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)
7 . 42
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
7 . 43
SCHÉMA
Architecture Swift
7 . 44
HEAT : ORCHESTRATION
6 . 32
GÉNÉRALITÉS
Heat est la solution native OpenStack, service d'orchestration

Heat fournit une API de manipulation de stacks à partir de
templates
Un template Heat suit le format HOT (HeatOrchestration
Template),basé sur YAML
6 . 33
UN TEMPLATE HEAT ORCHESTRATION
TEMPLATE (HOT)
parameters - resources - outputs
heat_template_version: 2013-05-23
description: Simple template to deploy a single compute instance
resources:
my_instance:
type: OS::Nova::Server
properties:
key_name: my_key
image: F18-x86_64-cfntools
flavor: m1.small
6 . 34
CONSTRUIRE UN TEMPLATE À PARTIR
D’EXISTANT
Multiples projets en cours de développement

Flame (Cloudwatt)
HOT builder
Merlin
6 . 35
ARCHITECTURE
heat-api
heat-engine
7 . 50
CEILOMETER : COLLECTE DE MÉTRIQUES
7 . 45
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)
7 . 46
CEILOMETER
Récupère les données et les stocke

Historiquement :stockage MongoDB
Aujourd'hui :stockage Gnocchi
7 . 47
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
7 . 48
DÉPLOYER OPENSTACK
7.1

Cours Openstack Partie1-2 PDF

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

Cours Openstack Partie1-2 PDF

Titre original :

Transféré par

Droits d'auteur :

Formats disponibles

M211 - Implémenter un environnement Cloud

avec une solution libre

 Connaitre le fonctionnement du projet OpenStack

2 ID Cloud Computing Introduction à Openstack

 Mettre en service OpenStack

3 ID Cloud Computing Introduction à Openstack

4 ID Cloud Computing Introduction à Openstack

5 ID Cloud Computing Introduction à Openstack

8 ID Cloud Computing Introduction à Openstack

9 ID Cloud Computing Introduction à Openstack

1 ID Cloud Computing Introduction à Openstack

2010 : Rackspace Hosting + NASA

Objectif : créer et offrir des

2018 2019 2020 2021 2022

18 fev. 10 Avr. 13 Mai. 14 Avr. 30 Mai.

17 ID Cloud Computing Introduction à Openstack

“définir et superviser la “assure la supervision “représentent un large

 Aux USA jusqu’en 2013

19 ID Cloud Computing Introduction à Openstack

21 ID Cloud Computing Introduction à Openstack

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

22 ID Cloud Computing Introduction à Openstack

 Le packaging est fait dans de multiples

24 ID Cloud Computing Introduction à Openstack

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

27 ID Cloud Computing Introduction à Openstack

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

28 ID Cloud Computing Introduction à Openstack

30 ID Cloud Computing Introduction à Openstack

 Un forum pour les projets relatifs à OpenStack

31 ID Cloud Computing Introduction à Openstack

32 ID Cloud Computing Introduction à Openstack

1. L'évolutivité et l'élasticité sont nos principaux objectifsToute

33 ID Cloud Computing Introduction à Openstack

34 ID Cloud Computing Introduction à Openstack

 Des composants indépendants

35 ID Cloud Computing Introduction à Openstack

 Composants Individuels et autonomes

36 ID Cloud Computing Introduction à Openstack

37 ID Cloud Computing Introduction à Openstack

 Développement en Python (Django pour Horizon)

40 ID Cloud Computing Introduction à Openstack

41 ID Cloud Computing Introduction à Openstack

42 ID Cloud Computing Introduction à Openstack

43 ID Cloud Computing Introduction à Openstack

44 ID Cloud Computing Introduction à Openstack

45 ID Cloud Computing Introduction à Openstack

46 ID Cloud Computing Introduction à Openstack

50 ID Cloud Computing Introduction à Openstack

51 ID Cloud Computing Introduction à Openstack

 Oslo (ou OpenStack common) :

52 ID Cloud Computing Introduction à Openstack

53 ID Cloud Computing Introduction à Openstack

 Service de renseignements (utilisateurs, groupes,

54 ID Cloud Computing Introduction à Openstack

55 ID Cloud Computing Introduction à Openstack

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

56 ID Cloud Computing Introduction à Openstack

57 ID Cloud Computing Introduction à Openstack

58 ID Cloud Computing Introduction à Openstack

 Keystone est indispensable

59 ID Cloud Computing Introduction à Openstack