HAProxy se distingue par sa robustesse dans les environnements à forte charge et sa capacité à opérer à la fois au niveau 4 (TCP) et au niveau 7 (HTTP), ce qui permet une granularité fine dans le routage des requêtes. Contrairement à certains reverse proxies, il intègre nativement des mécanimses de persistance de session, de détection proactive de défaillance des nœuds et une large palette d’algorithmes d’équilibrage — allant du simple round-robin à des stratégies basées sur l’empreinte IP, l’URL ou les paramètres de requête.

Il prend en charge la répartition de trafic vers des services non-HTTP tels que MySQL, avec vérification continue de la santé des instances backend via des checks HTTP ou TCP personnalisables. Sa conception monoprocessus optimisée offre souvent de meilleures performances latence/connexion comparé à des solutions multi-processus dans des scénarios de haute fréquence de connexions courtes.

Compilation manuelle depuis les sources

Pour une installation personnalisée sur CentOS, on peut compiler HAProxy à partir du code source :

tar xzf haproxy-2.8.5.tar.gz
cd haproxy-2.8.5
make TARGET=linux-glibc USE_OPENSSL=1 USE_ZLIB=1 USE_PCRE2=1
sudo make install

Exemple de configuration fonctionnelle

Ce fichier /etc/haproxy/haproxy.cfg définit trois frontaux distincts : un équilibreur HTTP avec persistance par cookie, un relais transparent, et un endpoint de santé dédié.

global
    log /dev/log local0
    maxconn 65536
    chroot /var/lib/haproxy
    user haproxy
    group haproxy
    daemon
    tune.ssl.default-dh-param 2048

defaults
    mode http
    timeout connect 5s
    timeout client 30s
    timeout server 30s
    option http-keep-alive
    option forwardfor
    option httplog

frontend http_frontend
    bind *:8000
    log global
    option httpchk GET /health
    http-check expect status 200
    default_backend app_servers

backend app_servers
    balance cookie
    cookie SERVERID insert indirect nocache
    server node_a 127.0.0.1:8080 check cookie a inter 2000 rise 2 fall 3 weight 40
    server node_b 192.168.1.105:8080 check cookie b inter 2000 rise 2 fall 3 weight 60

frontend transparent_proxy
    bind *:3128 transparent
    mode tcp
    default_backend tcp_backends

backend tcp_backends
    mode tcp
    balance source
    server db_primary 10.10.20.30:3306 check
    server db_secondary 10.10.20.31:3306 check backup

listen health_check
    bind *:3130
    mode http
    monitor-uri /status
    monitor fail if { nbsrv(app_servers) lt 1 }

Lancement et validation

Après avoir placé la configuration dans /etc/haproxy/haproxy.cfg, lancez le service avec :

sudo /usr/local/sbin/haproxy -f /etc/haproxy/haproxy.cfg -D -p /var/run/haproxy.pid

Pour tester la persistance, envoyez plusieurs requêtes successives vers http://localhost:8000 tout en inspectant les en-têtes Set-Cookie retournés — chaque session devrait être systématiquement dirigée vers le même serveur backend idenitfié par le cookie SERVERID.

Méthodes de persistance de session

HAProxy propose trois approches principales :

• Persistance par adresse IP : utilise balance source, idéal pour les clients sans cookies activés.
• Insertion de cookie côté proxy : avec cookie <name> insert indirect nocache, HAProxy injecte un identifiant stable dans la réponse HTTP.
• Apprentissage dynamique de session : via appsession, utile quand l’application génère déjà un jeton de session (ex. PHPSESSID), permettant à HAProxy de suivre automatiquement la correspondance entre jeton et nœud.

Chaque méthode s’adapte à différents contextes opérationnels — par exemple, appsession est privilégié dans les architectures PHP où la gestion de session est centralisée, tandis que cookie insert convient mieux aux applications stateless ou lorsqu’on ne contrôle pas le backend.