Formation OpenStack utilisateur

Concernant ces supports de cours

Concernant ces supports de cours 1/2

Supports de cours réalisés par Osones https://osones.com

Logo Osones
Logo Osones

Auteurs

Concernant ces supports de cours 2/2

Licence Creative Commons BY-SA 4.0
Licence Creative Commons BY-SA 4.0

Introduction

Objectifs de la formation

  • Assimiler les concepts et le vocabulaire liés au cloud
  • Manipuler et orchestrer des ressources dans un cloud OpenStack
  • Définir, déployer et maintenir une infrastructure dans le cloud
  • Architecturer une application cloud-ready

Pré-requis de la formation

  • À l'aise dans un envirionnement Linux (shell)
  • Notions de virtualisation
  • Optionnel :
    • Notions de Python (langage et environnement)

Le cloud, vue d'ensemble

Définition formelle

Caractéristiques

Fournir un (des) service(s)...

  • Self service
  • À travers le réseau
  • Mutualisation des ressources
  • Élasticité rapide
  • Mesurabilité

Inspiré de la définition du NIST http://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-145.pdf

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
  • Les ressources sont disponibles en grandes quantités
  • La localisation précise et le taux d'occupation des ressources ne sont pas visibles

Élasticité rapide

  • Provisionning et suppression des ressources quasi instantané
  • Possibilité d'automatiser ces actions de scaling (passage à l'échelle)
  • 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 à partir de ces informations
  • L'utilisateur est facturé en fonction de son usage précis des ressources

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
  • Environnement permettant de développer/déployer une application
  • Spécifique à un language/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

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
IaaS - PaaS - SaaS

Cloud public ou privé ?

À qui s'adresse le cloud ?

  • Public : tout le monde, disponible sur internet
  • Privé : à une organisation, disponible sur son réseau

Concernant le cloud hybride : utilisation mixte de multiples clouds privés et/ou publics

Cloud hybride

  • Concept séduisant
  • Mise en œuvre a priori difficile
  • Certains cas d'usages s'y prêtent très bien
    • Exemple : jobs de CI
  • 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

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)
  • REST

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”

Le marché

Amazon Web Services (AWS), le leader

  • 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
  • Rackspace
  • DreamHost
  • DigitalOcean
  • En France :
    • Cloudwatt (Orange Business Services)
    • Numergy (SFR)
    • OVH
    • Ikoula
    • Scaleway
    • Outscale

Faire du IaaS privé

  • OpenStack
  • CloudStack
  • Eucalyptus
  • OpenNebula

OpenStack en quelques mots

  • Naissance en 2010
  • Fondation OpenStack depuis 2012
  • Écrit en Python et distribué sous licence Apache 2.0
  • Soutien très large de l'industrie et contributions variées

Exemples de PaaS public

Solutions de PaaS privé

Les concepts Infrastructure as a Service

La base

  • Infrastructure :
    • Compute
    • Storage
    • Network

Ressources compute

  • Instance
  • Image
  • Flavor (gabarit)
  • Paire de clé (SSH)

L'instance

  • Éphémère, durée de vie typiquement courte
  • Dédiée au compute
  • Ne doit pas stocker de données persistantes
  • Disque racine non persistant

Image cloud

  • Image disque contenant un OS déjà installé
  • Instanciable à l'infini
  • Sachant parler à l'API de metadata

API ... de metadata

  • http://169.254.169.254
  • Accessible depuis l'instance
  • Fournit des informations relatives à l'instance
  • cloud-init permet d'exploiter cette API

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

  • Block
  • Objet

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

"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

  • Pousser et retirer des objets dans un container/bucket
  • Pas de hiérarchie des données, pas de système de fichiers
  • Accès par les APIs
  • 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

Bonne pratiques d'utilisation

Haute disponibilité (HA)

  • Le control plane (les APIs) du cloud est HA
  • Les ressources provisionnées ne le sont pas forcément

Pets vs Cattle

Comment considérer ses instances ?

  • Pet
  • Cattle

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

