[Dovecot] [ Re: best practises for mail systems]

[Michescu Andrei]

Hello,

> I agree, in practice this is not an issue compared to the unavailability
> of the service, but on longer IMAP sessions (e.g. transferring a big
> file) the connection loss is noticeable.

It is noticeable for somebody that really waits for a large email. For the
standard user there is nothing visible because the synchronization starts
/ fails and starts again...

In corporate environment the servers are "close" and the network is
generally configured to have proper Destination Unreachable.

For road-warriors, the main concern is the uplink/downlink and generally
not the couple of seconds lost due to time-out.

For the DNS... use "fast-flux"-like configuration and any proper resolver
will behave correctly (at least in my experience).

For the road-warrior setup: DNS with geoip, and all locations with
split-dns (internally HA setup with failover on external locations).

Unfortunately the classical HA setup (with heart-beat monitor, update DNS
etc etc) it is not designed to be "internet-proof" (internet like in WAN).
The initial design of the internet was to be able to operate even when
significant segments are unavailable.

Picture the following scenario: master servers on each continent.
Catastrophic failure of the trans-continental network => 5 big
disconnected chunks of network fully functional. Any HA setup that I saw
will fail miserably. The simplest design with fully replicated masters
will continue to work.

Obviously planning for the scenario above is an overkill for most of the
companies out there. Once you trow in the advantage of have the emails
close to you anywhere where you go, then it starts making sense.

And you can top it up by segmenting you user base to replicate only the
users that are on the go, or are important enough.

As for the current status of the ideal implementation: waiting for Timo to
finalize the refactoring of dsync.

As a temporary solution: rsync replication with master-slave model (not
master-master).

This design makes sense to us, but I'm sure that it is under-optimal for
most other uses.

Andrei

>
>> Like this you have no SPOF and no split-brain and you get the
>> flexibility
>> (if needed) to geographically distribute your servers in the the future.
>>
>> Keep each server with its own ip, connect to them via DNS (round robin
>> etc
>> etc).
>
> This depends on the resolver, operating systems and clients you want to
> support, because I read that not all networks generate proper
> ICMP/ICMPv6 Destination Unreachable messages and instead simple drop the
> packets, so that the clients first try to connect to the failed server
> until timeout and then connects to the second server. Since IMAP is a
> stateful protocol the latency of the initial connect to the failed
> server can be ignored, but if you want to eliminate this, you can use
> dynamic DNS to automatically remove the corresponding RRs (depending on
> your situation you need an external monitoring server for this to avoid
> problems in case of net splits).
>
>> We are currently experimenting with a setup similar to this one, but
>> with
>> geographically distributed servers (trans-continental) (bandwidth
>> limited
>> and high cost).
>
> I also have some plans for a similar setup in the near future. Can you
> share your results on the mailing list? I'm especially interested if
> failover via DNS works in practice (I did some searches, but I'm not
> fully convinced of it, but it seems quite simple compared to other
> solutions).
>
> Regards,
> Matthias-Christian
>
> !DSPAM:4fce5ae0149132093961185!
>
>