Répartition de charge : HAProxy, DNS round-robin et contrôles de santé

La répartition de charge (load balancing) distribue les requêtes des clients entre plusieurs serveurs qui rendent le même service. Un répartiteur de charge (load balancer) choisit, pour chaque requête, un serveur en bonne santé : il augmente la capacité du service et retire automatiquement les serveurs en panne. Ce chapitre compare le DNS round-robin et les répartiteurs, présente les algorithmes, les contrôles de santé et la gestion des sessions, puis configure HAProxy pas à pas, jusqu'à la maintenance sans coupure.

Répartir la charge : deux objectifs

Un service répartit sa charge pour deux raisons, qu'il faut savoir distinguer à l'oral :

• la capacité : quand un serveur ne suffit plus, on peut en acheter un plus gros (montée en charge verticale, limitée et coûteuse) ou en ajouter un second (montée en charge horizontale, presque sans limite). La répartition de charge rend la seconde possible ;
• la disponibilité : le répartiteur vérifie en permanence l'état de chaque serveur et cesse d'envoyer des requêtes à celui qui ne répond plus. Le service survit à la panne d'un serveur, et on peut en arrêter un pour le mettre à jour sans couper personne.

Il existe trois grandes familles de solutions : la répartition par le DNS, le répartiteur réseau (niveau 4, qui voit des connexions TCP ou UDP) et le répartiteur applicatif (niveau 7, qui comprend le protocole, le plus souvent HTTP).

Le DNS round-robin

La solution la plus simple consiste à publier plusieurs enregistrements A pour le même nom. Dans une zone BIND :

intranet   300   IN   A   10.10.20.31
intranet   300   IN   A   10.10.20.32

Le serveur DNS renvoie les deux adresses, en changeant leur ordre à chaque réponse (c'est le round-robin), et la plupart des clients utilisent la première. La charge se répartit, sans aucun équipement supplémentaire. Le serveur DNS de Windows Server fait de même ; attention, il applique aussi par défaut le tri par masque de réseau (netmask ordering), qui place en tête l'adresse la plus proche du réseau du client et peut défaire la rotation.

Mais le DNS ne sait rien de l'état des serveurs :

Le DNS round-robin n'est donc pas une solution de haute disponibilité en soi. Il sert en complément : par exemple pour répartir les clients entre deux adresses virtuelles de répartiteurs, chacune elle-même protégée par VRRP.

Répartiteur de niveau 4 ou de niveau 7

Un répartiteur de niveau 7 est un proxy inverse (reverse proxy) : le client parle au répartiteur, et le répartiteur parle au serveur. Deux conséquences pratiques :

• le certificat TLS est installé sur le répartiteur, qui déchiffre (on parle de terminaison TLS) ; il transmet ensuite en HTTP vers les serveurs, dans un VLAN serveurs protégé, ou rechiffre si la politique de sécurité l'exige. En niveau 4, le flux chiffré passe tel quel (TLS passthrough) et chaque serveur porte son certificat ;
• l'adresse du client : les serveurs voient arriver toutes les requêtes depuis l'adresse du répartiteur. Pour garder l'adresse réelle dans les journaux, le répartiteur l'ajoute dans l'en-tête X-Forwarded-For, et le serveur web est configuré pour la lire.

Les algorithmes de répartition

Les contrôles de santé

Un contrôle de santé (health check) est une vérification que le répartiteur effectue régulièrement sur chaque serveur pour décider s'il peut recevoir des requêtes. C'est lui qui transforme une simple répartition en solution de haute disponibilité.

Trois paramètres règlent la réactivité, avec leurs valeurs dans HAProxy :

• inter : l'intervalle entre deux contrôles (2 secondes par défaut) ;
• fall : le nombre d'échecs consécutifs avant de retirer le serveur (3 par défaut) ;
• rise : le nombre de succès consécutifs avant de le réintégrer (2 par défaut).

Avec inter 2s fall 3 rise 2, un serveur qui tombe est retiré au bout d'environ 6 secondes (3 contrôles ratés à 2 secondes d'intervalle), et réintégré 4 secondes après son retour. Pendant ces 6 secondes, une partie des requêtes échoue encore : HAProxy peut les renvoyer vers un autre serveur avec option redispatch et retries.

La page de santé. Sur un serveur Nginx, une page de santé simple tient en une ligne dans le bloc server :

location = /sante {
    access_log off;
    return 200 "OK\n";
}

Une page de santé profonde, en PHP, vérifie que l'application joint sa base de données :

<?php
// /var/www/intranet/sante.php : 200 si la base répond, 503 sinon
require '/etc/intranet/sante-config.php'; // définit $dsn, $utilisateur, $motDePasse (hors du site)
try {
    $pdo = new PDO($dsn, $utilisateur, $motDePasse, [PDO::ATTR_TIMEOUT => 2]);
    $pdo->query('SELECT 1');
    http_response_code(200);
    echo "OK\n";
} catch (Throwable $e) {
    http_response_code(503);
    echo "KO\n";
}

Le compte utilisé n'a besoin d'aucun droit sur les tables. Et la page ne doit rien afficher d'autre que OK ou KO : un message d'erreur détaillé donnerait des informations à un attaquant.

Les sessions : persistance ou serveurs sans état