Applications cloud ready

  • Stockent leurs données au bon endroit
  • Sont architecturées pour tolérer les pannes
  • Etc.

Cf. http://12factor.net/

Derrière le cloud

Comment implémenter un service de Compute

  • Virtualisation
  • Containers
  • Bare metal

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

SDS - Théorème CAP

Consistency - Availability - Partition tolerance
Consistency - Availability - Partition tolerance

Récapitulatif vocabulaire

Notions et vocabulaire IaaS 1/4

  • Identité et accès
    • Tenant/Projet (Project) : locataire du cloud, propriétaire de ressources.
    • Utilisateur (User) : compte autorisé à utiliser les API OpenStack.
    • Quota : contrôle l’utilisation des ressources (vcpu, ram, fip, security groups,...) dans un tenant.
    • Catalogue (de services) : services disponibles et accessibles via les API.
    • Endpoint : URL permettant l’accès à une API. Un endpoint par service.

Notions et vocabulaire IaaS 2/4

  • Calcul/Serveurs (Compute)
    • Image : généralement, un OS bootable et “cloud ready”.
    • Instance : forme dynamique d’une image.
    • Type d’instance (flavor) : mensurations d’une instance (cpu, ram, capacité disque,...).
    • Metadata et user data : informations gérées par le IaaS et mises à disposition de l’instance.
    • Cloud-init, cloud-config : mécanismes permettant la configuration finale automatique d’une instance.

Notions et vocabulaire IaaS 3/4

  • Stockage (Storage)
    • Volume : disque virtuel accessible par les instances (stockage “block”).
    • Conteneur (Container) : entités logiques pour le stockage de fichiers et accessibles via une URL (stockage “objet”).
  • Réseau et sécurité (Network, Security)
    • Groupe de sécurité (Security groups) : ensemble de règles de filtrage de flux appliqué à l’entrée des instances.
    • Paire de clés (Keypairs) : clé privée + clé publique permettant les connexions aux instances via SSH.
    • IP flottantes (Floating IP) : adresse IP allouée à la demande et utilisée par les instances pour communiquer avec le réseau “externe”.

Notions et vocabulaire IaaS 4/4

  • Orchestration
    • Stack : ensemble des ressources IaaS utilisées par une application.
    • Template : fichier texte contenant la description d’une stack.

OpenStack : le projet

Tour d'horizon

Vue haut niveau

Version simple
Version simple

Historique

  • Démarrage en 2010
  • Objectif : le Cloud Operating System libre To produce a 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.
  • Fusion de deux projets de Rackspace (Storage) et de la NASA (Compute)
  • Logiciel libre distribué sous licence Apache 2.0
  • Naissance de la Fondation en 2012

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)
  • Fin 2017 : Pike

Quelques soutiens/contributeurs ...

  • Editeurs : Red Hat, Suse, Canonical, Vmware, ...
  • Constructeurs : IBM, HP, Dell, ...
  • Constructeurs/réseau : Juniper, Cisco, ...
  • Constructeurs/stockage : NetApp, Hitachi, ...
  • En vrac : NASA, Yahoo, Rackspace, OVH, Citrix, SAP, ...
  • Google ! (depuis juillet 2015)

https://www.openstack.org/foundation/companies/

... et utilisateurs

  • Tous les contributeurs précédemment cités
  • En France : Cloudwatt et Numergy
  • Wikimedia
  • CERN
  • Paypal
  • Comcast
  • BMW
  • Etc. Sans compter les implémentations confidentielles

https://www.openstack.org/user-stories/

Les différents sous-projets

  • OpenStack Compute - Nova
  • OpenStack (Object) Storage - Swift
  • OpenStack Block Storage - Cinder
  • OpenStack Networking - Neutron
  • OpenStack Image Service - Glance
  • OpenStack Identity Service - Keystone
  • OpenStack Dashboard - Horizon
  • OpenStack Telemetry - Ceilometer
  • OpenStack Orchestration - Heat
  • OpenStack Database Service - Trove

