[sympa-fr] Re: sympa, haute disponibilité et NFS

[Jacques Leyrat <adresse@cachée>]

Sylvain Amrani a écrit :

Bonjour,
Jacques Leyrat a écrit :

Nous étudions la mise en place de la haute disponibilité pour le service de listes sympa sur 2 serveurs sous Debian Sarge.
Nous disposons d'un filer Netapp et de deux serveurs que nous voulons mettre en haute disponibilité via Heartbeat (si possible avec répartition de charge).

Heartbeat n'est pas fait pour de la répartition de charge. La plupart du temps, un seul serveur est exposé aux utilisateurs.

Des montages NFS permettront aux serveurs de se partager  l'accès aux données, configurations et spool stockées sur le filer.
La database Mysql est déportée et accédée via un autre serveur.
Une première solution à laquelle nous avons pensé, après lecture de la FAQ "Sympa in a cluster architecture" et des messages retrouvés sur sympa-fr et sympa-users (en particulier de l'expérience de Sylvain Amrani):

Comprenez bien que je ne fais pas de répartition de charge. Un post dans les archives de Serge ou Olivier mentionnait qu'il fallait des patches pour faire un locking compatible NFS (et qu'un patch était disponible, d'ailleurs). J'avais trouvé la source de quelques problèmes de locks (bug corrigé dans les branches 5.2 et 5.3), mais il m'en reste encore avec wwsympa.fcgi (des locks laissés par le fcgi sur include_admin mettent temporairement la liste en statut error_config ; je n'ai pas encore pris le temps de regarder attentivement, car ça n'est pas très gênant.). En faisant du strict heartbeat, vous limiter les problèmes d'écritures concurrentes.

Serveur 1                                                         Filer                                                        Serveur 2

postfix                                                                                                                              Apache
sympa.pl                                                           /home/sympa/etc                                     wwwsympa.fcgi
bounced.pl                                                        /home/sympa/expl
archived.pl                                                        /home/sympa/spool
task_manager.pl                                               /home/sympa/arc

Vous faites donc là de la répartition en séparant le côté web, mais pas de haute dispo. Avec des scripts MON appropriés, on pourrait faire qu'en cas de défaillance d'un de vos deux serveurs, les services correspondants repartent sur le serveur restant : par exemple, on exposerait apache sur le serveur1 si le s2 tombe, grâce à une IP virtuelle pilotée par les scripts hearbeat.

C'est effectivement ce que je voudrais mettre en place, et j'aimerais savoir si cela a déja été réalisé et s'il y a des précautions particulières ou des problèmes à prévoir, tels que ceux de locks dont vous faites état.

Pour ma part, pour simplifier, j'ai les services qui tournent sur un spare "en lecture seule", et donc en cas de défaillance du serveur maître, on n'a pas d'administration possible le temps de la remontée. Mais il n'y a en fait pas de raison en soi, j'ai fait ça par facilité en attendant de creuser plus avant. La seule chose à surveiller sont les bascules automatiques incessantes de maitre vers spare puis retour vers maitre (suite à des problèmes réseau, par exemple).

Si j'ai bien compris, sur votre spare tournent seulement Heartbeat, le MTA, sympa.pl et bounced.pl avec basculement automatique de l'IP en cas de défaillance du maître. Est-ce bien cela ?

Serge et Olivier peuvent-ils nous éclairer sur le support des verrous NFS et du patch adéquat ?

Le monde idéal serait la possibilité de monter en charge par simple adjonction de serveurs. Peut-être devrions dresser la liste de tous les prérequis à atteindre.

Sylvain.

Merci.
Cordialement.

-- 
Jacques Leyrat
CRISI - Département Réseaux et Systèmes
Université de Caen

tél.: (02 31 56) 62 12