1

Topic: Can DBMail work for georedundancy?

I am planning to install iRedmail with SoGo on two new vServers (OpenVZ CentOS 7) which are in different datacenters / different cities.

I do not want to create a setup with a simple MX backup since that would only ensure mail delivery when a server is down and wouldn't help in a critical event where the primary server is lost.

When I replace Dovecot with DBMail from my understanding everything from configuration to mail data incl. attachments should be stored in MariaDB. When I setup a Master-Master sync of MariaDB between the two servers then both servers should contain the full setup and any one server could fail without loosing any functionality.

Since KeepAlived, HAProxy, etc. will not work with geographic redundant locations and the inability to route one ip to both hosts I plan on using cheap DNS round robin. I know DNS RR can have issues when a DNS cache has the IP stored which is down etc., but I am not looking into high performance failover but rather a fully functioning server in the case of a disaster to keep services running within 24 hours max.

So what do you think? Basically there are two questions out there:
- What's the probability of breaking future iRedmail upgrades when switching from the default Dovecot to DBMail?
- Will a Master-Master sync in combination with DNS round robin work with iRedmail and is there really no data left to be synced when DBMail is used except maybe config files?

----

Spider Email Archiver: On-Premises, lightweight email archiving software developed by iRedMail team. Supports Amazon S3 compatible storage and custom branding.

2

Re: Can DBMail work for georedundancy?

Chrissicom wrote:

So what do you think?

It should work well.

Chrissicom wrote:

- What's the probability of breaking future iRedmail upgrades when switching from the default Dovecot to DBMail?

It breaks many features in iRedMail since iRedMail heavily relies on Dovecot and its own SQL structure ("vmail" sql db).

Chrissicom wrote:

- Will a Master-Master sync in combination with DNS round robin work with iRedmail and is there really no data left to be synced when DBMail is used except maybe config files?

You're correct.

3

Re: Can DBMail work for georedundancy?

Just a personal warning message: DBMail is not under active development for few years. so, switching to DBMail is a risk (of course you have your own opinion). That's why i stopped developing web admin panel for DBMail.
http://dbmailadmin.org

4

Re: Can DBMail work for georedundancy?

ZhangHuangbin wrote:

Just a personal warning message: DBMail is not under active development for few years. so, switching to DBMail is a risk (of course you have your own opinion). That's why i stopped developing web admin panel for DBMail.
http://dbmailadmin.org

Thanks for the warning and this will indeed stop me from choosing this path.

I can still sync settings via MariaDB Master-Master replication but as long as vmail is a directory on storage I need to find a way to sync storage between the servers.

Maybe you have some ideas?

GlusterFS and similar solutions will not work, because they all assume that you have physical machines (I am running on OpenVZ vServers) and/or machines on the same subnet which isn't the case for me.

Of course I could do a cronjob with rsync, but I think that will be riddled with mistakes. Rsync would be no near real-time sync and it would also require that only one server handles the emails as I don't think a two-way rsync would work.

5

Re: Can DBMail work for georedundancy?

Chrissicom wrote:

but as long as vmail is a directory on storage I need to find a way to sync storage between the servers.

Use Dovecot Replication for INSTANT, 2-way mailbox sync:
https://wiki2.dovecot.org/Replication

6

Re: Can DBMail work for georedundancy?

Wow, why didn't I find this earlier big_smile the description looks just like what I need

Dovecot supports master/master replication using dsync. It's recommended that the same user always gets redirected to the same replica, but no changes get lost even if the same user modifies mails simultaneously on both replicas, some mails just might have to be redownloaded. The replication is done asynchronously, so high latency between the replicas isn't a problem. The replication is done by looking at Dovecot index files (not what exists in filesystem), so no mails get lost due to filesystem corruption or an accidental rm -rf, they will simply be replicated back.

Hmmmm, hmmmm now I am really thinking what to do, because in the meantime with the support of my hoster loading the fuse kernel module in OpenVZ I was able to get GlusterFS running, but GlusterFS replicated volumes are synchronous and prone to failure on high latency. I have latency about 3.5 ms right now, but you never know and the description of dovecot replication also seems to be much easier. I will look into this. Thank you!

7

Re: Can DBMail work for georedundancy?

Chrissicom wrote:
ZhangHuangbin wrote:

Just a personal warning message: DBMail is not under active development for few years. so, switching to DBMail is a risk (of course you have your own opinion). That's why i stopped developing web admin panel for DBMail.
http://dbmailadmin.org



I can still sync settings via MariaDB Master-Master replication but as long as vmail is a directory on storage I need to find a way to sync storage between the servers.

Maybe you have some ideas?

GlusterFS and similar solutions will not work, because they all assume that you have physical machines (I am running on OpenVZ vServers) and/or machines on the same subnet which isn't the case for me.

I can recommend GlusterFS to do that, and also there are a couple of options too:
IPFS (relative new, uses DHT)
SSHFS (filesystem over SSH basically)
Or just another server where the two instances mounts the vmail catalogue over NFS.

8

Re: Can DBMail work for georedundancy?

Chrissicom wrote:

but you never know and the description of dovecot replication also seems to be much easier.

The setup is very easy - especially sync with ssh.