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. 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. The last topic on that is dating back to 2016 (https://dovecot.org/pipermail/dovecot/2016-August/105191.html) with references to 2012 (https://www.dovecot.org/list/dovecot/2012-November/087033.html) and no solution posted so far. After five more years :D, I?m asking myself if we finally have a solution for that, or if my approach of achieving clustered director servers is potentially wrong? 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?) - Only have director running on the currently active loadblancer node and stopped on the passive loadblancer node (would possibly have the same effects as above). - 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. So 2021, what is the ?correct? (best practive) way of having a reduntant HA setup for dovecot? This means a MUA connects to one public IP and gets connected to (preferably the same) IMAP Server, no matter which machine in the whole chain might be down? PS: Using just multiple A records on the mail domain name (round-robin), while working perfectly for SMTP is not accepatbl for IMAP IMHO, as in case of a failure every second request from the client (MUA) would fail and most MUAs are not automatially reconnecting again in that case. thanks, Steven -- https://steven.varco.ch/
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
Am 14.03.21 um 17:52 schrieb Steven Varco:> 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. > > 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. > > The last topic on that is dating back to 2016 (https://dovecot.org/pipermail/dovecot/2016-August/105191.html) with references to 2012 (https://www.dovecot.org/list/dovecot/2012-November/087033.html) and no solution posted so far. > > After five more years :D, I?m asking myself if we finally have a solution for that, or if my approach of achieving clustered director servers is potentially wrong? > > 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?) > > - Only have director running on the currently active loadblancer node and stopped on the passive loadblancer node (would possibly have the same effects as above). > > - 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. > > > So 2021, what is the ?correct? (best practive) way of having a reduntant HA setup for dovecot? > > This means a MUA connects to one public IP and gets connected to (preferably the same) IMAP Server, no matter which machine in the whole chain might be down? > PS: Using just multiple A records on the mail domain name (round-robin), while working perfectly for SMTP is not accepatbl for IMAP IMHO, as in case of a failure every second request from the client (MUA) would fail and most MUAs are not automatially reconnecting again in that case. > > thanks, > Steven >hi ,i had this long time ago https://blog.sys4.de/tag/keepalived.html but dovecot has some new stuff since then, you might combinate them with keepalived which worked extrem good -- [*] sys4 AG http://sys4.de, +49 (89) 30 90 46 64 Schlei?heimer Stra?e 26/MG, 80333 M?nchen Sitz der Gesellschaft: M?nchen, Amtsgericht M?nchen: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein
Hi Steven, On 14/03/2021, 17:53, "dovecot on behalf of Steven Varco" <dovecot-bounces at dovecot.org on behalf of dovecot.org at bbs.varco.ch> wrote:> 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. > > 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.This can be fixed by specifying the IP address of the director in the inet_listener section of the director service, like this: service director { ### other configuration here ### inet_listener { address = 172.20.1.4 port = 9090 } } The listener address will be used as the 'self IP' of the director. This also means that each director will have a slightly different configuration file, but that should usually not be a problem. I got this from skimming the source, afaict it is not documented anywhere so I'm not sure if this behavior can always be relied on in future releases (it does seem logical to me though). Kind regards, -- Sebastiaan Hoogeveen NederHost KvK: 34099781