Concepts Haute Disponibilité¶

Introduction¶

La haute disponibilité (HA) garantit la continuité de service malgré les pannes. Pour OpenStack en production, c'est un prérequis absolu. Cette section couvre les concepts fondamentaux avant leur implémentation.

Prérequis¶

Compréhension de l'architecture OpenStack multi-nœuds
Phase 3 - Kolla-Ansible
Notions de clustering et réplication

Points à apprendre¶

Niveaux de disponibilité¶

graph TB
    subgraph app["Niveau 1: Application"]
        stateless["Stateless Services<br/>(API, Workers)"]
        aa["Active/Active<br/>Load Balanced"]
    end

    subgraph infra["Niveau 2: Infrastructure"]
        stateful["Stateful Services<br/>(DB, MQ)"]
        cluster["Clustering<br/>Replication"]
    end

    subgraph net["Niveau 3: Réseau"]
        vip["VIP Failover<br/>(Keepalived)"]
        bond["Bonding/LACP<br/>Redundant Links"]
    end

    subgraph storage["Niveau 4: Stockage"]
        ceph["Ceph<br/>Réplication 3x"]
        spof["Pas de SPOF"]
    end

    stateless --> aa
    stateful --> cluster
    vip --> bond
    ceph --> spof

Métriques de disponibilité¶

Disponibilité	Downtime/an	Downtime/mois	Niveau
99%	3.65 jours	7.3 heures	Basic
99.9%	8.76 heures	43.8 minutes	Standard
99.99%	52.6 minutes	4.4 minutes	Enterprise
99.999%	5.26 minutes	26.3 secondes	Carrier-grade

Stratégies HA par composant¶

graph TB
    subgraph control["Control Plane HA"]
        api["API Services<br/>Active/Active<br/>Nova, Neutron, Glance<br/>Derrière HAProxy"]
        db["MariaDB<br/>Galera Cluster<br/>Réplication synchrone<br/>3 nœuds minimum"]
        mq["RabbitMQ<br/>Cluster + Mirroring<br/>Queues mirrorées<br/>Quorum queues"]
        cache["Memcached<br/>Distributed<br/>Pas de réplication<br/>Régénération auto"]
    end

    subgraph network["Network HA"]
        vip["Virtual IP<br/>Keepalived VRRP<br/>Failover < 3s"]
        lb["HAProxy<br/>Active/Passive<br/>Health checks"]
        l3["L3 Agent<br/>VRRP ou L3 HA<br/>Routeurs redondants"]
    end

    subgraph storage_ha["Storage HA"]
        ceph_mon["Ceph MON<br/>Paxos Quorum<br/>3 ou 5 monitors"]
        ceph_osd["Ceph OSD<br/>CRUSH Rules<br/>Réplication 3x"]
    end

    api -->|"Connections<br/>SQL"| db
    api -->|"Messages<br/>AMQP"| mq
    vip -->|"Failover<br/>VRRP"| lb
    lb -->|"Distribute<br/>HTTP"| api

Types de clustering¶

Active/Active (A/A)¶

Tous les nœuds servent les requêtes
Load balancing requis
Idéal pour services stateless
Exemples: API services, workers

# Vérifier services active/active
docker ps --filter "name=nova_api" --format "{{.Names}}"
# Devrait montrer: nova_api sur chaque controller

Active/Passive (A/P)¶

Un seul nœud actif à la fois
Failover automatique
Pour services avec état difficile à partager
Exemples: certains agents réseau

Quorum-based¶

Majorité requise pour décisions
N = 2F + 1 (F = pannes tolérées)
Évite le split-brain
Exemples: Galera, RabbitMQ, Ceph MON

# Formules quorum
# 3 nœuds = tolérance 1 panne (quorum = 2)
# 5 nœuds = tolérance 2 pannes (quorum = 3)
# 7 nœuds = tolérance 3 pannes (quorum = 4)

Points de défaillance unique (SPOF)¶

graph LR
    subgraph before["Avant HA"]
        c1["1 Controller"]
        d1["1 Database"]
        n1["1 Network"]
    end

    subgraph after["Après HA"]
        c3["3 Controllers<br/>+ VIP"]
        d3["Galera Cluster<br/>3 nœuds"]
        n3["Bonding +<br/>Redundant Switches"]
    end

    before -.->|"Chaque composant = SPOF"| before
    after -.->|"Aucun SPOF<br/>Tolérance N-1 pannes"| after

