[afnog] Clustering Exim

[Mike Barnard]

Thanks Phil and SM

On Fri, Feb 26, 2010 at 12:37 PM, Phil Regnauld <regnauld at nsrc.org> wrote:

> Phil Regnauld (regnauld) writes:
> > Mike Barnard (mike.barnardq) writes:
> > > can provide?
> > >
> > > I'm looking at having an Active-Passive cluster whose message queues
> are
> > > replicated across each node in the cluster. The active node would copy
> its
> > > message queues over to the passive node or the passive node would copy
> the
> > > queues from the active node so that incase of a failure on the active
> node,
> > > the passive node can take over processing email.
>
>         Of interest to this discussion, the equivalent of DRBD is now
>        ready for FreeBSD!
>
>
> http://freebsdfoundation.blogspot.com/2010/02/hast-project-is-complete.html
>

>From all that I read it appears that I have to jump a few hurdles. My one
problem was how to ensure that the mail spool on the active node was somehow
copied over to the passive so that should the active node go down while sill
processing an email, I could pick it up from the passive node and continue
with no problem. At the same time, I'd have to find a way to start up the
exim process on the passive node when the active node goes down so that the
mail service continues without breaking.


The initial idea I had was to setup FreeBSD with CARP and use Unison to
synchronise the spool directories. This way, I would be able to ensure that
the passive node comes up *only* when the active node goes down and that I'd
have my mail spool on the passive node. But I faced a challenge on this;
Starting the MTA process on the passive node, unison's response to one node
going down, what happens when the active node comes back online, and of
course the queue management?

SM, I handle only one domain and I am backup mx for only one other domain

DRDB looks like it will sort out the spool directory copying, but I will
still need to overcome the starting of the MTA process on the passive node
and queue management. As Phil suggested, it may require making one MTA aware
of the second MTA's status.


-- 
Mike

Of course, you might discount this possibility, but remember that one in
a million chances happen 99% of the time.
------------------------------------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://afnog.org/pipermail/afnog/attachments/20100226/1df3f862/attachment-0001.htm>