Une application PHP range par défaut les sessions des utilisateurs dans des fichiers, sur le serveur qui les a créées. Si la première requête arrive sur WEB1 (connexion de l'utilisateur) et la suivante sur WEB2, WEB2 ne connaît pas la session : l'utilisateur est renvoyé à la page de connexion. Deux familles de solutions :

1. La persistance (sticky sessions) : le répartiteur renvoie toujours un même utilisateur vers le même serveur. En niveau 7, il insère un cookie qui désigne le serveur ; en niveau 4, il utilise le hachage de l'adresse source. C'est simple, mais la répartition devient inégale (un gros client derrière une seule adresse NAT pèse sur un seul serveur), et les sessions du serveur qui tombe sont perdues : ses utilisateurs doivent se reconnecter.
2. Des serveurs sans état (stateless) : les sessions sont rangées dans un stockage partagé (une base Redis, la base de données de l'application), et les fichiers déposés par les utilisateurs dans un stockage commun. N'importe quel serveur peut alors traiter n'importe quelle requête, et la panne d'un serveur ne déconnecte personne. C'est la bonne architecture, mais elle demande de configurer l'application.

En pratique, on combine souvent les deux : un cookie de persistance pour l'efficacité des caches, et des sessions partagées pour survivre aux pannes.

HAProxy pas à pas

HAProxy est le répartiteur libre de référence, en niveau 4 comme en niveau 7. Debian 13 fournit sa branche 3.0, maintenue à long terme. Sur LB1 et LB2 :

apt install haproxy socat

Le fichier /etc/haproxy/haproxy.cfg de Ravelle Conseil, avec la VIP 10.10.20.30 partagée par keepalived (chapitre 5) :

global
    log /dev/log local0
    user haproxy
    group haproxy
    daemon
    stats socket /run/haproxy/admin.sock mode 660 level admin

defaults
    mode http
    log global
    option httplog
    option forwardfor
    option redispatch
    retries 2
    timeout connect 5s
    timeout client 30s
    timeout server 30s

frontend intranet
    bind 10.10.20.30:80
    bind 10.10.20.30:443 ssl crt /etc/haproxy/certs/intranet.pem
    http-request redirect scheme https unless { ssl_fc }
    default_backend web_intranet

backend web_intranet
    balance roundrobin
    option httpchk GET /sante
    http-check expect status 200
    cookie SRV insert indirect nocache
    default-server inter 2s fall 3 rise 2
    server web1 10.10.20.31:80 check cookie w1
    server web2 10.10.20.32:80 check cookie w2

listen stats
    bind :8404
    stats enable
    stats uri /stats
    stats refresh 10s
    stats auth admin:Remplace-Moi-Par-Une-Longue-Phrase

Le fichier intranet.pem contient le certificat suivi de sa clé privée (lisible par root seul). Le mot-clé check est indispensable sur chaque ligne server : sans lui, HAProxy n'effectue aucun contrôle et continue d'envoyer des requêtes à un serveur mort. La page de statistiques ne doit être accessible que depuis le VLAN d'administration : filtre le port 8404 sur le pare-feu.

Vérifier, recharger, contrôler.

haproxy -c -f /etc/haproxy/haproxy.cfg       # « Configuration file is valid »
systemctl reload haproxy                      # rechargement sans couper les connexions
echo "show servers state" | socat stdio /run/haproxy/admin.sock

Côté serveurs web, Nginx doit lire l'adresse réelle du client dans l'en-tête ajouté par les répartiteurs, et seulement quand la requête vient d'eux :

set_real_ip_from 10.10.20.28;
set_real_ip_from 10.10.20.29;
real_ip_header X-Forwarded-For;

Prouver que ça marche. Dépose sur chaque serveur une page qui.html qui affiche son nom, puis, depuis un poste :

for i in 1 2 3 4; do curl -s https://intranet.ravelle.lan/qui.html; done
# web1 / web2 / web1 / web2 : curl n'envoie pas le cookie, le tourniquet s'applique

Arrête Nginx sur WEB2 : la page de statistiques le passe en rouge (DOWN) au bout de quelques secondes, et la boucle ne renvoie plus que web1, sans aucune erreur. Redémarre-le : il repasse en vert (UP) après deux contrôles réussis.

La maintenance sans coupure

Le répartiteur permet de mettre à jour les serveurs un par un, sans que les utilisateurs le voient. La socket d'administration accepte trois états :

• drain : le serveur ne reçoit plus de nouveaux utilisateurs, mais termine les sessions en cours (y compris celles liées par le cookie) ;
• maint : le serveur est retiré complètement ;
• ready : il reprend du service.

echo "set server web_intranet/web1 state drain" | socat stdio /run/haproxy/admin.sock
# attendre que les sessions en cours se terminent (page de statistiques)
echo "set server web_intranet/web1 state maint" | socat stdio /run/haproxy/admin.sock
# mettre à jour WEB1, redémarrer, tester directement http://10.10.20.31/sante
echo "set server web_intranet/web1 state ready" | socat stdio /run/haproxy/admin.sock

On recommence ensuite pour WEB2. Cette mise à jour progressive (rolling update) suppose que le serveur restant tienne seul la charge pendant l'opération : c'est la règle N+1 du chapitre 1.

Le répartiteur ne doit pas devenir le SPOF

Un répartiteur unique est un SPOF placé devant des serveurs redondants. On le double :

• en actif-passif : deux répartiteurs identiques, une VIP partagée par keepalived. C'est l'architecture de Ravelle Conseil ;
• en actif-actif : deux VIP, chacune active sur un répartiteur et en secours sur l'autre, et un DNS round-robin qui distribue les deux adresses. Les deux répartiteurs travaillent, et chacun peut tout reprendre.

Les deux répartiteurs doivent avoir la même configuration. Modifie-la sur LB1, vérifie-la avec haproxy -c, puis recopie-la sur LB2 (avec scp, un script ou un outil de gestion de configuration comme Ansible), vérifie et recharge. Un secours dont la configuration a trois mois de retard trahit le jour de la bascule.

Exercices

frontend site
    bind 10.10.20.28:80
    default_backend web

backend web
    balance roundrobin
    option httpchk GET /Sante
    server web1 10.10.20.31:80 check
    server web2 10.10.20.32:80