Tag Info

New answers tagged

0

the right keyword is use-server (notice that this is an dash and not an underscore like use_backend. Now my Load is reduced and configs are smaller. I only searched for something like use_server... So this is my working example: listen myFrontend bind 127.0.1.1:80 bind 127.0.1.1:443 ssl crt /etc/haproxy/ssl/myFrontend/myFrontend.pem redirect ...


1

What Florin said. It also would not make much sense - if the client has not completed its request inside the timeout boundary, how is haproxy supposed to apply any ACL rule?


0

Credit to @florin-asavoaie for pointing me in the write direction on this one. Here's a full write up: I already had a json page at /status that returned {"status":"up"} So I added option httpchk GET /status http-check expect string up To my backend in haproxy.cfg and restarted haproxy


1

From Unicorn, you shall have a "ping" page that responds with "OK" if the application is up and running fine. Then use that page as a healthcheck in haproxy by using http-check-expect.


0

This is not possible / supported. The client timeout value is set per frontend, not per request.


0

I'm having some troubles with this. At least I tought this will work, with more than one domain it doesn't. I have several ACL's for static content, CRM, etc. acl static hdr_dom(host) -i static.myhouses.com acl static hdr_dom(host) -i static.housesonline.com acl crm hdr_dom(host) -i intranet.myhouses.com acl crm hdr_dom(host) -i intranet.housesonline.com ...


0

You are basically almost there. Configure three backends: apache, with only the server localhost:8080 lighttpd, with server localhost:8082 webide, with server localhost:8081 Make apache your default backend. Add acls to use the other backends if the URI starts with the appropriate path.


0

The path of a HTTP request is always handed to the backend server, i.e. GET /small HTTP/1.1 will be visible behind HAproxy as just that request. If you suspect that this somehow is truncated to GET / HTTP/1.1 on the server behind HAproxy, you should check for this using tcpdump -i any port 8080 -As1024 | grep GET on that server and watch the inbound ...


1

Using a single frontend and multiplexing to the backends is indeed possible. You will be required to add one backend section per backend server, e.g. backend JabberD1 tcp-check connect tcp-check send PING\r\n tcp-check expect string +PONG server Server1ZoneD 10.60.30.209:80 check backend JabberE1 tcp-check connect tcp-check send ...


1

Note that roundrobin is not a good strategy to achieve even load. It will make sure that each backend receives the same number of connections over time, but does not care how long each connection last. In your stats view, it should be apparent that the total number of sessions per backend server is almost equal (if their uptimes are equal). The number of ...


0

Make certain that there is no other process that has open connections to your service. Take special note that during haproxy reload, there is a time frame in which two haproxy processes will use your resources, and each enforce connection limits on their own. The finishing process will not terminate before all queues are drained. Therefor, it is quite ...


2

Create an ACL to match for the www subdomain: acl is_host_www hdr(Host) -i www.mydomain.com If the acl is not matched, return a 3XX redirect: redirect pfx http://www.mydomain.com unless is_host_www


0

You could run into inconsistent data if you introduce separate caches elsewhere than inside MySQL. And I think that is the reason in the first place why Galera has no query cache. The application should have its own cache with memcached, where required data would be stored.


0

I wrote a utility to do just this, you can download it at GitHub: haproxy-dynamic-weight. It provides a way to dynamically and automatically allocate haproxy traffic across servers in proportion to their load. If this python & memcached solution isn't for you, you'll see the script's documentation refers and links to two alternatives.


0

You really should have this setup differently. If you are going to have 2 of the 3 services running on the same server, it should be HAProxy and Varnish, with requests that cant be immediately returned from varnishes cache, then sent over to NGINX. You don't want the cache servers also doing the processing, you semi defeat the purpose. Also doing it this way ...


2

You want option redispatch. This causes a request that fails to be retried on another server.


0

As the traffic increases, it will be split across your application servers by the Haproxy and of course, the application servers which process the requests will be mostly affected.


0

Wow. A detail that I omitted was that we purchase/re-issue our certificate through a reseller (Namecheap). I had requested a certificate re-issue 3 times today because I thought I was doing something funky. I called GeoTrust and asked about my requests. The guy on the phone checked all 3 CSR's that I had sent and all 3 were different than the CSR files I ...


0

I believe that I've found the solution, being a developer and not a sys admin, this took a little time to figure out but ultimately, I believe that the issue was that for transparent proxying to work, the proxy needs to also be the target host's default gateway. That way: The proxy makes a spoofed call, impersonating the original client The target host ...


2

As the name states, HAProxy will work as a proxy and for the client, it looks like it speaks only to the HAProxy server, while it transparently forwards the traffic to one of several backend application servers (which usually aren't accessible from the outside). Thus, you will use the bandwidth between the HAProxy and the backend servers plus about the same ...



Top 50 recent answers are included