Re: haproxy doesn't bring failed server up

2019-10-07 Thread rihad
BTW, all these resolver hold settings are a bit confusing, is there a 
way to tell haproxy to rely on the TTL it gets from DNS 
servers/resolvers? It seems to be relying on some hard-coded default 
values instead.


*hold 
* 
 


Defines  during which the last name resolution should be kept based
on last resolution 
   : last name resolution status. Acceptable values are "nx",
 "other", "refused", 
"timeout", "valid", "obsolete".
   : interval between two successive name resolution when the last
 answer was in . It follows the HAProxy time format.
  is in milliseconds by default.

Default value is 10s for "valid", 0s for "obsolete" and 30s for others.



Re: haproxy doesn't bring failed server up

2019-10-07 Thread rihad

On 10/07/2019 11:02 AM, Lukas Tribus wrote:

Hello,

On Mon, Oct 7, 2019 at 6:30 AM rihad  wrote:

Thanks! But according to the manual, shouldn't haproxy re-resolve AWS server 
name regardless of its resolver settings?


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.

No. That is when the resolver is actually configured. Please read from
the same section:
Oh, ok, I must have misunderstood "A few other events *can trigger* a 
name resolution at run time"
But that doesn't mean it will necessarily succeed in case no resolvers 
have been configured )
I should say that no errors or warnings regarding failed name resolution 
even appeared in syslog which left me puzzled about what the root cause 
could be.


Anyway, I've added this:

resolvers mydns
# this sugar seems to require haproxy-2.0:
#    parse-resolv-conf
    nameserver mydns0 127.0.0.1:53


hoping it will help.

Thanks!


HAProxy allows using a host name on the server line to retrieve its IP address
using name servers. By default, HAProxy resolves the name when parsing the
configuration file, at startup and cache the result for the process' life.
This is not sufficient in some cases, such as in Amazon where a server's IP
can change after a reboot or an ELB Virtual IP can change based on current
workload.
This chapter describes how HAProxy can be configured to process server's name
resolution at run time.



Regards,
Lukas
.





Re: haproxy doesn't bring failed server up

2019-10-07 Thread Lukas Tribus
Hello,

On Mon, Oct 7, 2019 at 6:30 AM rihad  wrote:
> Thanks! But according to the manual, shouldn't haproxy re-resolve AWS server 
> name regardless of its resolver settings?
>
>
> 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.

No. That is when the resolver is actually configured. Please read from
the same section:

> HAProxy allows using a host name on the server line to retrieve its IP address
> using name servers. By default, HAProxy resolves the name when parsing the
> configuration file, at startup and cache the result for the process' life.
> This is not sufficient in some cases, such as in Amazon where a server's IP
> can change after a reboot or an ELB Virtual IP can change based on current
> workload.
> This chapter describes how HAProxy can be configured to process server's name
> resolution at run time.



Regards,
Lukas



Re: haproxy doesn't bring failed server up

2019-10-07 Thread Lukas Tribus
Hello,

On Mon, Oct 7, 2019 at 10:00 AM rihad  wrote:
>
> BTW, all these resolver hold settings are a bit confusing, is there a way to 
> tell
> haproxy to rely on the TTL it gets from DNS servers/resolvers? It seems to be
> relying on some hard-coded default values instead.

I don't think TTL is currently considered, no. How long it will cache
is configurable and defaults to 10 seconds ("valid"). Because you'd
use very low values here anyway (and have your recursive resolver do
proper TTL considering caching), I don't believe there is a huge
impact because of this.

But I agree, it would be better to consider the TTL.


Lukas