Il y a donc un ‘prefered master’ ?
Pour moi plusieurs solutions, la première n’est clairement pas envisageable car elle passerai par le montage de DRBD afin de pouvoir répliquer block par block deux devices (l’un sur le serveur WEB1 et l’autre sur le serveur WEB2).
Cette solution est ma préféré dans le cas présent mais ce la réclame de refaire intégralement la partie stockage, si il y a assez de place pour créer les block utile à DRDB sans rien effacer alors nickel, sinon il faudra sacrifier un serveur le temps de la remise à plat de la chose.
L’autre solution consiste à monter un NFS et pouvoir ainsi répliquer les données de l’un vers l’autre, je ne suis pas sur que ce la supportera une bascule des services propre en cas de surcharge de WEB1.
Cela ne concernera que les fichiers
La troisième consiste effectivement à répliquer à grand coup de rsync (dans une CRON), ça bouffera de la bande passante et ne concernera que les fichiers.
Cette solution tout comme la précédente pourra par contre se coupler avec une bonne vielle réplication de base de donnée avec du corosync/pacemaker (ou simplement du mon avec du heartbeat), la VIP du mysql étant alors gérée grâce à ton haproxy 
Autre solution pour ce qui est de la partie base de donnée, si tu utilise du mysql ce serait de monter un cluster Galera, mais il me semble que ces trois bases distinctes qu’il te faudra dans ce cas pour fonctionner au mieux.
Attention toute fois lors de la mise ne HA actif/passif de bases de données la bascule exigera d’être traité rapidement car l’IP virtuelle rebascule vous allez écrire sur deux bases qui ne seront plus identiques et vous obligera à soit perdre de la donnée soit extraire les les modifications faites sur l’un et pas sur l’autre, écraser le slave et réinjecter les données du master … en somme un sacré travail.
Du coup le monitoring de tout ça est IMPERATIF !!!
PS : j’ai volontairement oublié les solutions de stockage réparti te lque CEPH et Gluster et consorts, cela me parait un poil disproportionné quant au besoin immédiat
