Configurer un load balancer sur VPS : le guide complet

Configurer un load balancer VPS est une etape incontournable des que vous devez repartir du trafic sur plusieurs instances, encaisser des pics de charge ou garantir une haute disponibilite. Ce tutoriel 2026 detaille l'architecture, l'installation de HAProxy et Nginx, la verification de sante des backends et les bonnes pratiques de securite pour un environnement de production stable et performant.

Pourquoi mettre en place un load balancer VPS

Un load balancer VPS agit comme point d'entree unique devant plusieurs serveurs applicatifs. Il distribue les requetes entrantes selon un algorithme (round-robin, least-connections, hash IP) et retire automatiquement du pool un backend defaillant. L'objectif est double : lisser la charge et supprimer le point unique de defaillance au niveau applicatif.

Les cas d'usage typiques

• Scalabilite horizontale : ajouter des VPS applicatifs plutot que de sur-dimensionner une seule machine.
• Haute disponibilite : maintenir le service meme si un backend tombe.
• Maintenance sans coupure : sortir un serveur du pool pour le mettre a jour, puis le reintegrer.
• Terminaison TLS centralisee : gerer les certificats a un seul endroit.

Repartition L4 vs L7

Deux approches coexistent. Le load balancing L4 (transport) route sur la base IP/port sans inspecter le contenu, ce qui est rapide et economique en ressources. Le load balancing L7 (applicatif) analyse les en-tetes HTTP et permet un routage par domaine, par chemin ou par cookie de session. La plupart des architectures web modernes utilisent le L7 pour sa souplesse.

Critere	Load balancing L4	Load balancing L7
Niveau	TCP/UDP	HTTP/HTTPS
Routage par URL	Non	Oui
Terminaison TLS	Limitee	Complete
Charge CPU	Faible	Moderee
Sticky sessions	IP hash	Cookie / header

Sur l'infrastructure OmegaCloud, l'anti-DDoS volumetrique est deja gere au niveau kernel cote reseau. Votre load balancer n'a donc pas a absorber les attaques volumetriques : il se concentre uniquement sur la distribution du trafic legitime.

Architecture recommandee pour un load balancer VPS

Une architecture saine repose sur un VPS dedie au role de load balancer, place devant au minimum deux VPS applicatifs. Sur des VPS Linux OmegaCloud equipes de SSD SAS et d'un reseau faible latence intra-datacenter, la communication entre le repartiteur et les backends reste rapide et previsible.

Schema type

            Internet
               |
        [ Load Balancer VPS ]   (HAProxy ou Nginx)
          /        |        \
   [ app-1 ]   [ app-2 ]   [ app-3 ]
       \          |          /
          [ Base de donnees ]

Reseau interne et resolution

Faites communiquer le load balancer et les backends via un reseau prive ou, a defaut, via les IP internes du datacenter. Cela evite d'exposer inutilement les serveurs applicatifs sur Internet. Definissez les hotes dans /etc/hosts pour eviter toute dependance DNS externe sur le chemin critique.

cat <<EOF | sudo tee -a /etc/hosts
10.0.0.11 app-1
10.0.0.12 app-2
10.0.0.13 app-3
EOF

Haute disponibilite du load balancer lui-meme

Un seul load balancer reste un point unique de defaillance. Pour aller plus loin, on associe deux VPS repartiteurs avec keepalived et une IP virtuelle (VRRP) basculee automatiquement. Ce document se concentre d'abord sur un noeud unique, base solide avant d'ajouter la redondance.

Installer et configurer HAProxy comme load balancer VPS

HAProxy reste la reference pour un load balancer VPS robuste, en L4 comme en L7. Il est stable, econome et parfaitement documente. L'exemple suivant cible Debian 12 ou Ubuntu 24.04, disponibles en un clic depuis le panel.

Installation

sudo apt update
sudo apt install -y haproxy
haproxy -v

Configuration de base en L7

Editez /etc/haproxy/haproxy.cfg. La configuration ci-dessous ecoute en HTTP, applique un algorithme round-robin et verifie la sante des backends.

global
    log /dev/log local0
    maxconn 20000
    user haproxy
    group haproxy
    daemon

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

frontend http_in
    bind *:80
    default_backend app_servers

backend app_servers
    balance roundrobin
    option httpchk GET /health
    server app-1 10.0.0.11:8080 check
    server app-2 10.0.0.12:8080 check
    server app-3 10.0.0.13:8080 check

La directive option httpchk GET /health impose que chaque backend expose un endpoint de sante renvoyant un code 200. Si un serveur ne repond plus, HAProxy le retire du pool sans intervention manuelle.

Validation et activation

sudo haproxy -c -f /etc/haproxy/haproxy.cfg
sudo systemctl enable haproxy
sudo systemctl restart haproxy
sudo systemctl status haproxy

Terminaison TLS

Pour centraliser le HTTPS, ajoutez un frontend en 443 avec le certificat concatene (fullchain + cle privee dans un seul fichier PEM).

frontend https_in
    bind *:443 ssl crt /etc/haproxy/certs/site.pem
    http-request redirect scheme https unless { ssl_fc }
    default_backend app_servers

Sticky sessions

Si votre application ne partage pas les sessions entre backends, activez l'affinite par cookie pour qu'un utilisateur reste sur le meme serveur pendant sa session.

backend app_servers
    balance roundrobin
    cookie SRV insert indirect nocache
    server app-1 10.0.0.11:8080 check cookie s1
    server app-2 10.0.0.12:8080 check cookie s2
    server app-3 10.0.0.13:8080 check cookie s3

