round-robin and multi MX practicalities

[Kevin Darcy]

If you just want server B to be a "holding tank" with no user access,
you should configure it with a worse MX preference and have it simply
*relay* the mail to server A. That way it'll hold the mail in its queue
while server A is down, and deliver it when server A comes back up
again. But users won't be able to access the mail while server A is
down, so it becomes a SPoF (Single Point of Failure) for that function.

If you want true *transparent* high availability, you need multiple
machines handling incoming mail, probably round-robin or
equal-preference MX'es, and multiple machines providing user access
(probably the same set of machines, but not necessarily) with some sort
of shared-storage-and-locking between them.


- Kevin

Alex Miller wrote:

> I had a server go down recently. It's the
> second failure I've had in 6 months both
> times were my error. What a different and
> refreshing world Linux is (as compared to
> Windows not other Unixes), when I can no
> longer blame the OS for down time!!
>
> Anyway, I want to set up a SECOND server
> for the next time I screw up.
>
> Round-robining should work fine for a web
> server, if one is down, the other is available,
> that I understand, but multiple MX records
> are a different story.
>
> If a user has not picked up mail on server A
> and then server A goes down, and mail gets
> handeled by server B, mail might get lost
> when server A goes back online. All the
> mail that collected on server B during server
> A's absence, will not be collected once server
> A is handling collections.
>
> Therefore I must, I presume, synchronize the
> user mail on server A and server B. This could
> be rather scary I would think, and I imagine
> all sorts of nasty file locking problems, etc.
>
> What solutions are being used to use two servers
> for web redundancy and email redundancy?
>
> Alex Miller
>
> -----------------------------------------
> Signature:
> the email address this is sent from
> is may be an anti-spam defense. Ignore it
> completely.  Instead, rely on an email
> address I have already provided or
> <mailto:reply-nospam at bannerclub.com>
> removing the "-nospam"