Skip to content

Phase 5 - Haute Disponibilité

Objectif

Configurer et valider l'architecture haute disponibilité d'OpenStack : HAProxy, Keepalived, MariaDB Galera, RabbitMQ cluster.

Architecture C4 - HA Layer

graph TB
    user["👤 Client<br/>API/Dashboard"]

    subgraph HA["HA Layer"]
        vip["🎯 VIP<br/>10.0.0.10 / 192.168.100.10"]
        haproxy1["HAProxy 1<br/>controller-1"]
        haproxy2["HAProxy 2<br/>controller-2"]
        haproxy3["HAProxy 3<br/>controller-3"]
    end

    subgraph DB["Database Cluster"]
        galera1[(MariaDB 1<br/>controller-1)]
        galera2[(MariaDB 2<br/>controller-2)]
        galera3[(MariaDB 3<br/>controller-3)]
        galera1 <-->|wsrep| galera2
        galera2 <-->|wsrep| galera3
    end

    subgraph MQ["Message Queue Cluster"]
        rabbit1["🐰 RabbitMQ 1<br/>controller-1"]
        rabbit2["🐰 RabbitMQ 2<br/>controller-2"]
        rabbit3["🐰 RabbitMQ 3<br/>controller-3"]
        rabbit1 <-->|Erlang| rabbit2
        rabbit2 <-->|Erlang| rabbit3
    end

    user -->|HTTPS| vip
    vip -->|Active| haproxy1
    vip -.->|Standby| haproxy2
    haproxy1 --> galera1

Sujets de cette phase

# Sujet Description Durée estimée
01 Concepts HA Patterns, SPOF, stratégies 1-2 heures
02 HAProxy configuration Load balancing, health checks 2-3 heures
03 Keepalived VIP VRRP, failover automatique 1-2 heures
04 MariaDB Galera Réplication synchrone 2-3 heures
05 RabbitMQ cluster Queues mirrored 2-3 heures
06 Tests de failover Scénarios de panne 2-3 heures

Checkpoint de validation

  • VIP accessible et bascule correctement
  • HAProxy distribue le trafic
  • Galera cluster 3 nœuds fonctionnel
  • RabbitMQ cluster synchronisé
  • Survivance à la perte d'un controller