There have been various attempts to set up a highly available IMAP system using a wide variety of solutions without much verified success. Dovecot provides a solution for this (dsync) but appears to be theoretical. Dovecot mailing lists have reports of difficulty without much in the way of solutions. Curious if anyone here has any comments about doing this and if ispconfig has anything to offer. We've run ispconfig multi server setups in the past successfully but primarily for web server, not mail. Also, synchronization of data between the servers had to be done by rsync or something similar. One determined fellow apparently put a great deal of effort into this and ended up with a solution involving syncthing somehow. Would be interested in any comments or ideas as far as achieving a highly available imap system where the member servers are geographically distant and connected by WAN. Much appreciated.
I run this myself and have described it in the multiserver guide: https://www.howtoforge.com/tutorial/ispconfig-multiserver-setup-debian-ubuntu/
Thanks very much Thom, this is great to see! May I ask how many accounts have you had success with this setup keeping in sync? And is this a fairly busy setup? Do you use or recommend a VPN between the two mail servers or is some form of ssh tunneling employed? Should one server become unavailable is the idea to manually make a dns entry change in order for the imap clients to connect to the other server or is there some other more elegant method with this setup? Also, after a mail server comes back online after an outage have you found this setup to reliably bring that server up to date or is some sort of administrator intervention needed? Much appreciated.
See https://doc.dovecot.org/configuration_manual/replication/ for more info. I haven't experienced problems with larger setups so far. The servers are on the same private lan network (but in 2 separate DC's). Use a highly available load balancer. Let the e-mail server hostnames point to that load balancer and let that distribute the traffic over the online servers. Yes, without any trouble.
Thanks for your collaboration, Thom, I very much appreciate it. Would you mine sharing how many users and # of messages per day you've run on such a setup stably? My concern is the long-term viability and scalability of such a setup. The determined fellow I mentioned earlier who has written about this you can see here: https://www.reddit.com/r/linuxadmin/comments/egzdik/dovecot_multi_master_cluster/ (see fragtionza) comments from 2 yrs ago It appears this same person posted about his solution here as well: https://github.com/fragtion/dovecot-core/issues/27 (see fragtion's comment on Jun 24 2020 & TCB13 reply the same day) My concern is this (and others) reporting instability and CPU spikes and performance issues about 50 users for example. Regarding the load balancer, while this makes sense, this makes the load balancer the single point of failure. I would be interested in strategies providing a no-SPOF solution. Thanks again.
On a setup I recently set up for a client there were a few hundred users, probably 200-300 messages / hour. Haven't heard any complaints or seen any issues. That's why you need a highly available load balancer. This means the load balancer is always available on multiple physical instances in separate availability zones. Should one of them fail, the other one takes over.
Good to know on the number of users, we will give it a go. May I ask what highly available load balancer you've found to be a good fit for this and whether outsourced or using the public cloud, etc? Thanks
There are several out there, the ones I have used so far where hosted by the same company that hosts the servers for the client. They only support a load balancer for their own systems. Who's your hosting provider?
another alternative to using load balancers, is to provide both mail servers public ip's for eg imap.domain.tld dns A records. and let dns responses effectively round-robin the provided ip. may be an issue with session info, windows clients may be fine, should just keep connecting to the same ip for quite a while, due to dns caching, linux / mac may be more of an issue. replicated redis servers for session data would resolve that, but again, the increased complexity / hassle is probably more effort that it's worth.