Fencing et Split-Brain¶

Le split-brain survient quand un cluster se partitionne et chaque partie croit être le cluster principal.

# Solutions anti-split-brain

# 1. Quorum (Galera, RabbitMQ)
# - La minorité s'arrête automatiquement

# 2. STONITH (Shoot The Other Node In The Head)
# - Fencing physique via IPMI/iLO
# - Garantit qu'un nœud défaillant est vraiment arrêté

# 3. Arbitre externe
# - Nœud witness léger
# - Aide à atteindre le quorum

Architecture HA complète¶

graph TB
    users["Users<br/>API/Horizon"]

    subgraph dc["Datacenter"]
        vip["VIP<br/>Keepalived<br/>10.0.0.10"]

        subgraph ctrl1["Controller-1"]
            api1["APIs<br/>Nova, Neutron..."]
            db1["Galera<br/>Node 1"]
            mq1["RabbitMQ<br/>Node 1"]
            ha1["HAProxy"]
        end

        subgraph ctrl2["Controller-2"]
            api2["APIs<br/>Nova, Neutron..."]
            db2["Galera<br/>Node 2"]
            mq2["RabbitMQ<br/>Node 2"]
            ha2["HAProxy"]
        end

        subgraph ctrl3["Controller-3"]
            api3["APIs<br/>Nova, Neutron..."]
            db3["Galera<br/>Node 3"]
            mq3["RabbitMQ<br/>Node 3"]
            ha3["HAProxy"]
        end

        subgraph compute["Compute Nodes"]
            nova["Nova Compute<br/>x2"]
        end

        subgraph ceph_nodes["Ceph Cluster"]
            ceph["MON + OSD<br/>x3"]
        end
    end

    users -->|"HTTPS<br/>443"| vip
    vip -->|Active| ha1
    vip -.->|Standby| ha2
    vip -.->|Standby| ha3

    db1 <-->|"Galera Sync"| db2
    db2 <-->|"Galera Sync"| db3
    mq1 <-->|Mirror| mq2
    mq2 <-->|Mirror| mq3

RTO et RPO¶

Métrique	Définition	Objectif typique
RTO (Recovery Time Objective)	Temps max pour restaurer le service	< 5 minutes
RPO (Recovery Point Objective)	Perte de données max acceptable	0 (réplication synchrone)

# Configuration Galera pour RPO = 0
# wsrep_sync_wait = 1 (réplication synchrone)

# Test RTO
time docker stop galera_node1
# Mesurer temps avant que le cluster soit fonctionnel

Exemples pratiques¶

Vérifier la santé HA¶

#!/bin/bash
# check-ha-status.sh

echo "=== VIP Status ==="
ip addr show | grep "10.0.0.10" && echo "VIP: Active on this node"

echo -e "\n=== Galera Status ==="
docker exec mariadb mysql -e "SHOW STATUS LIKE 'wsrep_cluster_size';"

echo -e "\n=== RabbitMQ Cluster ==="
docker exec rabbitmq rabbitmqctl cluster_status

echo -e "\n=== HAProxy Stats ==="
curl -s http://localhost:1984/stats | grep -E "(UP|DOWN)"

echo -e "\n=== Service Distribution ==="
openstack compute service list

Test de failover simple¶

# Simuler panne controller-1
ssh controller-1 "sudo systemctl stop docker"

# Vérifier le failover VIP
for i in {1..10}; do
    ping -c 1 10.0.0.10 && echo "VIP reachable"
    sleep 1
done

# Vérifier les services
openstack server list  # Doit fonctionner via controller-2 ou 3

# Restaurer
ssh controller-1 "sudo systemctl start docker"

Ressources¶

Checkpoint¶

Je comprends les différents niveaux de disponibilité (99.9%, 99.99%)
Je peux expliquer Active/Active vs Active/Passive vs Quorum
Je sais identifier et éliminer les SPOF
Je comprends les concepts de split-brain et fencing
Je connais la différence entre RTO et RPO
Je peux décrire l'architecture HA d'un déploiement OpenStack