[Dovecot] No failover from director to backend?
Hi everyone,
short version: Is there no built in failover mechanism for the director service to handle a backend failure?
Long version: I have a frontend server running the director service and two backends. Due to maintenance I had to shut down one of the backends which caused connection errors for the users being directed to this backend.
I was very surprised as I expected the director to redirect these users to the remaining backend.
Am I wrong or is the director not working as expected?
Regards Patrick
# 2.1.6: /usr/local/etc/dovecot/dovecot.conf # OS: Linux 2.6.32-5-amd64 x86_64 Debian 6.0.5 auth_mechanisms = plain login director_mail_servers = 172.17.1.1 172.17.1.2 director_servers = 172.17.1.3 172.17.1.4 lmtp_proxy = yes log_path = /var/log/dovecot.log managesieve_notify_capability = mailto managesieve_sieve_capability = fileinto reject envelope encoded-character vacation subaddress comparator-i;ascii-numeric relational regex imap4flags copy include variables body enotify environment mailbox date ihave protocols = imap pop3 lmtp sieve service auth { unix_listener /var/spool/postfix/private/auth { group = postfix mode = 0666 user = postfix } unix_listener auth-userdb { user = dovecot } } service director { fifo_listener login/proxy-notify { mode = 0666 } inet_listener { address = 172.17.1.3 port = 9090 } unix_listener director-userdb { mode = 0600 } unix_listener login/director { mode = 0666 } } service imap-login { executable = imap-login director } service lmtp { inet_listener lmtp { address = 172.17.1.3 port = 24 } } service managesieve-login { executable = managesieve-login director inet_listener sieve { port = 4190 } } service pop3-login { executable = pop3-login director } ssl_cert =
Patrick Westenberg wrote:
Is there no built in failover mechanism for the director service to handle a backend failure?
No, the director's job is to keep a hash table and direct the connection for each user to its associated backend. Currently, there is no built-in backend monitoring.
In order to handle maintenance of backends, you will need the poolmon daemon, which enables/disables backends in the director depending on their availability:
https://github.com/brandond/poolmon
Regards Daniel
On 10/21/12 2:43 PM, Daniel Parthey wrote:
Is there no built in failover mechanism for the director service to handle a backend failure? No, the director's job is to keep a hash table and direct
Patrick Westenberg wrote: the connection for each user to its associated backend. Currently, there is no built-in backend monitoring.
In order to handle maintenance of backends, you will need the poolmon daemon, which enables/disables backends in the director depending on their availability:
https://github.com/brandond/poolmon
Regards Daniel Considering the intention of the director was to alleviate locking issues in a shared storage environment are there any current solutions to improving the scalability/availability of Dovecot by implementing an alternative message storage systems such as nosql or maybe object storage that could abstract away the complexity of replicating data? We would love to finally have the ability to set our mail cluster on top of a storage subsystem that can span multiple geographic regions and do away with the NFS backend.
list@airstreamcomm.net wrote:
Considering the intention of the director was to alleviate locking issues in a shared storage environment are there any current solutions to improving the scalability/availability of Dovecot by implementing an alternative message storage systems such as nosql or maybe object storage that could abstract away the complexity of replicating data? We would love to finally have the ability to set our mail cluster on top of a storage subsystem that can span multiple geographic regions and do away with the NFS backend.
Key/value object store is planned for Dovecot v2.2 and has been discussed in this thread:
http://dovecot.org/list/dovecot/2012-September/068257.html
Regards Daniel
Hi,
no one here who is able to reply to my questions?
Regards Patrick
Patrick Westenberg schrieb:
Hi everyone,
short version: Is there no built in failover mechanism for the director service to handle a backend failure?
Long version: I have a frontend server running the director service and two backends. Due to maintenance I had to shut down one of the backends which caused connection errors for the users being directed to this backend.
I was very surprised as I expected the director to redirect these users to the remaining backend.
Am I wrong or is the director not working as expected?
Regards Patrick
# 2.1.6: /usr/local/etc/dovecot/dovecot.conf # OS: Linux 2.6.32-5-amd64 x86_64 Debian 6.0.5 auth_mechanisms = plain login director_mail_servers = 172.17.1.1 172.17.1.2 director_servers = 172.17.1.3 172.17.1.4 lmtp_proxy = yes log_path = /var/log/dovecot.log managesieve_notify_capability = mailto managesieve_sieve_capability = fileinto reject envelope encoded-character vacation subaddress comparator-i;ascii-numeric relational regex imap4flags copy include variables body enotify environment mailbox date ihave protocols = imap pop3 lmtp sieve service auth { unix_listener /var/spool/postfix/private/auth { group = postfix mode = 0666 user = postfix } unix_listener auth-userdb { user = dovecot } } service director { fifo_listener login/proxy-notify { mode = 0666 } inet_listener { address = 172.17.1.3 port = 9090 } unix_listener director-userdb { mode = 0600 } unix_listener login/director { mode = 0666 } } service imap-login { executable = imap-login director } service lmtp { inet_listener lmtp { address = 172.17.1.3 port = 24 } } service managesieve-login { executable = managesieve-login director inet_listener sieve { port = 4190 } } service pop3-login { executable = pop3-login director } ssl_cert =
People already replied and pointed to poolmon. There is no built-in failure handling, because it's not possible to implement it in a way that works well for everyone. Although I think poolmon could also itself use a bit of tweaking. For example if all hosts became very heavily loaded, poolmon would now probably drop all of them immediately if one if its check connections failed.
On 29.10.2012, at 23.05, Patrick Westenberg wrote:
Hi,
no one here who is able to reply to my questions?
Regards Patrick
Patrick Westenberg schrieb:
Hi everyone,
short version: Is there no built in failover mechanism for the director service to handle a backend failure?
Long version: I have a frontend server running the director service and two backends. Due to maintenance I had to shut down one of the backends which caused connection errors for the users being directed to this backend.
I was very surprised as I expected the director to redirect these users to the remaining backend.
Am I wrong or is the director not working as expected?
Regards Patrick
# 2.1.6: /usr/local/etc/dovecot/dovecot.conf # OS: Linux 2.6.32-5-amd64 x86_64 Debian 6.0.5 auth_mechanisms = plain login director_mail_servers = 172.17.1.1 172.17.1.2 director_servers = 172.17.1.3 172.17.1.4 lmtp_proxy = yes log_path = /var/log/dovecot.log managesieve_notify_capability = mailto managesieve_sieve_capability = fileinto reject envelope encoded-character vacation subaddress comparator-i;ascii-numeric relational regex imap4flags copy include variables body enotify environment mailbox date ihave protocols = imap pop3 lmtp sieve service auth { unix_listener /var/spool/postfix/private/auth { group = postfix mode = 0666 user = postfix } unix_listener auth-userdb { user = dovecot } } service director { fifo_listener login/proxy-notify { mode = 0666 } inet_listener { address = 172.17.1.3 port = 9090 } unix_listener director-userdb { mode = 0600 } unix_listener login/director { mode = 0666 } } service imap-login { executable = imap-login director } service lmtp { inet_listener lmtp { address = 172.17.1.3 port = 24 } } service managesieve-login { executable = managesieve-login director inet_listener sieve { port = 4190 } } service pop3-login { executable = pop3-login director } ssl_cert =
participants (4)
-
Daniel Parthey
-
list@airstreamcomm.net
-
Patrick Westenberg
-
Timo Sirainen