Re: backend has no server available!

[Igor Cicimov]

Dhaval,

What I put in my resolvers is the EC2 instance subnet dns server which for
EC2 is always the second IP of the subnet range, xxx.xxx.xxx..2

You can also find this IP in your /etc/resolv.conf on the haproxy
instances. Try replacing
​
169.254.169.253:53 with that value and see how you go.

On Wed, Nov 15, 2017 at 4:04 AM, DHAVAL JAISWAL  wrote:

> Even after reducing "hold valid"  to 1s shows the same behavior.
>
> One more observation is that after introducing ELB in haproxy config, site
> seems to have little late response.
>
> Provided link is helpful, however if any one face same issue or can share
> experience to solve it will be really helpful.
>
> On Tue, Nov 14, 2017 at 5:00 AM, Igor Cicimov  com> wrote:
>
>>
>>
>> On Mon, Nov 13, 2017 at 11:28 PM, James Stroehmann <
>> james.stroehm...@proquest.com> wrote:
>>
>>> I had a similar problem, and I believe reducing my ‘hold valid’ setting
>>> to 1s fixed it.
>>>
>>>
>>>
>>>
>>>
>>
>> ​Possible explanation is the "inter" parameter which is by default set to
>> 2s for the "check" operation, see https://cbonte.github.io/hapro
>> xy-dconv/1.7/configuration.html#inter for details.
>>
>> In other words, read the docs about ALL timeouts set in Haproxy to figure
>> out how they correlate between each other and how to set the proper values
>> for your user case.​
>>
>>
>>
>>
>>> *From:* DHAVAL JAISWAL [mailto:dhava...@gmail.com]
>>> *Sent:* Monday, November 13, 2017 2:31 AM
>>> *To:* HAproxy Mailing Lists 
>>> *Subject:* backend has no server available!
>>>
>>>
>>>
>>> [External Email]
>>>
>>> I had the following config where we are using AWS ELB for load
>>> balancing. However, now we are keep getting backend test_cluster has no
>>> server available!
>>>
>>>
>>>
>>> Under this ELB two servers attached. Both instance are in healthy state.
>>> Healthy state we are checking on port 80 and tomcat response sending on
>>> port 8080
>>>
>>>
>>>
>>> internal-testtomcatautoscale-1314784611.ap-southeast-1.elb.amazonaws.com
>>>
>>>
>>>
>>>
>>>
>>> resolvers testresolver
>>>
>>>   nameserver dns1 
>>> ​​ 
>>> 169.254.169.253:53
>>>
>>>   resolve_retries   3
>>>
>>>   timeout retry 1s
>>>
>>>   hold valid   10s
>>>
>>>
>>>
>>> backend test_cluster
>>>
>>> mode http
>>>
>>> option forwardfor
>>>
>>> fullconn 1
>>>
>>> option httpchk /test-testalive
>>>
>>> http-check expect string OK
>>>
>>> option http-server-close
>>>
>>> option abortonclose
>>>
>>> balance roundrobin
>>>
>>> server server1 internal-testtomcatautoscale-1
>>> 314784611.ap-southeast-1.elb.amazonaws.com:8080 check resolvers
>>> testresolver
>>>
>>>
>>>
>>>
>>>
>>> What could be the cause of this issue. How can i fix it.
>>>
>>>
>>>
>>

Re: [PATCH] BUG/MEDIUM: mworker: Fix re-exec when haproxy is started from PATH

[Tim Düsterhus]

William,

Am 14.11.2017 um 15:03 schrieb William Lallemand:
> Well, in my opinion the return value does not need to be checked because we
> should never reach the code after the exec, that means that the code after the
> exec is only reached during an exec error. But we could at least display the
> error code of exec and return afterwards.

Displaying the error code basically would imply "checking the return
value" for me.
I did not mean to say that some recovery should be performed if `exec`
fails. I am only saying that the error message should not be
misleadingly claim that we "Cannot allocate memory" when e.g. the
haproxy binary was deleted instead.

Personally I was confused whether I misconfigured the Docker container
with a broken memory limit, when the actual issue was the bug this patch
fixed. While *this* bug has been fixed `execvp` could possibly fail for
other reasons in the future.

> Willy, could you please apply this patch? thanks 
> 

Thanks!

Tim Düsterhus

Re: backend has no server available!

[DHAVAL JAISWAL]

Even after reducing "hold valid"  to 1s shows the same behavior.

One more observation is that after introducing ELB in haproxy config, site
seems to have little late response.

Provided link is helpful, however if any one face same issue or can share
experience to solve it will be really helpful.

On Tue, Nov 14, 2017 at 5:00 AM, Igor Cicimov <
ig...@encompasscorporation.com> wrote:

