dovecot - Jun 2012 - [ Re: best practises for mail systems]

Hello,

If disk space and bandwidth are affordable (and from your setup it seems
that they are affordable as you have everything locally) I would split the
mail storage completely and use replication in between n-master servers
(n=2 for your case).

The replication is not yet fully tested, but Timo is actively working on
this feature.

The fear of lossing the imap session does not make sense (at least to me)
as the client will reconnect automatically in the background.

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).

We are currently experimenting with a setup similar to this one, but with
geographically distributed servers (trans-continental) (bandwidth limited
and high cost).

Best regards,
Andrei
> We once try to use similar solution as your first.
>
> 3 servers for LVS -HA
>
> This master server redirect users for 2 or 3 dovecot backends..
>
> The mail storage were maildir ontop of OCFS2
>
> Our problem were that OCFS2 were too slow. We could not handle many users.
>
> So we took an step back and now use only user one server.
>
> But still thinking in go back to the first one. with LVS
>
> When using LVS try to sticky user to the same backend, LVs can do ths by
> source ip.
>
> Where i work we have problens on testign storage. If you have any advices
> for testing disk performance, i will be thankfull.
>
> I wil be glad to answer anything else.
>
> []'sf.rique
>
>
> On Tue, Jun 5, 2012 at 9:59 AM, ???????? ????????? ?????????? <
> a.kostyrev at serverc.ru> wrote:
>
>> I think LVS is just fine and it is not a SPOF 'cause it is actually
2
>> servers:
>> active master --> and standby slave.
>> LVS supports real time replication of connections from master to slave,
>> so if master dies slave knows which IP was connected to which dovecot
>> server.
>>
>> I'm more worried about right design of mailstorage.. should I use
some
>> cluster fs with all mail of all users
>> or should I split mailstorage across servers and somehow avoid long
>> downtime if one of servers goes down.
>>
>>
>> -----Original Message-----
>> From: dovecot-bounces at dovecot.org [mailto:dovecot-bounces at
dovecot.org]
>> On
>> Behalf Of Matthias-Christian Ott
>> Sent: Tuesday, June 05, 2012 11:28 PM
>> To: dovecot at dovecot.org
>> Subject: Re: [Dovecot] best practises for mail systems
>>
>> On 2012-06-05 05:14, ???????? ????????? ?????????? wrote:
>> > On each host system we created one VM and passed through 3x2TB
disks
>> into it.
>> >
>> >
>> >
>> > In guests vms on top of this disks we made XFS and fired up
glusterfs
>> with distributed replicated volumes for our mailstorage.
>> >
>> > so it looks like this:
>> >
>> >
>> >
>> > vm1    replicate     vm2
>> >
>> > disk1 ------------> disk4
>> >
>> > disk2 ------------> disk5
>> >
>> > disk3 ------------> disk6
>> >
>> >
>> >
>> > in each vm we mounted glusterfs and pointed dovecot to that dir
for
>> mail
>> creation (as ltmp) and imap4 user access.
>> >
>> > also we use exim as smtp.
>> >
>> >
>> >
>> > So, with glusterfs as mailstorage we can go for LVS to load
balancing
>> for exim and dovecot.
>> >
>> > so wherenever one of host systems (hence one of mail vms) goes
down,
>> users don't notice that
>> >
>> > 'cause LVS points them to working smtp and imap4 servers
>> >
>> > and they get their mail 'cause of glusterfs.
>> > [...]
>> > Cons:
>> >
>> > - not quite sure if glusterfs is production ready solution
'cause I've
>> experienced split-brains during setting it up
>> >
>> > - IO performance issue. Though we didn't yet run any io tests,
but
>> glusterfs uses fuse to mount on clients. And guys on #gluster told me
>> writing to the glusterfs mount will not be strictly local io.
>>
>> I'm not familiar with LVS, but from the project description it
seems
>> that you need a "front server" that does the load balancing,
so you
>> either have to run at least two of these servers in parallel or add to
>> your cons that you introduced a single point of failure. But you
>> mentioned that you only have two servers, so you really can do this.
>>
>> I would rather ensure high availability by running the two servers as
>> masters and using either IP address takeover or DNS failover (with
>> dynamic DNS) and either use Dovecot's replication (I haven't
tested it
>> yet and I'm not sure what happens in case of IP address takeover)
or a
>> file system that can handle these kinds of errors (e.g. Coda). You
could
>> do load balancing via round-robin DNS. This only protects you against
>> the failure of single machine and because IMAP sessions are not
>> replicated between the servers, connections will get reset if one
server
>> fails, but it's cost-effective and uses software that already
exists.
>>
>> Regards,
>> Matthias-Christian
>>
>
>
> !DSPAM:4fce037e104291424646138!
>

On 2012-06-05 17:33, Michescu Andrei wrote:
> The fear of lossing the imap session does not make sense (at least to me)
> as the client will reconnect automatically in the background.
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.
> 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