Cloud Prive OpenStack¶

Concepts de cloud computing¶

Le cloud computing est un modele de livraison de ressources informatiques a la demande, mesurables et accessibles via le reseau.

IaaS vs PaaS vs SaaS¶

graph TB
    subgraph IAAS["IaaS<br/>Infrastructure as a Service"]
        I1["Vous gerez : OS, Middleware, Apps, Donnees"]
        I2["Le fournisseur gere : Serveurs, Stockage, Reseau, Virtualisation"]
    end

    subgraph PAAS["PaaS<br/>Platform as a Service"]
        P1["Vous gerez : Apps, Donnees"]
        P2["Le fournisseur gere : OS, Middleware, Runtime, Infra"]
    end

    subgraph SAAS["SaaS<br/>Software as a Service"]
        S1["Vous gerez : Configuration, Donnees utilisateur"]
        S2["Le fournisseur gere : Tout le reste"]
    end

Modele	Controle client	Exemple	Equivalent INDIO
IaaS	OS + Applications	AWS EC2, Azure VMs	OpenStack Nova
PaaS	Application uniquement	Heroku, Azure App Service	Heat + Octavia
SaaS	Configuration	Office 365, Gmail	Nextcloud (auto-heberge)

Cloud prive vs public vs hybride¶

Type	Avantages	Inconvenients
Public (Azure, AWS)	Elasticite, pas d'investissement initial, services manages	Dependance fournisseur, cout variable, souverainete
Prive (OpenStack)	Controle total, souverainete des donnees, couts previsibles	Investissement initial, maintenance, expertise requise
Hybride (les deux)	Meilleur des deux mondes, burst vers le public	Complexite, integration reseau/identite

---

OpenStack : presentation¶

OpenStack est une plateforme open source de cloud computing IaaS, geree par l'OpenStack Foundation. Elle permet de creer et gerer un cloud prive ou public a partir de ressources physiques (serveurs, stockage, reseau).

Principes de fonctionnement¶

• Chaque fonction (compute, reseau, stockage, identite) est un service independant
• Les services communiquent entre eux via des API REST standardisees
• Un catalogue de services (Keystone) permet la decouverte dynamique des endpoints
• Le deploiement suit un cycle de releases semestrielles (nommees par ordre alphabetique)

Releases recentes¶

Release	Date	Nom	Nouveautes majeures
27	Mars 2023	Antelope	OVN par defaut, Cinder multi-attach
28	Oct 2023	Bobcat	Ironic improvements, Nova live migration
29	Avril 2024	Caracal	Nova unified limits, Neutron OVN improvements
30	Oct 2024	Dalmatian	Keystone OIDC, Nova PCI passthrough

---

Architecture deployee¶

L'architecture suit le modele de reference a 3 plans : controle, donnees (compute) et reseau.

graph TB
    subgraph CONTROL["Plan de Controle (3 noeuds HA)"]
        C1["Controller 1"]
        C2["Controller 2"]
        C3["Controller 3"]
        VIP["VIP Keepalived<br/>+ HAProxy LB"]
        C1 --- VIP
        C2 --- VIP
        C3 --- VIP

        subgraph SERVICES_CTRL["Services"]
            API["APIs (Nova, Neutron, ...)"]
            MDB["MariaDB Galera (quorum 3)"]
            RMQ["RabbitMQ (mirrored queues)"]
            MEM["Memcached (sessions)"]
        end
    end

    subgraph COMPUTE["Plan Compute (scalable)"]
        N1["Compute 1<br/>KVM/Libvirt<br/>Nova-compute"]
        N2["Compute 2<br/>KVM/Libvirt<br/>Nova-compute"]
        N3["Compute N...<br/>(ajout a chaud)"]
    end

    subgraph NETWORK["Plan Reseau"]
        OVN["OVN Controllers<br/>Routage distribue"]
        FIP["Floating IPs<br/>Provider Networks"]
    end

    subgraph STORAGE["Stockage"]
        CEPH["Ceph Cluster<br/>RBD Pools"]
    end

    VIP --> N1
    VIP --> N2
    VIP --> N3
    N1 --> CEPH
    N2 --> CEPH
    OVN --> N1
    OVN --> N2

Plan de controle (3 noeuds)¶

La haute disponibilite repose sur :

Composant	Mecanisme HA	Quorum
API endpoints	HAProxy round-robin + VIP Keepalived	2/3 noeuds
MariaDB Galera	Replication synchrone multi-master	2/3 noeuds (quorum)
RabbitMQ	Mirrored queues avec politique ha-all	2/3 noeuds
Memcached	Sessions distribuees	N/A (stateless)