>
>
> On Mon, Nov 13, 2017 at 11:28 PM, James Stroehmann <
> james.stroehm...@proquest.com> wrote:
>
>> I had a similar problem, and I believe reducing my ‘hold valid’ setting
>> to 1s fixed it.
>>
>>
>>
>>
>>
>
> ​Possible explanation is the "inter" parameter which is by default set to
> 2s for the "check" operation, see https://cbonte.github.io/
> haproxy-dconv/1.7/configuration.html#inter for details.
>
> In other words, read the docs about ALL timeouts set in Haproxy to figure
> out how they correlate between each other and how to set the proper values
> for your user case.​
>
>
>
>
>> *From:* DHAVAL JAISWAL [mailto:dhava...@gmail.com]
>> *Sent:* Monday, November 13, 2017 2:31 AM
>> *To:* HAproxy Mailing Lists 
>> *Subject:* backend has no server available!
>>
>>
>>
>> [External Email]
>>
>> I had the following config where we are using AWS ELB for load balancing.
>> However, now we are keep getting backend test_cluster has no server
>> available!
>>
>>
>>
>> Under this ELB two servers attached. Both instance are in healthy state.
>> Healthy state we are checking on port 80 and tomcat response sending on
>> port 8080
>>
>>
>>
>> internal-testtomcatautoscale-1314784611.ap-southeast-1.elb.amazonaws.com
>>
>>
>>
>>
>>
>> resolvers testresolver
>>
>>   nameserver dns1 169.254.169.253:53
>>
>>   resolve_retries   3
>>
>>   timeout retry 1s
>>
>>   hold valid   10s
>>
>>
>>
>> backend test_cluster
>>
>> mode http
>>
>> option forwardfor
>>
>> fullconn 1
>>
>> option httpchk /test-testalive
>>
>> http-check expect string OK
>>
>> option http-server-close
>>
>> option abortonclose
>>
>> balance roundrobin
>>
>> server server1 internal-testtomcatautoscale-1
>> 314784611.ap-southeast-1.elb.amazonaws.com:8080 check resolvers
>> testresolver
>>
>>
>>
>>
>>
>> What could be the cause of this issue. How can i fix it.
>>
>>
>>
>
>
>
> --
> Igor Cicimov | DevOps
>
>
> p. +61 (0) 433 078 728
> e. ig...@encompasscorporation.com 
> w*.* www.encompasscorporation.com
> a. Level 4, 65 York Street, Sydney 2000
> 
>



-- 
Thanks & Regards
Dhaval Jaiswal

Re: Websocket metrics

[Andrew Smalley]

Hi Claus

Below is a blog on the haproxy website about websockets, I apologies
if it does not have the information you need

https://www.haproxy.com/blog/websockets-load-balancing-with-haproxy/



Andruw Smalley

Loadbalancer.org Ltd.

www.loadbalancer.org
+1 888 867 9504 / +44 (0)330 380 1064
asmal...@loadbalancer.org

Leave a Review | Deployment Guides | Blog


On 14 November 2017 at 14:18, Claus Strommer  wrote:
>
> Hi,
>
> I'm looking for recommendations on best practices for collecting metrics and 
> performing analytics on websocket connections through HAProxy.  I'm already 
> capturing the http log which serves me well for http traffic, but since 
> websockets get upgraded to TCP connections I'm losing the kind of atomicity 
> I'm used to.  Is there anything I can do with HAProxy to sample frames from a 
> websocket, or am I going to have to go more low-level and do layer 2 traffic 
> capture?

Websocket metrics

[Claus Strommer]

Hi,

I'm looking for recommendations on best practices for collecting metrics
and performing analytics on websocket connections through HAProxy.  I'm
already capturing the http log which serves me well for http traffic, but
since websockets get upgraded to TCP connections I'm losing the kind of
atomicity I'm used to.  Is there anything I can do with HAProxy to sample
frames from a websocket, or am I going to have to go more low-level and do
layer 2 traffic capture?

Re: [PATCH] BUG/MEDIUM: mworker: Fix re-exec when haproxy is started from PATH

[Willy Tarreau]

On Tue, Nov 14, 2017 at 03:03:20PM +0100, William Lallemand wrote:
> Willy, could you please apply this patch? thanks 

OK now done, thanks guys.

Willy

Re: [PATCH] BUG/MEDIUM: mworker: Fix re-exec when haproxy is started from PATH

[William Lallemand]

Hi Tim,

On Sun, Nov 12, 2017 at 05:39:18PM +0100, Tim Düsterhus wrote:
> From: Tim Duesterhus 
> 
> If haproxy is started using the name of the binary only (i.e.
> not using a relative or absolute path) the `execv` in
> `mworker_reload` fails with `ENOENT`, because it does not
> examine the `PATH`:
> 
>   [WARNING] 315/161139 (7) : Reexecuting Master process
>   [WARNING] 315/161139 (7) : Cannot allocate memory
>   [WARNING] 315/161139 (7) : Failed to reexecute the master processs [7]
> 
> The error messages are misleading, because the return value of
> `execv` is not checked. This should be fixed in a separate commit.
>
> Once this happened the master process ignores any further
> signals sent by the administrator.
> 

Well, in my opinion the return value does not need to be checked because we
should never reach the code after the exec, that means that the code after the
exec is only reached during an exec error. But we could at least display the
error code of exec and return afterwards.

However, in the case of an exec failure, the master-worker should always work,
and so it should be able to receive signals.

I spot two other problems in this code path, I'll fix them shortly.

> Replace `execv` with `execvp` to establish the expected
> behaviour.

Willy, could you please apply this patch? thanks 

-- 
William Lallemand