Guide pas à pas : configurer un load balancer NGINX hautement disponible avec Keepalived et HAProxy

Un NGINX-Load-Balancer hautement disponible élimine le point de défaillance unique à la périphérie du réseau en faisant en sorte que deux Linux-nœuds fournissent une IP virtuelle (VIP) via VRRP et exécutent localement NGINX et HAProxy pour le TLS, le routage et les contrôles d’état. Dans ce guide pratique, je décris non seulement les configurations, mais aussi les conséquences en exploitation, les causes d’erreur typiques, les commandes de mesure et de vérification ainsi qu’une stratégie de repli pratique.

NGINX-Load-Balancer hautement disponible : Architektur und Verantwortungsaufteilung

En bref : Keepalived (VRRP) fournit une VIP à laquelle les clients s’adressent. Le nœud actif a lié la VIP localement et répond aux requêtes ARP. NGINX prend en charge la terminaison TLS, la politique d’en-têtes et les redirections ; HAProxy tourne localement et effectue des vérifications d’état précises et le routage vers les backends. Cette séparation permet des responsabilités claires : politique TLS et de sécurité dans NGINX, contrôle d’état et de performance dans HAProxy.

Prérequis, réseau et décisions de conception

Hypothèses essentielles : les deux load‑balancers sont dans la même domaine de couche 2 (VLAN), la VIP se trouve dans le même sous‑réseau, le trafic VRRP (protocole IP 112) doit pouvoir circuler entre les hôtes. Si les applications conservent l’état de session localement, prévoyez des sessions persistantes (sticky sessions) ou un magasin de sessions centralisé (par ex. Redis) — sinon les basculements entraînent la perte des informations de session.

Paramètres d’exemple

• LB1: 10.10.10.11/24, LB2: 10.10.10.12/24, VIP: 10.10.10.10/24
• Interface: eth0, Backends: 10.10.20.21:8080, 10.10.20.22:8080
• DNS : un enregistrement A pointant vers la VIP ; le TTL est une question de secondes, le basculement de la VIP est transparent pour les clients

Installation : paquets, services, ordre

Installez NGINX, HAProxy et Keepalived sur les deux nœuds. Activez et démarrez les services après les vérifications de configuration.

sudo apt-get update
sudo apt-get install -y nginx haproxy keepalived curl iproute2 iputils-arping

sudo systemctl enable --now nginx
sudo systemctl enable --now haproxy
sudo systemctl enable --now keepalived

Tuning du noyau et d’ARP : pourquoi c’est important

Si Linux répond incorrectement aux requêtes ARP, cela entraîne du blackholing de trafic ou un split‑brain. Les paramètres sysctl suivants réduisent les réponses ARP indésirables ; appliquez‑les sur les deux nœuds.

sudo tee /etc/sysctl.d/99-lb-ha.conf >/dev/null <<'EOF'
net.ipv4.conf.all.arp_ignore = 1
net.ipv4.conf.default.arp_ignore = 1
net.ipv4.conf.all.arp_announce = 2
net.ipv4.conf.default.arp_announce = 2
EOF

sudo sysctl --system

Explication : arp_ignore contrôle si le système répond aux requêtes ARP pour des IP non configurées localement ; arp_announce influence quelle IP source est utilisée dans les requêtes ARP. Des réglages incorrects permettent au nœud de secours de répondre aux ARP pour la VIP et provoquent un split‑brain.

HAProxy : couche backend locale, vérifications d’état et métriques

HAProxy fournit des vérifications d’état robustes (HTTP, TCP, SSL), des paramètres de pondération (weight) et de rise/fall. Utilisez une liaison locale (127.0.0.1) pour que NGINX puisse transférer en interne. Les statistiques peuvent être exploitées pour le monitoring ou exportées via un exporteur Prometheus.

# /etc/haproxy/haproxy.cfg
global
  log /dev/log local0
  tune.maxaccept 1000
  maxconn 50000
  daemon

defaults
  mode http
  option httplog
  timeout connect 5s
  timeout client 60s
  timeout server 60s

