HAProxy Sticky Sessions Within Request Body / Packet
Hi, Is it possible to decode a guid or session identifier that exists within a request packet's body?For example, if I would like to get the sessionID out of the body below? 12345 Kind Regards, Rohan
Sticky sessions
Hello guys Sorry that I'm distracting you but I was struggling with an error for 1 week and couldnt solve it by myself. Maybe you will have time to check my config to help a bit I've even made a topic in stackoverflow https://stackoverflow.com/questions/50149747/haproxy-sticky-sessions
Session persistence or sticky sessions in haproxy
Hi, I am having one website (crm.test.com) with 2 Apache server. I want to install Haproxy on this server, can i do following things with HaProxy. If my *web_server_1* goes down all the web http / https traffic should be on *web_server_1* whether it is down and all new request will go on *web_server_2* . Users serve by the web_server_1 get the session invalid or any custom error, they should not transfer to web_server_2. I am doing this because my website is session base. Can anyone suggest me. Devendra Joshi 8080106035 -- --
RE: sticky sessions with tcp mode
Thanks for the response. I changed to source ip. Application seems to like it better. Lukas Tribus luky...@hotmail.com 3/21/2015 4:44 AM I am having some issues with sticky sessions. The sessions are not sticking. I am using tcp mode with ssl. I have implemented the example out of the manual. The user is getting bounced back and forth between the two servers, which is causing issues in the application. Am I missing something? Probably because TLS tickets are used instead of the SSL session ID. Either disable TLS tickets on your backend or use some other stickiness methods, like source ip stickiness. Lukas -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. “CONFIDENTIALITY AND PROPRIETARY INFORMATION NOTICE: This email, including attachments, is covered by the Electronic Communications Privacy Act (18 U.S.C. 2510-2521) and contains confidential information belonging to the sender which may be legally privileged. The information is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution or the taking of any action in reliance of the contents of this information is strictly prohibited. If you have received this electronic transmission in error, please immediately notify the sender by return e-mail and delete this message from your computer or arrange for the return of any transmitted information.”
Re: sticky sessions with tcp mode
Thank you for support, we have fixed our issues. Ha. - Original Message - From: Richard Bassler richard.bass...@rsli.com To: haproxy@formilux.org, Lukas Tribus luky...@hotmail.com Sent: Monday, March 23, 2015 9:41:01 AM Subject: RE: sticky sessions with tcp mode Thanks for the response. I changed to source ip. Application seems to like it better. Lukas Tribus luky...@hotmail.com 3/21/2015 4:44 AM I am having some issues with sticky sessions. The sessions are not sticking. I am using tcp mode with ssl. I have implemented the example out of the manual. The user is getting bounced back and forth between the two servers, which is causing issues in the application. Am I missing something? Probably because TLS tickets are used instead of the SSL session ID. Either disable TLS tickets on your backend or use some other stickiness methods, like source ip stickiness. Lukas -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. “CONFIDENTIALITY AND PROPRIETARY INFORMATION NOTICE: This email, including attachments, is covered by the Electronic Communications Privacy Act (18 U.S.C. 2510-2521) and contains confidential information belonging to the sender which may be legally privileged. The information is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution or the taking of any action in reliance of the contents of this information is strictly prohibited. If you have received this electronic transmission in error, please immediately notify the sender by return e-mail and delete this message from your computer or arrange for the return of any transmitted information.”
Re: sticky sessions with tcp mode
Thank you for support, we have fixed our issues. Ha. - Original Message - From: Richard Bassler richard.bass...@rsli.com To: haproxy@formilux.org Sent: Friday, March 20, 2015 10:27:33 PM Subject: sticky sessions with tcp mode I am having some issues with sticky sessions. The sessions are not sticking. I am using tcp mode with ssl. I have implemented the example out of the manual. The user is getting bounced back and forth between the two servers, which is causing issues in the application . Am I missing something? HA-Proxy version 1.5.2 2014/07/12 frontend pc bind 192.168.10.72:443 mode tcp option tcplog default_backend pc backend pc mode tcp balance roundrobin stick-table type binary len 32 size 30k expire 30m acl clienthello req_ssl_hello_type 1 acl serverhello rep_ssl_hello_type 2 tcp-request inspect-delay 5s tcp-request content accept if clienthello tcp-response content accept if serverhello stick on payload_lv(43,1) if clienthello stick store-response payload_lv(43,1) if serverhello server r15-21 192.168.10.21:443 check server r16-22 192.168.10.22:443 check “CONFIDENTIALITY AND PROPRIETARY INFORMATION NOTICE: This email, including attachments, is covered by the Electronic Communications Privacy Act (18 U.S.C. 2510-2521) and contains confidential information belonging to the sender which may be legally privileged. The information is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution or the taking of any action in reliance of the contents of this information is strictly prohibited. If you have received this electronic transmission in error, please immediately notify the sender by return e-mail and delete this message from your computer or arrange for the return of any transmitted information.”
RE: sticky sessions with tcp mode
I am having some issues with sticky sessions. The sessions are not sticking. I am using tcp mode with ssl. I have implemented the example out of the manual. The user is getting bounced back and forth between the two servers, which is causing issues in the application. Am I missing something? Probably because TLS tickets are used instead of the SSL session ID. Either disable TLS tickets on your backend or use some other stickiness methods, like source ip stickiness. Lukas
sticky sessions with tcp mode
I am having some issues with sticky sessions. The sessions are not sticking. I am using tcp mode with ssl. I have implemented the example out of the manual. The user is getting bounced back and forth between the two servers, which is causing issues in the application. Am I missing something? HA-Proxy version 1.5.2 2014/07/12 frontend pc bind 192.168.10.72:443 mode tcp option tcplog default_backend pc backend pc mode tcp balance roundrobin stick-table type binary len 32 size 30k expire 30m acl clienthello req_ssl_hello_type 1 acl serverhello rep_ssl_hello_type 2 tcp-request inspect-delay 5s tcp-request content accept if clienthello tcp-response content accept if serverhello stick on payload_lv(43,1) if clienthello stick store-response payload_lv(43,1) if serverhello server r15-21 192.168.10.21:443 check server r16-22 192.168.10.22:443 check “CONFIDENTIALITY AND PROPRIETARY INFORMATION NOTICE: This email, including attachments, is covered by the Electronic Communications Privacy Act (18 U.S.C. 2510-2521) and contains confidential information belonging to the sender which may be legally privileged. The information is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution or the taking of any action in reliance of the contents of this information is strictly prohibited. If you have received this electronic transmission in error, please immediately notify the sender by return e-mail and delete this message from your computer or arrange for the return of any transmitted information.”
Re: Setting uuid cookies not for sticky sessions
On Thu, Feb 5, 2015 at 5:24 PM, Alberto alberto-hap4...@ggsys.net wrote: I have multiple back ends using different stacks. All I need is to ensure that every client gets a unique cookie. They don't need to be used for sticky sessions. Pretty much all the examples I find are for hard coding, prefixing and/or for sticky session purposes. Is there a way to get haproxy just set a simple uuid cookie if one isn't there? Thanks, Alberto Hi Alberto, You may be able to do something with the http-response set-header and the rand fetch. Baptiste
Setting uuid cookies not for sticky sessions
I have multiple back ends using different stacks. All I need is to ensure that every client gets a unique cookie. They don't need to be used for sticky sessions. Pretty much all the examples I find are for hard coding, prefixing and/or for sticky session purposes. Is there a way to get haproxy just set a simple uuid cookie if one isn't there? Thanks, Alberto
Re: Is it possible to have a minimum session time for HAPRoxy sticky sessions
Hi Duncan, You should use a a consistent hash to avoid dispatching your traffic each time a server fails or come back. In your backend declaration: hash-type consistent Baptiste On Fri, Nov 1, 2013 at 11:17 AM, Duncan Mason dma...@thinkanalytics.com wrote: We have HAProxy successfully performing sticky session routing based on a value in the request querystring with the following configuration command. balance url_param userId This works great and if application server A fails, then you can see subsequent requests being routed to a new target server B which is the desired behaviour. However, if application server A comes back online we see the requests for certain users once again being routed there which causes the users to experience 2 dropped sessions instead of just 1. Is there any way to tell HAProxy to pin requests for active sessions to server B for some minimum timeout period so that requests only return to Server A once those user sessions have expired? Any help on this much appreciated. Duncan Mason
Is it possible to have a minimum session time for HAPRoxy sticky sessions
We have HAProxy successfully performing sticky session routing based on a value in the request querystring with the following configuration command. balance url_param userId This works great and if application server A fails, then you can see subsequent requests being routed to a new target server B which is the desired behaviour. However, if application server A comes back online we see the requests for certain users once again being routed there which causes the users to experience 2 dropped sessions instead of just 1. Is there any way to tell HAProxy to pin requests for active sessions to server B for some minimum timeout period so that requests only return to Server A once those user sessions have expired? Any help on this much appreciated. Duncan Mason
How to get sticky sessions without cookies
Hello, Is it possible to get sticky sessions without using cookies? I was able to get sticky sessions using the cookie parameter but that would not work if cookies were disabled on purpose in the browser. Is there a workaround? Based on research, the options that constantly come up are using appsession and stick tables, but I haven't been able to understand how they operate. I would appreciate any help I can get with this. This is still relatively new to me so I am in a learning mode. Please let me know if you would like me to clarify my current set up. Thanks P.S. I posted a question yesterday as well, but I feel like this may slightly be different so I created a new one. If this is a problem please let me know, I wouldn't want to cause any problems.
Re: url based sticky sessions
Looking deeper it seems like stick tables might work here. Will these conflict with option http-server-close? -Joe On Jan 10, 2011, at 3:40 PM, Joe Williams wrote: List, Is it possible to setup an ACL that will any client that hits a specific uri will be sticky and subsequent requests will be routed to the same backend server? Note that I am using option http-server-close to force each request to hit a different server on the backend, I would like to continue to do this for all but one uri. Thanks. -Joe Name: Joseph A. Williams Email: j...@joetify.com Blog: http://www.joeandmotorboat.com/ Twitter: http://twitter.com/williamsjoe Name: Joseph A. Williams Email: j...@joetify.com Blog: http://www.joeandmotorboat.com/ Twitter: http://twitter.com/williamsjoe
Re: url based sticky sessions
Did a quick test and it seems option http-server-close always trumps the stick table and stick match. Do I have any options here? Thanks. -Joe On Jan 10, 2011, at 4:02 PM, Joe Williams wrote: Looking deeper it seems like stick tables might work here. Will these conflict with option http-server-close? -Joe On Jan 10, 2011, at 3:40 PM, Joe Williams wrote: List, Is it possible to setup an ACL that will any client that hits a specific uri will be sticky and subsequent requests will be routed to the same backend server? Note that I am using option http-server-close to force each request to hit a different server on the backend, I would like to continue to do this for all but one uri. Thanks. -Joe Name: Joseph A. Williams Email: j...@joetify.com Blog: http://www.joeandmotorboat.com/ Twitter: http://twitter.com/williamsjoe Name: Joseph A. Williams Email: j...@joetify.com Blog: http://www.joeandmotorboat.com/ Twitter: http://twitter.com/williamsjoe Name: Joseph A. Williams Email: j...@joetify.com Blog: http://www.joeandmotorboat.com/ Twitter: http://twitter.com/williamsjoe
Re: url based sticky sessions
On Tue, Jan 11, 2011 at 8:40 AM, Joe Williams j...@joetify.com wrote: List, Is it possible to setup an ACL that will any client that hits a specific uri will be sticky and subsequent requests will be routed to the same backend server? Note that I am using option http-server-close to force each request to hit a different server on the backend, I would like to continue to do this for all but one uri. Do you mean the whole URI or only part of it ? There is some code in the dev version of haproxy to stick session relatively to url parameter, but nothing else related to the url yet as far as I know. cheers, David
Re: url based sticky sessions
On Jan 10, 2011, at 5:06 PM, David Cournapeau wrote: On Tue, Jan 11, 2011 at 8:40 AM, Joe Williams j...@joetify.com wrote: List, Is it possible to setup an ACL that will any client that hits a specific uri will be sticky and subsequent requests will be routed to the same backend server? Note that I am using option http-server-close to force each request to hit a different server on the backend, I would like to continue to do this for all but one uri. Do you mean the whole URI or only part of it ? There is some code in the dev version of haproxy to stick session relatively to url parameter, but nothing else related to the url yet as far as I know. path_beg is good enough for me in this case. -Joe Name: Joseph A. Williams Email: j...@joetify.com Blog: http://www.joeandmotorboat.com/ Twitter: http://twitter.com/williamsjoe
Re: url based sticky sessions
On Tue, Jan 11, 2011 at 10:13 AM, Joe Williams j...@joetify.com wrote: path_beg is good enough for me in this case. Ok, there are two things here: - with ACL: you have a lot of options there, and I think you can get what you want with path_beg and similar query string-based ACL rules. - with stick tables: you don't have much options there w.r.t. url content, except url parameter. One big advantage of stick tables is that they can be shared between multiple haproxy instances. cheers, David
Re: sticky sessions based on request param
On Mon, Sep 13, 2010 at 08:06:37AM -0400, Karl Baum wrote: Hi Willy. The balance url_param looks like what I need. In regards to setting a cookie, in my case each of the http clients is actually an email fetching worker calling an imap api which will eventually sit behind HAProxy. Because each api node will have a connection pool of imap connections, depending on which email address the worker is processing, i want the request to be directed to the server which already has a pool of connections open for that email address. If i didn't do this, the more api nodes behind HAProxy, the more connections i will have open to the imap server and imap limits open connections to each email account. Each worker will be serving multiple email accounts and workers will process the same email account in parallel so i don't think the cookie based routing applies to this use case (but i could be wrong). OK, so what you describe perfectly matches the typical usage of a URL parameter hash. Is there significant overhead in the url_param hashing algorithm? No, it's still quite cheap. You should not notice it on a mailing system. Will the load be spread evenly across all nodes? yes, the hashing algorithm used tends to be quite smooth, but for that you obviously need a somewhat large population. I'd say that if your number of possible keys is about 100 times bigger than the number of nodes, you'll get quite a smooth distribution. Also, in the case of node failure, will the balance url_param pick another node? Yes, that's the same for all algorithms, provided that you enable health checks of course. The point to note with hashing algorithms is that when a node goes down, the farm size changes and everyone gets redispatched. This may or may not be desired. If this is a problem, you could use hash-type consistent to change the hashing algorithm to a consistent one : only the users of the failed node will be uniformly redispatched to remaining nodes. The downside is that consistent hashing is not as smooth at the normal one, but it might still be acceptable in your case. Regards, Willy
Re: sticky sessions based on request param
It sounds like balance url_param is exactly what i need. In regards to a node going down, hash-type consistent sounds great as i would like to keep my clients using the same node if it is still available. Thanks for your help! -karl On Sep 15, 2010, at 3:34 AM, Willy Tarreau wrote: On Mon, Sep 13, 2010 at 08:06:37AM -0400, Karl Baum wrote: Hi Willy. The balance url_param looks like what I need. In regards to setting a cookie, in my case each of the http clients is actually an email fetching worker calling an imap api which will eventually sit behind HAProxy. Because each api node will have a connection pool of imap connections, depending on which email address the worker is processing, i want the request to be directed to the server which already has a pool of connections open for that email address. If i didn't do this, the more api nodes behind HAProxy, the more connections i will have open to the imap server and imap limits open connections to each email account. Each worker will be serving multiple email accounts and workers will process the same email account in parallel so i don't think the cookie based routing applies to this use case (but i could be wrong). OK, so what you describe perfectly matches the typical usage of a URL parameter hash. Is there significant overhead in the url_param hashing algorithm? No, it's still quite cheap. You should not notice it on a mailing system. Will the load be spread evenly across all nodes? yes, the hashing algorithm used tends to be quite smooth, but for that you obviously need a somewhat large population. I'd say that if your number of possible keys is about 100 times bigger than the number of nodes, you'll get quite a smooth distribution. Also, in the case of node failure, will the balance url_param pick another node? Yes, that's the same for all algorithms, provided that you enable health checks of course. The point to note with hashing algorithms is that when a node goes down, the farm size changes and everyone gets redispatched. This may or may not be desired. If this is a problem, you could use hash-type consistent to change the hashing algorithm to a consistent one : only the users of the failed node will be uniformly redispatched to remaining nodes. The downside is that consistent hashing is not as smooth at the normal one, but it might still be acceptable in your case. Regards, Willy
Re: sticky sessions based on request param
Hi Willy. The balance url_param looks like what I need. In regards to setting a cookie, in my case each of the http clients is actually an email fetching worker calling an imap api which will eventually sit behind HAProxy. Because each api node will have a connection pool of imap connections, depending on which email address the worker is processing, i want the request to be directed to the server which already has a pool of connections open for that email address. If i didn't do this, the more api nodes behind HAProxy, the more connections i will have open to the imap server and imap limits open connections to each email account. Each worker will be serving multiple email accounts and workers will process the same email account in parallel so i don't think the cookie based routing applies to this use case (but i could be wrong). Is there significant overhead in the url_param hashing algorithm? Will the load be spread evenly across all nodes? Also, in the case of node failure, will the balance url_param pick another node? Thanks for your help! -karl On Sep 12, 2010, at 4:19 PM, Willy Tarreau wrote: Hello Karl, On Wed, Sep 08, 2010 at 08:36:30PM -0400, Karl Baum wrote: I am a beginner to haproxy meaning that i have never used it or any other load balancer before, but i wanted to get an idea of something was possible. hey, welcome to a world where you'll do many things that you'll find dirty, but will do them anyway because you can ;-) I would like to have sticky sessions based on only the value of a http request parameter such that if two different clients with the same request parameter make a request to the server, both requests will be handled by the same node. Let me know if that makes sense. Yes that makes sense. It is possible to hash a request parameter and select a server based on the result. Check balance url_param in the doc for more information. Also, usually stickiness involves cookies. Haproxy can insert (or even modify) a cookie in a response to note the server that handled the request. That way, when the client comes back, it knows what server to forward the request to. Maybe this is possible in your case and you don't need the url_param ? Regards, Willy
sticky sessions based on request param
I am a beginner to haproxy meaning that i have never used it or any other load balancer before, but i wanted to get an idea of something was possible. I would like to have sticky sessions based on only the value of a http request parameter such that if two different clients with the same request parameter make a request to the server, both requests will be handled by the same node. Let me know if that makes sense. thx. -karl
