HA des frontaux web.
La couche la plus simple à rendre hautement disponible : le trafic HTTP se répartit sur plusieurs serveurs identiques, et la perte de l'un d'eux passe inaperçue. À condition de traiter correctement l'état et la bascule.
Le principe : répartir et surveiller
On place un répartiteur de charge (load balancer) devant plusieurs serveurs web servant la même application. Le load balancer distribue les requêtes et vérifie en continu la santé de chaque frontal via un health check. Un serveur qui échoue au contrôle est automatiquement sorti de la rotation ; les requêtes vont vers les serveurs sains, sans interruption visible.
Attention au load balancer lui-même : mis seul, il devient le point de panne unique. On le double donc (deux instances) avec une IP virtuelle (VIP) qui bascule de l'un à l'autre via keepalived/VRRP.
Répartition + bascule de la VIP
Deux load balancers en actif/passif partagent une IP virtuelle. Si l'actif tombe, le passif prend la VIP en quelques secondes et continue de router vers les frontaux sains.
Les mécanismes en détail
Load balancer (HAProxy, nginx)
Reçoit tout le trafic et le distribue selon un algorithme (round-robin, least-connections, hash d'IP). Termine le TLS, applique le rate-limiting et route selon l'URL si besoin. HAProxy pour du L4/L7 pur et performant, nginx quand on veut aussi servir du statique et du reverse-proxy applicatif.
Health checks
Le load balancer interroge régulièrement une URL de santé de chaque frontal (ex. /health). Il faut vérifier la vraie santé applicative (accès DB, dépendances), pas seulement que le port répond — sinon on route vers un serveur qui renvoie des erreurs.
VIP + keepalived (VRRP)
Une IP virtuelle « flotte » entre les deux load balancers. keepalived, via le protocole VRRP, fait basculer la VIP sur le nœud passif si l'actif ne répond plus. La bascule prend quelques secondes, transparente pour les visiteurs.
Frontaux stateless
Pour qu'un serveur soit interchangeable, il ne doit rien stocker localement d'irremplaçable : pas de session en fichier local, pas d'upload sur le disque du frontal. Tout l'état va dans un store partagé (Redis, base de données, stockage objet). C'est la condition du scaling horizontal.
Sessions : partagées vs sticky
Deux approches. Sticky sessions : le load balancer renvoie toujours un visiteur vers le même frontal (simple mais fragile — la panne du frontal déconnecte ses utilisateurs). Sessions partagées : toutes les sessions vivent dans Redis, n'importe quel frontal peut servir n'importe quel visiteur. On préfère la seconde pour une vraie HA.
Déploiements rolling
Mettre à jour l'application sans coupure : on sort un frontal de la rotation, on le met à jour, on le teste, on le remet, puis on passe au suivant. À aucun moment le service n'est indisponible.
Le piège classique : on redonde les frontaux web… mais ils pointent tous vers une base de données unique. Le SPOF s'est juste déplacé. La couche web est rarement le vrai problème — la base de données l'est presque toujours →
Répartir la charge de votre site
On dimensionne le nombre de frontaux et on met en place le load balancing redondé adapté à votre trafic.
Demander un devisExplorer le pôle infogérance & haute disponibilité
Infogérance de serveur
Supervision, mises à jour, sauvegardes testées, durcissement et réponse à incident.
Exploitation & supervisionReprise d’infogérance
Vous changez d’infogéreur ? On reprend l’existant, même sans documentation ni accès complets.
Depuis un autre prestataireHaute disponibilité
SPOF, redondance, failover, RTO/RPO : supprimer les points de panne uniques.
Concepts & architectureHA de la base de données
Réplication, failover automatique, cluster Galera, read/write split.
Réplication & basculeHA du stockage
Stockage partagé/répliqué, objet S3, sauvegardes 3-2-1, redondance géo.
Fichiers & données répliqués