Accéder au contenu.
Menu Sympa

fr - Re: [sympa-fr] Architecture HA "simple" de sympa

Objet : Pour les administrateurs de serveurs de listes utilisant le logiciel Sympa

Archives de la liste

Chronologique Discussions  
  • From: Philippe Camps <adresse@cachée>
  • To: adresse@cachée, Gallavardin Antoine <adresse@cachée>
  • Subject: Re: [sympa-fr] Architecture HA "simple" de sympa
  • Date: Tue, 16 Nov 2021 16:08:31 +0100

Bonjour,

Je n'ai pas de contraintes particulières sur la HA de sympa, mais j'ai installé sympa sur une VM avec des sauvegardes.
Donc si l'hôte plante, je peux migrer la VM sur un autre hôte.
Si la VM plante, je restaure un snapshot ou récupère l'image sauvegardée;
Dans le pire des cas, je perds un peu d'historique dans l'archivage, mais cela n'a que peu d'importance si le service continue à fonctionner par la suite.

Cdt

Le 12/11/2021 à 16:11, Gallavardin Antoine a écrit :

Hello

Dans le but de rassembler 2 Sympas en un (merci le multirobot !) on se pose aussi la question d'avoir de la haute disponibilité de service ( à minima pour les envois /réceptions de mail)

On dispose de 2 centre de données  et donc avoir un service sympa dans chaque DC peut être pertinent.

Mais je reste assez hésitant sur l'architecture : Actif/Actif ou Actif / Passif.

Chacun des composants peut être répliqué en mode "Multi Maitre"

  • LDAP ( pour les alias) : réplication multiMaitre
  • base de donnée : réplication Multimaitre ( galera cluster)
  • fichier de conf ( apache/postfix / sympa) : réplication à chaque changement ( script / rsync /ansible /...)
  • binaire : Veiller à installer les même versions de sympa
  • Système de fichier ( spool / archive) : DRBD  ( ou tout autre système de réplication de système de fichier)

Mais j'ai un peu peur que cela devienne un peu une usine à gaz et notamment dans les évolutions des différents nœuds et ce que ce soit en mode Actif/Actif ou Actif /passif

L'autre option est de penser non pas "sympa" mais "service d'envoi de groupe".

Il s'agirait alors d'avoir un service dégradé (envoi de mail uniquement) en cas de l'indisponibilité du service sympa.

C'est à dire n 'avoir qu’un service d’envoi de mail avec un postfix qui utilise un réplicat de la BD de sympa (via mariadb)  pour envoyer aux abonnés des différentes listes [1].

Ce service dégradé ne serait actif que sur redirection du flux de mail du MX vers ce serveur et plus sur le serveur sympa principal.

L'objectif est simplement de pouvoir continuer à envoyer du mail à des abonnés ( en perdant les fonctionnalités de base de sympa ( archivage / étiquetage du sujet / entête et pied de page) .

Est ce pertinent ? Et vous ? Comment gérer vous votre haute disponibilité de "sympa" ou de votre "service d'envoi de groupe" ?

Antoine


[1] Postfix sais faire avec du LDAP, je pense qu'il sait le faire avec une base de donnée

-- 
Antoine Gallavardin
INRAE - SIIR Auvergne Rhone Alpes - DSI-INFRA

--
Philippe CAMPS
Administrateur Systèmes et Réseaux Tél : 04 67 14 39 85 adresse@cachée
IES - Institut d'Electronique et des systemes - UMR 5214 Campus Saint Priest Bâtiment 5 - CC5001 860 rue St Priest - 34095 Montpellier cedex 5 WWW.IES.UMONTPELLIER.FR

JPEG image

PNG image

PNG image




Archives gérées par MHonArc 2.6.19+.

Haut de le page