Resume Theorique M211

RÉSUMÉ THÉORIQUE – FILIÈRE INFRASTRUCTURE DIGITALE
M211 - Implémenter un environnement Cloud avec une solution libre
66,5 heures
1. Mettre en service OpenStack
Découvrir OpenStack
SOMMAIRE Installer OpenStack

Gérer le cluster OpenStack
2. Explorer les services de base

d’OpenStack
Provisionner des ressources de calculs
Configurer le réseau
Stocker des données
3. Explorer les services avancés

d’OpenStack
Gérer les identités
Superviser les ressources
4. Déployer des services d’OpenStack

Mettre en œuvre une solution de backup
Déployer des services de gestion infrastructure
MODALITÉS PÉDAGOGIQUES
1 2 3 4 5
LE GUIDE DE LA VERSION PDF DES CONTENUS DU CONTENU DES RESSOURCES
SOUTIEN Une version PDF TÉLÉCHARGEABLES INTERACTIF EN LIGNES
Il contient le est mise en ligne Les fiches de Vous disposez de Les ressources sont
résumé théorique sur l’espace résumés ou des contenus consultables en
et le manuel des apprenant et exercices sont interactifs sous synchrone et en
travaux pratiques formateur de la téléchargeables forme d’exercices asynchrone pour
plateforme sur WebForce Life et de cours à s’adapter au
WebForce Life utiliser sur rythme de
WebForce Life l’apprentissage
Copyright - Tout droit réservé - OFPPT 3

PARTIE 1
Mettre en service OpenStack
Dans ce module, vous allez :
• Comprendre l’écosystème OpenStack

• Déployer et mettre en œuvre OpenStack
• Opérer et administrer un cluster OpenStack
6,5 heures
CHAPITRE 1
Ce que vous allez apprendre dans ce chapitre :
• Avoir une vue d’ensemble de l’offre Cloud privé et

d’OpenStack
• S’imprégner de l’évolution et consistance des versions
d’OpenStack
2 heures
CHAPITRE 1
1. Introduction d’OpenStack
2. Chronologie des versions d’OpenStack
01 - Découvrir OpenStack
Introduction d’OpenStack
Présentation d’OpenStack
OpenStack est une plate-forme de Cloud Computing développée par le fournisseur de services d'hébergement RACKSPACE et la NASA pour aider les fournisseurs de
services Cloud et les entreprises à créer des services d'infrastructure Cloud.
Le projet OpenStack pourrait être considéré comme un système d'exploitation Cloud. Toute organisation ou tout particulier peut créer son propre environnement de Cloud
Computing (IaaS) basé sur OpenStack.
OpenStack permet la gestion du calcul, du stockage et du réseau à travers une interface web et visant à créer une plateforme de Cloud qui soit Open Source flexible et
élastique.
PARTIE 1

Modèles de déploiement OpenStack
Les déploiements Cloud sont aujourd’hui une tendance mondiale.
Les avantages : agilité, évolutivité, réduction des coûts.
Cloud public : ressources partagées, les modèles « pay-as-you-go » sont courants. Le Cloud public OpenStack est disponible dans plus de 60 centres de données dans le
monde.
Cloud Privé : dédié à un seul utilisateur. Peut être un Cloud privé hébergé dans le centre de données d'un fournisseur, ou un Cloud privé géré à distance.
Cloud hybride : un mélange de Cloud privé et de Cloud public orchestré ensemble pour répondre aux besoins de l'entreprise
PARTIE 1

Intégration avec les solutions existantes (Ecosystèmes)
OpenStack s'intègre à un certain nombre d'autres technologies, y compris de nombreux projets Open Source populaires, permettant aux utilisateurs de les
combiner avec OpenStack.
PARTIE 1

OpenNebula vs OpenStack vs CloudStack

Avec le nombre croissant de fournisseurs de services Cloud, il est très important de savoir comment chaque plate-forme de gestion Cloud (CMP) fonctionne dans un
écosystème Cloud ouvert. OpenNebula, OpenStack, CloudStack sont toutes des plates-formes de gestion Cloud avec des saveurs différentes.
Catégorie OpenNebula OpenStack CloudStack
API Cloud et OCCI (Open Cloud

API NOVA compatible avec EC2 (Elastic Compute
interface Computing Computin Services Web Amazon
Cloud) et S3 AWS
utilisateur g Interface) et API EC2
Modèle de Développement
Développement public Développement public
développement public
Préparation à la Assistance directe par
Disponible via des fournisseurs de service Assistance directe par les développeurs
production les développeurs
Langage de
Java et Ruby Python Java
PARTIE 1
programmation
Réseau plat
Modèle de mise
VLAN DHCP plat VLAN, groupes de sécurité
en réseau
DHCP VLAN

Mise en situation
Positionnement d’OpenStack 1/2

OpenStack est une plateforme Open Source pour environnements Cloud.
Il s'agit d'une infrastructure programmable qui permet aux utilisateurs d'avoir une plate-forme pour les machines virtuelles, les conteneurs et le bare metal.
Des centaines d'entreprises et des dizaines de milliers d'individus du monde entier se sont réunis pour créer et soutenir OpenStack parce qu'ils croient en l'importance
d'une plate-forme Cloud standardisée et omniprésente.
OpenStack a plusieurs projets sous son nom. Les projets couvrent des éléments fondamentaux tels que le calcul, la mise en réseau et le stockage, mais s'étendent
également de la télémétrie à l'orchestration en passant par les API de conteneur.
L’utilisation d’OpenStack est très répandue au niveau mondial. De grandes entreprises IT et non IT aux États-Unis utilisent OpenStack.
PARTIE 1

Mise en situation
Positionnement d’OpenStack 2/2

OpenStack offre les deux avantages suivants : une interface API d2veloppée et une plate-forme multi-technologies (VM, Conteneurs,...)
Ceci permet à Openstack d’être attractif aussi bien en termes de flexibilité d’usage que de possibilités d’interfaçage avec d’autres solutions.
Infrastructure programmable qui établit un Une plate-forme pour les machines virtuelles, les
ensemble commun d'API au-dessus du calcul, de la conteneurs et le bare metal
mise en réseau et du stockage
PARTIE 1

Architecture d’OpenStack
L'architecture d'OpenStack propose de nombreux services selon l'architecture réduite suivante:
PARTIE 1

Architecture d’OpenStack : Service Horizon

Le service Horizon d’OpenStack Fournit un portail libre-service de type web permettant d’interagir avec les services sous-jacents d’OpenStack, comme le lancement d’une
instance, l’attribution d’adresses IP ou la configuration des contrôles d’accès.
PARTIE 1

Architecture d’OpenStack : Service Nova

Le service Nova d’OpenStack gère le cycle de vie des instances dans un environnement OpenStack. Les tâches incluent la planification, la création et la mise hors service de
machines virtuelles à la demande.
PARTIE 1

Architecture d’OpenStack : Service Cinder

Fournit un stockage bloc persistant aux instances en cours d’exécution. Son architecture basée sur des drivers de type plugin facilite la création et la gestion des devices de
stockage bloc.
PARTIE 1

Architecture d’OpenStack : Service Neutron

Permet le Network-Connectivity-as-a-Service pour d’autres services d’OpenStack, comme Compute. Fournit une API utilisateur pour définir les réseaux et les attachements
à ces réseaux. Possède une architecture modulaire qui permet le support de la plupart des fournisseurs et des technologies réseau.
PARTIE 1

Architecture d’OpenStack : Service Glance

Stocke et récupère des images disques de machines virtuelles. OpenStack Compute les utilise lors du provisioning d’instance.
PARTIE 1

Architecture d’OpenStack : Service Swift

Stocke et récupère des objets de données non structurées via une API RESTful basée sur HTTP. Le service est hautement tolérant aux pannes avec sa réplication de
données et son architecture de type scale-out. Son implémentation diffère des serveurs de fichiers à répertoires montables. Le service écrit les objets et les fichiers vers
plusieurs disques, en s’assurant que les données sont répliquées sur un cluster de serveurs.
PARTIE 1

Architecture d’OpenStack : Service Keystone

Fournit un service d’authentification et d’autorisation pour les autres services d’OpenStack.
Fournit également un catalogue de Endpoints pour tous les services d’OpenStack.
PARTIE 1

Architecture d’OpenStack : Autre services

Service Ceilometer :
Surveille et mesure un Cloud OpenStack dans un but de facturation, de mesure de performances, de scalabilité et de
statistiques.
Service Heat :
Orchestre de nombreuses applications de Cloud composites en utilisant soit le format de template natif HOT ou le format
CloudFormation d’AWS, soit au travers d’une API REST native OpenStack, soit au travers d’une API compatible avec
CloudFormation.
PARTIE 1

CHAPITRE 1
1. Introduction d’OpenStack
2. Chronologie des versions d’OpenStack
Chronologie des versions d’OpenStack
La mise en service d’OpenStack est passée par plusieurs version selon la chronologie suivante :
• 2010 : Rackspace réécrivait le code de son infrastructure Cloud et envisageait d'en ouvrir une partie. La NASA travaillait également sur du code pour l'infrastructure
Cloud.
❖ La base d'OpenStack est la combinaison des deux efforts.
❖ Le premier sommet OpenStack s'est tenu à Austin, au Texas, en juillet 2010.
• 2012 : La Fondation OpenStack a été créée, et supervise les projets et gère la communauté.
• 2014 : OpenStack Marketplace a été créé. Il s'agit d'un portail sur OpenStack.org/marketplace qui aide les utilisateurs à naviguer dans un écosystème de formations,
distributions de projets OpenStack etc…
• 2015 : La certification d'interopérabilité OpenStack Powered a été lancée. Le badge OpenStack Powered est destiné aux produits qui exécutent des instances
entièrement fonctionnelles d'OpenStack et qui ont été testés selon les normes convenues par l'écosystème de fournisseurs et d'utilisateurs.
• 2016 a été importante pour OpenStack, car l'adoption par les entreprises chinoises a été remarquable. Le programme Certified OpenStack Administrator a été lancé,
qui est une certification professionnelle qui teste les compétences fondamentales d'OpenStack.
PARTIE 1
• 2017 : OpenStack a continué le développement de son infrastructure programmable, offrant aux utilisateurs une plate-forme pour les conteneurs, les VMs et le bare-
metal.

Les versions 2010-2015

Openstack est une solution Cloud Opensource, disposant d’une forte communauté et soutenue par de grandes entreprises.
L’activité des mises à jour des versions est très soutenue.
Ce dynamisme est remarqué au niveau du nombre ainsi que la fréquence des mises à jour comme illustré sur le tableau ci-après :
Nom version Date version Evolution des composants

Austin 21 October 2010 Nova, Swift
Bexar 3 February 2011 Nova, Glance, Swift
Cactus 15 April 2011 Nova, Glance, Swift
Diablo 22 September 2011 Nova, Glance, Swift
Essex 5 April 2012 Nova, Glance, Swift, Horizon, Keystone
Folsom 27 September 2012 Nova, Glance, Swift, Horizon, Keystone, Quantum, Cinder
Grizzly 4 April 2013 Nova, Glance, Swift, Horizon, Keystone, Quantum, Cinder
Havana 17 October 2013 Nova, Glance, Swift, Horizon, Keystone, Neutron, Cinder, Heat, Ceilometer
PARTIE 1
Icehouse 17 April 2014 Nova, Glance, Swift, Horizon, Keystone, Neutron, Cinder, Heat, Ceilometer, Trove
Juno 16 October 2014 Nova, Glance, Swift, Horizon, Keystone, Neutron, Cinder, Heat, Ceilometer, Trove, Sahara
Kilo 30 April 2015 Nova, Glance, Swift, Horizon, Keystone, Neutron, Cinder, Heat, Ceilometer, Trove, Sahara, Ironic


A partir de 2015 le rythme ainsi que la consistance des mises à jour des composants sont très soutenus.
Le produit a ainsi gagné en stabilité et en richesse fonctionnelle.

Nova, Glance, Swift, Horizon, Keystone, Neutron, Cinder, Heat, Ceilometer, Trove, Sahara, Ironic, Zaqar, Manila, Designate,
Liberty 16 October 2015 Barbican, Searchlight
Mitaka 7 April 2016 Barbican, Searchlight, Magnum
Newton 6 October 2016 Barbican, Searchlight, Magnum, aodh, Cloudkitty, congress, freezer, mistral, monasca-api, monasca-log-api, murano, panko,
senlin, solum, tacker, vitrage, Watcher
Ocata 22 February 2017 Barbican, Searchlight, Magnum, aodh, Cloudkitty, congress, freezer, mistral, monasca-api, monasca-log-api, murano, panko,
Pike 30 August 2017 Barbican, Searchlight, Magnum, aodh, Cloudkitty, congress, freezer, mistral, monasca-api, monasca-log-api, murano, panko,
PARTIE 1
Queens 28 February 2018 Barbican, Searchlight, Magnum, aodh, Cloudkitty, congress, freezer, mistral, monasca-api, monasca-log-api, murano, panko,
senlin, solum, tacker, vitrage, Watcher, blazar, ceilometer-powervm, karbor, octavia, storlets, tricircle, zun
Barbican, Searchlight, Magnum, aodh, Cloudkitty, congress, freezer, mistral, monasca-api, monasca-log-api, murano, panko,
Rocky 30 August 2018 senlin, solum, tacker, vitrage, Watcher, blazar, ceilometer-powervm, karbor, octavia, storlets, tricircle, zun, Cyborg, ec2-api,
Masakari, Qinling (40 services)


L’élan plutôt ascendant des mises en production s’est confirmé et s’est installé au delà de 2020
Openstack gagne en notoriété et se place largement au delà des solutions alternatives

Nova, Glance, Swift, Horizon, Keystone, Neutron, Cinder, Heat, Ceilometer, Trove, Sahara, Ironic, Zaqar, Manila, Designate, Barbican,
Searchlight, Magnum, aodh, Cloudkitty, congress, freezer, mistral, monasca-api, monasca-log-api, murano, panko, senlin, solum, tacker,
Stein 10 April 2019 vitrage, Watcher, blazar, ceilometer-powervm, karbor, octavia, storlets, tricircle, zun, Cyborg, ec2-api, Masakari, Qinling, monasca-events-
api, placement (44 services)
Searchlight, Magnum, aodh, Cloudkitty, congress, freezer, mistral, monasca-api, monasca-log-api, murano, panko, senlin, solum, tacker,
Train 16 October 2019 vitrage, Watcher, blazar, ceilometer-powervm, karbor, octavia, storlets, tricircle, zun, Cyborg, ec2-api, Masakari, Qinling, monasca-events-
api, placement (44 services)
Ussuri 13 May 2020 Searchlight, Magnum, aodh, Cloudkitty, congress, freezer, mistral, monasca-api, murano, panko, senlin, solum, tacker, vitrage, Watcher,
blazar, karbor, octavia, storlets, tricircle, zun, Cyborg, ec2-api, Masakari, Qinling, monasca-events-api, placement, adjutant (44 services)
Adjutant, Aodh, Barbican, Blazar, Ceilometer, Cinder, Cloudkitty, Cyborg, Designate, Ec2-api, Freezer, Glance, Heat, Horizon, Ironic, Karbor,
Victoria 14 October 2020 Keystone, Magnum, Manila, Masakari, Mistral, Monasca-api, Monasca-events-api, Murano, Neutron, Nova, Octavia, Panko, Placement,
Qinling, Sahara, Searchlight, Senlin, Solum, Storlets, Swift, Tacker, Trove, Vitrage, Watcher, Zaqar, Zun (42 services)
PARTIE 1
Adjutant, Aodh, Barbican, Blazar, Ceilometer, Cinder, Cloudkitty, Cyborg, Designate, Ec2-api, Freezer, Glance, Heat, Horizon, Ironic, Keystone,
Wallaby 14 April 2021 Magnum, Manila, Masakari, Mistral, Monasca-api, Monasca-events-api, Murano, Neutron, Nova, Octavia, Panko, Placement, Sahara, Senlin,
Solum, Storlets, Swift, Tacker, Trove, Vitrage, Watcher, Zaqar, Zun (39 services)
Adjutant, Aodh, Barbican, Blazar, Ceilometer, Cinder, Cloudkitty, Cyborg, Designate, Ec2-api, Freezer, Glance, Heat, Horizon, Ironic, Keystone,
Xena 06 October 2021 Magnum, Manila, Masakari, Mistral, Monasca-api, Monasca-events-api, Murano, Neutron, Nova, Octavia, Placement, Sahara, Senlin, Solum,
Storlets, Swift, Tacker, Trove, Vitrage, Watcher, Zaqar, Zun (38 services)

Contributeurs sur OpenStack : Exemple version Wallaby

La version OpenStack Wallaby a eu lieu faisant suite à la contribution de plusieurs collaborateurs.
Ci-dessous la liste des top 10 des collaborateurs ayant le plus grand nombre de revues (modification au niveau des composants) :
Contributeur Nombre de revue Pourcentage

