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

[Timo Sirainen]

On 27.2.2012, at 18.54, Charles Marcus wrote:

> 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?

I'll initially build it for only 2 locations, but I think it will be pretty simple to scale to more than 2.

> 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?

Synchronous drbd replication for a master/slave setup should also work, since the latency between your servers is probably quite low. I wouldn't use asynchronous replication since it can lose some of the last changes when failure happens.

Then there are of course all the cluster filesystems, but I don't have much experience with them other than what I've read in this list. I think GPFS is the only one I haven't read any complains of (but it could be also that so few people have actually used it).

> 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?

With a clusterfs setup you could do this. With dsync-replicated setup you could assign a primary location for the user, and proxy the connection there if user got connected to wrong server, except when the primary server is down.

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

Like other mentioned, I don't think the cross-office traffic will be that much of a problem, especially for external connections from outside office. For internal connections you should be able to mostly avoid it.