Thanks Baptiste,

The pdf was very helpful. I have split off https into its own frontend/backend 
and can see that this is the cause of a large number of "CD" client disconnect 
errors. So I need to investigate this further.. it looks like the majority of 
the client session closures end with a "CD" error. The users don't report any 
application issues however (e.g. OWA & Outlook perform fine).

I wonder if its related to TOE or other offload features on the 10Gig Emulex 
nic we are using (HP 554FLR-SFP+). Alternative it might be just the behaviour 
of the clients in combination to a http-keep-alive timeout.



ethtool -k eth0

Features for eth0:
rx-checksumming: on
tx-checksumming: on
scatter-gather: on
tcp-segmentation-offload: on
udp-fragmentation-offload: off
generic-segmentation-offload: on
generic-receive-offload: on
large-receive-offload: off
ntuple-filters: off
receive-hashing: on

Rgds,

Glenn


-----Original Message-----
From: Baptiste [mailto:bed...@gmail.com] 
Sent: Thursday, 9 October 2014 1:21 AM
To: Glenn Elliott
Cc: haproxy@formilux.org
Subject: Re: connection resets during transfers

On Wed, Oct 8, 2014 at 12:51 PM, Glenn Elliott <glenn.elli...@svha.org.au> 
wrote:
>
> Hi All,
>
>
>
> I am in the process of migrating from ultramonkey (lvs & heartbeat) to 
> haproxy 1.5.4 for our environment. I have been really impressed with haproxy 
> so far particularly the ssl offload feature and the Layer 7 flexibility for 
> our jboss apps.
>
>
>
> One of the VIPS that I have moved to haproxy is our exchange 2013 environment 
> which is running in tcp mode (expecting approx 1500 concurrent connections on 
> this VIP). I don't have any application/user issues yet but I wanted to get a 
> handle on the haproxy stats page and particularly the 'resp errors' on the 
> backend servers. The total 'resp error' count for the backend is 249 but when 
> I hover over the cell it tells me 'connection resets during transfer 314 
> client, 597 server'. This doesn't seem to add up?
>
>
>
> I assume this counter is accumulative?
>
>
>
> As a rule of thumb what sort of percentage would I be concerned with when 
> looking at this figure?
>
>
>
>
>
>
>
>
> My config snippets are:
>
>
>
> defaults
>
>     log                         global
>
>     mode                    http
>
>     option                  tcplog
>
>     option                  dontlognull
>
>     option                  redispatch
>
>     retries                 3
>
>     timeout http-request    15s
>
>     timeout queue           30s
>
>     timeout connect         5s
>
>     timeout client          5m
>
>     timeout server          5m
>
>     timeout http-keep-alive 1s
>
>     timeout check           10s
>
>     timeout tarpit          1m
>
>     backlog                 10000
>
>     maxconn                 2000
>
>
>
>
>
> #---------------------------------------------------------------------
>
> # exchange vip
>
> #---------------------------------------------------------------------
>
> frontend  exchange
>
>     bind 192.168.1.172:443
>
>     bind 192.168.1.172:25
>
>     bind 192.168.1.172:80
>
>     bind 192.168.1.172:587
>
>     bind 192.168.1.172:995
>
>     mode tcp
>
>     maxconn 10000
>
>
>
>     default_backend             exchange-backend
>
>
>
> #---------------------------------------------------------------------
>
> # exchange backend
>
> #---------------------------------------------------------------------
>
> backend exchange-backend
>
>     mode tcp
>
>     option ssl-hello-chk
>
>     balance     roundrobin
>
>     server  exch01 exch01 maxconn 5000 check port 443 inter 15s
>
>     server  exch02 exch02 maxconn 5000 check port 443 inter 15s
>
>     server  exch03 exch03 maxconn 5000 check port 443 inter 15s
>
>     server  exch04 exch04 maxconn 5000 check port 443 inter 15s
>
>
>
>
>
> Thanks very much for your time!
>
>
>
> Rgds,
>
>
>
> Glenn Elliott.
>
>
> ______________________________________________________________________
> For the purposes of protecting the integrity and security of the SVHA network 
> and the information held on it, all emails to and from any email address on 
> the "svha.org.au" domain (or any other domain of St Vincent's Health 
> Australia Limited or any of its related bodies corporate) (an "SVHA Email 
> Address") will pass through and be scanned by the Symantec.cloud anti virus 
> and anti spam filter service. These services may be provided by Symantec from 
> locations outside of Australia and, if so, this will involve any email you 
> send to or receive from an SVHA Email Address being sent to and scanned in 
> those locations.



Hi Glenn,

It means either the client or the server purposely closed the connection (using 
RST) during the DATA phase (after handshake since you're in TCP mode).
Have a look in your logs and search for 'SD' or 'CD' termination flags to know 
on which service did the problem occurred.

If you want / need to dig further, you may have to improve the log line 
generated or split your configuration in frontend/backend per service.
That way, you'll know on which TCP port (hence service) those errors are 
generated.

Note that you can get some configuration templates for HAProxy and Exchange 
2013 from our appliance documentation:
http://haproxy.com/static/media/uploads/eng/resources/aloha_load_balancer_appnotes_0065_exchange_2013_deployment_guide_en.pdf

Baptiste

Reply via email to