⚖️ Load Balancer (Équilibrage) – HA, L4/L7 & Algorithmes

Le jargon du Load Balancing :

Un LB de Couche 4 (Transport) opère au niveau TCP / UDP. Il est "rapide et stupide".

Fonctionnement (DNAT)

Il ne lit pas le contenu de la requête (ex: HTTP). Il regarde uniquement les en-têtes L3/L4 (IP Source, Port Source, IP Dest, Port Dest).

Il ne termine pas la connexion. Il se contente de faire du DNAT (Destination NAT) : il réécrit l'IP/Port de destination (le VIP) avec l'IP/Port d'un serveur réel (Membre) et "transmet" (forward) le paquet.

Client -> (Dest: VIP:80) -> [LB L4] -> (Dest: SRV1:80) -> [Serveur 1]

Avantages / Inconvénients

• (+) Très Haute Performance : Latence quasi-nulle (souvent géré en hardware/kernel).
• (+) Agnostique : Peut équilibrer n'importe quel protocole TCP/UDP (MySQL, SMTP, RDP...).
• (-) Non-Intelligent : Ne peut pas router basé sur l'URL (/api), les en-têtes, ou les cookies.
• (-) Problème SSL : Ne peut pas faire de SSL Offloading (car il ne lit pas le L7).

Exemples : AWS NLB, HAProxy (mode tcp), Nginx (stream module).

Un LB de Couche 7 (Application) opère au niveau Applicatif (ex: HTTP, HTTPS, gRPC). Il est "intelligent et plus lent".

Fonctionnement (Full Proxy)

C'est un proxy complet. Il termine la connexion TCP du client, lit la requête L7 (HTTP), prend une décision de routage, puis ouvre une nouvelle connexion TCP vers le serveur back-end choisi.

[Client] <--- (Connexion 1) ---> [LB L7] <--- (Connexion 2) ---> [Serveur 1]

Avantages / Inconvénients