Nombre de revue
Red Hat 1450 50%
Ericsson 446 15% 2%
5%3%2%1%
6%
Independent 285 10% 6% 50%
10%
Yovole 185 6% 15%
NEC 168 6%
Lenovo 154 5%
SUSE 74 3%
Red Hat Ericsson Independent Yovole NEC
PARTIE 1
IBM 58 2%
Lenovo SUSE IBM Dell EMC NetApp
Dell EMC 52 2%
NetApp 44 2%

CHAPITRE 2
Installer OpenStack
• Etapes de téléchargement et d’installation

• Détaille et présentation de l’architecture
• Analyse et exploration des différents composants
2 heures
CHAPITRE 2
Installer OpenStack
1. Téléchargement et installation
2. Présentation de l’architecture
3. Exploration des composants
02 - Installer OpenStack
Téléchargement et installation
Prérequis d’installation et de mise en place 1/2

Exemple d’architecture minimale
Les nœuds sont à la base de Linux Ubuntu.
Il est possible de prévoir un en environnement d’installation virtualisé.
Différents outils de virtualisation peuvent être utilisés :
• VMWARE Workstation
• Oracle VirtualBox
L’installation sera détaillée dans la partie travaux pratique.

Elle concernera la dernière version Yoga (Avril 2022)
PARTIE 1

Prérequis d’installation et de mise en place 2/2

Exemple d’architecture réseau minimale
La configuration réseau présentée définit l’architecture minimale.
L’ajout des composants se fait en fonction du scope de l’installation.
Il est fortement recommandé de démarrer par une installation minimale.
La possibilité d’étendre les fonctionnalités est toujours possible à travers l’ajout des composants.
PARTIE 1

Configuration réseau des hôtes

Principe de séparation des réseaux
La configuration réseau repose sur la séparation du réseau de gestion et du réseau d’accès.
La configuration présentée repose toujours sur la configuration minimale.
Les composants en pointillées sont optionnels pour le démarrage.
La possibilité d’étendre les fonctionnalités est toujours possible à travers l’ajout des composants.
PARTIE 1

Packages OpenStack
La solution OpenStack est constituée de plusieurs services qui s’installent séparément.
Ces services interagissent en fonction des besoins de votre Cloud.
Il s’agit notamment du service Compute, du service d’Identité, du service Réseau, du service Image, du service de Stockage Bloc, du service de Stockage Objet, du service
de Télémétrie, du service d’Orchestration et du service de Base de Données.
Il est possible d’installer chacun de ces services indépendamment et les configurer comme autonomes ou en tant qu’entités connectées.
Les distributions livrent les packages OpenStack soit avec la distribution elle-même, soit par d’autres moyens en fonction du calendrier de sortie des différentes versions.
Exécuter ces procédures sur tous les nœuds.
PARTIE 1

Packages OpenStack
La solution OpenStack est constituée de plusieurs services qui s’installent séparément.
Ces services interagissent en fonction des besoins de votre Cloud.
Il s’agit notamment du service Compute, du service d’Identité, du service Réseau, du service Image, du service de Stockage Bloc, du service de Stockage Objet, du service
de Télémétrie, du service d’Orchestration et du service de Base de Données.
Il est possible d’installer chacun de ces services indépendamment et les configurer comme autonomes ou en tant qu’entités connectées.
Les distributions livrent les packages OpenStack soit avec la distribution elle-même, soit par d’autres moyens en fonction du calendrier de sortie des différentes versions.
Exécuter ces procédures sur tous les nœuds.
PARTIE 1

Packages OpenStack
Activer le dépôt OpenStack
• # apt-get install software-properties-common
• # add-apt-repository Cloud-archive:mitaka
Finaliser l’installation
• # apt-get update && apt-get dist-upgrade
Installer le client OpenStack :

• # apt-get install python-OpenStackclient
PARTIE 1

CHAPITRE 2
Installer OpenStack
Présentation de l’architecture
Le projet OpenStack
Le projet OpenStack est une plate-forme de Cloud Computing Open Source qui supporte tout type d’environnement Cloud.
Le projet a pour objectif une implémentation simple, une scalabilité massive et un riche ensemble de fonctionnalités. Des experts en Cloud Computing du monde entier
contribuent au projet.
OpenStack fournit une solution d’Infrastructure-as-a-Service (IaaS) grâce à une variété de services complémentaires.
Chaque service offre une Application Programming Interface (API) qui facilite cette intégration.
PARTIE 1

Présentation de l’architecture
Architecture OpenStack
OpenStack est l'un des plus grands projets Open Source au
monde.
Vue sa nature Open Source, OpenStack est capable

d'évoluer, lorsque les besoins surviennent ou que les
situations changent
OpenStack est sous licence Apache 2.0, il est libre

d'utilisation, libre de distribution et de modification.
OpenStack est une suite d'options qui fonctionnent toutes

sur la même infrastructure sous-jacente. Pour les
utilisateurs, cela signifie qu’on peut passer d'un fournisseur
à l'autre ou combiner des services sans craindre d'être
PARTIE 1
enfermés dans une seule solution propriétaire.
Source : OpenStack

CHAPITRE 2
Installer OpenStack
Exploration des composants
Les services d’OpenStack

OpenStack offre une multitude de services destinés aux différents usages.
Un déploiement OpenStack contient un certain nombre de composants fournissant des API pour accéder aux ressources de l'infrastructure.
Dans ce qui suit sont répertoriés les différents services qui peuvent être déployés pour fournir ces ressources aux utilisateurs finaux du Cloud.
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, tous
gérés et provisionnés via des API avec des mécanismes d'authentification communs.
Un tableau de bord est également disponible, donnant aux administrateurs le contrôle tout en permettant à leurs utilisateurs de provisionner des ressources via une
interface Web.
Au-delà de la fonctionnalité standard d'infrastructure en tant que service, des composants supplémentaires assurent l'orchestration, la gestion des pannes et la gestion
des services, entre autres services, pour garantir une haute disponibilité des applications utilisateur.
PARTIE 1

Service Web : OpenStack Horizon

Explorer l'interface Web
Il existe trois façons d'accéder à OpenStack, la première est l'interface graphique (Horizon Dashboard), la deuxième est la ligne de commande et la troisième est en
utilisant les appels API OpenStack.
Qu'est-ce qu'Horizon ?
Horizon est l'implémentation canonique du tableau de bord d'Openstack, qui fournit une interface utilisateur Web aux services OpenStack, notamment Nova, Cinder,
Neutron et d'autres services. Il est livré avec trois tableaux de bord centraux, un "tableau de bord utilisateur", un "tableau de bord système" et un tableau de bord
"Paramètres". Entre ces trois, ils couvrent les principales applications OpenStack.
L’utilisateur final du Cloud, utilise le tableau de bord OpenStack pour provisionner les ressources dans les limites définies par les administrateurs pour déployer
l'infrastructure virtuelle.
PARTIE 1


Connexion à la page d’accueil
On se connecte moyennant un navigateur Web sur lequel JavaScript et les cookies sont activés.
Sur la page de connexion, introduire nom d'utilisateur et mot de passe, nom de domaine, puis Se connecter.
PARTIE 1


Onglet Projet
Les projets sont des unités organisationnelles

dans le Cloud. Chaque utilisateur est membre
d'un ou de plusieurs projets. Au sein d'un projet,
un utilisateur crée et gère des instances.
Dans l'onglet Projet, afficher et gérer les
ressources d'un projet sélectionné, y compris les
instances et les images. Sélectionner le projet
dans le menu déroulant en haut à gauche.
PARTIE 1


Onglet Identité
À partir de l'onglet Identité, il est possible d’afficher tous les projets attribués à un utilisateur.
PARTIE 1


Onglet Paramètres
Le bouton Paramètres dans le menu déroulant de l'utilisateur en haut à droite de n'importe quelle page, ouvre l'onglet Paramètres.
Paramètres utilisateur : affiche et gère les paramètres du tableau de bord.
Paramètres -> Changer le mot de passe : change le mot de passe de l'utilisateur.
PARTIE 1

Service réseau : OpenStack Neutron

Qu'est-ce que le neutron ?
Neutron est un projet OpenStack visant à fournir une « connectivité réseau en tant que service (NaaS) ». Le service OpenStack Networking (neutron) fournit une
API qui permet de créer des topologies de réseau riches, de configurer et de définir la connectivité réseau, de configurer des politiques réseau avancées et
l'adressage dans le Cloud.
OpenStack Networking gère la création et la gestion d'une infrastructure de réseau virtuel, y compris les réseaux, les commutateurs, les sous-réseaux et les
routeurs pour les machines virtuelles gérés par le service OpenStack Compute (nova). Des services avancés tels que des pare-feux ou des réseaux privés virtuels
(VPN) peuvent également être utilisés.
OpenStack Networking s'intègre à divers composants OpenStack :

• Le service OpenStack Identity est utilisé pour l'authentification et l'autorisation des requêtes API.
• Le service OpenStack Compute (nova) est utilisé pour connecter chaque carte réseau virtuelle de la machine virtuelle à un réseau particulier.
• OpenStack Dashboard (horizon) est utilisé par les administrateurs et les utilisateurs du projet pour créer et gérer des services réseau via une interface
PARTIE 1
graphique basée sur le Web.


Concepts de base
OpenStack Networking (neutron) gère toutes les facettes de mise en réseau pour l'infrastructure de réseau virtuel (VNI) et les aspects de la couche d'accès de
l'infrastructure de réseau physique (PNI) dans OpenStack.
La mise en réseau fournit des réseaux, des sous-réseaux et des routeurs en tant qu'abstractions d'objets. Chaque abstraction a des fonctionnalités qui imitent son
homologue physique : les réseaux contiennent des sous-réseaux et les routeurs acheminent le trafic entre différents sous-réseaux et réseaux.
Toute configuration de mise en réseau donnée comporte au moins un réseau externe. Contrairement aux autres réseaux, le réseau externe ou réseau de
fournisseur n'est pas simplement un réseau virtuellement défini. il représente une vue dans une tranche du réseau physique externe accessible en dehors
d'OpenStack. Les adresses IP sur le réseau externe sont accessibles par n'importe qui sur le réseau.
Dans OpenStack, différents types de réseaux de fournisseurs ont été définis pour répondre à différents cas d'utilisation :
• Le réseau public CUDN autorise le trafic public depuis Internet. Il s'agit du réseau du fournisseur à utiliser, pour créer un serveur Web public ou un service
général.
• Le réseau privé CUDN n'autorise que le trafic interne d’un domaine. Il s'agit d'un réseau plus restreint qui pourrait s'appliquer à des réseaux ou des services
de gestion restreints au domaine.
PARTIE 1


Options principales
Il existe deux menus importants dans OpenStack qui permettent de créer et de gérer tous les éléments requis : le menu Réseau et le menu Sécurité et accès. Le
premier, Réseau (Projet -> Réseau), présente toutes les options pour créer des réseaux, des sous-réseaux et des routeurs comme suit :
Topologie du réseau : afficher la topologie du réseau.
Réseaux : créer et gérer des réseaux publics et privés
PARTIE 1


Routeurs : créer et gérer des routeurs.
La figure montre deux routeurs différents créés, chacun attaché à un réseau externe différent.
PARTIE 1

Service calcul : OpenStack Nova