Les différents sous-projets (2)

  • Mais aussi :
    • Bare metal (Ironic)
    • Queue service (Zaqar)
    • Data processing (Sahara)
    • DNS service (Designate)
    • Shared File Systems (Manila)
    • Key management (Barbican)
    • PaaS (Solum)
    • Container (Magnum)
  • Autres
    • Les clients (python-*client), CLI et bibliothèques
    • Les bibliothèques utilisées par OpenStack
    • Les outils utilisés pour développer OpenStack

Les 4 Opens

  • Open Source
  • Open Design
  • Open Development
  • Open Community

La fondation OpenStack

  • Entité de gouvernance principale du projet
  • Représentation juridique du projet
  • Les membres du board sont issus des entreprises sponsors et élus par les membres individuels
  • Tout le monde peut devenir membre individuel (gratuitement)

La fondation OpenStack

  • La fondation supporte le projet par différents moyens :
    • Événements : organisation (Summits) ou participation (OSCON, etc.)
    • Infrastructure de développement (serveurs)
    • Ressources humaines : marketing, release manager, quelques développeurs (principalement sur l’infrastructure)
  • 500 organisations à travers le monde
  • 60000 membres individuels dans 160 pays

La fondation OpenStack

Les principales entités de la fondation
Les principales entités de la fondation

Ressources

Ressources

Ressources - Communauté francophone

Logo OpenStack-fr
Logo OpenStack-fr
  • Site web : http://openstack.fr/
  • Association des utilisateurs francophones d’OpenStack : https://asso.openstack.fr/
  • Meetups : Paris, Rhônes-Alpes, 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@Freenode

Utiliser OpenStack

Le principe

  • Toutes les fonctionnalités sont accessibles par l’API
  • Les clients (y compris Horizon) utilisent l’API
  • Des crédentials sont nécessaires
    • API OpenStack : utilisateur + mot de passe + tenant
    • API AWS : access key ID + secret access key

Les APIs OpenStack

  • Une API par service OpenStack
  • Chaque API est versionnée, la rétro-compatibilité est assurée
  • Le corps des requêtes et réponses est formatté avec JSON
  • Architecure REST
  • http://developer.openstack.org/#api
  • Certains services sont aussi accessibles via une API différente compatible AWS

Accès aux APIs

  • Direct, en HTTP, via des outils comme curl
  • Avec une bibliothèque
    • Les implémentations officielles en Python
    • OpenStackSDK
    • D’autres implémentations, y compris pour d’autres langages (exemple : jclouds)
    • Shade
  • Avec les outils officiels en ligne de commande
  • Avec Horizon

Clients officiels

  • Le projet fournit des clients officiels : python-PROJETclient
  • Bibliothèques Python
  • Outils CLI
    • L’authentification se fait en passant les credentials par paramètres ou variables d’environnement
    • L’option --debug affiche la communication HTTP

OpenStack Client

  • Client CLI unifié
  • Commandes du type openstack <ressource ><action >
  • Vise à remplacer à terme les clients spécifiques
  • Permet une expérience utilisateur plus homogène
  • Fichier de configuration clouds.yaml

Shade

  • Bibliothèque Python incluant la business logic

Authentification

Authentification et catalogue de service

  • Une fois authentifié, récupération d’un jeton (token)
  • Récupération du catalogue de services
  • Pour chaque service, un endpoint HTTP (API)

Scénario d’utilisation typique

Interactions avec Keystone
Interactions avec Keystone

Compute

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

Flavors

  • Gabarit
  • Équivalent des “instance types” d’AWS
  • Définit un modèle d’instance en termes de CPU, RAM, disque (racine), disque éphémère
  • Un disque de taille nul équivaut à prendre la taille de l’image de base
  • Le disque éphémère a, comme le disque racine, l’avantage d’être souvent local donc rapide

Types d’images

Glance supporte un large éventail de types d’images, limité par le support de l’hyperviseur sous-jacent à Nova

  • raw
  • qcow2
  • ami
  • vmdk
  • iso

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
  • Publique ou non

Utiliser des images cloud

