Re: [Dovecot] No failover from director to backend?
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 = > ssl_key = > protocol !smtp {
>> passdb {
>> args = proxy=y nopassword=y starttls=any-cert
>> driver = static
>> }
>> }
>> protocol smtp {
>> passdb {
>> args = /usr/local/etc/dovecot/dovecot-sql.conf.ext
>> driver = sql
>> }
>> userdb {
>> args = /usr/local/etc/dovecot/dovecot-sql.conf.ext
>> driver = sql
>> }
>> }
>> protocol lmtp {
>> auth_socket_path = director-userdb
>> }
>
Re: [Dovecot] No failover from director to backend?
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 =
Re: [Dovecot] No failover from director to backend?
l...@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 -- https://plus.google.com/103021802792276734820
Re: [Dovecot] No failover from director to backend?
On 10/21/12 2:43 PM, Daniel Parthey wrote: 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 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.
Re: [Dovecot] No failover from director to backend?
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 -- https://plus.google.com/103021802792276734820
[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 =
