Self service
L'utilisateur accède directement au service
Pas d'intermédiaire humain
Réponses immédiates
Catalogue de services permettant leur découverte
À travers le réseau
L'utilisateur accède au service à travers le réseau
Le fournisseur du service est distant du consommateur
Réseau = internet ou pas
Utilisation de protocoles réseaux standards (typiquement : HTTP)
Mutualisation des ressources
Un cloud propose ses services à de multiples utilisateurs/organisations (multi-tenant )
Tenant ou projet : isolation logique des ressources
Les ressources sont disponibles en grandes quantités (considérées illimitées)
Le taux d'occupation du cloud n'est pas visible
La localisation précise des ressources n'est pas visible
Élasticité rapide
Provisionning et suppression des ressources quasi instantané
Permet le scaling (passage à l'échelle)
Possibilité d'automatiser ces actions de scaling
Virtuellement pas de limite à cette élasticité
Mesurabilité
L'utilisation des ressources cloud est monitorée par le fournisseur
Le fournisseur peut gérer son capacity planning et sa facturation à partir de ces informations
L'utilisateur est ainsi facturé en fonction de son usage précis des ressources
L'utilisateur peut tirer parti de ces informations
Modèles
On distingue :
modèles de service : IaaS, PaaS, SaaS
modèles de déploiement : public, privé, hybride
IaaS
Infrastructure as a Service
Infrastructure :
Compute (calcul)
Storage (stockage)
Network (réseau)
Utilisateurs cibles : administrateurs (système, stockage, réseau)
PaaS
Platform as a Service
Désigne deux concepts :
Environnement permettant de développer/déployer une application (spécifique à un langage/framework - exemple : Python/Django)
Ressources plus haut niveau que l'infrastructure, exemple : BDD
Utilisateurs cibles : développeurs d'application
SaaS
Software as a Service
Utilisateurs cibles : utilisateurs finaux
Ne pas confondre avec la définition économique du SaaS
Quelquechose as a Service ?
Load balancing as a Service (Infra)
Database as a Service (Platform)
MonApplication as a Service (Software)
etc.
Les modèles de service en un schéma
IaaS - PaaS - SaaS (source : Wikipedia)
Cloud public ou privé ?
À qui s'adresse le cloud ?
Public : tout le monde, disponible sur internet
Privé : à une organisation, disponible sur son réseau
Cloud hybride
Utilisation mixte de multiples clouds privés et/ou publics
Concept séduisant mais mise en œuvre a priori difficile
Certains cas d'usages s'y prêtent très bien
Intégration continue (CI)
Motivations
Éviter le lock-in
Débordement (cloud bursting )
L'instant virtualisation
Mise au point.
La virtualisation est une technologie permettant d'implémenter la fonction compute
Un cloud fournissant du compute peut utiliser la virtualisation
Mais peut également utiliser :
Du bare-metal
Des containers (système)
Les APIs, la clé du cloud
Rappel : API pour Application Programming Interface
Au sens logiciel : Interface permettant à un logiciel d’utiliser une bibliothèque
Au sens cloud : Interface permettant à un logiciel d’utiliser un service (XaaS)
Interface de programmation (via le réseau, souvent HTTP)
Frontière explicite entre le fournisseur (provider) et l'utilisateur (user)
Définit la manière dont l'utilisateur communique avec le cloud pour gérer ses ressources
Gérer : CRUD (Create, Read, Update, Delete)
API REST
Une ressource == une URI (Uniform Resource Identifier )
Utilisation des verbes HTTP pour caractériser les opérations (CRUD)
GET
POST
PUT
DELETE
Utilisation des codes de retour HTTP
Représentation des ressources dans le corps des réponses HTTP
REST - Exemples
GET http://endpoint/volumes/
GET http://endpoint/volumes/?size=10
POST http://endpoint/volumes/
DELETE http://endpoint/volumes/xyz
Exemple concret
GET /v2.0/networks/d32019d3-bc6e-4319-9c1d-6722fc136a22
{
"network":{
"status":"ACTIVE",
"subnets":[ "54d6f61d-db07-451c-9ab3-b9609b6b6f0b" ],
"name":"private-network",
"provider:physical_network":null,
"admin_state_up":true,
"tenant_id":"4fd44f30292945e481c7b8a0c8908869",
"provider:network_type":"local",
"router:external":true,
"shared":true,
"id":"d32019d3-bc6e-4319-9c1d-6722fc136a22",
"provider:segmentation_id":null
}
}
Pourquoi le cloud ? côté économique
Appréhender les ressources IT comme des services “fournisseur”
Faire glisser le budget “investissement” (Capex) vers le budget “fonctionnement” (Opex)
Réduire les coûts en mutualisant les ressources, et éventuellement avec des économies d'échelle
Réduire les délais
Aligner les coûts sur la consommation réelle des ressources
Pourquoi le cloud ? côté technique
Abstraire les couches basses (serveur, réseau, OS, stockage)
S’affranchir de l’administration technique des ressources et services (BDD, pare-feux, load-balancing, etc.)
Concevoir des infrastructures scalables à la volée
Agir sur les ressources via des lignes de code et gérer les infrastructures “comme du code”
Amazon Web Services (AWS), le leader
AWS logo
Lancement en 2006
À l'origine : services web "e-commerce" pour développeurs
Puis : d'autres services pour développeurs
Et enfin : services d'infrastructure
Récemment, SaaS
Alternatives IaaS publics à AWS
Google Cloud Platform
Microsoft Azure
DigitalOcean
Alibaba Cloud
En France :
Scaleway
OVH
Outscale
Ikoula
Faire du IaaS privé
OpenStack
CloudStack
Eucalyptus
OpenNebula
OpenStack en quelques mots
OpenStack logo
Naissance en 2010
Fondation OpenStack depuis 2012...
...rebaptisée Open Infrastructure Foundation en 2020 (https://openinfra.dev/ )
Écrit en Python et distribué sous licence Apache 2.0
Soutien très large de l'industrie et contributions variées
Les concepts Infrastructure as a Service
La base
Infrastructure :
Compute
Storage
Network
Ressources compute
Instance
Image
Flavor (gabarit)
Paire de clé (SSH)
Instance
Dédiée au compute
Durée de vie typiquement courte, à considérer comme éphémère
Ne doit pas stocker de données persistantes
Disque racine non persistant
Basée sur une image
Image cloud
Image disque contenant un OS déjà installé
Instanciable à l'infini
Sachant parler à l'API de metadata
Flavor (gabarit)
Instance type chez AWS
Définit un modèle d’instance en termes de CPU, RAM, disque (racine), disque éphémère
Le disque éphémère a, comme le disque racine, l’avantage d’être souvent local donc rapide
Paire de clé
Clé publique + clé privée SSH
Le cloud manipule et stocke la clé publique
Cette clé publique est utilisée pour donner un accès SSH aux instances
Ressources réseau 1/2
Réseau L2
Port réseau
Réseau L3
Routeur
IP flottante
Groupe de sécurité
Ressources réseau 2/2
Load Balancing as a Service
VPN as a Service
Firewall as a Service
Ressources stockage
Le cloud fournit deux types de stockage
Stockage block
Volumes attachables à une instance
Accès à des raw devices type /dev/vdb
Possibilité d’utiliser n’importe quel système de fichiers
Possibilité d'utiliser du LVM, du chiffrement, etc.
Compatible avec toutes les applications existantes
Nécessite de provisionner l'espace en définissant la taille du volume
Du stockage partagé ?
Le stockage block n’est pas une solution de stockage partagé comme NFS
NFS se situe à une couche plus haute : système de fichiers
Un volume est a priori connecté à une seule machine
"Boot from volume"
Démarrer une instance avec un disque racine sur un volume
Persistance des données du disque racine
Se rapproche du serveur classique
Stockage objet
API : faire du CRUD sur les données
Pousser et retirer des objets dans un container /bucket
Pas de hiérarchie, pas de répertoires, pas de système de fichiers
Accès lecture/écriture uniquement par les APIs
Pas de provisioning nécessaire
L’application doit être conçue pour tirer parti du stockage objet
Orchestration
Orchestrer la création et la gestion des ressources dans le cloud
Définition de l'architecture dans un template
Les ressources créées à partir du template forment la stack
Il existe également des outils d'orchestration (plutôt que des services )
Bonnes pratiques d'utilisation
Pourquoi des bonnes pratiques ?
Deux approches :
Ne pas évoluer
Risquer de ne pas répondre aux attentes
Se contenter d'un cas d'usage test & dev
Adapter ses pratiques au cloud pour en tirer parti pleinement
Haute disponibilité (HA)
Le control plane (les APIs) du cloud est HA
Les ressources provisionnées ne le sont pas forcément
Pet vs Cattle
Comment considérer ses instances ?
Infrastructure as Code
Avec du code
Provisionner les ressources d'infrastructure
Configurer les dites ressources, notamment les instances
Le métier évolue : Infrastructure Developer
Scaling, passage à l'échelle
Scale out plutôt que Scale up
Scale out : passage à l'échelle horizontal
Scale up : passage à l'échelle vertical
Auto-scaling
Géré par le cloud
Géré par un composant extérieur
Applications cloud ready
Stockent leurs données au bon endroit
Sont architecturées pour tolérer les pannes
Etc.
Cf. https://12factor.net/
Implémentation du stockage : (Software Defined Storage) SDS
Attention : ne pas confondre avec le sujet block vs objet
Utilisation de commodity hardware
Pas de RAID matériel
Le logiciel est responsable de garantir les données
Les pannes matérielles sont prises en compte et gérées
Le projet Ceph et le composant OpenStack Swift implémentent du SDS
Voir aussi Scality, OpenIO, OpenSDS,...
SDS - Théorème CAP
Consistency - Availability - Partition tolerance
Vue haut niveau (1/2)
Vue haut niveau
Vue haut niveau (2/2)
Vue haut niveau
Historique
Démarrage du projet en 2010
Objectif : le Cloud Operating System libre
Fusion de deux projets : Rackspace (Storage) et la NASA (Compute)
Logiciel libre distribué sous licence Apache 2.0
Naissance de l'OpenStack Foundation en 2012, rebaptisée Open Infrastructure Foundation en octobre 2020
Mission
"To produce an ubiquitous Open Source Cloud Computing platform that is easy to use, simple to implement, interoperable between deployments, works well at all scales, and meets the needs of users and operators of both public and private clouds."
Les releases
Austin (2010.1)
Bexar (2011.1), Cactus (2011.2), Diablo (2011.3)
Essex (2012.1), Folsom (2012.2)
Grizzly (2013.1), Havana (2013.2)
Icehouse (2014.1), Juno (2014.2)
Kilo (2015.1), Liberty (2015.2)
Mitaka (2016.1), Newton (2016.2)
Ocata (2017.1), Pike (2017.2)
Queens (2018.1), Rocky (2018.2)
Stein (2019.1), Train (2019.2)
Ussuri (2020.1), Victoria (2020.2)
Wallaby (2021.1)
Second semestre 2021 : Xena
... et utilisateurs
BBC
Banco Santander, Société Générale
BMW, Volkswagen AG
Cathay Pacific
CERN
China Railway
Ministère de l'Intérieur (France)
Walmart
Wikimedia
et beaucoup d'autres
https://www.openstack.org/user-stories/
Les principaux composants d'OpenStack (1/3)
Identity : Keystone
Compute : Nova, Placement
Storage : Cinder (block), Swift (object), Manila (shared file system)
Networking : Neutron (sdn), Octavia (lbaas), Designate (dns)
Image : Glance
Dashboard : Horizon
Telemetry : Ceilometer
Alerting : AODH
Orchestration : Heat (infra as code), Mistral (workflow), Blazar (resource reservation)
https://www.openstack.org/software/project-navigator/
Les principaux composants d'OpenStack (2/3)
Et aussi :
Bare metal : Ironic
Container : Magnum
Message Queue : Zaqar
Database : Trove
Data processing : Sahara
Key management : Barbican
Billing : Cloudkitty
Application catalog : Murano
...
Les principaux composants OpenStack (3/3)
Autres :
OpenStack sdk (bibliothèque python) et OpenStack client (CLI)
Les outils de déploiement d'OpenStack (OSA)
Les bibliothèques utilisées par OpenStack (Oslo)
Les outils utilisés pour développer OpenStack (git, gerrit, zuul,...)
APIs
Chaque composant maintient sa propre API OpenStack
Certains composants supportent l'API AWS équivalente (Nova/EC2, Swift/S3)
Software map
Software map
La Fondation OpenStack
Rebaptisée Open Infrastructure Foundation en 2020
Entité de gouvernance principale et représentation juridique
Les membres du "Board of Directors" sont issus des entreprises sponsors et des membres individuels élus
Tout le monde peut devenir membre individuel (gratuit, pas de cotisation)
Ressources humaines : marketing, événementiel, release management, quelques développeurs (principalement sur l’infrastructure)
710 organisations dans le monde, 110 000 membres, 182 pays
Rapport annuel: https://www.openstack.org/annual-reports/2020-openinfra-foundation-annual-report/
https://osf.dev
Open Infrastructure Foundation
Les principales entités de la Fondation
Open Infrastructure
En 2018, la Fondation OpenStack s'élargit à l'Open Infrastructure
https://openinfra.dev/about/open-infrastructure/
"The integration of open alternatives for all the different forms that compute storage and networking are taking now and in the future. The interoperable open source components are production ready, scale easily, and businesses can rely on them for real and emerging workloads."
Au-delà d'OpenStack, des nouveaux projets sont incubés :
Airship
Kata Containers
StarlingX
Zuul
Ressources (3/3)
Ressources commerciales :
Job board :
User Survey
Enquête réalisée chaque année par la Fondation
Auprès des déployeurs et utilisateurs
Résultats publiés :
Certification : Certified OpenStack Administrator (COA)
Seule certification OpenStack existante
Validée par la Fondation OpenStack
Contenu :
Modalités :
Ressources :
Communauté francophone et association
Logo OpenStack-fr
https://openstack.fr - https://asso.openstack.fr
Meetups : Paris, Lyon, Toulouse, Montréal, etc.
Présence à des événements tels que Paris Open Source Summit
Canaux de communication :
openstack-fr@lists.openstack.org
#openstack-fr@oftc
Architecture
Vue détaillée des services
Implémentation
Tout est développé en Python (framework Django pour la partie web)
Chaque projet est découpé en plusieurs services (exemple : API, scheduler, etc.)
Réutilisation de composants existants et de bibliothèques existantes
Utilisation des bibliothèques oslo.*
(développées par et pour OpenStack) : logs, config, etc.
Utilisation de rootwrap
pour appeler des programmes sous-jacents en root
Implémentation - dépendances
Base de données : relationnelle SQL (MariaDB-Galera)
Communication entre les services : AMQP (RabbitMQ)
Mise en cache : Memcached
Load balancing: HAProxy
Développement du projet : en détails
Ouvert à tous (individuels et entreprises)
Cycle de développement de 6 mois
Chaque cycle débute par un Project Team Gathering (PTG)
Pendant chaque cycle a lieu un OpenStack Summit
Les outils et la communication
Code : Git (GitHub est utilisé comme miroir)
Revue de code (peer review) : Gerrit
Intégration continue (CI: Continous Integration) : Zuul
Blueprints/spécifications et bugs :
Launchpad
StoryBoard
Communication : IRC et mailing-lists
Traduction : Zanata
Développement du projet : en détails
Workflow de changements dans OpenStack
Cycle de développement : 6 mois
Qui contribue ?
Active Technical Contributor (ATC)
Personne ayant au moins une contribution récente dans un projet OpenStack reconnu
Droit de vote (TC et PTL)
Core reviewer : ATC ayant les droits pour valider les patchs dans un projet
Project Team Lead (PTL) : élu par les ATCs de chaque projet
Stackalytics fournit des statistiques sur les contributions http://stackalytics.com/
Upstream Training
Avant chaque summit
1,5 jours de formation, en anglais
Apprendre à devenir contributeur à OpenStack
Les outils
Les processes
Travailler et collaborer de manière ouverte
https://docs.openstack.org/upstream-training/
OpenStack Infra
Équipe projet en charge de l’infrastructure de développement d’OpenStack
Travaille comme les équipes de dev d’OpenStack et utilise les mêmes outils
Résultat : Infrastructure as code open source https://opensourceinfra.org/
Utilise du cloud (hybride)
OpenStack Summit
Tous les 6 mois
Aux USA jusqu’en 2013, aujourd'hui alternance Amérique de Nord et Asie/Europe
Quelques dizaines au début à des milliers de participants aujourd’hui
En parallèle : conférence (utilisateurs, décideurs) et Forum (développeurs/opérateurs, remplace une partie du précédent Design Summit)
Exemple du Summit d’avril 2013 à Portland
Photo : Adrien Cunin
Exemple du Summit d’octobre 2015 à Tokyo
Photo : Elizabeth K. Joseph, CC BY 2.0, Flickr/pleia2
Exemple du Summit d’octobre 2015 à Tokyo
Photo : Elizabeth K. Joseph, CC BY 2.0, Flickr/pleia2
Exemple du Summit d’octobre 2015 à Tokyo
Photo : Elizabeth K. Joseph, CC BY 2.0, Flickr/pleia2
Exemple du Summit d’octobre 2015 à Tokyo
Photo : Elizabeth K. Joseph, CC BY 2.0, Flickr/pleia2
Project Team Gathering (PTG)
Depuis 2017
Au début de chaque cycle
Roadmap fonctionnelle et discussion de sujets techniques
Remplace une partie du précédent Design Summit
Dédié aux développeurs, opérateurs et utilisateurs
DevStack : faire tourner rapidement un OpenStack
Utilité de DevStack
Déployer rapidement un OpenStack
Utilisé par les développeurs pour tester leurs changements
Utilisé pour faire des démonstrations
Utilisé pour tester les APIs sans se préoccuper du déploiement
Ne doit PAS être utilisé pour de la production
Fonctionnement de DevStack
Support d'Ubuntu, Debian, Fedora, CentOS/RHEL, OpenSUSE
Un script shell qui fait tout le travail : stack.sh
Un fichier de configuration : local.conf
Installe toutes les dépendances nécessaires (paquets)
Clone les dépôts git (branche master par défaut)
Lance tous les composants
Configuration : local.conf
Exemple
[[local|localrc]]
ADMIN_PASSWORD=secrete
DATABASE_PASSWORD=$ADMIN_PASSWORD
RABBIT_PASSWORD=$ADMIN_PASSWORD
SERVICE_PASSWORD=$ADMIN_PASSWORD
SERVICE_TOKEN=a682f596-76f3-11e3-b3b2-e716f9080d50
#FIXED_RANGE=172.31.1.0/24
#FLOATING_RANGE=192.168.20.0/25
#HOST_IP=10.3.4.5
Conseils d’utilisation
DevStack installe beaucoup de paquets sur la machine
Il est recommandé de travailler dans une machine virtuelle
Pour tester tous les composants OpenStack dans de bonnes conditions, plusieurs Go de RAM sont nécessaires
L’utilisation de Vagrant est conseillée # OpenStack : utilisation
Principes
Toutes les fonctionnalités sont accessibles par l’API
Les clients (y compris le dashboard Horizon) utilisent l’API
Des identifiants sont nécessaires :
utilisateur
mot de passe
projet (aka tenant)
domaine
Les APIs OpenStack
Une API par service OpenStack :
Versionnée, la rétro-compatibilité est assurée
Le corps des requêtes et réponses est formatté avec JSON
Architecture REST
Les ressources gérées sont spécifiques à un projet
Un cloud OpenStack déployé dans les règles de l'art fournit des APIs hautement disponibles.
(La haute-disponibilité des instances est un autre sujet)
https://developer.openstack.org/#api
Accès aux APIs
Direct, en HTTP, via des outils comme curl
En mode programmatique, avec une bibliothèque :
OpenStackSDK
D’autres implémentations, y compris pour d’autres langages (gophercloud, jclouds,...)
Avec le CLI officiel
Avec le dashboard Horizon (WUI)
Avec des outils tiers de plus haut niveau tels que Terraform
Clients officiels
OpenStack fournit des clients officiels
Historiquement : python-PROJETclient
(bibliothèque Python et CLI)
Aujourd'hui : openstackclient
(CLI)
CLI
L’authentification se fait en passant les identifiants par paramètres, variables d’environnement ou fichier de configuration (yaml)
L’option --debug
affiche les requêtes et les réponses
Keystone : identité et catalogue de services
Principes
Keystone est responsable de l'authentification, des autorisations et du catalogue de services.
L'utilisateur standard s'authentifie auprès de Keystone
L'administrateur intéragit régulièrement avec Keystone (pour gérer les projets, utilisateurs, autorisations,...)
APIs
API keystone v3 --> port 5000
Gère :
Domaines
Projets
Utilisateurs , groupes
Rôles (lien entre utilisateur et projet)
Services et endpoints (catalogue de services)
Fournit :
Tokens d'authentification
Catalogue de services
Pour chaque service, plusieurs endpoints (URLs) sont possibles en fonction de :
la région
le type d'interface (public, internal, admin)
Scénario d’utilisation typique
Interactions avec Keystone
Principes
Gère principalement les instances
Les instances sont créées à partir des images fournies par Glance
Les interfaces réseau des instances sont connectées à des ports Neutron
Du stockage block peut être fourni aux instances par Cinder
Propriétés d’une instance
Éphémère, a priori non hautement disponible
Définie par une flavor
Construite à partir d’une image
Optionnel : attachement de volumes
Optionnel : boot depuis un volume
Optionnel : une clé SSH publique
Optionnel : des ports réseaux
API
Ressources gérées :
Instances
Flavors : vcpu, ram, disque de boot
Keypairs (clés ssh) : ressource propre à l'utilisateur (et non au projet)
Actions sur les instances
Reboot / shutdown
Snapshot
Resize
Migration (admin)
Deletion
Lecture des logs
Accès console
Affinity/anti-affinity
Demander à Nova de démarrer 2 ou plus instances :
le plus proche possible (affinity)
le plus éloigné possible (anti-affinity)
Besoin de performances ou besoin de distribution/résistance aux pannes
Principes
Fournit des volumes (stockage block) attachables aux instances (/dev)
Gère différents types de volume
Gère snapshots et backups de volumes
Utilisation
Volume supplémentaire (et stockage persistant) sur une instance
Boot from volume : l’OS est sur le volume
Fonctionnalité de backup vers un object store (Swift ou Ceph)
Glance : registre d'images
Principes
Registre d'images et de snapshots
Propriétés sur les images
API
API v2 : version courante, gère images et snapshots d'instances
Types d’images
Glance supporte un large éventail de types d’images, limité par le support de la technologie sous-jacente à Nova :
Propriétés des images dans Glance
L’utilisateur peut définir un certain nombre de propriétés dont certaines seront utilisées lors de l’instanciation :
Type d’image
Architecture
Distribution
Version de la distribution
Espace disque minimum
RAM minimum
Visibilité et partage des images
Image publique : accessible à tous les projets
Par défaut, seul l'administrateur peut rendre une image publique
Image privée : accessible uniquement au projet auquel elle appartient
Image partagée : accessible à un ou plusieurs autre(s) projet(s)
Images cloud
Une image cloud c’est :
La plupart des distributions Linux fournissent des images régulièrement mises à jour :
Cloud-init
Cloud-init est un moyen de tirer parti de l’API de metadata, et notamment des user data
Intégré par défaut dans la plupart des images cloud
À partir des user data , cloud-init effectue les opérations de personnalisation de l’instance
cloud-config est un format possible de user data
Exemple cloud-config
:
#cloud-config
mounts:
- [ vda2, /var/www ]
packages:
- apache2
package_update: true
API
L’API permet notamment de manipuler les ressources :
Réseau : niveau 2
Sous-réseau : niveau 3
Port : attachable à une interface sur une instance, un load-balancer, etc.
Routeur
IP flottante
Groupe de sécurité
Les IP flottantes
Permettent d'exposer une instance au réseau externe
En plus des fixed IPs portées par les instances
Non portées directement par les instances
Allocation (réservation par le projet) d'une IP depuis un pool
Association à un port d'une IP allouée
Les groupes de sécurité
Équivalents à un pare-feu devant chaque instance
Une instance peut être associée à un ou plusieurs groupes de sécurité
Gestion des accès en entrée (ingress) et sortie (egress)
Règles de filtrage par protocole (TCP/UDP/ICMP) et par port
La source d'une règle est soit une adresse IP, un réseau ou un autre groupe de sécurité
Fonctionnalités supplémentaires
Outre les fonctions réseau de base niveaux 2 et 3, Neutron peut fournir d’autres services :
VPN : permet d’accéder à un réseau privé sans IP flottantes
QoS : règles de gestion de la bande passante
Principes
Fournit des fonctionnalités de load balancing aux projets
Load balancing implémenté par des instances spécifiques, les amphores
Gestion de la haute-disponibilité des load balancers eux-mêmes
Agnostique des technologies sous-jacentes
Basé par défaut sur HAProxy
Composants : vue aérienne
Composants Octavia
API
Version courante : V2
L'API Octavia permet de gérer les ressources suivantes :
Load balancer
Listener
Pool
Member
Health monitor
Rules
Policies
Généralités
Heat est la solution native OpenStack du service d'orchestration
Il permet de décrire, dans des templates YAML, des ensembles cohérents de ressources virtuelles
Heat fournit une API de manipulation de stacks à partir de templates
Un template Heat suit le format HOT (Heat Orchestration Template )
Il est possible de générer des templates interactivement avec le dashboard Horizon
Exemple de template
heat_template_version: 2018-08-31
description: Simple template to deploy a single compute instance
parameters:
instance_name:
type: string
label: Instance Name
default: my_instance
subnet_id:
type: string
resources:
instance:
type: OS::Nova::Server
properties:
name: { get_param: instance_name }
image: cirros
flavor: m1.small
networks:
- port: { get_resource: instance_port }
instance_port:
type: OS::Neutron::Port
properties:
network_id: { get_param: subnet_id }
fixed_ips:
- subnet_id: { get_param: subnet_id }
outputs:
fixed_ip: { get_attr: [ instance, first_address ]
Principes
Fournit une interface web (WUI) à l'utilisateur et à l'administrateur OpenStack
S'appuie sur les services déployés pour déterminer les fonctionnalités offertes dans le WUI
Log in sans préciser un projet : Horizon détermine la liste des projets accessibles
Utilisation
Fonctionne bien avec Firefox et Chrome
Echanges HTTPS
Authentification de type username/password
Notion de projet courant, possibilité de basculer d'un projet à l'autre
Une zone “admin” restreinte
Support multilingue
OpenStack en production et opérations
Bonnes pratiques pour un déploiement en production
Quels composants dois-je installer ?
Keystone est indispensable
L’utilisation de Nova va de paire avec Glance et Neutron
Cinder et Swift s'apprécient en fonction des besoins de stockage
Swift peut être utilisé indépendemment des autres composants
Heat coûte peu
Les services plus haut niveau s'évaluent au cas par cas
https://docs.openstack.org/arch-design/
Penser dès le début aux choix structurants
Distribution et méthode de déploiement
Politique de mise à jour
Drivers/backends : hyperviseur, stockage block, etc.
Réseau : quelle architecture et quels drivers
Les différentes méthodes d’installation
DevStack est à oublier pour la production
Le déploiement à la main comme vu précédemment n’est pas recommandé car peu maintenable
Distributions OpenStack packagées et prêtes à l’emploi
Distributions classiques et gestion de configuration
Déploiement continu
Mises à jour entre versions majeures
OpenStack supporte les mises à jour N → N+1
Swift : très bonne gestion en mode rolling upgrade
Autres composants : tester préalablement avec vos données
Lire les release notes
Cf. articles de blog du CERN https://techblog.web.cern.ch/techblog/
Mises à jour dans une version stable
Fourniture de correctifs de bugs majeurs et de sécurité
OpenStack intègre ces correctifs sous forme de patchs dans la branche stable
Publication de point releases intégrant ces correctifs issus de la branche stable
Durée variable du support des versions stables, dépendant de l’intérêt des intégrateurs
Assigner des rôles aux machines
Beaucoup de documentations font référence à ces rôles :
Controller node : APIs, BDD, AMQP
Network node : DHCP, routeur, IPs flottantes
Compute node : Hyperviseur/pilotage des instances
Ce modèle simplifié n’est pas HA.
Haute disponibilité de l’agent L3 de Neutron
Distributed Virtual Router (DVR)
L3 agent HA (VRRP)
Considérations APIs
Des URLs uniformes pour toutes les APIs :
Utiliser un reverse proxy
Mettre à jour le catalogue de services
Apache/mod_wsgi pour servir les APIs lorsque cela est possible (Keystone, etc.)
Guide Operations : https://docs.openstack.org/openstack-ops/content/
Découpage réseau
Management network : réseau d’administration
Data/instances network : réseau pour la communication inter instances
External network : réseau externe, dans l’infrastructure réseau existante
Storage network : réseau pour le stockage Cinder/Swift
API network : réseau contenant les endpoints API
Considérations liées à la sécurité
Indispensable : HTTPS sur l’accès des APIs à l’extérieur
Sécurisation des communications MySQL/MariaDB et RabbitMQ
Un accès MySQL/MariaDB par base et par service
Un utilisateur Keystone par service
Limiter l’accès en lecture des fichiers de configuration (mots de passe, token)
Veille sur les failles de sécurité : OSSA (OpenStack Security Advisory ), OSSN (... Notes )
Guide sécurité : https://docs.openstack.org/security-guide/
Segmenter son cloud
Host aggregates : machines physiques avec des caractéristiques similaires
Availability zones : machines dépendantes d’une même source électrique, d’un même switch, d’un même DC, etc.
Regions : chaque région a son API
Cells : permet de regrouper plusieurs cloud différents sous une même API
Host aggregates / agrégats d’hôtes
Spécifique Nova
L’administrateur définit des agrégats d’hôtes via l’API
L’administrateur associe flavors et agrégats via des couples clé/valeur communs
1 agrégat ≡ 1 point commun, ex : GPU
L’utilisateur choisit un agrégat à travers son choix de flavor à la création d’instance
Availability zones / zones de disponibilité
Spécifique Nova et Cinder
Groupes d’hôtes
Découpage en termes de disponibilité : Rack, Datacenter, etc.
L’utilisateur choisit une zone de disponibilité à la création d’instance
L’utilisateur peut demander à ce que des instances soient démarrées dans une même zone, ou au contraire dans des zones différentes
Régions
Générique OpenStack
Équivalent des régions d’AWS
Un service peut avoir différents endpoints dans différentes régions
Chaque région est autonome
Cas d’usage : cloud de grande ampleur (comme certains clouds publics)
Cells / Cellules
Spécifique Nova
Un seul nova-api devant plusieurs cellules
Chaque cellule a sa propre BDD et file de messages
Ajoute un niveau de scheduling (choix de la cellule)
Packaging d’OpenStack - Ubuntu
Le packaging est fait dans de multiples distributions, RPM, DEB et autres
Ubuntu est historiquement la plateforme de référence pour le développement d’OpenStack
Le packaging dans Ubuntu suit de près le développement d’OpenStack, et des tests automatisés sont réalisés
Canonical fournit la Ubuntu Cloud Archive, qui met à disposition la dernière version d’OpenStack pour la dernière Ubuntu LTS
Ubuntu Cloud Archive (UCA)
Support d'OpenStack dans Ubuntu via l'UCA
Packaging d’OpenStack dans les autres distributions
OpenStack est intégré dans les dépôts officiels de Debian
Red Hat propose RHOS/RDO (déploiement basé sur TripleO)
Comme Ubuntu, le cycle de release de Fedora est synchronisé avec celui d’OpenStack
TripleO
OpenStack On OpenStack
Objectif : pouvoir déployer un cloud OpenStack (overcloud ) à partir d’un cloud OpenStack (undercloud )
Autoscaling du cloud lui-même : déploiement de nouveaux nœuds compute lorsque cela est nécessaire
Fonctionne conjointement avec Ironic pour le déploiement bare-metal
Gestion de configuration
Ansible, Puppet, Chef, CFEngine, Saltstack, etc.
Ces outils peuvent aider à déployer le cloud OpenStack
... mais aussi à gérer les instances (section suivante)
Modules Puppet, Playbooks Ansible
Déploiement continu
OpenStack maintient un master (trunk) toujours stable
Possibilité de déployer au jour le jour le master
(CD : Continous Delivery )
Nécessite la mise en place d’une infrastructure importante
Facilite les mises à jour entre versions majeures
Test et validation : Tempest
Suite de tests d’un cloud OpenStack
Effectue des appels à l’API et vérifie le résultat
Est très utilisé par les développeurs via l’intégration continue
Le déployeur peut utiliser Tempest pour vérifier la bonne conformité de son cloud
Cf. aussi Rally
Les réflexes en cas d’erreur ou de comportement erroné
Travaille-t-on sur le bon projet ?
Est-ce que l’API renvoie une erreur ? (le dashboard peut cacher certaines informations)
Si nécessaire d’aller plus loin :
Regarder les logs sur le(s) contrôleur(s) (/var/log/<composant>/*.log)
Regarder les logs sur le compute node et le network/controller node si le problème est spécifique réseau/instance
Éventuellement modifier la verbosité des logs dans la configuration
Est-ce un bug ?
Si le client CLI crash, c’est un bug
Si le dashboard web ou une API renvoie une erreur 500, c’est peut-être un bug
Si les logs montrent une stacktrace Python, c’est un bug
Sinon, à vous d’en juger
Gestion des logs
Centraliser les logs
Logs d'API
Logs autres composants OpenStack
Logs BDD, AMQP, etc.
Backup
Bases de données
Mécanisme de déploiement, plutôt que backup des fichiers de configuration
Monitoring
Réponse des APIs
Vérification des services OpenStack et dépendances
Utilisation des quotas
Limiter le nombre de ressources allouables
Par utilisateur ou par projet
Support dans Nova
Support dans Cinder
Support dans Neutron
Comment implémenter un service de Compute