Une image cloud c’est :

  • Une image disque contenant un OS déjà installé
  • Une image qui peut être instanciée en n machines sans erreur
  • Un OS sachant parler à l’API de metadata du cloud (cloud-init)

Détails : http://docs.openstack.org/image-guide/openstack-images.html
La plupart des distributions fournissent aujourd’hui des images cloud.

Cirros

  • Cirros est l’image cloud par excellence
  • OS minimaliste
  • Contient cloud-init

https://launchpad.net/cirros

Cloud-init

  • Cloud-init est un moyen de tirer parti de l’API de metadata, et notamment des user data
  • L’outil est 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:
 - [ xvdc, /var/www ]
packages:
 - apache2
 - htop

Comment gérer ses images ?

  • Utilisation d’images génériques et personnalisation à l’instanciation
  • Création d’images intermédiaires et/ou totalement personnalisées : Golden images
    • libguestfs, virt-builder, virt-sysprep
    • diskimage-builder (TripleO)
    • Packer
    • solution “maison”

 Réseau

API

L’API permet notamment de manipuler ces ressources

  • Réseau (network) : niveau 2
  • Sous-réseau (subnet) : niveau 3
  • Port : attachable à une interface sur une instance, un load-balancer, etc.
  • Routeur

Les groupes de sécurité

  • Équivalent à un firewall devant chaque instance
  • Une instance peut être associée à un ou plusieurs groupes de sécurité
  • Gestion des accès en entrée et sortie
  • Règles par protocole (TCP/UDP/ICMP) et par port
  • Cible une adresse IP, un réseau ou un autre groupe de sécurité

Fonctionnalités supplémentaires

Outre les fonctions réseau de base niveaux 2 et 3, Neutron peut fournir d’autres services :

  • Load Balancing
  • Firewall : diffère des groupes de sécurité
  • VPN : permet d’accéder à un réseau privé sans IP flottantes

 Orchestration

Natif OpenStack et alternatives

  • Heat est la solution native OpenStack
  • Heat fournit une API de manipulation de stacks à partir de templates
  • Des alternatives externes à OpenStack existent, comme Terraform

Un template Heat Orchestration Template (HOT)

parameters - resources - outputs

heat_template_version: 2013-05-23
description: Simple template to deploy a single compute instance
resources:
  my_instance:
    type: OS::Nova::Server
    properties:
      key_name: my_key
      image: F18-x86_64-cfntools
      flavor: m1.small

Construire un template à partir d’existant

Multiples projets en cours de développement

  • Flame (Cloudwatt)
  • HOT builder
  • Merlin

 Avancé

Un grand cloud

  • Régions
  • Zones de disponibilité (AZ)

Architectures cloud-ready

Concevoir une application pour le cloud

12-factor

“The Twelve-Factor App” http://12factor.net/

  • Écrit par Heroku
  • Suivre (tout) le code dans un VCS
  • Configuration

Modulaire

  • Multiples composants de taille raisonnable
  • Philosophie Unix
  • Couplage faible et interface documentée

Passage à l’échelle

  • Vertical vs Horizontal
  • Scale up vs Scale out
  • Plusieurs petites instances plutôt qu’une grosse instance

Stateful vs stateless

  • Beaucoup de stateful dans les applications legacy
  • Nécessite de partager l’information d’état lorsque plusieurs workers
  • Le stateless élimine cette contrainte

Tolérance aux pannes

  • L’infrastructure n’est pas hautement disponible
  • L’API d’infrastructure est hautement disponible
  • L’application doit anticiper et réagir aux pannes

Stockage des données

  • Base de données relationnelles
  • Base de données NoSQL
  • Stockage bloc
  • Stockage objet
  • Stockage éphémère
  • Cache, temporaire

Design Tenets d’OpenStack (exemple) 1/2

  1. Scalability and elasticity are our main goals
  2. Any feature that limits our main goals must be optional
  3. Everything should be asynchronous. If you can’t do something asynchronously, see #2
  4. All required components must be horizontally scalable

