Redundant and Geobalancing setup

[Daniel Tröder]

On 02/13/2016 04:00 AM, Cedric Malitte wrote:
> Hi,
> 
> I use dovecot for a long time now, but only as a single isolated server
> each time.
> 
> I joined a company a few years back. We had trouble with compagnies hosting
> our mail, supposedly full redundant and so on.
> 
> The company is small, but we have many dealers around the world, and it's
> growing.
> 
> Mail became the fist choice for clients to contact the dealers.
> No mail, and we loose sales.
> 
> For now we have a single server ( with a backup ) on east coast.
> And sometimes peoples from EU complain about speed.... ah users :)
> 
> What I'd like to implement is a redundant system with 2 servers, one in NA,
> one in EU.
> And I'd also like to be able to add another server if needed on the west
> coast.
> 
> Idea is, that if a server goes down, the users will be able to still
> receive and send mails, and never loose mails.
> 
> For geobalacing and failover, I read that I can do it with DNS ( I'm with
> easydns ).
> 
> I'm at the first stage where I collect informations that I try to
> understand and foresee a solution.
> 
> First idea is to set up servers with a mysql master, slaves and a glusterfs
> in replica mode on the servers.
> I tried glusterfs on FreeBSD and OMG, it's slow as hell ! ( well maybe it's
> a trouble on the VMs nics )
> On centos it's way better.
> But I read there might be trouble/index corruption for the mail storage on
> "shared" space using maildir.
> 
> I also had a look at dsync, but I wonder if it can be used on more than 2
> servers.
> 
> I found many pages on dovecot clusters using shared storage NFS mounted,
> but I feel it's not really what I need as the servers will be in different
> datacenters.
> 
> So any guide, clue hint would be really appreciated for me to do my
> homework !
> 
> Regards.
> 
> Cedric

Hi Cedric,

I think a simpler solution will not just be cheaper but less complex -
and with that more reliable:

The speed problem of the EU users is probably just feeling. You should
quantify it for both SMTP and IMAP. Collect that data for the scenarios
that your users complain about (is it to a partner or inter-office?).
Only then can you work on a solution that you will be able to prove to
them, is better. This is paramount.

My suggestions:
* Server on the east cost is good for both NA and EU.
* Good (better?) internet connection for the EU office, prioritize SMTP
vs HTTP in router/firewall (fast internet is WAY cheaper than cluster
setups plus administrators)
* SMTP relay in EU _office_, so that _sending_ mails is with LAN speed
for users

Create a redundant setup for SMTP and IMAP together on the east cost.
You'll get redundancy without the WAN problem.

Setup a secondary MX in a different data center for uber-redundency. It
will not enable your users to read their mail in case the 1st data
center is on fire, but no client mails will get lost, as they will be
queued on the 2nd MX - better read client mails late then never!

Setup a clone of the primary server at the 2nd MX and sync mails &
backup there on a hourly basis. If the 1st data center is not back in an
hour, you can still switch DNS to the 2nd site and your users will have
had a very short downtime.

The result is not a top-notch 100% solution, but it is simple and
everything is implemented on application layer. That gives you freedom
to switch products, hardware, platform and administrators(!).

Ask your customer/supervisor what uptime is necessary and how much they
are willing to pay. The SLAs of MS/Google/etc offer up to 99.9% (~9
hours downtime per year). If that is the goal, then they should pay the
price for their equipment and staff. For anything less my argument is
less complexity for higher reliability.

Greetings
Daniel

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://dovecot.org/pipermail/dovecot/attachments/20160215/11f1e694/attachment.sig>