Hello there everyone,

I have 2 postfix servers running in different geographical locations which save mails onto a shared storage using glusterfs. I use maildir on both of them and one to one replication so the mail data stay consistent on both nodes.

Now's the hard part. I was thinking initially that I'll use dovecot imap both of them and it does not matter to which node I am connecting because in theory I should see same mails (as they are saved on the glusterfs level). The problem is that when I have 2 imap servers running simultaneously they both create some lock files and both of them want to create same files.

How then, can I accomplish my task of having a redundant-geo-imap solution where I could access my mails regardless of which server is up? Maybe my approach is wrong and I should do that differently? Any kind of help is highly appreciated.

P.

P.s. Don't worry about the traffic between servers, I've got it figured out.

active - active clustering requires lock managers (state manager) that work across nodes (in general). So, either the application can handle that or it can't. In the case where it can't, what you need is to deploy a active - passive clustering.. that is, one node is in a dormant state with regards to areas requiring statefulness and becomes live when the other node fails (which in turn needs to be STONITH'd to keep it down usually). In the case where you can't keep a node "down" after fail, often times it's possible to at least force a boot/reboot into a failure state that at least keeps the node from brining up the common service and using the stateful areas (e.g. disk for example).

Btw.. in a active - passive config, sometimes you don't need a cluster filesystem. For example if "state" is written to disk (e.g. lock files), then a disk could be mounted (e.g. let's say a SAN or NAS disk) to only the live node running the active service. Then when failed (and left in a "failure state"), the other node comes up and mounts the disk. Does that make sense? Anyway.. it's actually fairly common to do this sort of thing when there is no distributed locking mechanism available for a service being clustered.

What you lose is that GEO feature where you want to hit active - active services based on region. The only solution there is to make sure the service can actually be run in a active - active cluster configuration. If not, you may want to look at alternative service applications that are cluster aware.

Sometimes a disk locking scenario is as simple as having different configs for the service on each node such that the locks are kept in different locations (and possible the elements being locked)... in other words, you have to partition the service applications. Sure.. it's more like having two completely different installations at that point, but depending on the scenario, there still might be some benefit.

I've seen a LOT of active - active scenarios that truly were NOT... so be careful. Examine everything.. do not make assumptions.. and I think you'll be fine. There is no "magic" to solve every service out there and make them active - active aware.

oh.. and finally, since a lot of software is FOSS... if it's not cluster aware, you could always try to make it cluster aware (can be hard though).