Infrastructure haute disponibilité

L'ordre suit les dépendances : le réseau avant les serveurs, la base avant les applications, les tests de panne à la fin. Chaque étape est validée avant de passer à la suivante.

1. Proxmox : 12 VM créées, bridge vmbr0 « VLAN aware ».
2. pfSense installé, WAN 10.4.0.198.
3. VLAN 301 à 304 : chaque VM pingue sa passerelle .254.
4. MYSQL-01 : MariaDB installé, bind-address = 10.0.20.1.
5. MYSQL-02 : idem avec 10.0.20.2.
6. MYSQL-03 : idem avec 10.0.20.3.
7. Galera formé : cluster_size = 3 sur chaque nœud.
8. HAProxy : configuration valide, SQL réparti sur les 3 nœuds.
9. WEB-01 : Apache + PHP.
10. WEB-02 : Apache + PHP.
11. WordPress : installé une fois, site identique sur les deux, servi via 10.0.10.2.
12. GLPI via 10.0.10.2:8080.
13. NAT : http://10.4.0.198:8081 affiche WordPress, http://10.4.0.198:8082 affiche GLPI.
14. Filtrage deny-by-default, flux interdits vérifiés.
15. Tests nominaux.
16. Tests de bascule (web et Galera).

VLAN

1. Proxmox : cocher VLAN aware sur vmbr0. La carte de pfSense reste sans tag (elle reçoit le trunk) ; chaque VM reçoit le tag de son VLAN (Hardware → Network Device → VLAN Tag).
2. pfSense, Interfaces → Assignments → VLANs : créer 301, 302, 303 et 304 sur vtnet1.
3. Assigner chaque VLAN à une interface, l'activer, IP statique : 10.0.10.254/24, 10.0.20.254/24, 10.0.30.254/24, 10.0.40.254/24.

# SUR L'HÔTE PROXMOX : poser le tag 302 sur la VM MYSQL-01 (VMID 105)
qm set 105 --net0 virtio,bridge=vmbr0,tag=302
# SUR MYSQL-01 : vérifier
ping -c 2 10.0.20.254

NAT vers HAProxy

Firewall → NAT → Port Forward : WAN, TCP, port 8081 → 10.0.10.2:80, avec règle de filtrage associée. On cible HAProxy et jamais un serveur web : sinon la panne de ce serveur couperait le site.

Règles principales (deny-by-default)

Installation (sur les 3 nœuds)

# SUR MYSQL-01, MYSQL-02 et MYSQL-03
sudo apt update
sudo apt install -y mariadb-server mariadb-client galera-4 rsync
sudo mariadb-secure-installation

Écouter sur l'IP du VLAN : /etc/mysql/mariadb.conf.d/50-server.cnf

# SUR MYSQL-01 (10.0.20.2 sur MYSQL-02, 10.0.20.3 sur MYSQL-03)
bind-address = 10.0.20.1      # et non 127.0.0.1 (valeur par défaut)

Configuration Galera : /etc/mysql/mariadb.conf.d/60-galera.cnf

[galera]
wsrep_on                 = ON
wsrep_provider           = /usr/lib/galera/libgalera_smm.so
wsrep_cluster_name       = "mon_cluster_galera"                     # identique partout
wsrep_cluster_address    = "gcomm://10.0.20.1,10.0.20.2,10.0.20.3"  # identique partout
wsrep_node_address       = "10.0.20.1"                              # propre au nœud
wsrep_node_name          = "MYSQL-01"                               # propre au nœud
wsrep_sst_method         = rsync
binlog_format            = ROW        # réplication des lignes, déterministe
default_storage_engine   = InnoDB     # seul moteur répliqué de façon fiable
innodb_autoinc_lock_mode = 2          # indispensable en multi-maître

Bootstrap : une seule fois, sur un seul nœud

# SUR LES 3 NŒUDS
sudo systemctl stop mariadb
# SUR MYSQL-01 UNIQUEMENT : crée le cluster
sudo galera_new_cluster
# SUR MYSQL-02, puis SUR MYSQL-03 : rejoignent le cluster
sudo systemctl start mariadb
# SUR N'IMPORTE QUEL NŒUD : vérifier
sudo mariadb -e "SHOW STATUS WHERE Variable_name IN
  ('wsrep_cluster_size','wsrep_cluster_status','wsrep_local_state_comment','wsrep_ready');"
# Attendu : 3 / Primary / Synced / ON

