email: courriel@victor-hery.com
date: 2013-01-17T13:21+01:00
author: Victor
website: http://blog.xn--hry-bma.com/
replyto: 0md

Hello !  
Merci, j'essaye d'être précis :)

Pour tes questions, je vais tâcher de traiter ces sujets dans la suite. Mais rapidement, ce que je peux en dire :  
 - Le fencing peut être détourné via Node Assassin (qui peut faire du fencing via SSH) ou du Manual Fencing (qui consiste à attendre une intervention humaine se chargeant du fencing, donc aucun intérêt). Node Assassin est assez intéressant, mais dans l'optique où la connexion entre les 2 machines est mortes (ce qui est le cas le plus répandu dans un contexte distant comme ça), ça ne sert à rien et le PRA tourne en boucle en attendant de réussir son fencing. La solution la plus simple (et moche !) consiste à bidouiller un script qui retourne exit 0 après avoir envoyé un courriel d'alerte...  
 - DRBD va imposer (j'aurai peut être pu en parler là d'ailleurs, désolé) d'utiliser KVM. J'ai passé de longues semaines à tenter de faire fonctionner OpenVZ sur DRBD, mais à travers un lien Internet, la latence est trop importante, et le système d'OpenVZ fonctionnant avec des dossiers (private, root, ...) n'est pas viable. Peut être avec le futur ploop, mais alors on perd tout l'intérêt d'openvz-diff-backup :) Etre sous KVM est donc une contrainte importante en effet. Mais ça fonctionne correctement, même avec Mysql, dans le sens où DRBD a une notion de cohérence des données plutôt bien foutue. Pour ma part, je n'ai pas eu de soucis lors de mes tests à ce niveau là.  
 - Pour les IP failover, je "règle" le problème avec une passerelle portant l'IP publique sur chaque système, qui n'est pas en HA. Et cette passerelle met un jour les DNS dynamiques automatiquement en cas de besoin. C'est le moyen le plus propre que j'ai pu trouver. (Voir l'article sur le DynDNS OVH) Pas vraiment du failover, mais la vitesse de réplication est acceptable (environ 10 minutes), ça marche parfaitement avec des liens IPsec par exemple.
