Aller au contenu

Notes1

  • Différence entre les services Core et optionels

Pourquoi Openstack#

Introduction au Cloud#

Modeles de cloud#

  • 4 modeles (classique, IaaS, PaaS, SaaS)
  • (schema des responsabilités)
  • les publics qui correspondent (devops, devs, utilisateurs)

Avantages#

  • efficacité, fiabilité, flexibilité
  • applications comme utilités sur internet
  • configuration et manipulation des apps en ligne
  • aucun logiciel requis
  • outils de déploiement et developmeent en ligne
  • resources disponibles en ligne
  • libre service sur demande
  • rentable et économique

Acteurs internationnaux du cloud#

  • Amazon (AWS)
  • VMWare
  • Google (GCP)
  • Apache (CloudStack)
  • Rackspace
  • Microsoft (Azure)
  • Heroku
  • Openstack

et aussi

  • terremark ?
  • softlayer ?
  • savvis ?

Architecture d'Openstack#

Presentation du projet#

  • Middleware Cloud ouvert / libre
  • Solution de cloud privé
  • Naissance en 2010
    • Rackspace (stockage) + NASA (calcul)
  • Fondation Openstack depuis 2012
    • Juridique
    • RH (dev, marketing, release manager)
    • Infrastructure
    • Organisation des OpenStack summit (4,5K participants)
    • 500 organisations
    • 23K membres individuels
  • Ecrit en python et distribué sous licence Apache 2
  • Nombreux contributeurs
  • Versions
    • Dernieres releases: ...
    • 6 mois d'intervale entre les versions
    • Notion de LTS (FIXME: screenshot)
  • Alternative:
    • Cloudstack (Apache) https://cloudstack.apache.org/
    • Eucalyptus ( https://www.eucalyptus.cloud/ )
    • OpenNebula ( https://opennebula.io/ )

utilisateurs d'openstack#

Contributeurs

  • ~1500 contributeurs
  • 70 organisations
    • de 7K bogues corrigés
  • 800K chaînes traduites
  • RedHat, IBM, Dell, Intel, Cisco, Juniper, NetApp, HP, VMWare, Google, Yahoo,

Développement

  • Ouvert à tous
  • Cycles courts
  • Git, Github, Gerrit, Launchpad, Jenkins
  • Très actifs (17k commits, progression annuelle +25%)

Utilisateurs

  • Public: CERN, Harvard, INFN, MIT, Wikimedia, DGFIP,
  • Privé: OVH, Paypal, Seagate, Orange, Disney, Sony, BMW, etc.
  • Cloud souverain FR: Cloudwatt (Orange, Thales), Numergy (SFR, Bull)

Architecture#

Version simple#

  • du hardware standard
  • OS organisé autour de "services"
  • un dashboard (transverse)
  • une API

Composants Core (vue détaillée)#

  • Dashboard
  • Compute
  • Network
  • Image
  • Object Storage
  • Block Strorage
  • Identity

FIXME: schéma des communication entre macro-services

Composants Core (vue micro)#

FIXME: schéma des communication entre micro-services

TP 0 : installation#

Prerequis

  • Connaissances en virtualisation et bases réseau
  • Virtualbox
  • 8Go de RAM
  • 4 VCPU
  • 50 Go d'espace disque

=> on se focalise d'abord sur l'utilisation avant d'apprendre à le déployer

Configurer les réseaux

  • Management network
  • Internal network
  • External network
  • External network (again)

Forcer "Allow all" sur le promiscuous mode

Ref. https://docs.openstack.org/kolla-ansible/latest/admin/production-architecture-guide.html

Ref. https://docs.openstack.org/devstack/latest/networking.html

TP 0: recovery#

Relancer la BDD

$ kolla-ansible -i all-in-one -e mariadb_recovery

Relancer Nova

$ kolla-ansible -i all-in-one --tags nova

Password

$ cat /etc/kolla/admin-openrc.sh

TP 0 : Se connecter à une VM#

Présentation des services core#

Nova#

Glance#

...#

Vocabulaire#

Identité et acces#

  • Tenant/Projet
  • Utilisateur
  • Quota
  • Catalogue Endpoint

Calcul/Serveur:#

  • image
    • OS que l'on souhaite déployer
    • installation déjà réalisé & packagée
  • instance
    • vm en cours d'exécution dans Openstack
  • type d'instance (ou flavor)
    • configuration de la machine (= sa "taille")
  • user data
    • customiser le déploiement de la machine
    • ex: commandes à exécuter à la finalisation de la configuration de la vm
  • metadata
    • rendre disponible des informations à l'ensemble des VM des info les concernant
    • permet l'introspection (ex: récupérer l'id, etc.)
  • cloud-init
    • systeme de config des VM
    • choix de services operationels, etc.

Stockage#

  • Volume
    • Volumes Cinder
  • Conteneur
    • Objets Cinder / Swift

Réseau et sécurité#

  • Groupe de sécurité
    • Définition d'une politique de sécurité
    • pour les VMs
  • Paire de clefs
    • clefs à utiliser pour l'acces en SSH aux VMs
  • IP flottante
    • permet d'accéder aux VMs depuis l'extérieur

Orchestration#

  • Stack
    • Ensemble de resources déjà deployées
  • Template

TP-2 : creer votre projet#

Voir exercices/02-project-setup/ENONCE.md

TP-3 : Déployer votre premiere instance#

Voir exercices/03-first-instance/ENONCE.md

Services complémentaires#

Cf. screenshot services complémentaires

FIXME: TP: ajouter des services complémentaires (ex: Trove, ou Manila, ou Ceilometer, ou Heat)

Q: Log Visualizer ? (quelle intégration?)

Q: Minitoring (telegraf, influxdb, grafana)

OpenStack Kolla Ansible#

Notion de micro-services#

  • Monolith vs Microservices
  • Notion d'API
  • Docker, etC.

Présentation de Ansible#

Présentation de Kolla#

  • Projet géré par OpenStack
  • 3 réseaux

Mini-projet#

GYR: Questions#

equivalent CLI de chaque opération ?#

c'est quoi un vCPU ? (comment c'est défini?)#

* https://wiki.openstack.org/wiki/VirtDriverGuestCPUTopology * https://docs.openstack.org/nova/pike/admin/cpu-topologies.html

fonctionnement des IP flottantes ?#

Floating IP addresses in OpenStack serve as a way to provide externally accessible, static IP addresses to instances within a private cloud. They are essential for enabling communication between instances and external networks, as well as for providing stable, reachable endpoints for applications or services running on those instances. Floating IPs are particularly useful in situations where you need to maintain consistent access to an instance or service, even when the underlying virtual machine might change or be replaced.

Here's how floating IPs work in OpenStack:

Allocation: In OpenStack, floating IPs are allocated from a pool of available public IP addresses. These addresses are managed by the OpenStack Networking service (Neutron). An administrator or user with appropriate permissions can allocate a floating IP from the pool.

Association: Once a floating IP is allocated, it can be associated with an instance. This association is essentially a mapping between the floating IP and the private IP address of the instance. This allows external traffic to be directed to the correct instance within the private network.

NAT (Network Address Translation): OpenStack uses NAT to enable communication between the floating IP address and the private IP address of the instance. When external traffic reaches the floating IP, it is translated to the private IP address of the instance by a Neutron router or other network devices. This translation is performed in both directions, allowing bidirectional communication between the instance and external networks.

Disassociation and Release: If needed, a floating IP can be disassociated from an instance and either associated with another instance or released back into the pool of available floating IPs. This flexibility allows users to easily reassign public IP addresses to different instances as needed.