⏱️ Haute Disponibilité (HA) – Redondance, Failover & Clustering

Ces deux termes décrivent le processus de basculement dans un cluster Active/Passive.

État Normal :
[ Nœud 1 (ACTIF) ] <---> [ Nœud 2 (PASSIF) ]

(Panne de Nœud 1 !)

État de Failover :
[ Nœud 1 (MORT) ]     [ Nœud 2 (DEVIENT ACTIF) ]
                    (Prend l'IP Flottante)

État (Nœud 1 réparé) :
[ Nœud 1 (PASSIF) ] <---> [ Nœud 2 (ACTIF) ]

(Intervention Admin : "Failback")

État Normal (Retour) :
[ Nœud 1 (REDEVIENT ACTIF) ] <---> [ Nœud 2 (REDEVIENT PASSIF) ]

SPOF : Le câble unique entre deux appareils (ex: Switch <-> Switch, ou Serveur <-> Switch).

Solution : Link Aggregation (LACP)

La Link Aggregation (Agrégation de liens), aussi appelée "EtherChannel" (Cisco) ou "Bonding" (Linux), permet de grouper plusieurs ports physiques (ex: 2 x 1 Gbps) en un seul lien logique (ex: 1 x 2 Gbps).

Bénéfices

• Redondance (HA) : Si un câble (ou port) du groupe est coupé, le trafic continue automatiquement sur les autres liens (pas de failover, c'est instantané).
• Bande Passante : La capacité est agrégée (ex: 2 Gbps).

Protocole : LACP (802.3ad)

LACP (Link Aggregation Control Protocol) est le protocole standard (ouvert) qui négocie dynamiquement la création du lien agrégé (le "bundle") entre les deux appareils (Mode "Active"/"Passive").

SPOF : Le switch lui-même (ex: le switch "core" de l'étage).

[ Serveur (LACP) ]
   (Lien A) │    │ (Lien B)
            ▼    ▼
 (FORWARD) [SW A] -- (BLOCKED) -- [SW B]

SPOF : La Passerelle par défaut (Default Gateway) (ex: 192.168.1.1). Si ce routeur tombe, tous les clients du LAN perdent l'accès à Internet et aux autres VLANs.

Solution : FHRP (First Hop Redundancy Protocol)

Un FHRP est un protocole qui permet à deux routeurs (ou plus) de partager une IP Flottante (Virtuelle), qui sera utilisée comme passerelle par les clients.

Les routeurs s'envoient des "heartbeats" (multicast) pour s'assurer que le maître est vivant.

Protocoles FHRP (Cluster Actif/Passif)

Le Load Balancer (Répartiteur de Charge) est le composant central de la Haute Disponibilité Applicative (Serveurs).

1. Répartition de Charge (Scalabilité)

Il distribue le trafic entrant (via un algorithme) sur un "pool" de serveurs back-end. (Voir guide Load Balancer).

2. Health Checks (HA)

C'est la fonction HA. Le LB agit comme un "moniteur" (sonde) qui vérifie la santé des serveurs en temps réel (ex: GET /healthz toutes les 5 sec).

Pool : [Srv A (UP)], [Srv B (UP)], [Srv C (UP)]

--- (Panne : Le service PHP sur Srv C crash) ---

1. [LB] envoie la sonde HTTP à [Srv C].
2. [Srv C] répond "503 Service Unavailable" (ou Timeout).
3. [LB] (après 3 échecs) marque Srv C comme "DOWN".
4. [LB] arrête immédiatement d'envoyer du trafic utilisateur
   à Srv C.

Résultat : Le service reste 100% disponible
(sur Srv A et Srv B).

Le Load Balancer (LB) élimine le SPOF des serveurs, mais il devient lui-même le SPOF. On doit donc le rendre redondant, généralement avec une paire Active/Passive.

Architecture (VRRP / Keepalived)

On utilise un protocole FHRP (comme VRRP) pour gérer une IP Flottante (VIP) entre deux LBs.

                     [ Clients (Internet) ]
                            │
                            ▼
                     [ IP Flottante (VIP) ]
                    ↗ (Possède le VIP)   ↘ (Écoute)
                   ╱                     ╲
[ LB 1 (ACTIF) ]  <---- (Heartbeat VRRP) ---->  [ LB 2 (PASSIF) ]
(Priorité 100)                                (Priorité 90)
   │                                           
   └──────────► [ Pool de Serveurs ]

Failover

1. LB 1 (Actif) gère 100% du trafic. LB 2 (Passif) ne fait rien (en "standby").
2. LB 1 et LB 2 s'envoient des "heartbeats" (VRRP).
3. Panne : LB 1 (Actif) crash.
4. LB 2 (Passif) ne reçoit plus de heartbeats.
5. LB 2 (Passif) se déclare "Actif" (Maître VRRP), usurpe l'IP Flottante (VIP), et commence à traiter le trafic.

Outils : Keepalived (Linux), HSRP (Cisco), F5 (intégré).

Le mode Actif/Passif est simple et fiable, mais "gâche" des ressources (le LB 2 est inactif 99% du temps). Le mode Actif/Actif vise à utiliser tous les LBs simultanément.

www   A   60   80.1.2.3
www   A   60   80.1.2.4

Avoir un Load Balancer ne suffit pas si l'application elle-même n'est pas conçue pour la HA. L'état (State) est le problème.

[ LB (Non-Sticky) ]
   │      │
[ Srv A ] [ Srv B ]
   │      │
   └─[ BDD Externe (Redis/DB) ]
      (Stocke les sessions)

Keepalived est un service (daemon) Linux open-source qui fournit une solution de HA simple (Actif/Passif) en combinant deux fonctionnalités :

1. FHRP (Routage) : Il implémente le protocole VRRP (voir 2.3) pour gérer une IP Flottante (VIP) entre deux serveurs (un Maître, un Backup).
2. Health Checking : Il intègre un "Health Checker" qui peut surveiller l'état d'un service (ex: nginx, haproxy).

Exemple (Cluster Nginx)

On installe Nginx + Keepalived sur 2 serveurs (LB1, LB2).

# Fichier: /etc/keepalived/keepalived.conf

vrrp_script check_nginx {
    script "killall -0 nginx"  # (Vérifie si le process nginx tourne)
    interval 2
}

vrrp_instance VI_1 {
    state MASTER            # (Sur LB1) (state BACKUP sur LB2)
    interface eth0
    virtual_router_id 51    # (Doit être identique sur les deux)
    priority 101            # (Mettre 100 sur LB2)
    
    virtual_ipaddress {
        192.168.1.100/24    # (L'IP Flottante / VIP)
    }
    
    track_script {
        check_nginx
    }
}

Failover : Si le script check_nginx échoue sur LB1 (Maître), Keepalived baisse sa priorité, et LB2 (Backup) prend le VIP.

RAID (Redundant Array of Independent Disks) fournit la HA au niveau des disques durs (L0). Il protège contre la panne d'un (ou plusieurs) disques physiques.

SPOF : Le serveur (physique) lui-même (qui contient les disques RAID).

SAN (Storage Area Network)

Un SAN est un réseau dédié (séparé du LAN) conçu pour le stockage bloc (Block Storage).

Les serveurs (Initiators) se connectent à une baie de stockage (Target) via des protocoles (iSCSI (sur IP) ou Fibre Channel (FC)) pour voir les disques (LUNs) comme s'ils étaient locaux.

MPIO (Multi-Path I/O)

C'est la HA du SAN. On utilise deux switchs SAN (tissu A, tissu B) et deux contrôleurs sur la baie de stockage.

Le serveur (via MPIO) a plusieurs chemins (paths) pour atteindre le même disque (LUN).

[ Serveur ]
 (HBA 1) │    │ (HBA 2)
         ▼    ▼
      [ SW A ] [ SW B ] (Réseau SAN redondant)
         │    │
         ▼    ▼
[ Baie SAN (Contrôleur A | Contrôleur B) ]
[ (Disques RAID) ]

Si le Switch A (ou HBA 1) tombe, le trafic bascule instantanément sur le chemin B (MPIO).

SPOF : La baie SAN elle-même (ou le Data Center entier : incendie, inondation).

Solution : Répliquer (copier) les données vers une deuxième baie SAN (sur un site distant).

La réplication de BDD (ex: PostgreSQL, MySQL) est le mécanisme de copie des transactions d'un serveur Primaire (Maître) vers un (ou plusieurs) serveurs Secondaires (Esclaves/Standby).

Architecture Primaire/Secondaire (Master/Slave)

(Écritures : INSERT, UPDATE)
        │
        ▼
[ SERVEUR PRIMAIRE (Master) ]
 (ex: PostgreSQL)
        │
        │ (Envoie les WAL (Logs))
        ▼
[ SERVEUR SECONDAIRE (Standby) ]
 (Suit le Maître)

RPO (Recovery Point Objective)

La réplication (Synchrone vs Asynchrone) détermine le RPO (Objectif de Point de Reprise) : Quelle quantité de données suis-je prêt à perdre ?

• Asynchrone : (Défaut) Le Maître écrit, puis envoie le log. (Rapide, RPO > 0s (risque de perte)).
• Synchrone : Le Maître écrit, envoie le log, attend que l'Esclave confirme l'écriture, *puis* confirme au client. (Lent, RPO = 0s (zéro perte)).

La réplication gère la HA des données (RPO). Le Failover Automatique gère la HA du service (RTO - Recovery Time Objective : "Combien de temps pour redémarrer ?").

Le Problème (Split-Brain)

Si le Maître tombe, comment les Esclaves décident-ils (1) qu'il est mort, et (2) qui devient le nouveau Maître (Promotion) ?

Solution : Outil de Clustering (Témoin)

Des outils externes (Watchdog) gèrent l'élection et le failover, en utilisant un Quorum (voir 4.2) pour éviter le Split-Brain.

Le modèle Primaire/Secondaire (Maître/Esclave) est Actif/Passif (on n'écrit que sur le Maître).

Le Clustering Multi-Master (Actif/Actif) permet d'écrire sur tous les nœuds du cluster.

Galera / Percona XtraDB Cluster (MySQL)

C'est la solution A/A la plus connue pour MySQL/MariaDB.

Fonctionnement : Réplication Synchrone "Virtuelle".

1. Client écrit (INSERT) sur Nœud A.
2. Nœud A (avant de "commiter") envoie l'INSERT à Nœud B et Nœud C.
3. Nœud B et Nœud C (certifient et appliquent) et répondent "OK".
4. Nœud A reçoit "OK" de B et C, et "commit" (confirme) au client.

Avantages : HA (pas de failover, tous sont actifs), Scalabilité en lecture.

Inconvénients : Latence en écriture (l'écriture est aussi lente que le nœud le plus lent), Conflits (DEADLOCKs) si 2 nœuds écrivent la même ligne en même temps.