Re: dovecot director and keepalived
On 15/3/2021 9:11 μ.μ., Aki Tuomi wrote: On 15/03/2021 20:54 Paterakis E. Ioannis wrote: On 15/3/2021 6:09 μ.μ., Steven Varco wrote: Hi John Thanks for you input. So you basically state that („physically“) separating the director servers from keepalive/haproxy servers is the only option? I would like to avoid setting up two additional machines for that whenever possible, as any node more in the chain potentially is another point of failure… ;) Nope, it's not the only option. You can always have all three daemons (keepalived/haproxy/director) on each machine. Keepalived will handle the floating ip job, haproxies will have no problems with the floating ip, the directors will always be binded to the static ips of the machines and have their setup in the haproxies. That's all. But, if you plan to make a Highly available environment, u have to consider splitting your services to different VMs, and them to different hypervisors in order to be as Highly available as you can John The point of dovecot director is that it acts as a proxy that always routes users to same backend. You can use keepalived, if it supports external commands, to maybe tell director which backends are up / down. It's not keepalived's work to tell the directors which backend is up/down. You can use poolmon for that. keepalived will make sure the floating ip will always be assigned on an alive haproxy. Then it's haproxies' work to check the aliveness of directors. Then It's Directors job to assign the users to the same dovecot backend all the time, and so on Don't mix things. J
Re: dovecot director and keepalived
On 15/3/2021 6:09 μ.μ., Steven Varco wrote: Hi John Thanks for you input. So you basically state that („physically“) separating the director servers from keepalive/haproxy servers is the only option? I would like to avoid setting up two additional machines for that whenever possible, as any node more in the chain potentially is another point of failure… ;) Nope, it's not the only option. You can always have all three daemons (keepalived/haproxy/director) on each machine. Keepalived will handle the floating ip job, haproxies will have no problems with the floating ip, the directors will always be binded to the static ips of the machines and have their setup in the haproxies. That's all. But, if you plan to make a Highly available environment, u have to consider splitting your services to different VMs, and them to different hypervisors in order to be as Highly available as you can John
Re: dovecot director and keepalived
On 14/3/2021 6:52 μ.μ., Steven Varco wrote: Hi All I’m trying to establish a dovecot HA setup with two loadbalancers, running keepalived for sharing a virtual public IP. On the same machines I’m running a dovecot director which proxies the requests to two underlying mail servers (on seperate machines). Now I’m hitting the issue with the way director determines his „Self IP“ by trying to bind to all configured director_servers IPs, taking the first one possible. Each Director has to listen only on the static IP address of each machine. Then you have to configure the 2 directors in the HAproxies. The floating ip with keepalived will work along with the 2 HAproxies. However this approach only works, when the sysctl setting is: net.ipv4.ip_nonlocal_bind=0 On the other side keepalived needs net.ipv4.ip_nonlocal_bind=1 in order to bind the VIP. You don't have to mess with these settings. Other possible solutions I could think about: - Configure each director as „independent“ by setting only one IP in director_servers. => With this aporach you would loose the user to mailserver mapping, although only in a a case of a failover on the loadbalancer, which might can be neglected (or are there any other fallbacks?) The two directors have a connection to each other, so both know at the same time where's a user mapped. You don't have to worry about that. The user->dovecot mapping will work without any problems even if there is a failover. - Putting director on seperated intermediate machines and proxing the requests through haproxy on the keepalived servers (keepalived -> haproxy -> director -> IMAP => Besides the disadvantage of having another bunch of servers in the chain, also some special configuration on the directory servers might be neccessary to assure director works neatly with haproxy. The identical scenario will be to have keepalived along with haproxy on same machine, and directors on another. But can work with all three on the same as well. I use the keepalived, haproxy on two machines, with 2 directors underneath each one on different machine/hardware for the high availability's sake, and below them there are 3 dovecot servers. So 2021, what is the „correct“ (best practive) way of having a reduntant HA setup for dovecot? Cheers :-) John
Re: Dovecot Director scaling / performance
From my short experience, we run 2 directors and 3 dovecot servers behind them, with approx. 800 concurent users/dovecot server without any problems. During peak times, they go as high as 2000-2200 users/dovecot server, again without any problems. These 2 directors are behind a haproxy, so i'd say each director handles at approx. 1200-3500 concurent connections without problems. You may face problems with limitations on your OS if you plan to serve such an amount of users though. It depends on the OS you use. i hope this helps, John On 15/12/2020 13:25, t...@linux-daus.de wrote: Hi, currently i'm going to evaluate the Dovecot Director. Are there someone with experience how the Dovecot Director does scale? The last current information i could find was a post on this mailing list from 2012: 4 Directors are well known, >75 are too much. Are there any more up to date experience regarding how many user (current and new/s) a single Dovecot Director/proxy node could handle and how many director nodes in a ring are known to work (well)? Best regards, Tim
Re: Directors and LMTP: mailAlternateAddress of same user [solved]
On 26/10/2020 8:54 π.μ., Vincent Brillault wrote:
Dear Ioannis,
I've searched around for a solution to this, and figured out that a special
userdb {} section in the protocol lmtp {} section, with driver = ldap etc etc
so that i 'd be able to "show" the correct user to the lmtp might work, but
strangely that userdb {} setting looks like being ignored by lmtp.
A very similar issue was discussed on IRC last Friday. userdb is indeed
ignored on the director, as the different process are going through the
special "director-userdb", which has nothing to do with the userdb you have
define... The documentation
(https://doc.dovecot.org/configuration_manual/authentication/user_databases_userdb/)
was updated to make it cleaner.
The solution is to use passdb instead. Use basically the same configuration as
the one you have for userdb but for passdb. For the ldap configuration itself
replace user_* by pass_*.
Dear Vincent hi,
thank you very much for your reponse. I'd already tried the passdb {}
section, but i've missed the replacing of the user_* attributes in the
ldap .ext file. Index corruptions are gone now!
Cheers
Ioannis
Directors and LMTP: mailAlternateAddress of same user
Good evening everyone,
I'd like to paste a problem i experience the last days with a mail
cluster system based on three dovecot servers and two directors in front
of them. The Directors are proxying the auth requests to the dovecot
servers below (LDAP). The protocols i use are imap/managesieve/lmtp.
The setup works as intented, exept one detail. There are a lot of users
that happen to have mailAlternateAddress attriutes with different e-mail
addresses. The problem is that when a mail arrives to the lmtp of the
directors, and the recipient is one of the mailalternateAddresses the
same user has, director/lmtp doesn't recognise the real user of that
e-mail address, and routes the e-mail to a different dovecot server than
the real user is logged in, resulting in a corrupted .index.cache file.
I've searched around for a solution to this, and figured out that a
special userdb {} section in the protocol lmtp {} section, with driver =
ldap etc etc so that i 'd be able to "show" the correct user to the lmtp
might work, but strangely that userdb {} setting looks like being
ignored by lmtp.
Has any of you guys have an idea how will i be able to solve that issue
because i get thousands of corrupted .index.cache files every day
Thank you very much in advance,
Ioannis