Design Tenets d’OpenStack (exemple) 2/2

  1. Always use shared nothing architecture (SN) or sharding. If you can’t Share nothing/shard, see #2
  2. Distribute everything. Especially logic. Move logic to where state naturally exists.
  3. Accept eventual consistency and use it where it is appropriate.
  4. Test everything. We require tests with submitted code. (We will help you if you need it)

https://wiki.openstack.org/wiki/BasicDesignTenets

Concevoir une infrastructure pour le cloud

Automatisation

  • Automatiser la gestion de l’infrastructure : indispensable
  • Création des ressources
  • Configuration des ressources

Infrastructure as Code

  • Travailler comme un développeur
  • Décrire son infrastructure sous forme de code (Heat, Ansible)
  • Suivre les changements dans un VCS (git)
  • Utiliser des outils de tests

Besoin d’orchestration

  • Manager tous les types de ressources par un point d’entrée
  • Description de l’infrastructure dans un fichier (template)
  • Heat (intégré à OpenStack), Terraform

Tests et intégration continue

  • Style de code
  • Validation de la syntaxe
  • Voire plus si possible

Autoscaling group

  • Groupe d’instances similaires
  • Nombre variable d’instances
  • Scaling automatique en fonction de métriques

L’isolation

  • Niveau control plane : Tenant (projet)
  • Niveau réseau : L2, L3, security groups

Multi-tenant

  • Notion générale : un déploiement du logiciel permet de multiples utilisations
  • Un cloud OpenStack permet aux utilisateurs de travailler dans des environnements isolés
  • Les instances, réseaux, images, etc. sont associés à un tenant
  • Certaines ressources peuvent être partagées entre tenants (exemple :image publique)
  • On peut aussi parler de “projet”

Les instances

  • Éphémère
  • Pets vs Cattle
  • Basé sur une image
  • API de metadata

L’API de metadata

  • API à destination des instances
  • Standard de fait initié par AWS
  • Accessible depuis l’instance sur http://169.254.169.254/
  • Expose des informations relatives à l’instance
  • Expose un champ libre dit “userdata”

Réseau

  • Fixed IP
  • Multiples interfaces réseaux
  • Floating IPs : pool, allocate, associate

Floating IPs

  • IP flottantes
  • Surcharge des “Fixed IPs”
  • Non portée par l’instance
  • Souvent une IP “publique”
  • Une fois allouée à un tenant, l’IP est réservée
  • Elle est ensuite associable et désassociable à loisir

Security groups

  • Équivalent à un firewall devant chaque instance
  • Une instance peut être associée à un ou plusieurs groupes de sécurité
  • Gestion des accès en entrée et sortie
  • Règles par protocole (TCP/UDP/ICMP) et par port
  • Cible une adresse IP, un réseau ou un autre groupe de sécurité

Flavors

  • Gabarit
  • Équivalent des “instance types” d’AWS
  • Définit un modèle d’instance en termes de CPU, RAM, disque (racine), disque éphémère
  • Un disque de taille nul équivaut à prendre la taille de l’image de base
  • Le disque éphémère a, comme le disque racine, l’avantage d’être souvent local donc rapide

Keypairs

  • Paires de clé
  • Clés SSH publiques/privés
  • Le cloud a connaissance de la clé publique
  • La clé publique est injectée dans les instances

Monitoring

Monitoring

  • Prendre en compte le cycle de vie des instances : DOWN != ALERT
  • Monitorer le service plus que le serveur

Backup

Backuper, quoi ?

  • Être capable de recréer ses instances (et le reste de son infrastructure)
  • Données (applicatives, logs) : block, objet

Un exemple : l’équipe 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
  • Infrastructure as code
  • Infrastructure ouverte : code “open source”
  • Utilise du cloud (hybride)

Conclusion

Pour conclure

  • Le cloud révolutionne l’IT
  • OpenStack est le projet libre phare sur la partie IaaS
  • L’utilisation d’un cloud IaaS implique des changements de pratique
  • Les métiers d’architecture logicielle et infra évoluent