• (+) Routage Intelligent : Peut prendre des décisions basées sur :
  • Path (Chemin) : /images/* -> Pool-Images, /api/* -> Pool-API.
  • Host (Hôte) : a.com -> Pool-A, b.com -> Pool-B.
  • Header/Cookie : User-Agent: Mobile -> Pool-Mobile.
• (+) Fonctions Avancées : Peut faire du SSL Offloading (voir 3.3) et du Caching.
• (-) Plus Lent (Overhead) : Terminer TCP et parser HTTP consomme plus de CPU que le L4.
• (-) Limité : Ne fonctionne que pour les protocoles qu'il comprend (HTTP, gRPC...).

Exemples : AWS ALB, Nginx (http module), HAProxy (mode http), F5.

C'est le mécanisme vital qui permet au LB d'assurer la Haute Disponibilité (HA). Le LB teste en permanence ses membres (serveurs) pour savoir s'ils sont "UP" (sains) ou "DOWN" (morts).

Problème : Les algorithmes (Round Robin, Least Conn) sont "stateless". Ils envoient les requêtes n'importe où. C'est parfait pour du contenu statique, mais problématique pour les applications "stateful" (ex: un panier e-commerce stocké dans la session PHP/Java du Srv A).

Req 1 (Login) -> [LB] -> Srv A (Crée session "panier")
Req 2 (Ajout) -> [LB] -> Srv B (Ne connaît pas la session)
-> Erreur !

Solution : Persistence (Stickiness). Forcer un client à toujours retourner sur le même serveur back-end.

SSL Offloading (ou Terminaison TLS) est une fonction du LB L7 où il gère 100% des opérations de chiffrement/déchiffrement.

Le Flux

Le trafic est chiffré (HTTPS) sur Internet (entre Client et LB), mais en clair (HTTP) sur le LAN interne (entre LB et Serveurs).

[CLIENT] <--- (Connexion 1 : HTTPS - Cryptée) ---> [REVERSE PROXY (Nginx/LB)]
                                                        │ (Port 443)
                                                        │ (Déchiffre)
                                                        │
         <--- (Connexion 2 : HTTP - Non cryptée) ---> [Serveur App 1]
                                                        │ (Port 80)
                                                        │
         <--- (Connexion 2 : HTTP - Non cryptée) ---> [Serveur App 2]
                                                          (Port 80)

Avantages

• Performance (Offloading) : Le chiffrement est lourd (CPU). Les serveurs d'application (PHP, Node) sont "déchargés" de cette tâche. Les LB matériels ont des puces (ASICs) dédiées à cela.
• Centralisation (Gestion) : Un seul endroit où gérer (installer, renouveler) les certificats SSL, au lieu de 20 serveurs.
• Visibilité (L7) : La seule façon pour un LB L7 de lire les URLs, Headers ou Cookies (pour le routage intelligent ou la persistance) est de déchiffrer le trafic d'abord.

Un Load Balancer Matériel (ou ADC - Application Delivery Controller) est un appareil physique dédié (une "boîte noire") conçu spécifiquement pour le load balancing à très haute performance.

Leaders du Marché

• F5 (BIG-IP) : Le leader historique, souvent considéré comme le standard de l'industrie (LTM - Local Traffic Manager).
• Citrix (NetScaler) : Un concurrent majeur, très puissant.
• (Autres : Kemp, A10 Networks...)

Avantages

• Performance Extrême : Utilise des puces spécialisées (ASICs, FPGAs) pour traiter le trafic (L4) et le SSL (Offloading) à la vitesse du matériel (wirespeed), sans impacter le CPU.
• Fiabilité : Matériel redondant (alimentations, ventilateurs).
• Fonctionnalités : Solution "tout-en-un" (LB L4/L7, WAF, Caching, SSL VPN...)

Inconvénients

• Coût : Extrêmement cher (modèle CAPEX - Achat de matériel).
• Rigidité : Propriétaire ("vendor lock-in"), lent à provisionner (il faut commander et installer une boîte).

Nginx (Open Source) est le Reverse Proxy L7 le plus populaire au monde. Il est excellent pour le load balancing HTTP/HTTPS, mais peut aussi gérer le L4 (stream module).

Configuration (Exemple L7 HTTP)

Configuration (nginx.conf) pour répartir la charge (Round Robin) d'un site web sur 2 serveurs back-end.

# 1. Définir le pool (la ferme) de serveurs back-end
upstream backend_servers {
    server 192.168.1.10:80;  # Serveur 1
    server 192.168.1.11:80;  # Serveur 2
    # server 192.168.1.12:80 weight=3; (Weighted)
    # ip_hash; (Pour la persistance IP)
}

server {
    listen 80;
    server_name www.ideolab.com;

    location / {
        # 2. Transférer le trafic au pool
        proxy_pass http://backend_servers;
        
        # 3. (Important) Passer les bons en-têtes
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

HAProxy (Open Source) est un logiciel dédié au Load Balancing. Il est réputé pour être extrêmement rapide (surtout en L4/TCP) et très stable.

Configuration (Exemple L7 HTTP)

Configuration (haproxy.cfg) similaire à Nginx.

# 1. Définir le "Frontend" (ce que le client voit)
frontend http_frontend
    bind *:80
    mode http
    default_backend web_servers

# 2. Définir le "Backend" (le pool de serveurs)
backend web_servers
    mode http
    balance roundrobin  (Algorithme)
    
    # 3. Ajouter les membres et les health checks
    server srv1 192.168.1.10:80 check
    server srv2 192.168.1.11:80 check

# 4. (Optionnel) Dashboard de statistiques
listen stats
    bind *:8080
    stats enable
    stats uri /haproxy?stats

Les LBs "Cloud" sont des services entièrement managés (SaaS/PaaS). Vous ne gérez pas de VM, vous ne configurez pas Nginx. Vous "commandez" un LB via une API ou une interface web.

Exemple : Écosystème AWS

Avantages : Scalabilité automatique (gérée par le Cloud), intégration (IAM, WAF, Certificats), pas de maintenance (HA gérée par le Cloud).

Inconvénients : Coût (OPEX), "vendor lock-in".

Le Load Balancer résout le problème de SPOF (Single Point of Failure) des serveurs back-end. Mais il devient lui-même le nouveau SPOF.

[ Clients (Internet) ]
         │
         ▼
[ LOAD BALANCER (VIP) ]  <--- (Si ce serveur crash,
   (IP Publique)              TOUT LE SITE EST DOWN !)
   │      │      │
   ├──────┼──────┤
   ▼      ▼      ▼
[ Srv 1] [ Srv 2] [ Srv 3]
(UP)     (UP)     (UP)

Problème : Un Load Balancer seul n'est pas en Haute Disponibilité (HA).

Solution : Il faut toujours déployer les Load Balancers par paire (Cluster), dans une configuration Active/Passive.

Pour rendre le LB redondant (HA), on utilise un cluster Active/Passive et une IP Flottante (Floating IP), gérée par un protocole comme VRRP.

Architecture HA (Active/Passive)

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

VRRP (Virtual Router Redundancy Protocol)

1. LB 1 (Actif) "possède" l'IP Flottante (VIP) car il a la priorité la plus élevée.
2. LB 1 et LB 2 s'envoient des "heartbeats" (paquets "je suis vivant") en permanence.
3. Scénario de panne : LB 1 (Actif) crash (panne de courant).
4. LB 2 (Passif) ne reçoit plus de heartbeats de LB 1.
5. LB 2 (Passif) se déclare "Actif", usurpe l'IP Flottante (VIP), et commence à traiter le trafic.

Résultat : Le basculement (failover) est automatique et (presque) instantané (quelques secondes).

Un WAF est un type spécifique de Reverse Proxy (Couche 7) axé sur la sécurité applicative.

Il est souvent intégré directement dans les Load Balancers L7 modernes (Nginx (ModSecurity), F5 (AWF), AWS (AWS WAF)).

Fonctionnement (Inspection L7)

Comme le LB L7 fait du SSL Offloading (déchiffre le trafic), il peut inspecter le contenu des requêtes HTTP (URLs, Headers, Body) à la recherche de signatures d'attaques (ex: OWASP Top 10).

Exemple de règle WAF

Client envoie :
GET /login.php?user=' OR '1'='1'

1. [LB (Nginx)] déchiffre le HTTPS.
2. [LB (WAF)] analyse le paramètre "user".
3. [LB (WAF)] détecte la signature d'une Injection SQL.
4. [LB (WAF)] bloque (Drop) la requête (répond 403 Forbidden).

(Le trafic n'atteint jamais le serveur applicatif vulnérable).

Les LBs L7 (comme Nginx ou Varnish) peuvent agir comme des caches de Reverse Proxy pour réduire la charge sur les serveurs back-end.

Cache Statique (Nginx)

Le LB peut être configuré pour servir lui-même les fichiers statiques (CSS, JS, Images) depuis son disque local, sans jamais déranger les serveurs d'application (PHP/Node).

Cache Dynamique (Varnish, Nginx)

Mise en cache de la réponse HTML complète d'une page (ex: la page d'accueil) pendant 60 secondes.

1. [User 1] demande "/"
2. [LB] -> [Srv App (PHP)]
3. [Srv App] (génère la page) -> [LB]
4. [LB] stocke le HTML (Cache, TTL 60s) -> [User 1]

5. [User 2] demande "/" (10 sec plus tard)
6. [LB] (Sert la page depuis son cache) -> [User 2]
   (Le serveur PHP n'est jamais contacté).

L4 vs L7

Algorithmes