frontend fe_local
  bind 127.0.0.1:9000
  default_backend be_app

backend be_app
  balance roundrobin
  option httpchk GET /healthz
  http-check expect status 200
  default-server inter 2s fall 3 rise 2
  server app1 10.10.20.21:8080 check
  server app2 10.10.20.22:8080 check

listen stats
  bind 127.0.0.1:8404
  stats enable
  stats uri /stats

Vérifiez HAProxy avant le redémarrage :

sudo haproxy -c -f /etc/haproxy/haproxy.cfg
sudo systemctl reload haproxy

NGINX : terminaison TLS, chemins de proxy et timeouts

NGINX gère la terminaison TLS. Automatisez les certificats (p. ex. certbot/ACME) ou utilisez votre PKI interne. Portez attention à proxy_read_timeout et aux réglages de buffer, afin que des réponses longues du backend ne bloquent pas la connexion.

# /etc/nginx/sites-available/lb.conf
server {
  listen 80;
  server_name _;
  return 301 https://$host$request_uri;
}

server {
  listen 443 ssl http2;
  server_name _;
  ssl_certificate     /etc/ssl/certs/lb.pem;
  ssl_certificate_key /etc/ssl/private/lb.key;
  client_max_body_size 50m;
  proxy_read_timeout 120s;
  location / {
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_pass http://127.0.0.1:9000;
  }
}

Keepalived : configuration VRRP, script de suivi et temporisations

Keepalived détermine quel nœud détient la VIP. Les scripts de suivi réduisent la priorité en cas d’erreur de service, afin qu’un nœud de secours sain puisse prendre le relais. Les valeurs advert_int et priority contrôlent le temps de basculement et l’ordre de préférence.

Script de suivi avec codes de sortie

sudo tee /usr/local/sbin/chk_proxy.sh >/dev/null <<'EOF'
#!/usr/bin/env bash
set -euo pipefail

# Vérifie les services et l'endpoint de santé local d'HAProxy
systemctl is-active --quiet nginx || exit 1
systemctl is-active --quiet haproxy || exit 1
curl -fsS --max-time 1 http://127.0.0.1:9000/healthz >/dev/null || exit 1
exit 0
EOF
sudo chmod 0755 /usr/local/sbin/chk_proxy.sh

Configuration Keepalived (Master/Backup)

# /etc/keepalived/keepalived.conf (exemple MASTER)
vrrp_script chk_proxy {
  script "/usr/local/sbin/chk_proxy.sh"
  interval 2
  timeout 2
  fall 2
  rise 2
  weight -30
}

vrrp_instance VI_10 {
  state MASTER
  interface eth0
  virtual_router_id 10
  priority 110
  advert_int 1
  authentication { auth_type PASS; auth_pass 7f3c9d2a }
  virtual_ipaddress { 10.10.10.10/24 }
  track_script { chk_proxy }
}

# Le Backup a priority 100 et state BACKUP

Remarque : l’authentification dans Keepalived (auth_pass) est un mécanisme simple ; dans des réseaux non sécurisés, vous devriez utiliser une segmentation réseau supplémentaire, car VRRP lui‑même n’offre pas de cryptographie forte.

Sources d’erreur : ARP, fonctions du commutateur, pare‑feux

Causes fréquentes de comportements inattendus :

• Des fonctions du commutateur comme Dynamic ARP Inspection (DAI) bloquent les Gratuitous ARP après un basculement — dans de tels réseaux, une configuration du commutateur est nécessaire.
• Le pare‑feu de l’hôte ou les groupes de sécurité cloud bloquent le protocole IP 112 (VRRP) — vérifiez cela avec tcpdump.
• Conntrack (Stateful NAT/Firewall) : lors d’une traduction NAT, un basculement peut interrompre des connexions existantes parce que la table NAT manque sur le nœud prenant le relais.

Diagnostic avec tcpdump, arping et logs

Contrôles utiles pour l’analyse :

# VRRP traffic beobachten (Protocol 112)
sudo tcpdump -n -i eth0 proto 112

