On 27/02/13 20:19, Nikolaos Milas wrote:

Any suggestions?

I am looking for a solution that would work in creating a failover cluster with two nodes, utilizing (two) CentOS 6 VMs, each on a different data center; this requirement makes technologies like drbd unusable (due to the inherent lack of complete link reliability between the two nodes).

Not sure how one can provide full HA between two datacenters with a single unreliable link in any case. You should arrange multiple physically independent links before you even think about doing failover

• otherwise you stand to find yourself in a sticky situation when something odd happens. DRBD "split-brain" also applies to other solutions such as clustered and replicating filesystems. It hurts like hell when your storage gets damaged and you have no way of telling what the "good" copy is.

*If* you can wire in a second circuit between the two DCs (and preferably a 3rd you will be OK for any HA scenario. Ie, one circuit for data+DRBD traffic (ideally this should be 2 circuits) and another for heartbeat/fencing etc.

That said, I've heard good things about GlusterFS but I'm still not sure I'd trust it for corporate-level offsite HA.

This kind of thing is cheap to do badly and expensive to do right.

Cheers

Alex

On 2/27/13 3:10 PM, Timo Sirainen wrote:

On 27.2.2013, at 21.19, Nikolaos Milas <nmilas@noa.gr> wrote:

...

Any suggestions?

I am looking for a solution that would work in creating a failover cluster with two nodes, utilizing (two) CentOS 6 VMs, each on a different data center; this requirement makes technologies like drbd unusable (due to the inherent lack of complete link reliability between the two nodes).

I was thinking that dsync might be a good foundation for such scenarios. dsync was meant exactly for that kind of replication. For a relatively few number of users this should work well (minus the initial bugs until they get all fixed). It's a little bit heavy operation to run dsync for each small change though, so I wouldn't necessarily use it for large systems. Then again it's mainly CPU usage, and Dovecot uses normally about 0% CPU, so maybe it's not so bad.

The other possibility that is more efficient and easier to scale to large systems is to use one of the scalable object storage backends and Dovecot's object storage plugin (commercial-only, available soon).

The idea behind both of these ways is to make it easy, cheap and reliable to do multi-datacenter replication for IMAP servers. None of the cluster filesystems can do that.

Timo, has this been tested on large systems yet? I plan on hammering a two node dsync cluster running 2.2rc2 (each node is 100 miles apart in a different data center connected via 10gb ring) with a SMTP/IMAP/POP generating bot cluster we have in our test network to see how well it scales. I will update with my findings next week when I get a chance to work on it. I have to +1 Nikolaos' sentiment for a geographically distributed mail cluster, we have been hoping for a Dovecot solution to this problem for the last few years.

Hi! I am very interested with dsync of replication and I assemble the test stand. Me one question interests. In the version 2.2rc1 tcp target for dsync was added. Somebody how to adjust it can write?

On Thu, 28 Feb 2013 08:08:50 +0100 Michael Grimm <trashcan@odo.in-berlin.de> writes:

On 2013-02-28 6:55, list@airstreamcomm.net wrote:

...

I have to +1 Nikolaos' sentiment for a geographically distributed mail cluster, we have been hoping for a Dovecot solution to this problem for the last few years.

I am using that solution over a year now. Both mail servers have been running ~500 km apart. Regular mail traffic is very low, though, only a couple of users and ~1000 mails a day.

I haven't been using such an elaborate test scenario you are describing here, but I did test dsync with huge loads of locally injected messages (100000 messages at either site, or simultaneously). Thus, I am very much interested in your stress test results simulating a real world scenario in a much better way than my more ore less lab- like scenario, only.

As Timo mentioned before, there have been bugs (especially with v2.1), but I never ever lost a single mail since starting dsync replication. Main issues have been duplicates, instead, and this is history after all those improvements Timo has achieved in v2.2.

Thus, whoever is interested in a cheap man's fail-over mail cluster with geographically distributed servers and moderate load, I would encourage to consider and test replicator/dsync v2.2, now.

Just my two cents, Michael

-- Best regards, Aleksey Tsvetkov System Administrator Company Grand Vision tel. +7(495)933-39-79, ext. 184

On 28/2/2013 9:25 πμ, Цветков Алексей wrote:

Thus, whoever is interested in a cheap man's fail-over mail cluster with geographically distributed servers and moderate load, I would encourage to consider and test replicator/dsync v2.2, now.

On 27/2/2013 11:10 μμ, Timo Sirainen wrote:

dsync was meant exactly for that kind of replication. For a relatively few number of users this should work well

Thank you Timo and Alexei for your encouraging info. This is exactly what I was thinking about. We have about 250 mailboxes (most of which are using POP3) with about 4000 outgoing / 8000 incoming mail messages per day. Normal traffic is under 5 mails (total in/out) per minute. IMHO, this sounds like a good case for dsync.

Now, where can I find directions on how to set up dsync/dovecot to work as explained, i.e. with real-time replication (for v2.2)?

Thanks again, Nick

On 28.2.2013, at 16.06, Nikolaos Milas <nmilas@noa.gr> wrote:

In any case, please provide some link with info on how to set this up correctly for continuous real-time dsync.

http://wiki2.dovecot.org/Replication