On Wed, Oct 8, 2014 at 12:51 PM, Glenn Elliott <[email protected]> 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
