The mailing list for listmasters using Sympa

[Christopher Andrews <address@concealed>]

I was thinking the same thing about the spools, there is no need to have the servers share the actual spools. If each server has its own spool folders in separate parent folders on the same NFS mount, or are on separate NFS mounts that are mounted to both servers, then if the one fails it would be trivial to copy of the spooled messages from the downed server to the active server.  That was we do not have to worry about the separate Sympa instances fighting over the spool files and folders.

 

Manually having to restart Sympa to implement changes across both servers is not an issue, all changes have to be planned and completed off hours.

 

A couple of further questions:

 

·         Are there any issues with having two Sympa instances talking to the same database?

·         We will be doing a lot of LDAP based lists and nested lists, so would we want to limit the task_manager.pl to one server? or could it run on both servers?

·         How about the archived.pl process?  Would we only want one of the instances to be responsible for archiving of incoming messages?

 

 

---

  Chris Andrews

  Boston College

  Collaboration Team

  Sr. Applications Systems Administrator

  617-552-6365

 

From: Steve Shipway [mailto:address@concealed]
Sent: Thursday, November 01, 2012 8:33 PM
To: Christopher Andrews; address@concealed
Subject: RE: Sympa and high availabilty

 

Interesting setup – we’ve investigated similar here.  I think you may have problems with the shared spool, if both instances try to grab an item at once., in some cases.  Also if someone changes something in the configs via wwsympa, will both instances reload? 

 

We’ve virtualised our Sympa onto vmware 4.1, which gives a lot of HA over our big cluster; the underlying VMDK is SAN-mirrored to our DR site and so barring complete filesystem destruction we should be able to bring up Sympa within an hour even if we lose the whole primary datacentre.

 

Since Sympa is only non-interactive email, which does not have to be delivered within seconds (according to our SLA), a short (hour) outage is acceptable in a DR situation, and we’re not trying for an F5-based hot standby, just relying on VMware to provide a DR solution.

 

Steve

 

---

Steve Shipway

ITS Unix Services Design Lead

University of Auckland, New Zealand

Floor 1, 58 Symonds Street, Auckland

Phone: +64 (0)9 3737599 ext 86487

DDI: +64 (0)9 924 6487

Mobile: +64 (0)21 753 189

Email: address@concealed

P Please consider the environment before printing this e-mail

 

From: address@concealed [mailto:address@concealed] On Behalf Of Christopher Andrews
Sent: Friday, 2 November 2012 9:20 a.m.
To: address@concealed
Subject: [sympa-users] Sympa and high availabilty

 

We are currently exploring our Sympa upgrade paths.  We currently have one Sympa 5.3X server with a local MySQL database instance.  We are looking at using Sympa to replace some other mail list functionality on campus and possibly replacing our custom bulk mailer.  Is it possible to do the following architecture?

 

·         One F5 Load Balancer Pair doing SSL off load for the web UI

 

·         2 Sympa front ends (Linux servers running sendmail and Sympa)

 

·         One mirrored SQL instance (2 Linux servers running mirrored MySQL)

 

·         NFS mounts for shared files, like the web archives and configuration files

 

 

We are going for High Availability here, any one server (or NetApp head or F5 loadblancer) could fail and the whole system keep chugging along.  We could even break out the BULK.PL to other servers to reduce the load on the frontends.  Also we would be virtualizing all of the server on VMware ESXi  4.1. 

 

---

  Chris Andrews

  Boston College

  Collaboration Team

  Sr. Applications Systems Administrator

 

Attachment: smime.p7s
Description: S/MIME cryptographic signature