Test de réplication

# SUR MYSQL-01
sudo mariadb -e "CREATE DATABASE ha_test;
  CREATE TABLE ha_test.t (id INT AUTO_INCREMENT PRIMARY KEY, origine VARCHAR(20));
  INSERT INTO ha_test.t (origine) VALUES ('MYSQL-01');"
# SUR MYSQL-03 : la ligne est déjà là
sudo mariadb -e "SELECT * FROM ha_test.t;"

Installation

# SUR HAPROXY (compte d'admin « haproxyadmin », PAS « haproxy » : réservé au service)
sudo apt install -y haproxy mariadb-client socat curl
# SUR MYSQL-01 : compte de health-check, sans mot de passe ni privilège
sudo mariadb -e "CREATE USER 'haproxy_check'@'10.0.10.2';"

Configuration : /etc/haproxy/haproxy.cfg (extrait)

frontend fe_wordpress
    bind 10.0.10.2:80
    option forwardfor
    default_backend be_wordpress

backend be_wordpress
    balance roundrobin
    option httpchk
    http-check send meth GET uri /wp-login.php ver HTTP/1.1 hdr Host 10.0.10.2
    http-check expect status 200-399
    cookie SRV_WP insert indirect nocache httponly
    http-response set-header X-Served-By %[srv_name]   # rend la bascule visible
    default-server inter 3s fall 3 rise 2
    server WEB-01 10.0.10.1:80 check cookie web01
    server WEB-02 10.0.10.4:80 check cookie web02

listen galera_cluster
    bind 10.0.10.2:3306
    mode tcp
    balance roundrobin
    option mysql-check user haproxy_check post-41
    default-server inter 3s fall 3 rise 2 on-marked-down shutdown-sessions
    server MYSQL-01 10.0.20.1:3306 check
    server MYSQL-02 10.0.20.2:3306 check
    server MYSQL-03 10.0.20.3:3306 check

frontend fe_glpi
    bind 10.0.10.2:8080
    default_backend be_glpi

backend be_glpi
    option httpchk
    server GLPI-01 10.0.10.3:80 check

Appliquer et vérifier

# SUR HAPROXY
sudo haproxy -c -f /etc/haproxy/haproxy.cfg    # toujours vérifier AVANT
sudo systemctl reload haproxy                  # reload : sans couper les connexions
# Le SQL est-il bien réparti ? (un nœud différent à chaque connexion)
for i in 1 2 3 4 5 6; do mariadb -h 10.0.10.2 -u haproxy_check -N -e 'SELECT @@hostname'; done

Base et compte (une seule fois, répliqué par Galera)

# SUR MYSQL-01
sudo mariadb -e "CREATE DATABASE wordpress CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
  CREATE USER 'wordpress'@'10.0.10.2' IDENTIFIED BY '<PASSWORD>';
  GRANT ALL PRIVILEGES ON wordpress.* TO 'wordpress'@'10.0.10.2';"

Serveurs web

# SUR WEB-01 et WEB-02
sudo apt install -y apache2 libapache2-mod-php php-mysql php-curl php-gd php-mbstring php-xml php-zip php-intl rsync
sudo a2enmod rewrite remoteip
# vhost DocumentRoot /var/www/wordpress, AllowOverride All, IP réelle via X-Forwarded-For
sudo a2ensite wordpress && sudo a2dissite 000-default
sudo apachectl configtest && sudo systemctl reload apache2

wp-config.php : identique sur les deux serveurs

define( 'DB_HOST', '10.0.10.2:3306' );        // la base via HAProxy, jamais un nœud
define( 'DB_PASSWORD', '<PASSWORD>' );
// Clés et sels IDENTIQUES sur WEB-01 et WEB-02 : la session reste valide sur les deux
define( 'DISALLOW_FILE_EDIT', true );          // une modif sur un seul serveur = divergence
define( 'AUTOMATIC_UPDATER_DISABLED', true );  // idem pour les mises à jour

Synchroniser les fichiers de WEB-01 vers WEB-02

Galera réplique la base, pas les fichiers : une image téléversée sur WEB-01 n'existe pas sur WEB-02. L'installation, les extensions et les médias passent donc par WEB-01, puis sont copiés :

# SUR WEB-01 : simulation (-n) puis exécution réelle
sudo rsync -aAXn --delete /var/www/wordpress/ <ADMIN_USER>@10.0.10.4:/var/www/wordpress/ --rsync-path="sudo rsync"
sudo rsync -aAX  --delete /var/www/wordpress/ <ADMIN_USER>@10.0.10.4:/var/www/wordpress/ --rsync-path="sudo rsync"