Page de statistiques

HAProxy expose une interface d'etat tres utile pour surveiller les backends en temps reel.

listen stats
    bind *:8404
    stats enable
    stats uri /haproxy?stats
    stats refresh 10s
    stats auth admin:motdepasse_solide

Alternative Nginx et securisation du load balancer VPS

Nginx constitue une alternative pertinente lorsque vous voulez cumuler reverse proxy, cache statique et load balancing L7 sur une meme instance. Il s'integre naturellement a un Hebergement Web OmegaCloud ou a un VPS applicatif.

Configuration Nginx en upstream

sudo apt install -y nginx

Dans /etc/nginx/conf.d/lb.conf :

upstream app_backend {
    least_conn;
    server 10.0.0.11:8080 max_fails=3 fail_timeout=15s;
    server 10.0.0.12:8080 max_fails=3 fail_timeout=15s;
    server 10.0.0.13:8080 max_fails=3 fail_timeout=15s;
}

server {
    listen 80;
    server_name exemple.fr;

    location / {
        proxy_pass http://app_backend;
        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;
    }
}

sudo nginx -t
sudo systemctl reload nginx

L'algorithme least_conn route vers le backend ayant le moins de connexions actives, ce qui convient bien aux requetes de duree variable. Les parametres max_fails et fail_timeout gerent l'exclusion temporaire d'un backend defaillant.

Filtrage reseau avec le pare-feu

Le load balancer expose 80 et 443 vers Internet, mais les backends ne doivent accepter que le trafic provenant du repartiteur. Sur les backends, restreignez l'acces au port applicatif.

# Sur le load balancer
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw allow OpenSSH
sudo ufw enable

# Sur chaque backend : n'autoriser que l'IP du LB
sudo ufw allow from 10.0.0.10 to any port 8080 proto tcp
sudo ufw allow OpenSSH
sudo ufw enable

Durcir l'acces SSH

Sur toute la chaine, appliquez les fondamentaux : cles SSH uniquement, desactivation du mot de passe et protection contre le bruteforce avec fail2ban.

ssh-keygen -t ed25519 -C "admin@omega"
# Copier la cle publique sur les serveurs
ssh-copy-id [email protected]

sudo apt install -y fail2ban
sudo systemctl enable --now fail2ban

Dans /etc/ssh/sshd_config, verifiez :

PasswordAuthentication no
PermitRootLogin prohibit-password
PubkeyAuthentication yes

sudo systemctl restart ssh

Ce que gere deja l'infrastructure

La protection anti-DDoS volumetrique est appliquee cote reseau par l'infrastructure OmegaCloud, de maniere transparente. Votre role au niveau du load balancer se limite donc au filtrage applicatif, aux limites de connexions et a l'hygiene SSH. Pour la documentation de reference sur le durcissement, consultez les guides de l'Source ANSSI.

Limiter les connexions abusives

Meme derriere un anti-DDoS reseau, il reste utile de plafonner les connexions applicatives pour se premunir contre les abus L7 legers.

# HAProxy : limiter les connexions par IP
frontend http_in
    bind *:80
    stick-table type ip size 100k expire 30s store conn_cur
    tcp-request connection track-sc0 src
    tcp-request connection reject if { sc0_conn_cur gt 50 }
    default_backend app_servers

Automatisation et supervision

Le panel OmegaCloud permet de suivre en temps reel le CPU, la RAM, le SSD et le reseau de chaque VPS, de creer des snapshots avant toute modification de configuration et de piloter le provisioning via l'API. Vous pouvez integrer le deploiement de vos backends dans un pipeline CI/CD via GitHub Actions ou GitLab CI, comme detaille dans la section Integrations & API OmegaCloud. Prenez toujours un snapshot avant de recharger HAProxy en production.

La documentation officielle du projet reste la reference pour approfondir les directives avancees. Consultez egalement les manuels systeme via Source pour les commandes reseau et systemd.

Un article complementaire sur la haute disponibilite et les architectures multi-noeuds est disponible sur le Blog OmegaCloud.

Conclusion

Configurer un load balancer VPS repose sur des briques eprouvees : HAProxy ou Nginx, des checks de sante fiables, un filtrage reseau strict et une supervision continue. En separant clairement le role du repartiteur de celui des backends, vous obtenez une architecture evolutive et resiliente. Ajoutez ensuite keepalived pour eliminer le dernier point unique de defaillance.

FAQ

Faut-il un VPS dedie pour heberger le load balancer ?

Oui, c'est recommande en production. Isoler le load balancer sur son propre VPS evite la concurrence de ressources avec les backends et simplifie la maintenance. Un VPS de gamme moyenne suffit souvent, car HAProxy et Nginx consomment peu de CPU pour de la distribution de trafic.

Comment gerer la haute disponibilite du load balancer lui-meme ?

Deployez deux VPS repartiteurs avec keepalived et une IP virtuelle en VRRP. Si le noeud actif tombe, l'IP bascule automatiquement vers le noeud de secours. Les deux instances doivent partager une configuration identique de HAProxy ou Nginx pour une transition transparente.

Le load balancer doit-il absorber les attaques DDoS ?

Non, la mitigation volumetrique est deja assuree au niveau kernel par l'infrastructure OmegaCloud, de facon transparente. Le load balancer se concentre sur la distribution du trafic legitime. Vous pouvez toutefois ajouter des limites de connexions par IP pour contenir les abus applicatifs legers.