HA du stockage & des données.
La couche qu'on oublie. On redonde les frontaux et la base, puis on réalise que les fichiers uploadés (images, PDF, pièces jointes) vivent sur le disque d'un seul serveur. Si ce serveur tombe, les fichiers disparaissent. Voici comment l'éviter.
Le problème des uploads en multi-serveurs
Dès qu'on a plusieurs frontaux web, un fichier uploadé sur le serveur Web 1 n'existe pas sur Web 2. Un visiteur servi par Web 2 obtient une erreur 404 sur l'image qu'il vient d'envoyer. Et si Web 1 est perdu, le fichier l'est aussi. Le stockage local est incompatible avec des frontaux stateless : il faut sortir les fichiers des serveurs web vers un stockage partagé, répliqué et sauvegardé.
La bonne réponse moderne : le stockage objet
On externalise les fichiers vers un stockage objet compatible S3 (AWS S3, Scaleway, MinIO auto-hébergé). Les frontaux ne stockent plus rien : ils lisent et écrivent via une API. Le stockage objet gère lui-même la réplication et la durabilité. C'est ce qui rend les frontaux réellement interchangeables.
Quand on ne peut pas passer en objet
Certaines applications legacy exigent un système de fichiers classique. On dispose alors de plusieurs mécanismes de stockage partagé ou répliqué.
DRBD
Réplication de bloc en temps réel entre deux serveurs : chaque écriture disque est copiée sur le nœud miroir, comme un RAID-1 réseau. Idéal pour une paire active/passive (base de données, NFS).
GlusterFS / Ceph
Systèmes de fichiers distribués : les fichiers sont répartis et répliqués sur plusieurs nœuds, montés comme un volume unique. Ceph offre en prime du bloc et de l'objet (S3). Robuste, mais plus complexe à opérer.
lsyncd / rsync
Synchronisation quasi temps réel d'un répertoire entre serveurs (lsyncd surveille les changements et lance rsync). Simple à mettre en place, mais asynchrone : convient aux fichiers peu critiques, pas à un stockage fortement concurrent.
NFS — avec prudence
Un partage NFS centralise les fichiers, mais le serveur NFS devient lui-même un point de panne unique s'il n'est pas redondé (NFS + DRBD + VIP). Souvent un faux ami : on déplace le SPOF au lieu de le supprimer.
La sauvegarde reste indispensable : la règle 3-2-1
La réplication protège du crash matériel, pas de l'erreur humaine ni du ransomware : une suppression accidentelle se réplique instantanément sur tous les nœuds. La sauvegarde, elle, garde des points dans le temps. La règle de référence :
copies
Au moins trois copies de vos données (la production + deux sauvegardes).
supports
Sur deux types de supports différents (disque local + stockage objet distant, par ex.).
hors site
Dont au moins une copie hors site (autre datacenter, autre région) — protège du sinistre physique.
Redondance géographique : pour les applications critiques, on réplique aussi vers une seconde région. Un incendie de datacenter (déjà vu) ne doit pas emporter toutes les copies d'un coup.
Rendre vos données résilientes
On externalise vos fichiers, on met en place la réplication adaptée et une stratégie de sauvegarde 3-2-1 testée.
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 des frontaux web
Répartition de charge, health checks, VIP flottante, frontaux stateless.
Load balancing & failoverHA de la base de données
Réplication, failover automatique, cluster Galera, read/write split.
Réplication & bascule