OpenStack Compute Service (Nova) est un contrôleur d'instance de Cloud computing, qui est la partie principale d'un système IaaS. Nova est le projet OpenStack
qui fournit un moyen de provisionner des instances de calcul (c'est-à-dire des serveurs virtuels), qui est utilisé pour héberger et gérer des systèmes de Cloud
computing.
Il s'agit d'un service qui fournit une capacité de calcul redimensionnable dans OpenStack. Il offre un contrôle complet des ressources informatiques ce qui permet
d'augmenter rapidement la capacité, à la hausse comme à la baisse, à mesure que les besoins changent.
Nova s'exécute comme un ensemble de démons au-dessus des serveurs Linux existants (nœud de calcul) pour fournir ce service. Le nœud de calcul exécute la
partie hyperviseur de Compute qui exploite les instances. Par défaut, Compute utilise l'hyperviseur de VM basé sur le noyau (KVM). Le nœud de calcul exécute
également un agent de service de mise en réseau qui connecte les instances aux réseaux virtuels et fournit des services de pare-feu aux instances via des groupes
de sécurité.
Nova est généralement déployé avec d'autres services OpenStack (par exemple, Block Storage, Object Storage, Image, etc.) dans le cadre d'une infrastructure
Cloud plus vaste et plus complète. OpenStack utilise les services suivants pour fournir les fonctionnalités de base :
• Keystone : fournit l'identité et l'authentification pour tous les services OpenStack.
• Glance : fournit le référentiel d'images de calcul. Toutes les instances de calcul se lancent à partir d'images.
PARTIE 1
• Neutron : responsable du provisionnement des réseaux virtuels ou physiques auxquels les instances de calcul se connectent au démarrage.
Il peut également s'intégrer à d'autres services pour inclure d'autres fonctionnalités telles que le stockage de blocs persistant et les disques chiffrés.

Concepts de base
Instance
Une instance est l'unité de ressource fondamentale allouée par le service OpenStack Compute. Il représente une allocation de capacité de calcul ainsi qu'un
stockage éphémère facultatif utilisé pour prendre en charge la capacité de calcul provisionnée.
À moins qu'un disque racine ne provienne de Cinder, les disques associés aux VM sont « éphémères », ce qui signifie qu’ils disparaissent effectivement lorsqu'une
machine virtuelle est terminé.
Une instance peut éventuellement être référencée par un nom significatif, bien qu'il ne soit pas garanti que cette chaîne soit unique au sein d'un déploiement
unique. ils peuvent cependant être identifiés de manière unique via un UUID attribué par le service Nova au moment de la création de l'instance.
Les saveurs
Dans OpenStack, les modèles de matériel virtuel sont appelés versions, définissant les tailles de RAM, de disque, de nombre de cœurs, etc. Les saveurs définissent
un certain nombre de paramètres. Ceci permet à l'utilisateur de choisir le type de machine virtuelle à exécuter, comme il le ferait s'il achetait un serveur physique.
Les saveurs peuvent également contenir des extra_specs, qui peuvent être utilisées pour définir des caractéristiques de forme libre, offrant une grande flexibilité
au-delà de la taille de la RAM, du processeur et du disque pour déterminer où une instance est provisionnée.
PARTIE 1

Service stockage : OpenStack Glance et OpenStack Cinder

Disques racine (et éphémères)
Chaque instance a besoin d'au moins un disque racine (qui contient le chargeur de démarrage et les fichiers du système d'exploitation principal) et peut avoir un
disque éphémère facultatif (selon la définition de la version sélectionnée au moment de la création de l'instance). Le contenu du disque racine provient soit d'une
image stockée dans le référentiel Glance, soit d'un volume de stockage de blocs persistant (via Cinder).
Il existe plusieurs choix pour la création du disque racine, qui sont présentés aux utilisateurs du Cloud lors du démarrage des instances Nova.
• Boot from image : cette option permet à un utilisateur de spécifier une image du référentiel Glance à copier sur un disque éphémère.
• Boot from snapshot : cette option permet à un utilisateur de spécifier un instantané d'instance à utiliser comme disque racine ; l'instantané est copié sur un
disque éphémère.
• Boot from volume : cette option permet à un utilisateur de spécifier un volume Cinder (par nom ou UUID) qui doit être directement attaché à l'instance en
tant que disque racine ; aucune copie n'est effectuée sur un disque éphémère et tout contenu stocké dans le volume est persistant.
• Démarrée à partir d'une image (créer un nouveau volume), cette option permet à un utilisateur de spécifier une image du référentiel Glance à copier dans un
volume Cinder persistant, qui est ensuite attaché en tant que disque racine de l'instance.
• Démarrée à partir d'un instantané de volume (créer un nouveau volume), cette option permet à un utilisateur de spécifier un instantané de volume Cinder
PARTIE 1
(par nom ou UUID) qui doit être utilisé comme disque racine ; l'instantané est copié dans un nouveau volume Cinder persistant qui est ensuite attaché en tant
que disque racine de l'instance pour créer un volume éphémère qui sera marqué pour suppression lorsque l'instance elle-même sera résiliée.

CHAPITRE 3
• Gérer le cluster OpenStack à partir de l’interface graphique

• Gérer le cluster OpenStack à partir du CLI
2,5 heures
CHAPITRE 3
1. Gestion du cluster à partir de l’interface graphique

2. Gestion du cluster à partir du CLI
03 - Gérer le cluster OpenStack
Gestion du cluster à partir de l’interface graphique
Dashboard
Le Dashboard (horizon) est une interface web qui permet aux administrateurs et aux utilisateurs du Cloud d’administrer les différentes ressources et services OpenStack.
Le dashboard repose sur les services de base fonctionnels comme le service d’Identité, le service Image, le service Compute, et soit le service Réseau (neutron) ou le
service Réseau legacy (nova-network).
Vérifications préalables :
• Vérifier le fonctionnement du dashboard.
• Accéder au dashboard via un navigateur web et l’adresse http://controller/horizon.
• S’authentifier avec les crédentials de l’utilisateur admin ou demo et le domaine default.
Il est possible d’effectuer les actions suivantes :

• Fournir aux utilisateurs une adresse IP, un nom d’utilisateur et un mot de passe pour qu’ils puissent accéder au dashboard via un navigateur web.
• En cas de problème de connexion dû au certificat SSL, associer un nom de domaine à l’adresse IP du serveur et donner l’accès aux utilisateurs.
PARTIE 1
• Personnaliser le dashboard.
• Paramétrer le stockage de session.
• Pour utiliser le client VNC avec le dashboard, le navigateur doit supporter les canvas et les WebSockets HTML5.

Dashboard
Tableau de bord OpenStack — onglet Projet
Les projets sont des unités organisationnelles dans le Cloud et sont également appelés locataires ou comptes. Chaque utilisateur est membre d'un ou de plusieurs projets.
Au sein d'un projet, un utilisateur crée et gère des instances.
PARTIE 1

Dashboard
Tableau de bord OpenStack — onglet Admin
Les utilisateurs administratifs peuvent utiliser l'onglet Admin pour afficher l'utilisation et gérer les instances, les volumes, les versions, les images, les réseaux, etc.
PARTIE 1

Dashboard
Tableau de bord OpenStack — onglet Identité
Les utilisateurs administratifs peuvent utiliser l'onglet identité pour gérer les autres utilisateurs, les droits d’accès, les rôles, etc.
PARTIE 1

CHAPITRE 3
1. Gestion du cluster à partir de l’interface graphique

2. Gestion du cluster à partir du CLI
Gestion du cluster à partir du CLI
Installer OpenStackClient
OpenStackClient
OpenStackClient (alias OSC) est un client de ligne de commande pour OpenStack.
Il rassemble le jeu de commandes pour les API de calcul, d'identité, d'image, de stockage d'objets et de stockage de blocs.
Un seul shell avec une structure de commande uniforme.
Installer les clients de ligne de commande OpenStack
La plupart des distributions Linux incluent des versions packagées des clients en ligne de commande qu’il est possible d’installer directement.
Prérequis : Python 2.7, setuptools package, pip package.
L'exemple suivant montre la commande d'installation du client OpenStack avec pip, qui prend en charge plusieurs services.
# apt install python-dev python-pip.
Utiliser pip pour installer les clients OpenStack sur un système Linux afin d’obtenir la dernière version du client à partir du Python Package.
De plus, pip permet de mettre à jour ou de supprimer un package.
# pip install python-OpenStackclient.
PARTIE 1
Installation à partir de packages

# apt-get install python-PROJECTclient.

OpenStack command-line interface
Sourcer les crédentiels admin pour accéder aux commandes en ligne réservées à l’administrateur :
$ . admin-openrc
Lister les composants du service pour vérifier le bon lancement et le bon enregistrement de chaque
processus :
$ openstack compute service list

+----+--------------------+------------+----------+---------+-------+----------------------------+
| Id | Binary | Host | Zone | Status | State | Updated At |
+----+--------------------+------------+----------+---------+-------+----------------------------+
| 1 | nova-consoleauth | controller | internal | enabled | up | 09T23:11:15.000000 |
| 2 | nova-scheduler | controller | internal | enabled | up | 09T23:11:15.000000 |
| 3 | nova-conductor | controller | internal | enabled | up | 09T23:11:16.000000 |
| 4 | nova-compute | compute1 | nova | enabled | up | 09T23:11:20.000000 |
+----+--------------------+------------+----------+---------+-------+----------------------------+
PARTIE 1


• Identité (keystone)
Lister tous les utilisateurs
$ OpenStack user list
Répertorier le catalogue des services d'identité
$ OpenStack catalog list
• Images (Glance)
Lister les images
$ OpenStack image list
Supprimer l'image spécifiée
$ OpenStack image delete IMAGE
Mettre à jour l'image
$ OpenStack image set IMAGE
PARTIE 1
Télécharger l'image du noyau

$ OpenStack image create "cirros-threepart-kernel" \
--disk-format aki --container-format aki --public \
--file ~/images/cirros-0.3.5-x86_64-kernel


• Compute (nova)
Répertorier les instances, vérifier l'état de l'instance
$ OpenStack server list
Liste des images
$ OpenStack image list
Créer une saveur nommée m1.tiny
$ OpenStack flavor create --ram 512 --disk 1 --vcpus 1 m1.tiny
Liste des saveurs
$ OpenStack flavor list
Démarrer une instance à l'aide des noms de type et d'image
$ OpenStack server create --image IMAGE --flavor FLAVOR INSTANCE_NAME
$ OpenStack server create --image cirros-0.3.5-x86_64-uec --flavor m1.tiny \
PARTIE 1
MyFirstInstance
Se connecter à l'instance avec une adresse IP
$ ssh Cloud-user@128.107.37.150

PARTIE 2
Explorer les services de base d’OpenStack
• Provisionner des ressources de calculs

• Configurer le réseau
• Stocker des données
27 heures
CHAPITRE 1
• Avoir une vue d'ensemble sur la brique Nova

• Avoir une vue d'ensemble sur la brique Glance
• Créer une VM via le catalogue et via une imag personnalisée
• Gérer une instance avec les commandes
9 heures
CHAPITRE 1
1. Vue d'ensemble de la brique Nova

2. Vue d'ensemble de la brique Glance
3. Création d’une VM via le catalogue et via une image
personnalisée
4. Gestion d'une instance avec les commandes
01 - Provisionner des ressources de calculs
Vue d'ensemble de la brique Nova
Le nœud Compute
Le nœud Compute exécute la partie hyperviseur du service Compute qui

fait fonctionner les instances.
Par défaut, le service Compute utilise l’hyperviseur KVM.
Le nœud Compute héberge également un agent du service Réseau qui

connecte les instances aux réseaux virtuels et fournit des services de
firewall aux instances via les groupes de sécurité.
Il est possible de déployer plus d’un nœud Compute.

Chaque nœud nécessite au minimum deux interfaces réseau.
PARTIE 2

Vue d'ensemble de la brique Nova
La brique Nova
Nova est le projet OpenStack qui fournit un moyen de provisionner des instances de calcul (serveurs virtuels).
Nova prend en charge la création de machines virtuelles, de serveurs baremetal (grâce à l'utilisation d'ironic) et a une prise en charge limitée des conteneurs système. Il
s'exécute comme un ensemble de démons au-dessus des serveurs Linux existants pour fournir ce service.
Il nécessite les services OpenStack supplémentaires suivants pour les fonctions de base :
• Keystone : fournit l'identité et l'authentification pour tous les services OpenStack.

• Glance : cela fournit le référentiel d'images de calcul. Toutes les instances de calcul se lancent à partir d'images d'aperçu.
• Neutron : il est responsable du provisionnement des réseaux virtuels ou physiques auxquels les instances de calcul se connectent au démarrage.
• Placement : il est chargé de suivre l'inventaire des ressources disponibles dans un Cloud et d'aider à choisir le fournisseur de ces ressources qui sera utilisé lors de la
création d'une machine virtuelle.
PARTIE 2
Il peut également s'intégrer à d'autres services pour inclure : le stockage de blocs persistant, les disques chiffrés et les instances de calcul baremetal.

CHAPITRE 1

personnalisée
Vue d'ensemble de la brique Glance
La brique Glance
Elle stocke et récupère des images disques de machines virtuelles.
OpenStack Compute les utilise lors du provisioning d’instance.
Le projet Image service (Glance) fournit un service dans lequel les utilisateurs peuvent télécharger et découvrir des actifs de données destinés à être utilisés avec d'autres
services. Cela inclut actuellement les définitions d'images et de métadonnées.
Les services d'imagerie Glance incluent la découverte, l'enregistrement et la récupération d'images de machines virtuelles (VM). Glance dispose d'une API RESTful qui
permet d'interroger les métadonnées de l'image VM ainsi que de récupérer l'image réelle.
Les images de machines virtuelles mises à disposition via Glance peuvent être stockées dans divers emplacements, des systèmes de fichiers simples aux systèmes de
stockage d'objets comme le projet OpenStack Swift.
PARTIE 2

Identificateurs d'image
Les images sont identifiées de manière unique au moyen d'un URI qui correspond à la signature suivante :
<Glance Server Location>/v1/images/<ID>
où
<Glance Server Location> est l'emplacement de la ressource du service Glance qui connaît une image,
<ID> est l'identifiant de l'image,
Les identifiants d'image dans Glance sont des uuids, ce qui les rend globalement uniques.
Formats de disque
Lors de l'ajout d'une image à Glance, spécifier le format de disque et le format de conteneur de l'image de la machine virtuelle.
Les formats de disque et de conteneur sont configurables pour chaque déploiement.
Formater le disque
PARTIE 2
Le format de disque d'une image de machine virtuelle est le format de l'image de disque sous-jacente.
Les fournisseurs d'appliances virtuelles ont différents formats pour disposer les informations contenues dans une image disque de machine virtuelle.
Il est nécessaire de définir le format de disque de l’image sur l'un des formats.

Formats de disque
VHD
Il s'agit du format de disque VHD (Virtual Hard Disk), un format de disque courant utilisé par les moniteurs de machines virtuelles de VMware, Xen, Microsoft, VirtualBox
vhdx
Il s'agit du format VHDX, une version améliorée du vhdformat. Il prend en charge des tailles de disque plus importantes et une protection contre la corruption des données
lors de pannes de courant.
vmdk
Le format VMDK (Virtual Machine Disk) est pris en charge par de nombreux moniteurs de machines virtuelles courants, par exemple l'hyperviseur VMware ESXi.
vdi
Le format VDI (Virtual Disk Image) pour les fichiers image est pris en charge par le moniteur de machine virtuelle VirtualBox et l'émulateur QEMU.
iso
Le format ISO est une image disque formatée avec le système de fichiers en lecture seule ISO 9660 (également appelé ECMA-119) couramment utilisé pour les CD et les
DVD.
PARTIE 2
bouc
Un format de disque pris en charge et utilisé par Virtuozzo pour exécuter des conteneurs OS.
qcow2
Le format QCOW2 (QEMU copy-on-write version 2) est couramment utilisé avec l'hyperviseur KVM. Il utilise une représentation de sorte que la taille de l'image est
inférieure à celle d'un fichier au format brut du même disque virtuel.

CHAPITRE 1

personnalisée
Création d’une VM via le catalogue et via une image
personnalisée
Définir les options de l’instance

• Pour lancer une instance, au minimum spécifier le gabarit, le nom de l’image, le réseau, le groupe de sécurité, la clé et le nom de l’instance.
• Sur le contrôleur, sourcer les crédentiels demo pour obtenir l’accès aux commandes en ligne non
privilégiées :
$ . demo-openrc
• Un gabarit définit un profil d’allocation de ressources virtuelles qui inclut le processeur, le mémoire
et le stockage.
Lister les gabarits disponibles :
$ openstack flavor list

+----+-----------+-------+------+-----------+-------+-----------+
| ID | Name | RAM | Disk | Ephemeral | VCPUs | Is Public |
+----+-----------+-------+------+-----------+-------+-----------+
| 1 | m1.tiny | 512 | 1 | 0 | 1 | True |
| 2 | m1.small | 2048 | 20 | 0 | 1 | True |
PARTIE 2
| 3 | m1.medium | 4096 | 40 | 0 | 2 | True |

| 4 | m1.large | 8192 | 80 | 0 | 4 | True |
| 5 | m1.xlarge | 16384 | 160 | 0 | 8 | True |
+----+-----------+-------+------+-----------+-------+-----------+

personnalisée

• Pour créer une instance, commencer par lister les images disponibles ainsi que les réseaux.
• Lister les images disponibles :
$ openstack image list

+--------------------------------------+--------+--------+
| ID | Name | Status |
+--------------------------------------+--------+--------+
| 390eb5f7-8d49-41ec-95b7-68c0d5d54b34 | cirros | active |
+--------------------------------------+--------+--------+
Cette instance utilise l’image cirros.
• Lister les réseaux disponibles :

$ openstack network list
+--------------------------------------+--------------+--------------------------------------+
| ID | Name | Subnets |
PARTIE 2
+--------------------------------------+--------------+--------------------------------------+
| 4716ddfe-6e60-40e7-b2a8-42e57bf3c31c | selfservice | 2112d5eb-f9d6-45fd-906e-7cabd38b7c7c |
| b5b6993c-ddf9-40e7-91d0-86806a42edb8 | provider | 310911f6-acf0-4a47-824e-3032916582ff |
+--------------------------------------+--------------+--------------------------------------+

personnalisée

• Avant de créer une instance, lister les groupes de sécurité disponibles.
• Lister les groupes de sécurité disponibles :
$ openstack security group list

+--------------------------------------+---------+------------------------+
| ID | Name | Description |
+--------------------------------------+---------+------------------------+
| dd2b614c-3dad-48ed-958b-b155a3b38515 | default | Default security group |
+--------------------------------------+---------+------------------------+
Cette instance utilise le groupe de sécurité default.

PARTIE 2

personnalisée
Lancer l’instance
$ openstack server create --flavor m1.tiny --image cirros \
• La commande ci-après crée une instance de calcul avec --nic net-id=PROVIDER_NET_ID --security-group default \
--key-name mykey provider-instance
des paramètres spécifiques pour l’image, le groupe de
sécurité ainsi que le modèle de machine. +--------------------------------------+-----------------------------------------------+
| Property | Value |
+--------------------------------------+-----------------------------------------------+
| OS-DCF:diskConfig | MANUAL |
| OS-EXT-AZ:availability_zone | nova |
| OS-EXT-STS:power_state | 0 |
| OS-EXT-STS:task_state | scheduling |
| OS-EXT-STS:vm_state | building |
| OS-SRV-USG:launched_at | - |
| OS-SRV-USG:terminated_at | - |
| accessIPv4 | |
| accessIPv6 | |
| adminPass | hdF4LMQqC5PB |
| config_drive | |
| created | 09-17T21:58:18Z |
| flavor | m1.tiny (1) |
| hostId | |
| id | 181c52ba-aebc-4c32-a97d-2e8e82e4eaaf |
| image | cirros (38047887-61a7-41ea-9b49-27987d5e8bb9) |
| key_name | mykey |
| metadata | {} |
| name | provider-instance |
PARTIE 2
| os-extended-volumes:volumes_attached | [] |
| progress | 0 |
| security_groups | default |
| status | BUILD |
| tenant_id | f5b2ccaa75ac413591f12fcaa096aa5c |
| updated | 2015-09-17T21:58:18Z |
| user_id | 684286a9079845359882afc3aa5011fb |
+--------------------------------------+-----------------------------------------------+

CHAPITRE 1

personnalisée
Gestion d'une instance avec les commandes
Vérifier le statut de l’instance :

• Suivre le processus de mise à disposition de l’instance avec la commande suivante :
$ openstack server list

+--------------------------------------+-------------------+--------+---------------------------------+
| ID | Name | Status | Networks |
+--------------------------------------+-------------------+--------+---------------------------------+
| 181c52ba-aebc-4c32-a97d-2e8e82e4eaaf | provider-instance | ACTIVE | provider=203.0.113.103 |
+--------------------------------------+-------------------+--------+---------------------------------+
Le statut passe de BUILD à ACTIVE quand le processus de construction se termine correctement.

PARTIE 2

Accéder à l’instance via la console virtuelle
• Obtenir une URL de session Virtual Network Computing (VNC) pour votre instance et y accéder via un navigateur web :
$ openstack console url show provider-instance

+-------+---------------------------------------------------------------------------------+
| Field | Value |
+-------+---------------------------------------------------------------------------------+
| type | novnc |
| url | http://controller:6080/vnc_auto.html?token=5eeccb47-525c-4918-ac2a-3ad1e9f1f493 |
+-------+---------------------------------------------------------------------------------+
PARTIE 2

Accéder à l’instance à distance

• Vérifier la connectivité à l’instance depuis le contrôleur ou tout autre hôte sur le réseau physique :
$ ping -c 4 203.0.113.103
PING 203.0.113.103 (203.0.113.103) 56(84) bytes of data.
64 bytes from 203.0.113.103: icmp_req=1 ttl=63 time=3.18 ms
--- 203.0.113.103 ping statistics ---

4 packets transmitted, 4 received, 0% packet loss, time 3002ms
rtt min/avg/max/mdev = 0.929/1.539/3.183/0.951 ms
• Accéder à l'instance en SSH depuis le contrôleur ou tout autre hôte sur le réseau physique :
$ ssh cirros@203.0.113.103
The authenticity of host '203.0.113.102 (203.0.113.102)' can't be established.
RSA key fingerprint is ed:05:e9:e7:52:a0:ff:83:68:94:c7:d1:f2:f8:e2:e9.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '203.0.113.102' (RSA) to the list of known hosts.
PARTIE 2

CHAPITRE 2
• Avoir une vue d'ensemble de la brique Quantum

• Découvrir la topologie de réseau et adressage IP
• Gérer des flux
• Interconnecter des ressources
9 heures
CHAPITRE 2
1. Vue d'ensemble de la brique Quantum

2. Topologie de réseau et Adressage IP
3. Gestion des flux
4. Interconnexion des ressources
02 - Configurer le réseau
Vue d'ensemble de la brique Quantum
Présentation du service de mise en réseau

Le service Réseau d’OpenStack (neutron) gère tous les aspects de l’Infrastructure de Réseau Virtuel (VNI) et ceux de la couche d’accès à l’Infrastructure de Réseau Physique
(PNI) dans votre environnement OpenStack. Le service réseau OpenStack permet aux tenants de créer des topologies avancées de réseaux virtuels qui peuvent inclure des
services comme un firewall, un load balancer et un réseau privé virtuel (VPN).
Le service Réseau fournit des abstractions de réseaux, de sous-réseaux et de routeurs. Chaque abstraction a des fonctionnalités qui imitent leurs homologues physiques :
les réseaux contiennent des sous-réseaux et les routeurs acheminent le trafic entre les différents réseaux et sous-réseaux.
Toute configuration Réseau comporte au moins un réseau externe. A la différence des autres réseaux, le réseau externe n’est pas simplement un réseau défini
virtuellement. Il représente une vue d’une partie du réseau physique externe accessible à l’extérieur de l’installation OpenStack. Les adresses IP du réseau externe sont
accessibles par n’importe qui physiquement connectés au réseau extérieur.
En plus des réseaux externes, toute configuration réseau comporte un ou plusieurs réseaux internes. Ces réseaux définis par logiciel se connectent directement aux VMs.
Seules les VMs d’un réseau interne donné, ou celles de sous-réseaux connectés par des interfaces sur le même routeur, peuvent accéder directement aux VMs connectées
à ce réseau.
PARTIE 2


Pour que le réseau extérieur accède aux VMs, et vice versa, des routeurs entre les réseaux sont nécessaires.
Chaque routeur possède une passerelle connectée à un réseau externe et une ou plusieurs interfaces connectées aux réseaux internes.
Comme avec un routeur physique, les sous-réseaux peuvent accéder aux machines sur d’autres sous-réseaux connectés au même routeur, et les machines peuvent
accéder au réseau extérieur via la passerelle du routeur.
Il est également possible de translater des adresses IP du réseaux externes vers le réseau interne.
La translation d’adresse peut être statique ou dynamique via des ports.
Ce mécanisme permet d’associer des adresses IP du réseau externe aux VMs.
Les VMs sont ainsi joignable depuis le réseau externe.
Le service Réseau supporte aussi les groupes de sécurité. Les Groupes de Sécurité permettent aux administrateurs de regrouper des règles de filtrage.
Une VM peut appartenir à un ou plusieurs groupes de sécurité et le service Réseau applique les règles dans ces groupes de sécurité pour interdire ou autoriser des ports,
PARTIE 2
des plages de ports ou des types de trafic pour cette VM.
Toutes les installations Réseau utilisent un core plugin et un plugin security group.
Des plugins Firewall-as-a-Service (FWaaS) et Load-Balancer-as-a-Service (LBaaS) sont également disponibles.


OpenStack Networking (neutron) permet de créer et de connecter des périphériques d'interface gérés par d'autres services OpenStack à des réseaux.
Des plug-ins peuvent être implémentés pour s'adapter à différents équipements et logiciels de mise en réseau, offrant une flexibilité à l'architecture et au déploiement
d'OpenStack.
Il comprend les éléments suivants :
• neutron-server
Accepte et achemine les demandes d'API vers le plug-in OpenStack Networking approprié pour action.
• Plug-ins et agents OpenStack Networking
Branche et débranche les ports, crée des réseaux ou des sous-réseaux et fournit un adressage IP.
OpenStack Networking est livré avec des plug-ins et des agents pour les commutateurs virtuels et physiques Cisco, les produits NEC OpenFlow, Open vSwitch, le pont Linux
et le produit VMware NSX.
Les agents communs sont L3 (couche 3), DHCP (adressage IP dynamique de l'hôte) et un agent de plug-in.
• File d'attente de messagerie
PARTIE 2
Utilisé par la plupart des installations, OpenStack Networking pour acheminer les informations entre le serveur neutron et divers agents. Agit également comme une base
de données pour stocker l'état du réseau pour des plug-ins particuliers.
• OpenStack Networking interagit principalement avec OpenStack Compute pour fournir des réseaux et une connectivité pour ses instances.

CHAPITRE 2

3. Gestion des flux
Topologie de réseau et Adressage IP
Exemple de topologie réseau

• Afin d’assurer une étanchéité au niveau réseau, un réseau de
gestion est dédié et séparé du réseau d’accès.
• Les contrôleurs ont idéalement deux interfaces et sont à cheval
sur les deux réseaux.
• Les accès Internet depuis le réseau de management sont
réalisés via NAT
PARTIE 2

Topologie de réseau et Adressage IP
Exemple de modèle de déploiement

Le diagramme illustre un exemple de déploiement OpenStack
Networking.
Un nœud OpenStack Networking dédié effectuant le routage de
couche 3 et DHCP, et exécutant l'équilibrage de charge en tant
que service (LBaaS).
Deux nœuds de calcul exécutent Open vSwitch (openvswitch-
agent) et disposent chacun de deux cartes réseau physiques, une
pour le trafic des locataires et une autre pour la connectivité de
gestion.
Le nœud OpenStack Networking possède une troisième carte
réseau spécifiquement pour le trafic fournisseur.
PARTIE 2

CHAPITRE 2

3. Gestion des flux
Gestion des flux
Architecture réseau
OpenStack Networking est un service autonome qui déploie souvent plusieurs processus sur plusieurs nœuds.
Ces processus interagissent entre eux et avec d'autres services OpenStack.
Le processus principal du service OpenStack Networking est neutron-server.
C’est un démon Python qui expose l'API OpenStack Networking et transmet les demandes des locataires à une suite de plug-ins pour un traitement supplémentaire.
Les composants OpenStack Networking sont :
Serveur neutron ( neutron-server et neutron-*-plugin )

Ce service s'exécute sur le nœud de réseau pour desservir l'API de mise en réseau et ses extensions. Il applique également le modèle de réseau et l'adressage IP de chaque
port. Le serveur de neutrons nécessite un accès indirect à une base de données persistante. Ceci est accompli grâce à des plugins, qui communiquent avec la base de
données en utilisant AMQP (Advanced Message Queuing Protocol).
Agent de plugin ( neutron-*-agent )
PARTIE 2
S'exécute sur chaque nœud de calcul pour gérer la configuration du commutateur virtuel local (vswitch). Le plug-in utilisé détermine les agents exécutés. Ce service
nécessite un accès à la file d'attente des messages et dépend du plugin utilisé. Certains plugins comme OpenDaylight (ODL) et Open Virtual Network (OVN) ne nécessitent
aucun agent python sur les nœuds de calcul.

Gestion des flux
Agent DHCP ( neutron-dhcp-agent )
Fournit des services DHCP aux réseaux de locataires.
Cet agent est le même pour tous les plug-ins et est responsable de la maintenance de la configuration DHCP.
L'agent neutron-dhcp nécessite un accès à la file d'attente des messages. Facultatif selon le plug-in.
Agent L3 ( neutron-l3-agent )
Fournit le transfert L3/NAT pour l'accès réseau externe des machines virtuelles sur les réseaux locataires.
Nécessite un accès à la file d'attente des messages. Facultatif selon le plug-in.
Services du fournisseur de réseau ( serveur/services SDN )

Fournit des services de mise en réseau supplémentaires aux réseaux de locataires.
Ces services SDN peuvent interagir avec neutron-server, neutron-plugin et plugin-agents via des canaux de communication tels que les API REST.
PARTIE 2

Gestion des flux
Organigramme d'architecture et de mise en réseau des
composants de mise en réseau OpenStack :
PARTIE 2

Gestion des flux
Placement du service OpenStack Networking sur des serveurs physiques

Architecture standard qui comprend un hôte de
contrôleur Cloud, un hôte réseau et un ensemble
d'hyperviseurs de calcul pour l'exécution de machines
virtuelles.
PARTIE 2

Gestion des flux
Connectivité réseau des serveurs physiques

Une configuration de mise en réseau OpenStack standard comporte jusqu'à quatre réseaux de centres de données physiques distincts :
Réseau de gestion
Utilisé pour la communication interne entre les composants OpenStack.
Les adresses IP sur ce réseau doivent être accessibles uniquement dans le centre de données et sont considérées comme le domaine de sécurité de gestion.
Réseau d'invités
Utilisé pour la communication de données VM dans le déploiement Cloud.
Les exigences d'adressage IP de ce réseau dépendent du plug-in OpenStack Networking utilisé et des choix de configuration réseau des réseaux virtuels effectués par le
locataire. Ce réseau est considéré comme le domaine de sécurité invité.
Réseau externe
Utilisé pour fournir aux machines virtuelles un accès Internet dans certains scénarios de déploiement.
Les adresses IP de ce réseau doivent être accessibles par n'importe qui sur Internet.
Ce réseau est considéré comme faisant partie du domaine de la sécurité publique.
PARTIE 2
Réseau API
Expose toutes les API OpenStack, y compris l'API OpenStack Networking, aux locataires. Les adresses IP de ce réseau doivent être accessibles par n'importe qui sur
Internet. Il peut s'agir du même réseau que le réseau externe, avec la possibilité de créer un sous-réseau du réseau externe. Ce réseau est considéré comme le domaine de
la sécurité publique.

Gestion des flux
Services de mise en réseau

Dans les phases architecturales initiales de la conception de l’infrastructure réseau OpenStack, il est important de s'assurer d’une bonne conception de l'infrastructure
réseau physique, pour identifier les contrôles de sécurité et les mécanismes de gestion de flux appropriés.
OpenStack Networking ajoute une couche de services réseau virtualisés qui donne aux locataires la possibilité de concevoir leurs propres réseaux virtuels.
Actuellement, ces services virtualisés ne sont pas aussi matures que leurs homologues de mise en réseau traditionnels.
Tenir compte de l'état actuel de ces services virtualisés avant de les adopter, ceci conditionne les contrôles à mettre en œuvre aux limites des réseaux virtualisés et
traditionnels.
Isolation L2 à l'aide de VLAN et de tunnels
OpenStack Networking peut utiliser deux mécanismes différents pour la ségrégation du trafic sur une combinaison locataire/réseau : VLAN (balisage IEEE 802.1Q) ou
tunnels L2 utilisant l'encapsulation.
La portée et l'échelle du déploiement OpenStack déterminent la méthode à utiliser pour la ségrégation ou l'isolation du trafic.
• VLAN
Les VLAN sont réalisés sous forme de paquets sur un réseau physique spécifique contenant des en-têtes IEEE 802.1Q avec une valeur de champ ID VLAN (VID) spécifique.
Les réseaux VLAN partageant le même réseau physique sont isolés les uns des autres au niveau L2 et peuvent même avoir des espaces d'adressage IP qui se chevauchent.
PARTIE 2
Chaque réseau physique distinct prenant en charge les réseaux VLAN est traité comme un tronc VLAN distinct, avec un espace distinct de valeurs VID. Les valeurs VID
valides vont de 1 à 4094.
La complexité de la configuration VLAN dépend des exigences de conception OpenStack. Afin de permettre à OpenStack Networking d'utiliser efficacement les VLAN, il est
nécessaire d’allouer une plage de VLAN (une pour chaque locataire) et transformer chaque port de commutateur physique de nœud de calcul en un port de jonction VLAN.

Gestion des flux

• Tunnellisation L2
Le tunneling réseau encapsule chaque combinaison locataire/réseau avec un « identifiant de tunnel » unique qui est utilisé pour identifier le trafic réseau appartenant à
cette combinaison.
La connectivité réseau L2 du locataire est indépendante de la localité physique ou de la conception du réseau sous-jacent.
En encapsulant le trafic à l'intérieur des paquets IP, ce trafic peut traverser les limites de la couche 3, éliminant ainsi le besoin de VLAN préconfigurés et de jonction VLAN.
Le tunneling ajoute une couche d'obscurcissement au trafic de données réseau, réduisant la visibilité du trafic des locataires individuels du point de vue de la surveillance.
OpenStack Networking prend actuellement en charge l'encapsulation GRE et VXLAN.
Le choix de la technologie pour fournir l'isolation L2 dépend de l'étendue et de la taille des réseaux de locataires qui seront créés dans le déploiement.
Si l’environnement a une disponibilité limitée d'ID VLAN ou aura un grand nombre de réseaux L2. Il est alors recommandé d'utiliser le tunneling.
Listes de contrôle d'accès
OpenStack Compute prend en charge les contrôles d'accès au trafic réseau des locataires directement lorsqu'il est déployé avec le service nova-network, ou peut différer
le contrôle d'accès au service OpenStack Networking.
Noter que les groupes de sécurité nova-network hérités sont appliqués à tous les ports d'interface virtuelle sur une instance utilisant iptables.
PARTIE 2
Les groupes de sécurité permettent aux administrateurs et aux locataires de spécifier le type de trafic et la direction (entrée/sortie) autorisés à passer par un port
d'interface virtuelle. Les règles des groupes de sécurité sont des filtres de trafic L2-L4 avec état.
Il est recommandé d'activer les groupes de sécurité dans ce service et de les désactiver dans le service Compute.

Gestion des flux

Routage L3 et NAT
Les routeurs OpenStack Networking peuvent connecter plusieurs réseaux L2 et peuvent également fournir une passerelle qui connecte un ou plusieurs réseaux L2 privés à
un réseau externe partagé, tel qu'un réseau public pour l'accès à Internet.
Le routeur L3 fournit des fonctionnalités de base de traduction d'adresses réseau (NAT) sur les ports de passerelle qui relient le routeur aux réseaux externes.
Ce routeur SNAT (NAT statique) tout le trafic par défaut et prend en charge les adresses IP flottantes, ce qui crée un mappage statique un à un d'une adresse IP publique
sur le réseau externe à une adresse IP privée sur l'un des autres sous-réseaux connectés au routeur.
Il est recommandé de tirer parti du routage L3 par locataire et des adresses IP flottantes pour une connectivité plus granulaire des machines virtuelles locataires.
Qualité de service (QoS)

Par défaut, les politiques et les règles de qualité de service (QoS) sont gérées par l'administrateur du Cloud, ce qui empêche les locataires de créer des règles QoS
spécifiques ou d'attacher des ports spécifiques aux politiques.
Dans certains cas d'utilisation, comme certaines applications de télécommunications, l'administrateur peut déléguer aux locataires et donc les laisser créer et attacher
leurs propres politiques aux ports.
PARTIE 2
Le service de mise en réseau (neutron) prend en charge les règles de QoS limitant la bande passante.

Gestion des flux

Équilibrage de charge
Une autre fonctionnalité d'OpenStack Networking est Load-Balancer-as-a-service (LBaaS).
L'implémentation de référence LBaaS est basée sur HA-Proxy.
Il existe des plug-ins tiers en cours de développement pour les extensions dans OpenStack Networking afin de fournir des fonctionnalités L4-L7 étendues pour les ports
d'interface virtuelle.
Pare-feu
FW-as-a-Service (FWaaS) est considéré comme une fonctionnalité expérimentale pour la version Kilo d'OpenStack Networking.
FWaaS répond au besoin de gérer et d'exploiter le riche ensemble de fonctionnalités de sécurité fournies par les produits de pare-feu typiques qui sont généralement
beaucoup plus complets que ce qui est actuellement fourni par les groupes de sécurité.
Freescale et Intel ont tous les deux développé des plug-ins tiers en tant qu'extensions dans OpenStack Networking pour prendre en charge ce composant dans la version
Kilo.
Lors de la conception d'une infrastructure de mise en réseau OpenStack, il est important d’identifier les limites actuelles des services réseau disponibles.
PARTIE 2
Comprendre les limites des réseaux virtuel et physique aidera à ajouter les contrôles de sécurité requis dans l’environnement.

Gestion des flux
Principe de séparation des flux réseau

Importance de la séparation des réseaux :
L’architecture en exemple utilise un espace d’adresses privées pour le réseau des
ressources et suppose que l’infrastructure réseau physique fournit l’accès à Internet
via du NAT ou tout autre méthode.
Les architectures utilisent un espace d’adresses IP routables pour le réseau externe
et supposent que l’infrastructure réseau physique fournit un accès Internet direct.
Dans une architecture réseaux fournisseur, toutes les instances sont directement
connectées au réseau fournisseur.
Dans une architecture réseaux en self-service (privée), les instances peuvent
s’attacher à un réseau self-service ou au réseau fournisseur.
Les réseaux self-service peuvent résider entièrement à l’intérieur du périmètre
OpenStack ou fournir un certain niveau d’accès au réseau externe en utilisant le NAT
via le réseau fournisseur.
PARTIE 2

Gestion des flux
Principe de séparation des flux réseau
Tous les nœuds nécessitent un accès Internet pour des besoins administratifs comme l’installation de packages, de mises à jour de sécurité, le DNS et le NTP. Dans la
plupart des cas, les nœuds doivent avoir accès à Internet via l’interface réseau de management.
L’architecture en exemple suppose l’utilisation des réseaux suivants :

Management sur 10.0.0.0/24 avec la passerelle 10.0.0.1
Ce réseau nécessite une passerelle pour fournir un accès Internet à tous les nœuds pour des besoins administratifs comme l’installation de packages, de mises à jour de
sécurité, le DNS, et NTP.
Fournisseur sur 203.0.113.0/24 avec la passerelle 203.0.113.1

Ce réseau nécessite une passerelle pour fournir un accès Internet aux instances de l’environnement OpenStack.
PARTIE 2

CHAPITRE 2

3. Gestion des flux
Interconnexion des ressources
Configuration réseau des nœuds

Pour chaque nœud de l’environnement :
• Configurer les interfaces réseau
Configurer la première interface comme interface de management :
Adresse IP : 10.0.0.11
Netmask : 255.255.255.0 (ou /24)
Passerelle par défaut : 10.0.0.1
L’interface fournisseur utilise une configuration spéciale sans adresse IP assignée.

Configurer la seconde interface comme interface fournisseur.
Remplacer INTERFACE_NAME par le nom de l’interface réelle. Par exemple, eth1 ou ens224.
Éditer le fichier /etc/network/interfaces afin qu’il contienne ce qui suit :
# The provider network interface
auto INTERFACE_NAME
PARTIE 2
iface INTERFACE_NAME inet manual

up ip link set dev $IFACE up
down ip link set dev $IFACE down


Pour chaque nœud de l’environnement :
Configurer la résolution de nom

· Définir le hostname du nœud à contrôler.
· Editer le fichier /etc/hosts pour qu’il contienne ce qui suit :
# controller
10.0.0.11 controller
# compute1
10.0.0.31 compute1
# block1
10.0.0.41 block1
# object1
10.0.0.51 object1
PARTIE 2
# object2
10.0.0.52 object2


Réseau fournisseur
Pour ce réseau, une instance utilise un réseau fournisseur (externe) qui se connecte à l’infrastructure réseau physique via la couche 2 (switching). Ce réseau inclut un
serveur DHCP qui fournit les adresses IP aux instances.
L’utilisateur admin ou tout autre utilisateur avec privilèges doit créer ce réseau parce qu’il se connecte directement à l’infrastructure de réseau physique.
PARTIE 2


Réseau self-service
Un réseau self-service (privé) se connecte à l’infrastructure réseau
physique via NAT.
Ce réseau inclut un serveur DHCP qui fournit des adresses IP aux
instances.
Une instance sur ce réseau peut accéder automatiquement aux réseaux
externes comme Internet.
Néanmoins, l’accès à une instance de ce réseau à partir d’un réseau
externe comme Internet nécessite une adresse IP flottante.
Tout utilisateur sans privilèges peut créer ce réseau parce qu’il fournit la
connectivité uniquement aux instances du projet de cet utilisateur.
PARTIE 2

CHAPITRE 3
• Avoir une vue d'ensemble sur Swift

• Gérer des pools de stockage
• Mettre en œuvre du stockage en mode bloc avec Cinder
• Connaitre le backend supportés par Cinder
9 heures
CHAPITRE 3
1. Vue d'ensemble de Swift

2. Gestion des pools de stockage
3. Mise en œuvre du stockage en mode bloc avec Cinder
4. Backend supportés par Cinder
03 - Stocker des données
Vue d'ensemble de Swift
Présentation stockage objet

Lors de la sortie d'OpenStack en 2010, Rackspace a fourni le code source de son produit « Cloud Files » en tant que code initial pour le composant de stockage d'objets
OpenStack Object Storage (maintenant Swift).
Le but est de fournir un stockage redondant et massivement évolutif sur toutes les plates-formes matérielles de base.
Le modèle de base de ce service s'inspire des serveurs de stockage Amazon S3 et est géré de la même manière.
Le stockage en mode objet est une structure plate dans laquelle les fichiers sont décomposés en éléments et répartis sur du matériel. Avec le stockage en mode objet, les
données sont décomposées en petites unités distinctes appelées objets et sont conservées dans un référentiel unique.
La figure suivante schématise le mode de stockage en objet :
PARTIE 2


Object Storage utilise les composants suivants pour offrir une haute disponibilité, une haute durabilité et une simultanéité élevée :
• Serveurs proxy - Gèrent toutes les requêtes API entrantes.
• Anneaux - Mapper les noms logiques des données à des emplacements sur des disques particuliers.
• Zones - Isoler les données des autres zones. Une défaillance dans une zone n'a pas d'impact sur le reste du cluster car les données sont répliquées dans les
zones.
• Comptes et conteneurs - Chaque compte et conteneur sont des bases de données individuelles réparties sur le cluster. Une base de données de compte
contient la liste des conteneurs de ce compte. Une base de données de conteneur contient la liste des objets de ce conteneur.
• Objets - Les données elles-mêmes.
• Partitions - Une partition stocke des objets, des bases de données de comptes et des bases de données de conteneurs et aide à gérer les emplacements où les
données résident dans le cluster.
PARTIE 2


Object Storage utilise les composants suivants pour offrir une haute disponibilité, une haute durabilité et une simultanéité élevée :
PARTIE 2

Présentation de Swift
Swift est un magasin d'objets hautement disponible, distribué et cohérent.
Les organisations peuvent utiliser Swift pour stocker de nombreuses données de manière efficace, sûre et à moindre coût.
Le service stocke et récupère des objets de données non structurées via une API RESTful basée sur HTTP.
Le service est hautement tolérant aux pannes avec sa réplication de données et son architecture de type scale-out.
Son implémentation diffère des serveurs de fichiers à répertoires montables.
Le service écrit les objets et les fichiers vers plusieurs disques, en s’assurant que les données sont répliquées sur un cluster de serveurs.
PARTIE 2

Présentation de Swift
Architecture réseau de stockage objet avec nœud de gestion :

PARTIE 2

Présentation du service de stockage d'objets

Le stockage d'objets OpenStack est un système de stockage d'objets multi-tenant. Il est hautement évolutif et peut gérer de grandes quantités de données non structurées
à faible coût via une API HTTP RESTful.
Elle comprend les éléments suivants :
Serveurs proxy (Swift-proxy-server)

Accepte l'API OpenStack Object Storage et les requêtes HTTP brutes pour télécharger des fichiers, modifier des métadonnées et créer des conteneurs. Il fournit également
des listes de fichiers ou de conteneurs aux navigateurs Web. Pour améliorer les performances, le serveur proxy peut utiliser un cache facultatif qui est généralement
déployé avec Memcache.
Serveurs de compte (Swift-account-server)
Gère les comptes définis avec Object Storage.
Serveurs de conteneurs (Swift-container-server)
Gère le mappage des conteneurs ou des dossiers, dans Object Storage.
PARTIE 2
Serveurs d'objets (Swift-object-server)

Gère les objets réels, tels que les fichiers, sur les nœuds de stockage.

Présentation du service de stockage d'objets

Divers processus périodiques
Effectue des tâches d'entretien sur le grand magasin de données. Les services de réplication garantissent la cohérence et la disponibilité via le cluster. D'autres processus
périodiques incluent les auditeurs, les mises à jour et les moissonneurs.
Intergiciel WSGI
Gère l'authentification et est généralement OpenStack Identity.
client rapide
Permet aux utilisateurs de soumettre des commandes à l'API REST via un client de ligne de commande autorisé en tant qu'utilisateur administrateur, utilisateur revendeur
ou utilisateur rapide.
initialisation rapide
Script qui initialise la construction du fichier ring, prend les noms de démons en paramètre et propose des commandes.
reconnaissance rapide
Un outil CLI (command line interface, ou bien interface en ligne de commande) utilisé pour récupérer diverses métriques et informations de télémétrie sur un cluster qui
ont été collectées par le middleware Swift-recon.
PARTIE 2
constructeur d'anneaux rapides

Utilitaire de création et de rééquilibrage de l'anneau de stockage.

CHAPITRE 3

Gestion des pools de stockage
Installer et configurer les nœuds de stockage

Bien que le Stockage Objet supporte tout système de fichier avec des attributs étendus (xattr), des tests et des benchmarks ont montré les meilleures performances et
meilleure fiabilité sur XFS. La gestion des nœuds de stockage permet le dimensionnement horizontal de l’environnement.
Les nœuds de stockage font tourner les services compte, conteneur et objet. Pour simplifier, cette configuration référence deux nœuds de stockage, chacun contenant
deux devices de stockage bloc locaux et vides. Les consignes utilisent /dev/sdb et /dev/sdc, mais il est possible de substituer par des valeurs différentes en fonction de la
configuration des nœuds.
Prérequis
Avant d’installer et configurer le service de Stockage Objet sur les nœuds de stockage, préparer les devices de stockage.
# apt-get install xfsprogs rsync
Installer et configurer les composants

# apt-get install swift swift-account swift-container swift-object
PARTIE 2

Architecture de stockage
Il existe de nombreuses architectures de stockage différentes disponibles lors de la conception d'un Cloud OpenStack.
La convergence de l'orchestration et de l'automatisation au sein de la plate-forme OpenStack permet un provisionnement rapide du stockage sans les problèmes des processus manuels
traditionnels tels que la création et la connexion de volumes.
Cependant, avant de choisir une architecture de stockage, il convient de répondre à quelques questions génériques :
• L'architecture de stockage évoluera-t-elle de manière linéaire à mesure que le Cloud se développe et quelles sont ses limites ?
• Quelle est la méthode de connexion souhaitée : NFS, iSCSI, FC ou autre ?
• Le stockage est-il compatible avec la plateforme OpenStack ?
• Quel est le niveau de support fourni par le fournisseur au sein de la communauté ?
• Quelles fonctionnalités et améliorations d'OpenStack le pilote Cinder active-t-il ?
• Inclut-il des outils pour aider à dépanner et résoudre les problèmes de performances ?
• Est-il interopérable avec tous les projets envisagés ?

PARTIE 2

Choix des back-ends de stockage

Les usages indiqueront différents besoins d’architecture Cloud.
Certains peuvent avoir besoin d'un accès rapide à de nombreux objets qui ne changent pas souvent, ou souhaitent définir une valeur de durée de vie (TTL) sur un fichier.
D'autres peuvent accéder uniquement au stockage monté avec le système de fichiers lui-même, mais souhaitent qu'il soit répliqué instantanément lors du démarrage d'une nouvelle
instance.
Pour d’autres systèmes, le stockage éphémère est le choix préféré. Lors de la sélection des back-ends de stockage, tenir compte des questions suivantes du point de vue de l'utilisateur :
Tout d'abord:
Ai-je besoin d'un stockage en bloc ?
Ai-je besoin d'un stockage d'objets ?
Ai-je besoin d'un stockage basé sur des fichiers ?
Ensuite, préciser les questions suivantes :

PARTIE 2
Les disques de stockage persistants doivent-ils être contenus dans les nœuds de calcul ou dois-je utiliser un stockage externe ?
De quel type de performances ai-je besoin en termes d'IOPS ? Total IOPS et IOPS par instance ? Ai-je des applications avec des SLA IOPS ?
Mes besoins de stockage sont-ils principalement en lecture, en écriture ou mixtes ?

Créer et attacher un volume à une instance

Configurer les services OpenStack Compute et OpenStack Block Storage via le fichier /etc/Cinder/Cinder.conf.
• Utiliser la commande OpenStack volume create pour créer un volume. La commande crée un LV dans le groupe de volumes (VG) Cinder-volumes.
• Utiliser la commande OpenStack server add volume pour attacher le volume à une instance. Cette commande crée un lien IQN unique qui est exposé au nœud de
calcul.
• Le nœud de calcul, qui exécute l'instance, dispose désormais d'une session active et d'un nouveau stockage local (/dev/sdX).
• L'instance obtient un nouveau disque (/dev/vdX).
Gestionnaire de volume logique (LVM)

• Permet l'allocation d'espace sur les périphériques de stockage de masse qui est plus flexible que les schémas de partitionnement conventionnels.
Nom qualifié iSCSI (IQN) :

PARTIE 2
• Identifie de manière unique les nœuds d'un réseau de stockage. Tous les IQN suivent le modèle de nommage déterminé

Gérer les volumes de stockage

Selon la configuration du fournisseur du stockage, les point de terminaison à utiliser pour gérer les volumes diffèrent.
Dans tous les cas, utiliser OpenStack CLI pour gérer les volumes.
Commandes de gestion des volumes OpenStack
Commande Description
server add volume Attacher un volume à un serveur.
volume create Ajouter un nouveau volume.
volume delete Supprimer ou supprimer un volume.
server remove volume Détacher ou supprimer un volume d'un serveur.
volume list Lister tous les volumes.
volume show Afficher les détails d'un volume.
snapshot create Ajouter un nouvel instantané.
snapshot delete Supprimer un instantané.
snapshot list Lister tous les instantanés.
PARTIE 2
snapshot show Afficher les détails d'un instantané.

volume type create Créer un nouveau type de volume.
volume type delete Supprimer une saveur spécifique
volume type list Lister les 'types de volumes' disponibles.

CHAPITRE 3

Mise en œuvre du stockage en mode bloc avec Cinder
Service de Stockage Bloc

Le service de Stockage Bloc (Cinder) fournit des devices de stockage bloc aux instances invitées. La méthode avec laquelle le stockage est provisionné et consommé est
déterminée par le driver de Stockage Bloc, ou les drivers dans le cas d’une configuration multi-backends.
Cinder fournit des périphériques persistants de type bloc aux instances OpenStack. Il gère les opérations de création, d’attachement et de détachement de ces
périphériques sur les serveurs. En plus du stockage local sur le serveur, Cinder peut utiliser de multiples plateformes de stockage tel que Ceph, EMC (ScaleIO, VMAX et
VNX), GlusterFS, Hitachi Data Systems, IBM Storage (Storwize family, SAN Volume Controller, XIV Storage System, et GPFS), NetApp, HP (StoreVirtual et 3PAR) et bien
d’autres.
Le stockage en mode bloc est utilisé pour des scénarios performant comme celui du stockage de base de données, mais aussi pour fournir au serveur un accès bas niveau
au périphérique de stockage. Cinder gère aussi la création d’instantanés (snapshots), très utile pour sauvegarder des données contenues dans les périphériques de type
bloc. Les instantanés peuvent être restaurés ou utilisés pour créer de nouveaux volumes.
Les services API et scheduler du Stockage Bloc tournent généralement sur les contrôleurs. En fonction des drivers utilisés, le service de volume peut tourner sur les
contrôleurs, sur les nœuds Compute ou sur des nœuds de stockage autonomes.
PARTIE 2

Service de Stockage Bloc

Le service de Stockage Bloc (Cinder) fournit des devices de stockage bloc aux instances invitées.
PARTIE 2

Présentation du service de stockage de blocs

Le service OpenStack Block Storage (Cinder) ajoute un stockage persistant à une machine virtuelle. Block Storage fournit une infrastructure de gestion des volumes et
interagit avec OpenStack Compute pour fournir des volumes aux instances. Le service permet également la gestion des instantanés de volume et des types de volume.
Le service Block Storage se compose des éléments suivants :
cendre-api
Accepte les demandes d'API et les achemine vers le volume Cinder pour action.
volume de cendre
Interagit directement avec le service Block Storage et les processus tels que le Cinder-scheduler. Il interagit également avec ces processus via une file d'attente de
messages. Le service Cinder-volume répond aux demandes de lecture et d'écriture envoyées au service Block Storage pour maintenir l'état. Il peut interagir avec une
variété de fournisseurs de stockage via une architecture de pilote.
démon Cinder-scheduler
Sélectionne le nœud de fournisseur de stockage optimal sur lequel créer le volume. Un composant similaire au nova-scheduler.
démon de sauvegarde Cinder
Le service Cinder-backup fournit des volumes de sauvegarde de tout type à un fournisseur de stockage de sauvegarde. Comme le service de volume de cendres, il peut
PARTIE 2
interagir avec une variété de fournisseurs de stockage via une architecture de pilote.
File d'attente de messagerie
Achemine les informations entre les processus de stockage de blocs.

Mise en œuvre du service de stockage de blocs

• Installer et configurer le nœud contrôleur
Prérequis
Avant d’installer et configurer le service de Stockage Bloc, vous devez créer une base de données, des crédentiels de service et les Endpoints API.
Configurer le service Compute pour utiliser le Stockage Bloc
• Installer et configurer un nœud de stockage
Prérequis
Avant d’installer et configurer le service de Stockage Bloc sur le nœud de stockage, préparer le device de stockage.
Installer les packages :
• # apt-get install Cinder-volume
Finaliser l’installation
PARTIE 2
Redémarrer le service de volume du Stockage Bloc, ainsi que ses dépendances.

CHAPITRE 3

Backend supportés par Cinder
Mise en situation du stockage Cinder
Le service OpenStack Block Storage assure la gestion des ressources de stockage de

blocs persistantes.
En plus d'agir en tant que stockage persistant attaché secondairement, il est
possible d’écrire des images dans un volume Cinder pour que Nova les utilise
comme volume racine persistant amorçable pour une instance.
Le service Block Storage était à l'origine d’un composant de Nova appelé nova-
volume, mais est devenu un projet officiel et indépendant dans la version Folsom.
Cinder est généralement déployé en conjonction avec d'autres services OpenStack
(par exemple, calcul, stockage d'objets, image, etc.) dans le cadre d'une
infrastructure Cloud plus vaste et plus complète. Il ne s'agit pas d'une exigence
explicite, car Cinder a été déployé avec succès en tant que solution autonome pour
le provisionnement du stockage en mode bloc et la gestion de son cycle de vie.
PARTIE 2
En tant que service de gestion, Cinder contrôle le provisionnement et la gestion du

cycle de vie des volumes de stockage en mode bloc. Il ne réside pas dans le chemin
d'E/S (données) entre l'hyperviseur et le contrôleur de stockage, comme illustré
dans la Figure.

Backend Cinder
Les backends servent de réceptacles pour la gestion du cycle de vie des données
Il est possible de configurer plusieurs backends de stockage Cinder
Plusieurs considérations d’architecture entrent en jeux avant de statuer sur le type et la technologie du backend à utiliser
PARTIE 2

Backend
• Blockbridge EPS • HPE LeftHand/StoreVirtual driver • ProphetStor Fibre Channel and iSCSI drivers
• Ceph RADOS Block Device (RBD) • HP MSA Fibre Channel and iSCSI drivers • Pure Storage iSCSI and Fibre Channel volume drivers
• CloudByte volume driver • Huawei volume driver • Quobyte driver
• Coho Data volume driver • IBM GPFS volume driver • Scality SOFS driver
• Dell EqualLogic volume driver • IBM Storwize family and SVC volume driver • Sheepdog driver
• Dell Storage Center Fibre Channel and iSCSI drivers • IBM XIV and DS8000 volume driver • SambaFS driver
• Dot Hill AssuredSAN Fibre Channel and iSCSI drivers • IBM FlashSystem volume driver • SolidFire
• EMC ScaleIO Block Storage driver configuration • ITRI DISCO volume driver • Tintri
• EMC VMAX iSCSI and FC drivers • Lenovo Fibre Channel and iSCSI drivers • Violin Memory 7000 Series FSP volume driver
• EMC VNX driver • LVM • VMware VMDK driver
• EMC XtremIO Block Storage driver configuration • NetApp unified driver • Windows iSCSI volume driver
• Fujitsu ETERNUS DX driver • Nimble Storage volume driver • X-IO volume driver
PARTIE 2
• GlusterFS driver • NexentaStor 4.x NFS and iSCSI drivers • Oracle ZFS Storage Appliance iSCSI driver
• HDS HNAS iSCSI and NFS driver • NexentaStor 5.x NFS and iSCSI drivers • Oracle ZFS Storage Appliance NFS driver
• Hitachi storage volume driver • NexentaEdge iSCSI driver
• HPE 3PAR Fibre Channel and iSCSI drivers • NFS driver

PARTIE 3
Explorer les services avancés d’OpenStack
• Gérer les identités

• Superviser les ressources
13 heures
CHAPITRE 1
• Appréhender la brique Keystone

• Créer des utilisateurs, des projets et des rôles
• Manipuler le service d’authentification
• Manipuler le service d’autorisation
6 heures
CHAPITRE 1
1. Présentation de la brique Keystone

2. Création des utilisateurs, projets et rôles
3. Service d’authentification
4. Service d’autorisation
01 - Gérer les identités
Présentation de la brique Keystone
Service d’identité
Fournit un service d’authentification et d’autorisation pour les autres services d’OpenStack.
Fournit un catalogue de Endpoints pour tous les services d’OpenStack.
Keystone est un service OpenStack qui fournit l'authentification du client API, la découverte de services et l'autorisation multi-locataire distribuée en implémentant l'API
Identity d'OpenStack.
Présentation du service d'identité
Le service OpenStack Identity fournit un point d'intégration unique pour la gestion des services d'authentification, d'autorisation et de catalogue de services.
D'autres services OpenStack utilisent le service Identity comme API unifiée commune. De plus, les services qui fournissent des informations sur les utilisateurs mais qui ne
sont pas inclus dans OpenStack (tels que les services LDAP) peuvent être intégrés dans une infrastructure préexistante.
PARTIE 3
Afin de bénéficier du service Identity, d'autres services OpenStack doivent collaborer avec lui. Lorsqu'un service OpenStack reçoit une requête d'un utilisateur, il vérifie
auprès du service Identity si cet utilisateur est autorisé à effectuer la requête.

Présentation de la brique Keystone
Service d’identité
Le service d'identité contient ces composants :
Serveur
Un serveur centralisé fournit des services d'authentification et d'autorisation à l'aide d'une interface RESTful.
Conducteurs
Des pilotes ou un back-end de service sont intégrés au serveur centralisé. Ils sont utilisés pour accéder aux informations d'identité dans des référentiels externes à
OpenStack et peuvent déjà exister dans l'infrastructure où OpenStack est déployé (par exemple, des bases de données SQL ou des serveurs LDAP).
Modules
Les modules middleware s'exécutent dans l'espace d'adressage du composant OpenStack qui utilise le service Identity. Ces modules interceptent les demandes de service,
extraient les informations d'identification des utilisateurs et les envoient au serveur centralisé pour autorisation. L'intégration entre les modules middleware et les
composants OpenStack utilise l'interface Python Web Server Gateway.
PARTIE 3
Lors de l'installation du service OpenStack Identity, il est nécessaire d’enregistrer chaque service dans l’installation OpenStack. Le service d'identité peut ensuite suivre les
services OpenStack installés et leur emplacement sur le réseau.

CHAPITRE 1

Création des utilisateurs, projets et rôles
Créer un domaine, des projets, des utilisateurs et des rôles

Le service d’Identité fournit les services authentification pour chaque service OpenStack. Le service d’authentification utilise une combinaison de domaines, projets
(tenants), utilisateurs, et rôles.
Créer le domaine default :
+-------------+----------------------------------+
| Field | Value |
+-------------+----------------------------------+
| description | Default Domain |
| enabled | True |
| id | e0353a670a9e496da891347c589539e9 |
| name | default |
+-------------+----------------------------------+
Créer un projet, un utilisateur et un rôle administrateur pour réaliser les opérations d’administration dans l’environnement :
Créer le projet admin : $ openstack project create --domain default \
--description "Admin Project" admin
+-------------+----------------------------------+
PARTIE 3
| Field | Value |
+-------------+----------------------------------+
| description | Admin Project |
| domain_id | e0353a670a9e496da891347c589539e9 |
| enabled | True |
| id | 343d245e850143a096806dfaefa9afdc |
| is_domain | False |
| name | admin |
| parent_id | None |
+-------------+----------------------------------+

Créer un domaine, des projets, des utilisateurs et des rôles

Créer l’utilisateur admin :
$ openstack user create --domain default \
--password-prompt admin
User Password:
Repeat User Password:
+-----------+----------------------------------+
| Field | Value |
+-----------+----------------------------------+
| domain_id | e0353a670a9e496da891347c589539e9 |
| enabled | True |
| id | ac3377633149401296f6c0d92d79dc16 |
| name | admin |
+-----------+----------------------------------+
Créer le rôle admin :

$ openstack role create admin
+-----------+----------------------------------+
| Field | Value |
+-----------+----------------------------------+
| domain_id | None |
| id | cd2cb9a39e874ea69e5d4b896eb16128 |
| name | admin |
+-----------+----------------------------------+
PARTIE 3
Ajouter le rôle admin au projet et à l’utilisateur admin :

$ OpenStack role add --project admin --user admin Séries

Mapping entre utilisateurs, rôles et projets

PARTIE 3

CHAPITRE 1

Service d’authentification
Notions d'identité
Authentification
Processus de confirmation de l'identité d'un utilisateur. Pour confirmer une demande entrante, OpenStack Identity valide un ensemble d'informations d'identification
fournies par les utilisateurs. Initialement, ces informations d'identification sont un nom d'utilisateur et un mot de passe, ou un nom d'utilisateur et une clé API.
Lorsqu'OpenStack Identity valide les informations d'identification de l'utilisateur, il émet un jeton d'authentification. Les utilisateurs fournissent le jeton dans les demandes
ultérieures.
Identifiants
Données qui confirment l'identité de l'utilisateur. Par exemple, nom d'utilisateur et mot de passe, nom d'utilisateur et clé API, ou un jeton d'authentification fourni par le
service d'identité.
Domaine
Une entité de l'API du service d'identité. Les domaines sont un ensemble de projets et d'utilisateurs qui définissent les limites administratives pour la gestion des entités.
Les domaines peuvent représenter un espace appartenant à un individu, à une entreprise ou à un opérateur. Ils exposent les activités administratives directement aux
PARTIE 3
utilisateurs du système. Les utilisateurs peuvent se voir attribuer le rôle d'administrateur pour un domaine. Un administrateur de domaine peut créer des projets, des
utilisateurs et des groupes dans un domaine et attribuer des rôles aux utilisateurs et aux groupes dans un domaine.

Notions d'identité
Point final
Une adresse accessible par le réseau, généralement une URL, par laquelle accéder à un service. Il est possible de créer un modèle de point de terminaison qui représente
les modèles de tous les services consommables disponibles.
Groupe
Une entité de l'API du service d'identité. Les groupes sont une collection d'utilisateurs appartenant à un domaine. Un rôle de groupe, accordé à un domaine ou à un projet,
s'applique à tous les utilisateurs du groupe. L'ajout ou la suppression d'utilisateurs à ou d'un groupe accorde ou révoque leur rôle et leur authentification au domaine ou
au projet associé.
OpenStackClient
Une interface de ligne de commande pour plusieurs services OpenStack, y compris l'API Identity. Par exemple, un utilisateur peut exécuter les commandes OpenStack
service create et OpenStack Endpoint create pour enregistrer des services dans son installation OpenStack.
Projet
Conteneur qui regroupe ou isole des ressources ou des objets d'identité. Un projet peut être mappé à un client, un compte ou une organisation etc..
PARTIE 3

Notions d'identité
Région
Une entité de l'API v3 du service d'identité. Représente une division générale dans un déploiement OpenStack. Vous pouvez associer zéro ou plusieurs sous-régions à une
région pour créer une hiérarchie structurée en arbre. Bien qu'une région n'ait pas de connotation géographique, un déploiement peut utiliser un nom géographique pour
une région, tel que us-east.
Rôle
Une personnalité avec un ensemble défini de droits et de privilèges d'utilisateur pour effectuer un ensemble spécifique d'opérations. Le service d'identité délivre un jeton
à un utilisateur qui inclut une liste de rôles. Lorsqu'un utilisateur appelle un service, ce service interprète le jeu de rôles utilisateur et détermine à quelles opérations ou
ressources chaque rôle accorde l'accès.
Service
Un service OpenStack, tel que Compute (nova), Object Storage (Swift) ou Image service (Glance), qui fournit un ou plusieurs points de terminaison via lesquels les
utilisateurs peuvent accéder aux ressources et effectuer des opérations.
Jeton
Une chaîne de texte alphanumérique qui permet d'accéder aux API et aux ressources OpenStack. Un token peut être révoqué à tout moment et est valable pour une durée
PARTIE 3
déterminée. Alors qu'OpenStack Identity prend en charge l'authentification basée sur les jetons, il a l'intention de prendre en charge des protocoles supplémentaires à
l'avenir.
Utilisateur
Représentation numérique d'une personne, d'un système ou d'un service qui utilise les services Cloud d'OpenStack. Le service d'identité valide que les demandes
entrantes sont faites par l'utilisateur qui prétend passer l'appel. Les utilisateurs peuvent accéder aux ressources à l'aide de jetons attribués.

Créer l’entité de service et les Endpoints API

Le service d’Identité fournit un catalogue de services et leur emplacement. Chaque service ajouté à votre environnement OpenStack nécessite une entité de service et
plusieurs Endpoints API dans le catalogue.
Prérequis
Par défaut, la base de données du service d’Identité ne contient aucune information pour supporter les services d’authentification et de catalogue. Il faudrait utiliser un
jeton d’authentification temporaire pour initialiser l’entité de service et les Endpoints API pour le service d’Identité.
Passer la valeur du jeton d’authentification à la commande OpenStack à l’aide du paramètre --os-token ou en définissant la variable d’environnement OS_TOKEN.
Passer la valeur de l’URL du service d’Identity à la commande OpenStack à l’aide du paramètre --os-url ou en définissant la variable d’environnement OS_URL.
Utiliser les variables d’environnement pour réduire la taille des commandes.
Configurer le jeton d’authentification :
$ export OS_TOKEN=ADMIN_TOKEN
$ export OS_TOKEN=294a4c8a8a475f9b9836
Configurer l’URL du Endpoint :
PARTIE 3
$ export OS_URL=http://controller:35357/v3
Créer l’entité de service et les Endpoints API
$ OpenStack service create \
--name keystone --description "OpenStack Identity" identity

CHAPITRE 1

Service d’autorisation
Autorisation
Le service Identity prend en charge la notion de groupes et de rôles.

Les utilisateurs appartiennent à des groupes alors qu'un groupe a une liste de rôles.
Les services OpenStack référencent les rôles de l'utilisateur tentant d'accéder au service.
OpenStack Policy Enforcer prend en considération la règle de politique associée à chaque ressource, puis le groupe/les rôles et l'association de l'utilisateur pour
déterminer si l'accès est autorisé à la ressource demandée.
Ceci permet un contrôle d'accès précis aux ressources OpenStack.
Établir des politiques de contrôle d'accès formelles

Avant de configurer les rôles, les groupes et les utilisateurs, les politiques de contrôle d'accès requises pour l'installation d'OpenStack doivent être documentées.
Les politiques doivent être conformes à toutes les exigences réglementaires ou légales de l'organisation.
Les modifications futures de la configuration du contrôle d'accès doivent être effectuées conformément aux politiques officielles.
Les politiques doivent inclure les conditions et les processus de création, de suppression, de désactivation et d'activation des comptes, ainsi que l'attribution de privilèges
PARTIE 3
aux comptes.
L’examen périodique des politiques permet de vérifier que la configuration est conforme aux politiques approuvées.

Autorisation
Autorisation de service
Les administrateurs de Cloud doivent définir un utilisateur avec le rôle d'administrateur pour chaque service, comme recommandé par les meilleurs pratiques
d'OpenStack. Ce compte de service fournit au service l'autorisation d'authentifier les utilisateurs.
Les services de calcul et de stockage d'objets peuvent être configurés pour utiliser le service d'identité pour stocker les informations d'authentification.
Le service d'identité prend en charge l'authentification client pour TLS qui peut être activé.
L'authentification client TLS fournit un facteur d'authentification supplémentaire, en plus du nom d'utilisateur et du mot de passe, qui offre une plus grande fiabilité lors de
l'identification de l'utilisateur. Il réduit le risque d'accès non autorisé lorsque les noms d'utilisateur et les mots de passe peuvent être compromis. Cependant, l'émission de
certificats aux utilisateurs entraîne des frais et des coûts administratifs supplémentaires pour le déploiement.
L'authentification client avec TLS nécessite que des certificats soient délivrés aux services. Ces certificats peuvent être signés par une autorité de certification externe ou
interne. Les services OpenStack vérifient la validité des signatures de certificat par rapport aux autorités de certification approuvées par défaut et les connexions
échoueront si la signature n'est pas valide ou si l'autorité de certification n'est pas approuvée.
Les déployeurs Cloud peuvent utiliser des certificats auto-signés. Dans ce cas, le contrôle de validité doit être désactivé ou le certificat doit être marqué comme approuvé.
PARTIE 3

Autorisation
Utilisateurs administratifs
Il est recommandé aux utilisateurs administrateurs de s'authentifier à l'aide du service d'identité et d'un service d'authentification externe prenant en charge
l'authentification à deux facteurs, tel qu'un certificat. Cela réduit le risque de mots de passe qui peuvent être compromis. Cette recommandation est conforme aux
directives concernant l'utilisation de l'authentification multi-facteur pour l'accès réseau aux comptes privilégiés.
Utilisateurs finaux
Le service d'identité peut fournir directement l'authentification de l'utilisateur final ou peut être configuré pour utiliser des méthodes d'authentification externes afin de
se conformer aux politiques et exigences de sécurité d'une organisation.
PARTIE 3

Exemple de stratégie
Chaque service OpenStack définit les politiques d'accès pour ses
ressources dans un fichier de politique associé.
Une ressource, par exemple, peut être l'accès à l'API, peut avoir la {
possibilité de s'attacher à un volume ou de lancer des instances. "admin_required": "role:admin",
"cloud_admin": "rule:admin_required and domain_id:admin_domain_id",
Les règles de politique sont spécifiées au format JSON et le fichier est "service_role": "role:service",
"service_or_admin": "rule:admin_required or rule:service_role",
appelé policy.json. "owner" : "user_id:%(user_id)s or user_id:%(target.token.user_id)s",
"admin_or_owner": "(rule:admin_required and domain_id:%(target.token.user.domain.id)s) or
rule:owner",
"admin_or_cloud_admin": "rule:admin_required or rule:cloud_admin",
"admin_and_matching_domain_id": "rule:admin_required and domain_id:%(domain_id)s",
Ces politiques peuvent être modifiées ou mises à jour par "service_admin_or_owner": "rule:service_or_admin or rule:owner",
l'administrateur du Cloud pour contrôler l'accès aux différentes "default": "rule:admin_required",
ressources.
"identity:get_service": "rule:admin_or_cloud_admin",
"identity:list_services": "rule:admin_or_cloud_admin",
Toute modification des politiques de contrôle d'accès ne devrait pas "identity:create_service": "rule:cloud_admin",
affaiblir involontairement la sécurité d'une ressource. "identity:update_service": "rule:cloud_admin",
"identity:delete_service": "rule:cloud_admin",
Les modifications apportées au fichier policy.json prennent effet "identity:get_endpoint": "rule:admin_or_cloud_admin",
immédiatement et ne nécessitent pas le redémarrage du service. "identity:list_endpoints": "rule:admin_or_cloud_admin",
PARTIE 3
"identity:create_endpoint": "rule:cloud_admin",
"identity:update_endpoint": "rule:cloud_admin",
L'exemple suivant montre comment le service peut restreindre l'accès "identity:delete_endpoint": "rule:cloud_admin",
pour créer, mettre à jour et supprimer des ressources aux seuls }
utilisateurs qui ont le rôle de Cloud_admin, tandis que les ressources
get et list sont mises à la disposition des utilisateurs

CHAPITRE 2
• Avoir une vue d'ensemble du client Web Horizon

• Analyser de la télémétrie et de la performance
• Mettre à l’échelle des ressources
• Connaitre les aspects de la facturation
7 heures
CHAPITRE 2
1. Vue d'ensemble du client Web Horizon

2. Analyse de la télémétrie et de la performance
3. Mise à l’échelle
4. Facturation
02 - Superviser les ressources
Vue d'ensemble du client Web Horizon
Dashboard Horizon
Le Dashboard (horizon) est une interface web qui permet aux
administrateurs et aux utilisateurs du Cloud d’administrer les
différentes ressources et services OpenStack.
Il fournit un portail libre-service de type web permettant d’interagir

avec les services sous-jacents d’OpenStack, comme le lancement d’une
instance, l’attribution d’adresses IP ou la configuration des contrôles
d’accès.
PARTIE 3

Dashboard Horizon
Admin TAB
Le volet admin offre une vue sur l’ensemble des éléments du projet, compute, stockage, réseau etc ..
PARTIE 3

Dashboard Horizon
Identity TAB
Le volet identité permet de gérer le volet identité en matière de domaines, projets, utilisateurs, rôles et groupes
PARTIE 3

Dashboard Horizon
Setting TAB
Le volet configuration générale permet de régler les paramètres généraux de l’infrastructure
PARTIE 3

CHAPITRE 2

4. Facturation
Analyse de la télémétrie et de la performance
Présentation du service de télémétrie

Service de collecte de données de télémétrie
Les services de collecte de données de télémétrie offrent les fonctions
suivantes :
Interrogent efficacement les données de mesure liées aux services

OpenStack.
Collectent les données d'événement et de mesure en surveillant les

notifications envoyées par les services.
Publient les données collectées sur diverses cibles, notamment les

magasins de données et les files d'attente des messages.
PARTIE 3


• Service de collecte de données de télémétrie
Le service de télémétrie comprend les composants suivants :
Un agent de calcul ( ceilometer-agent-Compute )
S'exécute sur chaque nœud de calcul et interroge les statistiques d'utilisation des ressources. Il pourrait y avoir d'autres types d'agents à l'avenir, mais pour l'instant, notre
objectif est de créer l'agent de calcul.
Un agent central ( ceilometer-agent-central )
Fonctionne sur un serveur de gestion central pour scruter les statistiques d'utilisation des ressources qui ne sont pas liées aux instances ou aux nœuds de calcul. Plusieurs
agents peuvent être lancés horizontalement à l'échelle de service.
Un agent de notification ( ceilometer-agent-notification )
S'exécute sur un ou plusieurs serveurs de gestion centralisés et utilise les messages de la ou des files d'attente de messages pour créer des données d'événement et de
mesure.
Un collecteur ( célomètre-collecteur )
Fonctionne sur serveur(s) central de gestion et dépêche les données de télémétrie récupérant à un magasin de données ou au consommateur externe sans modification.
PARTIE 3
Un serveur API ( ceilometer-api )

S'exécute sur un ou plusieurs serveurs de gestion centralisés pour fournir un accès aux données à partir du magasin de données.


• Service d'alarme de télémétrie
Les services d'alarme de télémétrie déclenchent des alarmes lorsque les données de mesure ou d'événement collectées enfreignent les règles définies.
Le service d'alarme de télémétrie comprend les composants suivants :
Un serveur API ( aodh-api )
S'exécute sur un ou plusieurs serveurs de gestion centralisés pour fournir un accès aux informations d'alarme stockées dans le magasin de données.
Un évaluateur d'alarme ( aodh-evaluator )
S'exécute sur un ou plusieurs serveurs de gestion centralisés pour déterminer quand les alarmes se déclenchent en raison de la tendance statistique associée franchissant
un seuil sur une fenêtre de temps glissante.
Un écouteur de notification ( aodh-listener )
Fonctionne sur un serveur de gestion central et détermine quand déclencher les alarmes. Les alarmes sont générées en fonction de règles définies par rapport aux
événements, qui sont capturées par les agents de notification du service de collecte de données de télémétrie.
Un notificateur d'alarme ( aodh-notifier )
PARTIE 3
S'exécute sur un ou plusieurs serveurs de gestion centralisés pour permettre de définir des alarmes en fonction de l'évaluation du seuil pour une collection d'échantillons.
Ces services communiquent à l'aide du bus de messagerie OpenStack. Seuls le collecteur et le serveur d'API ont accès au magasin de données.

Activer les compteurs du service Compute

Le service de Télémétrie utilise une combinaison de notifications et un agent pour collecter les compteurs Compute.
Effectuer ces opérations sur chaque nœud Compute.
# apt-get install ceilometer-agent-Compute
Configurer Compute pour utiliser la Télémétrie

Editer le fichier /etc/nova/nova.conf et configurer les notifications dans la section [DEFAULT] :
[PAR DÉFAUT]
...
instance_usage_audit = Vrai
instance_usage_audit_period = heure
notify_on_state_change = vm_and_task_state
PARTIE 3
notification_driver = messageriev2

Service d’alarme
Prérequis
Avant d’installer et configurer le service d’Alarme, créer une base de données, des crédentiels de service et des Endpoints API.
Créer l’entité de service aodh
$ openstack service create --name aodh \

--description "Telemetry" alarming
+-------------+----------------------------------+
| Field | Value |
+-------------+----------------------------------+
| description | Telemetry |
| enabled | True |
| id | 3405453b14da441ebb258edfeba96d83 |
| name | aodh |
| type | alarming |
PARTIE 3
+-------------+----------------------------------+

CHAPITRE 2

4. Facturation
Mise à l’échelle
Présentation de la mise à l'échelle automatique

Dans OpenStack, la mise à l’échelle "Auto-Scaling" fait référence à la capacité d'un Cloud à détecter automatiquement les conditions liées à la charge dans le Cloud et à
réagir de manière appropriée sans l'intervention d'un Opérateur.
Cela fait généralement référence aux charges de travail de calcul dans le Cloud, mais également des cas d'utilisation concernant la mise à l'échelle du plan de contrôle ou
d'autres ressources.
La mise à l'échelle comprend à la fois des actions d'augmentation et de réduction pour essayer d'allouer les ressources de manière appropriée et efficace et d'éviter les
problèmes. Cela vise la meilleure expérience client et le meilleur retour sur investissement.
La mise à l’échelle vise à éviter les problèmes en allouant plus de ressources lorsqu'un besoin est détecté ou prévu, ou à conserver les ressources en les désactivant
lorsque les charges sont faibles.
OpenStack fournit plusieurs méthodes pour mettre à l'échelle automatiquement le cluster : utilisation de Heat AutoScalingGroup, Senlin Cluster, etc..
PARTIE 3

Architecture de la mise à l'échelle automatique
Plusieurs couches et composants de

l’architecture permettent d’aboutir aux
objectifs de mise à l’échelle.
• Service de monitoring
• Service d’alarme
• Service d’optimisation
• Service de mise en cluster
• Service d’analyse
PARTIE 3

Composants de la mise à l'échelle automatique

OpenStack offre un riche ensemble de services pour créer, gérer, orchestrer et provisionner un Cloud.
Cela donne aux administrateurs des choix sur la meilleure façon de répondre aux besoins de leurs clients.
Unités de mise à l'échelle
- Il existe un certain nombre de composants qui peuvent être contrôlés avec la mise à l'échelle automatique.
• Hôte de calcul
• VM exécutée sur un hôte de calcul
• Conteneur exécuté sur un hôte de calcul
• Stockage en réseau
• Fonctions de réseau virtuel
Service de surveillance
- La surveillance fonctionne soit en utilisant un agent installé sur l'unité de mise à l'échelle, soit en utilisant une méthode d'interrogation pour récupérer les métriques.
PARTIE 3
• Monasca
• Ceilometer
• Prometheus

Composants de la mise à l'échelle automatique

Service alarmant
• Monasca dispose d'un service de seuillage d'alarme intégré et d'un service de notification
• Aodh du projet Télémétrie
Services de décision
- Il existe un certain nombre de services dans OpenStack qui peuvent interpréter les métriques et les alarmes en fonction de la logique configurée et produire des
commandes pour les moteurs d'orchestration.
• Congress
• Heat peut contenir une logique pour les décisions de mise à l'échelle automatique dans les modèles HOT
• Mistral
• Vitrage
• Watcher
Moteurs d'orchestration
PARTIE 3
• Heat
• Senlin est un moteur de clustering pour OpenStack et peut orchestrer la mise à l'échelle automatique
• Tacker

Environnements avec mise à l'échelle automatique

Les environnements avec mise à l'échelle automatique ajoutent ou suppriment des ressources selon les variations de la demande.
Les groupes de mise à l'échelle automatique comportent des règles qui indiquent le moment auquel les ressources doivent être ajoutées ou supprimées.
Par exemple, une règle peut indiquer que le groupe doit ajouter une instance lorsque l'utilisation moyenne de l'unité centrale dépasse 80%.
Dans la plupart des cas, utiliser les groupes de mise à l'échelle automatique avec des équilibreurs de charge qui chargent directement les ressources dans le groupe.
PARTIE 3

CHAPITRE 2

4. Facturation
Facturation
Ceilometer, composant de facturation

Ceilometer, composant de facturation, permet de calculer la consommation de chaque client.
Des mesures :
Le service de télémétrie collecte les compteurs dans un déploiement OpenStack.
Dans ce qui suit, un résumé du format et de l'origine des compteurs. Il contient également la liste des compteurs disponibles.
La télémétrie collecte les compteurs en interrogeant les éléments de l'infrastructure et également en consommant les notifications émises par d'autres services
OpenStack.
Il existe plusieurs compteurs qui sont collectés par sondage et par consommation. L'origine de chaque compteur est répertoriée dans les tableaux ci-dessous.
La télémétrie utilise les types de compteurs suivants :
PARTIE 3

Facturation
Calcul OpenStack
Exemples de grandeurs métrées par OpenStack
Nom Taper Unité Ressource Origine Soutien Noter
Compteurs ajoutés dans la version Mitaka ou antérieure
Mémoire Jauge Mo ID d'instance Notification Libvirt, Hyper-V Volume de RAM alloué à l'instance
Libvirt, Hyper-V, vSphere, Volume de RAM utilisé par l'instance à partir
utilisation de la mémoire Jauge Mo ID d'instance Sondeur
XenAPI de la quantité de sa mémoire allouée
mémoire.résident Jauge Mo ID d'instance Sondeur Libvirt Volume de RAM utilisé par l'instance sur la machine physique
CPU Cumulatif ns ID d'instance Sondeur Libvirt, Hyper-V Temps CPU utilisé
vcpu Jauge vcpu ID d'instance Notification Libvirt, Hyper-V Nombre de CPU virtuels alloués à l'instance
demand
disk.device.read.requests Cumulatif ID de disque Sondeur Libvirt, Hyper-V Nombre de requêtes de lecture
PARTIE 3
e
demand
disk.device.write.requests Cumulatif ID de disque Sondeur Libvirt, Hyper-V Nombre de demandes d'écriture
e
disk.device.read.bytes Cumulatif B ID de disque Sondeur Libvirt, Hyper-V Volume de lectures

PARTIE 4
Déployer des services d’OpenStack
• Mettre en œuvre une solution de backup

• Déployer des services de gestion infrastructure
20 heures
CHAPITRE 1
• Créer une base de données

• Importer des données
• Simuler la sauvegarde et la restauration de données
10 heures
CHAPITRE 1
1. Création d’une base de données

2. Importation des données
3. Simulation de Sauvegarde et restauration de données
01 - Mettre en œuvre une solution de backup
Création d’une base de données
Service de base de donnée

Trove est une base de données en tant que service pour OpenStack.
Il est conçu pour fonctionner entièrement sur OpenStack, dans le but de permettre d'utiliser rapidement et facilement les fonctionnalités d'une base de données
relationnelle sans avoir à gérer des tâches administratives complexes.
Les utilisateurs du Cloud et les administrateurs de base de données peuvent provisionner et gérer plusieurs instances de base de données selon les besoins.
Le service permet l'isolation des ressources à haute performance tout en automatisant les tâches administratives complexes, notamment le déploiement, la configuration,
les correctifs, les sauvegardes, les restaurations et la surveillance.
Trove permet d’installer et de gérer des instances de base de données relationnelle et NoSQL au sein d’OpenStack.
Les services de base de données supportés sont les suivants : MySQL, Redis, PostgreSQL, Mongodb, Cassandra, Couchbase et Percona …
PARTIE 4

Créer et accéder à une instance de base de données

Avant de créer l'instance
Choisir la saveur. Une version définit la RAM et la taille du volume racine pour l'instance. Trove OpenStack CLI fournit une commande pour obtenir une liste de saveurs qui
sont prises en charge pour créer une instance de Trove.
$ OpenStack database flavor list
Créer une instance de base de données

Cet exemple crée une instance de base de données avec les paramètres suivants :
Nom de l'instance :mysql_instance_1.
Version de la base de données :1fb05bb0-4605-48b6-81e6-3d4622e4a330.
Une taille de volume de 5(5 Go).
Une base de données nommée test.
La base de données est basée sur mysql et la version du magasin de données est la 5.7.29
PARTIE 4
L'utilisateur « user » avec le mot de passe « password ».

Un réseau Neutron 8799cf10-01ef-40e2-b04e-06da7cfa5668 pour allouer l'adresse IP de la base de données (pour l'accès interne).
Exposer l'instance au public via --is-public(pour un accès externe).
Seules les adresses IP provenant de 202.37.199.1/24ou 10.1.0.1/24 sont autorisées à accéder à la base de données.

Créer et accéder à une instance de base de données
$ openstack database instance create mysql_instance_1 \

--flavor 6 \
--size 5 \
--nic net-id=8799cf10-01ef-40e2-b04e-06da7cfa5668 \
--databases test --users userA:password \
--datastore mysql --datastore-version 5.7.29 \
--is-public \
--allowed-cidr 10.1.0.1/24 \
--allowed-cidr 202.37.199.1/24
+--------------------------+--------------------------------------+
| Field | Value |
+--------------------------+--------------------------------------+
| allowed_cidrs | [10.1.0.1/24, 202.37.199.1/24] |
| created | 08T21:00:19 |
| datastore | mysql |
| datastore_version | 5.7.29 |
| datastore_version_number | 5.7.29 |
| flavor | 1fb05bb0-4605-48b6-81e6-3d4622e4a330 |
| id | ad40cf6c-6532-4a22-a3f3-7364f0f04a0f |
| name | mysql_instance_1 |
PARTIE 4
| operating_status | |
| public | True |
| region | RegionOne |
| service_status_updated | 08T21:00:19 |
| status | BUILD |
| updated | 08T21:00:19 |
| volume | 5 |
+--------------------------+--------------------------------------+

CHAPITRE 1

Importation des données
Accéder à la base de donnée et importer les donnés
Accéder à la nouvelle base de données en utilisant les commandes d'accès à la base de données typiques MySQL.
IP_ADDRESS selon l'endroit où la commande s'exécute.
L’adresse IP doit figurer dans les CIDR autorisés et spécifiés dans la commande ci-dessus :
$ mysql -h IP_ADDRESS -uuserA –ppassword
Importation des données SQL
Il est possible d’importer des données à partir d’une autre base de données ou bien de fichiers de base de donnée existants
Exemple : import depuis csv :
LOAD DATA INFILE 'c:/tmp/import.csv'
INTO TABLE import
FIELDS TERMINATED BY ','
ENCLOSED BY '"'
PARTIE 4
LINES TERMINATED BY '\n'

IGNORE 1 ROWS;

Sauvegarder et restaurer une base de données

Utiliser les services de base de données pour sauvegarder une base de données et stocker la sauvegarde dans le service Object Storage.
Plus tard, si la base de données d'origine est endommagée, utiliser la sauvegarde pour restaurer la base de données.
Le processus de restauration crée une nouvelle instance de base de données.
Les données de sauvegarde sont stockées dans OpenStack Swift. L'utilisateur peut personnaliser le conteneur pour stocker les données. :
• Le nom du conteneur peut être spécifié lors de la création de sauvegardes.

Cela pourrait remplacer soit le paramètre de stratégie de sauvegarde, soit le paramètre par défaut dans la configuration de Trove.
Un nom par défaut (issu de la configuration de base de Trove) est utilisé s'il n'est pas spécifié par l'utilisateur.
• Les utilisateurs peuvent créer une stratégie de sauvegarde pour la portée du projet ou pour une instance particulière.
PARTIE 4


Cet exemple crée une stratégie de sauvegarde, crée une instance de sauvegarde et de restauration à partir de la sauvegarde.
S’assurer d'avoir créé une instance
$ openstack database instance list

+--------------------------------------+--------+-----------+-------------------+--------+-----------+------+
| id | name | datastore | datastore_version | status | flavor_id | size |
+--------------------------------------+--------+-----------+-------------------+--------+-----------+------+
| 97b4b853-80f6-414f-ba6f-c6f455a79ae6 | guest1 | mysql | mysql-5.5 | ACTIVE | 10 | 2 |
+--------------------------------------+--------+-----------+-------------------+--------+-----------+------+
Créer une stratégie de sauvegarde pour l'instance

$ openstack database backup strategy create --instance-id 97b4b853-80f6-414f-ba6f-c6f455a79ae6 --swift-
container my-trove-backups
+-----------------+--------------------------------------+
| Field | Value |
+-----------------+--------------------------------------+
| backend | swift |
| instance_id | 97b4b853-80f6-414f-ba6f-c6f455a79ae6 |
PARTIE 4
| project_id | 922b47766bcb448f83a760358337f2b4 |
| swift_container | my-trove-backups |
+-----------------+--------------------------------------+


Sauvegarder l'instance de base de données
Sauvegarder l'instance de base de données à l'aide de la commande de création de sauvegarde de la base de données OpenStack.
Dans cet exemple, la sauvegarde s'appelle backup1.
$ openstack database backup create 97b4b853-80f6-414f-ba6f-c6f455a79ae6 backup1

+-------------+--------------------------------------+
+-------------+--------------------------------------+
| created | 2014-03-18T17:09:07 |
| description | None |
| id | 8af30763-61fd-4aab-8fe8-57d528911138 |
| locationRef | None |
| name | backup1 |
| size | None |
| status | NEW |
| updated | 2014-03-18T17:09:07 |
PARTIE 4
+-------------+--------------------------------------+


Utiliser la commande OpenStack database backup list ou la commande OpenStack database backup show pour vérifier l'état de la sauvegarde :
$ openstack database backup list

+--------------------------------------+--------------------------------------+---------+-----------+-----------+---------------------+
| id | instance_id | name | status | parent_id | updated |
+--------------------------------------+--------------------------------------+---------+-----------+-----------+---------------------+
| 8af30763-61fd-4aab-8fe8-57d528911138 | 97b4b853-80f6-414f-ba6f-c6f455a79ae6 | backup1 | COMPLETED | None | 2014-03-18T17:09:11 |
+--------------------------------------+--------------------------------------+---------+-----------+-----------+---------------------+
$ openstack database backup show 8af30763-61fd-4aab-8fe8-57d528911138
+-------------+----------------------------------------------------+
+-------------+----------------------------------------------------+
| created | 2014-03-18T17:09:07 |
| id | 8af...138 |
| instance_id | 97b...ae6 |
| locationRef | http://10.0.0.1:.../.../8af...138.xbstream.gz.enc |
| name | backup1 |
| size | 0.17 |
| status | COMPLETED |
| updated | 2014-03-18T17:09:11 |
+-------------+----------------------------------------------------+
PARTIE 4

Vérifier les données de sauvegarde dans Swift

Vérifier que le conteneur est créé et que les données de sauvegarde sont enregistrées en tant qu'objets à l'intérieur du conteneur.
$ openstack container list

+------------------+
| Name |
+------------------+
| my-trove-backups |
+------------------+
$ openstack object list my-trove-backups
+--------------------------------------------------+
| Name |
+--------------------------------------------------+
| 8af30763-61fd-4aab-8fe8-57d528911138.xbstream.gz |
+--------------------------------------------------+
PARTIE 4

Restaurer une instance de base de données

Si l'instance de base de données « guest1 » est endommagée et que l’on désir la restaurer :
Utiliser la commande de création d'instance de base de données OpenStack pour créer une nouvelle instance de base de données « guest2 ».
Spécifier que la nouvelle instance « guest2 » a le même type ( 10) et la même taille de volume racine (2) que l'instance guest1 d'origine.
Utiliser l’argument « --backup » pour indiquer que cette nouvelle instance est basée sur la sauvegarde identifiée par BACKUP_ID.
Dans cet exemple, remplacer BACKUP_ID par 8af30763-61fd-4aab-8fe8-57d528911138.
$ openstack database instance create guest2 --flavor 10 --size 2 --nic net-id=$network_id --backup BACKUP_ID
+-------------------+----------------------------------------------+
+-------------------+----------------------------------------------+
| created | 2014-03-18T17:12:03 |
| datastore | {u'version': u'mysql-5.5', u'type': u'mysql'}|
|datastore_version | mysql-5.5 |
| flavor | {u'id': u'10', u'links': [{u'href': ...]} |
| id | ac7a2b35-a9b4-4ff6-beac-a1bcee86d04b |
| name | guest2 |
| status | BUILD |
PARTIE 4
| updated | 2014-03-18T17:12:03 |
| volume | {u'size': 2} |
+-------------------+----------------------------------------------+

Vérifier la sauvegarde
Vérifier que la nouvelle instance a les mêmes caractéristiques que l‘instance d'origine.
+-----------+--------+-----------+-------------------+--------+-----------+------+
+-----------+--------+-----------+-------------------+--------+-----------+------+
| 97b...ae6 | guest1 | mysql | mysql-5.5 | ACTIVE | 10 | 2 |
| ac7...04b | guest2 | mysql | mysql-5.5 | ACTIVE | 10 | 2 |
+-----------+--------+-----------+-------------------+--------+-----------+------+
Utiliser la commande show de l'instance de base de données OpenStack pour afficher des informations sur la nouvelle instance.
$ openstack database instance show INSTANCE_ID

+-------------------+--------------------------------------+
+-------------------+--------------------------------------+
| created | 2014-03-18T17:12:03 |
| datastore | mysql |
| datastore_version | mysql-5.5 |
| flavor | 10 |
PARTIE 4
| ip | 10.0.0.3 |
| name | guest2 |
| status | ACTIVE |
| updated | 2014-03-18T17:12:06 |
| volume | 2 |
| volume_used | 0.18 |
+-------------------+--------------------------------------+

CHAPITRE 1

Simulation de Sauvegarde et restauration de données
Stratégie de sauvegarde
Il est recommandé de procéder à la création d’une stratégie personnalisée pour la sauvegarde de base de données :
Dans cet exemple, lister les instances de base de données :

+--------------------------------------+--------+-----------+-------------------+--------+-----------+------+
+--------------------------------------+--------+-----------+-------------------+--------+-----------+------+
| 97b4b853-80f6-414f-ba6f-c6f455a79ae6 | guest1 | mysql | mysql-5.5 | ACTIVE | 10 | 2 |
+--------------------------------------+--------+-----------+-------------------+--------+-----------+------+
Créer une stratégie de sauvegarde personnalisée pour une instance donnée.

Spécifier le conteneur SWIFT pour la sauvegarde en précisant l’argument (--swift-container)
$ openstack database backup strategy create --instance-id 97b4b853-80f6-414f-ba6f-c6f455a79ae6 --swift-container my-trove-

backups
+-----------------+--------------------------------------+
PARTIE 4
| Field | Value |
+-----------------+--------------------------------------+
| backend | swift |
| project_id | 922b47766bcb448f83a760358337f2b4 |
| swift_container | my-trove-backups |
+-----------------+--------------------------------------+

Sauvegarder une base de données

Sauvegarder l'instance de base de données
Sauvegarder l'instance de base de données à l'aide de la commande de création de sauvegarde de la base de données OpenStack.
Dans cet exemple, la sauvegarde s'appelle backup1.
$ openstack database backup create 97b4b853-80f6-414f-ba6f-c6f455a79ae6 backup1

+-------------+--------------------------------------+
+-------------+--------------------------------------+
| created | 18T17:09:07 |
| id | 8af30763-61fd-4aab-8fe8-57d528911138 |
| locationRef | None |
| name | backup1 |
| size | None |
PARTIE 4
| status | NEW |
| updated | 18T17:09:07 |
+-------------+--------------------------------------+

Restaurer une instance de base de données

Utiliser la commande de création d' instance de base de données OpenStack pour créer une nouvelle instance de base de données.
Utiliser l’argument « -backup » pour indiquer que cette nouvelle instance est basée sur la sauvegarde identifié par BACKUP_ID.
Dans cet exemple, remplacer BACKUP_ID par 8af30763-61fd-4aab-8fe8-57d528911138.
$ openstack database instance create guest2 --flavor 10 --size 2 --nic net-id=$network_id --

backup BACKUP_ID
+-------------------+----------------------------------------------+
+-------------------+----------------------------------------------+
| created | 18T17:12:03 |
| datastore | {u'version': u'mysql-5.5', u'type': u'mysql'}|
|datastore_version | mysql-5.5 |
| flavor | {u'id': u'10', u'links': [{u'href': ...]} |
| name | guest2 |
| status | BUILD |
| updated | 18T17:12:03 |
PARTIE 4
| volume | {u'size': 2} |
+-------------------+----------------------------------------------+

CHAPITRE 2
Déployer des services de gestion
infrastructure
• Implémenter un DHCP
• Configurer un NTP
• Implémenter un DNS
10 heures
CHAPITRE 2
infrastructure
1. Implémentation du DHCP
2. Configuration du NTP
3. Implémentation DNS
02 - Déployer des services de gestion infrastructure
Implémentation du DHCP
DHCP distribué
Le serveur DHCP est implémenté à l'aide du serveur Dnsmasq exécuté dans un espace de noms sur le nœud de réseau par sous-réseau locataire configuré avec DHCP
activé.
Actuellement, la haute disponibilité est obtenue en exécutant plusieurs serveurs Dnsmasq sur plusieurs nœuds de réseau.
DHCP distribué dans Dragonflow

Dragonflow distribue la politique et la configuration DHCP à l'aide de la base de données embarquée. Chaque contrôleur local installe des règles Openflow de redirection
DHCP à gérer par le contrôleur local. Ces règles sont installées uniquement pour les ports locaux attachés à un réseau virtuel avec DHCP activé.
Le contrôleur définit les métadonnées de flux dans les règles de redirection sur la clé unique du port local comme indice pour permettre une recherche rapide des
informations de port pour les paquets DHCP réactifs gérés par l'application DHCP.
L'application DHCP locale gère les paquets DHCP redirigés et répond en tant que serveur DHCP. Le trafic DHCP est géré directement au niveau du nœud de calcul et ne
passe jamais sur le réseau.
PARTIE 4

DHCP distribué
PARTIE 4

DHCP distribué
PARTIE 4

CHAPITRE 2
infrastructure
Configuration du NTP
Network Time Protocol (NTP)

Installer Chrony, une implémentation de NTP, pour synchroniser correctement les services entre les nœuds.
Il est recommandé de configurer le contrôleur pour pointer vers des serveurs plus précis (stratum moins élevé) et les autres nœuds pour pointer vers le contrôleur.
# apt-get install chrony
Redémarrer le service NTP
# service chrony restart

PARTIE 4

Installation des autres nœuds

Les autres nœuds font référence au nœud contrôleur pour la synchronisation d'horloge.
Effectuer ces étapes sur tous les autres nœuds.
# apt-get install chrony
Modifier le fichier « /etc/chrony/chrony.conf » pour référencer le nœud du contrôleur : server controller iburst
Redémarrer le service NTP
# service chrony restart

PARTIE 4

Vérifier le fonctionnement
Vérifier la synchronisation NTP :
Exécuter cette commande sur le nœud du contrôleur :
# chronyc sources
210 Number of sources = 2

MS Name/IP address Stratum Poll Reach LastRx Last sample
===============================================================================
^- 192.0.2.11 2 7 12 137 -2814us[-3000us] +/- 43ms
^* 192.0.2.12 2 6 177 46 +17us[ -23us] +/- 68ms
Exécutez la même commande sur tous les autres nœuds :
# chronyc sources
210 Number of sources = 1

MS Name/IP address Stratum Poll Reach LastRx Last sample
===============================================================================
PARTIE 4
^* controller 3 9 377 421 +15us[ -87us] +/- 15ms

CHAPITRE 2
infrastructure
Implémentation DNS
Designate, un composant DNSaaS pour OpenStack
Designate est un service DNSaaS mutualisé pour OpenStack. Il

fournit une API REST avec authentification Keystone intégrée.
Il peut être configuré pour générer automatiquement des

enregistrements basés sur les actions Nova et Neutron.
Designate prend en charge une variété de serveurs DNS,

notamment Bind9 et PowerDNS 4.
PARTIE 4

Implémentation DNS
Architecture en DNS pour OpenStack

PARTIE 4

Implémentation DNS
Déploiement pour OpenStack

• Installer les packages :
# apt-get install designate
• Créer une base données de designate accessible par l'utilisateur designate. Remplacer DESIGNATE_DBPASS par un mot de passe approprié :
# mysql
mysql> CREATE DATABASE designate CHARACTER SET utf8 COLLATE utf8_general_ci;
mysql> GRANT ALL PRIVILEGES ON designate.* TO 'designate'@'localhost' \
IDENTIFIED BY 'DESIGNATE_DBPASS';
mysql> GRANT ALL PRIVILEGES ON designate.* TO 'designate'@'%' \
IDENTIFIED BY 'DESIGNATE_DBPASS';
• Installer les packages BIND9 :

PARTIE 4
# apt-get install bind9 bind9utils bind9-doc

Resume Theorique M211

Transféré par

Informations du document

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

Resume Theorique M211

Transféré par

Droits d'auteur :

Formats disponibles

RÉSUMÉ THÉORIQUE – FILIÈRE INFRASTRUCTURE DIGITALE

M211 - Implémenter un environnement Cloud avec une solution libre

SOMMAIRE Installer OpenStack

2. Explorer les services de base

3. Explorer les services avancés

4. Déployer des services d’OpenStack

Copyright - Tout droit réservé - OFPPT 3

Dans ce module, vous allez :

• Comprendre l’écosystème OpenStack

Ce que vous allez apprendre dans ce chapitre :

• Avoir une vue d’ensemble de l’offre Cloud privé et

Copyright - Tout droit réservé - OFPPT 7

Modèles de déploiement OpenStack

Les déploiements Cloud sont aujourd’hui une tendance mondiale.

Les avantages : agilité, évolutivité, réduction des coûts.

Copyright - Tout droit réservé - OFPPT 8

Intégration avec les solutions existantes (Ecosystèmes)

Copyright - Tout droit réservé - OFPPT 9

OpenNebula vs OpenStack vs CloudStack

Catégorie OpenNebula OpenStack CloudStack

API Cloud et OCCI (Open Cloud

Copyright - Tout droit réservé - OFPPT 10

Positionnement d’OpenStack 1/2

Copyright - Tout droit réservé - OFPPT 11

Positionnement d’OpenStack 2/2

Copyright - Tout droit réservé - OFPPT 12

Copyright - Tout droit réservé - OFPPT 13

Architecture d’OpenStack : Service Horizon

Copyright - Tout droit réservé - OFPPT 14

Architecture d’OpenStack : Service Nova

Copyright - Tout droit réservé - OFPPT 15

Architecture d’OpenStack : Service Cinder

Copyright - Tout droit réservé - OFPPT 16

Architecture d’OpenStack : Service Neutron

Copyright - Tout droit réservé - OFPPT 17

Architecture d’OpenStack : Service Glance

Copyright - Tout droit réservé - OFPPT 18

Architecture d’OpenStack : Service Swift

Copyright - Tout droit réservé - OFPPT 19

Architecture d’OpenStack : Service Keystone

Copyright - Tout droit réservé - OFPPT 20

Architecture d’OpenStack : Autre services

Copyright - Tout droit réservé - OFPPT 21

Copyright - Tout droit réservé - OFPPT 23

Les versions 2010-2015

Nom version Date version Evolution des composants

Copyright - Tout droit réservé - OFPPT 24

Les versions 2015-2018

Nom version Date version Evolution des composants

Copyright - Tout droit réservé - OFPPT 25

Les versions 2019-2021

Nom version Date version Evolution des composants

Copyright - Tout droit réservé - OFPPT 26

Contributeurs sur OpenStack : Exemple version Wallaby

Contributeur Nombre de revue Pourcentage

Copyright - Tout droit réservé - OFPPT 27

Ce que vous allez apprendre dans ce chapitre :

• Etapes de téléchargement et d’installation

Prérequis d’installation et de mise en place 1/2

L’installation sera détaillée dans la partie travaux pratique.

Copyright - Tout droit réservé - OFPPT 30

Prérequis d’installation et de mise en place 2/2

La configuration réseau présentée définit l’architecture minimale.

L’ajout des composants se fait en fonction du scope de l’installation.