On Wed, Feb 27, 2013 at 3:00 PM, Robbert van Waveren <[email protected]> wrote: > Hi, > > Ive got the following use-case that I cant seem to solve. > > Problem: > sticky session load balancing client-to-server SSL traffic without > decrypting it > assumption is that source ip and sslid can't be used as there are less > clients then servers in my scenario. > > My current solution (that does not work) is the following: > using an alias of the java sessionid as subdomainname within the request > and thus allowing HAProxy to see some per session unique id using SNI and > stick on that. > Both the clients and the servers run java 7 so they should be SSL SNI > capable. > > My problem is that currently "stick on req_ssl_sni" does not seem to be > supported: > 'stick': unknown fetch method 'req_ssl_sni' > > > example hostname pattern: > somesession1.myserver.local > somesession2.myserver.local > somesession3.myserver.local > somesession4.myserver.local > > my current configuration: > listen sticky_server_to_server_ssl > mode tcp > bind :1000 > balance roundrobin > > tcp-request inspect-delay 5s > tcp-request content accept if { req_ssl_hello_type 1 } > > stick-table type string len 20 size 2m expire 60m > stick on req_ssl_sni > > server srv1 10.0.0.1:2000 weight 1 maxconn 100 check > server srv2 10.0.0.2:2000 weight 1 maxconn 100 check > > Are there any obvious answers/solutions to this that could help me? > If not, does my solution make sense to support in HAProxy? > > Considering HAProxy does support sticking on payload, could I perhaps use > that for this: > acl clienthello req_ssl_hello_type 1 > stick-table type string len 20 size 2m expire 60m > stick on payload(...) if clienthello > > > Kind regards, > > Robbert >
Hi Robbert, first of all, in order to do this, you must have a wildcard certificate, otherwise your client will get warnings (I don't know how you can manage such warnings in your Java client code). Second, you want to do persistence on an information provided by the client, BUT HAProxy can't learn it on the fly from the server first, which means that HAProxy may send the first and the second request from the same session to 2 different servers. but from request #2, you will have the persistence. the diagram bellow shows what happens: 1. client to haproxy to server on https://domain.com with SNI domain.com 2. server answers "come back to clientX.domain.com" 3. client to haproxy with https://clientX.domain.com + SNI clientX.domain.com ==> there are no link between requests from #1 and #3. so at #3, haproxy may choose a different server from #1, but will store clientX.domain.com in the stick table then whenever clientX.domain.com will get connected again, then HAProxy will be able to maintain persistence and redirect this user to the same server forerver (until expire timeout in the stick table actually). More about load-balancing and persistence: http://blog.exceliance.fr/2012/03/29/load-balancing-affinity-persistence-sticky-sessions-what-you-need-to-know/ Last but not least, you should avoid persistence on the first domain, because you may redirect all first requests to a single server, making it to generate symmetric keys which takes a huge amount of CPU resources (furthermore if your cert is big: 2K or more)... ! Baptiste
