Some more information while showing backend not available.

Server test_cluster/server1 is DOWN, reason: Layer7 timeout, check
duration: 2001ms. 0 active and 0 backup servers left. 3 sessions active, 0
requeued, 0 remaining in queue.
 backend test_cluster has no server available!
 Server test_cluster/server1 is DOWN, reason: Layer7 timeout, check
duration: 2001ms. 0 active and 0 backup servers left. 1 sessions active, 0
requeued, 0 remaining in queue.
 backend test_cluster has no server available!
 Server test_cluster server1 is UP, reason: Layer7 check passed, code: 200,
info: "HTTP content check matched", check duration: 1ms. 1 active and 0
backup servers online. 0 sessions requeued, 0 total in queue.




On Wed, Nov 15, 2017 at 5:20 PM, DHAVAL JAISWAL <dhava...@gmail.com> wrote:

> I did apply that and its under observation.
>
> There is one more issue after introducing Internal ELB is overall
> performance of site is slightly reduced. The response which I used to get
> in less than 100 ms now some time is going beyond 100 ms.
>
> Any clue how can I improve it.
>
> On Wed, Nov 15, 2017 at 4:21 AM, Igor Cicimov <igorc@encompasscorporation.
> com> wrote:
>
>> 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 <dhava...@gmail.com>
>> 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 <
>>> 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/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 <haproxy@formilux.org>
>>>>> *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.a
>>>>> mazonaws.com
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> resolvers testresolver
>>>>>
>>>>>       nameserver dns1 <http://169.254.169.253:53>
>>>>> ​​ <http://169.254.169.253:53>
>>>>> 169.254.169.253:53
>>>>>
>>>>>       resolve_retries       3
>>>>>
>>>>>       timeout retry         1s
>>>>>
>>>>>       hold valid           10s
>>>>>
>>>>>
>>>>>
>>>>> backend test_cluster
>>>>>
>>>>> mode http
>>>>>
>>>>> option forwardfor
>>>>>
>>>>> fullconn 10000
>>>>>
>>>>> 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.
>>>>>
>>>>>
>>>>>
>>>>
>
>
> --
> Thanks & Regards
> Dhaval Jaiswal
>



-- 
Thanks & Regards
Dhaval Jaiswal

Reply via email to