Re: [sympa-fr] Migration et clusters

[Serge Aumont <adresse@cachée>]

On 07/01/2010 02:23 PM, Pech Guillaume wrote:

Bonjour à tous,

 

J’étudie toujours la version 6.0 de Sympa et envisage de mettre une solution au point avec deux serveurs en cluster qui produisent le service sympa (Listes + Web). Les flux sont loadbalancés en amont et un Filer et une BDD seront mise en place pour que les serveurs stockent et aient l’accès à toutes les informations de toutes les listes.

 

Je me pose la question suivante :

Si, ultérieurement, je veux faire la MAJ des Sympa sur les machines. Comment dois-je procéder ? Car l’update d’un Sympa engendrera la modification de la BDD et potentiellement des données (suivant la MAJ) du Filer … Qu’en sera-t-il lors de la MAJ du second ? Message d’erreur (type : les fichiers ont déjà la bonne structure) ? Erreur ? Problème ? Aucun problème ? … Voyez-vous un moyen de ne pas suspendre le service durant la MAJ ?

 

J’attends vos retours, méthodes et conseils !

 

Non, du moins, on n'a pas de garantie que ce sera possible pour tout saut de versions. Par exemple, impossible pour passer d'une version 5 à une version 6 (le stokage des mots de passe à changer). Toutefois pour le passage de 6.0 à 6.1. Ce sera possible selon le mode opératoire suivant :

• httpd stop;  sympa stop ; make ; make install; sympa.pl --upgrade ; sympa start sur la machine 1.
• httpd stop;  sympa stop ; make ; make install; sympa start sur la machine2.

Bien entendu si les exécutables de sympa sont sur en 1 seul exemplaire, sur le filer, il est inutile de faire un make; make install sur la machine 2.

A moins que la version 6.2 n'apporte la gestion de l'ensemble des spools en bdd la même procédure sera possible. En effet, nous ne supprimons rien dans la structure de la base de donnée lors des changement, nous ne faisons qu'enrichir la base.  La définition de la 6.2 n'est pas encore assez précise  pour s'engager sur ce point. Dans tous les cas si vous n'arrêtez pas les services Sympa, épluchez bien le changelog !!!

Selon moi, cet l'upgrade est assez rapide pour rendre supportable un arrêt de quelques minutes. Si vous avez des exigences de disponibilité  vraiment forte, le plus sur est alors de roder l'upgrade sur un clone du serveur en production (merci la virtualisation).  Cela peut permettre d'identifier des pbs d'install de modules cpan qui pourraient vous faire perdre du temps.  Une fois fait, scriptez l'enchainement  : arret, upgrade, restart. Le tout ne doit pas prendre plus de quelques secondes.

Je signale sur ce point que la sauvegarde dans un état cohérent de la base de donnée impose souvent un arrêt du serveur de BDD donc un arrêt du service d'une durée équivalente à celui imposé par un tel upgrade.

Un retour sur votre config de cluster sera apprécié.

Serge Aumont