# ARP prüfen
sudo tcpdump -n -i eth0 arp

# GARP senden (nach Failover)
sudo arping -U -I eth0 -c 5 10.10.10.10

# Keepalived logs
sudo journalctl -u keepalived -f

Si tcpdump ne montre pas de paquets VRRP, c’est souvent un pare-feu ou un switch interposé qui en est la cause. Si le GARP envoyé par le Master n’atteint pas le réseau, des clients conservent une ancienne association MAC dans leurs tables ARP et doivent réapprendre.

Effets de Conntrack et NAT lors d’un basculement

Dans des architectures avec NAT ou pare-feux stateful, la table Conntrack est spécifique à chaque hôte. Après un basculement du VIP, les entrées Conntrack établies font défaut sur le nœud de remplacement, ce qui provoque des sessions interrompues. Mesures possibles :

• Faire fonctionner Keepalived avec synchronisation Conntrack (p. ex. conntrackd) — augmente la complexité.
• Tolérer le renouvellement des connexions : accepter de courtes reconnexions, laisser les clients se reconnecter.
• Envisager une architecture actif/actif si la continuité des sessions est critique.

Aspects de sécurité et gestion des certificats

Les certificats TLS doivent être identiques sur les deux LBs. Automatisez les déploiements avec Certbot (ACME) ou votre PKI interne et contrôlez les clés privées via les permissions des fichiers. Conservez les certificats versionnés dans un dépôt d’artéfacts sécurisé ou dans un magasin de secrets.

# Beispiel Certbot (Let's Encrypt) - nicht für private PKI
sudo apt-get install -y certbot
sudo certbot certonly --standalone -d lb.example.com
# Verteilen Sie das resultierende PEM sicher auf beide Nodes (scp/Ansible)

Processus de déploiement et de patch — runbook concret

Une procédure typique et testée pour le patching ou la mise à jour de configuration minimise les risques :

1. Plan : communiquer la fenêtre de maintenance, réduire temporairement les alertes de monitoring.
2. Basculer le trafic sur le backup : soit arrêter Keepalived sur le Master, soit réduire sa Priority.
3. Validation : vérifier sur le backup que le VIP a été pris en charge et que la latence/les erreurs sont normales.
4. Patch du Master, tests (vérifier localement NGINX/HAProxy), remettre dans le pool.
5. Patch du deuxième nœud.
6. Post‑checks : test de basculement, contrôles de santé, analyse des logs.

# Beispiel: Traffic auf Backup bringen
# Auf Master:
sudo systemctl stop keepalived
# Auf Backup prüfen:
ip -br addr show dev eth0
sudo curl -I --resolve lb.example.com:443:10.10.10.10 https://lb.example.com/
# Nach Patch:
sudo systemctl start keepalived

Monitoring, métriques et alertes

Métriques importantes à surveiller :

• Transitions VRRP de Keepalived (des basculements fréquents indiquent une instabilité)
• Moment de la liaison du VIP et événements GARP
• Taux 4xx/5xx NGINX
• État des backends HAProxy, temps de réponse et mise en file
• Métriques système : descripteurs de fichiers, netstat pour sockets ouverts, loadavg

Exportez les stats HAProxy via un exporter pour Prometheus ou utilisez le stats-endpoint interne pour des règles d’alerte.

Alternatives de conception avancées

Si vous avez besoin d’une plus grande scalabilité ou d’une disponibilité globale, examinez les options suivantes :

• Cloud public : un Load Balancer managé évite les problèmes ARP/VRRP.
• Anycast/BGP : pour une distribution globale et une latence réduite, nécessite une expertise en routage réseau.
• Actif/actif : les deux LBs portent du trafic ; nécessite synchronisation des sessions ou applications sans état.

Liste de contrôle avant la mise en production

