Szerző: James P. Roberts Dátum: Címzett: Giuliano Gavazzi CC: exim-users Tárgy: Re: [Exim] mirror MX
<snip> > The
> issue is availability. I want to be able to login onto the secondary
> and get my email (when the primary is unreachable), so this is why
> both secondary and primary must consider the domains local and send a
> copy (with a veeery long retry cutoff) to the other. So far this
> would be dead easy if it wasn't for the synchronisation issues. But
> even this would not be too bad, once in a while both mailserver could
> be cut off from the rest of the world (using the firewall or some
> other mean, like communicatinig only via tunnels), perform a queue
> synchronisation first (secondary to primary) and then copying the
> primary mailboxes onto secondary using rsync. Actually, mailboxes
> should be merged... (for instance if we have an outgoing mailbox,
> like sent-mail in pine, but this is going to make things difficult).
>
> Backup is nice, but too messy and not quite what I want.
>
> Does this all make less sense now? I know it does...
>
> Giuliano
Ah. Point taken. Sounds like you really need a third box, a super-reliable
disk server (RAID, probably) for storing your mailboxes on, shared by both
servers. Have seen all sorts of discussion on list about this sort of thing.
But they are usually talking about the servers being connected by short, very
fat, pipes to the shared disks. In your case, where the two servers are
physically very far apart, this might not be practical, unless your bandwidth
needs are sufficiently modest, and you can thus use the internet itself as a
path between them.
Which sounds rather like the path you are exploring.
We all "know" that the limiting factor in email "throughput" is generally the
speed of the path to disk, so whatever you come up with may reduce your
overall capacity (GB of email per day kind of thing), since you will have a
relatively slow connection between the two servers.
hmmm...
Still brainstorming here...
I am thinking that, for what you are trying to do, beautiful and flexible
though Exim is, SMTP may not be the "right tool for the job."
How about... Set up Secondary as an ordinary SMTP secondary relay, in the
usual fashion. Then set up a method for duplicating the primary's mailboxes
on the secondary; I suspect there are many options here. Then also install an
IMAP server on the Secondary. The last, and perhaps most difficult step,
would be duplicating changes made to the IMAP store on the secondary, back
onto the primary. Unless you are using some sort of custom, web-based
interface, in which you can duplicate the IMAP commands to both servers (and
save commmands for later replication while one or the other is down)...
OK, here is yet another, similar, wild idea.
What if you created a third box, one with a reasonably reliable disk system.
Keep a duplicate of the Primary's mailboxes on it, and keep it synched as
close to real-time as possible (rsynch?). Put IMAP/POP services on this third
box. It can be co-located with the Primary, so you could use a fairly fat
pipe between them. I suggest using dedicated ethernet cards for this (reason
explained below). Under normal circumstances, have your users talk to this
3rd box for retrieving their email. (i.e. I am suggesting you split SMTP and
POP/IMAP services onto separate boxes). If one should fail, then all you have
to do is re-define the IP (and hostname, etc.) of the (now spare) ethernet
card, and plug it into your router directly, taking the place of the (either
IMAP/POP or SMTP) service provided by the downed box. Of course, you'd have
to fire up the appropriate service on the operating box. Re-synch the boxes
after repairs are complete.
One caveat... I have no idea how to automate this one, especially the part
about re-plugging ethernet cables. Maybe someone, smarter than I, has some
ideas.
