Re: -sf/-st not working
Thanks for the answer, as written in http://www.mgoff.in/2010/04/18/haproxy-reloading-your-config-with- minimal-service-impact/ The end-result is a reload of the configuration file which is not visible by the customer But in our case it leads to unbinding from all ports and finishing haproxy process. Can this issue related to rpm build options? RPM build log is https://build.opensuse.org/package/rawlog?arch=x86_64package=haproxy-1.5project=server%3Ahttprepository=openSUSE_12.2 -- Best regards, Eugene Istomin On Thursday 07 February 2013 07:28:17 Willy Tarreau wrote: Hello Eugene, On Wed, Feb 06, 2013 at 08:29:33PM +0200, Eugene Istomin wrote: Hello, We have problem with reload/HUP: if i run #/usr/sbin/haproxy -D -f /etc/haproxy/haproxy.cfg -p /var/run/haproxy.pid -sf $(cat /var/run/haproxy.pid) - haproxy process is shutting down and exit This is the intended behaviour, it unbinds from its ports so that the new process can bind, then waits for all existing connections to terminate and leaves. Isn't it what you're observing ? What would you have expected instead ? Willy
Re: failing to redirect http to https using HAProxy 1.5dev15
Hi, You should consider to use the brand new redirect just ment for that : redirect scheme https code 301 if ! secure Regards Le jeudi 07 février 2013 11:38:34 Robbert van Waveren a écrit : Hi, I'm trying out HAProxy and would like to use as our general purpose proxy/loadbalancer. Currently I've all requirements tackled except forcing the use of https (by means of a redirection). We're planning host many different sub domains so I really need to redirect to be as generic as possible. On the web I found a solution proposal using reqirep to rewrite the host header to https and then a generic redirect. However I can't get it to work as the redirect seems to fail to add the protocol+host part in the redirect url. (Leading to a redirect loop) Below is a simplified configuration that I'm currently trying to get working. Note that I´m using HAProxy itself to deal with SSL termination. global maxconn 4096 daemon nbproc 2 defaults clitimeout 6 srvtimeout 3 contimeout 4000 modehttp frontend fe_default bind :443 ssl crt /opt/haproxy/ppc.pem crt /opt/haproxy/keystore/ bind :80 acl secure dst_port 443 reqirep ^Host:[\ ]*\(.*\) Host:\ https://\1 if ! secure redirect prefix / if ! secure default_backend be_default backend be_default balance roundrobin option httpchk cookie srv insert postonly indirect server civ1 10.2.32.175:443 weight 1 maxconn 512 check cookie one server civ2 10.2.32.176:443 weight 1 maxconn 512 check cookie two Any help is much appreciated. Regards, Robbert -- Guillaume Castagnino ca...@xwing.info / guilla...@castagnino.org
compress only if response size is big enough
Hello! It would be nice to add some parameter min_compress_size. So haproxy will compress HTTP response only if response size is bigger than that value. Because compressing small data can lead to size increase and is useless. Thanks.
Re: -sf/-st not working
You should have a new HAProxy process started using the new configuration and binding the ports... cheers On 2/7/13, Eugene Istomin e.isto...@edss.ee wrote: Thanks for the answer, as written in http://www.mgoff.in/2010/04/18/haproxy-reloading-your-config-with- minimal-service-impact/ The end-result is a reload of the configuration file which is not visible by the customer But in our case it leads to unbinding from all ports and finishing haproxy process. Can this issue related to rpm build options? RPM build log is https://build.opensuse.org/package/rawlog?arch=x86_64package=haproxy-1.5project=server%3Ahttprepository=openSUSE_12.2 -- Best regards, Eugene Istomin On Thursday 07 February 2013 07:28:17 Willy Tarreau wrote: Hello Eugene, On Wed, Feb 06, 2013 at 08:29:33PM +0200, Eugene Istomin wrote: Hello, We have problem with reload/HUP: if i run #/usr/sbin/haproxy -D -f /etc/haproxy/haproxy.cfg -p /var/run/haproxy.pid -sf $(cat /var/run/haproxy.pid) - haproxy process is shutting down and exit This is the intended behaviour, it unbinds from its ports so that the new process can bind, then waits for all existing connections to terminate and leaves. Isn't it what you're observing ? What would you have expected instead ? Willy
Re: SSL handshake failure
Thank you very much, overlooked your email due to filters, sorry for delay.
I am very happy to help, sure I would accept a patch.
Server is available from outside world but is not heavily used — we dont
point load to it because of this SSL errors.
By the way, I am using default haproxy-devel port in FreeBSD tree, so
http://haproxy.1wt.eu/download/1.5/src/devel/haproxy-1.5-dev17.tar.gzsource
is being used.
On Wed, Feb 6, 2013 at 10:56 AM, Willy Tarreau w...@1wt.eu wrote:
Hello Samat,
On Tue, Feb 05, 2013 at 12:39:20PM +0400, Samat Galimov wrote:
Hello,
I have very strange behaviour of HA-Proxy version 1.5-dev17 2012/12/28 on
FreeBSD 9.0-Stable
% openssl s_client -debug -servername dharma.zvq.me -connect
dharma.zvq.me:443 /usr/local/etc
CONNECTED(0003)
write to 0x801407160 [0x801525000] (128 bytes = 128 (0x80))
- 16 03 01 00 7b 01 00 00-77 03 01 51 10 6a 26 66 {...w..Q.jf
0010 - e8 2b 77 63 f9 ea 25 e8-b7 cb 51 84 0a d7 0d 7c .+wc..%...Q???.|
0020 - 58 2c 32 6f 0f 54 94 c6-29 57 c4 00 00 34 00 39 X,2o.T..)W???4.9
0030 - 00 38 00 35 00 88 00 87-00 84 00 16 00 13 00 0a .8.5..??
0040 - 00 33 00 32 00 2f 00 45-00 44 00 41 00 05 00 04 .3.2./.E.D.A???.
0050 - 00 15 00 12 00 09 00 14-00 11 00 08 00 06 00 03 .??.
0060 - 00 ff 01 00 00 1a 00 00-00 12 00 10 00 00 0d 64 .??d
0070 - 68 61 72 6d 61 2e 7a 76-71 2e 6d 65 00 23 harma.zvq.me.#
0080 - SPACES/NULS
read from 0x801407160 [0x801577000] (7 bytes = 0 (0x0))
42642:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake
failure:/mnt/jq032hgn/usr/src/secure/lib/libssl/../../../crypto/openssl/ssl/s23_lib.c:182:
OpenSSL is 0.9.8q 2 Dec 2010
It's randomly gives such a weird error, 50% chance, as I see.
Are you the only one to access this service or is it in production and
used by other people ? I'm asking because we had a similar report a few
weeks ago of 0.9.8 on solaris experiencing random errors, and we suspected
that the error queue was probably sometimes filled by some SSL calls
without returning an error, and thus was not flushed.
Would you accept to try a patch ? We have one to change the behaviour
that we have still not merged due to the lack of testers experiencing
the issue !
On server side (i run haproxy with -d) i get:
000c:https.accept(0005)=0007 from [5.9.11.40:43423]
000c:https.clicls[0007:0008]
000c:https.closed[0007:0008]
Here is my config:
(...)
I see nothing wrong in your configuration, and a config should not cause
a random behaviour anyway. Also you're not in a chroot so it cannot be
caused by a lack of entropy caused by the inability to access /dev/urandom.
Willy
Re: SSL handshake failure
On Thu, Feb 07, 2013 at 06:49:14PM +0400, Samat Galimov wrote:
Thank you very much, overlooked your email due to filters, sorry for delay.
I am very happy to help, sure I would accept a patch.
Server is available from outside world but is not heavily used ??? we dont
point load to it because of this SSL errors.
By the way, I am using default haproxy-devel port in FreeBSD tree, so
http://haproxy.1wt.eu/download/1.5/src/devel/haproxy-1.5-dev17.tar.gzsource
is being used.
OK, please find it attached. You should apply it on top of your current
source tree and rebuild.
Thanks,
Willy
diff --git a/src/ssl_sock.c b/src/ssl_sock.c
index 87eff2b..07b1ca7 100644
--- a/src/ssl_sock.c
+++ b/src/ssl_sock.c
@@ -128,7 +128,8 @@ int ssl_sock_verifycbk(int ok, X509_STORE_CTX *x_store)
}
if (objt_listener(conn-target)-bind_conf-ca_ignerr (1ULL
err)) {
- ERR_clear_error();
+ if (ERR_peek_error())
+ ERR_clear_error();
return 1;
}
@@ -141,7 +142,8 @@ int ssl_sock_verifycbk(int ok, X509_STORE_CTX *x_store)
/* check if certificate error needs to be ignored */
if (objt_listener(conn-target)-bind_conf-crt_ignerr (1ULL err))
{
- ERR_clear_error();
+ if (ERR_peek_error())
+ ERR_clear_error();
return 1;
}
@@ -885,6 +887,9 @@ int ssl_sock_handshake(struct connection *conn, unsigned
int flag)
if ((conn-flags CO_FL_CONNECTED)
SSL_renegotiate_pending(conn-xprt_ctx)) {
char c;
+ if (unlikely(ERR_peek_error()))
+ ERR_clear_error();
+
ret = SSL_peek(conn-xprt_ctx, c, 1);
if (ret = 0) {
/* handshake may have not been completed, let's find
why */
@@ -942,6 +947,9 @@ int ssl_sock_handshake(struct connection *conn, unsigned
int flag)
goto reneg_ok;
}
+ if (unlikely(ERR_peek_error()))
+ ERR_clear_error();
+
ret = SSL_do_handshake(conn-xprt_ctx);
if (ret != 1) {
/* handshake did not complete, let's find why */
@@ -1008,7 +1016,8 @@ reneg_ok:
out_error:
/* Clear openssl global errors stack */
- ERR_clear_error();
+ if (ERR_peek_error())
+ ERR_clear_error();
/* free resumed session if exists */
if (objt_server(conn-target)
objt_server(conn-target)-ssl_ctx.reused_sess) {
@@ -1062,6 +1071,9 @@ static int ssl_sock_to_buf(struct connection *conn,
struct buffer *buf, int coun
* EINTR too.
*/
while (try) {
+ if (unlikely(ERR_peek_error()))
+ ERR_clear_error();
+
ret = SSL_read(conn-xprt_ctx, bi_end(buf), try);
if (conn-flags CO_FL_ERROR) {
/* CO_FL_ERROR may be set by ssl_sock_infocbk */
@@ -1084,7 +1096,8 @@ static int ssl_sock_to_buf(struct connection *conn,
struct buffer *buf, int coun
conn-flags |= CO_FL_ERROR;
/* Clear openssl global errors stack */
- ERR_clear_error();
+ if (ERR_peek_error())
+ ERR_clear_error();
}
goto read0;
}
@@ -1118,7 +1131,8 @@ static int ssl_sock_to_buf(struct connection *conn,
struct buffer *buf, int coun
return done;
out_error:
/* Clear openssl global errors stack */
- ERR_clear_error();
+ if (ERR_peek_error())
+ ERR_clear_error();
conn-flags |= CO_FL_ERROR;
return done;
@@ -1158,6 +1172,9 @@ static int ssl_sock_from_buf(struct connection *conn,
struct buffer *buf, int fl
if (buf-data + try buf-p)
try = buf-data + try - buf-p;
+ if (unlikely(ERR_peek_error()))
+ ERR_clear_error();
+
ret = SSL_write(conn-xprt_ctx, bo_ptr(buf), try);
if (conn-flags CO_FL_ERROR) {
/* CO_FL_ERROR may be set by ssl_sock_infocbk */
@@ -1201,7 +1218,8 @@ static int ssl_sock_from_buf(struct connection *conn,
struct buffer *buf, int fl
out_error:
/* Clear openssl global errors stack */
- ERR_clear_error();
+ if (ERR_peek_error())
+ ERR_clear_error();
conn-flags |= CO_FL_ERROR;
return done;
@@ -1226,7 +1244,8 @@ static void ssl_sock_shutw(struct connection *conn, int
clean)
/* no handshake was in progress, try a clean ssl shutdown */
if (clean (SSL_shutdown(conn-xprt_ctx) = 0)) {
/* Clear openssl global errors stack */
- ERR_clear_error();
+ if (ERR_peek_error())
+
Re: -sf/-st not working
I think the main problem is in systemd: - from commandline -sf working as expected - from sysvinit -sf working as expected - from systemd -sf only stop process. I try both init.d systemd scripts in systemd-based linux - all results are the same: Loaded: loaded (/lib/systemd/system/haproxy.service; disabled) Active: failed (Result: signal) since Thu, 07 Feb 2013 17:18:43 +0200; 12s ago Process: 28125 ExecReload=/usr/sbin/haproxy -D -f /etc/haproxy/haproxy.cfg - p /var/run/haproxy.pid -sf $MAINPID (code=exited, status=0/SUCCESS) Process: 28118 ExecStart=/usr/sbin/haproxy -D -f /etc/haproxy/haproxy.cfg -p /var/run/haproxy.pid (code=exited, status=0/SUCCESS) Process: 28115 ExecStartPre=/usr/sbin/haproxy -c -q -f /etc/haproxy/haproxy.cfg (code=exited, status=0/SUCCESS) Main PID: 28126 (code=killed, signal=KILL) CGroup: name=systemd:/system/haproxy.service systemd script: [Unit] Description=HAProxy For TCP And HTTP Based Applications After=network.target [Service] Type=forking PIDFile=/var/run/haproxy.pid ExecStartPre=/usr/sbin/haproxy -c -q -f /etc/haproxy/haproxy.cfg ExecStart=/usr/sbin/haproxy -D -f /etc/haproxy/haproxy.cfg -p /var/run/haproxy.pid ExecReload=/usr/sbin/haproxy -D -f /etc/haproxy/haproxy.cfg -p /var/run/haproxy.pid -sf $MAINPID [Install] WantedBy=multi-user.target -- Best regards, Eugene Istomin On Thursday 07 February 2013 14:07:44 Baptiste wrote: You should have a new HAProxy process started using the new configuration and binding the ports... cheers On 2/7/13, Eugene Istomin e.isto...@edss.ee wrote: Thanks for the answer, as written in http://www.mgoff.in/2010/04/18/haproxy-reloading-your-config-with- minimal-service-impact/ The end-result is a reload of the configuration file which is not visible by the customer But in our case it leads to unbinding from all ports and finishing haproxy process. Can this issue related to rpm build options? RPM build log is https://build.opensuse.org/package/rawlog?arch=x86_64package=haproxy-1.5; project=server%3Ahttprepository=openSUSE_12.2 -- Best regards, Eugene Istomin On Thursday 07 February 2013 07:28:17 Willy Tarreau wrote: Hello Eugene, On Wed, Feb 06, 2013 at 08:29:33PM +0200, Eugene Istomin wrote: Hello, We have problem with reload/HUP: if i run #/usr/sbin/haproxy -D -f /etc/haproxy/haproxy.cfg -p /var/run/haproxy.pid -sf $(cat /var/run/haproxy.pid) - haproxy process is shutting down and exit This is the intended behaviour, it unbinds from its ports so that the new process can bind, then waits for all existing connections to terminate and leaves. Isn't it what you're observing ? What would you have expected instead ? Willy
Re: -sf/-st not working
It is totally normal that systemd kills the new process as the main one which was the first has exited. This is the expected behaviour. I'm currently patching haproxy to fully support systemd, I'll probably submit my patches by tomorrow (It's fully functionnal here, only needs a little cleaning) On 7 February 2013 16:31, Eugene Istomin e.isto...@edss.ee wrote: ** I think the main problem is in systemd: - from commandline -sf working as expected - from sysvinit -sf working as expected - from systemd -sf only stop process. I try both init.d systemd scripts in systemd-based linux - all results are the same: Loaded: loaded (/lib/systemd/system/haproxy.service; disabled) Active: failed (Result: signal) since Thu, 07 Feb 2013 17:18:43 +0200; 12s ago Process: 28125 ExecReload=/usr/sbin/haproxy -D -f /etc/haproxy/haproxy.cfg -p /var/run/haproxy.pid -sf $MAINPID (code=exited, status=0/SUCCESS) Process: 28118 ExecStart=/usr/sbin/haproxy -D -f /etc/haproxy/haproxy.cfg -p /var/run/haproxy.pid (code=exited, status=0/SUCCESS) Process: 28115 ExecStartPre=/usr/sbin/haproxy -c -q -f /etc/haproxy/haproxy.cfg (code=exited, status=0/SUCCESS) Main PID: 28126 (code=killed, signal=KILL) CGroup: name=systemd:/system/haproxy.service systemd script: [Unit] Description=HAProxy For TCP And HTTP Based Applications After=network.target [Service] Type=forking PIDFile=/var/run/haproxy.pid ExecStartPre=/usr/sbin/haproxy -c -q -f /etc/haproxy/haproxy.cfg ExecStart=/usr/sbin/haproxy -D -f /etc/haproxy/haproxy.cfg -p /var/run/haproxy.pid ExecReload=/usr/sbin/haproxy -D -f /etc/haproxy/haproxy.cfg -p /var/run/haproxy.pid -sf $MAINPID [Install] WantedBy=multi-user.target -- Best regards, Eugene Istomin On Thursday 07 February 2013 14:07:44 Baptiste wrote: You should have a new HAProxy process started using the new configuration and binding the ports... cheers On 2/7/13, Eugene Istomin e.isto...@edss.ee wrote: Thanks for the answer, as written in http://www.mgoff.in/2010/04/18/haproxy-reloading-your-config-with- minimal-service-impact/ The end-result is a reload of the configuration file which is not visible by the customer But in our case it leads to unbinding from all ports and finishing haproxy process. Can this issue related to rpm build options? RPM build log is https://build.opensuse.org/package/rawlog?arch=x86_64package=haproxy-1.5; project=server%3Ahttprepository=openSUSE_12.2 -- Best regards, Eugene Istomin On Thursday 07 February 2013 07:28:17 Willy Tarreau wrote: Hello Eugene, On Wed, Feb 06, 2013 at 08:29:33PM +0200, Eugene Istomin wrote: Hello, We have problem with reload/HUP: if i run #/usr/sbin/haproxy -D -f /etc/haproxy/haproxy.cfg -p /var/run/haproxy.pid -sf $(cat /var/run/haproxy.pid) - haproxy process is shutting down and exit This is the intended behaviour, it unbinds from its ports so that the new process can bind, then waits for all existing connections to terminate and leaves. Isn't it what you're observing ? What would you have expected instead ? Willy
Re: could a single ha proxy server sustain 1500 requests per second
Thanks Willy. On the same note you said not to run anything on the same machine, to lower costs I want to run other things on the haproxy front-end load balancer. What are the critical things to watch for on the server so I can be notified at what point having 2 things on the server are becoming a problem? On Wed, Dec 5, 2012 at 2:00 AM, Willy Tarreau w...@1wt.eu wrote: On Tue, Dec 04, 2012 at 02:19:30PM -0500, S Ahmed wrote: Hi, So 500 Mbits is 1/2 usage of a 1 Gbps port (haproxy and the back-end servers will have 1 Gbps connections). No, the traffic goes in opposite directions and the link is full duplex, so you can effectively have 1 Gbps in and 1 Gbps out at the same time. How does latency change things? e.g. what if it takes 90% clients 1 second to send the 20K file, while some may take 1-3 seconds. it's easy, you said you were counting on 1500 req/s : - 90% of 1500 req/s = 1350 req/s - 10% of 1500 req/s = 150 req/s 1350 req/s are present for one second = 1350 concurrent requests. 150 req/s are present for 3 seconds = 450 concurrent requests. = you have a total of 1800 concurrent requests (with one connection each, it's 1800 concurrent connections). What we can say with such numbers : - 1500 connections/s is light, even if conntrack is loaded and correctly tuned, you won't notice (we're doing twice this on a 500 Mbps Geode running on 1 watt). - 1800 concurrent connections is light too, multiply that by 16 kB, it's 30MB of RAM for the kernel-side sockets, and twice that at most for haproxy, so less than 100 MB of RAM. - 250 Mbps in both directions should not be an issue either, even my pc-card realtek NIC does it on my 8-years old pentium-M. At only 1800 concurrent connections, the latency will probably be mostly related to the NIC's interrupt rate. But we're speaking about hundreds of microseconds here. If you're concerned about latency, use a correct NIC, don't run any other software on the machine, and obviously don't run this in a VM ! Hoping this helps, Willy
Re: SSL handshake failure
Funny, with patch applied it establishes first connection after start normally. Then old thing continues. On Thu, Feb 7, 2013 at 6:58 PM, Willy Tarreau w...@1wt.eu wrote: On Thu, Feb 07, 2013 at 06:49:14PM +0400, Samat Galimov wrote: Thank you very much, overlooked your email due to filters, sorry for delay. I am very happy to help, sure I would accept a patch. Server is available from outside world but is not heavily used ??? we dont point load to it because of this SSL errors. By the way, I am using default haproxy-devel port in FreeBSD tree, so http://haproxy.1wt.eu/download/1.5/src/devel/haproxy-1.5-dev17.tar.gzsource is being used. OK, please find it attached. You should apply it on top of your current source tree and rebuild. Thanks, Willy
Re: SSL handshake failure
On Thu, Feb 07, 2013 at 09:22:37PM +0400, Samat Galimov wrote: Funny, with patch applied it establishes first connection after start normally. Then old thing continues. I'm unsure what you mean, do you mean the patch has slightly improved the situation but not completely ? Willy
Re: could a single ha proxy server sustain 1500 requests per second
On Thu, Feb 07, 2013 at 11:34:43AM -0500, S Ahmed wrote: Thanks Willy. On the same note you said not to run anything on the same machine, to lower costs I want to run other things on the haproxy front-end load balancer. What are the critical things to watch for on the server so I can be notified at what point having 2 things on the server are becoming a problem? First, you need to ensure that the machine never ever swaps. This is absolutely critical. The second important point to consider is that you don't want another process to use a lot of CPU on the same machine, or you want to dedicate some CPUs to other processes. And last point is that you don't want other processes to harm the network stack (eg: eat all the source ports by doing nasty things such as connecting and closing as a client, rendering the source port unusable for doing real work for 2 minutes). There are people who live very well with their LB doing several things, but the ones who do it without taking much care can really regret it. After all, the LB is the point where *all* your traffic passes, you certainly don't want it to slow down because a stupid process was started on it by accident. And some web sites can lose so much per minute of failure that they don't want to risk mixing workloads to save a $500 machine ! Regards, Willy
Re: installing SSL, and backend communication is non-ssl
On Thu, Feb 07, 2013 at 11:54:56AM -0500, S Ahmed wrote: Is it hard to install SSL with haproxy? I want all incoming connections to use SSL, but when haproxy communicates with the backends I don't want them to be ssl based. ANy tutorials on setting this up? With 1.5-dev17 (or whatever's the latest) that's fairly easy. Here's a config snippet. The :::443 thing is to make it bind to ipv6, which *:443 doesn't. The cert file has to be all the relevant certs concatenated; see the docs for more info. # Listen for ssl requests # 443, but get passed on to http-based ports for Apache listen https balance roundrobin mode http option http-server-close option forwardfor option httpchk HEAD /cytobank/images/logo_bigger.gif bind :::443 ssl crt /opt/haproxy/etc/wildcard.cert default_backend https_apache_localhost backend https_apache_localhost server server_0 localhost:83 check inter 3000 rise 1 fall 1 error-limit 1 on-error mark-down -Robin
Re: Consistent hashing based on cookie - across multiple HAProxy boxes
Hi Willy, Thanks for your suggestion. I'm guessing you mean something like this backend: backend x balance roundrobin stick-table type string size 32k peers other_haproxy_server expire 24h stick store-response set-cookie(PHPSESSID) If I understand you correctly, you are saying that this will only mean that sessions become persistant once PHPSESSID is set. So, to translate into practicality, as long as the login page creates the relevant cooke (and it does not subsequently change once logged in), this should work nicely. Thanks, -Alex On Sun, Feb 3, 2013 at 7:59 AM, Baptiste bed...@gmail.com wrote: Hi, the only way you could do what you want for now is using stick tables (and haproxy 1.5-dev17). You can learn the Set-Cookie from the server and match the Cookie in the table from the client. That way, all the request from a user will be sent to the same server, from the first to the last one. Today, haproxy is able to hash a HTTP header for load-balancing, so a configuration like: balance hdr(Cookie) could do the trick, but it means that ALL clients cookie to load-balance. And worste, since there is no phpsessionid cookie on the first request, there are chances that the first and the second requests won't be routed to the same server. I guess it would be possible soon to have a: balance cook(PHPSessionID) but it won't fix the sticking issue between first and second request since the cookie is not present in the first request. So if you really want using the algorithm method, you must be able to share cookies between your backend servers, only lucky people will be able to get authenticated. Well, maybe there are some dirty tricks like managing a farm for cookie-less clients and configuring PHP to learn an unknown session on the fly. Baptiste On Sun, Feb 3, 2013 at 2:03 AM, Alex Davies a...@davz.net wrote: Hi All, What is the best way to configure haproxy to hash based on an application cookie (such as PHPSESSID), in a way that is consistent (meaning multiple haproxy servers will route to the same backend), ideally including the ability to weight backends (the configuration would clearly have to be the same on these different boxes). appsession obviously allows this for a single HAProxy server, but it seems from the documentation that it generates a server based on the hash at the start of each session, so if the same session hit a different but identically configured haproxy server it would end up with a Thanks, -Alex
Re: Consistent hashing based on cookie - across multiple HAProxy boxes
ahah, you can call me Baptiste :) You miss a stick on cookie(PHPSESSID). Also consider using the same expire delay you have on your application server. And last but not least, add a peers section (and a peer directive on the stick-table definition) where you provide all your HAProxy server IPs in order to get the table of each HAProxy synchronized. then you're done. Baptiste On 2/8/13, Alex Davies a...@davz.net wrote: Hi Willy, Thanks for your suggestion. I'm guessing you mean something like this backend: backend x balance roundrobin stick-table type string size 32k peers other_haproxy_server expire 24h stick store-response set-cookie(PHPSESSID) If I understand you correctly, you are saying that this will only mean that sessions become persistant once PHPSESSID is set. So, to translate into practicality, as long as the login page creates the relevant cooke (and it does not subsequently change once logged in), this should work nicely. Thanks, -Alex On Sun, Feb 3, 2013 at 7:59 AM, Baptiste bed...@gmail.com wrote: Hi, the only way you could do what you want for now is using stick tables (and haproxy 1.5-dev17). You can learn the Set-Cookie from the server and match the Cookie in the table from the client. That way, all the request from a user will be sent to the same server, from the first to the last one. Today, haproxy is able to hash a HTTP header for load-balancing, so a configuration like: balance hdr(Cookie) could do the trick, but it means that ALL clients cookie to load-balance. And worste, since there is no phpsessionid cookie on the first request, there are chances that the first and the second requests won't be routed to the same server. I guess it would be possible soon to have a: balance cook(PHPSessionID) but it won't fix the sticking issue between first and second request since the cookie is not present in the first request. So if you really want using the algorithm method, you must be able to share cookies between your backend servers, only lucky people will be able to get authenticated. Well, maybe there are some dirty tricks like managing a farm for cookie-less clients and configuring PHP to learn an unknown session on the fly. Baptiste On Sun, Feb 3, 2013 at 2:03 AM, Alex Davies a...@davz.net wrote: Hi All, What is the best way to configure haproxy to hash based on an application cookie (such as PHPSESSID), in a way that is consistent (meaning multiple haproxy servers will route to the same backend), ideally including the ability to weight backends (the configuration would clearly have to be the same on these different boxes). appsession obviously allows this for a single HAProxy server, but it seems from the documentation that it generates a server based on the hash at the start of each session, so if the same session hit a different but identically configured haproxy server it would end up with a Thanks, -Alex
