Hi Lukas, On Sat, Aug 4, 2018 at 11:19 PM, Lukas Tribus <[email protected]> wrote:
> On Sat, 4 Aug 2018 at 14:21, Igor Cicimov > <[email protected]> wrote: > > > > Hi, > > > > On Sat, Aug 4, 2018 at 1:50 AM, K3 <[email protected]> wrote: > >> > >> Hi, > >> We are running into a problem and would like to hear any advice. > >> > >> Our Setup: > >> We use haproxy 1.7.7 with two backends. > >> One of the backends is AWS ELB > >> The haproxy is running on a linux machine in our data center (on > premises) > >> > >> Problem: > >> The ELB is available on 3 AZ so the endpoint can resolve to 3 IPs at a > given time. > >> After startup, when one of the ELB's IP changes, our haproxy shows the > ELB as down with L4TMOUT and never recovers the backend. > >> > >> From 1.7.7 doc, under section 5.3.1 we see the below > >> "A few other events can trigger a name resolution at run time: > >> > >> - when a server's health check ends up in a connection timeout: this > may be > >> because the server has a new IP address. So we need to trigger a > name > >> resolution to know this new IP." > >> > >> Its not clear if the resolvers section is required for the above > statement to be true. > >> > >> Unfortunately, we cannot define name server's IPs in our configuration > since these IPs can change. > >> > >> On the system (/etc/resolv.conf), these are automatically updated by > dhclient. > >> > >> Question: > >> > >> 1. Is there any way by which haproxy can use the latest DNS entries > from the system config and use it during the runtime? > > > > I just saw this announced in 1.9-dev1 > > > > > > - the "resolvers" section can now be fed directly from resolv.conf > > using the "parse-resolv-conf" directive. The DNS code also supports > > new options to enable/disable address deduplication within a farm. > > This is on startup only though. Haproxy cannot continuously re-read > resolv.conf, not even with this feature. > > If the DNS servers on your system keep changing unpredictably, there > is no solution other than restarting haproxy, with the > parse-resolv-conf configuration and the haproxy internal resolver. > > Would a reload suffice instead of restart? It should not be difficult to create a monitor for *resolv.conf* file using inotify lets say and automatically reload/restart haproxy in case it's content has changed.
