Architecture OpenStack¶

Introduction¶

OpenStack est une plateforme cloud open source composée de services modulaires interconnectés. Chaque service gère un aspect spécifique de l'infrastructure (compute, storage, network) et communique via des APIs REST.

Comprendre cette architecture est fondamental pour le déploiement, l'opération et le troubleshooting.

Prérequis¶

Notions de base cloud computing (IaaS)
Concepts REST API
Phase 0 - Prérequis

Points à apprendre¶

Vue d'ensemble - Diagramme Contexte (C4 L1)¶

graph TB
    admin[Cloud Administrator<br/>Déploie, configure et maintient<br/>l'infrastructure OpenStack]
    operator[Cloud Operator<br/>Gère les quotas, projets<br/>et utilisateurs]
    tenant[Tenant/User<br/>Consomme les ressources cloud<br/>VMs, volumes, networks]
    devops[DevOps/Developer<br/>Automatise via API/Terraform]

    openstack[OpenStack Cloud<br/>Plateforme IaaS privée<br/>Nova, Neutron, Cinder, Glance, Keystone]

    ldap[LDAP/AD<br/>Authentification externe]
    monitoring[Monitoring Stack<br/>Prometheus, Grafana]
    ceph[Ceph Storage<br/>Stockage distribué]
    network[Physical Network<br/>Switches, routers]

    admin -->|Déploie & Configure<br/>Kolla-Ansible, SSH| openstack
    operator -->|Administre<br/>Horizon, CLI| openstack
    tenant -->|Provisionne ressources<br/>Horizon, API| openstack
    devops -->|Automatise<br/>API REST, Terraform| openstack

    openstack -->|Authentifie users<br/>LDAP| ldap
    openstack -->|Expose métriques<br/>Prometheus| monitoring
    openstack -->|Stocke données<br/>RADOS, RBD| ceph
    openstack -->|Connecte VMs<br/>VLAN, VXLAN| network

    classDef person fill:#08427B
    classDef system fill:#1168BD
    classDef external fill:#999999

    class admin,operator,tenant,devops person
    class openstack system
    class ldap,monitoring,ceph,network external

Architecture Services - Diagramme Container (C4 L2)¶

graph TB
    user[User/Admin<br/>Utilise le cloud]

    subgraph "OpenStack Cloud"
        horizon[Horizon<br/>Django<br/>Dashboard Web UI]
        keystone[Keystone<br/>Python/WSGI<br/>Identity & Auth<br/>Port 5000]

        nova_api[Nova API<br/>Python/WSGI<br/>Compute API<br/>Port 8774]
        nova_sched[Nova Scheduler<br/>Python<br/>Placement des VMs]
        nova_cond[Nova Conductor<br/>Python<br/>Coordination DB]
        nova_compute[Nova Compute<br/>Python<br/>Gestion hyperviseur]

        neutron_api[Neutron Server<br/>Python/WSGI<br/>Network API<br/>Port 9696]
        neutron_agents[Neutron Agents<br/>Python<br/>L2/L3/DHCP/Metadata]

        glance[Glance<br/>Python/WSGI<br/>Image Service<br/>Port 9292]
        cinder_api[Cinder API<br/>Python/WSGI<br/>Block Storage<br/>Port 8776]
        cinder_vol[Cinder Volume<br/>Python<br/>Backend Driver]

        placement[Placement<br/>Python/WSGI<br/>Resource Inventory<br/>Port 8778]

        mariadb[(MariaDB Galera<br/>MariaDB<br/>Databases services)]
        rabbitmq{RabbitMQ<br/>AMQP<br/>Message Bus}
        memcached[Memcached<br/>Memcached<br/>Token Cache]
    end

    ceph[Ceph Cluster<br/>Stockage distribué]
    hypervisor[KVM/libvirt<br/>Virtualisation]

    user -->|Accède<br/>HTTPS| horizon
    user -->|API calls<br/>REST/HTTPS| nova_api
    horizon -->|Auth<br/>HTTP| keystone
    horizon -->|Compute ops<br/>HTTP| nova_api

    nova_api -->|Valide tokens<br/>HTTP| keystone
    nova_api -->|Publie messages<br/>AMQP| rabbitmq
    nova_sched -->|Consomme<br/>AMQP| rabbitmq
    nova_cond -->|Consomme<br/>AMQP| rabbitmq
    nova_compute -->|Consomme<br/>AMQP| rabbitmq
    nova_compute -->|Gère VMs<br/>libvirt| hypervisor

    neutron_api -->|Messages<br/>AMQP| rabbitmq
    neutron_agents -->|Messages<br/>AMQP| rabbitmq

    keystone -->|Stocke<br/>SQL| mariadb
    nova_api -->|Stocke<br/>SQL| mariadb
    neutron_api -->|Stocke<br/>SQL| mariadb
    keystone -->|Cache tokens<br/>Memcached| memcached

    glance -->|Stocke images<br/>RBD| ceph
    cinder_vol -->|Stocke volumes<br/>RBD| ceph
    nova_compute -->|Disques éphémères<br/>RBD| ceph

    classDef container fill:#438DD5
    classDef database fill:#23A8D5
    classDef queue fill:#F2C94C
    classDef external fill:#999999

    class horizon,keystone,nova_api,nova_sched,nova_cond,nova_compute,neutron_api,neutron_agents,glance,cinder_api,cinder_vol,placement,memcached container
    class mariadb database
    class rabbitmq queue
    class ceph,hypervisor external

Services principaux¶

Service	Nom de code	Rôle
Identity	Keystone	Authentification, autorisation, catalogue de services
Compute	Nova	Gestion des instances (VMs)
Network	Neutron	Réseaux virtuels, routeurs, firewalls
Block Storage	Cinder	Volumes persistants attachables
Image	Glance	Stockage et distribution des images
Object Storage	Swift	Stockage objet distribué
Dashboard	Horizon	Interface web
Orchestration	Heat	Templates d'infrastructure
Telemetry	Ceilometer/Gnocchi	Métriques et billing
Container	Magnum	Clusters Kubernetes/Swarm
Load Balancer	Octavia	LBaaS (Load Balancer as a Service)

Flux d'authentification et création VM¶

sequenceDiagram
    actor User
    participant Horizon/CLI
    participant Keystone
    participant Nova API
    participant Placement
    participant Nova Scheduler
    participant Nova Conductor
    participant Nova Compute
    participant Glance
    participant Neutron
    participant RabbitMQ

    User->>Horizon/CLI: 1. Login credentials
    Horizon/CLI->>Keystone: 2. POST /auth/tokens
    Keystone-->>Horizon/CLI: 3. Token + Service Catalog
    Horizon/CLI-->>User: 4. Authenticated session

    User->>Nova API: 5. POST /servers (create VM)
    Nova API->>Keystone: 6. Validate token
    Keystone-->>Nova API: 7. Token valid

    Nova API->>Placement: 8. Get resource providers
    Placement-->>Nova API: 9. Available hosts

    Nova API->>RabbitMQ: 10. build_instance message
    RabbitMQ->>Nova Conductor: 11. Consume message
    Nova Conductor->>RabbitMQ: 12. schedule_instance
    RabbitMQ->>Nova Scheduler: 13. Consume

    Nova Scheduler->>Placement: 14. Claim resources
    Nova Scheduler->>RabbitMQ: 15. build_on_host (compute-1)
    RabbitMQ->>Nova Compute: 16. Consume

    Nova Compute->>Glance: 17. GET image
    Glance-->>Nova Compute: 18. Image data (RBD)

    Nova Compute->>Neutron: 19. Create port
    Neutron-->>Nova Compute: 20. Port/VIF info

    Nova Compute->>Nova Compute: 21. libvirt: create domain
    Nova Compute->>RabbitMQ: 22. instance_update (ACTIVE)
    RabbitMQ->>Nova Conductor: 23. Update DB
    Nova API-->>User: 24. VM Running

Architecture Controller Node (C4 L3)¶

graph TB
    subgraph "Controller Node"
        haproxy[HAProxy<br/>Load Balancer<br/>VIP: 10.0.0.10<br/>Balance API requests]
        keepalived[Keepalived<br/>VRRP<br/>Gère VIP failover]

        horizon[Horizon<br/>Port 443<br/>Dashboard Web]
        keystone[Keystone<br/>Port 5000<br/>Identity Service]
        nova_api[Nova API<br/>Port 8774<br/>Compute API]
        nova_sched[Nova Scheduler<br/>Placement VMs]
        nova_cond[Nova Conductor<br/>DB Coordination]

        neutron[Neutron Server<br/>Port 9696<br/>Network API]
        l3_agent[L3 Agent<br/>Routing, NAT]
        dhcp_agent[DHCP Agent<br/>DHCP Service]
        meta_agent[Metadata Agent<br/>VM Metadata]

        glance[Glance API<br/>Port 9292<br/>Image Service]
        cinder[Cinder API<br/>Port 8776<br/>Volume API]
        placement[Placement<br/>Port 8778<br/>Resource Tracking]

        mariadb[(MariaDB<br/>Port 3306<br/>Galera Cluster)]
        rabbitmq{RabbitMQ<br/>Port 5672<br/>Message Queue}
        memcached[Memcached<br/>Port 11211<br/>Token Cache]
    end

    haproxy -->|Proxies HTTP| keystone
    haproxy -->|Proxies HTTP| nova_api
    haproxy -->|Proxies HTTP| neutron
    haproxy -->|Proxies HTTP| glance
    haproxy -->|Proxies HTTP| cinder
    haproxy -->|Proxies HTTP| horizon

    keystone -->|Stores SQL| mariadb
    nova_api -->|Stores SQL| mariadb
    neutron -->|Stores SQL| mariadb

    nova_sched -->|Messages AMQP| rabbitmq
    nova_cond -->|Messages AMQP| rabbitmq
    l3_agent -->|Messages AMQP| rabbitmq

    keystone -->|Cache TCP| memcached

    classDef component fill:#85BBF0
    classDef database fill:#23A8D5
    classDef queue fill:#F2C94C

    class haproxy,keepalived,horizon,keystone,nova_api,nova_sched,nova_cond,neutron,l3_agent,dhcp_agent,meta_agent,glance,cinder,placement,memcached component
    class mariadb database
    class rabbitmq queue

Architecture Compute Node (C4 L3)¶

graph TB
    subgraph "Compute Node"
        nova_compute[Nova Compute<br/>Python<br/>Gestion lifecycle VMs<br/>Interface libvirt]

        ovs_agent[OVS Agent<br/>Python<br/>Open vSwitch Agent<br/>Gère bridges & flows]
        l3_dvr[L3 Agent DVR<br/>Python<br/>Distributed Virtual Router<br/>si DVR activé]
        metadata[Metadata Proxy<br/>Python<br/>cloud-init metadata]

        libvirt[libvirtd<br/>C<br/>Gestion hyperviseur<br/>Socket: /var/run/libvirt]
        qemu[QEMU-KVM<br/>C<br/>Hyperviseur<br/>VMs execution]

        ovs[Open vSwitch<br/>C<br/>Virtual Switch<br/>br-int, br-tun, br-ex]

        ceph_client[Ceph Client<br/>librbd<br/>Accès RBD<br/>Disques VMs]
    end

    rabbitmq[RabbitMQ<br/>Message Bus<br/>Controllers]
    ceph[Ceph Cluster<br/>Storage Backend]

    nova_compute -->|Reçoit instructions<br/>AMQP| rabbitmq
    nova_compute -->|Crée/gère VMs<br/>libvirt API| libvirt
    libvirt -->|Lance<br/>Fork| qemu

    ovs_agent -->|Config réseau<br/>AMQP| rabbitmq
    ovs_agent -->|Configure flows<br/>OpenFlow| ovs

    l3_dvr -->|Routing updates<br/>AMQP| rabbitmq
    l3_dvr -->|NAT rules<br/>iptables/netns| ovs

    nova_compute -->|Attach disques<br/>librbd| ceph_client
    ceph_client -->|RADOS I/O<br/>TCP| ceph

    qemu -->|vNIC tap<br/>virtio| ovs

    classDef component fill:#85BBF0
    classDef external fill:#999999

    class nova_compute,ovs_agent,l3_dvr,metadata,libvirt,qemu,ovs,ceph_client component
    class rabbitmq,ceph external

Message Queue (RabbitMQ) - Architecture¶

graph TB
    subgraph "RabbitMQ Cluster"
        exchange{openstack Exchange<br/>Topic Exchange<br/>Route messages par routing key}

        nova_q[nova Queue<br/>Queue<br/>nova-conductor.*<br/>nova-scheduler.*<br/>nova-compute.*]
        neutron_q[neutron Queue<br/>Queue<br/>q-agent-notifier.*<br/>l3_agent.*<br/>dhcp_agent.*]
        cinder_q[cinder Queue<br/>Queue<br/>cinder-scheduler.*<br/>cinder-volume.*]
    end

    nova_api[Nova API<br/>Publisher]
    nova_cond[Nova Conductor<br/>Consumer]
    nova_sched[Nova Scheduler<br/>Consumer]
    nova_compute[Nova Compute<br/>Consumer]

    neutron_srv[Neutron Server<br/>Publisher]
    l3_agent[L3 Agent<br/>Consumer]
    ovs_agent[OVS Agent<br/>Consumer]

    nova_api -->|Publie<br/>conductor.*| exchange
    exchange -->|Route| nova_q
    nova_q -->|Consomme| nova_cond
    nova_q -->|Consomme| nova_sched
    nova_q -->|Consomme| nova_compute

    neutron_srv -->|Publie<br/>agent.*| exchange
    exchange -->|Route| neutron_q
    neutron_q -->|Consomme| l3_agent
    neutron_q -->|Consomme| ovs_agent

    classDef queue fill:#F2C94C
    classDef component fill:#85BBF0

    class exchange,nova_q,neutron_q,cinder_q queue
    class nova_api,nova_cond,nova_sched,nova_compute,neutron_srv,l3_agent,ovs_agent component

Base de données¶

Chaque service OpenStack possède sa propre base de données.

-- Bases de données typiques
SHOW DATABASES;
+--------------------+
| Database           |
+--------------------+
| keystone           |
| nova               |
| nova_api           |
| nova_cell0         |
| neutron            |
| cinder             |
| glance             |
| placement          |
| heat               |
| octavia            |
+--------------------+

Catalogue de services (Keystone)¶

# Voir le catalogue
openstack catalog list

# Exemple de sortie
+----------+----------+-----------------------------------------+
| Name     | Type     | Endpoints                               |
+----------+----------+-----------------------------------------+
| keystone | identity | internal: http://10.0.0.10:5000/v3      |
|          |          | public: https://cloud.example.com:5000/v3|
|          |          | admin: http://10.0.0.10:5000/v3         |
| nova     | compute  | internal: http://10.0.0.10:8774/v2.1    |
|          |          | public: https://cloud.example.com:8774   |
| neutron  | network  | internal: http://10.0.0.10:9696         |
|          |          | public: https://cloud.example.com:9696   |
| glance   | image    | internal: http://10.0.0.10:9292         |
|          |          | public: https://cloud.example.com:9292   |
| cinder   | volume   | internal: http://10.0.0.10:8776/v3      |
|          |          | public: https://cloud.example.com:8776   |
+----------+----------+-----------------------------------------+

Types d'endpoints¶

Type	Usage
public	Accessible depuis l'extérieur (internet/clients)
internal	Communication entre services OpenStack
admin	Opérations d'administration (souvent = internal)

Exemples pratiques¶

Exploration architecture existante¶

# Lister les services
openstack service list

# Détails d'un service
openstack service show nova

# Endpoints
openstack endpoint list --service nova

# Voir l'état des services
openstack compute service list
openstack network agent list
openstack volume service list

Diagramme d'architecture à dessiner¶

Exercice : Dessinez l'architecture d'un déploiement avec : - 3 controllers (HA) - 2 compute nodes - 1 cluster Ceph (3 nodes)

Incluez : - Les réseaux (management, provider, storage) - Le load balancer (HAProxy) - Les services sur chaque nœud

Ressources¶

Checkpoint¶

Je peux dessiner l'architecture OpenStack avec les services principaux
Je comprends le rôle de Keystone dans l'authentification
Je peux expliquer le flux de création d'une VM
Je comprends la différence entre controller et compute node
Je connais le rôle de RabbitMQ et MariaDB
Je comprends les types d'endpoints (public, internal, admin)
Je sais interpréter les diagrammes C4 (Context, Container, Component)