[afnog] Clustering Exim

Phil Regnauld regnauld at nsrc.org
Thu Feb 25 17:11:45 UTC 2010

SM (sm) writes:
> The idea seems to be about how to span mail spools across multiple hosts.

	Yes.  That's already an issue, since most MTAs, including Postfix,
	Sendmail and EXIM don't expect another process to mess with the queue
	while they're working on it.  That's why only 1 qmgr process is running,
	for instance (Postfix).

> CARP is not required unless you want some internal load balancing.

	Not quite, CARP is used for failover scenarios, but can also be
	used for load balancing.

> MTAs should retry delivery.  If one host is done, it can always
> contact the next host available.

	It depends whether you want to enforce the delivery by controlling
	the active IP, or you want to leave that up to the remote sender

	Which is why MX based load balancing doesn't work that well since
	many badly written MTAs and spammers order the results returned
	by the DNS and send email to the first IP in numerical order or

> >        Any other form of non-synchronous replication will leave you with
> >        potentially 1 or more mails stuck on the currently active system.
> The main problem is how to avoid that message from being stuck in a
> spool when the host is unavailable.

	You can't unless you share the filesystem at block level (DRBD)
	or VFS level (NFS on a shared backend) or using GFS or similar.
	ZFS snapshots face the same problem as scheduled rsync replications.

	Or you need to make the MTA aware that it should deliver a copy
	of the incoming mail to the local queue and the remote queue
	(since this is not a POP/IMAP server, we are talking about the
	mail queue).

> When the master goes down, take it off the list of available hosts.
> You either have to "copy" the spool to another host where it can be
> processed

	How do you do that without either a) shared storage or b) synchronous
	block replication ?

> or else have some "master" spool and keep track of
> messages that have been sent.

	That requires making the MTA aware.

More information about the afnog mailing list