Tutoriel : Mettre en place une architecture haute disponibilité avec 2 VPS synchronisés

par

Tutoriel : Mettre en place une architecture haute disponibilité avec 2 VPS synchronisés

Réplication MySQL, synchronisation des fichiers, load balancing et basculement automatique

🧭 Objectif

Dans ce tutoriel, tu vas apprendre à mettre en place une architecture à haute disponibilité (HA) entre deux VPS, capable de résister à une panne d’un serveur sans interruption du service.

Ce que nous allons configurer :

  • 🔁 Réplication MySQL (Master/Master ou Master/Replica)
  • 📂 Synchronisation des fichiers avec rsync ou GlusterFS
  • 💡 Basculement automatique avec Keepalived ou Heartbeat
  • ⚖️ Répartition de charge (Load Balancing) avec HAProxy ou NGINX
  • 🔥 Un service web WordPress ou autre, toujours en ligne

🛠️ Pré-requis

  • 2 VPS Linux (Debian/Ubuntu), accessibles par SSH
  • 1 adresse IP flottante ou un nom de domaine pointant vers un proxy/load balancer
  • Un peu de temps, de rigueur, et une passion pour la résilience

🌐 Architecture cible

           [ Client ]
               |
          +------------+
          |  HAProxy   | ← IP flottante ou domaine
          +------------+
            /        \
      +----------+ +----------+
      | VPS1 (web/db) | VPS2 (web/db)
      +----------+ +----------+
        ↕ Sync DB      ↕ Sync fichiers

Étape 1 – Préparer les 2 VPS

Sur les deux serveurs :

apt update && apt upgrade -y
apt install nginx mariadb-server rsync keepalived -y

Crée un utilisateur ha pour les synchronisations :

adduser ha

Assure-toi que les deux serveurs ont leurs IPs locales définies dans /etc/hosts :

192.168.1.1   vps1
192.168.1.2   vps2

Étape 2 – Réplication MySQL (Master-Master)

Sur VPS1 (192.168.1.1) :

Dans my.cnf ou 50-server.cnf :

[mysqld]
server-id = 1
log_bin = mysql-bin
bind-address = 0.0.0.0
auto_increment_increment = 2
auto_increment_offset = 1

Sur VPS2 (192.168.1.2) :

[mysqld]
server-id = 2
log_bin = mysql-bin
bind-address = 0.0.0.0
auto_increment_increment = 2
auto_increment_offset = 2

Redémarre les deux serveurs MySQL :

systemctl restart mariadb

Crée l’utilisateur de réplication sur les deux :

CREATE USER 'repli'@'%' IDENTIFIED BY 'password';
GRANT REPLICATION SLAVE ON *.* TO 'repli'@'%';
FLUSH PRIVILEGES;

Récupère les infos binlog

Sur VPS1 :

SHOW MASTER STATUS;

Sur VPS2 :

CHANGE MASTER TO
MASTER_HOST='192.168.1.1',
MASTER_USER='repli',
MASTER_PASSWORD='password',
MASTER_LOG_FILE='mysql-bin.000001',
MASTER_LOG_POS=XYZ;
START SLAVE;

Fais l’inverse depuis VPS1 vers VPS2.

⚠️ Utiliser gtid_mode=ON pour une réplication plus moderne (optionnel).

Étape 3 – Synchronisation des fichiers

Deux options : rsync via cron + inotify, ou GlusterFS.

Option 1 : rsync (simple et efficace)

Sur VPS2 (récupère depuis VPS1) :

rsync -avz -e ssh ha@192.168.1.1:/var/www/ /var/www/

Automatise avec cron ou inotifywait :

apt install inotify-tools

Script (ex. /usr/local/bin/sync_files.sh) :

#!/bin/bash
inotifywait -mrq -e modify,create,delete /var/www | while read path _ file; do
    rsync -az /var/www/ ha@192.168.1.2:/var/www/
done

Option 2 : GlusterFS (clusterisé)

Sur les deux VPS :

apt install glusterfs-server -y
systemctl enable --now glusterd

Crée le volume partagé :

gluster peer probe 192.168.1.2
mkdir -p /data/web
gluster volume create web-volume replica 2 transport tcp 192.168.1.1:/data/web 192.168.1.2:/data/web force
gluster volume start web-volume

Monter sur /var/www :

mount -t glusterfs 192.168.1.1:/web-volume /var/www

Étape 4 – Load Balancing avec HAProxy

Sur un VPS tiers (ou sur l’un des deux), installe HAProxy :

apt install haproxy -y

Configuration de base :

frontend http_front
   bind *:80
   default_backend http_back

backend http_back
   balance roundrobin
   server vps1 192.168.1.1:80 check
   server vps2 192.168.1.2:80 check

Étape 5 – IP flottante avec Keepalived

Keepalived permet d’avoir une IP virtuelle active sur un seul VPS à la fois.

Sur les deux VPS :

apt install keepalived -y

VPS1 : /etc/keepalived/keepalived.conf

vrrp_instance VI_1 {
    state MASTER
    interface eth0
    virtual_router_id 51
    priority 101
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass secret
    }
    virtual_ipaddress {
        192.168.1.100
    }
}

VPS2 :

Même chose mais avec state BACKUP et priority 100.

Démarre Keepalived :

systemctl restart keepalived

Teste en coupant le réseau de VPS1 : VPS2 prend l’IP 192.168.1.100.

✅ Tests et vérifications

  • 🔁 MySQL : modifie une ligne, vérifie sa réplication
  • 📂 Fichiers : ajoute une image, elle doit apparaître sur l’autre VPS
  • 🖥️ Load balancer : recharge la page, round-robin actif
  • ⚠️ Failover : éteins un VPS, le service reste accessible

📌 En résumé

Élément Outils
Réplication SQL MySQL/MariaDB (Master-Master)
Sync fichiers rsync + inotify ou GlusterFS
Load balancing HAProxy ou NGINX
IP flottante Keepalived
Tolérance de panne Oui (si 1 VPS tombe, l’autre prend le relais)

💡 Bonus : Docker ou Ansible ?

Tu peux automatiser cette stack avec :

  • Docker Swarm + Keepalived
  • Ansible pour la réplication + déploiement
  • Traefik comme reverse proxy intelligent

🎯 Conclusion

Créer une architecture haute disponibilité n’est pas réservé aux grands sites web. Même avec 2 petits VPS, tu peux assurer :

  • une redondance de service
  • un site toujours disponible
  • une résilience réelle à moindre coût