[Dovecot] Multiple locations, 2 servers - planning questions...

[Charles Marcus]

Hello all/Timo,

Up until now, my main Clients office has consisted of a single location, 
and I have never had to deal with the situation of multiple locations 
for a single company.

They have just told me that they are acquiring an additional floor at a 
building that is about 4 minutes away - but obviously far enough away 
that I now have to deal with supporting users in the same domain but at 
two disparate physical locations.

These two locations will be connected via a private Gb ethernet 
connection, and each location will have its own internet connection (I 
think - still waiting on some numbers to present to the owner to see 
what he wants to do in that regard, but that will be my recommendation), 
so bandwidth for replication won't be an issue.

I have a couple of months to get this done, and I am already planning on 
hiring Timo's new commercial support company to help with the final and 
actual design and implementation, but obviously first I need to know 
what my actual options are.

Just a rough idea of what I'd like to do is:

1. Set up one dovecot server at each location (these will be VMs), so
    users at each location are accessing the local server for that office

2. Full replication between the two for the mail/indexes, and configure
    them such that each can act as a failover for the other in case one
    goes down for whatever reason

This is my first/main question...

I recall that 'dsync based replication' is actually on the map for 2.1, 
but, since apparently dsync can't do this now, Timo, do you have even a 
rough idea how much work this would be to get it working for only 2 
locations (assuming it *may* be easier to get the initial support for 
only 2 locations, my client may be willing to pay for it if it isn't a 
huge amount - feel free to reply privately to this question), then you 
could revisit it later to make it more scalable? Or, if it is going to 
take more work than my client is willing to pay for (I'm hoping not, 
since you said it was on the map for 2.1, not 2.2+), maybe the notify 
plugin could be leveraged in some way to provide something 'close 
enough' until it is fully implemented in dsync?

On that note (something 'close enough' until dsync fully supports this 
natively), would setting up a dsync cron job, say, every 5 or 10 
minutes, be asking for trouble? Our mail server is not all that busy, 
really, so in 5 or 10 minutes, there wouldn't be many changes at all.

If that is not recommended, although I want to avoid the hassles of NFS 
if at all possible, maybe there is another shared filesystem that will 
work ok - or... since I will be forcing users to a single server always 
anyway, maybe NFS or some other shared filesystem is really the best 
option here, and just let it take care of the syncing?

and

3. Configure things such that each offices users are directed to the 
local server for that office, but connections will fail-over to the 
remote server in the case of one of them going down for whatever reason?

I'm fairly sure that some combination of Dovecot Proxy/Director will 
accomplish this, but one concern is - for internal users, my 
understanding is it will redirect them via the private IP, but that 
would result in lots of traffic across the Gb connection between  the 
two locations, and I'd like to eliminate that if possible - so how will 
this work when they are accessing it from outside the office, where each 
office has its own public IP? I'd prefer to not rely on users using the 
correct hostname (currently, we just use 'mail.example.com', and I know 
I could set up two new ones - office1.example.com and 
office2.example.com - but then I'd be relying on the users to get it 
right, and I'd prefer to avoid that can of worms). I guess a worst case 
scenario (if there is no better way) would be to do it that way, then 
watch the logs for users who get it wrong and are using the inter-office 
connection, and deal with them on a case by case basis.

Thanks to any/all for reading this far and for any thoughts, suggestions 
and/or ideas...

-- 

Best regards,

Charles