Noeuds Compute¶

Les noeuds compute sont stateless : ils n'hebergent aucune donnee persistante. Si un noeud tombe, les VMs sont evacuees vers les autres noeuds via live migration.

Caracteristique	Detail
Hyperviseur	KVM avec Libvirt
Ajout a chaud	Un nouveau noeud compute peut etre ajoute sans interruption
CPU pinning	Affectation de coeurs physiques dedies pour les workloads sensibles a la latence
Overcommit	Ratio configurable (par defaut 16:1 CPU, 1.5:1 RAM)

---

Services OpenStack¶

Service	Nom de code	Fonction	Backend / Detail
Dashboard	Horizon	Interface web d'administration et self-service	Apache HTTP, theming personnalise
Compute	Nova	Gestion du cycle de vie des VMs (create, resize, migrate, shelve)	KVM/Libvirt, scheduler multi-criteres
Reseau	Neutron	SDN : reseaux virtuels, sous-reseaux, routeurs, firewall	OVN (Open Virtual Network)
Stockage bloc	Cinder	Volumes persistants attaches aux VMs	Ceph RBD, multi-attach supporte
Images	Glance	Catalogue d'images (ISO, templates, snapshots)	Ceph RBD, formats qcow2/raw
Identite	Keystone	Authentification, autorisation, catalogue de services	Federation AD/LDAP via LDAPS
Orchestration	Heat	Deploiement par templates (stacks de ressources)	Compatible HOT et Terraform
Load Balancer	Octavia	Repartition de charge L4 (TCP) et L7 (HTTP/HTTPS)	VMs Amphora, health monitors

---

Deploiement Kolla-Ansible¶

Le deploiement est entierement automatise via Kolla-Ansible, qui utilise des conteneurs Docker pour chaque service OpenStack.

Pourquoi Kolla-Ansible ?¶

Avantage	Detail
Conteneurisation	Chaque service tourne dans son conteneur Docker, isolation et rollback facile
Reproductibilite	Configuration declarative en YAML, deploiement identique a chaque fois
Mise a jour	Upgrade release par release (rolling upgrade sans interruption)
Simplicite	Un seul outil pour deployer l'ensemble de la plateforme

Fichiers cles¶

Fichier	Contenu
globals.yml	Configuration globale (VIP, backend reseau, options de services)
passwords.yml	Mots de passe generes (chiffres avec Ansible Vault)
inventory	Liste des noeuds et leurs roles (control, compute, network, storage)
kolla-ansible deploy	Commande de deploiement complet
kolla-ansible reconfigure	Application de changements de configuration

---

Integration avec l'infrastructure¶

graph LR
    subgraph OPENSTACK["OpenStack"]
        NOVA["Nova (Compute)"]
        NEUTRON["Neutron (Reseau)"]
        CINDER["Cinder (Bloc)"]
        GLANCE["Glance (Images)"]
        KEYSTONE["Keystone (Identite)"]
        OCTAVIA["Octavia (LB)"]
    end

    CEPH["Ceph RBD"] --> CINDER
    CEPH --> GLANCE
    OVN["OVN SDN"] --> NEUTRON
    AD["Active Directory<br/>LDAPS"] --> KEYSTONE
    VAULT["HashiCorp Vault<br/>Certificats TLS"] --> NOVA

Integration	Detail technique
Ceph RBD	Pools dedies pour Cinder (volumes) et Glance (images), replication facteur 3
OVN	Remplace Open vSwitch classique, routage distribue directement sur les computes
AD/LDAPS	Federation Keystone, mapping groupes AD vers projets OpenStack
CPU pinning	Flavors dediees (m1.pinned) pour les workloads HPC et bases de donnees
Octavia	Load balancer as a Service, health checks HTTP/TCP, SSL termination
Vault	Certificats TLS pour les endpoints API (via PKI intermediaire)

---

Isolation des tenants¶

OpenStack supporte le multi-tenancy : plusieurs equipes ou projets partagent la meme plateforme tout en etant isoles les uns des autres.

Mecanisme	Fonction	Granularite
Projets	Isolation logique des ressources (VMs, reseaux, volumes)	Par equipe ou application
Quotas	Limitation des ressources par projet (vCPU, RAM, stockage, IPs)	Configurable par projet
Security Groups	Pare-feu par VM (regles ingress/egress par port/protocole)	Par instance ou groupe
Floating IPs	Adresses publiques attribuees dynamiquement aux VMs	Par instance
RBAC	Roles (admin, member, reader) par projet et par domaine	Par utilisateur