# SUR MYSQL-01
sudo mariadb -e "CREATE DATABASE glpi CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
  CREATE USER 'glpi'@'10.0.10.2' IDENTIFIED BY '<PASSWORD>';
  GRANT ALL PRIVILEGES ON glpi.* TO 'glpi'@'10.0.10.2';"
# SUR GLPI-01
sudo apt install -y apache2 libapache2-mod-php php-mysql php-curl php-gd php-intl php-ldap php-mbstring php-xml php-zip php-bz2 php-bcmath php-apcu
sudo a2enmod rewrite

vhost : seul le dossier public/ est exposé

<VirtualHost *:80>
    DocumentRoot /var/www/glpi/public
    <Directory /var/www/glpi/public>
        Require all granted
        RewriteEngine On
        RewriteCond %{REQUEST_FILENAME} !-f
        RewriteRule ^(.*)$ index.php [QSA,L]   # tout passe par le routeur GLPI
    </Directory>
</VirtualHost>

Dans l'assistant d'installation : serveur SQL 10.0.10.2 (HAProxy), compte glpi. Ensuite : changer les mots de passe des comptes par défaut et supprimer install/install.php. GLPI est ensuite accessible sur http://10.0.10.2:8080.

Panne de WEB-01 : WEB-02 doit continuer

# SUR ADM-01 : observer en continu quel serveur répond
while true; do curl -sI http://10.0.10.2 | grep -Ei '^HTTP/|x-served-by' | tr -d '\r' | tr '\n' ' '; echo; sleep 1; done

# SUR WEB-01 : provoquer la panne
sudo systemctl stop apache2
#   → ADM-01 n'affiche plus que "X-Served-By: WEB-02", sans aucune erreur

# SUR WEB-01 : retour
sudo systemctl start apache2
#   → après ~6 s, l'alternance WEB-01 / WEB-02 reprend toute seule

Même test dans l'autre sens (WEB-02 arrêté → WEB-01 répond). La page de statistiques http://10.0.10.2:8404/stats montre le serveur passer au rouge puis revenir au vert.

Panne d'un nœud Galera : le site doit rester en ligne

# SUR MYSQL-03
sudo systemctl stop mariadb
# SUR MYSQL-01 : 2 nœuds, toujours Primary (2/3 = majorité)
sudo mariadb -e "SHOW STATUS LIKE 'wsrep_cluster_s%';"
# → WordPress et GLPI fonctionnent toujours

# SUR MYSQL-03 : il rejoint seul et rattrape son retard (PAS de bootstrap)
sudo systemctl start mariadb

Si les 3 nœuds s'arrêtent (coupure de l'hôte Proxmox par exemple), il faut redémarrer le cluster depuis le nœud le plus à jour. Si on se trompe de nœud, les transactions les plus récentes sont perdues.

# SUR CHAQUE NŒUD : état sauvegardé
sudo cat /var/lib/mysql/grastate.dat
#   safe_to_bootstrap: 1  → dernier nœud arrêté proprement : c'est lui
#   seqno: -1             → arrêt brutal : lire la vraie position :
sudo galera_recovery
#   --wsrep_start_position=<uuid>:1842   → comparer ce numéro sur les 3 nœuds

# SUR LE NŒUD LE PLUS À JOUR UNIQUEMENT
sudo sed -i 's/^safe_to_bootstrap: 0/safe_to_bootstrap: 1/' /var/lib/mysql/grastate.dat
sudo galera_new_cluster
# SUR LES DEUX AUTRES
sudo systemctl start mariadb

• SSH par clé uniquement, pas de connexion root, accepté depuis le VLAN d'administration seulement.
• Un compte SQL par application, limité à sa base et à l'IP de HAProxy ; jamais '%' ni root.
• Bases non exposées : seul HAProxy atteint le port 3306 du VLAN vBDD.
• Aucun secret sur GitHub : configurations publiées en .example avec <PASSWORD>, .gitignore strict, contrôle automatique des secrets dans la CI.

# SUR CHAQUE VM : /etc/ssh/sshd_config.d/10-hardening.conf
PermitRootLogin no
PasswordAuthentication no
# vérifier la syntaxe puis recharger (garder une session ouverte !)
sudo sshd -t && sudo systemctl reload ssh