[Dovecot] Concurrent dovecot instances on same spool?
Hi all,
While reading the "Multiple locations, 2 servers - planning questions..." thread, it just hit me that I was planning to do something that seems to be a bit hazardous...
I am setting up an high-availability server set, which consists of two (or more) servers with common disk space, all set behind redundant hardware load balancers. At first, there will be two servers and disk space will be kept on NFS server or on both servers using DRBD+OCFS2 filesystem (what creates kind of networked RAID1 storage space). This will be done mostly to keep WWW service available in case when one of servers fails.
However, if we have everything redundant, why not have the same with SMTP and POP3/IMAP? But - won't anything fail if two (or more) dovecots are accessing the same disk space, both for IMAP/POP3 and LDA/LMTP?
If it is possible, that would be a good solution for the mentioned thread. If not - where are possible dangers, and are there any plans to make it possible in the future?
Greetings,
Jacek Osiecki joshua@ceti.pl GG:3828944 I don't want something I need. I want something I want.
On Thu, 2012-03-01 at 09:21 +0100, Jacek Osiecki wrote:
I am setting up an high-availability server set, which consists of two (or more) servers with common disk space, all set behind redundant hardware load balancers. At first, there will be two servers and disk space will be kept on NFS server or on both servers using DRBD+OCFS2 filesystem (what creates kind of networked RAID1 storage space). This will be done mostly to keep WWW service available in case when one of servers fails.
However, if we have everything redundant, why not have the same with SMTP and POP3/IMAP? But - won't anything fail if two (or more) dovecots are accessing the same disk space, both for IMAP/POP3 and LDA/LMTP?
If both servers randomly access users' mails, with NFS you'll have some trouble, with OCFS2 probably less trouble. But in both cases you'll have better performance and no problems if you use Dovecot director in both servers (install both director and backend to both servers). http://wiki2.dovecot.org/Director
On Fri, 2 Mar 2012, Timo Sirainen wrote:
On Thu, 2012-03-01 at 09:21 +0100, Jacek Osiecki wrote:
However, if we have everything redundant, why not have the same with SMTP and POP3/IMAP? But - won't anything fail if two (or more) dovecots are accessing the same disk space, both for IMAP/POP3 and LDA/LMTP?
If both servers randomly access users' mails, with NFS you'll have some trouble, with OCFS2 probably less trouble. But in both cases you'll have better performance and no problems if you use Dovecot director in both servers (install both director and backend to both servers). http://wiki2.dovecot.org/Director
Thanks, I'll probably give it a try. On the other hand, it would be nice to have a possibility to allow multiple dovecot instances to access mail spool (at cost of handling some extra file/directory locks) - a bit slower, but safe... Another question: as I assume, when you wrote about troubles it was applying to IMAP. How about LMTP/LDA? Can anything bad happen when one mailbox is being filled by LMTP/LDA from more than one server)?
Greetings,
Jacek Osiecki joshua@ceti.pl GG:3828944 I don't want something I need. I want something I want.
On 5.3.2012, at 19.25, Jacek Osiecki wrote:
However, if we have everything redundant, why not have the same with SMTP and POP3/IMAP? But - won't anything fail if two (or more) dovecots are accessing the same disk space, both for IMAP/POP3 and LDA/LMTP?
If both servers randomly access users' mails, with NFS you'll have some trouble, with OCFS2 probably less trouble. But in both cases you'll have better performance and no problems if you use Dovecot director in both servers (install both director and backend to both servers). http://wiki2.dovecot.org/Director
Thanks, I'll probably give it a try. On the other hand, it would be nice to have a possibility to allow multiple dovecot instances to access mail spool (at cost of handling some extra file/directory locks) - a bit slower, but safe...
You can safely do that with director.
Also the problem with NFS isn't locks, but caching.
Another question: as I assume, when you wrote about troubles it was applying to IMAP. How about LMTP/LDA? Can anything bad happen when one mailbox is being filled by LMTP/LDA from more than one server)?
Yes, because they're still updating Dovecot index files. You could disable LMTP/LDA index updates, but I'm still not sure if it works 100% correctly (because dovecot-uidlist is appended to).
Il 05/03/2012 18.53, Timo Sirainen ha scritto:
On 5.3.2012, at 19.25, Jacek Osiecki wrote:
However, if we have everything redundant, why not have the same with SMTP and POP3/IMAP? But - won't anything fail if two (or more) dovecots are accessing the same disk space, both for IMAP/POP3 and LDA/LMTP? If both servers randomly access users' mails, with NFS you'll have some trouble, with OCFS2 probably less trouble. But in both cases you'll have better performance and no problems if you use Dovecot director in both servers (install both director and backend to both servers). http://wiki2.dovecot.org/Director Thanks, I'll probably give it a try. On the other hand, it would be nice to have a possibility to allow multiple dovecot instances to access mail spool (at cost of handling some extra file/directory locks) - a bit slower, but safe... You can safely do that with director.
Also the problem with NFS isn't locks, but caching.
After reading a little bit, it seems that Director does the job of a decent load balancer, but in the middle instead of in front of your servers, I've limited problems with NFS by using "sticky" connections with long timeouts in my load balancer, unless they're disconnected for days, they'll always end up going through the same server for POP3/IMAP conections. Doesn't work great for the SMTP/LDA part though.
Another question: as I assume, when you wrote about troubles it was applying to IMAP. How about LMTP/LDA? Can anything bad happen when one mailbox is being filled by LMTP/LDA from more than one server)? Yes, because they're still updating Dovecot index files. You could disable LMTP/LDA index updates, but I'm still not sure if it works 100% correctly (because dovecot-uidlist is appended to).
In the rare case it does happen, NFS locking and concurrent_connections set to one has seemed to reduce my problems to a minimum..
I like the Director idea though, since it's content aware it isn't organizing connections based on port/IP, but on the the actual users, especially if it does so with the LDA, it seems like an excellent solution to collisions (I guess they're called this) ..
I wish it had been a reality when I was building my servers.
participants (3)
-
Jacek Osiecki
-
Nick Warr
-
Timo Sirainen