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.