• VRRP (IP 112) autorisé entre les LBs et dans le réseau via le pare‑feu/switch ?
• Les paramètres sysctl‑ARP sont-ils définis et chargés sur les deux nœuds ?
• Le script de Track de Keepalived fonctionne‑t‑il et les codes de sortie sont‑ils valides ?
• Les health checks HAProxy renvoient‑ils les réponses attendues (200/OK) ?
• Les certificats TLS sont‑ils installés et synchronisés sur les deux nœuds ?
• Les fonctionnalités du switch (DAI, Port Security) ont‑elles été vérifiées et, le cas échéant, adaptées ?
• Le monitoring et l’alerte pour les transitions VRRP et la santé des backends sont‑ils configurés ?
• Plan de rollback testé (ip addr add manuel, démarrage/arrêt de Keepalived) ?

Pièges typiques et mesures correctives rapides

Split Brain : vérifiez les paquets VRRP, les tokens d’authentification, le virtual_router_id et les priorités. Si les switches ont DAI activé, configurez des mappages DHCP/ARP appropriés ou mettez en liste blanche les MAC des LB.

Temps de basculement lents : advert_interval trop élevé, mise en cache ARP côté clients/switches ou GARP supprimés. Réduisez advert_int et testez le comportement d’envoi GARP, mais gardez à l’esprit que des intervalles très courts génèrent davantage de trafic VRRP.

Conclusion et pertinence opérationnelle

Un Load Balancer NGINX hautement disponible avec Keepalived et HAProxy est une solution pragmatique pour réduire les risques d’indisponibilité en bord de réseau. Il ne suffit pas d’avoir des fichiers de configuration corrects : les paramètres réseau et des switches, le comportement ARP, des health checks robustes et un processus de déploiement testé sont tout aussi décisifs. Investissez du temps dans le monitoring, des runbooks documentés et des tests de basculement réguliers — cela garantit une maturité opérationnelle prévisible.

Commandes de vérification complémentaires (référence rapide)

# Qui a la VIP ?
ip -br addr show dev eth0 | grep 10.10.10.10 || true

# Observer le trafic VRRP en direct
sudo tcpdump -n -i eth0 proto 112

# Vérifier si le script de Track de Keepalived tourne et renvoie un code de sortie
/usr/local/sbin/chk_proxy.sh && echo OK || echo FAIL

# Envoyer un GARP (Master)
sudo arping -U -I eth0 -c 5 10.10.10.10

# Statistiques HAProxy (local)
curl -sS http://127.0.0.1:8404/stats

Sécurité opérationnelle : gestion des configurations, tests et récupération rapide

Après la mise en service technique, la gestion des changements détermine la stabilité à long terme. Placez toutes les configurations Keepalived, NGINX et HAProxy dans un dépôt Git, versionnez les templates et produisez des artefacts idempotents depuis des pipelines CI automatisés. Ainsi, les rollbacks par commit sont traçables et les dérives de configuration évitables.

Compléments pratiques :

• Canary‑Rollout : déployez les modifications de configuration d’abord sur le nœud de secours, vérifiez les health checks et les logs, puis sur le master.
• Récupération rapide : des étapes documentées pour définir manuellement la VIP, un accès SSH d’urgence et la restauration des configurations depuis Git minimisent le temps d’indisponibilité.
• Détection de panne avancée : utilisez BFD (Bidirectional Forwarding Detection) en complément de VRRP pour une détection plus rapide des coupures de lien, surtout lorsque les exigences de latence sont critiques.
• Segmentation réseau : isolez la signalisation VRRP sur un HA‑VLAN/VRF dédié pour réduire la surface d’attaque — VRRP n’offre pas de chiffrement fort.
• Intégration au monitoring : poussez les états VRRP, les config‑hashes et les événements de changement de configuration vers votre système central d’alerte/ticketing afin que les modifications soient immédiatement visibles.

Ces briques opérationnelles réduisent les erreurs humaines, accélèrent la restauration et rendent l’exploitation des LB reproductible et auditable — essentiel pour des solutions d’entreprise orientées processus avec des exigences élevées de disponibilité.

Pour ce sujet, Haproxy High Availability et Load Balancing Layer 4 et Layer 7 sont également importants. L’article situe ces aspects de manière compréhensible et montre ce qui compte au quotidien.