The mailing list for listmasters using Sympa

[Christopher Andrews <address@concealed>]

Steve, thanks for the detailed responses, it validated some of our assumptions and gives us a lot more to think about.  We will let everyone know how it works out.

 

---

  Chris Andrews

  Boston College

  Collaboration Team

  Sr. Applications Systems Administrator

  617-552-6365

 

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

 

I think most of the issues, if any, will relate to race conditions, and so will be difficult to reliably test for.

 

The shared database would seem OK for most, but might be an issue for the logs table and more importantly the table used for spools.

 

The spool directories can likely be separate, apart from the moderation and auth queues!  These would need to be shared because you cant know which server will end up being asked to approve the post.

 

As fast as resynch tasks go, for external datasources, you could either kill task manger on one server, delete the tasks files on one server, or simply halve the TTLs for the datasources.  My preference would be for the latter since the first two options have problems for HA.  If you just halve the TTL in the list definition, and make sure that the scheduled tasks are perfectly out of synch, then you effectively get proper synchronisation... we have used a similar method in a different system here.

 

We currently have about 12,000 ldap-based lists, with a 1-day TTL (but a 1-hour TTL on distribution).  These do not put undue loading on our LDAP cluster or on the Sympa server, though the LDAP cluster does occasionally ping us as a suspect DoS source...

 

Tasks for subscription reminders, though, would be more of an issue – not sure of a good way to get around this, since Sympa doesn’t make an internal note of the last reminder time, it just relies on the task schedule time (though it appears to auto-recreate the remind task if you delete it)

 

The archiving task can likely run on both servers and probably should, if you’re keeping the spools separate.  Rebuilding the HTML archives more frequently than strictly required shouldn’t be a problem, and it means that should one server go down then the other will continue to handle the work without intervention.

 

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: Christopher Andrews [mailto:address@concealed]
Sent: Saturday, 3 November 2012 5:35 a.m.
To: Steve Shipway; address@concealed
Subject: RE: Sympa and high availabilty

 

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

 

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