Hi, [ next time, please put a subject on your e-mail, as it's really unconvenient for people reading the list to process messages with no subject ]
Some responses below. On Mon, Jan 26, 2015 at 11:43:39AM -0800, Aaron Golub wrote: (...) > So far, so good...the SWAP_SERVERID cookies gets set fine. Now...from > here, the servers at the www_prodswap and PROD_https_swap backends > redirects some of their traffic to these frontends using reverse proxy that > is configured in our paython site and effectively uses curl to access urls > and the delivers that data back out to the client: I'm assuming that when you say "redirect", you really mean "forward" in fact. > #--------------------------------- > # "frontend" section describes a set of listening sockets accepting client > connections. > frontend PROD_rev_proxy_http > #--------------------------------- > bind 10.2.0.202:80 <http://10.2.0.202/> > mode http > option httplog > default_backend PROD_http > > #--------------------------------- > # "frontend" section describes a set of listening sockets accepting client > connections. > frontend PROD_rev_proxy_tcp > #--------------------------------- > bind 10.2.0.202:443 > acl is_port_443 dst_port 443 > mode tcp > use_backend PROD_https if is_port_443 > default_backend PROD_http Note that the ACL above will always match given that the frontend only listens to port 443. > These front ends them direct traffic to the following backends: > > #--------------------------------- > # "backend" section describes a set of servers to which the proxy will > connect to forward incoming connections. > backend PROD_http > #--------------------------------- > mode http > option httplog > stats enable > stats auth ****:**** > balance roundrobin > stick on src table PROD_https > cookie PHP_SERVERID insert indirect nocache > option httpclose > option forwardfor > option httpchk /healthcheck.txt > server prod4 10.2.0.105:80 <http://10.2.0.105/> cookie prod4 weight 34 > check > server prod5 10.2.0.106:80 <http://10.2.0.106/> cookie prod5 weight 33 > check > server prod6 10.5.0.107:80 <http://10.5.0.107/> cookie prod6 weight 33 > check > > > #--------------------------------- > backend PROD_https > #--------------------------------- > mode tcp > option tcplog > balance roundrobin > stick-table type ip size 200k expire 30m > stick on src > server prod4 10.2.0.105:443 > server prod5 10.2.0.106:443 > server prod6 10.5.0.107:443 > > > > So here's the problem....The pages on the PROD_http/PROD_https load just > fine, but the PHP_SERVERID cookie is only set intermittently. Why would > that be? Do I have the cookies settings configured incorrectly? The > reason I ask is because we believe that these cookies settings are causing > server affinity to be lost. Any insight into this would be greatly > appreciated. I'm seeing two possibilities : 1) are you sure that none of your requests are made over SSL ? Since you have a pass-through configuration for SSL which forwards in TCP mode without setting any cookie, that could be the explanation. 2) another possibility could be related to the "indirect" keyword. When it is set, haproxy will only add the cookie in responses to requests which do not have a valid cookie. Maybe in your case the client expects the cookie to be present in every response and would flush it if it's not present, then causing the affinity to be lost ? If that's the case, you can simply workaround this by removing the "indirect" keyword. > Also...is it possible to have cookies set for HTTPs as well and can it be > the same cookie as the http cookie? > I'm currently using HAproxy1.4. Yes but for that you need to decipher SSL. That requires haproxy 1.5 and that you install your server's certificate on haproxy. It may or may not be acceptable in your environment. Regards, Willy
